摘要：于是后來業(yè)界開始探索依舊利用技術(shù)棧開發(fā)出媲美原生體驗的方案，于是以為代表云原生開發(fā)框架開始出現(xiàn)。依舊采取傳統(tǒng)的開發(fā)技術(shù)棧進行開發(fā)，同時在終端的運行體驗不輸。其同時解決了開發(fā)效率發(fā)版速度以及用戶體驗三個核心問題。

摘要： WEEX依舊采取傳統(tǒng)的web開發(fā)技術(shù)棧進行開發(fā)，同時app在終端的運行體驗不輸native app。其同時解決了開發(fā)效率、發(fā)版速度以及用戶體驗三個核心問題。那么WEEX是如何實現(xiàn)的？目前WEEX已經(jīng)完全開源，并捐給Apache基金會，我們可以通過分析其源碼來一探究竟。

點此查看原文：https://yq.aliyun.com/article...

作者：阿里-移動云-大前端團隊

傳統(tǒng)的移動端開發(fā)，一個完整的業(yè)務(wù)需要維護三份終端代碼：Android、iOS、H5，這帶來了極大的開發(fā)成本以及維護成本。尤其是對處于業(yè)務(wù)初創(chuàng)期需要快速試錯的業(yè)務(wù)以及需要支持定期運營活動的業(yè)務(wù)。所以業(yè)界也一直在探索跨平臺方案，旨在通過一套代碼完成各個終端的業(yè)務(wù)邏輯。相關(guān)方案經(jīng)過不斷演化，從早期的H5、Hybrid到如今的Cloud Native(云原生)，在開發(fā)效率和用戶體驗上都在一點點逼近最初的設(shè)想。

早期H5和Hybrid方案的核心是利用終端的內(nèi)置瀏覽器（webview）功能，通過開發(fā)web應(yīng)用滿足跨平臺需求。該方案可以解決跨平臺問題，同時可以提升發(fā)版效率。但其最大的弊端在于用戶體驗相較于native開發(fā)的app存在較大差距，經(jīng)常出現(xiàn)頁面卡頓，加載慢等問題。

于是后來業(yè)界開始探索依舊利用web技術(shù)棧開發(fā)出媲美原生體驗app的方案，于是以WEEX為代表云原生開發(fā)框架開始出現(xiàn)。所謂云原生(Cloud Native)指可以通過云端快速發(fā)布（與遠程web應(yīng)用發(fā)布流程類似），同時還可以達到媲美原生App體驗的方案。WEEX依舊采取傳統(tǒng)的web開發(fā)技術(shù)棧進行開發(fā)，同時app在終端的運行體驗不輸native app。其同時解決了開發(fā)效率、發(fā)版速度以及用戶體驗三個核心問題。那么WEEX是如何實現(xiàn)的？目前WEEX已經(jīng)完全開源，并捐給Apache基金會，我們可以通過分析其源碼來一探究竟。

WEEX框架主要分為兩部分：

前端JavaScript框架
Native SDK

本文主要探討Native SDK的核心原理，其前端JavaScript框架會在后續(xù)的文章中進行介紹。

1 整體架構(gòu)

首先來看下WEEX開發(fā)的整體架構(gòu)：

從上圖中可以看到weex的大致工作流程：

研發(fā)人員利用web技術(shù)棧開發(fā)weex file，打包成JS Bundle，然后部署到服務(wù)器上
終端通過網(wǎng)絡(luò)獲取JS Bundle，然后在本地執(zhí)行該JS Bundle

終端上提供了JS的執(zhí)行引擎(JSCore)用于執(zhí)行遠程加載到JS Bundle

JS執(zhí)行引擎執(zhí)行JS Bundle，并將相關(guān)渲染指令以及其他需要利用native能力的指令通過JS-Native Bridge透出

JS-Native Bridge將渲染指令分發(fā)到native（Andorid、iOS）渲染引擎，由native渲染引擎完成最終的頁面渲染

看完上述整體架構(gòu)后，可以大致理解為何WEEX可以達到媲美原生的體驗，因為其頁面渲染并不是像H5方案一樣接入瀏覽器的渲染能力，而是原生渲染，所以本質(zhì)上渲染出來的頁面就是一個native頁面。

接下來我們再來將端上的模塊進行詳細的拆分：

如上圖所示，WEEX NATIVE SDK大致可以分為如下幾個層級：

JS執(zhí)行層：

JS執(zhí)行引擎：JSCore，解釋并執(zhí)行JS Bundle
main.js：提供WEEX runtime，SDK初始化，JS Core會首先加載main.js,為js bundle提供weex runtime
Bridge層：提供JS和Native的雙向通信能力
Dom層：維護頁面Dom結(jié)構(gòu)
Render層：完成頁面渲染
native組件庫：本地UI組件庫，每一個組件對應(yīng)一個html標簽，所以當我們在weex開發(fā)過程中使用到的各種標簽：div、text、image等等，最終都被轉(zhuǎn)化成為了一個native的控件
module manager、module庫：功能模塊管理層
WXSDKManger、WXSDKEngine：SDK全局環(huán)境維護
WXSDKInstance：weex 實例，一個js bundle對應(yīng)一個weex實例

2 WEEX SDK初始化

有了上述大致架構(gòu)和功能劃分后，我們以一個實際的例子來分析WEEX NATIVE SDK的運行邏輯。首先來看下WEEX SDK在初始化階段都做了哪些準備工作。

這里以Andorid代碼為例進行分析:WEEX的初始化通常放在Application中，其初簡化的初始化邏輯入如下：

public class WXApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        initWeex();
        ......
    }

    private void initWeex() {
        // 自定義相關(guān)配置
        InitConfig config=new InitConfig.Builder()
                .setImgAdapter(new ImageAdapter()) // 自定義圖片適配器
                .build();
        WXSDKEngine.initialize(this,config);

        // register module
        try {
            WXSDKEngine.registerModule("testmodule", TestModule.class); // 注冊自定義模塊
            WXSDKEngine.registerModule("event", WXEventModule.class);

            WXSDKEngine.registerComponent("richtext", RichText.class); // 注冊自定義UI組件
            ......
        } catch (WXException e) {
            e.printStackTrace();
        }
    }
}

從代碼中可以看到，weex的初始化比較簡單，主要完成兩件事：

完成初始化配置：比如指定相關(guān)適配器，比如圖片請求適配器
注冊自定義的UI組件和功能模塊

剩下的事情都交給WEEX SDK來完成了，那么接下來就來看下WEEX SDK都做了些什么？

具體代碼在WXSDKEngine.doInitInternal:

 private static void doInitInternal(final Application application,final InitConfig config){
    WXEnvironment.sApplication = application;
    WXEnvironment.JsFrameworkInit = false;

    WXBridgeManager.getInstance().post(new Runnable() {
      @Override
      public void run() {
        long start = System.currentTimeMillis();
        WXSDKManager sm = WXSDKManager.getInstance();
        sm.onSDKEngineInitialize();
        if(config != null ) {
          sm.setInitConfig(config);
          if(config.getDebugAdapter()!=null){
            config.getDebugAdapter().initDebug(application);
          }
        }
        WXSoInstallMgrSdk.init(application,
                              sm.getIWXSoLoaderAdapter(),
                              sm.getWXStatisticsListener());
        boolean isSoInitSuccess = WXSoInstallMgrSdk.initSo(V8_SO_NAME, 1, config!=null?config.getUtAdapter():null);
        if (!isSoInitSuccess) {
          return;
        }
        sm.initScriptsFramework(config!=null?config.getFramework():null);

        WXEnvironment.sSDKInitExecuteTime = System.currentTimeMillis() - start;
        WXLogUtils.renderPerformanceLog("SDKInitExecuteTime", WXEnvironment.sSDKInitExecuteTime);
      }
    });
    register();
  }

這是WEEX SDK的初始化邏輯，其主要做了以下幾件事：

初始化WXBridge，同時啟動WXBridge線程，待接收指令。WXBridge在Android的實現(xiàn)本質(zhì)上是一個基于HandlerThread的異步任務(wù)處理線程

initSo：加載so文件，即JS執(zhí)行引擎

initScriptsFramework：加載SDK中的main.js,完成weex runtime的初始化

register：注冊SDK自帶的UI組件和功能模塊

3 頁面渲染

WEEX SDK在完成了初始化之后，即可開始渲染頁面了。接下來我們以如下這JS代碼為例，來介紹頁面的渲染邏輯：

JS代碼比較簡單，邏輯就不介紹了。接下來重點介紹，當終端獲取到如上圖右側(cè)的js bundle后，如何進行加載、渲染以及后續(xù)的相關(guān)邏輯執(zhí)行。

3.1 weex實例創(chuàng)建

實際上當WEEX SDK獲取到JS Bundle后，第一時間并不是立馬渲染頁面，而是先創(chuàng)建WEEX的實例：

這幅時序圖中有兩個主要邏輯：

創(chuàng)建createInstance：創(chuàng)建一個weex實例，每一個JS bundle對應(yīng)一個實例，同時每一個實例都有一個instance id。由于所有的js bundle都是放入到同一個JS執(zhí)行引擎中執(zhí)行，那么當js執(zhí)行引擎通過WXBridge將相關(guān)渲染指令傳出的時候，需要通過instance id才能知道該指定要傳遞給哪個weex實例

execJs：在創(chuàng)建實例完成后，接下來才是真正將js bundle交給js執(zhí)行引擎執(zhí)行

3.2 頁面渲染

在實例創(chuàng)建完成后，接下來就是頁面渲染了。首先來看下頁面渲染的整體流程：

js bundle涉及dom操作的執(zhí)行都會被weex-vue-framework轉(zhuǎn)化成native dom api, 前端框架vue是基于virtual dom api,而weex的前端框架:weex-vue-framework的核心邏輯就是將vue的virtual-dom轉(zhuǎn)換成Native DOM API
weex終端的執(zhí)行引擎在執(zhí)行到Native DOM API后，則會將其轉(zhuǎn)化為Platform API,說白了就是通過WXBridge將Native DOM API以約定的方式轉(zhuǎn)發(fā)給native渲染引擎，完成頁面渲染

可以看到，在js執(zhí)行引擎創(chuàng)建好weex實例后，會執(zhí)行對應(yīng)的JS Bundle，并在執(zhí)行到platform api的時候?qū)⑵渫ㄟ^wxbridge，發(fā)送給DomManager。相關(guān)代碼可參考：com.taobao.weex.bridge.WXBridge

3.2.1 createbody

一個頁面的DOM結(jié)構(gòu)最外層是body，所以創(chuàng)建頁面一開始就是createbody，整個create body的過程大致可以分為以下幾個步驟：

WXBridge將create body指令發(fā)送給WXDom模塊。WXDom是另一個異步線程，負責維護頁面的Dom樹

WXDom創(chuàng)建一個新的dom樹，同時創(chuàng)建body節(jié)點

WXDom將create body指令傳遞給WXRenderManager渲染引擎，渲染引擎主要完成如下幾件事：

初始化一個組件實例，稱為mGodComponent
generateComponentTree：由于一個WEEX頁面就是由多個UI組件(Component)構(gòu)成的一棵樹，所以渲染引擎會初始化組件樹
創(chuàng)建view

3.3.2 addElement

創(chuàng)建完body后，需要在body中添加一個text組件，指向該操作的Native DOM API為addElement,其具體操作為：

WXDomManager:更新本地dom樹，添加text節(jié)點
WXRenderManager：本地渲染引擎添加相關(guān)組件：

從已注冊的組件中找到text對應(yīng)的組件，并實例化
將初始化完成的text組件添加到body所對應(yīng)的view之上
給text組件設(shè)定布局、添加監(jiān)聽事件
加入數(shù)據(jù)綁定
在此一個帶有一個text標簽的簡單頁面才算是渲染完成。值得一提的是，在WXRenderManager創(chuàng)建組件時，需要在本地已注冊的組件中需要標簽對應(yīng)的組件，此處標簽對應(yīng)的組件為com.taobao.weex.ui.component.WXText，其本質(zhì)上是一個TextView。從這里可以發(fā)現(xiàn)，其實我們在JS Bundle中指定的各種標簽，其實都最終被轉(zhuǎn)化為了一個native的控件。這也就是為什么用WEEX開發(fā)出來的app，本質(zhì)上還是一個Native App。

其他的對應(yīng)關(guān)系還有：

div 對應(yīng)WXDiv
image 對應(yīng)WXImage
list對應(yīng)WXListComponent
a對應(yīng)WXA
…...
4 總結(jié)
通過前文的介紹，相信大家對WEEX有了一個初步的系統(tǒng)認識。簡單來說，WEEX放棄了傳統(tǒng)的Webview，而是搭建了一個native化的瀏覽器，因為用native的方式實現(xiàn)了一個瀏覽器的大部分核心組成成分：

JS 執(zhí)行引擎
渲染引擎
DOM樹管理
網(wǎng)絡(luò)請求，持久層存儲等等能力
...

另外為了保證整個SDK的運行效率，SDK維護了三個線程：

bridge線程：完成js到native之間的通信
dom線程：完成dom結(jié)構(gòu)的構(gòu)建
渲染線程：完成UI渲染，也就是UI線程

以上就是WEEX SDK的大致框架和核心邏輯，篇幅有限，無法面面俱到，只是希望通過該文想大家展示W(wǎng)EEX基于WEB技術(shù)棧開發(fā)native app的原理。文章內(nèi)容如有偏頗，歡迎大家指正。