「站在10年研發路上，眺望前端將來」：讀後感

遷移一批老文章到掘金

如下內容感受都是嘴炮，沒啥乾貨，也沒啥源碼，就是本身的一點亂七八糟的想法，甚至多是我的單方面的yy。。。我仍是不歸類在搬磚裏，歸類在扯淡裏吧

偶然間看到了這篇阿里大神的採訪稿，看過以後，做爲一個對前端抱有極大興趣客戶端開發，做爲一個不太懂前端的小白，依然以爲好贊。

站在10年研發路上，眺望前端將來

如下爲原文引用

App混合開發的優缺點有哪些？是否會成爲主流？

桐木：混合開發主要是爲了實現動態化和節約開發成本，但WebView裏跑的部分不管如何也很難達到Native的性能和體驗。目前不少技術的發展其實都是在改造WebView，試圖甩掉一些包袱或者說歷史負擔。有人可能會奇怪，WebView有哪些歷史負擔呢？咱們能夠來仔細看看：

首先，是標準兼容上的包袱。因爲WebView做爲一個通用的瀏覽器內核，自己要求具有向前兼容性，好比雖然用flexbox佈局瀏覽器能夠更高效地layout，但爲了兼容它仍然必須得能認得浮動佈局、相對定位佈局甚至表格佈局。這些邏輯交織在一塊兒很是複雜，牽一髮而動全身。假設我如今fork一個新的WebView出來，裁減掉flexbox以外的支持，就大大下降了layout邏輯的複雜度，即便不作優化就已經能快很多了，更況且狀況變簡單之後還可以針對flexbox佈局作專門的優化，得到更大的性能提高。

其次，瀏覽器的內部機制以及js語言在設計上，其實也有一些歷史包袱。好比瀏覽器從一開始設計，js engine和dom engine就是兩塊獨立的黑盒，js調用dom時至關於一次rpc調用，每次調用都會涉及上下文的保存和恢復。同時，js excute和dom render是跑在一個線程裏的，即便二者沒有調用關係，dom也必須等js執行完畢才能render。這兩件事的結果就是網頁在運行過程當中會在這兩個黑盒之間來回切換，各類上下文切換，各類互相等待，這樣一來掉幀就在所不免了。因此，若是咱們可以讓js engine和dom engine在執行層面可以打通，變rpc調用爲本地調用，就能加快很多。更進一步來講，若是可以有效利用多核，把js excute和render在必定條件下並行起來，或者把style resolving和layout並行起來，也能提高新性能。

再次，WebView自己確實也在越變越快，但有些OS的限制或者一些設備老舊WebView的存在，會致使碎片問題，這也在拖慢咱們的腳步。這個你們比較熟悉了，例如iOS的Nitro、WKWebView之於UIWebView，還有Andorid4.4以後的Chromium WebView之於以前的WebKit WebView。

老郭的BeeFramework/Samurai、阿里的birdnest，是在甩前兩項包袱，一方面取Web標準的子集，一方面把全部東西都拉到Native的runtime裏執行；FB的React Native和阿里的Weex，主要在甩第一項包袱（部分優化了第二項）；Mozilla的Servo致力於並行化和GC，主要是在甩第二項包袱；Intel的crosswalk、微信的X五、阿里的UCWebView等，是在必定範圍內甩第三項包袱……你們爲了甩掉這些包袱，都提出了不一樣的解決方案。

不論你們走哪條路，有一個共識仍是你們都找到了的，那就是看齊Web的幾個標準。由於Web的技術體系在UI的描述能力以及靈活度上確實設計得很優秀的，並且相關的開發人員也好招。因此，若是說混合開發指的是Native裏運行一個Web標準，來看齊Runtime來寫GUI，並橋接一部分Native能力給這個Runtime來調用的話，那麼它應該是一個永恆的潮流。

對fe有興趣的一個外行

我本身在剛畢業的時候作遊戲，作過半年時間的cocos2dx-lua的開發，早在3年前，就已經產生了這種，純lua腳本動態更新整個遊戲app的解決方案，這種腳本解釋驅動native的方案，當時就已經讓我一個剛畢業的新人產生無限的探索求知慾望。

後來轉行iOS，由於業務緣由，接觸到了和排版相關的工做內容，發現咱們的文字排版引擎，都很相似瀏覽器內核的webcore部分，將UI描述文件JSON（內容相似HTML,CSS）經過解析生成數據結構（相似dom樹的東西），再通過排版計算（相似flexbox），生成了渲染結構（相似render樹的東西），再進行渲染。

再後來接觸了JSPatch，React-Native，這些看起來都能實現動態更新這一目標，但深刻思考會以爲這裏面不少思路都是徹底相通的

• 腳本去驅動native（C++native，源平生臺native，runtime動態native）
• 界面描述語言組織布局和渲染

懷着對這種動態化hybrid方案的極度好奇，對於腳本驅動native，對於html+css驅動佈局渲染，究竟是怎麼實現的，極大地求知慾，我對前端也產生了濃厚的興趣

我歷來不認爲何H5開發與Native開發是衝突或者對立的，這倆誰搶誰飯碗的問題，就像引文最後這一段所說的，native與web，我以爲應該是水乳交融的狀態。

Hyrbid的第四個包袱

我還很不瞭解FE，但從客戶端的角度看這個問題，也有點本身的琢磨，也不知道對不對，真的很但願能有專業人士幫我指正一下，同時我也會盡量的彌補本身在FE方面知識的欠缺

大神文章中提到的三個包袱，都是純webview的狀況下的包袱，若是進入了web與native，hybrid混合開發的模式下，我以爲還會有第四個包袱 （此處經@bang哥修正，對原來的表述有所修改）

rpc不僅存在於js與dom之間，還存在於js環境與native環境兩個環境的協議溝通。

既然是hybrid，那離不開na的工做，na的運行環境與js的運行環境是徹底獨立的兩個環境，雖然在一個app內，但兩者之間也不是那麼順暢的無縫調用，都依賴於一個橋

• 基於webview hybrid依賴於webview的JSbridge設計
• cocos2dx-lua 依賴於tolua++ 半自動生成的 lua/C++bridge設計
• 基於JavaScriptCore的橋接API的JSbridge設計

橋的設計與調用方案各不相同，但走過這個橋也是有開銷和成本的，並非隨便調用的，JSCore在app環境內是一個JS虛擬機+不一樣上下文，而Na的環境也會有安卓的java虛擬機，iOS/C/C++的直接內存環境，不一樣的環境之間，通訊傳遞數據，面臨的都是rpc的切換開銷。若是想減小這個包袱，那就應該儘量的減小web-native通訊次數，可能的佈局運算，邏輯運算，都先放在web這個環境的內部。

若是拿cocos2dx-lua對比react-native來講，cocos2d-x確實是以腳本驅動native實現了動態更新的目標，可是缺失的確是一整套UI描述語言的佈局能力，也就是第一個包袱，正由於徹底缺失了第一個包袱，因此才必須頻繁的切換luaengine（類比jsengine）與native的上下文，用lua來使用na的佈局代碼方案進行界面編寫，從而形成了我說的第四個包袱的問題（再也不是腳本與dom切換，而是腳本與native切換頻繁）。

但cocos2dx有個特色，得益於lua這種語言的C內核解釋器的運行效率以及以及同爲C/C++語言的native部分的類似性，這部分開銷在普通的2D簡單UI型遊戲的開發上，目前看還沒啥瓶頸，可是，遇到COC這種同屏多兵種每一個兵種各自有獨立AI運算的狀況下，就會有吃力（之前遊戲組遇到的case，不過具體狀況還有點複雜，不太好徹底歸結於第四個包袱）

而react-native正如文中所說，一方面着手優化第一個包袱，並且還以React.js的virturl dom的特色優化了第二個包袱，而且因爲在js層處理了佈局運算，從而減輕了我說的第四個包袱的壓力

（如下是@彩虹的修正）

性能上，不只第四個包袱js-native bridge有性能問題，自己JavaScriptCore也會存在性能問題，不一樣的設備，安卓or iOS不一樣系統版本，在JavaScriptCore能力差得狀況下，RN也會面臨性能困境

RN虛擬出了一套diff virturl dom，是放在內存中的一套配置文件，這部份內存中的數據配置，直接生效在native，也就是說，這個dom環境其實也就是na環境，js與dom的切換包袱存在，但這一塊其實不屬於我說的js與native bridge的第四個切換包袱，

根據彩虹的修正，能夠理解RN的dom環境其實就是na環境，是一個na佈局+渲染的環境，而我第四個包袱提到的na環境，嚴格上講是native-bridge所橋接的那塊na環境，這兩個環境都是na，若是切換js環境，都存在rpc，這兩個環境自己並不直接互通

我對前端的瞭解只知其一;不知其二，這些理解，也不知道說的對不對，片面不片面，最近也在學習前端，但願能補上本身這塊知識點的空白，也但願能獲得前端同窗的指導

我以爲Hyrid，確實就是引文所說，若是說標準webview不能知足性能或者native獨有硬件設備上的需求，那麼咱們就參照借鑑web標準，在native內從新打造一個，通過優化包袱後的web native runtime，畢竟web的標準從靈活性上經歷了那麼久的考驗，而客戶端若是能改變一些內核策略，甩掉一些包袱，爭取到適應當下移動設備性能而且兼顧動態性的最優體驗，那就真的是客戶端與前端的水乳交融的hybrid了

以上內容感受都是嘴炮，沒啥乾貨，也沒啥源碼，就是本身的一點亂七八糟的想法。。。我仍是不歸類在搬磚裏，歸類在扯淡裏吧