Android Performance Patterns Season 5 主要介绍了 Android 多线程环境下的性能问题。通过介绍 Android 提供的多种多线程工具类 (AsyncTask, HandlerThread, IntentService, ThreadPool),让我们熟悉各个组件的适用场景,从而在特定场景下选择性能最好的一个。
本文为观看视频 1 ~ 3 节,参考 胡凯的 Android 性能优化典范第 5 季 总结所得,感谢他们。
Android 开发中,许多操作都需要由 主线程(UI 线程)来执行,比如:
我们经常需要针对这些情况编写代码。
由于主线程只有一个,所有任务都是串行执行,如果我们在某个操作中包含大量的网络请求、I/O,将会影响后续用户后续操作。
用户感知最明显的就是界面绘制、响应是否及时:
我们知道 Android 系统的屏幕刷新频率为 60 fps, 也就是每隔 16 ms 刷新一次。如果在某次绘制过程中,我们的操作不能在 16 ms 内完成,那它则不能赶上这次的绘制公交车,只能等下一轮,这种现象叫做 “掉帧”,用户看到的就是界面绘制不连续、卡顿。
为了避免耗时较久的操作导致 “掉帧”,我们会把这些操作从主线程执行换到子线程,这样主线程的其他操作不会受到影响,用户体验也会流畅许多。
一个线程,主要有三个状态:开始、执行任务、结束。
当线程存活期间,我们会让它执行大量的任务,当任务完成或者主动取消时,线程功成身退。
很多情况下,我们会有很多线程同时存活、执行任务,这时需要添加一个 任务队列,让线程不停地从队列中获取任务,同时有其他线程向其中添加任务,典型的 生产者-消费者 模型:
如果我们来实现这个模型,需要写三个角色:生产者线程、消费者线程、任务队列,同时还要保证它们的协作有条不紊,这可能会难倒一大堆人。
为了让开发者更省心,Android 系统替我们实现了上述类,分别是:
MessageQueue 就是任务队列,保存着不同类型任务的载体 (Intent, Runnable, Message)。
Looper 就是我们所说的 “消费者”,它不停地从任务队列中获取任务并执行。
Handler 就是 “生产者”,它把任务从其他线程送到 MessageQueue 中。
Handler 可以指定任务在任务队列中的位置,也可以按照一定的时间延迟送货。
HandlerThread 就是上述三个组件的组合。
每个应用启动时,系统会创建一个该应用的进程以及主线程,这里的主线程就是一个 HandlerThread。
这个主线程会处理主要事件,具体内容如图所示:
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 提示的那样,内部线程工具类持有外部类引用,可能会导致 内存泄漏。
不要再任何子线程持有 UI 组件或者 Activity 的引用。
本文大概介绍了 Android 中多线程的必要性以及一些基础概念。
Android 系统为我们提供了以下几种工具类:
接下来我们将跟随官方视频逐渐了解这几个工具类的特点,从而能够在合适的场景下选择对的人,尽可能地优化应用的性能。
感谢关注。
https://www.youtube.com/watch?v=qk5F6Bxqhr4&index=1&list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE&t=39s