APM （Application Performance Management，即應(yīng)用性能管理，在分布式領(lǐng)域也稱為分布式跟蹤管理）對企業(yè)的應(yīng)用系統(tǒng)進(jìn)行實(shí)時監(jiān)控，它是用于實(shí)現(xiàn)對應(yīng)用程序性能管理和故障管理的系統(tǒng)化的解決方案。
建網(wǎng)站原本是網(wǎng)站策劃師、網(wǎng)絡(luò)程序員、網(wǎng)頁設(shè)計(jì)師等，應(yīng)用各種網(wǎng)絡(luò)程序開發(fā)技術(shù)和網(wǎng)頁設(shè)計(jì)技術(shù)配合操作的協(xié)同工作。創(chuàng)新互聯(lián)公司專業(yè)提供成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站,網(wǎng)頁設(shè)計(jì),網(wǎng)站制作(企業(yè)站、響應(yīng)式網(wǎng)站開發(fā)、電商門戶網(wǎng)站)等服務(wù),從網(wǎng)站深度策劃、搜索引擎友好度優(yōu)化到用戶體驗(yàn)的提升,我們力求做到極致!
隨著分布式系統(tǒng)和微服務(wù)架構(gòu)的應(yīng)用和發(fā)展，應(yīng)用性能管理成為系統(tǒng)運(yùn)維管理和網(wǎng)絡(luò)管理的一個重要方向，它能夠?qū)ζ髽I(yè)的關(guān)鍵業(yè)務(wù)應(yīng)用進(jìn)行監(jiān)測、優(yōu)化，提高企業(yè)應(yīng)用的可靠性和質(zhì)量，保證用戶得到良好的服務(wù)，降低IT總擁有成本(TCO)。應(yīng)用性能管理APM能夠?qū)φ麄€企業(yè)的IT系統(tǒng)各個層面進(jìn)行集中的性能監(jiān)控，并對有可能出現(xiàn)的性能問題進(jìn)行及時、準(zhǔn)確的分析和處理。它能輕松地從一個IT應(yīng)用系統(tǒng)中找到故障點(diǎn)，并提供有相關(guān)解決建議或方法，從而提高整體的系統(tǒng)性能。一個企業(yè)的關(guān)鍵業(yè)務(wù)應(yīng)用的性能強(qiáng)大，可以保證企業(yè)業(yè)務(wù)應(yīng)用系統(tǒng)的高效性和穩(wěn)定性，為企業(yè)帶來核心競爭力的提升。
當(dāng)下成熟的互聯(lián)網(wǎng)公司都建立有從基礎(chǔ)設(shè)施到應(yīng)用程序的全方位監(jiān)控系統(tǒng)，力求及時發(fā)現(xiàn)故障進(jìn)行處理并為優(yōu)化程序提供性能數(shù)據(jù)支持，降低整體運(yùn)維成本。國內(nèi)外商業(yè)的APM有Compuware、iMaster、博睿Bonree、聽云、New Relic、云智慧、OneAPM、AppDyn、Amics等。 本文主要針對Java技術(shù)體系介紹APM的框架、核心功能以及業(yè)界主流APM工具的功能特點(diǎn)。
隨著互聯(lián)網(wǎng)技術(shù)和應(yīng)用的快速發(fā)展，應(yīng)用程序本身變得越來越難以管理，因?yàn)樗鼈儚膯误w架構(gòu)轉(zhuǎn)向高度分布的、多層、多元素的分布式應(yīng)用架構(gòu)，應(yīng)用系統(tǒng)在許多情況下依賴于應(yīng)用程序的開發(fā)框架。APM概念框架旨在幫助企業(yè)優(yōu)先考慮在IT系統(tǒng)架構(gòu)中需要首先關(guān)注的方法，以便企業(yè)能夠快速實(shí)施并全面了解五維APM模型。
APM被形象的稱為應(yīng)用程序的私人醫(yī)生，越來越收到企業(yè)的青睞，比起通過日志方式記錄關(guān)鍵數(shù)據(jù)顯然要更加實(shí)用，APM主要包含如下核心功能：
基于Java體系的應(yīng)用程序運(yùn)行時的性能指標(biāo)可通過Java.lang.Runtime、java.lang.Management中的方法采集。除此之外，著名的Metrics類庫也能夠通過這些底層技術(shù)獲取Java程序性能指標(biāo)。CPU利用率、內(nèi)存利用率等基礎(chǔ)數(shù)據(jù)的采集僅僅是性能監(jiān)控的一部分，Metrics提供了更為豐富的五個基本度量類型，可在此基礎(chǔ)上開發(fā)滿足需求的監(jiān)控指標(biāo)。
大多數(shù)企業(yè)希望有一個功能完善的APM系統(tǒng)具有JVM性能監(jiān)控、服務(wù)調(diào)用追中、監(jiān)控告警功能，CAT、PinPoint、SkyWalking、Hawkular相對來講功能更為完備，推薦企業(yè)使用。
理論上是不行的，要想實(shí)時就必須連續(xù)不斷傳輸?shù)囊曨l信號，而你的軟件是播放視頻文件的，文件的話必須有頭尾，如果做成文件格式再播放，那就不叫實(shí)時監(jiān)控了。
1. 部署簡單
Go
編譯生成的是一個靜態(tài)可執(zhí)行文件，除了glibc外沒有其他外部依賴。這讓部署變得異常方便：目標(biāo)機(jī)器上只需要一個基礎(chǔ)的系統(tǒng)和必要的管理、監(jiān)控工具，完全不需要操心應(yīng)用所需的各種包、庫的依賴關(guān)系，大大減輕了維護(hù)的負(fù)擔(dān)。
2. 并發(fā)性好
Goroutine和channel使得編寫高并發(fā)的服務(wù)端軟件變得相當(dāng)容易，很多情況下完全不需要考慮鎖機(jī)制以及由此帶來的各種問題。單個Go應(yīng)用也能有效的利用多個CPU核，并行執(zhí)行的性能好。
3. 良好的語言設(shè)計(jì)
從學(xué)術(shù)的角度講Go語言其實(shí)非常平庸，不支持許多高級的語言特性;但從工程的角度講，Go的設(shè)計(jì)是非常優(yōu)秀的：規(guī)范足夠簡單靈活，有其他語言基礎(chǔ)的程序員都能迅速上手。更重要的是
Go 自帶完善的工具鏈，大大提高了團(tuán)隊(duì)協(xié)作的一致性。
4. 執(zhí)行性能好
雖然不如 C 和 Java，但相比于其他編程語言，其執(zhí)行性能還是很好的，適合編寫一些瓶頸業(yè)務(wù)，內(nèi)存占用也非常省。
Go語言由Google公司開發(fā)，并于2009年開源，相比Java/Python/C等語言，Go尤其擅長并發(fā)編程，性能堪比C語言，開發(fā)效率肩比Python，被譽(yù)為“21世紀(jì)的C語言”。
Go語言在云計(jì)算、大數(shù)據(jù)、微服務(wù)、高并發(fā)領(lǐng)域應(yīng)用應(yīng)用非常廣泛。BAT大廠正在把Go作為新項(xiàng)目開發(fā)的首選語言。
Go語言能干什么?
1、服務(wù)端開發(fā)：以前你使用C或者C++做的那些事情，用Go來做很合適，例如日志處理、文件系統(tǒng)、監(jiān)控系統(tǒng)等;
2、DevOps：運(yùn)維生態(tài)中的Docker、K8s、prometheus、grafana、open-falcon等都是使用Go語言開發(fā);
3、網(wǎng)絡(luò)編程：大量優(yōu)秀的Web框架如Echo、Gin、Iris、beego等，而且Go內(nèi)置的 net/http包十分的優(yōu)秀;
4、Paas云平臺領(lǐng)域：Kubernetes和Docker Swarm等;
5、分布式存儲領(lǐng)域：etcd、Groupcache、TiDB、Cockroachdb、Influxdb等;
6、區(qū)塊鏈領(lǐng)域：區(qū)塊鏈里面有兩個明星項(xiàng)目以太坊和fabric都使用Go語言;
7、容器虛擬化：大名鼎鼎的Docker就是使用Go語言實(shí)現(xiàn)的;
8、爬蟲及大數(shù)據(jù)：Go語言天生支持并發(fā)，所以十分適合編寫分布式爬蟲及大數(shù)據(jù)處理。
APM的意思有多種，如“每分鐘操作次數(shù)”、“高級電源管理”、“旅客自動捷運(yùn)系統(tǒng)”、“自動化精確生產(chǎn)”、“應(yīng)用性能管理”。
1、APM（每分鐘操作的次數(shù)）
APM，（英語：ActionsPerMinute）每分鐘操作的次數(shù)，又稱“手速”。該詞多見于星際爭霸和魔獸爭霸系列游戲中，在一定程度上反映了玩家的水平。在即時戰(zhàn)略游戲中，每分鐘操作數(shù)指的是每分鐘操作指令數(shù)，這一般包括鼠標(biāo)點(diǎn)擊和鍵盤敲擊。APM很好地反映了玩家的操作速度。
高APM通常還意味著良好的微操作——即在游戲中精心操控每一個單位使其作用達(dá)到最大化。最著名的星際爭霸APM測試軟件是BWChart。
2、APM（高級電源管理）
APM（英文AdvancedPowerManagement），高級電源管理，一種工業(yè)標(biāo)準(zhǔn)，它允許系統(tǒng)處理器和各個組件進(jìn)入省電模式，包括掛起、睡眠和關(guān)機(jī)。
3、APM（旅客自動捷運(yùn)系統(tǒng)）
APM，（英語：AutomatedPeopleMoversystems）中文名為自動旅客捷運(yùn)系統(tǒng)，該系統(tǒng)也稱為自動導(dǎo)軌快捷運(yùn)輸系統(tǒng)(AGTS)，是一種無人自動駕駛、立體交叉的大眾運(yùn)輸系統(tǒng)。
旅客捷運(yùn)系統(tǒng)并不是一種獨(dú)立及特殊的鐵路運(yùn)輸技術(shù)，通常都會應(yīng)用到多種鐵路運(yùn)輸技術(shù)。2010年11月8日，廣州市地下鐵道總公司宣布，中國大陸第二條無人駕駛APM（自動旅客捷運(yùn)系統(tǒng)）廣州地鐵APM線11月8日通車試運(yùn)營。
4、APM（自動化精確生產(chǎn)）
APM（英語AutomatedPreciseManufacture），自動化精確生產(chǎn)，AMD采用的一種高效的、基于合作伙伴的研發(fā)模式，確保它的產(chǎn)品和解決方案可以始終在性能和功率方面保持領(lǐng)先。
5、APM（應(yīng)用性能管理）
應(yīng)用性能管理（英語：ApplicationPerformanceManagement），是一個比較新的網(wǎng)絡(luò)管理方向，主要指對企業(yè)的關(guān)鍵業(yè)務(wù)應(yīng)用進(jìn)行監(jiān)測、優(yōu)化，提高企業(yè)應(yīng)用的可靠性和質(zhì)量，保證用戶得到良好的服務(wù)，降低IT總擁有成本(TCO)。
使用全業(yè)務(wù)鏈的敏捷APM監(jiān)控，可使一個企業(yè)的關(guān)鍵業(yè)務(wù)應(yīng)用的性能更強(qiáng)大，可以提高競爭力，并取得商業(yè)成功，因此，加強(qiáng)應(yīng)用性能管理（APM）可以產(chǎn)生巨大商業(yè)利益。
參考資料來源：百度百科-APM（每分鐘操作的次數(shù)）
參考資料來源：百度百科-APM（高級電源管理）
參考資料來源：百度百科-APM（旅客自動捷運(yùn)系統(tǒng)）
參考資料來源：百度百科-APM（自動化精確生產(chǎn)）
參考資料來源：百度百科-APM（應(yīng)用性能管理）
Github 鏈接 Collie
如何衡量一個APP性能好壞？直觀感受就是：啟動快、流暢、不閃退、耗電少等感官指標(biāo)，反應(yīng)到技術(shù)層面包裝下就是：FPS（幀率）、界面渲染速度、Crash率、網(wǎng)絡(luò)、CPU使用率、電量損耗速度等，一般挑其中幾個關(guān)鍵指標(biāo)作為APP質(zhì)量的標(biāo)尺。目前也有多種開源APM監(jiān)控方案，但大部分偏向離線檢測，對于線上監(jiān)測而言顯得太重，可能會適得其反，方案簡單對比如下：
還有其他多種APM檢測工具，功能復(fù)雜多樣，但其實(shí)很多指標(biāo)并不是特別重要，實(shí)現(xiàn)越復(fù)雜，線上風(fēng)險越大，因此，并不建議直接使用。而且，分析多家APP的實(shí)現(xiàn)原理，其核心思路基本相同，且門檻也并不是特別高，建議自研一套，在靈活性、安全性上更有保障，更容易做到輕量級。本文主旨就是 圍繞幾個關(guān)鍵指標(biāo) ：FPS、內(nèi)存（內(nèi)存泄漏）、界面啟動、流量等，實(shí)現(xiàn) 輕量級 的線上監(jiān)測。
Crash統(tǒng)計(jì)與聚合有比較通用的策略，比如Firebase、Bugly等，不在本文討論范圍
每個APP的網(wǎng)絡(luò)請求一般都存在統(tǒng)一的Hook點(diǎn)，門檻很低，且各家請求協(xié)議與SDK有別，很難實(shí)現(xiàn)統(tǒng)一的網(wǎng)絡(luò)請求監(jiān)測，其次，想要真正定位網(wǎng)絡(luò)請求問題，可能牽扯整個請求的鏈路，更適合做一套網(wǎng)絡(luò)全鏈路監(jiān)控APM，也不在討論范圍。
線上監(jiān)測的重點(diǎn)就聚焦后面幾個，下面逐個拆解如何實(shí)現(xiàn)。
直觀上說界面啟動就是：從點(diǎn)擊一個圖標(biāo)到看到下一個界面首幀，如果這個過程耗時較長，用戶會會感受到頓挫，影響體驗(yàn)。從場景上說，啟動耗時間簡單分兩種：
本文粒度較粗，主要聚焦Activity，這里有個比較核心的時機(jī)：Activity首幀可見點(diǎn)，這個點(diǎn)究竟在什么時候？經(jīng)分析測試發(fā)現(xiàn)，不同版本表現(xiàn)不一，在Android 10 之前這個點(diǎn)與onWindowFocusChanged回調(diào)點(diǎn)基本吻合，在Android 10 之后，系統(tǒng)做了優(yōu)化，將首幀可見的時機(jī)提前到onWindowFocusChanged之前，可以簡單看做onResume（或者onAttachedToWindow）之后，對于一開始點(diǎn)擊icon的點(diǎn)，可以約等于APP進(jìn)程啟動的點(diǎn)，拿到了上面兩個時間點(diǎn)，就可以得到冷啟動耗時。
APP進(jìn)程啟動的點(diǎn)可以通過加載一個空的ContentProvider來記錄，因?yàn)镃ontentProvider的加載時機(jī)比較靠前，早于Application的onCreate之前，相對更準(zhǔn)確一點(diǎn)，很多SDK的初始也采用這種方式，實(shí)現(xiàn)如下：
這樣就得到了冷啟動的開始時間，如何得到第一個Activity界面可見的時間呢？大概回執(zhí)流程如下
網(wǎng)上有一些認(rèn)為可以監(jiān)聽onAttachedToWindow或者OnWindowFocusChange，onAttachedToWindow的問題是可能太過靠前，還沒有Draw, OnWindowFocusChange的缺點(diǎn)可能是太過滯后。其實(shí)可以簡單認(rèn)為在view draw以后，View的繪制就算完成，雖然到展示還可能相差一個VSYNC等待圖層合成，但是對于性能監(jiān)測的評定，誤差一個固定值可以接受：
在onResume函數(shù)中插入一條消息可以嗎，理論上來說，太過靠前，這條消息在執(zhí)行的時候，還沒Draw，因?yàn)檎埱骎SYNC的同步柵欄是在是在Onresume結(jié)束后才插入的，無法攔截之前的Message，但是由于VSYNC可能存在復(fù)用，Onresume中插入的消息也有可能會在繪制之后執(zhí)行，這個不是完全一定的，比如點(diǎn)擊MaterialButton啟動一個Activity，第二個Activity的setView觸發(fā)的VSYNC就可能復(fù)用MaterialButton的波紋觸發(fā)的VSYNC，從而導(dǎo)致第二個Activity的performTraval復(fù)用第一個VSYNC執(zhí)行，從而發(fā)生在onResume插入消息之前，如下
綜上所述， 將指標(biāo)定義在第一次View的Draw執(zhí)行可能比較靠譜 。具體可以再DecorView上插入一個透明View，監(jiān)聽器onDraw回調(diào)即可，如果覺得不夠優(yōu)雅，就退一步，監(jiān)聽OnWindowFocusChange的回調(diào)，也勉強(qiáng)可以接受, OnWindowFocusChange一定是在Draw之后的。如此就可以檢測到冷啟動耗時。APP啟動后，各Activity啟動耗時計(jì)算邏輯類似，首幀可見點(diǎn)沿用上面方案即可，不過這里還缺少上一個界面暫停的點(diǎn)，經(jīng)分析測試，錨在上一個Actiivty pause的時候比較合理，因此Activity啟動耗時定義如下：
同樣為了減輕對業(yè)務(wù)入侵，也依賴registerActivityLifecycleCallbacks來實(shí)現(xiàn)：補(bǔ)全上方缺失
到這里就獲取了兩個比較關(guān)鍵的啟動耗時，不過，時機(jī)使用中可能存在各種異常場景：比如閃屏頁在onCreate或者onResume中調(diào)用了finish跳轉(zhuǎn)首頁，對于這種場景就需要額外處理，比如在onCreate中調(diào)用了finish，onResume可能不會被調(diào)用，這個時候就要在 onCreate之后進(jìn)行統(tǒng)計(jì)，同時利用用Activity.isFinishing()標(biāo)識這種場景，其次，啟動耗時對于不同配置也是不一樣的，不能用絕對時間衡量，只能橫向?qū)Ρ?，簡單線上效果如下：
FPS是圖像領(lǐng)域中的定義，指畫面每秒傳輸幀數(shù)，每秒幀數(shù)越多，顯示的動作就越流暢。FPS可以作為衡量流暢度的一個指標(biāo)，但是，從各廠商的報告來看，僅用FPS來衡量是否流暢并不科學(xué)。電影或視頻的FPS并不高，30的FPS即可滿足人眼需求，穩(wěn)定在30FPS的動畫，并不會讓人感到卡頓，但如果FPS 很不穩(wěn)定的話，就很容易感知到卡頓，注意，這里有個詞叫 穩(wěn)定 。舉個 極端 例子：前500ms刷新了59幀，后500ms只繪制一幀，即使達(dá)到了60FPS，仍會感知卡頓，這里就突出 穩(wěn)定 的重要性。不過FPS也并不是完全沒用，可以用其上限定義流暢，用其下限可以定義卡頓，對于中間階段的感知，F(xiàn)PS無能為力，如下示意：
上面那個是極端例子，Android 系統(tǒng)中，VSYNC會杜絕16ms內(nèi)刷新兩次，那么在中間的情況下怎么定義流暢？比如，F(xiàn)PS降低到50會卡嗎？答案是不一定。50的FPS如果是均分到各個節(jié)點(diǎn)，用戶是感知不到掉幀的，但，如果丟失的10幀全部在一次繪制點(diǎn)，那就能明顯感知卡頓，這個時候， 瞬時幀率 的意義更大，如下
Matrix給的卡頓標(biāo)準(zhǔn)：
總之，相比1s平均FPS，瞬時掉幀程度的嚴(yán)重性更能反應(yīng)界面流暢程度，因此FPS監(jiān)測的重點(diǎn)是偵測瞬時掉幀程度。
在應(yīng)用中，F(xiàn)PS對動畫及列表意義較大， 監(jiān)測開始的時機(jī) 放在界面啟動并展示第一幀之后，這樣就能跟啟動完美銜接起來，
偵測停止的時機(jī)也比較簡單在onActivityPaused：界面失去焦點(diǎn)，無法與用戶交互的時候
如何偵測瞬時FPS？有兩種常用方式
360的實(shí)現(xiàn)依賴Choreographer VSYNC回調(diào)，具體實(shí)現(xiàn)如下：循環(huán)添加Choreographer.FrameCallback
這種監(jiān)聽有個問題就是，監(jiān)聽過于頻繁，因?yàn)樵跓o需界面刷新的時候Choreographer.FrameCallback還是不斷循環(huán)執(zhí)行，浪費(fèi)CPU資源，對線上運(yùn)行采集并不友好，相比之下BlockCanary的監(jiān)聽單個Message執(zhí)行要友善的多，而且同樣能夠涵蓋UI繪制耗時、兩幀之間的耗時，額外執(zhí)行負(fù)擔(dān)較低，也是本文采取的策略，核心實(shí)現(xiàn)參照Matrix：
為Looper設(shè)置一個LooperPrinter，根據(jù)回傳信息頭區(qū)分消息執(zhí)行開始于結(jié)束，計(jì)算Message耗時：原理如下
自定義LooperPrinter如下：
利用回調(diào)參數(shù)""與""的 區(qū)別即可診斷出Message執(zhí)行耗時，從而確定是否導(dǎo)致掉幀。以上實(shí)現(xiàn)針對所有UI Message，原則上UI線程所有的消息都應(yīng)該保持輕量級，任何消息超時都應(yīng)當(dāng)算作異常行為，所以，直接拿來做掉幀監(jiān)測沒特大問題的。但是，有些特殊情況可能對FPS計(jì)算有一些誤判，比如，在touch時間里往UI線程塞了很多消息，單條一般不會影響滾動，但多條聚合可能會帶來影響，如果沒跳消息執(zhí)行時間很短，這種方式就可能統(tǒng)計(jì)不到，當(dāng)然這種業(yè)務(wù)的寫法本身就存在問題，所以先不考慮這種場景。
Choreographer有個方法addCallbackLocked，通過這個方法添加的任務(wù)會被加入到VSYNC回調(diào)，會跟Input、動畫、UI繪制一起執(zhí)行，因此可以用來作為鑒別是否是UI重繪的Message，看看是不是重繪或者觸摸事件導(dǎo)致的卡頓掉幀。Choreographer源碼如下：
該方法不為外部可見，因此需要通過反射獲取，
然后在每次執(zhí)行結(jié)束后，重新將callback添加回Choreographer的Queue，監(jiān)聽下一次UI繪制。
這樣就能檢測到每次Message執(zhí)行的時間，它可以直接用來計(jì)算 瞬時幀率 ，
瞬時掉幀小于2次可以認(rèn)為沒有發(fā)生抖動，如果出現(xiàn)了單個Message執(zhí)行過長，可認(rèn)為發(fā)生了掉幀，流暢度與瞬時幀率監(jiān)測大概就是這樣。不過，同啟動耗時類似，不同配置結(jié)果不同，不能用絕對時間衡量，只能橫向?qū)Ρ?，簡單線上效果如下：
內(nèi)存泄露有個比較出名的庫LeakCanary，實(shí)現(xiàn)原理也比較清晰，就是利用弱引用+ReferenceQueue，其實(shí)只用弱引用也可以做，ReferenceQueue只是個輔助作用，LeakCanary除了泄露檢測還有個堆棧Dump的功能，雖然很好，但是這個功能并不適合線上，而且，只要能監(jiān)聽到Activity泄露，本地分析原因是比較快的，沒必要將堆棧Dump出來。因此，本文只實(shí)現(xiàn)Activity泄露監(jiān)測能力，不在線上分析原因。而且，參考LeakCanary，改用一個WeakHashMap實(shí)現(xiàn)上述功能，不在主動暴露ReferenceQueue這個對象。WeakHashMap最大的特點(diǎn)是其key對象被自動弱引用，可以被回收，利用這個特點(diǎn)，用其key監(jiān)聽Activity回收就能達(dá)到泄露監(jiān)測的目的。核心實(shí)現(xiàn)如下：
線上選擇監(jiān)測沒必要實(shí)時，將其延后到APP進(jìn)入后臺的時候，在APP進(jìn)入后臺之后主動觸發(fā)一次GC，然后延時10s，進(jìn)行檢查，之所以延時10s，是因?yàn)镚C不是同步的，為了讓GC操作能夠順利執(zhí)行完，這里選擇10s后檢查。在檢查前分配一個4M的大內(nèi)存塊，再次確保GC執(zhí)行，之后就可以根據(jù)WeakHashMap的特性，查找有多少Activity還保留在其中，這些Activity就是泄露Activity。
內(nèi)存檢測比較簡單，弄清幾個關(guān)鍵的指標(biāo)就行，這些指標(biāo)都能通過 Debug.MemoryInfo獲取
這里關(guān)心三個就行，
一般而言total是大于nativ+dalvik的，因?yàn)樗斯蚕韮?nèi)存，理論上我們只關(guān)心native跟dalvik就行，以上就是關(guān)于內(nèi)存的監(jiān)測能力，不過內(nèi)存泄露不是100%正確，暴露明顯問題即可，效果如下：
流量監(jiān)測的實(shí)現(xiàn)相對簡單，利用系統(tǒng)提供的TrafficStats.getUidRxBytes方法，配合Actvity生命周期，即可獲取每個Activity的流量消耗。具體做法：在Activity start的時候記錄起點(diǎn)，在pause的時候累加，最后在Destroyed的時候統(tǒng)計(jì)整個Activity的流量消耗，如果想要做到Fragment維度，就要具體業(yè)務(wù)具體分析了，簡單實(shí)現(xiàn)如下
Android電量狀態(tài)能通過一下方法實(shí)時獲取，只是對于分析來說有點(diǎn)麻煩，需要根據(jù)不同手機(jī)、不同配置做聚合，單處采集很簡單
不過并不能獲取絕對電量，只能看百分比，因?yàn)閷蝹€Activity來做電量監(jiān)測并不靠譜，往往都是0，可以在APP推到后臺后，對真?zhèn)€在線時長的電池消耗做監(jiān)測，這個可能還能看出一些電量變化。
沒想好怎么弄，顯不出力
APP端只是完成的數(shù)據(jù)的采集，數(shù)據(jù)的整合及根系還是要依賴后臺數(shù)據(jù)分析，根據(jù)不同配置，不同場景才能制定一套比較合理的基線，而且，這種 基線肯定不是絕對 的，只能是相對的，這套基線將來可以作為頁面性能評估標(biāo)準(zhǔn)，對Android而言，挺難，機(jī)型太多。
GITHUB鏈接 Collie
重慶分公司
重慶分公司
