IMWeb Conf2018 Native跨端融合總結

有幸全程參與IMWeb Conf 2018的Native跨端融合議題，近幾年來因爲移動Web的高速發展，它的簡單靈活性使得愈來愈多的跨端融合方案不斷涌現，尤爲是小程序等各類端平臺的出現，使得跨端融合訴求進一步提升，在當下跨端融合絕對是很是值得探討的一個話題。會場以三個主流框架層面的分享引入話題討論，本文總結會議主要內容，加以本身的思考，但願可以拋磚引玉，引起思考。

跨端融合

「一次編寫，處處運行」(Write once, run anywhere, WORA)，最先是Sun公司在跨平臺方面的宣傳口號，也表明着咱們做爲開發人員對於效率的極致追求。近幾年隨着移動互聯網的快速發展，移動終端設備的軟硬件、操做系統、開發工具鏈和技術社區等日趨成熟完善，在前端也涌現出各類跨平臺的開發方案。

會場主題

Weex內核的原理和演進方向

第一場分享是由阿里巴巴技術專家張翰、申遠帶來的有關Weex的分享，在分享中，張翰介紹了Weex的基本狀況、內部結構、分析比較，申遠講述了Weex in 2018及相關特性。

Weex目前已在「阿里系」應用以及社區內獲得普遍應用，常規業務、雙十一/大促、高性能場景都有着生產環境的實踐。同時搭配了一系列的配套設施，如EMACS、weex-ui、達芬奇等。

Weex總體結構設計分爲Vue、JS Framework、Weex Core和Render Engine四個部分，由JS FrameWork與Weex DOM API對接，並經過Bridge API與Weex Core通訊，Weex Core對Native進行底層調用。

如咱們所知，在移動端出現的各類方案中，越接近原生開發的性能越好，越接近Web的開發成本越低，weex前期是比較貼近於Web的開發體驗，所以和Web的開發曲線十分相似，到後來貼近原生開發的體驗，中間會經歷一個拐點，張翰認爲這個拐點在於前端和客戶端的有效結合，須要客戶端爲前端賦能，當前端須要客戶端時，客戶端能夠提供相應的基礎設施，過分到原生開發的性能體驗。

接着申遠講述了WeexCore的架構升級，以及渲染架構2.0的狀況，主要針對Layout性能進行了相關優化，對Timer進行了升級，針對首屏渲染狀況進行了特別優化，能夠看到優化後在速度性能、內存佔用方面的明顯效果。

最後申遠也提到，Weex Render是基於skia的，拋開客戶端原生view的限制，能夠換來性能上的提高，最重要的是，能夠實現複雜的CSS效果，基於此，weex也擴展了140多種CSS樣式能力。

Hippy 框架設計與優化

第二場分享由騰訊高級工程師趙宏罡、盛波帶來的有關Hippy的分享，從前端和終端的角度介紹了Hippy的誕生，相比RN的逐條改進優化策略，使用場景以及未來的規劃等等。

Hippy做爲騰訊的一款跨端框架，融合了前端和終端實現的優勢，具備體驗好、開發效率高等優點。Hippy的初衷是爲了解決RN所帶來的一系列問題。

Hippy整體架構設計分爲組件層、Render解析、前端核心、C++和終端層5個部分，組件層封裝了許多實用的上層組件，Render解析層支持React和Vue的核心解析渲染邏輯，前端核心層定義了通訊模塊、日誌、ui管理等等核心模塊，經過Bridge與終端通訊，終端經過定製的V8和JS Core進行解析渲染。另外，Hippy提供了完善的發佈管理系統，直接對接終端的sdk包，具備增量發佈等功能，有效解決RN包太大的問題。

Hippy在上層支持React、Vue的語法，在Render層解析jsx或Vue Template，統一對應到Hippy的DOM API，再經過Bridge與底層通訊。這與瀏覽器自己的DOM API設計思路也很是的類似。

Hippy相比RN在諸多方面都有優化，手勢方面，Hippy改善了終端向前端持續發送手勢事件的行爲，解決了前終端通道被大量佔用的問題；通訊方面，Hippy去除了RN LastFlush的緩存；動畫方面，Hippy使用AnimateConfig使得動畫一步到位，性能獲得顯著提升。

針對ListView，Hippy也作了UI複用，防止List數據過多時帶來的內存損耗。同時，Hippy也針對啓動速度、兩端的API設計、穩定性作了很多的優化工做。

Hippy介紹到，它不只僅是提供一個庫，還提供一整套解決服務，包括打包管理系統、動態運營、隔離灰度、ABTest、差量發佈、強制更新、安全校驗、流控等等，幫助更好的管理髮布。

Hippy已經被騰訊內部很多業務普遍使用，在QQ瀏覽器的首屏已經切換到Hippy，在這個UI繁多、DAU達到千萬級別的業務中經受住考驗。

最後，Hippy也給出在實際業務中優化的一些建議，如裁剪包大小、掃描圖片大小、第三方庫檢測、懶加載、AsyncStorage、關鍵路徑優化等等。

多端開發統一框架 Taro 深度剖析

第三場分享由京東的高級工程師李偉濤帶來關於Taro的分享，介紹了Taro的歷史背景、設計思想、持續優化、開源探索以及將來規劃等。

Taro自己做爲多端統一框架，初衷是爲了解決小程序開發中的各類痛點，快速開發小程序，以後可以根據一套代碼適配到h五、RN等各端。

小程序在開發中會遇到代碼組織複雜、規範不統1、字符串模板弱、依賴管理混亂、不能使用ES Next、開發方式落後等問題（部分問題已經在小程序更新版本中得以改善），因而Taro決定將React現代技術棧編寫的代碼，並經過編譯的方式生成到不一樣平臺，作到」一處編寫，多端運行「。

Taro的整體思想是藉助Babel的編譯能力，通過詞法語法等分析流程以後，對代碼進行優化並根據不一樣平臺進行轉換，最終獲得目標代碼。

在編譯過程當中，會遇到許多難題，各平臺的組件和API差別都比較大，所以Taro經過統一的組件和API層，經過bootstrap適配到各個平臺。

Taro對JSX持續作較爲豐富完善的支持，對小程序組件化方案作重構，使用更加直觀好用的組件化形式組織代碼，對於小程序的setState性能也按照React的異步方式作了優化，對TypeScript、React Native的轉換作了進一步支持，百度/支付寶小程序也在支持中。

Taro是今年6月7日正式對外開源的，開源以來獲取不少好評，對於issue的解決率也比較高，pr數量也不錯，對React社區和小程序社區的一些知名框架都作了支持，同時也有一套較爲好看的UI。

在將來規劃中，Taro即將支持百度/支付寶小程序、快應用，提供更加便捷的測試調試方法，支持從原生小程序生成Taro代碼，支持可視化的界面生成，都是一些值得期待的特性。

小結

跨端開發在前端領域探索已久，從PhoneGap時代開始，咱們就但願移動應用既能擁有原生開發的性能體驗，又能擁有Web開發的靈活性和敏捷性。在小程序與更多端的出現後，「一次編寫，處處運行」成爲了開發人員心裏最強烈的渴望，RN、Weex、Hippy在不斷平衡開發和性能中發展，Flutter選擇犧牲一些開發體驗追求較高的性能，Taro/mpVue等方案在小程序多端方面作出本身的探索，每一個框架都有本身的出發點，但本質上的追求是多端可以更加統一，加強代碼的可維護性，加強開發體驗，加強性能體驗。

很高興可以在會議中看到Weex團隊與W3C的交流，但願可以在多端方面制定些標準，在實際開發中少一些選擇，多一些統一。同時也但願小程序團隊可以更加開放的接納社區意見，可以提供更好的開發體驗，原生支持主流框架，而非依賴於其餘手段曲線救國，解決好跨端開發體驗的問題，前端才能更專一于思考自身。

(知乎相關問題：www.zhihu.com/question/29…)