Android线程优化——整体思路与方法

**在日常开发APP的过程中，难免需要使用第二方库和第三方库来帮助开发者快速实现一些功能，提高开发效率。但是，这些库也可能会给线程带来一定的压力，主要表现在以下几个方面：

线程数量增多：一些库可能会在后台启动一些线程来执行任务，这样会增加系统中线程的数量，从而导致系统资源的浪费。
线程竞争：一些库可能会在同一时间启动多个线程来执行任务，这样会导致线程之间的竞争，从而影响程序的执行效率。
线程阻塞：一些库可能会在执行任务时阻塞主线程，从而导致程序的卡顿和响应速度变慢。

整体思路

为了解决使用第二方库和第三方库代理的线程问题，我选择用下面的思路来进行线程优化：

线程检测，评估优化空间。
线程统计，收集优化范围。
线程和线程池优化，线程数收敛。
线程栈裁剪，减少线程内存。

线程的性能

熟练使用Android上的线程可以帮助你提高应用程序的性能。本篇文章讨论了使用线程的几个方面：使用UI或主线程; 应用程序生命周期和线程优先级之间的关系; 以及平台提供的帮助管理线程复杂性的方法。在每一部分，本篇都描述了潜在的陷阱以及如何避免它们的策略。

主线程

当用户启动你的应用程序时，Android会创建一个新的 Linux process 以及一个执行线程。这个main线程，也称为UI线程，负责屏幕上发生的一切。了解其工作原理可以帮助你使用主线程设计你的应用程序以获得最佳性能。

内部细节

主线程具有非常简单的设计：它的唯一工作就是从线程安全的工作队列中取出并执行工作块，直到应用程序被终止。框架从各个地方生成一些这些工作块。这些地方包括与生命周期信息，用户事件（如输入）或来自其他应用程序和进程的事件相关联的回调。此外，应用程序还可以在不使用框架的情况下显式地将工作块加入队列。

应用程序执行的任何代码块都会被绑定到一个事件回调上，例如输入，布局填充或绘制。当某个时间触发一个事件时，事件发生的所在线程会将事件加入到主线程的消息队列。之后主线程可以处理该事件。

当发生动画或屏幕更新时，系统试图每16ms左右执行一个工作块（负责绘制屏幕），以便以每秒60帧的速度平滑地渲染。为了让系统达到这个目标，一些操作必须发生在主线程上。但是，当主线程的消息队列包含太多或太耗时的任务，为了让主线程能够在16ms内完成工作，你应将这些任务移到工作线程中去。如果主线程不能在16ms内完成执行的代码块，则用户可能感觉到卡顿或UI响应较慢。如果主线程阻塞大约5秒钟，系统将显示“（ANR）”对话框，允许用户直接关闭应用程序。

从主线程移除多个或耗时的任务，以便它们不会干扰到平滑渲染和对用户输入的快速响应，是你在应用程序中采用线程的最大原因。

线程和UI对象的引用

按照设计，Android UI对象不是线程安全的。应用程序应该在主线程上创建，使用和销毁UI对象。如果尝试修改或甚至引用除主线程之外的线程中的UI对象，结果可能是异常，静默失败，崩溃和其他未定义的错误行为。

UI对象引用导致的问题可以划分为两种：显式引用和隐式引用。

显示引用

许多非主线程上的任务在最后都会更新UI对象。但是，如果某一个线程访问视图层级中的对象，可能会导致应用的不稳定性：如果工作线程修改了同时被任何其他线程引用的对象属性（这里都是指UI对象），则结果是不可预测的。

假设一个应用程序在工作线程上直接引用UI对象。这个UI对象可能包含对一个View的引用; 但在工作完成之前，该View被从视图层次结构中删除了。如果该引用将View对象保留在内存中并对其设置属性，用户并不会看到此对象，因为一旦对象的引用消失，应用程序就会删除该对象。

再举另一个例子，View对象（被工作线程引用）持有包含它们的Activity的引用。如果该Activity被销毁了，但仍有一个工作的线程直接或间接引用它 - 垃圾收集器将不会回收Activity，直到该工作线程执行完成。

在某些Activity生命周期事件（如屏幕旋转）发生时，某些线程工作可能正在运行。系统将无法执行垃圾回收，直到正在进行的工作完成。因此，在内存中可能会有两个Activity对象，直到垃圾回收发生。

考虑到以上场景，我们建议你的应用程序的工作线程中不应该包含对UI对象的显式引用。避免此类引用可帮助你避免这些类型的内存泄漏，同时避免线程竞争。

在所有情况下，应用程序应该只在主线程上更新UI对象。如果有多个任务希望更新实际的UI，你应该制定一个策略，允许多个线程交互，最终将结果返回到主线程。

隐式引用

在以下代码片段中可以看到带有线程对象代码的常见设计缺陷：

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

这段代码的缺陷是将线程对象MyAsyncTask声明为一些Activity的内部类。这种声明创建一个对Activity对象隐式引用。因此，该对象持有对Activity的引用，直到线程工作完成，这样会导致所引用的Activity延迟销毁。这种延迟会给内存带来更大的压力。

解决该问题的直接解决方案是在自己的文件中定义重载类实例，从而移除对Activity的隐式引用。

另一个解决方案是将AsyncTask声明为静态内部类。这样做也可以消除隐式引用问题，因为静态内部类与普通内部类不同：普通内部类实例需要外部类的实例才可以实例化，并且可以直接访问其包含的方法和字段。相比之下，静态内部类不需要引用外部类实例，因此它不包含对外部类成员的引用。

public class MainActivity extends Activity { // …… Static public class MyAsyncTask extends AsyncTask { @Override protected String doInBackground(Void… params) {…} @Override protected void onPostExecute(String result) {…} }}

Android线程优化方案出发点：

不能通过非UI线程对View进行操作。因为Android的UI不是安全的，如果View能被不同的线程所访问或修改，那么就可能在程序的执行期间，产生不可预期的行为或者并发错误。
使用线程时，避免在循坏中使用同步，因为获取和释放锁的操作代价很大。会引起CPU资源的损耗。
处理多线程以及线程间通信时，使用HandlerThread来操作，它内部包装了Looper，记得不用的时候退出/释放资源哦。
当工作线程与UI线程之间通信的时候，推荐使用AsyncTask（Android 7.0后内部任务变成串行处理，不再会出现以前并行时超过任务数执行饱和策略的情况）
Loader可以用来代替AsyncTask的某些情况，因为Loader的生命周期是独立的（与Application Context有关），当Activity/Fragment销毁重建时，它仍然在，而且它特别使用异步操作，比如AsyncTaskLoader代替AsyncTask也可以实现后者的功能，但是生命周期完全独立于Activity。切记Loader使用完记得销毁。
当你的Service不需要交互时，请使用可以自动停止的IntentService。
当你希望延长BroadcastReceiver的生命周期时，例如启动一个后台线程IntentService。在onReceiver中调用BroadcastReceiver.goAsync()，它会返回一个PendingResult对象，这时，广播接收器的生命周期会延长持续到PendingResult.finish()方法调用。
线程池最好用构造方法手动创建，而不要用Executors来直接调用工厂方法，这样利于明白线程池的运行规则，避免用了错误的线程池导致资源耗尽。
给线程一个好听的名字，调试时候用。
线程池设置线程的存活时间，以保证空闲线程准确释放。

有关Android的线程优化就介绍这麽多，更多的Android性能优化问题，可以参考《Android性能优化》这个文档。