微信小程序開發帶來的思考

若無小程序開發經驗，可先閱讀 玩轉微信小程序 一文。

微信小程序正式上線已有幾周時間，相信它的開發模式你已爛熟於胸，可能你也有所疑問，我竟能用 web 語言開發出如此流暢的幾乎原生體驗的應用。可能你又會猜這不就是 h5 麼，厲害點的想不就是 hybrid 麼。可是在咱們的開發旅途中至始至終都沒有使用過 webview ，爲啥呢？開發時用的 view 一類的標籤，瀏覽器又是怎麼解析成頁面的呢？帶着重重疑惑，進入微信小程序源碼分析吧！

開發平臺

這個 IDE 是如何保證咱們小程序的開發和預覽的？簡要分析兩點。

1. 文件目錄

打開 微信web開發者工具目錄 ，進入 package.nw ，嗯？熟悉的味道來了。裏面就3個文件：app ，node_modules，package.json 。顯然咱們開發時構建階段所用資源來自於 node_modules ，因而我嘗試找下 react模塊，結果沒有收穫...

進入 app 目錄下，呈現的四個文件夾分別是：html ，style ，images ，dist 。而你開發時使用的 IDE 的實現正是經過這些文件，不妨用瀏覽器打開其中一個 html 看看。

這不就是從桌面打開後看到的效果嗎（其中 nodeWebkit 提供了 web 到桌面應用的轉換）。而且在 index.html 中找到咱們的主腳本文件 ../dist/app.js ，整個 IDE 從編輯，開發，預覽，發佈等一系列操做都在 app.js 及其引用的腳本中。

2. 邏輯關係

接下來開始分析下 dist 下有什麼鬼。 不要怕，也就幾十行的源碼。

不過每行都是壓縮事後的而已...好吧，丟去反壓縮一下。在 Sublime Text3 中裝一個 jsFormat 的插件，對要格式化的代碼進行 Ctrl + Alt + F 便可，接下來對咱們的文件進行一個邏輯劃分。

顯然，微信小程序 IDE 自己是用 React 組件而且以 Flux 的架構來構建的，那咱們所編寫的小程序又是如何運行起來的呢？首先從 ./app/dist/components/sidebar/sidebar.js 開始看起，找到 React Render 出的 restart 按鈕(編譯按鈕的上方)。

// sidebar.js a.createElement('div', { className: 'sidebar-item sidebar-item-sep' }), a.createElement('div', { className: 'sidebar-item-toolbar', style: p }, a.createElement(g, null), a.createElement('div', { title: `${'darwin'===process.platform?'Command':'Ctrl'} + b`, onClick: this.handleAppRestart, className: 'sidebar-item', style: { paddingBottom: 0 } }, a.createElement('i', { className: 'sidebar-item-icon sidebar-item-icon-reset' })); 

每當點擊這個按鈕時，IDE 都會從新展示當前 app 。因此這個 handleAppRestart 就是關鍵之處了。

頁面構建

1. 構建流程

觸發 handleAppRestart 的 200ms 後會調用 ./actions/projectActions.js 中的 restart 方法，構建流程正式開始。

// sidebar.js handleAppRestart: function(l) { clearTimeout(j), j = setTimeout(() => { e.restart(this.props.project); // e爲projectActions.js輸出對象 let m = 'edit' === this.props.show ? `project_compile` : `project_restart`; i(m, this.props.project.appid) }, 200) } 

在 projectActions.js 中，能夠清楚的看到 flux 架構的部分 actions ，這些 actions 都會隨着 dispatch 傳入到 store 當中，進行一個狀態的改變，最後從新渲染到應用中。

// projectActions.js del: function(b) { a.dispatch({ actionType: 'DELETE_PROJECT', projectid: b }) }, add: function(b, c) { a.dispatch({ actionType: 'ADD_PROJECT', project: b, needInitQuickStart: c }) }, close: function(b) { a.dispatch({ actionType: 'CLOSE_PROJECT' }) }, restart: function(b) { a.dispatch({ actionType: 'RESTART_PROJECT', project: b }) } 

projectActions.js 的每個 action 都會經過 projectDispatcher.js 映射到 projectStores.js 中，應用的 restart ，add方法在 store 中也有具體實現。

add: function(F, G) {
    F.hash = a(F.projectid), F.es6 = !0, F.watcher = !0, F.editWebview = !0, F.newFeature = { time: Date.now(), show: !1, check: !1 }, F.initPath = { enable: !1 }, F.uploadPath = { enable: !1 }, w.unshift(F), c(F, G), b(), h.info(`projectStores.js add ${JSON.stringify(F)}`), this.emit('ADD_PROJECT', w) }, close: function() { this.emit('CLOSE_PROJECT') }, restart: function(F) { this.emit('RESTART_PROJECT', F) }, 

對於 Flux，若是還不清楚，這張圖能夠作個簡單的詮釋。nw 中用的是 facebook 官方給出的 Flux 架構，github 上比較活躍的 redux 和 mobx 都是比較好用的狀態管理架構。

2. 三端運行

在未安裝 android/ios sdk 時，咱們的 app 依然可以呈如今 IDE 中，此時是經過雲端的 webpack 將 .wxml，.wxss，.js 轉換成 nw 可解析的 html，css，js 。固然在 android/ios 的微信客戶端上，依然能夠訪問，這即是 Write Once, run anywhere ，因此微信小程序和阿里 weex 是殊途同歸的，只不過微信小程序的 API 都是基於微信的。

以 IOS 爲例

微信小程序與傳統 hybrid 使用 webview 不一樣，後者是提供了 stringByEvaluatingJavaScriptFromString 方法讓 js 能在當前 context 上執行，實質上仍是 web 應用。而前者是經過 JsBrigde 定義模塊的方法映射到 OcBrigde 中，調用 native module ，其中還有不少回調，但其實質上是 native 應用。

native化

在你工做或者實習公司的前端組，可能已經出現了 native 化這些目標，這給公司客戶端人員帶來了不小的危機感，的確，前端能作的事愈來愈多(依託於強大的開源社區)。

在合適的應用場景下，好比頻率通常流量不大的產品上，native 化的確是很好的選擇，由於對於業務複雜度高以及產品須要頻繁更新迭代的公司來說能夠很大的提高開發效率，一個前端工程師能完成曾經一個前端+一個android客戶端+一個IOS客戶端須要完成的任務，同時又能避開屢次發版的痛點，因此native 化將是前端將來幾年一個必修的方向。

那它究竟帶來了哪些好處，之於 web app ， native app 以及 hybrid app 又有哪些優點呢？

更低的開發成本

Write Once, Run Anywhere ，只要你會 Web 技術，一樣也能開發出 native 應用。這大大下降了前端開發者進入原生開發領域的門檻。

比 hybrid 更接近原生的用戶體驗

解決了傳統 Webview 帶來的性能瓶頸，由於調用的是原生的模塊，而非直接執行 js 腳本。

解決 native 頻繁發版問題

對於敏捷開發的團隊來講，爲了能快速上線產品，一個版本的迭代週期可能幾天就好了，因此發佈新版本就成了一個新問題，有時新版本完成開發，而上一個版本尚未完成審覈。而對於用微信小程序/ weex / React Native 開發的 app 只須要加載 jsbundle 便可，這個文件是能夠隨時更新，從而 app 就能夠避免從新發布。