一、寫作背景

接觸小程序一年多，真實體驗就是小程序開發(fā)門檻相對而言確實比較低。不過小程序的開發(fā)方式，一直是開發(fā)者吐槽的，如習(xí)慣了 Vue，React 開發(fā)的開發(fā)者經(jīng)常會吐槽小程序一個 Page 必須由多個文件組成，組件化支持不完善或者說不能非常愉快的開發(fā)組件。在以前小項目中沒太大感覺，從加入有贊，參與有贊微商城小程序的開發(fā)，是真切的體會到對于大型小程序項目開發(fā)的復(fù)雜性。

有贊從微信小程序內(nèi)測就開始開發(fā)小程序，在不支持自定義組件的時代，只能通過 import 的形式拆分模塊或?qū)崿F(xiàn)組件。在業(yè)務(wù)復(fù)雜的頁面，可能會 import 非常多的模塊，而相應(yīng)的 wxss 也需要 import 樣式，除了操作繁瑣，有時候也難免遺漏。

作為開發(fā)者，我們當(dāng)然希望可以讓工作更簡單，更愉快，也希望改善我們的開發(fā)方式。所以希望能夠更了解微信小程序框架，減少不必要的試錯，于是有了一次對小程序框架的 debug 之旅。(基礎(chǔ)庫 1.9.93)

通過三周空余時間的 debug，也算對小程序框架有了一些淺顯的認識，達到了最初的目的；對小程序啟動，實例，運行等有了真切的體會。這篇文章記錄了小程序框架的基本代碼結(jié)構(gòu)，啟動流程，以及程序?qū)嵗�化過程。

本文的目的是希望把我看到的分享給對小程序感興趣或者正在開發(fā)小程序的讀者，主要解答“框架對傳入的對象等到底做了什么”。

二、從啟動流程一窺小程序框架細節(jié)

在開發(fā)者工具中使用 help() 方法，可以查看一些指令和方法。使用其中的 openVendor 方法可以打開微信開發(fā)者工具在小程序框架所在目錄。其中以包括以基礎(chǔ)庫命名的目錄和其他幫助文件，如其中有兩個工具 wcc，wcsc。wcc 可把 wxml 轉(zhuǎn)換為對應(yīng)的 JS 函數(shù) —— $gwx(path, global)，wcsc 可將 wxss 轉(zhuǎn)換為 css。而基礎(chǔ)庫目錄包括 WAService.js 和 WAWebview.js 文件。小程序框架在開發(fā)者工具中以 WAService.js 命名（WAWebview.js 不知其作用，聽說在真機環(huán)境使用該文件）。

在開發(fā)中工具命令行使用 document.head 可以查看到小程序的啟動流程大致如下： 以小節(jié)的方式分別介紹這些流程，小程序是如何處理的（小節(jié)編號與圖中編號相同）。

1、初始化全局變量

下圖是小程序啟動是初始化的一些全局的變量：

那些使用“__”開頭，未在文檔中提及可使用變量是不建議使用的，__wxAppCode__ 在開發(fā)者工具中分為兩類值，json 類型和 wxml 類型。以 .json 結(jié)尾的，其 key 值為開發(fā)者代碼中對應(yīng)的 json 文件的內(nèi)容，.wxml 結(jié)尾的，其 key 值為通過調(diào)用 $gwx('./pages/example/index.wxml') 將得到一個可執(zhí)行函數(shù)，通過調(diào)用這個函數(shù)可得到一個標(biāo)識節(jié)點關(guān)系的 JSON 樹。

2、加載框架（WAService.js）

使用工具對 WAService.js 進行格式化后進行 debug�？梢园l(fā)現(xiàn)小程序框架大致由： WeixinJSBridge 、 NativeBuffer 、 wxConsole 、 WeixinWorker 、 JavaScript 兼容 （這部分為猜測）、 Reporter 、 wx 、 exparser 、 __virtualDOM__ 、 __appServiceEngine__ 幾部分組成。

其中除了 wx 和 WeixinJSBridge 這兩個基礎(chǔ) API 集合， exparser , __virtualDOM__ , __appServiceEngine__ 這三部分作為框架的核心， __appServiceEngine__ 提供了框架最基本的接口如 App，Page，Component； exparser 提供了框架底層的能力，如實例化組件，數(shù)據(jù)變化監(jiān)聽，view 層與邏輯層的交互等；而 __virtualDOM__ 則起著鏈接 __appServiceEngine__ 和 exparser 的作用，如對開發(fā)者傳入 Page 方法的對象進行格式化再傳入 exparser 的對應(yīng)方法處理。

框架對外暴露了以下API：Behavior，App，Page，Component，getApp，getCurrentPages，definePlugin，requirePlugin，wx。

3、業(yè)務(wù)代碼的加載

在小程序中，開發(fā)者的 JavaScript 代碼會被打包為

define('xxx.js', function(require, module, exports, window, document, frames, self, location, navigator, localStorage, history, Caches, screen, alert, confirm, prompt, fetch, XMLHttpRequest, WebSocket, webkit, WeixinJSCore, Reporter, print, WeixinJSBridge) {  
  'use strict';

  // your code
})

這里的 define 是在框架中定義的方法，在框架中提供了兩個方法：require 和 define 用來定義和使用業(yè)務(wù)代碼。其方式有些像 AMD 規(guī)范接口，通過 define 定義一個模塊，使用 require 來應(yīng)用一個模塊。但是也有很大區(qū)別，首先 define 限制了模塊可使用的其他模塊，如 window，document；其次 require 在使用模塊時只會傳入 require 和 module，也就是說參數(shù)中的其他模塊在定義的模塊中都是 undefined，這也是不能在開發(fā)者工具中獲取一些瀏覽器環(huán)境對象的原因。

在小程序中，JavaScript 代碼的加載方式和在瀏覽器中也有些不同，其加載順序是首先加載項目中其他 js 文件（非注冊程序和注冊頁面的 js 文件），其次是注冊程序的 app.js，然后是自定義組件 js 文件，最后才是注冊頁面的 js 代碼。而且小程序?qū)τ谠?app.js 以及注冊頁面的 js 代碼都會加載完成后立即使用 require 方法執(zhí)行模塊中的程序。其他的代碼則需要在程序中使用 require 方法才會被執(zhí)行。

下面詳細介紹了 app.js，自定義組件，頁面 js 代碼的處理流程。

4、加載 app.js 與注冊程序

在 app.js 加載完成后，小程序會使用 require('app.js') 注冊程序，即對 App 方法進行調(diào)用，App 方法是對 __appServiceEngine__.App 方法的引用。

下圖是框架對于 App 方法調(diào)用時的處理流程：

App 方法根據(jù)傳入的對象實例化一個 app 實例，其生命周期函數(shù) onLaunch 和 onShow 因為使用不同的方式獲取 options的參數(shù)。在有些需要根據(jù)場景值來實現(xiàn)需求的，或許使用 onShow 中的場景值更合適。

在實際開發(fā)過程中發(fā)現(xiàn)，在微信頂部喚起小程序和在小程序列表喚起的 options 也是不一樣的。在該案例中通過點擊分享的小程序進入后，關(guān)閉小程序，再通過不同方式進入小程序，通過頂部喚起的還是 options 的 path 屬性還是分享出來的 path，但是通過列表中打開直接回到了首頁，這里 App 中的 onShow 就會獲取到不同的 options。

5、加載自定義組件代碼以及注冊自定義組件

自定義組件在 app.js 之后被加載，小程序會在這個過程中加載完所有的自定義組件（分包中自定義組件沒有有測試過），并且是加載完成后自動注冊，只有注冊完成后才會加載下一個自定義組件的代碼。

下圖是框架對于 Component 方法處理流程：

圖中介紹了框架如何對傳入 Component 方法的對象的處理，其后面還有很多深入的對于組件實例化的步驟沒有在圖中表示出來，具體可以在文章最后的附件中查看。

自定義組件在小程序中越來越完善，其擁有的能力也比 Page 更強大，而后面會提到在使用自定義組件的 Page 中，Page 實例也會使用和自定義組件一樣的實例化方式，也就是說，他擁有和自定義組件一樣的能力。

6、加載頁面代碼和注冊頁面

加載頁面代碼的處理流程和加載自定義組件一樣，都是加載完成后先注冊頁面，然后才會加載下一個頁面。

下圖是注冊一個頁面時框架對于 Page 方法的處理流程：

Page 方法會根據(jù)是否使用自定義組件做不同的處理。使用自定義組件的 page 對象會被處理為和自定義組件的結(jié)構(gòu)，并在頁面實例化時使用不同的處理流程進行實例化。當(dāng)然對于開發(fā)而言沒任何不同。

從圖中可以發(fā)現(xiàn) Page 傳入的（生命周期）代碼并不會在這里被執(zhí)行，可以通過下面小節(jié)了解 Page 實例化的詳細過程。

7、等待頁面 Ready 和 Page 實例化

還記得上面介紹的啟動流程中最后一步等待頁面 Ready？嚴格來講是等待瀏覽器 Ready，小程序雖然有部分原生的組件，不過本質(zhì)上還是一個 web 程序。

在小程序中切換頁面或打開頁面時會觸發(fā) onAppRoute 事件，小程序框架通過 wx.onAppRoute 注冊頁面切換的處理程序，在所有程序就緒后，以 entryPagePath 作為入口使用 appLaunch 的方式進入頁面。

下圖是處理導(dǎo)航的程序流程：

從圖中可以看出頁面的實例化是在進入頁面時進行，下圖是具體的實例化過程：

下圖是最終可得到 Page 實例：

可以發(fā)現(xiàn)其中多了 onRouteEnd API，實際該接口不會被調(diào)用。其中以 component 標(biāo)記的表示只有在使用了自定義組件時才會有的方法和屬性。在前面第 5 小節(jié)提到了對于使用自定義組件的頁面會按照自定義組件方式解析，這些屬性和方法與自定義組件表現(xiàn)一致。

8、關(guān)于 setData

小程序框架是一個以數(shù)據(jù)驅(qū)動的框架，當(dāng)然不能少了對他如何實現(xiàn)數(shù)據(jù)綁定的探索，下圖是 Page 實例的 setData 執(zhí)行流程：

其中 component:setData 表示使用自定義組件的 Page 實例的 setData 方法。

三、寫在最后

這是一次不完全的小程序框架探索，是在微信開發(fā)工具中 debug 的結(jié)果。雖然對于實際開發(fā)沒有什么太大的幫助，但是對框架如何對開發(fā)的 js 代碼進行處理有了一個很明確的認識，在使用一些 js 特性時可以有明確的感知。如果你還疑惑“小程序框架對傳入的對象等到底做了什么”那一定是我表達能力太差，說聲對不起。

通過這一次 debug ，也給我引入了新的問題，還希望能夠有更多的討論：

• 自定義組件太多啟動時會耗時處理自定義組件
• 文件太多會耗時讀文件
• 合理的設(shè)計分包很重要

一份在調(diào)試過程中的筆記 小程序框架不完全分析.xmind ，如果看官有興趣可以下載看看。當(dāng)然最后對于框架中已有的能力，還是分層希望微信可以開放更多穩(wěn)定的接口，并在文檔中告知開發(fā)者，讓開發(fā)變得簡單一些。

 

來自：https://tech.youzan.com/weapp-booting/

 

標(biāo)簽： 代碼 開發(fā)者

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。