內容來源：2017年5月6日，去哪兒網平臺事業部客戶端技術總監張子天在“攜程技術沙龍——移動開發工程實踐與效能優化”進行《去哪兒網快速App開發及問題解決平臺實踐》演講分享。IT大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：2211 | 4分鐘閱讀
摘要
本次分享主要介紹去哪兒的客戶端團隊在大規模多團隊多APP的情景下，如何快速簡單可靠地維護自己的產品。
通過實際場景重現，介紹使用者行為跟蹤和網路資料互動的監控的相關內容，解決目前業界難以處理的方案如無埋點統計的收集與提取，網路監控的Hook方案及無線遠端測試等。
通過介紹去哪兒在解決產品和使用者問題的過程，介紹相關係統的使用和技術內幕，啟發大家在多前後端、跨團隊的場景如何更快的開發和維護APP，迅速定位解決問題。
嘉賓演講視訊和PPT地址
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排序是用來把前面所有的行為讓它以一個正確的順序排列在一起。
所有使用者日誌統一以客戶端本身的時間進行排序。
日誌上傳
我們會把互動日誌和網路請求日誌壓縮打包後再上傳。
崩潰或卡頓等異常日誌實時上傳。
這一套系統開發出來是為了滿足開發、測試、釋出、監控這一個完整流程來做的，可以保證用最少的人力做最多的事。
冰山一角——繫結資料項
繫結資料項就是給控制元件一個比較人性化的名字，可以由非工作人員來完成。繫結完之後可以在日誌行為中看到使用者操作。
這樣就極大減少了開發過程中對於統計類需求消耗的時間。也避免了網路日誌只有程式設計師看得懂的尷尬，可以讓它自主地進行操作。
冰山一角——崩潰聚合
我們發現外面主流做收集的廠商往往不能更完整地收集到所有需要的錯誤，我們是通過一整套的方式把它們收集在一起。
總結
我們是從資料、測試、釋出、監控這幾個環節把所有事情打包在一起，提供給業務人員，給他們一個友善的開發環境。
我今天的分享就到這裡，謝謝大家！
推薦文章
近期活動