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

內容來源：2017年5月6日，去哪兒網平臺事業部客戶端技術總監張子天在「攜程技術沙龍——移動開發工程實踐與性能優化」進行《去哪兒網快速App開發及問題解決平臺實踐》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。
閱讀字數：2211 | 4分鐘閱讀

摘要

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

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

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

嘉賓演講視頻和PPT地址

t.cn/RChIMfH

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排序是用來把前面全部的行爲讓它以一個正確的順序排列在一塊兒。

全部用戶日誌統一以客戶端自己的時間進行排序。

日誌上傳

咱們會把交互日誌和網絡請求日誌壓縮打包後再上傳。

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

這一套系統開發出來是爲了知足開發、測試、發佈、監控這一個完整流程來作的，能夠保證用最少的人力作最多的事。

冰山一角——綁定數據項

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

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

冰山一角——崩潰聚合

咱們發現外面主流作收集的廠商每每不能更完整地收集到全部須要的錯誤，咱們是經過一整套的方式把它們收集在一塊兒。

總結

咱們是從數據、測試、發佈、監控這幾個環節把全部事情打包在一塊兒，提供給業務人員，給他們一個友善的開發環境。

我今天的分享就到這裏，謝謝你們！

推薦文章

• 小米深度學習平臺架構與實現
  

• 支撐百度搜索引擎99.995%可靠名字服務架構設計
  

近期活動

• 直播+福利 | 當AI趕上大數據——ArchData技術峯會
  

• 資訊 | 聚焦2017中國FinTech大會