業務運維實戰：騰訊是怎麼優化APP使用者體驗的？
作者簡介：
黃偉俊（henry）
騰訊高階運維工程師，多年研發與運維工作經驗。專注（移動端+服務端）效能管理，大資料分析領域的探索與實踐。
引言
當前，使用者體驗已成為一種新的產品價值。當技術實現不再是產品核心競爭力時，產品的競爭就是使用者體驗的競爭。而使用者彈指間感知到的效能體驗對於使用者體驗尤為重要。
移動網際網路產品因為使用者的手機型號繁多、手機作業系統版本不一致、app版本難統一等問題，很難在開發或測試環節就完全解決掉移動app的效能問題，這使得移動app產品在運維過程中，不得不面對使用者體驗不優、效能不佳的問題。
如何讓開發可以高效定位效能問題？
讓開發，測試，運維清晰的把控各個產品的效能狀況？
我們結合了當前業界商用的APM技術，實現了一套騰訊社交運維的myAPM方案。
myAPM是什麼？
APM（Application Performance Management）應用效能管理，它是一套集終端，網路，服務端效能管理於一體的監控方案。在這裡，就不展開介紹了。
myAPM，專注於移動端的效能管理。既能監控定位效能問題（卡慢），也能應用於日常的app效能運營分析，提升產品使用者體驗。
監控方式
myAPM採用BCI注入方式，實現業務方法粒度監聽。
在注入技術選型時，myAPM採用了類ASM的注入技術，其注入效率，校錯能力，學習成本，都比ASM要好一些。
注入階段
myAPM實現效能監控與功能開發零耦合。在編譯階段注入監控能力,對開發零感知。
myAPM特點：
- 實現方法粒度的自動化注入監控；
- myAPM採用外掛化設計：各個特性功能可自由組合，以滿足開發者定製化需求。
myAPM可以做什麼？
當前，我們利用myAPM的能力，主要從以下四個方面進行探索與實踐：
一、Apk 包大小分析
二、App卡慢監控分析
三、App啟動效能分析
四、App 核心鏈路效能分析
一、Apk 包大小分析
一個app，隨著新功能的持續增加，其apk的大小也在不斷地膨脹。Apk size的問題，越來越困擾和限制著開發同學，影響某些功能的上線，同時，也降低了使用者體驗。
同時，app運營時間越長，功能迭代 / 程式碼重構次數越多，“垃圾”程式碼（就是沒有被實際呼叫過的程式碼）的數量就會越多。
由於程式碼量大，程式碼呼叫層次深，每個開發同學只負責部分功能開發。如果讓開發同學人工去做全域性“垃圾程式碼”的分析，顯然，其難度很大，效率不高。
而myAPM的apk包大小分析，就是用來幫助開發同學，快速暴露這些“垃圾程式碼”，開發同學只須集中精力，針對梳理出來的問題程式碼，做進一步確認和清理即可。
1、Apk包大小分析原理
- myAPM會在類或方法中，注入一個唯一ID；
- 內測環境部署，通過大量的自動化用例，過濾掉有呼叫關係程式碼；
- 對未呼叫程式碼，進行重新注入，灰度外網，收集線上真實使用者的行為。通過內網測試，可以過濾掉部分常用程式碼，從而減少因注入增加的app包量。
- 通過長時間、大使用者量的資料運營，我們即可定位出無實際呼叫的程式碼。開發小夥伴即可集中精力在這些問題方法的確認及清理。
2、Apk包大小分析應用場景
- 定位完全無呼叫或被引用的類；（粒度粗，清理方便）
- 定位孤島方法：即沒有主調和被調的方法（粒度細，清理全面）
- 定位無呼叫的方法鏈路；
3、Apk包大小分析特點
- 結合線下模擬測試行為大資料分析
- 結合線上使用者實際行為大資料分析
- 效能消耗小
- 自動注入
4、開源工具 & apk包分析
可能有同學，會羅列出一系列開源的工具，也可以很方便地甄別出app這種無呼叫程式碼。但對於有呼叫關係的一條鏈路（一組方法），僅僅通過線下分析，無法判斷其是否有被呼叫。我們只能利用線上大量使用者的真實行為分析，更好地去判斷和確認。
5、方法注入樣例
通過一個唯一ID（14236）來上報，既避免了程式碼中敏感資訊的洩漏風險，同時，也大大節省上報量。
6、Qzone –android應用例項
Qzone android app，針對業務程式碼以及第三方包程式碼，採用類無呼叫分析。（類中所有變數或方法，沒有被引用或呼叫。）
內部測試階段：
在內部測試中，由於機型，測試用例有限，分析結果是42%的類沒有呼叫或引用。
灰度外網階段：
在灰度外網使用者後發現，所有類都被呼叫或引用。但40%類被呼叫次數少於10次。由於灰度使用者是50W，即40%的程式碼只有萬分之二的使用者有呼叫。針對這些，後續我們可以分析，調整這些類的啟動載入順序（如：延時載入）。
結論：
- 當前QQ空間 APP，不存在多餘無呼叫類檔案。
- 後續，在監控粒度上，我們會從“類方法”進行深層面的挖掘分析。
二、App卡慢分析
在app使用者體驗上，除了crash故障外，相信app主執行緒卡慢（負責與使用者互動的執行緒），是使用者最不能忍受的。
我們這裡所說的卡慢分析，是指對app主執行緒程式碼的卡慢監控分析。
1、工作原理
myAPM卡慢監控，實現對目的碼的“方法粒度”的注入、卡慢監聽。
其本質，是在目標方法呼叫的前後，注入時間，進行卡慢監聽及分析。原理圖，如下：
2、卡慢分析全流程
- app編譯時，注入 : 跟上面“apk包大小分析”的注入階段一樣：在class編譯後，實現監控邏輯注入。
注入時，我們會根據當前注入方法的“主調方法-被調方法”方法對，生成ID。同樣，也是用於資訊加密及節省上報量。
- app卡慢監控 : app版本上線後，myAPM會監控目標方法線上執行耗時，出現卡慢，則觸發卡慢方法上層全鏈路上報，同時上報app當前基本軟硬體CPU等使用率等環境資訊。
- myAPM後臺，會根據app上報的一組ID，進行鏈路還原。開發同學，可以針對卡慢方法，以及上層鏈路進行效能分析；
說明：
myAPM上報的卡慢鏈路，還原了業務方法執行呼叫的過程。是一種輕量級的堆疊/快照。其好處是避免列印堆疊的效能消耗。因為，在卡慢監控中，最消耗效能的就是列印堆疊。
- 收集堆疊，輔助分析 : 若某些卡慢方法，通過卡慢鏈路沒法分析定位出問題，可以將指定方法推送到指定使用者app上，收集線上使用者指定卡慢方法再次出現時，對應的堆疊資訊，用於輔助開發同學的分析定位。
3、卡慢例項
在主執行緒卡慢監控中，比較常見的案例是：主執行緒載入檔案，底層DB讀寫，圖片處理這些比較耗時的操作。我們優化的方案，通常是將這些耗時操作移到非同步執行緒中進行處理。
以下是四個案例片斷：
例項一:
主執行緒進行DB查詢導致卡慢。
平均耗時檢視：
myAPM後臺，會先統計卡慢鏈路的次數，計算鏈路中每個節點的平均耗時。
卡慢鏈路最後的兩組數值含義：(程式碼呼叫行號)， [方法平均耗時]。耗時單位為ms。
明細檢視：
在明細檢視中，我們會列出所有卡慢例項，以及使用者基礎環境資訊。
卡慢鏈路最後的兩組數值含義：(程式碼呼叫行號)， [方法耗時]。耗時單位為ms。
例項二：
主執行緒中載入dex檔案引起的卡慢例項。
例項三：
在主執行緒中，載入本地xml檔案導致卡慢。
例項四：
在主執行緒中，圖片處理耗時比較大。
Process()方法消耗了1.3秒，setFacadeImage()，也另外消耗了1秒。
4、myAPM卡慢監控的優勢
- 監控粒度： myAPM卡慢監控的粒度為方法。
- 效能消耗： myAPM卡慢方案，採用卡慢業務鏈路上報，是一種輕量級的業務堆疊，避免直接使用原生堆疊。避免了打堆疊的效能消耗。(列印原生堆疊：1-3ms，列印業務鏈路：0.1-0.3ms)。
- 資料上報： 採用了的一組鏈路ID。而非堆疊資訊。上報量小，不用加解密過程。
- 程式碼依賴： 卡慢邏輯與業務程式碼完全解耦，對開發者透明，零感知。只是在測試，釋出前注入。
5、不足及方案
myAPM，也存在不足。由於採用注入方式，會使apk的包，稍微變大。
以qzone android apk注入進行全量業務程式碼時，其apk大小增長0.5M，增長率為2.79%.
方案：
- 若使用者對apk大小比較敏感，可以採用部分注入分析。
- 可以配合myAPM的apk包大小分析方案，做apk瘦身分析。
myAPM新特性
app卡慢只是用於問題方法的效能優化。其實，對於一個產品，我們不但要關注及處理卡慢的問題，還需要關注app應用常規的效能狀況與監控。
因為，這個效能波動，不會像卡慢那麼明顯。但是在一次次新版本迭代中，可以會讓總體效能變慢。
1、監聽app啟動效能
- 我們可以將卡慢監控範圍進行定製縮小，提供個性化功能：只監聽啟動方法。
- 通過資料分析及比對，我們可以知道：
app每個版本的啟動效能及變化；
接入的各個產品在啟動效能上的差異，讓各個產品間可以相互借鑑與提升。
2、核心鏈路分析
無論是產品，開發，測試與運維，都會想知道：
一個APP中，哪些程式碼是屬於核心鏈路？
這些核心鏈路的效能怎樣？
每個新版本中，這些核心鏈路的效能是否受到明顯的損耗？
我們可以繼續將卡慢上報範圍擴大，上報全量方法。通過資料分析及篩選，我們可以挖掘出核心鏈路及其效能資料；
3、延時載入
通過鏈路特性分析，我們也可以抽取出呼叫次數很少，非主場景呼叫的程式碼。對於這些程式碼，在app啟動載入時，我們可以使用延時載入。從而提升APP的啟動效率。
續集說明
對於App 啟動效能分析以及App 核心鏈路效能分析，我們將在後續做單獨的介紹。
最後
myAPM，是我們結合部門實際需求和APM理念，在移動端效能管理的一個新探索，新實踐。不僅面向效能問題的定位，也應用於日常的app效能運營分析。
簡單分享myAPM在移動效能管理方面的一點思考及應用，希望大家打造好自己移動端的效能小船，關鍵時刻，不會說翻就翻。共勉！
文：黃偉俊（henry）
原文出處：高效運維(greatops）