Android 工程師眼裏的大前端：GMTC 2018 參會總結

本文由玉剛說寫做平臺提供寫做贊助

原做者：兩位低調的 Android 高手

版權聲明：本文版權歸微信公衆號玉剛說全部，未經許可，不得以任何形式轉載

概述

2018年的GMTC大會於6月22號在北京剛剛拉下帷幕，GMTC會議是由極客邦科技和InfoQ中國主辦的頂級技術盛會，主要涉獵前端、移動端、終端AI等多個技術領域，從16年到目前總共舉辦了3屆，從今年的火爆程度也能看出GMTC全球大前端開發者技術大會算是大前端的最重要的垂直會議之一了。

有幸參加了這屆GMTC大會，會議的14個專場基本覆蓋了大前端的方方面面，滿滿的日程對於體力也是消耗很是大，不過也收穫頗多，除了可以瞭解到各大公司面臨的技術難題與解決思路，還能瞭解到當前最前沿的技術熱點與將來方向。趁熱打鐵談談我的的一些收穫與感想，此次會議的專題包括Android新技術專場、iOS新技術專場、Node專場、Web框架專場、UI與動畫、PWA專場、終端AI、工程化、跨平臺專場、性能優化與監控等14個專題。因爲專題比較多，多個專題都是並行演講，分身乏術，這裏主要聊聊我的比較關心的2個專題。

1）Android新技術專場

2）性能優化與監控專場

Android新技術專場

新技術表明着當前的技術熱點與將來方向，做爲一個大前端的RD，不得不時刻關注着大前端技術的方向。Android新技術專場主要有三個主題分享，分別是《Android 研發的昨天今天明天》、《當插件化趕上Android P》與《快應用開發與實現指南》。

《Android 研發的昨天、今天、明天》

做者具備豐富的軟件研發經驗，推進了App組件化、動態部署、熱補丁等技術的發展和制定相關的機制，改善了Android設備的體驗，包括綠色聯盟(Greenify)應用公約、Android6.0-Doze&App Standby/Android7.0-部分限制靜態廣播註冊/Android8.0-全面限制靜態廣播註冊和後臺服務等。

首先，做者認爲Android發展的昨天是屬於一種流量圈地的時代，起初由簡單的WebApp的流量入口，到最後大多數都轉到NativeApp的入口；由於流量是互聯網的基礎概念，有了流量，有了用戶，纔有更加深刻的轉換，因此說流量是關鍵的第一步，所以昨天屬於搶佔流量入口的時代。

其次，做者認爲Android發展的今天是流量攻守的時代，隨着各大應用功能愈來愈複雜，規模愈來愈大，得到了流量的入口，那麼就須要攻守兼備，對於攻採用從大型應用到免安裝應用的過分，例如像PWA、Google Play Instant、小程序等，對於守採用啓動圖標+推送的方式，例如Shortcut、Contextual Push、Rich Notification等。

最後，做者認爲Android發展的明天是心智滲透的時代，須要針對不一樣的羣體塑造差別化的認知。做者認爲將到來的根本性變動是移動互聯網的範式轉移和移動應用的技術棧躍遷。

總結，做者認爲從技術層面簡單來講：昨天是從Web到Native，今天是跨平臺，明天是跨終端。

《當插件化趕上Android P》

首先，做者介紹了Android P的時間表，今天3月谷歌發佈了Android P的預覽版，預計今年Q3會發布最終的release版本；Android P中發佈了禁令：禁止調用非SDK的接口，各類訪問非SDK接口的方式都會產生錯誤或者其餘不但願的後果，若是下表中詳細說明了各類訪問方式及相應的結果。

針對上述的後果，對於開發者來講是至關糟糕了，幸虧在Android P中有三個名單來幫助開發者進行相關工做，具體以下表所示。

其次，做者介紹了實現插件化的黑科技，主要包括Hook App運行時的一些關鍵點，經過反射將插件的dex加入到BaseDexClassLoader中的pathList中，資源加載這塊經過反射調用AssertManager中的addAssertPaths方法加載插件中的資源，以下圖所示。

再次，做者介紹了下爲何京東業務要實現插件化，以及他們業務的需求和將來的方向：

做者對插件化、Android App Bundles、組件化和前端進行了對比：

最後，做者針對京東的插件化框架Aura，進行了升級，原來單純的插件化框架升級後由插件化和組件化共同組成Aura Plus。京東重構後的架構圖以下，包括了業務組件和業務插件兩部分。

《快應用開發與實現指南》

快應用是九大手機廠商基於硬件平臺共同推出的新型應用生態，用戶無需下載安裝，即點即用，享受原生應用的性能體驗。 首先，做者用2段小視頻展現了快應用的使用場景和多場景融入的一個示例。快應用與H5均由腳手架生成項目，做者進行了對比和分析，以下圖。

項目腳手架的整個工程結構以下圖所示。

經過簡單的例子展現了靜態頁面的編寫和佈局的調整。

其次，做者講解了下開發過程當中的模板渲染、事件響應、整個頁面的生命週期、組件化的使用和導入和動畫的使用等，經過一段視頻展現了快應用開發過程當中debug調試的使用方式。以上主要是快應用開發過程當中須要掌握的一些基礎知識，做者進行了詳細的介紹。做者聊了下快應用的整個架構思路，主要包括編譯時和運行時兩部分，編譯時由輸入的html+style+script、ux頁面等轉爲json+js、js頁面和rpk壓縮文件，運行時由編譯時的產物生成DOM樹、UI頁面和最終的應用程序。

快應用編譯時的主要架構以下圖，能夠看到從下層到上層主要包括：hap-toolkit工具->腳手架+編譯器+調試器+服務器->模塊化+數據模塊等->ux頁面文件+其餘類型文件->手機運行平臺：

快應用運行時的主要架構爲：

快應用JS層的架構爲：

快應用樣式計算引擎爲：

快應用頁面渲染結構爲：

最後做者總結了下整個快應用的架構：數據驅動+DOM模型+應用管理。

性能優化與監控專場

尤爲是這兩年，性能優化與監控方向愈來愈受到各大公司的重視，從現場的火爆程度也能反應出來，一整個下午的演講，會場坐滿了人，還有很多是直接坐在地上的，講臺邊的，甚至門口還有一大波實在是擠不進來了在門外聽的。性能優化與監控專場主要有4個主題的分享，對於這4個主題的最終目標是一致的，所用手段不盡相同，可是總體思路差很少，限於篇幅的關係，這裏主要分享一下《LinkedIn移動應用的性能優化之道》。

《LinkedIn移動應用的性能優化之道》

首先介紹了爲何要作性能優化，做者的觀點是用戶第一，接着展現了當前LinkedIn註冊用戶超5億，20多個業務線，團隊開發人員200多人，代碼行數累積400萬；而後做者引出性能問題每每是項目規模太大引發的，所以認爲合理的架構設計能夠將問題化繁爲簡，要解決好性能問題，首先就須要好的架構設計；以下圖所示，項目組件化應該算是任何項目架構變動的必經之路，將不一樣的模塊分離出來，拆成獨立的組件，能夠獨立的運行。

其次，做者介紹了合理的架構下也要有一個針對性能的監控方案，做者認爲線上性能監控主要包括：發現問題、分析問題、解決問題和驗證效果四大模塊。Crash率、業務異常屬於一個App是否可用的重要指標；啓動時間和包大小做爲App的基礎性能；頁面FPS、頁面渲染度是頁面流暢性的重要指標；CUP使用率、內存佔用狀況以及流量消耗等是資源消耗監控的關鍵點。 下圖是監控的地方和監控的鏈路，做者提到他們會在關鍵鏈路中的每一個地方都會打點，從網絡初始化，到網絡握手，到發送第一個字節，接收到第一個字節，以及數據的解析，到UI的展現，都進行了打點計時，爲此作了一個專用的網絡庫。

在數據採集方面，做者也提出一些較好的看法：

1）面向切面編程，儘可能避免侵入業務，作到業務層面無感知；

2）數據採集不只僅是包括性能指標的數據，有時候須要採集發生性能問題的上下文數據，同時須要劃分業務線和責任人；

3）數據採集完成後最終都是要上傳到服務器上，在上傳的過程當中，若是速度太快就會對服務器形成太大的壓力，並且可能會把主業務的流量淹沒掉，太慢又可能對問題不能及時修復，所以在數據上傳的過程當中須要權衡服務器壓力與實效性；

4）因爲採集的日誌量很是大，咱們不可能去分析全部的日誌，所以須要對日誌作優先級的選擇。對實效性要求比較高的數據，例如Crash日誌、實時下發的一些自定義事件，但願很快的上傳到服務器，不重要的日誌先暫存在客戶端，最後通過壓縮批量上傳；

再次，做者展現了領英從數據採集、存儲、上報到數據可視化的整個方案。以下圖所示：首先是客戶端進行數據採集，通過後臺提供的數據上傳Api接口把數據上傳到後臺，後臺服務把數據寫入到Kafka，接着把數據分發到下游的訂閱者：Samza實時任務和HDFS，Samza實時任務主要是流式處理，具備較高的實時性；HDFS是天天或者每一個小時的一個定時任務處理，主要是對離線數據進行批量操做，處理大量的數據，可是實時性就差一些了；當處理完成以後，會把實時數據和定時數據寫到數據庫裏，經過數據可視化工具，就能看到不一樣數據對應的表格；最後經過設置數據的性能報警閾值，能夠對性能問題進行實時監控。

有了性能日誌，那麼接下來就是對日誌進行分析。首先咱們看下是否可以對當前問題進行重現；而後檢測當前網絡、數據開關等是否正常；最後再經過一些分析工具對當前獲取的日誌進行分析並定位問題。問題定位到後，就須要對問題進行修復，經常使用的解決方式主要有：後臺服務進行降級處理、客戶端發補丁進行熱修復、發佈新的小版本。問題修復完成後，最後一步就是對剛剛修復的問題進行驗證，驗證線上是否已經徹底進行修復而且不會對其餘功能模塊產生影響。

最後，做者介紹了下性能優化在LinkedIn中的具體實踐；以下圖所示，主要包括：

1）網絡優化

2）數據簡化

3）佈局優化

1）網絡優化主要是從Mux轉爲HTTP/2，同時做者也在嘗試Google的QUIC；

2）數據優化使用了採用數據精簡工具Frontend Deco，刪除無用字段，精簡數據的模型等；

3）佈局優化做者首先分析了下Auto Layout的性能問題，針對佈局優化，做者開發了一套LayoutKit框架，經過對比統計要比AotoLayout性能高出不少。LayoutKit的思路主要借鑑於Flexbox，把佈局的計算侷限於在一個軸上，使佈局計算的複雜度可以大大降低，LayoutKit的開源地址：https://github.com/linkedin/LayoutKit。

最後做者進行了一個總結，就很少描述了，附圖一張。

總結

GMTC從16年第一屆的移動端發展到如今第三屆的大前端，知名度也愈來愈高，專題數也擴大至當前的14個。我的感受大方向主要有3個：

• 第一個是端上的深根細做，好比性能優化與監控等；
• 第二個是端上的跨界融合，好比端上AI與音視頻等的結合；
• 第三個是大前端的一統江湖，國外從FaceBook推出的RN到如今Google發佈的Flutter，國內從微信的小程序到如今的九大廠商聯合推出的快應用，國內外廠商在大前端一統的路上百花齊放，充分說明將來必定是前端、Android與iOS大統一的趨勢。

以上內容僅表明我的觀點，有什麼問題歡迎探討指正。

歡迎關注個人微信公衆號，接收第一手技術乾貨