有幸全程參與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本身作為多端統一框架，初衷是為了解決小程式開發中的各種痛點，快速開發小程式，之後能夠根據一套程式碼適配到h5、RN等各端。
小程式在開發中會遇到程式碼組織複雜、規範不統一、字串模板弱、依賴管理混亂、不能使用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…)