手機管理應用研究【6】——省電管理篇

標籤：省電   耗電排行   電池   cpu調頻   充電   

歡迎轉載，轉載請註明：http://blog.csdn.net/zhgxhuaa

說明

本篇將介紹省電管理篇，主要介紹一下Android的耗電情況和目前市面上《電池助手》類應用涉及到的一些技術點。本篇將對這些知識點做一下總結和分析。主要包括：

A.       電池資訊（耗電排行）

B.       省電管理

C.       剩餘可用時間估算等

耗電分析
手機耗電分析

以My Phone（小米2S）為例，首先來看一下My Phone的電池使用方式，如（在設定->電量中查看）：

在手機中應用的耗電情況可以從硬體和軟體兩個層面分別去衡量。

在硬體層面主要是：

A.       螢幕（一般來說，螢幕尺寸越大、解析度越高，單位時間耗電也就越多）

B.       CPU（一般來說，CPU啟動並執行核心數越多，主頻越高，單位時間耗電越多）

C.       基帶（一般來說，Wifi耗電比無線要少，網路好的情況耗電比網路差的情況耗電要少）

在軟體層面主要是：

A.       應用運行（普通情況下的應用運行是正常認為行為，是合理的，但應用內過多的推送、通知等會導致額外耗電）

B.       後台常駐Service（消耗系統資源、可能會時不時被喚醒）

C.       長串連（佔用基帶、為了維持串連會定時喚醒系統）

所以，接下來看一下省電助手中都針對性的做了哪些工作，下面是金山電池醫生的：

電池充電方式

接下來結合上面的第一幅圖定義一下幾個名詞：

n  快速充電：(0%  ~ 80% )這個階段中，電池能夠快速的充到總電量的80%，但仍需要進行連續式充電才能完成充滿。（電流較強，速度較快）

n  連續充電：( 80%~100%)在電池即將充滿的狀態下，充電電流會逐漸減小，確保電池完成充滿。(電流減弱，放緩慢充）

n  涓流充電：(100%~100%)電池充滿後進行微小的脈衝電流充電，能讓電子保持流動，延長電池使用壽命，但不至於過充。(活躍電子，壽命更長）

下面是一張手機電池充電過程的：

這裡可參見：

http://www.apple.com/cn/batteries/iphone.html

http://www.apple.com/cn/batteries/

http://www.apple.com/cn/iphone/battery.html

關於這三種充電方式的一個比較（C為電池容量）：

關於涓流充電

“快速充電”和”連續充電“都比較容易理解，這裡簡單說一下”涓流充電”。那為什麼要進行”涓流充電”呢？其實主要是基於如下兩個方面的考慮：

A.       在電池充電過程中發生的一些效率上的損失，用來彌補電池在充滿電後由於自放電而造成的容量損失。

B.       電池充滿後進行小電流充電，能讓電子保持流動，延長電池使用壽命。

涓流充電過程一般占充電過程20%左右的時間，百度百科上說這個階段通常需要30-40分鐘。

關於“涓流充電”是否真的有必要，在網上有很多爭論。據蘋果官方和金山電池醫生的測試，還是有一定的用處的。本文就介紹到這裡，感興趣的同學可以自行查閱相關資料，這裡不再過多介紹。

 

本小節的一些參考：

http://wenku.baidu.com/view/44709e1da76e58fafab0038e.html

http://wenku.baidu.com/view/c0882e15a2161479171128b8.html

http://baike.baidu.com/view/206627.htm

http://baike.baidu.com/view/10022.htm

省電管理
可以從那些點來做

結合第一節中隊耗電情況的分析，我們在省電管理方面有那些工作可以做呢？

n  從硬體層面：

A.       螢幕：螢幕亮度、螢幕逾時

B.       CPU：CPU頻率、睡眠模式

C.       基帶：Wifi、藍芽、3G網路、同步、GPS

n  從軟體層面：

A.       後台進程限制（可參考系統”設定->開發人員選項->後台進程限制”）

B.       設定不保留活動（使用者離開後即銷毀每個活動，參見”設定->開發人員選項->設定不保留活動”）

C.       通過禁止開機自啟動、後台自啟動殺死後台常駐進程和清理記憶體。

D.       通過進程清理殺死後台進程並清理記憶體（鎖屏清理、定時清理）

E.        對長串連採用對齊喚醒策略（綠色守護和小米V5）

F.        限制喚醒鎖。

n  其他：

A.       關閉震動

B.       關閉觸感（觸摸時震動、觸摸提示音）

C.       適當調節系統音量

D.       系統動畫

下面是電池助手中實現的功能：

可以看出，目前流行的電池助手應用中，也是按照我們前面的思路實現的。

技術實現
螢幕控制

螢幕相關的可以直接調用系統SettingsProvider來設定，具體設定項為：

n  螢幕逾時：Settings.System.SCREEN_OFF_TIMEOUT

n  自動調整螢幕亮度：Settings.System.SCREEN_BRIGHTNESS_MODE；

其取值為：SCREEN_BRIGHTNESS_MODE_MANUAL = 0和SCREEN_BRIGHTNESS_MODE_AUTOMATIC= 1

n  螢幕亮度：Settings.System.SCREEN_BRIGHTNESS

CPU頻率控制

CPU的頻率控制主要涉及到三個方面：

n  CPU工作核心數

通過/sys/devices/system/cpu[id]/cpu1/online

n  CPU模式

通過/sys/devices/system/cpu/cpu[id]/cpufreq/scaling_governor

n  CPU頻率

所支援的頻率：/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

當前核心的頻率：/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

最大工作頻率：/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

最小工作頻率：/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

這裡有這麼幾點需要注意：

A.       並不是所有的CPU都可以控制工作核心數的，這取決於CPU的類型，一般來說採用非對稱式多處理的CPU是可以控制的，反之採用對稱式多處理技術（SMP）的CPU是不能控制的。

B.       上述對CPU的控制需要root許可權。

C.       CPU限制頻率等是需要root許可權來實現的。

CPU調節模式

CPU和IO調節模式。不同調節模式對應的效能提升、省電效果不一樣

CPU調節模式

?  ondemand（按需模式）

 

顧名思義，按需調節cpu頻率，不操作手機的時候控制在最低頻率，滑屏或進入應用後會迅速提升至最高頻率，當空閑時迅速降低頻率，效能較穩定，但因頻率變化幅度過大，省電方面只有一般的水平。

 

?  powersave（省電模式）

 

按設定最低頻率運行，最省電也最龜速，日常沒有使用價值，除非配合setcpu情景模式，關屏睡眠時使用此調節模式。

 

?  performance（高效能模式）

 

和省電模式相反，始終按設定最高菜譜頻率運行，最耗電也最剛猛！此模式亦無任何日常使用價值，果斷pass。

 

?  userspace（使用者隔離模式）

 

嚴格來說它並不是一個模式，是允許非核心進程式控制制cpu頻率的設定，現在已經不需要它了，setcpu官方的建議是，“不要使用此選項”。

 

?  conservative（保守模式）

 

和ondemand模式的調頻設定類似，不過有操作時提升cpu頻率的速度較慢，空閑時迅速降頻，所以名字叫保守模式，效能較低，省電程度略好於ondemand，隨著CPU負荷加大，頻率逐級上升，在CPU閑時頻率逐級下降，因此這個設定相對於ondemand模式省電，但變頻不夠順滑，所以會有卡頓現象。總體不推薦

interactive（互動模式）

 

相對於保守模式，這個模式算是高效能版的ondemand，開始操作手機後，頻率升至最高，可以帶來更好的響應速度，空閑時緩慢降至設定最低頻率。電量自然也是要多費一點。

 

關於CPU調節模式的設定可以參見：

 

/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

I/O調節模式

（什麼是I/O調節模式？i/o即input/output的縮寫，關於資料的讀寫操作，不同進程請求資料的優先順序等等。io調度模式比較複雜，這裡僅介紹常用的幾個模式，部分參考xda、androidforums、wik1pedia、linuxarchive資料）

 

?  noop

 

這個調度模式會把所有的資料請求直接合并到一個簡單的隊列裡。不適合有機械結構的儲存空間，因為沒有最佳化順序，會增加額外的尋道時間。屬於最簡單的一個調度模式，無視io操作優先順序和複雜性，執行完一個再執行一個，如果讀寫操作繁多的話，就會造成效率降低。

 

?  anticipatory

 

其實這個有點類似於pc硬碟的NCQ功能，執行有預測性的調度，看起來似乎可以提高效率，不過因為它的預測機制會在進程將要結束一個讀寫操作時時開始準備下一個的預先處理，所以會打亂系統正常的連續io調度，降低隨機存取效率。用的人很少，不推薦。

 

?  deadline

 

顧名思義，用到期時間來排序io操作順序，保證先出現的io請求有最短的延遲時間，相對於寫操作，給讀操作更優先的層級。是比較好的一個調度模式。

 

?  cfq

完全公平隊列，是anticipatory模式的替代品，沒有過多的做預測性調度，而是根據給定的進程io優先順序，直接來分配操作的順序。這個模式在linux上表現良好，但也許並不是最適合android的io調度模式，太強調均衡，而降低了連續讀寫資料的效能。

 

?  vr

 

具有和deadline相似的操作排序機制，有著最高的峰值讀寫速度，但是效能比較不穩定，也就是說可能跑出最高的分數，但是也會出現最低值。

 

?  sio

 

雖然基於deadline，但是它和noop一樣，不會對io操作進行排序，所以有著noop那樣快速的存取速度，但並沒有過多最佳化io操作。如果不喜歡noop完全不參與調度，也可以選擇這個。

 

關於I/O Scheduler的設定可以參見：

 

/sys/block/{DEVICE-NAME}/queue/scheduler

講到I/O Scheduler，就不得不同時提一下各類“跑分”軟體。

 

目前比較流行的跑分軟體是Quadrant象限以及超級兔子評測。而前者的測試結果可謂非常不準確，但大多數人仍然將這個軟體的測試成績作為衡量Android裝置效能的標準。

 

鑒於目前各個Android手機，其CPU效能基本不會出現太大波動（超頻除外，設定了不恰當的CPU Governor除外），因此影響這個軟體最終成績的，主要是I/O測試以及圖形測試。

 

剛剛說過，Android是有讀寫緩衝機制的。而部分ROM/核心修改者，為了讓自己修改的ROM或核心的效能看上去很NB，吸引更多人使用，故意針對Quadrant測試做了手腳，將Android磁碟緩衝設定得較大，讓分數更高。理論上來說，使用更大記憶體作為磁碟讀寫緩衝確實可以提升I/O效能，但這樣也會造成資料丟失的風險進一步增加，如果在配上noop、sio這樣沒有讀寫優先順序調整的I/O Scheduler，則資料很可能始終無法被真正寫入到NAND快閃記憶體中。

 

因此，在此代表廣大Android使用者，強烈鄙視這部分ROM/核心修改者（大部分是國內的，特別是大家經常聽說或提到的“X”大，“X”神等）。技術不如人不可怕，使用損人利己的手段達到目的就相當無恥了。

 

而超級兔子評測的準確度相對來說要高不少，特別是其針對I/O部分的測試，測試結果與PC上的CrystalDiskMark等軟體差距不大。

 

這一段參考自：http://bbs.gfan.com/android-3588731-1-1.html

網路控制

在電池助手中網路控制主要指控制3G資料、WIFI、藍芽等的開關，這些系統都有介面提供，直接使用即可。

對於針對軟體的一些控制措施很多都已經在手機加速等介紹過，這裡只提供一個思路，不做詳細介紹了。

軟體層控制

前面幾小節主要介紹了從螢幕、CPU和網路這些硬體層面的省電控制措施，本小節將簡單介紹一下從系統和軟體的層面有哪些工作可以做。

A.       控制待機功能（待機模式下關掉不必要的外設，一般平台的待機功耗可以控制在3-5ma）。

B.       手機鎖屏時，清理不必要的應用。

C.       架構層中控制partial型wakelock鎖的使用。

D.       控制系統層RTC Alarm 喚醒系統的頻率。

E.        定時模式切換等。

電池資訊
擷取電池基本資料

擷取電池的基本資料，可以通過監聽廣播android.intent.action.BATTERY_CHANGED實現，具體的實現代碼可以參考：

@/package/app/Settings/src/com/android/settings/BatteryInfo.java

擷取耗電排行資訊

在Android系統設定中有應用和子系統耗電排行的統計，可以作為我們在實現電池助手軟體時的參考，相關代碼可以參考目錄：@/package/app/Settings/src/com/android/settings/fuelguage/。

電池相關統計資訊是由類BatteryStatsImpl服務實現的，擷取BatteryStatsImpl的方式如下：

那是不是我們就可以使用BatteryStatsImpl來擷取耗電排行資訊了呢？實際上是不行的，原因如下：

1)        使用BatteryStatsImpl所需要許可權："android.permission.BATTERY_STATS"，而系統對其做了限制 ，非系統應用是無法使用BatteryStatsImpl的。

2)        在通過eclipse開發應用時，是無法飲用com.android.internal這個包內的類的，原因是adt對其做了排除。要想使用可參見http://mogoweb.net/archives/87。

估算電池充電時間

關於電池的充放電，電池的廠商一般都會有一個充放電的計算模型。也就是不同廠商的電池產品充放電的曲線是會有差異的。不同的電池技術之前充放電曲線可能會差異較大（如鎳鎘電池與鋰電池），同種技術的電池不同廠商之間差別不會太大。

下面是我從網上找到的一段估算電池充電耗時的計算模型，由於對電池相關技術並不是特別瞭解，所以這裡我也無法確定是否完全可靠，只作為參考吧。

 

1、充電電流小於等於電池容量的5％時：充電時間（小時）＝電池容量（mAH）×1.6÷充電電流(mA)

2、充電電流大於電池容量的5％，小於等於10％時： 充電時間（小時）＝電池容量（mAH）×1.5÷充電電流(mA)

3、充電電流大於電池容量的10％，小於等於15％時： 充電時間（小時）＝電池容量（mAH）×1.3÷充電電流(mA

4、充電電流大於電池容量的15％，小於等於20％時 充電時間（小時）＝電池容量（mAH）×1.2÷充電電流(mA)

5、充電電流大於電池容量的20％時： 充電時間（小時）＝電池容量（mAH）×1.1÷充電電流(mA)

 

參考：http://wenku.baidu.com/view/c0882e15a2161479171128b8.html

 

這裡簡單介紹一下在上面的模型中為什麼電池容量（mAH）後面都會有一個大於1的係數：其實這裡這裡大於1的部分就是電池充電過程中的損耗。

估算電池續航時間

簡單電池續航時間計算模型：電池續航時間 =電池容量 / 電池放電電流。實際上電池的續航還會受溫度和電池使用時間、放電時的電量等因素的影響。在放電時電流越大，就會導致溫度越高，發熱消耗越大；隨著電池充放電次數的增加，電池的容量會不斷的衰減。所以，在實際中電池的放電並不是一個簡單的線性關係，而是一條比較複雜的曲線。下面是一般鋰電池的典型放電曲線圖：

在電池管理軟體中隊電池續航時間的估算，往往分為兩種：

A.       總體續航（在正常使用時的續航時間）

B.       特定情境續航（比如可以看視頻多長時間、3G通話多長時間、上網多長時間）

無論哪種方式我們在估算續航時間時所需要的資料都是一樣的，即：電池電量和電流消耗情況。Android中對於電流的消耗情況是在檔案@/frameworks/base/core/res/res/xml/power_profile.xml中定義的，下面是一個片段：

 

@/frameworks/base/core/res/res/xml/power_profile.xml

這些資訊可以通過@/frameworks/base/core/java/com/android/internel/os/PowerProfile.java來擷取。

好了，有關省電的相關內容就先介紹這些了，歡迎交流討論。