Android消息机制(六) 总结

参考
Android线程的正确使用姿势
Android性能优化典范之多线程篇
Android多线程编程的总结
Android中8种异步处理与计算的方法

概要：Thread(),AsyncTask适合处理单个任务的场景，HandlerThread适合串行处理多任务的场景。当需要并行的处理多任务之时，ThreadPoolExecutor是更好的选择,尤其适合处理大量耗时较短的任务，避免出现单个任务阻塞整个队列的情况。IntentService看做是Service和HandlerThread的结合体，不需要与UI交互，适合需要在工作线程处理UI无关任务的场景。

一、线程调度（Thread Scheduling）

Android系统基于精简过后的linux内核，其线程的调度受时间片轮转和优先级控制等诸多因素影响。不少初学者会认为某个线程分配到的time slice多少是按照其优先级与其它线程优先级对比所决定的，这并不完全正确。

Linux系统的调度器在分配time slice的时候，采用的CFS（completely fair scheduler）策略。这种策略不但会参考单个线程的优先级，还会追踪每个线程已经获取到的time slice数量，如果高优先级的线程已经执行了很长时间，但低优先级的线程一直在等待，后续系统会保证低优先级的线程也能获取更多的CPU时间。显然使用这种调度策略的话，优先级高的线程并不一定能在争取time slice上有绝对的优势，所以Android系统在线程调度上使用了cgroups的概念，cgroups能更好的凸显某些线程的重要性，使得优先级更高的线程明确的获取到更多的time slice。

Android将线程分为多个group，其中两类group尤其重要。一类是default group，UI线程属于这一类。另一类是background group，工作线程应该归属到这一类。background group当中所有的线程加起来总共也只能分配到5～10%的time slice，剩下的全部分配给default group，这样设计显然能保证UI线程绘制UI的流畅性。

有不少人吐槽Android系统之所以不如iOS流畅，是因为UI线程的优先级和普通工作线程一致导致的。这其实是个误会，Android的设计者实际上提供了background group的概念来降低工作线程的CPU资源消耗，只不过与iOS不同的是，Android开发者需要显式的将工作线程归于background group。

new Thread(new Runnable() {
  @Override
  public void run() {
    Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
  }
}).start();

所以在我们决定新启一个线程执行任务的时候，首先要问自己这个任务在完成时间上是否重要到要和UI线程争夺CPU资源。如果不是，降低线程优先级将其归于background group，如果是，则需要进一步的profile看这个线程是否造成UI线程的卡顿。
在 Android 系统里面，我们可以通过 android.os.Process.setThreadPriority(int) 设置线程的优先级，参数范围从-20到19，数值越小优先级越高。Android 系统还为我们提供了以下的一些预设值，我们可以通过给不同的工作线程设置不同数值的优先级来达到更细粒度的控制。

Paste_Image.png

Android 系统里面的 AsyncTask 与 IntentService已经默认帮助我们设置线程的优先级，但是对于那些非官方提供的多线程工具类，我们需要特别留意根据需要自己手动来设置线程的优先级。

Paste_Image.png

二、用什么姿势开线程？

1.new Thread()
这是Android系统里开线程最简单的方式，也只能应用于最简单的场景，简单的好处却伴随不少的隐患。

new Thread(new Runnable() {
            @Override
            public void run() {

            }
        }).start();

• 这种方式仅仅是起动了一个新的线程，没有任务的概念，不能做状态的管理。start之后，run当中的代码就一定会执行到底，无法中途取消。
• Runnable作为匿名内部类还持有了外部类的引用，在线程退出之前，该引用会一直存在，阻碍外部类对象被GC回收，在一段时间内造成内存泄漏。
• 没有线程切换的接口，要传递处理结果到UI线程的话，需要写额外的线程切换代码。
• 如果从UI线程启动，则该线程优先级默认为Default，归于default cgroup，会平等的和UI线程争夺CPU资源。这一点尤其需要注意，在对UI性能要求高的场景下要记得
  Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
• 虽说处于background group的线程总共只能争取到5～10%的CPU资源，但这对绝大部分的后台任务处理都绰绰有余了，1ms和10ms对用户来说，都是快到无法感知，所以我们一般都偏向于在background group当中执行工作线程任务。

2.AsyncTask
一个典型的AsyncTask实现如下：

public class MyAsyncTask extends AsyncTask {

        @Override
        protected Object doInBackground(Object[] params) {
            return null;
        }

        @Override
        protected void onPreExecute() {
            super.onPreExecute();
        }

        @Override
        protected void onPostExecute(Object o) {
            super.onPostExecute(o);
        }
    }

和使用Thread()不同的是，多了几处API回调来严格规范工作线程与UI线程之间的交互。我们大部分的业务场景几乎都符合这种规范，比如去磁盘读取图片，缩放处理需要在工作线程执行，最后绘制到ImageView控件需要切换到UI线程。

• AsyncTask的几处回调都给了我们机会去中断任务，在任务状态的管理上较之Thread()方式更为灵活。值得注意的是AsyncTask的cancel()方法并不会终止任务的执行，开发者需要自己在doInBackground中去检查cancel的状态值来决定是否中止任务。
• AsyncTask也有隐式的持有外部类对象引用的问题，只要 Task 没有结束，引用关系就会一直存在，需要特别注意防止出现意外的内存泄漏。
• AsyncTask由于在不同的系统版本上串行与并行的执行行为不一致，被不少开发者所诟病，这确实是硬伤，绝大部分的多线程场景都需要明确任务是串行还是并行。具体来讲，在Android1.6前，AsyncTask是串行执行任务的，android1.6时采用线程池并行任务，但是从Androide3.0开始，为了避免并发错误，又采用一个线程串行执行任务。
• 线程优先级为background，对UI线程的执行影响极小。

3.HandlerThread
在需要对多任务做更精细控制，线程切换更频繁的场景之下，Thread()和AsyncTask都会显得力不从心。HandlerThread却能胜任这些需求甚至更多。
HandlerThread将Handler，Thread，Looper，MessageQueue几个概念相结合。Handler是线程对外的接口，所有新的message或者runnable都通过handler post到工作线程。Looper在MessageQueue取到新的任务就切换到工作线程去执行。不同的post方法可以让我们对任务做精细的控制，什么时候执行，执行的顺序都可以控制。HandlerThread最大的优势在于引入MessageQueue概念，可以进行多任务队列管理。
我们需要一个执行在工作线程，同时又能够处理队列中的复杂任务的功能，而 HandlerThread 的出现就是为了实现这个功能的，它组合了 Handler，MessageQueue，Looper 实现了一个长时间运行的线程，不断的从队列中获取任务进行执行的功能。HandlerThread 比较合适处理那些在工作线程执行，需要花费时间偏长的任务。我们只需要把任务发送给 HandlerThread，然后就只需要等待任务执行结束的时候通知返回到主线程就好了。

• HandlerThread背后只有一个线程，所以任务是串行执行的。串行相对于并行来说更安全，各任务之间不会存在多线程安全问题。
• HandlerThread所产生的线程会一直存活，Looper会在该线程中持续的检查MessageQueue。这一点和Thread()，AsyncTask都不同，thread实例的重用可以避免线程相关的对象的频繁重建和销毁。
• HandlerThread较之Thread()，AsyncTask需要写更多的代码，但在实用性，灵活度，安全性上都有更好的表现。

4.ThreadPoolExecutor
Thread(),AsyncTask适合处理单个任务的场景，HandlerThread适合串行处理多任务的场景。当需要并行的处理多任务之时，ThreadPoolExecutor是更好的选择,尤其适合处理大量耗时较短的任务，避免出现单个任务阻塞整个队列的情况。
例如我们需要一次性 decode 40张图片，每个线程需要执行 4ms 的时间，如果我们使用专属单线程的方案，所有图片执行完毕会需要花费 160ms(40*4)，但是如果我们创建10个线程，每个线程执行4个任务，那么我们就只需要16ms就能够把所有的图片处理完毕。

public static Executor THREAD_POOL_EXECUTOR
            = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
            TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);

• 线程池可以避免线程的频繁创建和销毁，显然性能更好，但线程池并发的特性往往也是疑难杂症的源头，是代码降级和失控的开始。多线程并行导致的bug往往是偶现的，不方便调试，一旦出现就会耗掉大量的开发精力。
• ThreadPool较之HandlerThread在处理多任务上有更高的灵活性，但也带来了更大的复杂度和不确定性。
• 使用线程池需要特别注意同时并发线程数量的控制，理论上来说，我们可以设置任意你想要的并发数量，但是这样做非常的不好。因为 CPU 只能同时执行固定数量的线程数，一旦同时并发的线程数量超过 CPU 能够同时执行的阈值，CPU 就需要花费精力来判断到底哪些线程的优先级比较高，需要在不同的线程之间进行调度切换。一旦同时并发的线程数量达到一定的量级，这个时候 CPU 在不同线程之间进行调度的时间就可能过长，反而导致性能严重下降。另外需要关注的一点是，每开一个新的线程，都会耗费至少 64K+ 的内存。
• Runtime.getRuntime().availableProcesser()方法并不可靠，他返回的值并不是真实的 CPU 核心数，因为 CPU 会在某些情况下选择对部分核心进行睡眠处理，在这种情况下，返回的数量就只能是激活的 CPU 核心数。

5.IntentService
不得不说Android在API设计上粒度很细，同一样工作可以通过各种不同的类来完成。IntentService又是另一种开工作线程的方式，从名字就可以看出这个工作线程会带有service的属性。和AsyncTask不同，没有和UI线程的交互，也不像HandlerThread的工作线程会一直存活。IntentService背后其实也有一个HandlerThread来串行的处理Message Queue，从IntentService的onCreate方法可以看出：

@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 = new HandlerThread("IntentService[" + mName + "]");
        thread.start();

        mServiceLooper = thread.getLooper();
        mServiceHandler = new ServiceHandler(mServiceLooper);
    }

只不过在所有的Message处理完毕之后，工作线程会自动结束。所以可以把IntentService看做是Service和HandlerThread的结合体，适合需要在工作线程处理UI无关任务的场景。

• 默认的 Service 是执行在主线程的，可是通常情况下，这很容易影响到程序的绘制性能(抢占了主线程的资源)。除了前面介绍过的 AsyncTask 与 HandlerThread，我们还可以选择使用 IntentService 来实现异步操作。IntentService 继承自普通 Service 同时又在内部创建了一个 HandlerThread，在 onHandlerIntent()的回调里面处理扔到 IntentService 的任务。所以 IntentService 就不仅仅具备了异步线程的特性，还同时保留了 Service 不受主页面生命周期影响的特点。
• 因为 IntentService 内置的是 HandlerThread 作为异步线程，所以每一个交给 IntentService 的任务都将以队列的方式逐个被执行到，一旦队列中有某个任务执行时间过长，那么就会导致后续的任务都会被延迟处理。
• 通常使用到 IntentService 的时候，我们会结合使用 BroadcastReceiver 把工作线程的任务执行结果返回给主 UI 线程。使用广播容易引起性能问题，我们可以使用 LocalBroadcastManager 来发送只在程序内部传递的广播，从而提升广播的性能。我们也可以使用 runOnUiThread() 快速回调到主 UI 线程。
• 包含正在运行的 IntentService 的程序相比起纯粹的后台程序更不容易被系统杀死，该程序的优先级是介于前台程序与纯后台程序之间的。

6.Threading and Loaders
参考Loader的初步学习笔记
当启动工作线程的 Activity 被销毁的时候，我们应该做点什么呢？为了方便的控制工作线程的启动与结束，Android 为我们引入了 Loader 来解决这个问题。我们知道 Activity 有可能因为用户的主动切换而频繁的被创建与销毁，也有可能是因为类似屏幕发生旋转等被动原因而销毁再重建。在 Activity 不停的创建与销毁的过程当中，很有可能因为工作线程持有 Activity 的 View 而导致内存泄漏(因为工作线程很可能持有 View 的强引用，另外工作线程的生命周期还无法保证和 Activity 的生命周期一致，这样就容易发生内存泄漏了)。除了可能引起内存泄漏之外，在 Activity 被销毁之后，工作线程还继续更新视图是没有意义的，因为此时视图已经不在界面上显示了。
Loader 的出现就是为了确保工作线程能够和 Activity 的生命周期保持一致，同时避免出现前面提到的问题。
LoaderManager 会对查询的操作进行缓存，只要对应 Cursor 上的数据源没有发生变化，在配置信息发生改变的时候(例如屏幕的旋转)，Loader 可以直接把缓存的数据回调到 onLoadFinished()，从而避免重新查询数据。另外系统会在 Loader 不再需要使用到的时候(例如使用 Back 按钮退出当前页面)回调 onLoaderReset()方法，我们可以在这里做数据的清除等等操作。
在 Activity 或者 Fragment 中使用 Loader 可以方便的实现异步加载的框架，Loader 有诸多优点。但是实现 Loader 的这套代码还是稍微有点点复杂，Android 官方为我们提供了使用 Loader 的示例代码进行参考学习。

三、网友评价

谢谢分享，公司用了HandlerThread，在Activity退出时还要调用Looper的quit方法，现在他们怀疑系统性能差是由于很多Looper在轮循导致，想废掉这种方法

之前试过用ThreadPool，发现设置最大线程数之后会有坑，有些页面的线程要等很久才执行，因为之前页面的线程还没执行完，后来又换回了HandlerThread