Taro、Weex、Hippy 齊聚 IMWebConf 2018！

IMWeb Conf 2018 Native 跨端融合分會場

瞭解更多：《IMWeb Conf 2018 Native 跨端融合分會場》

背景

Write once, Run anywhere. 一次編寫，處處運行。

這句程序員圈子裏十分著名的話，也許你早已聽過。事實上，這是 JAVA 語言的 slogan，誕生於 1991 年。語言與平臺，天生有着鴻溝，想要逾越，是當時美好的願景；但如何逾越，確實是一個難題。

雖然幾代的程序員，前赴後繼地爲這個夢想而努力，但遺憾的是，到 2018 年的今天，世界上尚未一個完美的方案。反而，由於程序在不一樣虛擬機或系統上執行的差異，很難確保正確性和穩定性，甚至形成了一個坊間笑話：

Write Once, Debug Everywhere. 一次編寫，處處調試。

---

慶幸的是，玩笑的背後，咱們從不缺乏砥礪前行的開創者。

最近這兩年，在移動端各類跨平臺的開發方案如雨後春筍般涌現，一方面是由於，隨着移動互聯網的普及和快速發展，移動終端設備的軟硬件、操做系統、開發工具鏈和技術社區等日趨成熟完善；另外一方面，近幾年傳統 PC 端的技術、資源也逐步遷移到移動端上來，你們都想造輪子，而後一統天下。 特別是今年，隨着微信小程序的流行，讓原本 Web、iOS、Android 的三足鼎立之勢，又加入了新的玩家。如何統籌兼顧，收歸開發成本，跨端技術勢在必行。

因此，「跨端融合」——這是每個追求新技術的開發者的嚮往，同時也是守舊者的噩夢。

即將於10月14日在深圳舉辦的 IMWeb Conf 2018 中， 《Native 跨端融合分會場》將帶你領略「天下大勢，分久必合」前的腥風血雨。

分享主題

本次騰訊 IMWeb 團隊，邀請到了業內各大公司的著名前端佈道者，圍繞「跨端融合」這一主題，爲您帶來全新的核心理念、設計思路專場剖析。

主題有：

• 多端統一開發框架：Taro 深度剖析 - 李偉濤（京東）
• Hippy - 過億量級動態運營解決方案介紹與應用 - 趙宏罡（騰訊）
• Hippy - 終端架構設計與核心優化 - 盛波（騰訊）
• Weex 內核的原理和演進方向 - 張翰、申遠（阿里）

親臨現場，你將收穫：

• 與前端大咖面對面交流
• 瞭解跨端技術的發展史和最新動態
• 深刻挖掘跨端技術的原理
• 瞭解方案之間的異同
• 認知哪一種方案最適合本身業務

10月14日，咱們與您不見不散！

會前問答

IMWeb Conf 2018 是誠意滿滿的一次前端嘉年華。
爲了讓你們提早感覺到大會的氛圍，咱們準備了乾貨滿滿的分會場提早問答。
採訪的對象，是分別來自阿里與騰訊的趙宏罡與張翰兩位前端技術專家，咱們來看下他們對「跨端融合」的一些見解吧。

問題1：最近有少許國外企業在放棄 RN，從新回到 native 開發，讓業界對RN的信心有所動搖，那在技術選型的時候，是否有必要繼續在 RN上面投入？新項目是否依然應該選擇RN？

趙宏罡：技術選型沒有「銀彈」。沒有一種技術方案能夠完美的解決全部業務場景的全部問題。在 Airbnb 這類開發資源充足，且對動態化需求並非那麼強烈的業務場景，RN 的優點並不突出。由於一些坑選擇放棄 RN 能夠理解。
可是對於追求更高開發效率，以及對動態化運營需求很大的業務場景。RN 依然是一個不錯的選擇。由於原生 Native 開發，H5 開發各自都有很大的痛點。而 RN 這類大前端框架，經過結合兩者的優點真正的抹平了這些痛點。只是目前的大前端框架都還不夠完善，自己又引入了一些新的坑。 可是在咱們長期的實踐中，發現其實不少坑都是有解決方案的。騰訊的 Hippy 框架就是站在巨人的肩膀上，不斷優化，讓大前端框架成爲「不坑」的選擇。 由於大前端方向自己很好的解決了 Naitve 和 H5 原生的問題，而它自身的問題也是能夠解的，因此咱們有理由相信它就是移動開發的將來。

---

問題2：facebook 最近在重寫 RN，是否意味着當前 facebook 也意識到了 RN 的部分性能問題；將來若是 RN 新的版本出來，且明顯高於一些相似的框架，在協議容許的狀況下，如何能夠快速切回RN？

趙宏罡：其實RN的誕生並不是考慮周全的系統架構下的產物。先誕生了 Android 版，以後纔有了 iOS 版，並且也不是一個團隊在統一維護。因此它的一些問題是能夠預見的。仔細看過 RN 的代碼也會發現，有些性能瓶頸，就是底層設計不合理帶來的。從一直沒有1.0版本的出現，也能夠看出 Facebook 顯然對 RN 的現狀是不滿意的。想要真正被大衆接受，重構勢在必行。
其實也很期待RN的重構版。他們重構聲明裏提到對前終端通訊機制的從新設計還挺使人振奮。不過他們也說明了本次重構只是在底層「大刀闊斧」，對上層API是保持了兼容的。而騰訊的 Hippy 框架，也是在上層兼容了 RN 的API。這意味着，若是你用 Hippy 構建了應用，又想要切回 RN 的時候，業務層的工做量是很是小的，幾乎0成本。

---

問題3：JSBridge是前端和 native 進行通信的橋樑，屢次頻繁的調用，會致使整個渲染和通信效率很低，因此對於渲染和動畫，常見的優化方案是下降傳輸字節數，下降調用的頻次；那除了這些常規的手段，還有那些深刻的通用優化方案，能夠進一步優化整個解決方案的性能？

趙宏罡：當前的經驗還有2個：

1. 大部分 JSBridge 都是基於 JSON 來通訊的。在設計協議時，應該儘可能減小數據的層級。用平鋪的方式是最好的。對於層級很深的狀況，序列化和反序列化會更加耗時。
2. 對於大前端框架自身而言，不必定非用 JSON。還能夠設計更輕量的定製化通訊協議。好比 Weex 有 wson，Hippy 有 hippy buffer。用描述式的協議設計讓編解碼更小更快。

還有更加面向將來的方式：
把儘可能多的工做直接交由JS引擎來完成。好比 vdom 的 diff、排版，渲染計算等。在C層作更多的事情，JSBridge的負擔天然就降下來了。這是也是騰訊的 Hippy 團隊正在預研的方向。

---

問題4：不少大企業都推出了一套本身的解決方案，好比阿里的 weex，京東的 taro，騰訊有 hippy、plato，攜程深度定製了 RN 等；業界有不少方案以供選擇，選擇困難症如何破？若是碰到不在持續維護和更新的技術方案，如何處理？

張翰：選擇困難可能來自於對自身技術需求和對大廠開源框架能力沒有精確的把握。解決好這兩點應該就不會選擇困難了。
第二個問題，若是從開源社區的角度看，任何一個開源項目的成功只依靠一家公司的力量是遠遠不夠的，須要社區開發者和企業的共同參與才能帶來持久生命力和繁榮。因此「不持續維護和更新」在我看來是個僞命題，我的更呼籲業界開發者和團隊破除用戶思惟，真正參與到項目的建設中來，成爲開源項目的貢獻者，親手賦予這個項目持久生命力，讓本身的思路在開源項目裏獲得體現。
另外若是真的不想貢獻開源又想要保證框架的穩定性和持續維護，那麼也能夠考慮購買大廠推出的移動研發商業服務產品（如阿里巴巴的 EMAS 產品線）。

---

問題5：大前端時代，不管是哪一種框架；native都在和前端逐步融合。從最初的H5，到hybrid App，再到RN跨端融合，都是想讓用戶體驗更好，因此不少組件都直接使用 native 組件進行渲染，可是又不缺失前端的靈活性；那從前端的角度來看，除了能夠在構建打包，dom-diff，vdom處理外，還有哪些方面能夠進一步挖掘前端的價值？

張翰：「向Native要性能」是咱們持續在探索的一個重要方向，如用 binding 取代 bridge、TS 強類型等 JS 引擎層優化，vdom、dom-diff、佈局能力 native 化，以及用直接繪製方式取代系統 UI 組件以加強特定場景性能表現等方案，均是能夠挖掘的地方。

---

以上是前端專家們的部分精彩問答，若是你想了解更多問題，或者有疑問想進行面對面交流，必定不要錯過參加 IMWeb Conf 2018 的機會！

參會信息

大會提供線下票和線上票兩種票型。

線下票（現場）

購買現場票的觀衆將能夠前往現場，得到與講師近距離接觸以及面對面提問的機會。購買連接：ke.qq.com/course/3179…

線上票（網絡直播）

若是您沒法到達現場，也能夠購買線上票，經過網絡直播觀看全部演講，會後也能夠觀看回放。【Native 跨端融合會場】購買連接：ke.qq.com/course/3187…

其餘會場購買連接：
主會場：ke.qq.com/course/3179…
Node 服務與性能專場：ke.qq.com/course/3187…
小程序快應用專場：ke.qq.com/course/3187…
可視化與動畫專場：ke.qq.com/course/3187…
優惠課程包：ke.qq.com/course/pack…

其餘信息

Conf 官網：2018.imweb.io/
會議時間：2018年10月14日（週日）
會議地址：深圳科興國際會議中心B棟4單元
負責人微信：guofengmian
負責人郵箱：coverguo@tencent.com

移動端請掃碼進入官網：