2015上海Qcon總結——Hybrid App監控與極限優化

• 2019 年 12 月 4 日
• 筆記

本文作者：IMWeb 劉恆兵 原文出處：IMWeb社區 未經同意，禁止轉載

感言

終於有時間停下來來回顧一下2015上海Qcon分享《Hybrid App極限優化解決方案》旅途。不喜歡總結，往往是比較痛苦的，些許時間之後回過頭來，發現部分細節已然模糊。不得已要求自己寫點什麼，哪怕隨便寫寫，給自己看也好，給其他人參考也好。總歸於相忘於歷史較好。

首先很感謝Qcon這個大平台，也感謝組織者@臧秀濤全程的鼎力幫助。特別感謝@郝培強老師的支持，有幸能和@羅昇陽、@ 趙世婚、@李躍輝、@胡文江（白衣）、@董一凡 幾位大牛一起分享《移動開發新趨勢》這個專題。

心路歷程

「一次收穫頗多的成長曆程」，用這句話概括，最適合不過了。至於聊到收穫，大致概括為：

• 人脈 ——又認識了很多新同學，都是在自己領域擅長的同學。在幾天的認識和交往中，一部分成了很好的朋友，在以後的技術然所之路上會有莫大的幫助。
• 技術——既然是一個技術盛會，免不了諸多的技術交流、探討。對之前未曾涉獵的一些領域都有了一些了解，算是門外漢入門吧。
• 分享——我是一個樂於分享的人，之前的一些分享，總歸沒有這一次聽眾多，除了線下的，線上分享，後期視頻觀看的人數，遠大多餘在場人數。對分享的技巧也是一個挑戰。這些很寶貴經驗，同時也是我後續努力提升的方向。
• 準備——所謂「兵馬未動，糧草先行」的道理在這次分享過程中，記憶猶新。相對而言，這次準備已是相對較長的時間了，可仍感不足，也激起了後續繼續分享的慾望。

PS:之前沒怎麼在上海停留，這次分享之餘，在上海停留一天。將以前沒有去過的地方走了一遭，也算是完成了長時間的夙願。

移動Web(HTML5)之殤

要提及分享主題，我們先從移動web(html5)說起(分享中口述帶過)。HTML5 是唯一兼容PC端、移動端( iOS、Android、WP)的跨平台語言。由此帶來諸多革命性的變革，低成本、低門檻、可復用、高效率，藉助HTML5技術，Hybrid混合模式也逐漸被認可(即能基本滿足native的豐富API、高體驗的要求，又能滿足Web高效率、快迭代的場景)。

似乎一切都很美好，但良辰兄表示不服。當我們以為我們的業務是這樣的時候

其實我們的業務大部分是這樣的

除了複雜的元素之外，還包含多資源（圖片、音視頻等）。

從上面的業務對比可以看到，隨着SPA的到來，業務複雜度不斷增加。而實際的開發過程中，我們也不斷的發現：

• 頁面打不開/打開慢
• 頁面菊花
• 操作卡頓
• 頁面展示錯誤
• 產品體驗不過關

這些問題，幾乎在所有移動端開發的場景都會遇到，針對這些問題，隨着經驗的積累，我們已然有一套行知有效的解決方案

• 資源加載
  • webview——提升webview初始化速度，提前處理網絡請求，並行，減少串行處理的情況
  • cache——通過瀏覽器緩存，減少網絡請求，加快網絡速度
  • 離線包機制——走客戶端CS通道，將web文件拉取下來，cache到本地，異步檢查更新，用戶直接使用本地文件，成功率可以提升到三個9
• 數據加載
  • Local化——針對頁面數據展示問題，通過LocalStorage數據以及客戶端Local的能力，將數據緩存到本地，頁面內（二次用戶）、頁面間的Local緩存，提升緩存命中率，使更多的用戶能夠通過Local數據緩存加快頁面的展示速度
• 體驗優化
  • 優化——頁面的體驗優化，通過前端的性能優化，渲染優化（GPU）等方案，提升移動性能
  • JS-SDK——客戶端提供的JS-SDK的能力，提升產品體驗，達到體驗要求

移動Web優化之道

優化，這個老生常談的問題，在很多場合，我們都會提到優化。重複的優化，造成了很多人力的浪費，而這些優化，我們嘗試去找到一些共性，嘗試找到統一的解決方案。

提到移動Web優化，一個頁面加載展示中間到底經歷了哪些流程？(What really happens when you navigate to a URL)

流程之下，我們才能針對性優化。在Hybrid模式下，多了一環(Webview的加載)，因此除了進行移動Web優化之外，就是減少webveiw的初始化時間。

在流程上，優化進一步細化之後，可以分為以下三個方面：

• 網絡優化——加載策略、優化請求、緩存優化
• 資源優化——Html、圖片、Js、Css
• 渲染優化——Dom、動畫、repaint/reflow

進一步細化：

到了這裡之後，似乎一切看起來有美好了。流程熟悉了，針對流程優化也有了標準，且具體到了每一項具體的優化點和規範。進而針對Hybrid App開發，也有了基於客戶端提供的Webview優化、離線包體系、JS-SDK等。看起來移動Web開發將無所不能。

其實並不然

移動Web監控體系

雖然有了優化方案，也有了優化細則。然，我們依然被用戶反饋所惱。Why？

細想之下，方案太過於普遍化，沒有具體到用戶的場景，舉個栗子：一個2G用戶反饋數據加載過慢，而你卻在拚命優化頁面渲染執行，其實效果不一定明顯，因為針對2G用戶而言，最重要的網絡時間，一個1kb的小文件，網絡所需的時間大概在10S左右（dns + tcp + rtt），及時頁面執行效率在高，也很難彌補網絡瓶頸所帶來的時間消耗。因此，優化第一步——Find The Bottlenecks(找到你頁面瓶頸)

透過監控窺方案

首先要完善我們的監控，需要有監控規範，我們監控的點需要囊括

以及對應的具體規範策略

在有視頻資源之下，監控還需要涵蓋視頻的監控

監控數據

有了監控，我們在回到我們的本質目的。通過監控，我們繼續舉一些栗子，來看一下監控體系下的數據與數據差異化。

• 2G VS WIFI

2G與WIFI的對比，9s vs 2s。即便是在同樣的網絡環境下，訪問次數的差別也是不一樣。正因為有如此大的差別，我們想辦法將資源本地化（離線包），減少資源網絡的時間。

• 離線包更新率

這裡以五個版本為例說明，離線包版本更新情況，從這裡也可以看到，離線包迭代3天內基本可以替換。但要基本完全覆蓋會在6天左右。當有某些大版本不兼容的時候，除了我們提前更新版本保證兼容之外，我們可以更好的知道我們的版本影響的用戶時間和範圍。而對於統計來講，我們只需要上報用戶，版本號，離線包的狀態就可以獲得這些信息。因是因為有這些完善的監控，我們才能針對我們的不同條件的監控數據給予不同的優化方案。

• 視頻數據

以直播為例，2G數據相當於4G數據3.4倍。而錄播更大，達到了5.4倍。可以看到，針對明顯的對比數據，我們就可以知道我們的優化方案：減少錄播資源片段。

方案策略

有了這些監控之後，我們在回到我們前面提到的一些問題，我們瓶頸在哪？不同的場景，所遇到的瓶頸不盡一致，這樣是我們之前說到的當我們做了很多優化之後，反饋依然。

不同的情況，選不同的方案；不同的場景，用不同的策略

業務實踐才是王道

優化體系，離不開三端：Web、Client、Server

具體的業務之中，Web優化重要的一環——資源優化。

Js資源優化之Badjs

前端上報數據到接入層，接入層badjs-acceptor，然後再通過推送中心(badjs-mq)將數據分發。

• 第三方接入系統，提供open api給第三方接入
• 數據存儲中心，採用mongodb存儲
• 到管理系統（統計、報表等）

通過系統，基於try catch機制(為什麼選擇try catch？參考Script error)，基本可以將我們的腳本錯誤控制在0.6%。

圖片資源優化之webp & iconfont

圖片的優化一般從兩個方面：請求數、大小。通過雪碧圖、base64等方案來減少圖片請求。提供不同壓縮的尺寸來減少圖片大小和默認拉取大小。

然而事事上，我們的圖片可以進一步優化為

在我們的應用場景以及我們的環境支持（主要是移動Android的支持）情況下，通過Webp可以將我們的終端提升近40%。

而在圖片的另一個方面，就是考慮將多個不同尺寸的同樣圖片歸納為一圖——矢量圖。矢量圖可以有svg 與 iconfont，然svg不支持ie8。

對於iconfont，首先得有個平台，其次得考慮上傳，然後使用下載，最後反饋平台。這是一個體系化的應用，基於構建工具以及平台之上的低開發、維護成本的應用。應用之後，整個業務資源節省92%。

http://iconfont.imweb.io，視覺、開發，通過這個平台大大減少了溝通成本以及維護成本，提升了開發效率。

Don't Repeat Yourself

拒絕重複的事情，在開發的過程中，我們不斷累積功能，隨着功能的增加，由模塊形成組件。當組件組件增加的時候，我們就希望有一個平台在維護這些組件，且最好是能和構建工具打通。這也是我們將要提到的lego平台。

對比現有的系統，其實我們不難發現，我們將我們好的一些優化方案和組件同步到現有的組件平台（bower、npm、browserify、compnont等），面問領的問題是，別人很難找到，而且我們自己要找一個組件也相對麻煩，招到組件之後也不一定能夠相信他和使用它，只能通過readme以及git的star數等做響應的參考，而在lego系統中，我們想要的目標是，能夠快速的找到發現可信任的組件，以及對組件完善的反饋改善體系，這就是lego平台的獨有部分，認證和反饋。

開發這通過開發和發佈組件，使用者Install來使用組件。從而保證組件最大範圍的復用。同時，支持內外網源以及組件權限認證能力，滿足局域網開發的需要。

通過支持組件復用的方式，補足移動端優化的需要，保證一次優化之後，可以在多處同場景下使用。

移動Web的未來

最後的最後，還是想拋磚引玉一下，移動的未來。針對移動優化，很多優化方案猶如雨後春筍般層出不窮（Lua、JS-PATCH、Semi Hybrid、React-Native等）。同時，我也堅信，移動的未來是要端結合。在開發方式不變下，尋求誇端的高度融合，去掉相對令人詬病的Webview、移動端http(s)協議下的數據加載。我們的移動未來將更廣闊

小結

移動話題源源不斷，移動優化也會經久不息。那麼在移動優化的時候，需要顧及場景、瓶頸。針對不同的場景，不同的瓶頸做不同的事情。專業的事，要留給專業的方案來解決。回到我們的主題，極限優化，什麼是極限優化？就是要細分場景優化，這樣才能俱到。要做到俱到，需要做到如下：

• 掌握加載的細分場景
• Find The Bottleneck(找到瓶頸)
• 規範是一切的基礎
• 方案比代碼更重要
• 透過數據窺方案

描述了很多，也講了很多，希望能夠給到大家一些幫助。也同時，給這個不喜歡總結的我，一個機會去細細回歸一下2015上海Qcon的內容，感謝那些能花時間閱讀至此的小夥伴，謝謝你們不厭其煩的看我長篇累贅的描述。我嘗試者精簡，竭盡所能之後，還是有這麼多。足可見此次Qcon分享的內容過於臃腫，導致分享過程語速過快，這裡也算是一種抱歉吧。把把分享的內容大致這麼一撲通的羅列出來，不加任何修辭和裝飾，能看到這裡的小夥伴，再次感謝。

最後ppt可以在這裡下載和閱讀，及關注我和在這裡討論Heron