Ⅰ android图形系统（八）-app与SurfaceFlinger共享UI元数据过程
Android应用程序与SurfaceFlinger服务是运行在不同的进程中的，因此，它们采用Binder进程间通信机制来进行通信。
但是我们知道一个Android应用程序可能会有很多个窗口，而每一个窗口都有自己的UI元数据，因此，Android应用程序需要传递给SurfaceFlinger服务的UI元数据是相当可观的。在这种情况下，通过Binder来在Android应用程序与SurfaceFlinger服务之间传递UI元数据是不合适的，因此这里选择了Android系统的匿名共享内存的方案。在每一个Android应用程序与SurfaceFlinger服务之间的连接上加上一块用来传递UI元数据的匿名共享内存。而这块区域被包装为SharedClient。
在每一个SharedClient里面，有至多31个SharedBufferStack,那什么又是SharedBufferStack？
SharedBufferStack就是共享缓冲区堆栈，每一个SharedBufferStack与一个Surface一一对应，每一个Surface又对应一个窗口，那就是一个应用程序内部最多可创建31个窗口。SharedBufferStack 内部包含N个缓冲buffer, 开篇介绍的双缓冲(front buffer , back buffer) ,三缓冲（front buffer , back buffer, tripple buffer），有了它SurfaceFlinger服务就可以使用N个缓冲区技术来绘制UI了。
下面我们再来了解下SharedBufferStack的结构：
SharedBufferStack中分为空闲buffer和已使用的buffer。其中SharedBufferStack中的每一个已经使用了的缓冲区都对应有一个GraphicBuffer，用来描述真正的UI数据。
客户端一次申请GraphicBuffer且将UI元数据写入GraphicBuffer的流程：
当Android应用程序需要更新一个Surface的时候，它就会找到与它所对应的SharedBufferStack，并且从它的空闲缓冲区列表的尾部取出一个空闲的Buffer。我们假设这个取出来的空闲Buffer的编号为index。接下来Android应用程序就请求SurfaceFlinger服务为这个编号为index的Buffer分配一个图形缓冲区GraphicBuffer。SurfaceFlinger服务分配好图形缓冲区GraphicBuffer之后，会将它的编号设置为index，然后再将这个图形缓冲区GraphicBuffer返回给Android应用程序访问。Android应用程序得到了SurfaceFlinger服务返回的图形缓冲区GraphicBuffer之后，就在里面写入UI数据。写完之后，就将与它所对应的缓冲区，即编号为index的Buffer，插入到对应的SharedBufferStack的已经使用了的缓冲区列表的头部去。这一步完成了之后，Android应用程序就通知SurfaceFlinger服务去绘制那些保存在已经使用了的缓冲区所描述的图形缓冲区GraphicBuffer了。
那么我们也知道一个绘图表面，在SurfaceFlinger服务和Android应用程序中分别对应Layer对象和Surface对象，其中这两个对象在内部分别使用一个SharedBufferServer对象和一个SharedBufferClient对象来操作这个绘图表面的UI元数据缓冲堆栈。操作过程如下：
在Android应用程序这一侧，当它需要渲染一个Surface时，它就会首先找到对应的SharedBufferClient对象，然后再调用它的成员函数dequeue来请求分配一个UI元数据缓冲区。有了这个UI元数据缓冲区之后，Android应用程序再调用这个SharedBufferClient对象的成员函数setDirtyRegion、setCrop和setTransform来设置对应的Surface的裁剪区域、纹理坐标以及旋转方向。此外，Android应用程序还会请求SurfaceFlinger服务为这个Surface分配一个图形缓冲区，以便可以往这个图形缓冲区写入实际的UI数据。最后，Android应用程序就可以调用这个SharedBufferClient对象的成员函数queue把前面已经准备好了的UI元数据缓冲区加入到它所描述的一个UI元数据缓冲区堆栈的待渲染队列中，以便SurfaceFlinger服务可以在合适的时候对它进行渲染。当SurfaceFlinger服务需要渲染一个Surface的时候，它就会找到对应的一个SharedBufferServer对象，然后调用它的成员函数getQueueCount来检查它所描述的一个UI元数据缓冲区堆栈的待渲染队列的大小。如果这个大小大于0，那么SurfaceFlinger服务就会继续调用它的成员函数retireAndLock来取出队列中的第一个UI元数据缓冲区，以及调用它的成员函数getDirtyRegion、getCrop和getTransform来获得要渲染的Surface的裁剪区域、纹理坐标和旋转方向。最后，SurfaceFlinger服务就可以结合这些信息来将保存这个Surface的图形缓冲区中的UI数据渲染在显示屏中。
另外想深入了解BufferQueue的生产者消费者模型，详细可以阅读下如下这篇博文，感觉还不错： https://blog.csdn.net/stn_lcd/article/details/73801313
参考：
https://blog.csdn.net/Luoshengyang/article/details/7867340
Ⅱ Android消息队列浅析
当面试官问到你消息对列的时候，恭喜你，已经跨过初级，在试探你的中级水平了。
Android的消息循环是参考Windows的消息循环机制来实现的。
消息队列4件套 Message、MessageQueue、Looper、Handler
1、Message 是消息对列的消息实体类，因为消息队列中会存放最多10个Message对象。常用属性 what，是消息体的Tag，用来区分是那个一消息体。
2、 MessageQueue 先进先出”的原则存放消息，将Message对象以链表的方式串联起来。
3、Looper 是MessageQueue的管理者，主线程中是一对一的关系。子线程需要用到消息对列的话就需要经典二人组 。先调用 Looper.prepare()方法，然后再调用Looper.loop()；
4、Handler 是封装和处理Message对象的。
通过源码可知消息走向如下
handler.sendMessage()-->handler.sendMessageDelayed()-->handler.sendMessageAtTime()-->msg.target = this;queue.enqueueMessage==>把msg添加到消息队列中
Ⅲ Android中的线程池
线程池的好处
1、重用线程池中的线程，避免线程的创建与销毁带来的性能开销
2、能有效控制线程池的最大并发数，避免大量线程因抢占资源而导致的阻塞
3、能对线程进行简单的管理，提供定时或者指定间隔时间、循环执行等操作
线程池的概率来自于java的Executor接口，实现类是ThreadPoolExecutor, 它提供一系列的参数来配置线程池，以此构建不同的线程池。Android的线程池分4类，都是通过Executors所提供的工厂方法来得到。
ThreadPoolExecutor有四个构造函数，下面这个是最常用的
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnnable> workQueue, ThreadFactory threadFactory)
corePoolSize
线程池中的核心线程数，默认情况下核心线程会在线程池中一直存活，即使他们处于闲置状态。如果设置ThreadPoolExecutor 中的allowCoreThreadTimeOut = true, 核心线程在等待新任务到来时有超时机制，时间超过keepAliveTime所指定的时间后，核心线程会终止。
maximumPoolSize
最大线程数
keepAliveTime
非核心线程闲置的超时时间，超过这个时间，非核心线程会被回收。核心线程则要看allowCoreThreadTimeOut属性的值。
unit
时间单位
workQueue
线程池中的工作队列
threadFactory
线程工厂，为线程池提供创建新线程的功能。
举个例子，我们常用的okhttp内部也是使用了线程池，它的ThreadPoolExecutor主要是定义在Dispatcher类里面。 使用的是CachedThreadPool。
executorService = ThreadPoolExecutor(0, Int.MAX_VALUE, 60, TimeUnit.SECONDS, SynchronousQueue(), ThreadFactory("okhttp Dispatcher", false))
1、FixedThreadPool
通过Executors的newFixedThreadPool（）创建，这是一个线程数量固定的线程池，里面所有的线程都是核心线程。
public static ExecutorService newFixedThreadPool(int nThreads){
return new ThreadPoolExecutor(nThreads, nThreads, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>())
}
2、CachedThreadPool
通过Executors的newCacheThreadPool（）创建，这是一个线程数量不定的线程池，里面所有的线程都是非核心线程。最大线程数是无限大，当线程池中的线程都处于活动状态时，新的task会创建新的线程来处理，否则就使用空闲的线程处理，所有的线程都是60s的超时时间，超时后会自动回收。
public static ExecutorService newFixedThreadPool(){
return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>())
}
3、ScheledThreadPool
通过Executors的newScheledThreadPool（）创建, 核心线程固定，非核心线程无限大，当非核心线程空闲时，会立即被回收。适合做定时任务或者固定周期的重复任务。
public static ExecutorService newScheledThreadPool(int corePoolSize){
return new ThreadPoolExecutor(corePoolSize, Integer.MAX_VALUE, 0, TimeUnit.SECONDS, new DelayedWorkQueue())
}
4、SingleThreadExcecutor
通过Executors的newSingleThreadPool（）创建，内部只有一个核心线程。
public static ExecutorService newFixedThreadPool(){
return new ThreadPoolExecutor(1, 1, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>())
}
课外知识：LinkedBlockingQueue
LinkedBlockingQueue是由链表组成的阻塞队列，内部head 指向队列第一个元素，last指向最后一个元素。入队和出队都会加锁阻塞，都是使用了不同的锁。
DelayedWorkQueue
延时队列，队内元素必须是Delayed的实现类。对内元素会按照Delayed时间进行排序，对内元素只有在delayed时间过期了才能出队。
入队的时候不阻塞队列，出队的时候，如果队列为空或者队列里所有元素都等待时间都没有到期，则该线程进入阻塞状态。
Ⅳ Android 线程池的封装
GlobalThreadPools.java：
调用：
线程池
线程池概念来源于Java中的Executor,它是一个接口，真正的实现为ThreadPoolExecutor。ThreadPoolExecutor提供了一系列参数来配置线程池。
优点
1：重用线程池中的线程，线程在执行完任务后不会立刻销毁，而会等待另外的任务，这样就不会频繁地创建、销毁线程和调用GC。。
2：有效控制线程池的最大并发数，避免大量线程抢占资源出现的问题。
3：对多个线程进行统一地管理，可提供定时执行及指定间隔循环执行的功能。
ThreadPoolExecutor 有多个重载方法，但最终都调用了这个构造方法
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
参数：
corePoolSize：线程池中核心线程的数量；为了内存优化，在线程池维护了几个重要的线程，不达到一定条件不开辟其余线程
maximumPoolSize ：线程池中最大线程数量：这个数量是包括核心线程的，当线程池中的正在执行的线程池达到了这个数字，再提交线程如果你不做特殊处理将会抛出异常
keepAliveTime：非核心线程的超时时长；当线程池中的非核心线程闲置时间超过这个值代表的时间后，将会被回收；同时如果调用ThreadPoolExecutor.allowCoreThreadTimeOut(true)，那么核心线程也会符合这个设置
unit：keepAliveTime值的单位，可以是时分秒等
workQueue：存放待执行的线程；你通过execute方法提交线程，但是这些线程还没达到执行条件，那么就会保存在这个队列里
threadFactory：创建线程池的工厂；在这个工厂里，我们可以指定线程的一些信息
handler：线程提交拒绝策略；通常是线程池中的正在执行的线程数量已经达到了最大线程数或线程池关闭，如果不传，默认是抛出一个RejectedExecutionException，所以最好传下
推荐使用 Executors 的工厂方法来创建线程池，通过直接或间接的配置 ThreadPoolExecutor 的参数来构建线程池，常用的线程池有如下 4 种，newFixedThreadPool ，newCachedThreadPool，
newScheledThreadPool 和 newSingleThreadExecutor。
ThreadPoolExecutor 执行任务时大致遵循如下流程：
1.如果线程池中的线程数未达到核心线程数，则会立马启用一个核心线程去执行。
2.如果线程池中的线程数已经达到核心线程数，且任务队列workQueue未满，则将新线程放入workQueue中等待执行。
3.如果线程池中的线程数已经达到核心线程数但未超过线程池规定最大值，且workQueue已满，则开启一个非核心线程来执行任务。
4.如果线程池中的线程数已经超过线程池规定最大值，则拒绝执行该任务，采取饱和策略，并抛出RejectedExecutionException异常。
线程池大小：（N为CPU数量）
如果是CPU密集型应用，则线程池大小设置为N+1
如果是IO密集型应用，则线程池大小设置为2N+1
I/O密集型
指的是系统的CPU效能相对硬盘/内存的效能要好，大部分的状况是 CPU 在等 I/O (硬盘/内存) 的读/写， CPU Loading 不高。
CPU密集型
指的是系统的 硬盘/内存 效能 相对 CPU 的效能 要好，大部分的状况是 CPU Loading 100%，CPU 要读/写 I/O (硬盘/内存)，I/O在很短的时间就可以完成，而 CPU 还有许多运算要处理，CPU Loading 很高。
获取CPU数量的方法为：
Runtime.getRuntime().availableProcessors();
摘自：
https://blog.csdn.net/qq_30993595/article/details/84324681
Ⅳ android怎么实现任务队列
主要就是有一个线程队列，维护这些任务，这里没有用到Queue而是用List是考虑到显示的问题。
Ⅵ Android中的Activity详解--启动模式与任务栈
目录
activity的简单介绍就不写了，作为最常用的四大组件之一，肯定都很熟悉其基本用法了。
首先，是都很熟悉的一张图，即官方介绍的Activity生命周期图.
情景：打开某个应用的的FirstActivity调用方法如下：
由于之前已经很熟悉了，这里就简单贴一些图。
按下返回键：
重新打开并按下home键：
再重新打开：
在其中打开一个DialogActivity(SecondActivity)
按下返回：
修改SecondAcitvity为普通Activity,依旧是上述操作:
这里强调一下 onSaveInstanceState(Bundle outState) 方法的调用时机：
当Activity有可能被系统杀掉时调用，注意，一定是被系统杀掉，自己调用finish是不行的。
测试如下：FirstActivity启动SecondActivity：
一个App会包含很多个Activity，多个Activity之间通过intent进行跳转，那么原始的Activity就是使用栈这个数据结构来保存的。
Task
A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the back stack ), in the order in which each activity is opened.
即若干个Activity的集合的栈表示一个Task。
当App启动时如果不存在当前App的任务栈就会自动创建一个，默认情况下一个App中的所有Activity都是放在一个Task中的，但是如果指定了特殊的启动模式，那么就会出现同一个App的Activity出现在不同的任务栈中的情况，即会有任务栈中包含来自于不同App的Activity。
标准模式，在不指定启动模式的情况下都是以此种方式启动的。每次启动都会创建一个新的Activity实例，覆盖在原有的Activity上，原有的Activity入栈。
测试如下：在FirstActivity中启动FirstActivity:
当只有一个FirstActivity时堆栈情况：
此种模式下，Activity在启动时会进行判断，如果当前的App的栈顶的Activity即正在活动的Activity就是将要启动的Activity，那么就不会创建新的实例，直接使用栈顶的实例。
测试，设置FirstActivity为此启动模式，多次点击FirstActivity中的启动FirstActivity的按钮查看堆栈情况：
（其实点击按钮没有启动新Activity的动画就可以看出并没有启动新Activity）
大意就是：
对于使用singleTop启动或Intent.FLAG_ACTIVITY_SINGLE_TOP启动的Activity，当该Activity被重复启动（注意一定是re-launched，第一次启动时不会调用）时就会调用此方法。
且调用此方法之前会先暂停Activity也就是先调用onPause方法。
而且，即使是在新的调用产生后此方法被调用，但是通过getIntent方法获取到的依旧是以前的Intent，可以通过setIntent方法设置新的Intent。
方法参数就是新传递的Intent.
1.如果是同一个App中启动某个设置了此模式的Activity的话，如果栈中已经存在该Activity的实例，那么就会将该Activity上面的Activity清空，并将此实例放在栈顶。
测试：SecondActivity启动模式设为singleTask，启动三个Activity：
这个模式就很好记，以此模式启动的Activity会存放在一个单独的任务栈中，且只会有一个实例。
测试：SecondActivity启动模式设为singleInstance
结果：
显然，启动了两次ThirdActivity任务栈中就有两个实例，而SecondActivity在另外一个任务栈中，且只有一个。
在使用Intent启动一个Activity时可以设置启动该Activity的启动模式：
这个属性有很多，大致列出几个：
每个启动的Activity都在一个新的任务栈中
singleTop
singleTask
用此种方式启动的Activity，在它启动了其他Activity后，会自动finish.
官方文档介绍如下：
这样看来的话，通俗易懂的讲，就是给每一个任务栈起个名，给每个Activity也起个名，在Activity以singleTask模式启动时，就检查有没有跟此Activity的名相同的任务栈，有的话就将其加入其中。没有的话就按照这个Activity的名创建一个任务栈。
测试：在App1中设置SecondActivity的taskAffinity为“gsq.test”，App2中的ActivityX的taskAffinity也设为“gsq.test”
任务栈信息如下：
结果很显然了。
测试：在上述基础上，在ActivityX中进行跳转到ActivityY,ActivityY不指定启动模式和taskAffinity。结果如下：
这样就没问题了，ActivityY在一个新的任务栈中，名称为包名。
这时从ActivityY跳转到SecondActivity，那应该是gsq.test任务栈只有SecondActivity，ActivityX已经没有了。因为其启动模式是singleTask，在启动它时发现已经有一个实例存在，就把它所在的任务栈上面的Activity都清空了并将其置于栈顶。
还有一点需要提一下，在上面，FirstActivity是App1的lunch Activity，但是由于SecondActivity并没有指定MAIN和LAUNCHER过滤器，故在FirstActivity跳转到SecondActivity时，按下home键，再点开App1，回到的是FirstActivity。
大致就先写这么多吧，好像有点长，废话有点多，估计也有错别字，不要太在意~~~
Ⅶ Android 守护进程的实现方式
在我们进行应用开发时，会遇到上级的各种需求，其中有一条 刚需： 后台保活 ，更有甚者：
我要我们的应用永远活在用户的手机后台不被杀死 —— 这都 TM 的扯淡
除了系统级别的应用能持续运行，所有三方程序都有被杀死的那一天！当然 QQ/微信/陌陌 等会好一些，因为他们已经深入设备的 心 ；
我们能做的只是通过各种手段尽量让我们的程序在后台运行的时间长一些，或者在被干掉的时候，能够重新站起来，而且这个也不是每次都有效的，也是不能在所有的设备的上都有效的；要做到后台进程保活，我们需要做到两方便：
要实现实现上边所说，通过下边几点来实现，首先我们需要了解下进程的优先级划分：
Process Importance 记录在 ActivityManager.java 类中:
了解进程优先级之后，我们还需要知道一个进程回收机制的东西；这里参考 AngelDevil 在博客园上的一篇文章:
Android 的 Low Memory Killer 基于 Linux 的 OOM 机制，在 Linux 中，内存是以页面为单位分配的，当申请页面分配时如果内存不足会通过以下流程选择bad进程来杀掉从而释放内存：
在 Low Memory Killer 中通过进程的 oom_adj 与占用内存的大小决定要杀死的进程， oom_adj 越小越不容易被杀死；
Low Memory Killer Driver 在用户空间指定了一组内存临界值及与之一一对应的一组 oom_adj 值，当系统剩余内存位于内存临界值中的一个范围内时，如果一个进程的 oom_adj 值大于或等于这个临界值对应的 oom_adj 值就会被杀掉。
下边是表示 Process State (即老版本里的 OOM_ADJ )数值对照表，数值越大，重要性越低，在新版SDK中已经在 android 层去除了小于0的进程状态
Process State （即老版本的 OOM_ADJ ）与 Process Importance 对应关系，这个方法也是在 ActivityManager.java 类中，有了这个关系，就知道可以知道我们的应用处于哪个级别，对于我们后边优化有个很好地参考
一般情况下，设备端进程被干掉有一下几种情况
由以上分析，我们可以可以总结出，如果想提高我们应用后台运行时间，就需要提高当前应用进程优先级，来减少被杀死的概率
分析了那么多，现在对Android自身后台进程管理，以及进程的回收也有了一个大致的了解，后边我们要做的就是想尽一切办法去提高应用进程优先级，降低进程被杀的概率；或者是在被杀死后能够重新启动后台守护进程
第一种方式就是利用系统漏洞，使用 startForeground() 将当前进程伪装成前台进程，将进程优先级提高到最高(这里所说的最高是服务所能达到的最高，即1);
这种方式在 7.x 之前都是很好用的，QQ、微信、IReader、Keep 等好多应用都是用的这种方式实现；因为在7.x 以后的设备上，这种伪装前台进程的方式也会显示出来通知栏提醒，这个是取消不掉的，虽然 Google 现在还没有对这种方式加以限制，不过这个已经能够被用户感知到了，这种方式估计也用不了多久了
下边看下实现方式，这边这个 VMDaemonService 就是一个守护进程服务，其中在服务的 onStartCommand() 方法中调用 startForeground() 将服务进程设置为前台进程，当运行在 API18 以下的设备是可以直接设置，API18 以上需要实现一个内部的 Service ，这个内部类实现和外部类同样的操作，然后结束自己；当这个服务启动后就会创建一个定时器去发送广播，当我们的核心服务被干掉后，就由另外的广播接收器去接收我们守护进程发出的广播，然后唤醒我们的核心服务；
当我们启动这个守护进程的时候，就可以使用以下 adb 命令查看当前程序的进程情况（需要 adb shell 进去设备），
为了等下区分进程优先级，我启动了一个普通的后台进程，两外两个一个是我们启动的守护进程，一个是当前程序的核心进程，可以看到除了后台进程外，另外两个进程都带有 isForeground=true 的属性：
然后我们可以用下边的命令查看 ProcessID
有了 ProcessID 之后，我们可以根据这个 ProcessID 获取到当前进程的优先级状态 Process State ，对应 Linux 层的 oom_adj
可以看到当前核心进程的级别为 0 ，因为这个表示当前程序运行在前台 UI 界面，守护进程级别为 1 ，因为我们利用漏洞设置成了前台进程，虽然不可见，但是他的级别也是比较高的，仅次于前台 UI 进程，然后普通后台进程级别为 4 ；当我们退到后台时，可以看到核心进程的级别变为 1 了，这就是因为我们利用 startForeground() 将进程设置成前台进程的原因，这样就降低了进程被系统回收的概率了；
可以看到这种方式确实能够提高进程优先级，但是在一些国产的设备上还是会被杀死的，比我我测试的时候小米点击清空最近运行的应用进程就别干掉了；当把应用加入到设备白名单里就不会被杀死了，微信就是这样，人家直接装上之后就已经在白名单里了，我们要做的就是在用户使用中引导他们将我们的程序设置进白名单，将守护进程和白名单结合起来，这样才能保证我们的应用持续或者
Android系统在5.x以上版本提供了一个 JobSchele 接口，系统会根据自己实现定时去调用改接口传递的进程去实现一些操作，而且这个接口在被强制停止后依然能够正常的启动；不过在一些国产设备上可能无效，比如小米；
下边是 JobServcie 的实现：
我们要做的就是在需要的时候调用 JobSchele 的 schele 来启动任务；剩下的就不需要关心了， JobSchele 会帮我们做好，下边就是我这边实现的启动任务的方法：
在实现 Service 类时，将 onStartCommand() 返回值设置为 START_STICKY ，利用系统机制在 Service 挂掉后自动拉活；不过这种方式只适合比较原生一些的系统，像小米，华为等这些定制化比较高的第三方厂商，他们都已经把这些给限制掉了；
这种方式在以下两种情况无效：
事事没有绝对，万物总有一些漏洞，就算上边的那些方式不可用了，后边肯定还会出现其他的方式；我们不能保证我们的应用不死，但我们可以提高存活率；
其实最好的方式还是把程序做好，让程序本身深入人心，别人喜欢你了，就算你被干掉了，他们也会主动的把你拉起来，然后把你加入他们的白名单，然后我们的目的就实现了不是 😁 ~