Android高级面试题之SDK源码分析：通过线程提升性能

目录

• 主线程
  • 内部原理
• 线程和界面对象引用
  • 显示引用
  • 隐式引用
• 线程和应用Activity生命周期
  • 保留线程
  • 线程优先级
• 线程处理的辅助类
  • AsyncTask 类
  • HandlerThread 类
  • ThreadPoolExecutor 类

善于在 Android 上利用线程可以帮助您提升应用的性能。本页从以下几个方面讨论线程的使用：使用界面线程（即主线程）；应用生命周期与线程优先级之间的关系；以及平台为帮助管理线程复杂性所提供的方法。对于每个方面，本文都介绍了潜在的陷阱和相应的规避策略。

主线程

当用户启动您的应用时，Android 会创建新的 Linux 进程以及执行线程。这个主线程也称为界面线程，负责屏幕上发生的一切活动。了解其工作原理有助于您通过设计让应用利用主线程实现最佳性能。

内部原理

主线程的设计非常简单：它的唯一工作就是从线程安全工作队列获取工作块并执行，直到应用被终止。框架会从多个位置生成部分工作块。这些位置包括与生命周期信息、用户事件（例如输入）或来自其他应用和进程的事件相关的回调。此外，应用也可以不使用框架而自行对块进行明确排队。

应用执行的任何代码块几乎都与事件回调（例如输入、布局扩充或绘制）相关联。当某个操作触发事件时，发生了事件的线程会将事件从线程本身里推送到主线程的消息队列中。然后，主线程可以为事件提供服务。

当有动画或屏幕更新正在进行时，系统会每隔 16ms 左右尝试执行一个工作块（负责绘制屏幕），从而以每秒 60 帧的流畅速度进行渲染。要使系统达到此目标，界面/视图层次结构必须在主线程上更新。但是，如果主线程的消息队列中的任务太多或太长，导致主线程无法足够快地完成更新，那么应用应将此工作移至工作线程。如果主线程无法在 16ms 内执行完工作块，则用户可能会察觉到卡顿、延迟或界面对输入无响应。 如果主线程阻塞大约 5 秒，系统会显示“应用无响应”(ANR) 对话框，允许用户直接关闭应用。

将大量或冗长的任务从主线程中移出，使其不影响流畅渲染和快速响应用户输入，这是您在应用中采用线程处理的最大原因。

线程和界面对象引用

根据设计，Android 视图对象不是线程安全的。无论是创建、使用还是销毁界面对象，应用都应在主线程上完成。如果您尝试在主线程以外的其他线程中修改甚至引用界面对象，则可能导致异常、无提示故障、崩溃以及其他未定义的异常行为。

引用方面的问题分为两类：显式引用和隐式引用。

显式引用

非主线程上的许多任务的最终目标是更新界面对象。但是，如果其中一个线程访问视图层次结构中的某个对象，则可能导致应用不稳定：如果工作线程更改该对象的属性，与此同时有任何其他线程正在引用该对象，则结果无法确定。

例如，假设某个应用在工作线程上直接引用了界面对象。工作线程上的该对象可能包含对 View 的引用；但在工作完成之前，View 已从视图层次结构中移除。当这两个操作同时发生时，该引用会将 View 对象保留在内存中，并对其设置属性。 但是，用户从不会看到此对象，而且应用会在对象引用消失后删除该对象。

再举一个例子，假设 View 对象包含对其所属的 Activity 的引用。如果该 Activity 被销毁，但仍有直接或间接引用它的线程处理工作块，则垃圾回收器会等到该工作块执行完毕再收集该 Activity。

如果在线程处理工作的执行过程中发生某个 Activity 生命周期事件（例如屏幕旋转），这种情况可能会导致问题。在执行中的工作完成之前，系统将无法执行垃圾回收。因此，等到可以进行垃圾回收时，内存中可能有两个 Activity 对象。

在这类情况下，我们建议您不要在应用的线程处理工作任务中包含对界面对象的显式引用。避免此类引用有助于防止这些类型的内存泄漏，同时避开线程处理争用。

在任何情况下，应用都只应在主线程上更新界面对象。这意味着您应制定允许多个线程将工作传回主线程的协商政策，让最顶层的 Activity 或 Fragment 负责更新实际界面对象。

隐式引用

以下代码段演示了线程处理对象的常见代码设计缺陷：

    public class MainActivity extends Activity {
      // ...
      public class MyAsyncTask extends AsyncTask<Void, Void, String>   {
        @Override protected String doInBackground(Void... params) {...}
        @Override protected void onPostExecute(String result) {...}
      }
    }

此代码段的缺陷在于，代码会将线程处理对象 MyAsyncTask 声明为某个 Activity 的非静态内部类（或 Kotlin 中的内部类）。此声明会创建对封装 Activity 实例的隐式引用。因此，在线程处理工作完成之前，该对象一直包含对相应 Activity 的引用，导致所引用 Activity 的销毁出现延迟。 这种延迟进而会给内存带来更多压力。

此问题的直接解决方法是将过载的类实例定义为静态类，或在其自己的文件中定义，从而移除隐式引用。

另一个解决方法是将 AsyncTask 对象声明为静态嵌套类（或在 Kotlin 中移除内部限定符）。这样做可以消除隐式引用问题，因为静态嵌套类与内部类有所不同：内部类的实例要求对外部类的实例进行实例化，并且可直接访问封装实例的方法和字段。相反，静态嵌套类不需要引用封装类的实例，因此它不包含对外部类成员的引用。

    public class MainActivity extends Activity {
      // ...
      static public class MyAsyncTask extends AsyncTask<Void, Void, String>   {
        @Override protected String doInBackground(Void... params) {...}
        @Override protected void onPostExecute(String result) {...}
      }
    }

线程和应用 Activity 生命周期

应用生命周期会影响线程处理在应用中的工作方式。您可能需要确定线程在 Activity 销毁后应不应该保留。您还应注意线程优先级与 Activity 是在前台运行还是在后台运行之间的关系。

保留线程

线程会在生成这些线程的 Activity 的生命周期过后继续保留。无论是否发生 Activity 创建或销毁事件，线程都会继续不间断地执行。在某些情况下，这种持久性是可取的。

假设某个 Activity 生成了一组线程处理工作块，然后在工作线程能执行工作块之前被销毁。应用应如何处理正在执行的工作块？

如果工作块将要更新不再存在的界面，则该工作不必再继续。例如，如果该工作是从数据库加载用户信息，然后更新视图，则不再需要该线程。

相比之下，工作数据包可能具有某种不完全与界面相关的优势。在这种情况下，您应该保留该线程。例如，数据包可能正在等待下载图片，将其缓存到磁盘并更新关联的 View 对象。虽然该对象已不存在，但是下载和缓存该图片可能仍然有用，以防用户返回到已销毁的 Activity。

为所有线程处理对象手动管理生命周期响应可能极其复杂。如果管理不当，应用可能会遇到内存争用和性能问题。您可以结合使用 ViewModel 和 LiveData加载数据并在数据发生更改时收到通知，而不用关心生命周期。ViewModel 对象是此问题的一种解决方案。ViewModel 会在配置更改后保持不变，便于您保留视图数据。要详细了解 ViewModel 和 LiveData，请分别参阅 ViewModel 指南和 LiveData 指南。如果您还想详细了解应用架构，请参阅应用架构指南。

线程优先级

应用线程的优先级一定程度上取决于应用处于生命周期的哪个阶段。在应用中创建和管理线程时，请务必设置线程的优先级，以便正确的线程适时获得正确的优先级。如果设置得过高，您的线程可能会干扰界面线程和 RenderThread，导致应用掉帧。如果设置得过低，可能会导致异步任务（例如图片加载）达不到所需的速度。

每次创建线程时，都应调用 setThreadPriority()。系统的线程调度程序会优先考虑优先级较高的线程，在这些优先级与最终将所有工作都完成的需求之间做出权衡。一般来说，前台组约占设备总执行时间的 95%，而后台组约占 5%。

系统还会使用 Process 类为每个线程分配系统自己的优先级值。

默认情况下，系统会将线程的优先级设置为与生成它的线程具有相同的优先级和组成员资格。但是，您的应用可以使用 setThreadPriority() 明确调整线程优先级。

Process 类提供了一组可供您的应用设置线程优先级的常量，以帮助简化优先级值的分配。例如，THREAD_PRIORITY_DEFAULT 代表线程的默认值。如果线程执行的工作不太紧急，应用应将线程的优先级设为 THREAD_PRIORITY_BACKGROUND。

应用可以使用 THREAD_PRIORITY_LESS_FAVORABLE 和 THREAD_PRIORITY_MORE_FAVORABLE 常量作为增量器来设置相对优先级。如需线程优先级的列表，请参阅 Process类中的 THREAD_PRIORITY 常量。

如需详细了解如何管理线程，请参阅有关 Thread 和 Process类的参考文档。

线程处理的辅助类

框架提供了相同的 Java 类和基元来方便线程处理，例如 Thread、Runnable和 Executors类。为了帮助减轻与开发适用于 Android 的线程处理应用相关的认知负荷，框架提供了一组可协助开发的辅助程序，例如 AsyncTaskLoader 和 AsyncTask。每个辅助类都有一组特定的性能细微差别，专用于解决一小部分特定的线程处理问题。将错误的类用在错误的场合可能会导致性能问题。

AsyncTask 类

对于需要快速将工作从主线程移动到工作线程的应用来说，AsyncTask 类是一个简单实用的基元。例如，输入事件可能会触发使用加载的位图更新界面的需求。AsyncTask对象可以将位图加载和解码分流到备用线程；处理完成后，AsyncTask对象可以设法回到主线程上接收工作以更新界面。

在使用 AsyncTask 时，请注意以下几个性能方面的要点。首先，默认情况下，应用会将其创建的所有 AsyncTask对象推送到单个线程中。因此，它们按顺序执行，而且与主线程一样，特别长的工作数据包可能会阻塞队列。鉴于这个原因，我们建议您仅使用 AsyncTask 处理持续时间短于 5ms 的工作项。

对于隐式引用问题，AsyncTask 对象也是最常见的诱因。AsyncTask 对象也会带来与显式引用相关的风险，但这些风险有时更容易解决。例如，AsyncTask 可能需要引用某个界面对象，以便 AsyncTask 在主线程上执行其回调后正确更新该界面对象。在这种情况下，您可以使用WeakReference存储对所需界面对象的引用，并在 AsyncTask 在主线程上运行后访问该对象。注意，保留对一个对象的 WeakReference 不会使该对象变为线程安全；WeakReference 仅提供一种处理显式引用和垃圾回收问题的方法。

HandlerThread 类

虽然 AsyncTask 很有用，但对您的线程处理问题来说，它可能并不一定是正确的解决方案。相反，您可能需要采用更传统的方法在更长时间运行的线程上执行工作块，并且能够手动管理该工作流。

想一想从您的 Camera 对象获取预览帧时遇到的常见问题。当您注册 Camera 预览帧时，您会在 onPreviewFrame() 回调中收到这些帧，该回调在调用了它的事件线程上被调用。如果该回调是在界面线程上调用的，则处理大型像素矩阵的任务会干扰渲染和事件处理工作。AsyncTask 也存在同样的问题，它也是按顺序执行作业，并且容易出现阻塞。

这种情况适合采用处理程序线程：处理程序线程实际上是一个长时间运行的线程，会从队列中抓取工作并对其进行操作。在此示例中，当您的应用将 Camera.open() 命令委托给处理程序线程上的工作块时，关联的 onPreviewFrame() 回调会进入处理程序线程，而不是界面或 [AsyncTask](https://developer.android.google.cn/reference/android/os/AsyncTask) 线程。因此，如果要对像素执行长时间运行的工作，这可能是更好的解决方案。

当您的应用使用 HandlerThread 创建线程时，别忘了根据线程正在执行的工作类型设置其优先级。请记住，CPU 只能并行处理少量线程。设置优先级有助于系统了解当所有其他线程都在争取关注时调度此工作的正确方法。

ThreadPoolExecutor 类

某些类型的工作可以简化为高度并行的分布式任务。例如，为 800 万像素图片的每个 8x8 块计算滤镜就是这样的一个任务。鉴于这会创建大量的工作数据包，AsyncTask 和 HandlerThread 类并不合适。具有单线程处理特性的 AsyncTask 会将所有线程池化的工作转化为一个线性系统。另一方面，使用 HandlerThread 类需要程序员在一组线程之间手动实现负载平衡。

ThreadPoolExecutor 是一个可简化此过程的辅助类。这个类可用于管理一组线程的创建，设置其优先级，并管理工作在这些线程之间的分布情况。随着工作负载的增减，该类会创建或销毁更多线程以适应工作负载。

该类还可帮助您的应用生成最佳数量的线程。构造 ThreadPoolExecutor 对象时，应用会设置最小和最大线程数。随着 ThreadPoolExecutor 上的工作负载不断增加，该类会考虑初始化的最小和最大线程计数，并考虑待处理工作量。ThreadPoolExecutor 根据这些因素决定在任何特定时间应保留多少线程。

您应该创建多少线程？

尽管在软件层面上，您的代码可以创建数百个线程，但这样做会导致性能问题。您的应用与后台服务、渲染程序、音频引擎、网络等共享有限的 CPU 资源。CPU 实际上只能并行处理少量线程；一旦超限便会遇到优先级和调度问题。因此，务必要根据工作负载需求创建合适数量的线程。

实际操作起来，这一决定取决于很多变量，但是可以选择一个值（例如首先选择 4 个），并使用 Systrace 进行测试，这个策略跟任何其他策略一样可靠。您可以采用试错法得出最少要将线程数减至多少才不至于遇到问题。

在决定创建多少个线程时，还需要考虑到线程不是免费的，它们会占用内存。每个线程至少需要占用 64k 内存。设备上安装的众多应用会使这一数字迅速累加，特别是在调用堆栈显著扩大的情况下。

许多系统进程和第三方库经常会创建自己的线程池。如果您的应用可以重复使用现有线程池，则可以减少内存和处理资源争用，从而帮助提高性能。

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。