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

 

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

　　21號晚上正和朋友一塊兒打牌，可貴的小七對剛剛定口，忽然間手機傳來了「叮咚」的消消息提示音，隨後就是「叮叮，咚咚」的連續震動。打開手機一看，微信上一堆人發信息給我，先是一篇《微信應用號來了》，而後就是：「你怎麼看?」

　　雖然以前曾經獲得過消息說「微信應用號」會在年末發佈，但沒想到竟然來的這麼快，並且還更名叫「微信小程序了」(簡稱小程序)。已經無意打牌，趕忙完成一吃三後速度回到電腦前開始了持續幾天的研究。並且這幾天裏各類相關資料都開始相繼出現，內測用的開發工具也有破解版漏出了。

　　身邊已經有很多朋友已經根據資料開始幹活了，差很少有以下幾類：

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

　　2)公司有一打的服務號，其實改爲小程序會更合適(管它合不合適，改了再說!)

　　3)又是一輪洗牌的機會!那個公衆號的功能是我先想到的但被別人搶了，此次我要在小程序裏第一個作出來並作到第一名!

　　4)微信果真是互聯網的「國務院」，新政策草案剛出馬上引發全行業的連夜研究。這麼重要的關頭，變革的前夜，我認爲正確的作法是「戰術上馬上響應，站略上沒必要着急」。不學習，不瞭解微信小程序是萬萬不行的，但馬上根據如今的資料，調整公司的方向，也有點爲時過早。畢竟如今還在內測階段，萬一內測結果是「回爐重造」或則「大幅調整」(目前泄漏的資料已經處於正式發佈的狀態，應該不會大改了)，那花在這裏的時間都賠進去了還沒地哭。因此我以爲對公司來講比較合理的作法是在馬上成立一個短時間的臨時小組，鼓勵對小程序有興趣的同窗加入，一塊兒開發幾個有趣的小程序，主要目的就是學習。若是作出來的結果好還能賺一波眼球。等微信小程序正式公測了，再決策要不要把這個臨時小組升級成一個正式的產品團隊。

　　這幾天經過目前公開的資料我已經對小程序的總體架構有了個初步的認識。個人風格一貫是從架構和系統設計的視角作一些深度的，有觀點的分析。如今終於能夠迴應朋友們的問題，談談我怎麼看了。

　　微信小程序是什麼?

　　官方這麼說：

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

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

　　能夠看到，騰訊仍是很是有誠意的，此次在微信小程序上新開放的能力不少，再也不是漸進式的演變而有一點像革命了。

　　小程序的入口在哪?

　　目前公開的資料裏對你們最關係的入口問題只提到了小程序能夠掃二維碼打開，因而業界對小程序的入口有了這麼幾種流行的假設：

　　假設零：朋友圈，朋友能夠把本身喜歡的小程序分享在朋友圈，看到了能夠點擊打開直接使用。

 

 

　　可能性:99%。小程序不能出如今朋友圈，流量從哪來?

　　假設一：出如今發現tab頁面中，遊戲下面(每一個小程序佔用一列)，同時搖一搖也能夠獲得附近的小程序

 

 

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

　　假設二：和當前的公衆號、服務號相似，安裝出如今會話列表

 

 

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

　　假設三：安裝後和native app同樣，直接出如今桌面

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

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

 

 

　　可能性:1%。多一個tab太醜了，並且小程序剛發佈，不可能馬上就對微信的總體結構產生影響。

　　假設五：出如今一些內置流程中(好比和好友的聊天界面內，發朋友圈的界面(拍照後處理)

 

 

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

　　微信小程序框架淺析

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

　　先看框架的底層API部分。微信一直有一個貫穿的"JS-SDK"在不斷演進。對比一下小程序的底層API的功能範圍，和JS-SDK仍是有不少類似的感受，相信將來會在形式上達到統一(JS-SDK這名字也足夠霸氣，塞進去什麼都不會以爲奇怪。不過JS-SDK的不少接口設計的實在不敢恭維，但願此次統一的進程也能從新修正下)。小程序的API部分因爲能夠跳出瀏覽器的框架，理論上確定能夠是JS-SDK的超集。

　　這裏面我以爲比較有意思的地方有：

　　>>網絡通訊

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

　　既然跨域都支持了，沒準之後能像nodejs同樣，直接在小程序裏使用tcp,udp協議，並基於buffer有必定的二進制協議的開發能力。跳出HTTP協議的框架，對於IoT方向是頗有想象空間的。

　　>>數據緩存

　　數據緩存接口的設計看起來和 HTML5裏的localStorage基本上同樣，原本沒什麼好說的。但文檔裏的一句話引發了個人興趣：

　　「注意： localStorage 是永久存儲的，可是咱們不建議將關鍵信息所有存在 localStorage，以防用戶換設備的狀況。」

　　難道微信提供的數據緩存能力雖然不是永久的存儲，但能夠作到跟隨用戶帳號而不是當前設備? 也就是說，無論用戶怎麼換手機，已安裝使用過的小程序都能使用同一份緩存(不存在不登錄使用小程序的場景)?雖然微信本身的聊天記錄跨設備漫遊都沒作，但這種app personal file cloud的支持，仍是能在不增長開發的工做量的狀況下，大幅提高用戶體驗的(做爲一個steam的重度用戶我已經徹底離不開遊戲存檔的自動同步功能)。這也讓我對小程序在雲端的能力，開始有了一些初步的想象。

　　>>並不兼容一些常見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的可能性。

　　感謝各位關心。

本文連接:http://www.yixieshi.com/54848.html(轉載請保留)

做者： 三少爺的劍