? ??前言：現(xiàn)在市場(chǎng)上很多App裝上之后發(fā)現(xiàn)手機(jī)變燙，每月流量猛增的問(wèn)題。開(kāi)篇前先講一個(gè)不恰當(dāng)?shù)亩巫訜釤嵘戆桑骸澳吵绦蛟惩瑫r(shí)攜帶某米手機(jī)和某星手機(jī)過(guò)機(jī)場(chǎng)安檢被抓了起來(lái)，被指懷疑其蓄意攜帶定時(shí)爆炸物”。
? ?技術(shù)背景：能耗問(wèn)題其實(shí)主要和App對(duì)CPU\GPU消耗使用率成一個(gè)比例關(guān)系的。我暫且總結(jié)為：電量消耗+流量消耗。其實(shí)這兩者也是互相牽制的。
? ?Ok，讓我們從代軟件開(kāi)發(fā)者的角度來(lái)深入剖析一下。
?電能消耗：
● 網(wǎng)絡(luò)請(qǐng)求耗電：按照系統(tǒng)層次原理，使用4G網(wǎng)絡(luò)遠(yuǎn)遠(yuǎn)比WIFI更耗電，因?yàn)槭謾C(jī)網(wǎng)絡(luò)需要調(diào)用更底層的硬件模塊。還有一點(diǎn)在網(wǎng)絡(luò)切換監(jiān)聽(tīng)廣播中代碼注意精簡(jiǎn)，去除耗時(shí)過(guò)重的操作。
● UI頁(yè)面嵌套太深、頻繁刷新：Layout繪制的過(guò)程是經(jīng)過(guò)一連串的計(jì)算最終渲染，如果開(kāi)發(fā)者在編寫(xiě)的UI中嵌套太深很容易造成卡頓的同時(shí)還造成了電能的過(guò)于消耗。具體如何解決，可以看下我之前的文章：Android 性能優(yōu)化系列－UI篇
● 頻繁的IO、數(shù)據(jù)庫(kù)操作：在短時(shí)間頻繁讀寫(xiě)會(huì)造成手機(jī)消耗大量電能。
● 定時(shí)任務(wù)：手機(jī)上的設(shè)置JOB非萬(wàn)不得已建議不要去嘗試。如定時(shí)拉服務(wù)器數(shù)據(jù)，即便你用 AlarmManager也是一樣，要不停的喚醒CPU執(zhí)行任務(wù)，造成電量消耗。
● 數(shù)據(jù)傳輸、解析：盡量不要用XML解析交互，使用Json、 Protobuf 。數(shù)據(jù)壓縮傳輸。避免頻繁的進(jìn)制轉(zhuǎn)換等等。
● 定位服務(wù)：GPS打開(kāi)后會(huì)不停的合理選擇定位服務(wù)的方式，可以使用wifi定位、移動(dòng)網(wǎng)絡(luò)定位來(lái)取代GPS定位。按照實(shí)際場(chǎng)景
●? WakeLock的不合理使用
● 對(duì)象回收：要記住手動(dòng)回收對(duì)象有百里無(wú)一害。
流量消耗：
● 還是網(wǎng)絡(luò)請(qǐng)求：請(qǐng)求頻次過(guò)多，盡量減少請(qǐng)求報(bào)文大小，返回報(bào)文包大小。包括合理的網(wǎng)絡(luò)請(qǐng)求緩存。
● 心跳包： 和服務(wù)端交互的定時(shí)心跳，盡量避免直接傳輸String。判斷當(dāng)前app是否在前臺(tái)來(lái)調(diào)節(jié)頻次。
● 拒絕輪詢(xún)調(diào)用服務(wù)端接口。
● 推送頻繁、內(nèi)容過(guò)大：合理采用推送渠道，用業(yè)務(wù)字段id取代內(nèi)容字符集。
● 文件下載：在確保大文件壓縮前提下，合理使用內(nèi)存、磁盤(pán)存儲(chǔ)，避免重復(fù)下載。
● 無(wú)視了用戶(hù)的網(wǎng)絡(luò)環(huán)境：在業(yè)務(wù)允許下盡量區(qū)分當(dāng)前是否是wifi狀態(tài)，合理走流量。
? ?????總結(jié)：個(gè)人覺(jué)得整體的優(yōu)化是一個(gè)協(xié)調(diào)復(fù)雜的過(guò)程，需要客戶(hù)端、服務(wù)端，當(dāng)然還會(huì)涉及到服務(wù)器的部署方式、產(chǎn)品的需求、業(yè)務(wù)運(yùn)維的方式等等。
未完待續(xù)。。。（如何檢查能耗及細(xì)節(jié)解決方案）
