让用户感觉使用非常流畅。迟缓会潜移默化地留下不好的印象。用户看见App的图标，便会在心中和“迟缓”、“卡”、“不稳定”画上等号，产生“打开畏惧症”。

　　用户滑动Listview、Gallery、Coverflow时觉得卡，多半是因为相应Adapter对getView的处理不够好。每个Item都会和数据源绑定，而数据源的获取方式有多种：网络、本地文件、SQLite数据库、SharedPreference以及内存，它们的传输时间分别是7秒、2秒、1秒、100毫秒、5毫秒。

　　对于最耗时的网络请求，很多人会采用异步操作，不会让用户耗费精力在网络等待过程中。但在I/O以及SQLite查询时，用户的等待时间容易被忽略，从而降低滑动的流畅感。Android用户常常遇到的ANR(Application Not Responding)，便是这个问题的升级版。要知道，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等数据压缩和编码机制，保证一次取到的数据不至于太大而造成额外延时。