去哪兒網快速App開發及問題解決平台實踐

內容來源：2017年5月6日，去哪兒網平台事業部客戶端技術總監張子天在「攜程技術沙龍——移動開發工程實踐與性能優化」進行《去哪兒網快速App開發及問題解決平台實踐》演講分享。

閱讀字數：2211 | 4分鐘閱讀

摘要

本次分享主要介紹去哪兒的客戶端團隊在大規模多團隊多APP的情景下，如何快速簡單可靠地維護自己的產品。

通過實際場景重現，介紹用戶行為跟蹤和網路數據交互的監控的相關內容，解決目前業界難以處理的方案如無埋點統計的收集與提取，網路監控的Hook方案及無線遠端測試等。

通過介紹去哪兒在解決產品和用戶問題的過程，介紹相關係統的使用和技術內幕，啟發大家在多前後端、跨團隊的場景如何更快的開發和維護APP，迅速定位解決問題。

大咖演講視頻

APP閃退

很多普通用戶在經歷APP閃退的時候，往往無法準確表述出APP出現的問題，最多只能告知我們機型或用戶賬號，以至於我們能了解到的信息非常少。

故障處理辦法

我們最需要知道的信息是用戶閃退的時間、閃退的具體頁面和閃退的原因。但這些信息用戶一般都不能提供，所以這時我們就只能到各個系統里查詢日誌、拉故障處理群，去「猜」故障的原因。

角色變化

因為在業務過程中整個工作團隊發生了很大的變化。最初遇到問題，幾個人討論一下基本就能解決；隨著業務發展日漸龐大，從單個團隊分成了多個團隊；再到後來，不同開發方式的出現導致每個人的職責和對APP的了解都非常片面，所以大家不能一目了然地知道問題出在哪兒。

頁面刷不出來

關於頁面刷不出來的問題，我們目前最新的做法是進行用戶的流程監控。

從圖中可以看見用戶具體進行了什麼操作、在什麼時間做了什麼事情。

我們稱之為「用戶細查」。

每個頁面還能打開它具體請求的情況，看到請求耗時、時間線，甚至可以打開每個請求看到介面請求的後台系統經過哪些環節。

現在可以通過用戶細查分析問題出現在哪個環節上，只需把對應環節的相關負責人召集到一起就能解決問題，不會像傳統辦法那樣耗時很長，還消耗大量人力。

這裡涉及到的技術細節就有以下幾種：

如何知道用戶的交互行為和渲染變化；

如何知道用戶的網路請求和時間線；

如何能還原用戶的場景；

怎樣才能不影響業務代碼的開發。

涉及到的系統——「筋斗雲」

QAV是交互統計，QACR是異常監控，QTrace是用於監控網路請求的整個流向。

交互行為和渲染變化

先從交互行為說起，首先要看監控的事件類型。事件類型分為APP生命周期事件、頁面切換事件和交互事件三種。

定位控制項在早年是用view-id的方式去做的，但這個方式非常的不靠譜，所以在那個年代經常會用手動埋點的方式進行操作。

後來有了坐標的方式，其實也沒有比view-id好很多，尤其是在Andriod上，會因為各種機型不同、屏幕尺寸不一樣而不準確。

在用了xpath一段時間后發現，它在Andriod上不夠穩定。體現在不同系統ROM里，它會對整個view數自行做一些廠商里定製的內容，甚至還有一些會自動增刪內容。

所以我們在xpath基礎上做了一些改進，對xpath基礎的頁面和布局的定義採用了自定義格式去做。

無論採取哪種方式，數據都會有變化，所以我們需要一個合併數據項。

各個平台xpath的樣式是不同的。

在業務的開發過程中不能讓它手動埋點，所以要採取Hook的方式。

Hook在不同平台上有不同的方式。在IOS上可以用Runtime去做，而在Andriod上則要採用不一樣的方式。

Andriod上其實也能用Runtime的方式做，但不是很好。因為它不是真正的運行期的Hook，它需要預插樁，對運行的效率會有影響。

所以運行期Hook使用的是InstantRun，在構建期Hook使用的是JavaAgent。

在IOS上注入代碼很簡單，在Andriod上就比較複雜了。

在構建過程中，Hook出構建的腳本，把所有預埋點加入Dex再打包，打完包的時候代碼已經在真正輸出的代碼Dex里了。

這裡分為三部分，一部分是Agent，一個是Gradle插件，以及真正要修改插入內容的部分。

插入內容部分就是網路部分的監控以及用戶行為上的監控，這些相對於Hook來說是業務層，所以我們把它叫做Dex。

Agent本身是用來做Hook。

再來看一下我們都Hook了哪些內容。最基礎的網路部分就是請求的時間、狀態，以及當前網路是Wifi還是4G。

注入幾個數據。

網路會根據不同的使用去注入不同的類型。因為一些歷史遺留問題或第三方問題，必須要採用到不同網路請求的框架。

在react-native里，會直接在react-native的框架層注入Hook的方案。

將各項數據聚合

如何併發串聯數據

我們會有一個綁定用戶行為與網路請求的id。每個用戶的交互行為都會生成一個id，下一次有網路數據的時候會把這個id帶上去，這樣哪個交互行為觸發了用戶請求，就能把它們關聯在一起。

Uuid用來做介面的調用棧的串聯。每經過一層都會加一個自己的標識，這樣就可以追蹤到整個網路調用棧的情況。

校正過的time排序是用來把前面所有的行為讓它以一個正確的順序排列在一起。

所有用戶日誌統一以客戶端本身的時間進行排序。

日誌上傳

我們會把交互日誌和網路請求日誌壓縮打包后再上傳。

崩潰或卡頓等異常日誌實時上傳。

這一套系統開發出來是為了滿足開發、測試、發布、監控這一個完整流程來做的，可以保證用最少的人力做最多的事。

冰山一角——綁定數據項

綁定數據項就是給控制項一個比較人性化的名字，可以由非工作人員來完成。綁定完之後可以在日誌行為中看到用戶操作。

這樣就極大減少了開發過程中對於統計類需求消耗的時間。也避免了網路日誌只有程序員看得懂的尷尬，可以讓它自主地進行操作。

冰山一角——崩潰聚合

我們發現外面主流做收集的廠商往往不能更完整地收集到所有需要的錯誤，我們是通過一整套的方式把它們收集在一起。

總結

我們是從數據、測試、發布、監控這幾個環節把所有事情打包在一起，提供給業務人員，給他們一個友善的開發環境。

我今天的分享就到這裡，謝謝大家！