迅雷首席架構師劉智聰：微信小程序的架構與系統設計的幾點觀感

筆者注：本文來自于迅雷首席工程師劉智聰的個人分享，他畢業于南昌大學化學系，加入迅雷后設計開發了多款迅雷核心產品，憑借“大規模網絡流媒體服務關鍵支撐技術”項目獲得2015年國家科學技術進步獎二等獎，同時也是第四代UI交互技術-----BOLT 界面引擎的發明人，目前擔任WebApp解決方案商--火速移動的首席技術顧問。

21號晚上正和朋友一起打牌，難得的小七對剛剛定口，突然間手機傳來了“叮咚”的消消息提示音，隨后就是“叮叮，咚咚”的連續震動。打開手機一看，微信上一堆人發信息給我，先是一篇《微信應用號來了》，然后就是：“你怎么看？”

雖然之前曾經得到過消息說“微信應用號”會在年底發布，但沒想到居然來的這么快，而且還改名叫“微信小程序了”（ 簡稱小程序 ）。已經無心打牌，趕緊完成一吃三后速度回到電腦前開始了持續幾天的研究。而且這幾天里各種相關資料都開始相繼出現，內測用的開發工具也有破解版漏出了。

身邊已經有不少朋友已經根據資料開始干活了，差不多有如下幾類：

1. 1）好好釋放想象力，要是能在公測的時候做個有趣的小程序出來一炮而紅那就賺大了

2. 2）公司有一打的服務號，其實改成小程序會更合適（ 管它合不合適，改了再說！ ）

3. 3）又是一輪洗牌的機會！那個公眾號的功能是我先想到的但被別人搶了，這次我要在小程序里第一個做出來并做到第一名！

4. 4）微信果然是互聯網的“國務院”，新政策草案剛出立刻引起全行業的連夜研究。這么重要的關頭，變革的前夜，我認為正確的做法是“戰術上立刻響應，站略上不必著急”。不學習，不了解微信小程序是萬萬不行的，但立刻根據現在的資料，調整公司的方向，也有點為時過早。畢竟現在還在內測階段，萬一內測結果是“回爐重造”或則“大幅調整”（ 目前泄漏的資料已經處于正式發布的狀態，應該不會大改了 ），那花在這里的時間都賠進去了還沒地哭。所以我覺得對公司來說比較合理的做法是在立刻成立一個短期的臨時小組，鼓勵對小程序有興趣的同學加入，一起開發幾個有趣的小程序，主要目的就是學習。如果做出來的結果好還能賺一波眼球。等微信小程序正式公測了，再決策要不要把這個臨時小組升級成一個正式的產品團隊。

這幾天通過目前公開的資料我已經對小程序的整體架構有了個初步的認識。我的風格一向是從架構和系統設計的視角做一些深度的，有觀點的分析。現在終于可以回應朋友們的問題，談談我怎么看了。

微信小程序是什么？

官方這么說：

“我們提供了一種新的開放能力，讓開發者可以快速地開發一個小程序。小程序可以在微信內被便捷地獲取和傳播，同時具有出色的使用體驗”。

聽起來非常美好，咱們具體一點，結合目前公開的信息和微信目前其它的開放形式對比一下吧

可以看到，騰訊還是非常有誠意的，這次在微信小程序上新開放的能力很多，不再是漸進式的演變而有一點像革命了。

小程序的入口在哪？

目前公開的資料里對大家最關系的入口問題只提到了小程序可以掃二維碼打開，于是業界對小程序的入口有了這么幾種流行的假設：

假設零：朋友圈，朋友可以把自己喜歡的小程序分享在朋友圈，看到了可以點擊打開直接使用。

可能性:99%。小程序不能出現在朋友圈，流量從哪來？

假設一：出現在發現tab頁面中，游戲下面（ 每個小程序占用一列 ），同時搖一搖也可以得到附近的小程序

可能性:80%。和一把騰訊的游戲擠在一起，不虧待你吧。

假設二：和當前的公眾號、服務號類似，安裝出現在會話列表

可能性:90%。新的開放能力和舊的開放能力用一樣的入口不奇怪吧。

假設三：安裝后和native app一樣，直接出現在桌面

可能性:10%。和微信在同一級入口，騰訊同意Apple都不一定同意。

假設四：微信多一個小程序的tab

可能性:1%。多一個tab太丑了，而且小程序剛發布，不可能立刻就對微信的整體結構產生影響。

假設五：出現在一些內置流程中（比如和好友的聊天界面內，發朋友圈的界面（拍照后處理）

可能性:1%。小程序和微信本體使用不同的框架技術開發，互相嵌套有困難。

微信小程序框架淺析

官方已經正式公開了小程序的開發資料 ，小程序的開發框架包含兩大塊內容，分別是：API 與 組件。官方的資料在組織和內容上都寫的還不錯，閱讀體驗也很順暢，沒看過的話推薦先簡單的通讀一遍。基本上有一定經驗的前端開發都可以沒有什么障礙的掌握目前資料里的內容，我就不去做入門性的介紹了，直接淺析吧。

先看框架的底層API部分。微信一直有一個貫穿的quot;JS-SDKquot;在不斷演進。對比一下小程序的底層API的功能范圍，和JS-SDK還是有很多相似的感覺，相信未來會在形式上達到統一( JS-SDK這名字也足夠霸氣，塞進去什么都不會覺得奇怪。不過JS-SDK的很多接口設計的實在不敢恭維，希望這次統一的進程也能重新修正下 )。小程序的API部分由于可以跳出瀏覽器的框架，理論上肯定可以是JS-SDK的超集。

這里面我覺得比較有意思的地方有：

gt;gt;網絡通信

只要目標服務器的域名在小程序配置的安全列表之類，就可以直接通信。不用考慮js的跨域問題了。

既然跨域都支持了，沒準以后能像nodejs一樣，直接在小程序里使用tcp,udp協議，并基于buffer有一定的二進制協議的開發能力。跳出HTTP協議的框架，對于IoT方向是很有想象空間的。

gt;gt;數據緩存

數據緩存接口的設計看起來和 HTML5里的localStorage基本上一樣，本來沒什么好說的。但文檔里的一句話引起了我的興趣：

“注意：localStorage 是永久存儲的，但是我們不建議將關鍵信息全部存在 localStorage，以防用戶換設備的情況。”

難道微信提供的數據緩存能力雖然不是永久的存儲，但可以做到跟隨用戶賬號而不是當前設備？ 也就是說，不管用戶怎么換手機，已安裝使用過的小程序都能使用同一份緩存（ 不存在不登陸使用小程序的場景 ）？雖然微信自己的聊天記錄跨設備漫游都沒做，但這種app personal file cloud的支持，還是能在不增加開發的工作量的情況下，大幅提升用戶體驗的（ 作為一個steam的重度用戶我已經完全離不開游戲存檔的自動同步功能 ）。這也讓我對小程序在云端的能力，開始有了一些初步的想象。

gt;gt;并不兼容一些常見js底層框架

小程序的官方QA里有一段話：

zepto/jquery 會使用到window對象和document對象，所以無法使用

這意味著所有基于HTML5的已有底層代碼資產，并不能完全無縫的遷移過來。不過連jQuery這么常用的庫都不能兼容還是有一點傷的。當然，現在用裁剪或兼容的方法，提供能在小程序平臺運行的常見js底層庫，短期內會很有市場。

MINA框架剖析

接下來我要解讀微信小程序提供的界面部分功能，也是最令人興奮的部分。一個小程序，必須基于MINA框架（ 從泄漏的資料里得知這個框架叫MINA,正式的資料里刪除了這個名字，但為了后面行文方便，我會一直把小程序的應用框架稱之為MINA ）構建。一個典型的小程序的結構如下：

app.json 小程序配置：

1.小程序里一共包含哪些頁面。

2.頁面套在一個怎么樣的 window里顯示。

3.window是否需要支持多tab,支持的話每個tab的默認page是什么。

4.一些底層組件的默認參數。

app.js（ 可以理解為入口函數 ）處理app的幾個關鍵事件:onLaunch,onShow，定義了app級（ 可以在不同的頁面之間共享 ）的數據的格式。

app.wxss 公用樣式表：每個頁面的樣式表，都是從這個應用級公有樣式表繼承下來的。

MINA一個最主要的核心概念是Page，一個Page是應用內可以導航到的最小粒度的界面。而如何構建Page是與大家過去猜測差別最大的地方。微信并沒有使用HTML5，而是提供了一套新的設計。新的設計要求每個 Page由3個文件構成：

index.js :包含Page的邏輯處理代碼，其中比較重要的就是定義Page的數據（ wxml可以通過數據綁定機制直接訪問 ）

index.wxml : Page的布局文件。隨便從demo中選一個布局文件來看，其整體結構非常簡介清晰，即使沒有提供任何資料也大概能看出來表達了一個什么樣的頁面。

.wxml不算是完全的靜態布局文件，還支持條件渲染和列表渲染。.wxml使用{{}}語法來簡單直接的支持數據綁定。可以通過template的方法進行復用

index.wxss: 樣式表。決定了在wxml中定義的各種組件最終應該如何顯示。官方文檔并沒有列出wxss的selector語法和支持的style，只是說“具有CSS的大部分特性”，wxss樣式表里也擴展了一些微信小程序專用的樣式是屬性。

Page的整體設計上有比較明顯的“反應式”編程風格，相信有vue.js,angularJS，reactive.js開發經驗的同學可以很快上手。由于沒有內測資格所以沒法在手機上測試性能，不清楚小程序的這套框架有沒有反應式編程常見的性能問題。這個等公測后寫個有10萬條數據的列表，看看滾動流不流暢就知道了。

目前demo沒有使用ES6，所以看起來沒那么“現代化”，這也可能是因為小程序這個項目立項比較早的緣故吧。不過ES6是大勢所趨，相信未來小程序會支持使用ES6開發。

一個基于MINA的小程序最后是如何跑起來的呢？

官方這么說：

開發者寫的所有代碼最終將會打包成一份 JavaScript，并在小程序啟動的時候運行，直到小程序銷毀。類似 ServiceWorker，所以邏輯層也稱之為 App Service。

網上已經有不少人通過琢磨開發工具的實現的方法，做了比較深度的研究了，推薦閱讀： 微信小程序「官方示例代碼」剖析【下】：運行機制

簡單的總結一下：

wxml文件通過編譯會得到html，wxss 文件通過編譯會得到css，分離的各個頁面的JS和App的主JS文件最終會打包在一起得到App Service。 開發狀態下運行小程序，基于blink內核，每個html會加載一些moko js用來支持框架功能。生產環境在手機上估計是運行在一個專用，定制的瀏覽器內核中。

為什么是MINA?

業界對目前微信使用的UI框架，有兩種截然相反的觀點：

微信“小程序”帶動HTML5發展 數據波來助力

“微信小程序的本質說來就是一個HTML5應用”

“以后互聯網的發展方向可能更偏重于HTML5”

而有的人又認為

我們真的需要“小程序”么？| HTML5老兵如是說

“微信雖然用了 HTML5 技術來做應用號（正式名稱：小程序），但是它并沒有真正用到 HTML5 的精髓——開放、互聯，也就決定了它可能無法實現“微信OS”的最終野心。”

這兩個觀點是矛盾的，那么，到底那種觀點是正確的呢？首先簡化一下問題，微信小程序是基于HTML5開發的么？

通過分析小程序的運行原理，這個答案是明確的：小程序的開發過程會用到大量HTML5相關的技術,但并不是使用HTML5開發。有 HTML5經驗的前端工程師學習微信小程序的開發相對會更容易一些。微信小程序的運行并不需要一個完整支持HTML5特性的標準瀏覽器內核，但也可以通過添加一些輔助設施，讓小程序在個完整支持HTML5標準的瀏覽器上運行起來。

“由于框架并非運行在瀏覽器中，所以 JavaScript 在 web 中一些能力都無法使用，如 document，window 等。” 也就是說，一個已存在的HTML5頁面，并不能通過自動轉換工具變成一個合法的Page，而需要有工程師根據HTML5頁面的功能，使用MINA框架再實現一次。

搞清楚MINA和 HTML5的關系后，我們還是沒有搞清楚為什么微信要提供一個新的MINA框架 。事實上這個問題是一個討論設計的問題，所以要回答這個問題，需要具備一定的設計能力，而不是只是停留在研究MINA實現的層面。而設計能力，是一種比較稀缺的能力。

想要系統的提升自己的設計能力，簡單的來說就是“多看 多想”，那么如何多想呢？我有一套還算完整的方法的，簡單來說有如下幾步：

首先，在研究一個新東西以前，先想想這個新東西，是為了解決什么樣的問題出現的。問題要多提，往深了提，反復提煉，最后得到幾個好問題。或則從一個問題，引申出一些子問題。很多時候只要問題提對了，設計就明白了大半。

下一步就是試著自己解決一下，回答一下自己提的問題，并比較不同的解決思路的優劣，形成一個對問題解的標準。比如說問題是“如何在一個超長文本中查找子串？” 那么對問題的評價標準就可以是查找速度，以及查找過程中的內存占用。

接下里就是看別人是如何解決這些問題的了。如果和自己的設計差不多，一邊竊喜一邊開始按自己預先設計的評價標準對別人的設計的好壞進行判斷。如果是自己完全沒想到過的解法（這通常會出現在第一次接觸某個領域問題），可以按圖索驥的補充一些基礎知識，再回來看。如果這個領域或解法非主流到不是常見范式，那么可以安下心來好好搞清楚，想明白。 這樣帶著問題研究設計，才能有效的提高自己的設計能力。

介紹完套路后咱們回到正題：我們如何來評價微信小程序選擇MINA框架？讓我來持續提問吧。

第一個問題：“為什么微信小程序不使用HTML5而是使用MINA來構建Page？”

不用HTML5我可以提供一個非技術答案：微信需要通過這種方法來轉化開發者，這些開發者未來會逐漸演變成“微信OS平臺”的忠實開發者。其實開發者通常都有患有“斯德哥爾摩綜合癥”，一旦在一個平臺上投入了智力資源進行學習，就會開始下意識的維護這個平臺（ 比如看不到平臺的缺點，只看到平臺的優點 ）。如果使用HTML5作為開發方式，那么現在小程序聚攏的開發者都是為了流量來的，并沒有投入額外的學習成本，對平臺不夠忠誠。而微信要成為OS是一個長期的演變過程，那么現在就要通過要求學習一個新的開發框架的方法開始多轉化一些忠誠的開發者。

當然是不是這個原因也只有張小龍自己知道了，這是一個揣摩動機的答案，所以沒有評價標準。問題終結。

為什么不用HTML5的技術答案可以是非常庸俗的。畢竟業界對于HTML5技術的優劣討論已經持續了一段很長的時間了。但基本上，大家認為HTML5的主要缺點集中在性能上：同樣的交互，用HTML5實現需要更多的系統資源，也可能會不夠流暢。同時，應用還需要集成一個非常巨大的瀏覽器內核。

這個答案盡管能讓大部分人滿意，但實際上是非建設性的（ 這些對HTML5性能的結論，是別人告訴你的 ）。大家一邊相信HTML5的美好前景，一邊把對性能問題的解決寄托于幾家傳統的瀏覽器廠商。按我們的套路，這個性能問題再往深了問是這樣的：“渲染指定頁面最少需要多少資源？”，“在當前硬件水平下，渲染指定頁面最快需要多少時間？”，“實現一個完整支持HTML5標準的瀏覽器內核，需要大概多少代碼？”。

要回答這些問題就需要了解瀏覽器的實現了，這不會是一件容易的事情，在閱讀瀏覽器的實現的時候，肯定會持續提出針對HTML的設計問題。最終你會對瀏覽器廠商什么時候能解決性能問題，得到一個更合理的預期：至少在5年內，HTML5的性能是不夠的。

雖然SAY NO的理由，有一條就夠了。但如能從其它角度思考一下為什么不是HTML5,可以得到一些更有建設性的答案。

第二個問題：“MINA作為一個新框架，為什么會設計成現在的樣子？”

可以肯定的是，這是MINA的架構師在綜合了多個因素后，拿出來的一個自己最滿意的答案。所以這是一個非常有建設性的問題，思考這個問題的時候，就開始逐步代入MINA的架構師視角了。

讓我們一起進入MINA架構師的角色，首先在否決了HTML5后，要設計一個什么樣的框架來支持小程序的交互開發？第一步就是要給這個新框架提一些基礎性的目標與需求。

這是一個現代化的框架，在最終表現力上要足夠好。

小程序跑在微信里，所以必然是和android,iOS的具體平臺特性無關的。

要面向更多的非專業開發者，所以學習門檻要低。

大規模的專業團隊進行團隊開發時，能有足夠的工程支持。工程支持包括：

模塊化

代碼易于長期維護和修改。這意味著基于框架的實現具體需求的結果要足夠清晰，好讀。

可復用性設計。

小程序不需要安裝就可以快速開始使用，只需要加載必要的資源就可以盡快展現用戶需要的頁面。

進一步思考這些需求該如何解決，并對不同的解決方案進行評價需要的領域知識非常多，已經超過了本文的討論范圍。我在這里要做的只是帶你入門，讓你開始思考設計問題就夠了。這也是本文的核心目的：學會對新技術，新設計進行獨立的分析和判斷。至于結果么，現在小程序還處于一個早期的狀態，等公測了之后在下結論也不遲。

而如何更好更快的探索小程序的可能性，也將是我接下來創業的方向。我將以火速移動技術顧問的身份，和小伙伴們一起從微信小程序開始，去探索移動Web的可能性。

感謝各位關心。

關注微信公眾號虎嗅網（huxiu_com），定時推送，福利互動精彩多