所謂『APM』，就是Application Performance Management的簡稱，我們利用這個系統(tǒng)來對應用的性能、可靠性進行線上的監(jiān)控和預警的一種機制。現(xiàn)在App的開發(fā)技術(shù)相對成熟，而提升App的使用體驗，就成了不同App之間的一個競爭點。
1、我們可以了解到線上App的實際使用情況，了解到App的奔潰、異常數(shù)據(jù)，從而針對潛在的風險問題進行預警，并進行相應的處理，例如發(fā)布補丁包、調(diào)整服務器策略等等。
2、了解App的真實使用信息，還有助于后端服務器了解客戶端使用情況，根據(jù)不同的策略進行服務端的架構(gòu)調(diào)整，同時有針對性的提高App使用體驗，提高用戶使用黏性。
APM實際上是一個比較大的工程，這里我們主要講解客戶端的實現(xiàn)，但僅僅是客戶端的實現(xiàn)，就已經(jīng)包含了很多我們需要去解決的問題，例如：混合編程對性能數(shù)據(jù)采集的影響，采集程序?qū)λ拗鰽pp的性能影響、侵入程度、可拓展性和可定制性等等，同時Android的碎片化和iOS的一些封閉性，造成了不同設(shè)備、不同平臺上的數(shù)據(jù)采集有很多的問題。
另外，APM系統(tǒng)對后端的要求也比較高，例如：數(shù)據(jù)的采集匯總，分析處理，如果App的用戶量比較大，對服務器的壓力也是一個比較大的問題，畢竟性能數(shù)據(jù)的量會比較大。
首先我們來看看『內(nèi)存』，內(nèi)存的重要性相信大家毋庸置疑，它是對App性能的一個綜合性反映，通常我們會考慮到『內(nèi)存峰值、內(nèi)存均值、內(nèi)存抖動、內(nèi)存泄漏』這樣幾個方面，這幾個考量維度綜合反映了App在對象操作、內(nèi)存使用是否合理、精簡內(nèi)存以及在內(nèi)存泄漏上的處理是否恰當。
在Android中，我們可以通過Runtime來獲取當前App所分配的內(nèi)存信息，這也是獲取實際內(nèi)存信息最準確的方法。另外，我們還可以借助『LeakCanary』來幫助我們分析內(nèi)存泄漏，將它集成到我們自己的APM系統(tǒng)中，獲取它的內(nèi)存泄漏信息。
『CPU』也是大家非常關(guān)心的一個方面，他主要影響了App的發(fā)熱和卡頓，我們主要通過『CPU峰值、CPU均值』來評判一個App對CPU的優(yōu)化程度，在Android中，我們可以通過讀取/proc目錄下的CPUInfo來獲取CPU的一些性能信息。
『啟動時間』是大家比較容易忽視的一個點，現(xiàn)在App接入的第三方SDK越來越多，大部分都需要在Application中進行初始化操作，這就會極大的拖慢啟動時間，這也是我們優(yōu)化的重點，關(guān)于App的啟動優(yōu)化，大家可以參考這篇文章http://blog.csdn.net/eclipsexys/article/details/53044990。
另外，啟動優(yōu)化也包括了頁面的啟動時間的考量，也就是頁面的渲染時間，在Android中，我們可以通過Choreographer和Activitylifecyclecallbacks來進行監(jiān)聽，同時，對于一些關(guān)鍵信息，通過使用AOP，我們可以獲取更加詳細的信息。
『UI性能』實際上在前一頁中已經(jīng)有所體現(xiàn)了，除了前面考量的頁面渲染性能外，我們對于『UI重繪、滾動幀率、頁面ANR』也要進行詳細的評測。這些東西，我們可以借助開發(fā)者選項中的相關(guān)內(nèi)容來進行測試。
『耗電量』實際上是App性能的一個上層表現(xiàn)，通過batteryhistorian我們可以在內(nèi)測階段，分析App的耗電異常，在線上，通過監(jiān)控App的使用和耗電，及時排除可能存在的異常。
『網(wǎng)絡性能』是一個App看不見的體驗，國內(nèi)網(wǎng)絡環(huán)境錯綜復雜，要面對各種流量劫持和各種不穩(wěn)定因素，所以，對于網(wǎng)絡接口性能，也是我們非常關(guān)注的點，例如『復雜網(wǎng)絡環(huán)境、接口往返時間、接口數(shù)據(jù)異常、CDN、服務器異?！贿@些都是我們需要考慮的。
那么為了保證在使用APM系統(tǒng)的時候，能夠降低接入的成本，所以這塊我們通過AOP方式來進行注入，避免大范圍的改動。
『用戶行為路徑』按道理來說并不算是APM的范疇，但是通過用戶行為路徑的分析，我們可以針對用戶訪問量大的內(nèi)容進行集中力量的優(yōu)化，有助于提高我們優(yōu)化的效率。
APM系統(tǒng)監(jiān)控的方式主要有兩種，在內(nèi)部測試階段，我們使用『PC端性能檢測，它不影響性能，無需侵入代碼，可測試競品，但是需連接ADB』，在線上階段，我們使用『客戶端性能檢測SDK，它不受設(shè)備限制、可進行場測，但對宿主App代碼有侵入、性能有一定影響』。
有了采集的性能數(shù)據(jù)，我們就可以對數(shù)據(jù)進行分析和展示了，對于這塊，后端其實有很多成熟的方案，很多類似的數(shù)據(jù)展示圖表控件，這里只舉幾個例子。
圖表～～
這是借助ELK平臺做的展示。ELK平臺是一個非常好的數(shù)據(jù)展示框架，詳細內(nèi)容大家可以參考這篇文章http://blog.csdn.net/eclipsexys/article/details/53364480。
前面我們了解了現(xiàn)有APM系統(tǒng)的一些內(nèi)容，當然，APM系統(tǒng)也是個與時俱進的系統(tǒng)，在現(xiàn)有的基礎(chǔ)內(nèi)容上，我們還能做很多事，例如『AI分析數(shù)據(jù)Pattern、本地異常數(shù)據(jù)監(jiān)控算法、異常數(shù)據(jù)預警機制、服務端指令控制』，這些也是我們后面的奮斗目標。
問答環(huán)節(jié)～
1、在省電節(jié)能方面，到底要怎么做
省電這一塊 主要是需要控制wakelock的使用?？刂茻o謂的CPU運行和計算 ?這些內(nèi)容都可以通過BatteryHistorion來進行查看
2、監(jiān)控會不會很費流量？
流量的話是一個考慮的因素，我們可以通過不同的策略來進行管理 比如 在WIFI情況下上傳。同時 使用pb等高壓縮協(xié)議來進行流量的優(yōu)化
3、現(xiàn)在不是都流行無埋點技術(shù)，這方面有什么不一樣
無痕埋點 ?主要是為了解決用戶行為數(shù)據(jù)和業(yè)務行為數(shù)據(jù) ?和性能不太一樣
4、在頻繁定位的情況下，如何達到省電節(jié)能呢
頻繁定位類的App 確實是耗電大戶，可以在非必須的情況下，采用緩存數(shù)據(jù)，或者通過簡化業(yè)務流程的情況下來進行優(yōu)化
5、做視頻下載那塊時，當用戶一次性選擇幾百個下載任務下載時，這時候界面會停留很久，等待添加下載任務的完成，請問這塊可以從哪些方面優(yōu)化？
一次幾百個下載，這種確實很難優(yōu)化，畢竟CPU是死的，有CPU運算，就會耗電，可以盡量將這些任務后臺化
6、如果有app申請wakelock不釋放，系統(tǒng)有什么好的應對策略么，如果我們自己就是系統(tǒng)的話，醫(yī)生大神會有什么好的建議讓系統(tǒng)怎么做呢
作為上層App，你只能控制自己的WakeLock ?其它App的耗電，交給系統(tǒng)去處理吧，大部分wakelock造成的問題 都是異常流程沒有考慮清楚導致的 。**作為系統(tǒng)開發(fā)者，可以給出提示，讓用戶來操作 或者Kill這些耗電進程
7、如果本地的應用產(chǎn)生bug崩潰了，這種要怎么監(jiān)控到呢？
本地的異常、崩潰信息，Android有專門的接口可以拿到 收集這些數(shù)據(jù)后上傳，用于分析。android提供了UncaughtExceptionHandler來幫助你處理崩潰
最后推薦一本書
性能優(yōu)化的具體代碼和操作分析方法《Android群英傳 神兵利器》
