深度解析多线程带来的Android性能优化原理

Android 开发中多线程的必要性；

Android 开发中，许多操作都需要由 主线程（UI 线程）来执行，比如：

系统事件（例如设备状态变动）

输入事件

服务

闹钟

UI 绘制

…

我们经常需要针对这些情况编写代码。

由于主线程只有一个，所有任务都是串行执行，如果我们在某个操作中包含大量的网络请求、I/O,将会影响后续用户后续操作。

用户感知最明显的就是界面绘制、响应是否及时：

我们知道 Android 系统的屏幕刷新频率为 60 fps, 也就是每隔 16 ms 刷新一次。如果在某次绘制过程中，我们的操作不能在 16 ms 内完成，那它则不能赶上这次的绘制公交车，只能等下一轮，这种现象叫做 “掉帧”，用户看到的就是界面绘制不连续、卡顿。

为了避免耗时较久的操作导致 “掉帧”，我们会把这些操作从主线程执行换到子线程，这样主线程的其他操作不会受到影响，用户体验也会流畅许多。

理解 Android 多线程

一个线程，主要有三个状态：开始、执行任务、结束。

当线程存活期间，我们会让它执行大量的任务，当任务完成或者主动取消时，线程功成身退。

很多情况下，我们会有很多线程同时存活、执行任务，这时需要添加一个 任务队列，让线程不停地从队列中获取任务，同时有其他线程向其中添加任务，典型的 生产者-消费者 模型：

如果我们来实现这个模型，需要写三个角色：生产者线程、消费者线程、任务队列，同时还要保证它们的协作有条不紊，这可能会难倒一大堆人。

为了让开发者更省心，Android 系统替我们实现了上述类，分别是：

     MessageQueue

     Looper

     Handler

MessageQueue

MessageQueue 就是任务队列，保存着不同类型任务的载体 (Intent, Runnable, Message)。

Looper

Looper 就是我们所说的 “消费者”，它不停地从任务队列中获取任务并执行。

Handler

Handler 就是 “生产者”，它把任务从其他线程送到 MessageQueue 中。

Handler 可以指定任务在任务队列中的位置，也可以按照一定的时间延迟送货。

HandlerThread

HandlerThread 就是上述三个组件的组合。

每个应用启动时，系统会创建一个该应用的进程以及主线程，这里的主线程就是一个 HandlerThread。

这个主线程会处理主要事件，具体内容如图所示：

Android 中为什么只允许在主线程更新 UI？

Android 系统中，默认只能在 主线程（UI 线程）更新 UI，当你在 子线程进行 UI 修改时，可能不起作用甚至是奔溃：

为什么要这样设计呢？

我们知道，多线程并发访问资源要遵循重要的原则就是 原子性、可见性、有序性。没有同步机制的情况下，多个线程同时读写内存可能会导致意料之外的问题：

多线程同时操作 UI 也一样，如果想要允许多个线程更新 UI，就要设计对应的同步机制，为了避免这种问题，Android 系统直接规定只允许在 UI 线程更新 UI。

除了线程安全外，还有个原因： UI 组件的生命周期并不确定。

可能有这种情况：我们在某个执行网络请求的线程中持有一个 Button 的引用，然而在请求结果返回之前，这个 button 被 View Hierarchy 移除，这时对 button 的任何操作都不可用，并且也没有意义了。

此外还有一点 线程引用导致的内存泄漏问题。

我们知道每个 View 都持有当前 Context, Activity 的引用，如果子线程持有某个 View 的引用，继而持有了对应 Activity 引用，那么在线程返回之前，即使该 Activity 不可用，也无法回收，这就造成了 内存泄漏。

除了持有 View，线程隐式持有 Activity 也可能导致内存泄漏，只要子线程没有结束，引用关系就一直存在。

比如在 Activity 中创建个内部 AsyncTask:

或者是常见的在 Activity 里创建个 Handler:

正如 Android Studio 提示的那样，内部线程工具类持有外部类引用，可能会导致 内存泄漏。

Android 系统为了避免过度复杂的线程安全问题，特地规定只允许在主线程中更新 UI。

而开发者，为了避免上述问题，需要注意的是：不要再任何子线程持有 UI 组件或者 Activity 的引用。

ps；欢迎有从事Android移动互联网开发方面的朋友加QQ群一起交流提升;701740775