[译]不要在UI主线程中进行耗时的操作

原文： Why Ice Cream Sandwich Crashes your App

问题

自Android Ice Cream Sandwich发布后， 这个问题就开始在StackOverflow弥散开来：

我的应用在Android2.x上运行良好，但是在3.x 和4.x系统上总是强退，是什么导致的？

这是一个很棒的问题，毕竟开发者总是希望基于旧版本系统开发的应用在新版本的Android系统仍能兼容。在我看来，问题的原因可能多种多样。 但大多数时候，原因非常简单：你把一个可能非常耗时的操作放进了UI线程。

什么是UI线程？

应用的主UI线程的概念及其重要性是每个Android开发者都应理解。当一个应用启动，系统会为应用创建一个名为“main”的主线程。这个主线程（也就是UI主线程）主要负责把事件分发给合适的view或者widget， 因此它非常重要。它也是你的应用和应用的UI交互的线程。例如，如果你点击了屏幕上的一个按钮，UI线程会把点击时间交给view处理，view接到事件后会设置它的pressed状态，然后向事件队列中发送一个invalidate请求。 UI线程会依次读取队列并且告诉view去重绘自己。

除非你的Android应用实现的非常合理，否则这个单线程模型会使性能变得极低。在极端情况下，如果UI线程负责整个应用中的所有操作，进行耗时的操作比如发送网络请求，或者数据库查询等都会导致用户界面的阻塞。这些操作在未完成之前，所有的时间包括绘制和触屏事件都不会被派发。从用户的角度来看，程序似乎是卡死了。

在这些情况下，即时的反馈相当重要。研究表明0.1s是用户感觉系统是否流畅的临界值。任何比临界值更慢的都被认为延迟（Miller 1968; Card et al. 1991）。虽然1秒看起来没什么影响，但在GooglePlay中，即便是十分之一秒也可能是好评和差评的区别。更糟糕的是，如果UI线程被阻塞5秒以上，用户会收到“程序未响应”（ANR）的提示对话框，并且会强制退出。

为什么Android会使应用崩溃

应用在2.x系统运行良好，在3.0及以上平台上崩溃的主要原因在于，3.0以上平台在处理UI线程资源滥用上更加严格。比如说，3.0平台检测到UI线程中有网络请求时，会抛出NetworkOnMainThreadExceptionwill的异常：

E/AndroidRuntime(673): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example/com.example.ExampleActivity}: android.os.NetworkOnMainThreadException

Android developer网站文档中也对此进行了很好的解释：

当应用试图在主线程中进行网络操作，NetworkOnMainThreadException会被抛出。只有在运行Honeycomb SDK及更高的版本中会被抛出。更早版本的SDK允许在主事件循环线程中进行网络操作，但是非常非常不鼓励这么做。

列出一些ICS和Honeycomb不允许在UI线程中进行的操作：

• 打开套接字连接 (i.e. new Socket()).
• HTTP 请求 (i.e. HTTPClient and HTTPUrlConnection).
• 试图连接远程的 MYSQL 数据库.
• 下载文件 (i.e.Downloader.downloadFile()).

如果你要在UI线程中进行某些操作，一定要把它们打包到一个工作线程中。其中最简单的方式是使用AsyncTask， 它允许你在你的用户界面中进行一些异步的操作。AsyncTask会把阻塞操作放到工作线程中，并把结果返回到UI线程，而你不需要处理任何与线程相关的工作。

结论

我决定写这篇主题的念头来源于我在StackOerflow和其它论坛上无数次看到了这个问题。问题的主要来源是在UI线程进行了耗时的操作。为了确保用户界面保持流畅，有必要把执行套接字连接、HTTP请求、文件下载和其他的耗时操作放到一个单独的线程中。最简单的方法就是把操作打包到AsyncTask中，它会帮助你启动新的线程并让他们与你的用户界面异步交互。

有帮助的链接

这些资料可能会帮助你熟悉AsyncTask

AsyncTask documentation
Multithreading For Performance