关于Android SDK里的compileSdk、minSdk

  categories:资料  author:

本篇文章介绍了Android SDK更新的包里关于compileSdk、minSdk、targetSdk、buildTools、Tools、Platform-tools的概念

0 前言

在开发中经常发现有AS有更新提示,在之前没有完全弄明白这些SDK,Tools的概念前都不敢轻易去更新,总担心更完就编译出错,API不能用==情况。所以对这几个概念进行深度梳理。
1 参考文章

国外一篇很清楚的关于compileSdk、minSdk、targetSdk的文章,建议看完译文后再重新看一遍原文

原文:
picking-your-compilesdkversion-minsdkversion-targetsdkversion

译文:
如何选择 compileSdkVersion, minSdkVersion 和 targetSdkVersion

关于tools的解释:
Android关于buildToolVersion与CompileSdkVersion的区别
2 compileSdk、minSdk、targetSdk到概念

以下内容摘自译文
2.1 compileSdkVersion

compileSdkVersion 告诉 Gradle 用哪个 Android SDK 版本编译你的应用。使用任何新添加的 API 就需要使用对应 Level 的 Android SDK。

需要强调的是 修改 compileSdkVersion 不会改变运行时的行为 … 阅读全文

Android基础之自定义Application

  categories:资料  author:

Application

Android提供了一个Application类,每当应用程序启动时,系统会自动将这个类进行初始化。在项目中,我们在一些工具类采用了单例模式,其生命周期和整个应用程序相同,并且可能直接或者间接的需要Context引用来进行获取资源的操作。那么我们需要一个全局Context也就是Application。

Android基础之Context文章中我们知道,Application生命周期是整个App

自定义Application用途

  • 为得到一个Application对象提供便捷
  • 封装一些通用操作
  • 初始化一些全局的变量数据

对于前两点,Google官方是不建议这样做的。因为使用一个单例模式同样可以做到。但是自定义Application没有任何副作用。而在Application中的onCreate()方法里去初始化各种全局的变量数据是一种比较推荐的做法。

自定义Application

新建一个Application类

新建一个MyApplication并让它继承自Application

public class MyApplication extends Application{
    private static Context mContext;

    @Override
    public void onCreate() {
        super.onCreate();
        mContext = getApplicationContext()
阅读全文

简单的线性规划问题

  categories:资料  author:

简单的线性规划问题在高中数学里体现了数形结合的思想方法,特别是线性规划中的参数问题是考试重点与难点之一,因此根据教学体会,写出一点解线性规划问题方法,希望能给同学们有一点小帮助。

一、二元一次不等式组表示的平面区域

(1)一般地,二元一次不等式Ax+By+C>0在平面直角坐标系中表示直线Ax+By+C=0某一侧所有点组成的平面区域。我们把直线画成虚线以表示区域不包括边界直线。当我们在坐标系中画不等式Ax+By+C≥0所表示的平面区域时,此区域应包括边界直线,则把边界直线画成实线。

(2)由于对直线Ax+By+C=0同一侧的所有点(x,y),把它的坐标(x,y)代入Ax+By+C,所得的符号都相同,所以只需在此直线的同一侧取一个特殊点(x0,y0)作为测试点,由Ax0+By0+C的符号即可判断Ax+By+C>0表示的直线是在Ax+By+C=0哪一侧的平面区域。

(1)

【方法总结】

确定二元一次不等式(组)表示的平面区域的方法:

(1)“直线定界,特殊点定域”,即选作直线,再取特殊点并代入不等式组,若满足不等式组,则不等式(组)表示的平面区域为直线与特殊点同侧的那部分区域;否则就对应与特殊点异侧的平面区域.若直线不过原点,特殊点一般取(0,0)点。

(2)当不等式中带等号时,边界为实线,不带等号时,边界应画为虚线,特殊点常取原点。

二、 目标函数的最值问题

(2)

解决线性规划问题的主要方法策略:

(1)截距法:作出线性约束条件表示的平面区域,将线性目标函数对应的直线方程化为斜截式,再将截距变为0得到过原点的直线,平移此直线使之始终保持与平面区域有公共点,截距的最值即为线性目标函数的最值。此种方法是最常见的解决线性规划问题的策略,对平面区域作图以及线性目标函数对应直线相对于平面区域边界直线的倾斜程度的准确性要求较高。

(2)顶点法:如果可行域是一个多边形围成的区域(包括边界多边形)时,线性目标函数z=f(x,y)的最优解一般在多边形的顶点处取到,排除在边界处取到的情况,先分别计算出线性目标函数z=f(x,y)在各个顶点处的函数值,再比较大小即可。

三、线性规划中的参数问题

(3)

求解线性规划中含参数问题的方法:

(1)若限制条件中含参数,依据参数的不同范围将各种情况下的可行域画出来,寻求最优解,确定参数的值;

(2)若线性目标函数中含有参数,可对线性目标函数的斜率分类讨论,以此来确定线性目标函数经过哪个顶点取得最值,从而求出参数的值;也可以直接求出线性目标函数经过各顶点时对应的参数的值,然后进行检验,找出符合题意的参数值。

———————

今天方法君给大家整理一下线性规划的内容,这是解析几何的重点。但是这块内容高考只考察5分,一般以选填的情况出现,难度不大。同学们需要的是细心,以及熟练掌握直线的相关性质。

线性规划

 

来源:http://www.sohu.com/a/249140600_100250056

——————

1

线性规划是数形结合的体现

线性规划实质上是“数形结合”数学思想方法在一个方面的体现,将最值问题借助图形直观、简便地寻找出来,是一种较快地求最值的方法。在求解应用问题时要特别注意题目中的变量的取值范围,不可将范围盲目扩大.

2
3

探究提高

本题主要考查不等式表示的平面区域、数列求和及不等式的应用等基础知识,考查了数形结合的方法和逻辑推理能力.

不等式组表示的平面区域是各个不等式所表示的平面区域点集的交集,因而是各个不等式所表示的平面区域的公共部分.在封闭区域内找整点数目时,若数目较小时,可画网格逐一数出;若数目较大,则可分x=m逐条分段统计.

5
6

探究提高

线性目标函数的最大(小)值一般在可行域的顶点处取得,也可能在边界处取得.求线性目标函数的最优解,要注意分析线性目标函数所表示的几何意义——在y轴上的截距或其相反数.

7
8

探究提高

解线性规划应用问题的一般步骤是:1分析题意,设出未知量;2列出线性约束条件和目标函数;3作出可行域并利用数形结合求解;4作答.

9
10
11
12

批阅笔记

阅读全文

转微服务写的最全的一篇文章

  categories:资料  author:

今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。

1.什么是微服务

1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可)

2)独立的进程(java的tomcat,nodejs等)

3)轻量级的通信(不是soap,是http协议)

4)基于业务能力(类似用户服务,商品服务等等)

5)独立部署(迭代速度快)

6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择)

ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。

2. 怎么权衡微服务的利于弊

利:

强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活)

可独立部署。

技术多样性。

弊:

分布式复杂性。

最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题)

运维复杂性。

测试复杂性。

3. 企业在什么时候考虑引入微服务

从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的时候,业务简单,用单体服务反而生产力很高。随着公司的发展,业务复杂性慢慢提高,这时候就可以采用微服务来提升生产力了。至于这个转化的点,需要团队的架构师来进行各方面衡量,就个人经验而言,团队发展到百人以上,采用微服务就很有必要了。

有些架构师是具有微服务架构能力,所以设计系统时就直接设计成了微服务,而不是通过单服务慢慢演化发展成微服务。在这里我并不推荐这种做法,因为一开始对业务领域并不是很了解,并且业务模式还没有得到验证,这时候上微服务风险比较高,很有可能失败。所以建议大家在单服务的应用成熟时,并且对业务领域比较熟悉的时候,如果发现单服务无法适应业务发展时,再考虑微服务的设计和架构。

4.微服务的组织架构

如上图左边,传统的企业中,团队是按职能划分的。开发一个项目时,会从不同的职能团队找人进行开发,开发完成后,再各自回到自己的职能团队,这种模式实践证明,效率还是比较低的。

如上图右边,围绕每个业务线或产品,按服务划分团队。团队成员从架构到运维,形成一个完整的闭环。一直围绕在产品周围,进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模,建议按照亚马逊的两个披萨原则,大概10人左右比较好。

5:怎么理解中台战略和微服务

中台战略的由来:马云2015年去欧洲的一家公司supersell参观,发现这个公司的创新能力非常强,团队的规模很小,但是开发效率很高。他们就是采用中台战略。马云感触很深,回国后就在集团内部推出了中台战略。

简单的理解就是把传统的前后台体系中的后台进行了细分。阿里巴巴提出了大中台小前台的战略。就是强化业务和技术中台,把前端的应用变得更小更灵活。当中台越强大,能力就越强,越能更好的快速响应前台的业务需求。打个比喻,就是土壤越肥沃,越适合生长不同的生物,打造好的生态系统。

6:服务分层

每个公司的服务分层都不相同,有的公司服务没有分层,有的怎分层很多。目前业界没有统一的标准。

下面推荐一个比较容易理解的两层结构。

1:基础服务: 比如一个电商网站,商品服务和订单服务就属于基础服务(核心领域服务)。缓存服务,监控服务,消息队列等也属于基础服务(公共服务)

2:聚合服务 :例如网关服务就算一种聚合服务(适配服务)。

这是一种逻辑划分,不是物理划分,实际设计的东西很多很复杂。

7:微服务的技术架构体系

阅读全文

微服务架构介绍

  categories:资料  author:

最近在整理单位的微服务的事情, 因此在网络上搜索到一些资料, 感觉一些内容很全, 需要记录一下就记录下来。

下面这个文章整理的很好, 内容丰富, 但是后面一些内容感觉太复杂了, 学习成本, 实施成本,运维成本都很高, 作为学习的资料还是很好的。

微服务核心架构梳理

业界主流微服务框架的核心原理,包括服务发现,网关,配置中心,监控等组件,功能和架构原理的简单介绍。感谢阅读!

什么是微服务

微服务Microservices之父,马丁.福勒,对微服务大概的概述如下:

就目前而言,对于微服务业界并没有一个统一的、标准的定义(While there is no precise definition of this architectural style ) 。 但通在其常而言,微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成一组小的服务,每个服务运行独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。 另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务,也可以使用不同的数据存储。

根据马丁.福勒的描述,我总结了一下几点:


(字差,勿嫌)

小服务

小服务,没有特定的标准或者规范,但他在总体规范上一定是小的。

进程独立

每一组服务都是独立运行的,可能我这个服务运行在tomcat容器,而另一个服务运行在jetty上。可以通过进程方式,不断的横向扩展整个服务。… 阅读全文

微服务设计模式

  categories:资料  author:

这里说的是为服务设计模式,  题目很大, 也不知道能否说好, 先简单的有一下, 有问题的地方我在修改!

双十一刚刚过去, 我们也沾上一点双十一的热气,现在电商系统可谓五花八门,形形色色,表面看就是一个卖东西, 其实地下包括了商品展示、商品管理、商品库存、商家、支付、保险、运输等等非常多的环节。 有的商品是房子,有的商品是家电等等! 他们的购买流程是一样的吗?估计买房子的流程同其他的流程完全不同了!

一. 传统的单一服务应用

1. 传统单一服务系统应用场景

传统的应用系统通常如下图:

用户通过互联网访问应用系统, 然后在应用系统内部调用数据库系统。

通常情况下各个功能模块都集中在应用系统中,这样开发简单,维护方便,在业务量不大的情况下还是比较实用的。

但是到了双十一这个超级压力大的情况下, 传统的系统就有些问题了,如上图中小绿负责的模块包括了一个慢查询语句,这样系统的整个资源都被占满了, 造成其他相关模块无辜的被拖累。 具体如下图

上图中可以清楚看到在传统的业务系统中经常将一系列耦合比较小或者相关性不大的模块合并到一起进行开发、测试、部署、维护等等, 这样在业务量不大时还看不出问题, 但当公司业务发展, 系统访问量增大后, 就有了上图的问题。

理论一点说法:传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR,部署在Tomcat或者Jetty上。

2. 这种单体应用比较适合于小项目,优点是:

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

3. 单体应用的缺点

当然它的缺点也十分明显,特别对于互联网公司来说:

缺点一:项目过于臃肿

当大大小小的功能模块都集中在同一项目的时候,整个项目必然会变得臃肿,让开发者难以维护。

缺点二:资源无法隔离

就像刚刚小灰的经历一样,整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源,一旦某个功能模块对资源使用不当,整个系统都会被拖垮。… 阅读全文

JSON入门

  categories:资料  author:

什么是json?为什么用json?

json是一种采用文本方式表示数据的方法!  请注意这里最重要的就是这个  文本方式表示数据的  文本是及其重要的!!

原因是 文本是  计算机里面非常普遍 非常普遍的, 在说一下, 非常普遍的方式, 普遍到, 你随便找个计算机就可以有文本查看,和编辑的工具, 这样 就非常方便的  查看,编辑 json的文本了, 便于调试、开发、修改等等!

及其重要的, 无论您水平多高, 程序都可能有bug的, 因此若是一个程序出了问题是  读取或者操作的数据有问题, 还是程序问题?   这样json的普通程序都可以查看的  特点为我们调试程序带来了福音!!

另外json除了普通外, 还有强大, 从文本数据, 二进制数据,流量流, 图片,声音等等, 只要你能搞到内存中, 就可以用json来表示, 你看人家支持byte[] 数据的, 因此只要你能变为byte[] 就能变为json,并且是文本!!

好了, 下面是网络上介绍json的两个资料整理到这里了, 大家有空慢慢看吧。… 阅读全文

一篇文章快速理解微服务架构

  categories:资料  author:

什么是微服务

首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应用,来理解什么是微服务。
1.jpg

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下:

尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR,部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目,优点是:

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

当然它的缺点也十分明显,特别对于互联网公司来说:

  • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
  • 代码维护难:代码功能耦合在一起,新人不知道何从下手
  • 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
  • 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
  • 扩展性不够:无法满足高并发情况下的业务需求

所以,现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用,而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能,比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。** 如果你想和更多微服务技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态**。

比如,前面描述的系统可被分解为:

2.jpg

每个业务逻辑都被分解为一个微服务,微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下,这些客户端并不能直接访问后台微服务,而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务架构的优点

微服务架构有很多重要的优点。首先,它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变,但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平,而这通过单体代码库很难实现。因此,微服务开发的速度要快很多,更容易理解和维护。

其次,这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约,开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务,由于服务相对较小,所以这并不会对整体应用造成太大影响。

第三,微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI/CD成为可能。

最后,微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务,在EC2内存优化实例上部署内存数据库服务。

微服务架构的缺点和挑战

实际上并不存在silver bullets,微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似,微服务强调了服务大小,但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务,这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的,但要记住,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署。

微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。

微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单,因为单体应用往往只存在一个数据库。但在微服务架构下,不同服务可能拥有不同的数据库。CAP原理的约束,使得我们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来说是一个挑战。

微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API即可,而对微服务进行测试,需要启动它依赖的所有其他服务。这种复杂性不可低估。

微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中,若有A、B、C三个服务需要更改,A依赖B,B依赖C。我们只需更改相应的模块,然后一次性部署即可。但是在微服务架构中,我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C,然后更新B,最后更新A。

部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上,然后前端使用负载均衡即可。每个应用都有相同的基础服务地址,例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外,我们还需要服务发现机制,以便服务可以发现与其通信的其他服务的地址。因此,成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。

以上问题和挑战可大体概括为:

  • API Gateway
  • 服务间调用
  • 服务发现
阅读全文

漫画:什么是微服务

  categories:资料  author:

单体架构的痛点

缺点一:项目过于臃肿

当大大小小的功能模块都集中在同一项目的时候,整个项目必然会变得臃肿,让开发者难以维护。

缺点二:资源无法隔离

就像刚刚小灰的经历一样,整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源,一旦某个功能模块对资源使用不当,整个系统都会被拖垮。

缺点三:无法灵活扩展

当系统的访问量越来越大的时候,单体系统固然可以进行水平扩展,部署在多台机器上组成集群:

但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块,希望只针对支付模块做水平扩展,这一点在单体系统是做不到的。

什么是微服务?

微服务(Microservice Architecture)是近几年流行的一种架构思想,关于它的概念很难一言以蔽之。

究竟什么是微服务呢?我们在此引用 ThoughtWorks 公司的首席科学家 Martin Fowler 的一段话:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in

阅读全文

Android在子线程中更新UI的方法汇总(共七种)

  categories:资料  author:

Android在子线程中更新UI的方法汇总(共七种)

1、常规写法:new Handler()的handleMessage()和handler.sendMessage(msg)

    Handler handler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };

   new Thread(new Runnable() {
            @Override
            public void run() {
                Message msg = Message.obtain();
                msg.what = 1000;
                msg.arg1 = 10;
                handler.sendMessage(msg);
            }
        }).start();
阅读全文


快乐成长 每天进步一点点      京ICP备18032580号-1