mAPM，就看你的了！

標籤：style   blog   http   使用   資料   ar   2014   問題   

前些日子參加了Velocity大會，在大會上聽雲的張濤先生在國內第一次提出了mAPM（移動APM）的概念。筆者是一個由傳統營運工程師創業的移動開發人員，剛好對APM有所瞭解。本文將對國內外移動APM做一個簡單的介紹，希望大家喜歡。

在傳統企業裡，IT運營部門仍然在購買APM監控工具，但這部分市場對於大多數APM服務商而言都顯得太過單調。理由很簡單，目前市場上幾乎找不到針對移動App運營團隊所需要的APM解決方案。通常傳統企業的App都屬於非重點項目，通常由來自業務部門的開發人員或者應用程式支援小組負責運營管理。在多數傳統企業中，根本不具備部署第三方APM工具監測管理App的能力。而大多數移動開發企業又都屬於傳統企業轉型或初創企業（比如筆者），不是關注應用管理的意識不強，就是乾脆沒有預算來採購APM工具——有了問題直接讓研發人員跑日誌、看log，基本上還處於非常低端的形態。但是隨著整個移動市場爆發，業務模式已經出現了翻天覆地的變化，資料和使用者總量幾何級增長使應用監控需求也在快速增長，這也間接地帶動了APM行業發展。筆者預言：mAPM的時代來了！

 

換句話來說，新的mAPM方案要想從現有產品中脫穎而出就必須擁有明確的競爭力與吸引力，同時確保開發人員能夠參與到mAPM工具嵌入工作中來。目前，APM的SaaS化解決方案，已經可以實現事故管理與綜合性交易處理。這對App效能管理的可用性來說非常重要。

國外mAPM服務商的解決方案已經有很多了，Keynote Systems公司為此投入重資，逐步將自身從傳統APM轉型到mAPM。目前Keynote Systems的移動業務在其總營收中佔比已超過五成。如今他們已經能夠實現行動裝置類比，利用實際裝置在其POP內部執行測試工作。此外其它多家廠商也拿出了包括mAPM的綜合效能監控解決方案。國內最近也有一些公司在做mAPM業務，其中包括Velocity大會上首次提出mAPM概念的聽雲。

 

真正的mAPM代碼應該被嵌入到原生App當中，其代碼要做的除了從移動角度提供效能資料之外、還需要通過各種通道將其交付給基礎設施以及介面，比如網路、伺服器、第三方API，監測工具SDK要嵌入App中，其體量大小也直接影響App啟動並執行情況以及效能監測資料的準確性。

聽雲是國內首家mAPM方案提供者。通過應用內嵌入聽雲App SDK,同步真實使用者訪問體驗，及時發現使用過程中的崩潰、連線逾時、記憶體流失等問題。據筆者瞭解，聽雲是基調網路的SaaS化服務平台，針對移動App用戶端——網路——Server端的整體解決方案。經過筆者的測試，其mAPM設計思路非常清晰，SDK也只有10K左右，相比國外同類產品優勢也非常明顯。

除了聽雲，下面再介紹幾個國外的解決方案（需要梯子，使用極其麻煩）：

AppDynamics公司將推出一套混合型APM解決方案，其中包括由內部或者SaaS交付的mAPM產品。這樣的設計思路使該方案顯示出端到端完整形態、即由裝置到託管基礎設施的全面覆蓋。

Crittercism公司此前則打造過一款事故偵查工具，用於追蹤緊急問題及App啟動情況。他們如今開始從移動視角出發進行網路監控，並從更深層面剖析效能表現。Crittercism公司在這一新興市場上佔有一席之地，這主要是因為他們所使用的SDK目前已經被嵌入到了數百款原生行動裝置 App當中。

最近我還看到了New Relic發布的mAPM產品——與AppDynamics類似，他們也將移動效能與基礎設施及應用程式效能結合在了一起。New Relic公司只提供SaaS式解決方案。

經過對各產品對比，筆者發現各產品的價格定位經常發生變化，不過一般來講通常會以月活數作為依據。各解決方案的價格基本相當，相比較而言，本地化的聽雲平台優勢比較明顯，擁有永久免費的版本，聽雲的收費版本也不需要用外國信用卡支付，使用非常方便。

對於APM行業來講今年將是有趣的一年。作為一個由營運工程師轉行移動互連網的從業人員來說，眾多精彩紛呈的mAPM產品將接踵而至，所以請大家拭目以待。如果大家還有其它疑問，請與筆者進行反饋，期待能與各位進行深入交流。

原文連結：http://www.tingyun.com/news/125.html