Android 性能优化：多线程

• • 前言
  • Android 开发中多线程的必要性
  • 理解 Android 多线程
    • MessageQueue
    • Looper
    • Handler
    • HandlerThread
  • Android 中为什么只允许在主线程更新 UI
    • Android 系统为了避免过度复杂的线程安全问题特地规定只允许在主线程中更新 UI
    • 而开发者为了避免上述问题需要注意的是
  • 总结
  • Thanks

前言

Android Performance Patterns Season 5 主要介绍了 Android 多线程环境下的性能问题。通过介绍 Android 提供的多种多线程工具类 (AsyncTask, HandlerThread, IntentService, ThreadPool)，让我们熟悉各个组件的适用场景，从而在特定场景下选择性能最好的一个。

本文为观看视频 1 ~ 3 节，参考 胡凯的 Android 性能优化典范第 5 季 总结所得，感谢他们。

Android 开发中多线程的必要性

这里写图片描述

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

• 系统事件（例如设备状态变动）
• 输入事件
• 服务
• 闹钟
• UI 绘制
• …

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

shixinzhang

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

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

这里写图片描述

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

shixinzhang

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

理解 Android 多线程

这里写图片描述

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

shixinzhang

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

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

shixinzhang

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

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

• MessageQueue
• Looper
• Handler

MessageQueue

这里写图片描述

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

Looper

shixinzhang

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

Handler

shixinzhang

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

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

HandlerThread

shixinzhang

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

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

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

这里写图片描述

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

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

这里写图片描述

为什么要这样设计呢？

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

shixinzhang

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

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

shixinzhang

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

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

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

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

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

shixinzhang

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

shixinzhang

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

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

而开发者，为了避免上述问题，需要注意的是：

不要再任何子线程持有 UI 组件或者 Activity 的引用。

总结

本文大概介绍了 Android 中多线程的必要性以及一些基础概念。

Android 系统为我们提供了以下几种工具类：

• AsyncTask

  • 主线程、子线程间任务的切换

• HandlerThread

  • 为某个任务/回调单独开一个线程

• ThreadPool

  • 管理多个线程，并发执行任务

• IntentService

  • 在子线程中获取 Intent，用于执行由 UI 出发的后台 Service

shixinzhang