本文由
玉剛說寫作平臺提供寫作贊助原作者：
兩位低調的 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大統一的趨勢。
以上內容僅代表個人觀點，有什麼問題歡迎探討指正。