優秀的體驗來自於優秀的效能

優秀的體驗來自於優秀的效能，而優秀的效能無非就是從這麼幾個方面著手：降低耗電量、減少CPU使用、CPU使用均衡、及時回收記憶體、避免頻繁GC、使裝置及時休眠。

這裡列舉一些具體實施時的切入點。

AlarmManager
不要不做限制地使用定時器，要根據情境選擇性地註冊並及時登出定時器。比如，依賴網路條件的應該使用SyncAdapter；使用者登出後，記得登出定時器等。
另外，定時器的周期最好控制在15分鐘以上，這個是Android官方給出的經驗值，再頻繁的話，對待機電量消耗的影響就會明顯變大了。
關於定時器的模式。wakeup的好處是可以對使用者關心的狀態及時更新，但會打斷機器休眠，如果很頻繁的話，會使用機器睡不下去，耗電量明顯上升。非wakeup的好處就是比較省電，但會把所有的任務集中到使用者喚醒機器的那一刹那來執行，從而造成使用者喚醒機器時的卡頓。

Wake Lock
除了像視頻播放這種即使使用者長時間不操作也需要保持在前台的程式，實質上很少有申請Wake Lock的需求。另外，一旦程式退出前台，記得釋放。

Broadcast
通過AndroidManifest.xml靜態聲明的全域廣播接收器是耗電大戶。可能會有很多程式註冊像“網路狀態改變”、“電話狀態”、“設定解鎖”等常見事件。那麼，在這些事件發生時會觸發多個進程建立，頻繁的GC，卡頓也就來了。所以，請盡量使用動態註冊。
另外，“網路狀態改變”可以使用Android提供的SyncAdapter來實現低成本的監聽。
Receiver的進程配置也有些技巧。如果Receiver需要喚醒UI進程，就把它和UI配置到一個進程當中，如果需要喚醒後台服務，就把它和後台服務配置到一個進程當中。可以減少系統建立進程的開銷。

後台服務
把後台服務單獨做為一個進程，可以大大減少UI進程的記憶體壓力。如果把它們放到一個進程中，只要它們中的任意一個沒有完成任務，它們倆都會一直存在於記憶體中。

長串連
長串連意味著需要保持網路連接、周期性的心跳資料轉送、裝置無法休眠，使用需謹慎。

Bitmap
在Java的設計中沒有釋放記憶體這個概念的，但實際使用中，大對象除外。Android中的Bitmap就是這麼一個例外。Bitmap的不及時回收會造成記憶體的彪升。詳細的分析可以參考這篇文章。
Bitmap recycle方法與製作Bitmap的記憶體緩衝：

http://blog.csdn.net/a345017062/article/details/7963081