进程优先级&＃xff08;Process Priority&＃xff09;
线程寄宿在进程当中&＃xff0c;线程的生命周期直接被进程所影响&＃xff0c;而进程的存活又和其优先级直接相关。在处理进程优先级的时候&＃xff0c;大部分人靠直觉都能知道前台进程&＃xff08;Foreground Process&＃xff09;优先级要高于后台进程&＃xff08;Background Process&＃xff09;。但这种粗糙的划分无法满足操作系统高精度调度的需求。无论Android还是iOS&＃xff0c;系统对于Foreground&＃xff0c;Background进程有进一步的细化。
Foreground Process
Foreground一般意味着用户双眼可见&＃xff0c;可见却不一定是active。在Android的世界里&＃xff0c;一个Activity处于前台之时&＃xff0c;如果能采集用户的input事件&＃xff0c;就可以判定为active&＃xff0c;如果中途弹出一个Dialog&＃xff0c;Dialog变成新的active实体&＃xff0c;直接面对用户的操作。被部分遮挡的activity尽管依然可见&＃xff0c;但状态却变为inactive。不能正确的区分visible和active是很多初级程序员会犯的错误。
Background Process
后台进程同样有更细的划分。所谓的Background可以理解为不可见&＃xff08;invisible&＃xff09;。对于不可见的任务&＃xff0c;Android也有重要性的区分。重要的后台任务定义为Service&＃xff0c;如果一个进程包含Service&＃xff08;称为Service Process&＃xff09;&＃xff0c;那么在“重要性”上就会被系统区别对待&＃xff0c;其优先级自然会高于不包含Service的进程&＃xff08;称为Background Process&＃xff09;&＃xff0c;最后还剩一类空进程&＃xff08;Empty Process&＃xff09;。Empty Process初看有些费解&＃xff0c;一个Process如果什么都不做&＃xff0c;还有什么存在的必要。其实Empty Process并不Empty&＃xff0c;还存在不少的内存占用。
在iOS的世界里&＃xff0c;Memory被分为Clean Memory和Dirty Memory&＃xff0c;Clean Memory是App启动被加载到内存之后原始占用的那一部分内存&＃xff0c;一般包括初始的stack, heap, text, data等segment&＃xff0c;Dirty Memory是由于用户操作所改变的那部分内存&＃xff0c;也就是App的状态值。系统在出现Low Memory Warning的时候会首先清掉Dirty Memory&＃xff0c;对于用户来说&＃xff0c;操作的进度就全部丢失了&＃xff0c;即使再次点击App图标&＃xff0c;也是一切从头开始。但由于Clean Memory没有被清除&＃xff0c;避免了从磁盘重新读取app数据的io损耗&＃xff0c;启动会变快。这也是为什么很多人会感觉手机重启后&＃xff0c;app打开的速度都比较慢。
同理Android世界当中的Empty Process还保存有App相关的Clean Memory&＃xff0c;这部分Memory对于提升App的启动速度大有帮助。显而易见Empty Process的优先级是最低的。
综上所述&＃xff0c;我们可以把Android世界的Process按优先级分为如下几类&＃xff1a;
进程的优先级从高到低依次分为五类&＃xff0c;越往下&＃xff0c;在内存紧张的时候越有可能被系统杀掉。简而言之&＃xff0c;越是容易被用户感知到的进程&＃xff0c;其优先级必定更高。
线程调度&＃xff08;Thread Scheduling&＃xff09;
Android系统基于精简过后的linux内核&＃xff0c;其线程的调度受时间片轮转和优先级控制等诸多因素影响。不少初学者会认为某个线程分配到的time slice多少是按照其优先级与其它线程优先级对比所决定的&＃xff0c;这并不完全正确。
Linux系统的调度器在分配time slice的时候&＃xff0c;采用的CFS&＃xff08;completely fair scheduler&＃xff09;策略。这种策略不但会参考单个线程的优先级&＃xff0c;还会追踪每个线程已经获取到的time slice数量&＃xff0c;如果高优先级的线程已经执行了很长时间&＃xff0c;但低优先级的线程一直在等待&＃xff0c;后续系统会保证低优先级的线程也能获取更多的CPU时间。显然使用这种调度策略的话&＃xff0c;优先级高的线程并不一定能在争取time slice上有绝对的优势&＃xff0c;所以Android系统在线程调度上使用了cgroups的概念&＃xff0c;cgroups能更好的凸显某些线程的重要性&＃xff0c;使得优先级更高的线程明确的获取到更多的time slice。
Android将线程分为多个group&＃xff0c;其中两类group尤其重要。一类是default group&＃xff0c;UI线程属于这一类。另一类是background group&＃xff0c;工作线程应该归属到这一类。background group当中所有的线程加起来总共也只能分配到5&＃xff5e;10%的time slice&＃xff0c;剩下的全部分配给default group&＃xff0c;这样设计显然能保证UI线程绘制UI的流畅性。
有不少人吐槽Android系统之所以不如iOS流畅&＃xff0c;是因为UI线程的优先级和普通工作线程一致导致的。这其实是个误会&＃xff0c;Android的设计者实际上提供了background group的概念来降低工作线程的CPU资源消耗&＃xff0c;只不过与iOS不同的是&＃xff0c;Android开发者需要显式的将工作线程归于background group。
| 1 2 3 4 5 6 | new Thread(new Runnable() { &＃64;Override public void run() { Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); } }).start(); |
所以在我们决定新启一个线程执行任务的时候&＃xff0c;首先要问自己这个任务在完成时间上是否重要到要和UI线程争夺CPU资源。如果不是&＃xff0c;降低线程优先级将其归于background group&＃xff0c;如果是&＃xff0c;则需要进一步的profile看这个线程是否造成UI线程的卡顿。
虽说Android系统在任务调度上是以线程为基础单位&＃xff0c;设置单个thread的优先级也可以改变其所属的control groups&＃xff0c;从而影响CPU time slice的分配。但进程的属性变化也会影响到线程的调度&＃xff0c;当一个App进入后台的时候&＃xff0c;该App所属的整个进程都将进入background group&＃xff0c;以确保处于foreground&＃xff0c;用户可见的新进程能获取到尽可能多的CPU资源。用adb可以查看不同进程的当前调度策略。
| 1 | $ adb shell ps -P |
当你的App重新被用户切换到前台的时候&＃xff0c;进程当中所属的线程又会回归的原来的group。在这些用户频繁切换的过程当中&＃xff0c;thread的优先级并不会发生变化&＃xff0c;但系统在time slice的分配上却在不停的调整。
是否真的需要新线程&＃xff1f;
开线程并不是提升App性能&＃xff0c;解决UI卡顿的万金油。每一个新启的线程会消耗至少64KB的内存&＃xff0c;系统在不同的线程之间switch context也会带来额外的开销。如果随意开启新线程&＃xff0c;随着业务的膨胀&＃xff0c;很容易在App运行的某个时间点发现几十个线程同时在运行。后果是原本想解决UI流畅性&＃xff0c;却反而导致了偶现的不可控的卡顿。
移动端App新启线程一般都是为了保证UI的流畅性&＃xff0c;增加App用户操作的响应度。但是否需要将任务放入工作线程需要先了解任务的瓶颈在哪&＃xff0c;是i/o&＃xff0c;gpu还是cpu&＃xff1f;UI出现卡顿并不一定是UI线程出现了费时的计算&＃xff0c;有可能是其它原因&＃xff0c;比如layout层级太深。
尽量重用已有的工作线程&＃xff08;使用线程池&＃xff09;可以避免出现大量同时活跃的线程&＃xff0c;比如对HTTP请求设置最大并发数。或者将任务放入某个串行的队列&＃xff08;HandlerThread&＃xff09;按顺序执行&＃xff0c;工作线程任务队列适合处理大量耗时较短的任务&＃xff0c;避免出现单个任务阻塞整个队列的情况。
用什么姿势开线程&＃xff1f;
new Thread()
这是Android系统里开线程最简单的方式&＃xff0c;也只能应用于最简单的场景&＃xff0c;简单的好处却伴随不少的隐患。
| 1 2 3 4 5 6 | new Thread(new Runnable() { &＃64;Override public void run() { } }).start(); |
这种方式仅仅是起动了一个新的线程&＃xff0c;没有任务的概念&＃xff0c;不能做状态的管理。start之后&＃xff0c;run当中的代码就一定会执行到底&＃xff0c;无法中途取消。
Runnable作为匿名内部类还持有了外部类的引用&＃xff0c;在线程退出之前&＃xff0c;该引用会一直存在&＃xff0c;阻碍外部类对象被GC回收&＃xff0c;在一段时间内造成内存泄漏。
没有线程切换的接口&＃xff0c;要传递处理结果到UI线程的话&＃xff0c;需要写额外的线程切换代码。
如果从UI线程启动&＃xff0c;则该线程优先级默认为Default&＃xff0c;归于default cgroup&＃xff0c;会平等的和UI线程争夺CPU资源。这一点尤其需要注意&＃xff0c;在对UI性能要求高的场景下要记得
| 1 | Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); |
虽说处于background group的线程总共只能争取到5&＃xff5e;10%的CPU资源&＃xff0c;但这对绝大部分的后台任务处理都绰绰有余了&＃xff0c;1ms和10ms对用户来说&＃xff0c;都是快到无法感知&＃xff0c;所以我们一般都偏向于在background group当中执行工作线程任务。
和使用Thread()不同的是&＃xff0c;多了几处API回调来严格规范工作线程与UI线程之间的交互。我们大部分的业务场景几乎都符合这种规范&＃xff0c;比如去磁盘读取图片&＃xff0c;缩放处理需要在工作线程执行&＃xff0c;最后绘制到ImageView控件需要切换到UI线程。
AsyncTask的几处回调都给了我们机会去中断任务&＃xff0c;在任务状态的管理上较之Thread()方式更为灵活。值得注意的是AsyncTask的cancel()方法并不会终止任务的执行&＃xff0c;开发者需要自己去检查cancel的状态值来决定是否中止任务。
AsyncTask也有隐式的持有外部类对象引用的问题&＃xff0c;需要特别注意防止出现意外的内存泄漏。
AsyncTask由于在不同的系统版本上串行与并行的执行行为不一致&＃xff0c;被不少开发者所诟病&＃xff0c;这确实是硬伤&＃xff0c;绝大部分的多线程场景都需要明确任务是串行还是并行。
线程优先级为background&＃xff0c;对UI线程的执行影响极小。
HandlerThread
在需要对多任务做更精细控制&＃xff0c;线程切换更频繁的场景之下&＃xff0c;Thread()和AsyncTask都会显得力不从心。HandlerThread却能胜任这些需求甚至更多。
HandlerThread将Handler&＃xff0c;Thread&＃xff0c;Looper&＃xff0c;MessageQueue几个概念相结合。Handler是线程对外的接口&＃xff0c;所有新的message或者runnable都通过handler post到工作线程。Looper在MessageQueue取到新的任务就切换到工作线程去执行。不同的post方法可以让我们对任务做精细的控制&＃xff0c;什么时候执行&＃xff0c;执行的顺序都可以控制。HandlerThread最大的优势在于引入MessageQueue概念&＃xff0c;可以进行多任务队列管理。
HandlerThread背后只有一个线程&＃xff0c;所以任务是串行执行的。串行相对于并行来说更安全&＃xff0c;各任务之间不会存在多线程安全问题。
HandlerThread所产生的线程会一直存活&＃xff0c;Looper会在该线程中持续的检查MessageQueue。这一点和Thread()&＃xff0c;AsyncTask都不同&＃xff0c;thread实例的重用可以避免线程相关的对象的频繁重建和销毁。
HandlerThread较之Thread()&＃xff0c;AsyncTask需要写更多的代码&＃xff0c;但在实用性&＃xff0c;灵活度&＃xff0c;安全性上都有更好的表现。
ThreadPoolExecutor
Thread(),AsyncTask适合处理单个任务的场景&＃xff0c;HandlerThread适合串行处理多任务的场景。当需要并行的处理多任务之时&＃xff0c;ThreadPoolExecutor是更好的选择。
IntentService
不得不说Android在API设计上粒度很细&＃xff0c;同一样工作可以通过各种不同的类来完成。IntentService又是另一种开工作线程的方式&＃xff0c;从名字就可以看出这个工作线程会带有service的属性。和AsyncTask不同&＃xff0c;没有和UI线程的交互&＃xff0c;也不像HandlerThread的工作线程会一直存活。IntentService背后其实也有一个HandlerThread来串行的处理Message Queue&＃xff0c;从IntentService的onCreate方法可以看出&＃xff1a;
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | &＃64;Override public void onCreate() { // TODO: It would be nice to have an option to hold a partial wakelock // during processing, and to have a static startService(Context, Intent) // method that would launch the service & hand off a wakelock. super.onCreate(); HandlerThread thread &＃61; new HandlerThread("IntentService[" &＃43; mName &＃43; "]"); thread.start(); mServiceLooper &＃61; thread.getLooper(); mServiceHandler &＃61; new ServiceHandler(mServiceLooper); } |
只不过在所有的Message处理完毕之后&＃xff0c;工作线程会自动结束。所以可以把IntentService看做是Service和HandlerThread的结合体&＃xff0c;适合需要在工作线程处理UI无关任务的场景。
结束语
Android开线程的方式虽然五花八门&＃xff0c;但归根到底最后还是映射到linux下的pthread&＃xff0c;业务的设计还是脱不了和线程相关的基础概念范畴&＃xff1a;线程的执行顺序&＃xff0c;调度策略&＃xff0c;生命周期&＃xff0c;串行还是并行&＃xff0c;同步还是异步等等。摸清楚各类API下线程的行为特点&＃xff0c;在设计具体业务的线程模型的时候自然轻车熟路了&＃xff0c;线程模型的设计要有整个app视角的广度&＃xff0c;切忌各业务模块各玩各的。
京公网安备 11010802041100号