先來看乙個瀏覽器使用者反饋。
如圖所示，在瀏覽器使用者反饋中，耗電一直是頭部問題之一，使用者對於電量是非常敏感的，特別是那種類似「我明明就沒用，怎麼還在耗電？」的後台耗電問題，更容易引起使用者的抱怨。
遇到這些情況，專案組和測試組都比較無奈。我們明明一直都有做耗電測試，本地的耗電監控也一直跑的很溜。但是線上仍然有這些問題，應該怎麼辦呢？
所以，我們需要一種新的耗電監控的方案，來解決線上使用者反饋的耗電問題。
對於線上使用者耗電的監控，我們需要解決兩個問題。
2、線上使用者數量龐大，不像本地測試才個位數的機器，這麼多使用者，手工分析太耗時，我們如何進行自動化分析？
先考察一下現有的耗電監控的方案：
測試方法一：batteryhistorian（
batteryhistorian報表
測試方法二：method profiling
針對常見的使用者場景，在瀏覽器切後台時通過ddms method profiling抓取後台執行的所有任務。method profiling一般是用來分析效能問題的，它會記錄每乙個執行緒、每乙個方法的耗時，也正是利用了這一點，我們可以清楚地看到瀏覽器在切後台後都做了哪些事情。
對比兩種方案, 最終我們選擇了基於後台method profiling方案，因為這個方案有兩個優點。
1、methodprofiling在使用者手機上容易執行, 呼叫乙個函式抓trace即可, 而battery historian需要執行shell命令。
2、methodprofiling有更加豐富的函式執行資訊, 而battery historian只能夠獲取一些系統事件。
線上監控別於本地測試，本地測試可以簡單粗暴,但在使用者的手機上，必須考慮方案對使用者的影響。method profiling生成的trace檔案相對來說是比較大的，最大可能有幾十兆，我們不可以把所有使用者的trace檔案都上報上來。
另外，監控本身可能導致耗電，例如我們首先排除的方案——用乙個例行執行緒不斷記錄當前所有執行緒，所以在設計方案時需要將監控本身的影響降到最低。
幾輪討論後，我們最終採用了這樣的思路——首先監控是否存在後台耗電現象，當判斷為後台耗電現象後開始method profiling並通過穿山甲上報。
這樣我們上報的都是經過篩選的有問題的場景，一方面減輕了後台資料儲存的壓力，另一方面也相當於做了過濾，減輕後台分析的工作量。
最終線上耗電監控的具體方案如下：
1、切後台時，記錄當前程序對cpu占用的時間片；
2、切後台一段時間後，再獲取程序對cpu占用的時間片，如果發現耗電異常，開始method profiling；
3、methodprofiling進行一段時間後停止，上報trace檔案到穿山甲後台；
4、穿山甲後台對上報的trace檔案進行分析和處理，並自動提bug單。
列印的第14~17個引數依次表示（單位：jiffies）：
114242 utime，任務在使用者態執行的時間
20692 stime，任務在核心態執行的時間
6 cutime，累計的任務的所有的waited-for程序曾經在使用者態執行的時間
2 cstime，累計的任務的所有的waited-for程序曾經在核心態執行的時間
jiffies是linux核心中代表時間的變數。系統中定義了乙個常數hz，代表每秒種最小時間間隔的數目，jiffies的單位就是1/hz。每個cpu時間片，jiffies都要加1。程序的cpu時間片占用就是使用者態+系統態的jiffies，程序占用的jiffies越大，對cpu的占用越多。
114242 + 20692+ 6 + 2 = 134942 (jiffies)
在瀏覽器切後台時，記錄當前程序占用的jiffies，當切後台達到設定時間後（10分鐘），再次獲取當前占用的jiffies，當兩次差值超過設定閥值時（400jiffies），判定為發生了後台耗電事件。閾值設定參考了手機廠商後台耗電的評判標準。
當判定後台耗電後，開始抓取trace，時長1分鐘，trace結束上報資料到後台。
正式版使用者數龐大，我們上報的trace檔案相對來說比較大，如果正式版做監控上報資料量會相當龐大, 目前資源無法支援。當存在耗電場景時，抽取一部分使用者應該也是可以監控到的，所以我們選取一部分內測版的使用者做監控和上報耗電異常。另外為了避免消耗使用者流量，我們只會在wifi環境下上報資料。
當存在耗電問題時，上報上來的trace檔案會比較多，我們不可能每乙個上報都做人工分析處理，所以需要乙個程式來進行自動化的分析。
對trace資料檔案的分析參考了traceview源**，主要是對metho profiling檔案格式的解析。從method profiling資料中我們可以得出當次上報有多少個執行緒在執行，每個執行緒裡都呼叫了哪些方法，以及每個方法的呼叫棧、耗時等。
有了方法的耗時, 呼叫棧等資訊, 是不是就可以確定問題了?
乙個耗時長的呼叫棧, 是不是就是耗電的元凶呢?
答案：並不是！
根據歷史經驗, 乙個孤立的呼叫棧, 就算它比較耗時,但很多時候並不是耗電問題的元凶. 真正的耗電原因, 常常是一些定時任務, 瀏覽器切後台以後本應該停止, 但這些任務還一直在執行, 導致耗電量大, 而這些呼叫棧, 具有下面一些特徵：
（1）多次被呼叫；
（2）呼叫具有規律性；
（3）呼叫比較耗時。
所以，我們從trace檔案中，對每個呼叫棧，分別計算下面3個指標。
1）呼叫次數，記為count；
2）呼叫時間間隔的方差, 記為diviation；
3）執行耗時, 記為cost。
針對每乙個呼叫棧, 我們給出乙個評分：
score = cost * count / diviation
分數越大的呼叫棧，越可能是耗電問題。同時，我們把類似的棧進行合併，上報次數越多的呼叫棧，影響面越廣。最終，我們根據排序，將top50的呼叫棧標記為疑似耗電問題，自動提交bug。
trace原始檔
最終bug資訊：
分析結果：
實施效果
以下是從引入線上電量監控以來的相關資料統計。
穿山甲廣告。swift穿山甲廣告40001報錯
第一步 初始化 穿山甲sdk if usermodel.shareinstance.user id 這個方法是 透傳引數 客戶端可以額外攜帶寫引數。但是如果不是必要的話 不建議設定哈。這個方法如果傳值，格式要求比較嚴格，不是簡單的字串。這個引數如果不是json序列化後的字串 也是會出現40001錯誤...
2018 穿山甲到底說了什麼 掘金年度徵文
不要吹滅你的靈感和你的想象力 不要成為你的模型的奴隸。文森特 梵谷 過去的這一年，還是有很多的心願沒有達成，我總是期待著在新的一年裡做點什麼，然後開始了對新一年無限的遐想，但是事實上，如果不能對之前的日子有足夠的反思，也許那些真的就只是遐想而已。文首引用的這句話可能看起來與主題毫無聯絡，但是如果你在...
谷歌上線情人節遊戲 穿山甲版《超級瑪麗》
今天是西方的情人節,谷歌照例推出了新的do程式設計客棧odle來為這個節日增添活躍氣氛。今年情人節doodle可謂是大製www.cppcns.com作,是一款講述穿山甲追愛旅程的web遊戲,共分為四關。遊戲的形式和操作方式都與 超級馬里奧 相似,需要收集可可豆rsuthfde製作的蛋糕www.cpp...