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