《業務運維實戰：騰訊是怎么優化APP用戶體驗的？》要點：
本文介紹了業務運維實戰：騰訊是怎么優化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)

 

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4472.html