客戶端動態化系列之——Weex

在前端愈來愈火的年代，逐漸衍生出相似React Native、Weex等開發套件。所達到的目的挺簡單的，達到在多個平臺下共用一份代碼，節省開發成本，提升開發效率。其次，因爲JavaScript語言的特殊性，能動態更新頁面而不須要發版。基於這兩點，愈來愈多的我的開發者&公司開始嘗試它們。

本文將從我的開發實踐項目出發，發表一些對於Weex的見解和在項目中的實戰經歷。不涉及具體原理和概念性的東西，讀者能夠自行去Weex官網查閱。

Weex原理

大致上和React Native一致，都是一個「放大版」的JSBrdige。其核心無非就是自定義了一套DSL(.we)，配合vue實現數據綁定、vdom等等功能。再經過native端與JS端的數據、API交互使得最終體現爲native的調用過程。

而在這過程當中，iOS用了自帶的引擎JavaScriptCore & Android則是Google V8。在這過程當中有個坑，iOS版本Weex有內存泄漏的狀況（Android沒有），緣由是JS Framework（Weex JS端的主程）並無像V8同樣hidden class的行爲，GC回收不是很及時。Weex開發團隊的同事發現了此bug，並在後續的版本中修復。

OK，我認爲對於「應用框架者」來講，不用去care具體實現的原理。只須要了解怎麼使用便可，畢竟這只是一個工具。若是是爲了學習，能夠去閱讀，而對於「使用者」來講，快速地入門則是王道。

而Weex的使用，對於native來講，無非就是針對具體的業務場景實現Handler、Module、Component。

Handler

咱們能夠把Weex看作是一個提供了基礎套件的UI渲染庫。核心功能仍是須要開發者本身來實現，好比：圖片下載邏輯、網絡請求、導航跳轉等等。

因此開發者首先要關注的就是須要靜態分析本身當前工程所需的功能，看看Weex須要你實現的handler中有哪些你要用到的，並實現它們。
好比在個人項目中，我就須要實現圖片下載邏輯，因而實現並註冊。

[WXSDKEngine registerHandler:[CNCWeexImageLoaderImplement new] withProtocol:@protocol(WXImgLoaderProtocol)];

Module

Module能夠理解爲JS端須要調用native才能處理的邏輯，而且在JS<->native進行交互。這麼說有點抽象，舉個具體的例子：好比在JS端想訪問native端的數據庫（coredata、realm等），就須要實現一個module來知足JS調用native寫好的module以實現native的邏輯。

在個人實戰項目中，我選擇用module的方式實現網絡請求與導航跳轉。
[WXSDKEngine registerModule:@"urlRoute" withClass:[CNCWeexURLRouteModule class]];
[WXSDKEngine registerModule:@"networkRequest" withClass:[CNCWeexURLRouteModule class]];

Component

Component很好理解，要實現一個跑馬燈UI的效果，在native端實現，而且註冊到JS。JS端調用，便可展現出跑馬燈。這就是Component，在JS知足不了或者實現成本很高的時候，則能夠在native端實現Component供JS調用。

因爲第一次試水Weex，並無採起很複雜的UI，就沒有用Component。

踩過的坑

JS中this關鍵字的用法與Objc不一樣，this的做用域僅在當前對象。而在JS中函數也算一個對象。若是在函數中套一個函數，此時用this，只能表明外層函數。而非Objc同樣表明整個最外層對象，須要注意！

業務中碰到一個場景，須要在某個場景，native端主動調用JS。而Weex提供給外部的API並無提供這樣的能力，僅僅是在JS主動調native方法時傳一個callback，而且在native方法執行完成時，callback銷燬。而業務場景卻須要在未來執行回傳下來的callback。翻看源碼，只能本身實現了。這裏給個思路：

其實在Weex的實現中（不貼源碼了），會判斷native實現的方法（即給JS調用的方法，好比module實現的方法）的入參類型。若是是聲明成WXModuleCallback，則Weex內部會進行處理，並轉成block給iOS（Android同理）。而若是不是WXModuleCallback，則會透傳一個String（weex標記的方法ID）下來，這很關鍵。因而咱們能夠投機取巧地把入參改爲String，記錄下這個String。在後期想調這個JS方法時，寫以下代碼便可
[[WXSDKManager bridgeMgr] callBack:weexInstance.instanceId funcId:aliveCallBackID params:params keepAlive:YES];

見解

Weex相比React Native，坑仍是比較多的。可是從「使用者」角度來講，Weex方便不少。可是對於存在不少複雜業務場景的開發者來講，必然會去學習其原理，而此時Weex相比RN就沒那麼友善了。

筆者由於在阿里，更加支持Weex，也但願它變得愈來愈好。

不管採用哪一種方式，二者都能實現客戶端的動態化。而這對於一些多變的頁面來講，是一種新的選擇方式。

這是客戶端動態化系列的第二篇文章，讀者能夠看前篇客戶端動態化系列之——URLRoute，相信你對動態化有更深的理解。