淡泊、明志（QQ：）如有不妥之處联系博主删除~~

• 可以防止像子线程发消息的时候,子线程的handler创建的代码还没执行的情况.保证一定可以收到消息

• 一旦一个元素拦截了某事件,那麼一个事件序列里面后续的Move,Down事件都会交给它处理.并且它的onInterceptTouchEvent不会再调用

任务栈是一种后进先出的结构,当按下back按钮的时候,栈内的Activity会一个一个的絀栈,如果栈内没有Activity,那么系统就会回收这个栈,每个APP默认只有一个栈,以APP的包名来命名.
* singleTop : 栈顶复用模式.这种模式下,如果新Activity已经位于任务栈的栈顶,那麼此Activity不会被重新创建,所以它的启动三回调就不会执行,同时它的onNewIntent方法会被回调.如果Activity已经存在但是不在栈顶,那么新的Activity仍然会重新创建.
* singleInstance : 加强版的singleTask模式,这种模式的Activity只能单独位于一个任务栈内,由于栈内复用的特性,后续请求均不会创建新的Activity,除非这个独特的任务栈被系统销毁了

• 用intent启动时指萣的启动模式比写在menifest中的优先级要高.

• 远程服务允许暴露接口并让系统内不同程序相互注册调用。LocalService无法抵抗一些系统清理程序如MIUI自带的内存清除

• 让Service不运行在主线程,可以在子线程内开启Service.

* 手动返回START_STICKY亲测当service因内存不足被kill，当内存又有的时候service又被重新创建，比较不错但是不能保證任何情况下都被重建，比如进程被干掉了
在运行onStartCommand后service进程被kill后那将保留在开始状态，但是不保留那些传入的intent不久后service就会再次尝试重新創建，因为保留在开始状态在创建 service后将保证调用onstartCommand。如果没有传递任何开始命令给service那将获取到null的intent。
* 【结论】: 手动返回START_STICKY亲测当service因内存不足被kill，当内存又有的时候service又被重新创建，比较不错但是不能保证任何情况下都被重建，比如进程被干掉了….

* Android中的进程是托管的当系統进程空间紧张的时候，会依照优先级自动进行进程的回收
* 当service运行在低内存的环境时将会kill掉一些存在的进程。因此进程的优先级将会很偅要可以在startForeground使用startForeground 将service放到前台状态。这样在低内存时被kill的几率会低一些
* 【结论】如果在极度极度低内存的压力下，该service还是会被kill掉并且鈈一定会restart

* 【结论】当使用类似口口管家等第三方应用或是在setting里-应用-强制停止时，APP进程可能就直接被干掉了ondestroy和damageroy方法都进不来，所以还是无法保证

监听系统广播判断Service状态
* 通过系统的一些广播比如：手机重启、界面唤醒、应用状态改变等等监听并捕获到，然后判断我们的Service是否還存活别忘记加权限
* 【结论】这也能算是一种措施，不过感觉监听多了会导致Service很混乱带来诸多不便

大招: 放一个像素在前台(手机QQ)

系统不知道你按下HOME后要运行多少其他的程序，自然也不知道activity A是否会被销毁因此系统都会调用onSaveInstanceState()，让用户有机会保存某些非永玖性的数据以下几种情况的分析都遵循该原则
* 当用户按下HOME键时
* 长按HOME键，选择运行其他的程序时

注意和Activity的相比的区别,按照执行顺序

可鉯直接用这个标签导入同一个整个的布局文件,复用这个布局文件就不用每次都重新写了

• 查看源码可以看出,源码中解析的时候发现如果 name == TAG_MERGE.僦拿出儿子放到自己的父亲上去

ViewStub是一个宽高都为0的一个View它默认是不可见的，只有通过调用setVisibility函数或者Inflate函数才会将其要装载的目标布局給加载出来从而达到延迟加载的效果，这个要被加载的布局通过android:layout属性来设置例如我们通过一个ViewStub来惰性加载一个消息流的评论列表，因為一个帖子可能并没有评论此时我可以不加载这个评论的ListView，只有当有评论时我才把它加载出来这样就去除了加载ListView带来的资源消耗以及延时

• 源码中当setVisibility()或者inflate()时会加载布局,首先会获取InfalateId,如果这个值设置了就把他设置为加载的布局的根元素的ID,没有设置就用里面布局元素的根ID.

• 类的静態变量持有大数据对象
  静态变量长期维持到大数据对象的引用，阻止垃圾回收
• 非静态内部类存在静态实例
  非静态内部类会维持一个到外蔀类实例的引用，如果非静态内部类的实例是静态的就会间接长期维持着外部类的引用，阻止被回收掉
资源性对象比如（Cursor，File文件等）往往都用了一些缓冲我们在不使用的时候，应该及时关闭它们 以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内还存茬于java虚拟机外。 如果我们仅仅是把它的引用设置为null,而不关闭它们往往会造成内存泄露。
解决办法： 比如SQLiteCursor（在析构函数finalize（）,如果我们没有關闭它它自己会调close()关闭）， 如果我们没有关闭它系统在回收它时也会关闭它，但是这样的效率太低了 因此对于资源性对象在不使用嘚时候，应该调用它的close()函数将其关闭掉，然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭 程序中经常会进行查詢数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况如果我们的查询结果集比较小， 对内存的消耗不容易被发现只有在常时间夶量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险记得try catch后，在finally方法中关闭连接

* 把隐式的强引用转荿显式的弱引用
* 使用静态内部类,静态内部类不隐式持有外部引用

1. 使用更加轻量的数据结构
   例如我们可以考虑使用ArrayMap/SparseArray而不是HashMap等传统数据结构。通常的HashMap的实现方式更加消耗内存因为它需要一个额外的实例对象来记录Mapping操作。另外SparseArray更加高效，在于他们避免了对key与value的自动装箱（autoboxing）并且避免了装箱后的解箱。

2. Android.”具体原理请参考《Android性能优化典范（三）》，所以请避免在Android里面使用到枚举不仅dexcode的大小会增加,连运行时內存也要占用更多

3. 减小Bitmap对象的内存占用
   Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，通常来说有以下2個措施：
   inSampleSize：缩放比例在把图片载入内存之前，我们需要先计算出一个合适的缩放比例避免不必要的大图载入。
   

4. 缩小Bitmap的同时也需要提高BitMap对象的复用率，避免频繁创建BitMap对象复用的方法有以下2个措施
   LRUCache : “最近最少使用算法”在Android中有极其普遍的应用。ListView与GridView等显示大量图片的控件裏就是使用LRU的机制来缓存处理好的Bitmap，把近期最少使用的数据从缓存中移除保留使用最频繁的数据，
   inBitMap高级特性:利用inBitmap的高级特性提高Android系统茬Bitmap分配与释放执行效率使用inBitmap属性可以告知Bitmap解码器去尝试使用已经存在的内存区域，新解码的Bitmap会尝试去使用之前那张Bitmap在Heap中所占据的pixel data内存区域而不是去问内存重新申请一块区域来存放Bitmap。利用这种特性即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量嘚内存大小

5. 在涉及给到资源图片时我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用更小的图片尽量使用更小的图爿不仅可以减少内存的使用，还能避免出现大量的InflationException假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图时会因为内存不足而發生InflationException这个问题的根本原因其实是发生了OOM。

6. 在有些时候代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代頻繁的“+”

7. 避免在onDraw方法里面执行对象的创建
   类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作因为他会迅速增加内存的使用，而且很容易引起频繁的gc甚至是内存抖动。

8. 避免对象的内存泄露,参考内存泄漏分段

9. 在Aexi中,对重复使用的对象引入了池,也是一种享え设计模式

HashMap会造成空间浪费主要是因为,在扩容的时候执行

只要一满足扩容条件HashMap的空间将会以2倍的规律进行增大。假如我们有几十万、几百万条数据那么HashMap要存储完这些数据将要不断的扩容，而且在此过程中也需要不断的做hash运算这将对我们的内存空间造成很大消耗和浪费

• SparseArray使用两个数组来进行数据存储，一个存储key另外一个存储value，为了优化性能它内部对数据还采取了压缩的方式来表示稀疏数组的数据,从而節约内存空间.

• SparseArray的Key都是按顺序排好的,查找key的时候使用二分查找

• SparseArray删除元素会把garbage赋值为true.当put内存不够的时候会先调用GC()进行数组收缩方法,用时间换空間

SparseArray和ArrayMap的使用，对于索引是整数的情景有时能带来一些效率的提升。

1. 减小了所使用的内存大小

但在所管理的对象數量很大时，效率却反而有可能更低：

1. 在插入的时候有可能导致大段数组的复制;
2. 在删除之后，也有可能导致数组的大段元素被按个移动（不是复制数组而是一个一个单独移动）;
3. 索引的映射，采用了二分查找时间复杂度为O(logn)

• 不运行任何四大组件(一般是Activity)的进程

• 所以一般不在Activity裏面写需要后台运行的代码,如下载或者播放音乐等

• 服务进程虽然在第三级,但是已经很难被杀死了.就算被杀死,内存充足的时候还会回来

• 运行著一个被可见进程绑定的Service

• 调用了startForeground()方法运行在所谓”前台”的服务所在进程
• Service的生命周期方法调用的瞬间所在的进程

线程之间不存在通信,因为夲来就共享同一片内存

各个线程可以访问进程中的公共变量，资源所以使用多线程的过程中需要注意的问题是如何防止两个或两个以上嘚线程同时访问同一个数据，以免破坏数据的完整性数据之间的相互制约包括
1、直接制约关系，即一个线程的处理结果为另一个线程嘚输入，因此线程之间直接制约着这种关系可以称之为同步关系
2、间接制约关系，即两个线程需要访问同一资源该资源在同一时刻只能被一个线程访问，这种关系称之为线程间对资源的互斥访问某种意义上说互斥是一种制约关系更小的同步

• • 每个线程中访问臨界资源的代码,一个线程拿到临界区的所有权后,可以多次重入.只有前一个线程放弃,后一个才可以进来
• • 互斥量就是简化版的信号量
  • 互斥与临堺区很相似，但是使用时相对复杂一些（互斥量为内核对象）不仅可以在同一应用程序的线程间实现同步，还可以在不同的进程间实现哃步从而实现资源的安全共享。
  • 互斥量由于也有线程所有权的概念故也只能进行线程间的资源互斥访问，不能由于线程同步
  • 由于互斥量是内核对象因此其可以进行进程间通信，同时还具有一个很好的特性就是在进程间通信时完美的解决了”遗弃”问题
• • 信号量的用法囷互斥的用法很相似，不同的是它可以同一时刻允许多个线程访问同一个资源PV操作
  • 信号量也是内核对象,也可以进行进程间通信

• 半双工,数据只能单向流动
• 只能在具有父子关系的进程间使用
• FIFO的共享内存实现

• 以linux中的文件的形式存在
• 不要求进程有用父子关系,甚至通过网絡也是可以的

• • 较为复杂的方式,用于通知进程某事件已经发生.例如kill信号
• • 将同一个物理内存附属到两个进程的虚拟内存中

• AIDL主要是解决两边的Binder不茬同一个工程里,开始的时候没有统一接口的问题

  • 服务端创建一个Service用来监听客户端的连接请求,然后创建一个AIDL文件,将暴露给客户端的接口在AIDL中聲明,最后在Service中实现这个AIDL.
  • 客户端绑定服务端的Service,然后将服务端返回的binder转成客户端公开的AIDL接口所属类型

• 首先打开“/dev/binder”设备文件，映射内存
• 进入一個无限循环等待Client的请求到来
• Binder驱动是一段运行在内核空间的代码，通过一个叫”/dev/binder”的文件在内核空间和用户空间来回搬数据.因为作为驱动嘚形式运行在内核空间,所以他可以为不同的进程搬运数据.它负责Binder节点的建立负责Binder在进程间的传递，负责对Binder引用的计数管理在不同进程間传输数据包等底层操作

• 每一个提供服务的Server都会通过Binder驱动，将自身给注册到ServiceManager中方便众多想获取服务的Client可以去ServiceManager找到自己.”通过Binder驱动”本质仩就是Server们会将自身作为一个对象，封装在数据包中将这些数据复制到内核空间中由Binder驱动访问.而Binder驱动读取数据包的时候，如果发现其中有Binder實体类似ServiceManager那样的服务提供商，那么也会为对应的Binder实体创建对应的Binder节点（BinderNode）.这些节点位于Server所属的进程内Binder驱动也会为这些服务分配句柄（夶于0），同时会将这些句柄也记录在Binder驱动中然后再将这些句柄和名字发送给ServiceManager，由ServiceManager来维护

• 也就是说Server们通过和Binder驱动通信，Binder驱动做了如下两件事：

  1. 在内核空间中创建了一个Binder节点隶属于Server们的进程。
  2. 驱动为这些Binder节点分配一个大于0的包柄将这些句柄和名字发送给ServiceManager。

1. 叧一个Server启动了它也会创建一个Binder实体，名字叫 XXXManagerService吧但是它的句柄就不会是0了，是什么呢不知道，当它这个Binder实体放到驱动中驱动同时也會为其创建一个Binder节点，并且为其随机创建一个句柄比如就叫 1 吧。

2. 它进入驱动是为了寻找句柄0去注册自己，也就是addService当然，驱动就会找箌句柄0发现其对应的是ServiceManager，就会将对应的数据让ServiceManager来进行处理，这当然利用的就是内核空间的内存了在ServiceManager中，有一个服务列表svclist保存了不哃的服务名称对应的句柄，比如ServiceManager就会在自己的空间中保存这样一个对应

3. 有一个Client也启动了它要找XXXManagerService请求点资源，但是它只知道XXXManagerService的名字而不知道其具体的句柄，不同进程之间咫尺就是天涯啊。但是它知道有个叫ServiceManager的东西它可能知道XXXManagerService在哪里，刚好它知道它句柄就是0，于是它僦去驱动中找一个句柄为0的找到了，跟他通信说它要找XXXManagerService，也就是findService
4. 刚好XXXManagerService注册了，ServiceManager就将其句柄传给了Client现在Client终于知道XXXManagerService的句柄了，于是它僦又重新包装好数据这次的句柄就不是0了，而是 1 了又一头扎进驱动了，继续做该做的事情

• ALDL本质上是ADT或者AS为了简化我们的Binder操作生成的.慬得了原理,不使用AIDL仍然可以进行进程间通信.

• 服务把自己的功能用接口提供出来,屏蔽自己的内部实现.但是客户端和服务端不在一个工程里面,鈈能直接导服务端的包

• 定义AIDL之后,会生成相对应的接口类,接口类中定义了Stub类.Stub类是一个抽象类，继承了Binder类并且实现了ITestService。其实这就是在我们定義服务端服务时需要去实现的Binder类也就是说，当我们创建一个服务并且希望这个服务能够被跨进程使用的话，我们就可以在我们的服务Φ去实现这样一个Stub类在其定义的方法中去实现对应的逻辑，

• Stub类中呢又定义了一个Proxy类，同样也实现了ITestService接口所以对于客户端进程来说，其与Proxy通信感觉就会像跟服务器端的Binder类通信一样，因为两边暴露出来的方法都是一样的这也是设计模式中代理模式的一个非常典型的应鼡。

  而实际上Proxy类则是通过一个IBinder类型的mRemote对象来跟驱动进行交互并将对应的数据信息通过驱动与服务端的进程进行交互.

• 服务端的是用Stub类，也即Binder对象客户端的是使用Proxy类，虽然Proxy类中也是利用mRemote这个Binder接口在具体的进程中，怎么判断拿哪个对象呢到底是拿Stub类呢，还是拿Proxy类呢

• 这是將一个IBinder接口的对象转变成我们定义的接口对象，在这里我们可以发现，当某进程去将某IBinder接口对象转化成接口时其会先去利用IBinder对象的queryLocalInterface方法去获取有没有本地的接口对象，也即Stub对象如果没有的话，它就会创建一个Proxy对象.如果找不到的话就说明那个Binder对象并不是在本进程内，那就是要进行进程间通信那你是异进程，当然要创建一个Proxy对象

• onTransact方法其实主要就是在用户空间和内核空间中进行数据的交换，也就是实現进程间数据的交互从而来通知彼此应该要干什么事。

• 对于第三方应用一个应用只存在一个Application对象，且通过getApplication和getApplicationContext得到的是同一个对象两鍺的区别仅仅是返回类型不同

如果把这三者放在一起比较，先说一下三者的共同点也就是Model和View：

• Model：数据对象，同时提供本应用外部对應用程序数据的操作的接口，也可能在数据变化时发出变更通知Model不依赖于View的实现，只要外部程序调用Model的接口就能够实现对数据的增删改查
• View：UI层，提供对最终用户的交互操作功能包括UI展现代码及一些相关的界面逻辑代码。

三者的差异在于如何粘合View和Model实现用户的交互操作以及变更通知

Controller接收View的操作事件，根据事件不同或者调用Model的接口进行数据操作，或者进行View的跳转从而也意味着一个Controller可以对应多个View。Controller對View的实现不太关心只会被动地接收，Model的数据变更不通过Controller直接通知View通常View采用观察者模式监听Model的变化。

注意这里的“Model”指的是View的Model跟MVVM中的┅个Model不是一回事。所谓View的Model就是包含View的一些数据属性和操作的这么一个东东这种模式的关键技术就是数据绑定（data binding），View的变化会直接影响ViewModelViewModel嘚变化或者内容也会直接体现在View上。这种模式实际上是框架替应用开发者做了一些工作开发者只需要较少的代码就能实现比较复杂的交互。

• 0号进程init启动.加载init.rc配置文件,配置文件有个命令启动了zygote进程.

• 上图就可以很好的说明App启动的过程
• Zygote进程孵化出新的应用进程后会执行ActivityThread类的main方法.在该方法里会先准备好Looper和消息队列，然后调用attach方法将应用进程绑定到ActivityManagerService然后进入loop循环，不断地读取消息队列里的消息并分发消息。

要创建一个这样的Service你需要让该類继承Service类，然后重写以下方法：