降低android應用程序耗電量的解決方案

隨時都得插在牆上充電的設備，不叫移動設備。如果你的App讓用戶一直守著牆角，用戶也會很快把你丟到牆角。你會問：“他怎麼知道我的應用耗電？”很抱歉，目前來看，Android用戶中有大量發燒友和技術高手，同時系統很不客氣地記錄了每個應用的耗電量，於是用戶偶爾會去系統後台查查耗電大戶，之後會毫不客氣地打開卸載工具。

所以需注意以下幾點：

1.不要絞盡腦汁設計復雜算法，不要在後台跑服務，不要網斷了還不停重試。

在開發一個模塊前先想想會不會費電，如果會，就不要去做。代碼是為了服務用戶，而不是折騰用戶。

高手喜歡挑戰，尤其在手機上實現精巧的算法，這樣能帶來更強的征服感。有人曾在手機上實現了布隆過濾器（一個龐大精巧的類哈希表，多用於在服務器端如垃圾郵件查找），其內存消耗和計算復雜度都遠遠高於普通的HashMap，且實現並不容易。結果App發布之後，出現用戶抱怨耗電量大，並且經常出現Bug，最後還是老老實實換成了HashMap。任何算法的目的都是為了服務用戶，如果簡單自然的方法能更好地做到這點，何樂而不為？如果真的在客戶端找不到簡單的算法，則需要反思——為什麼在手機上需要復雜的計算？是否該將這些計算放在服務器端？

2.不要在後台濫用Service。Android非常開放，開發者可在後台觸發任何處理邏輯，肆意占用CPU和內存。

一般來說，Service的目的是為了監控變化，包括系統和網絡變化。系統變化可通過注冊BroadcastReceiver監聽控制，比如應用安裝和卸載等事件，這樣耗電量非常小，完全可替代在Service中輪播。網絡請求無法用BroadcastReceiver監聽，但是有兩個建議。
? 無嚴苛的實時性要求，可延長輪播間隔，如6小時自動請求一次，同時時間隔可通過服務器在線更新。這樣既省電，偶爾急需實時推送時也可在線調整時間間隔。
? 對實時性有要求，考慮使用成熟的推送服務，如Google的C2DM（http://code.google.com/android/c2dm/），和亞馬遜的AWS SDK （http://aws.amazon.com/sdkforandroid/）。

3.網絡請求不要太頻繁。

系統組件中最耗電的是屏幕，其次就是網絡。前文已經提到過，網絡出錯重發會降低用戶體驗，還會耗費電力。可通過數據預取結合數據壓縮算法減少網絡請求次數。

總之，在開發時我們要替用戶思考是否做到了“流暢、友好、省電”，以保證App擁有不錯的用戶體驗。