知道，

Activity Manager 和 Window Manager 监视着应用程序的响应，当发现按键或触摸发

生后

5 秒还没执行完处理逻辑，或是 BroadcastReceiver 处理时间超过了 10 秒，系统便会抛

出

ANR 错误，并提醒用户强制终止应用。

我的建议如下：

对于无法在短时间完成的操作，在独立线程中处理，

Android 有多种异步处理模型可供

使用，包括

Thread-Handler、AsyncTask 以及 Loader and CursorLoader。  尽可能减少复杂计算

和降低

I/O，充分估计对象的使用频率，选择合适的数据源。个人认为大部分应用中不会存

在太多太大的对象，可以考虑将数据缓存在内存中。如果应用中有太多图片不能一直缓存，
可采用

LRU（Least Recently Used ,最近最少使用）算法将不常用的缓存清理出内存，这样

缓存大小可控，从而不会出现

Out of Memory（内存溢出）的 Bug。 

但要注意，算法是把双刃剑，如果你享受到类似

LRU 带来的提速后的爽快，就可能会

挖空心思探索更高效的算法。这时要慎重，后面会讲到看上去很牛的算法带来的问题。

另外，网络等待虽然是最耗时，但却容易被忽略。因为粗看上去网络是不可控的，与开

发无关。一般会设置几秒钟的超时，超时则重发。事实上，在国内，中国移动的

GRPS 网络

占主导，所以手机上网普遍很慢，

HTTP 连接上下行 10 秒是很正常的，超时设置 20 秒都不

为过。同时，根据友盟对

Android 应用使用的统计，用户在每个 App 上的一次启动花费时间

是

1 分钟左右，理论上有 3 次重发机会，但一次超时（假设是 20 秒）后，用户就已经失去

信心，不会再等待一次了。所以在开发时，要结合具体使用场景，设计数据预取机制，尽量
降低网络请求次数，同时考虑

gzip、protobuf 等数据压缩和编码机制，保证一次取到的数据

不至于太大而造成额外延时。