作者：趙九州鏈接：如何評價 9 月 21 日開始內測的「微信小程序」？ - 趙九州的回答來源：知乎著作權歸作者所有，轉載請聯系作者獲得授權。筆者注：本文[配圖7]app.json 小程序配置： 小程序里一共包含哪些頁面。頁面套在一個怎么樣的 window里顯示。window是否需要支持多tab,支持的話每個tab的默認page是什么。一些底層組件的默認參數。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發展 數據波來助力-CSDN.NET“微信小程序的本質說來就是一個HTML5應用”“以后互聯網的發展方向可能更偏重于HTML5” 而有的人又認為我們真的需要“小程序”么？| HTML5老兵如是說 我們真的需要“小程序”么？“微信雖然用了 HTML5 技術來做應用號（正式名稱：小程序），但是它并沒有真正用到 HTML5 的精髓——開放、互聯，也就決定了它可能無法實現“微信OS”的最終野心。”這兩個觀點是矛盾的，那么，到底那種觀點是正確的呢？首先簡化一下問題，微信小程序是基于HTML5開發的么？ 通過分析小程序的運行原理，這個答案是明確的：小程序的開發過程會用到大量HTML5相關的技術,但并不是使用HTML5開發。有 HTML5經驗的前端工程師學習微信小程序的開發相對會更容易一些。微信小程序的運行并不需要一個完整支持HTML5特性的標準瀏覽器內核，但也可以通過添加一些輔助設施，讓小程序在個完整支持HTML5標準的瀏覽器上運行起來。 “由于框架并非運行在瀏覽器中，所以 JavaScript 在 web 中一些能力都無法使用，如 document，window 等。” 也就是說，一個已存在的HTML5頁面，并不能通過自動轉換工具變成一個合法的Page，而需要有工程師根據HTML5頁面的功能，使用MINA框架再實現一次。[配圖 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的具體平臺特性無關的。要面向更多的非專業開發者，所以學習門檻要低。大規模的專業團隊進行團隊開發時，能有足夠的工程支持。工程支持包括：模塊化代碼易于長期維護和修改。這意味著基于框架的實現具體需求的結果要足夠清晰，好讀。可復用性設計。小程序不需要安裝就可以快速開始使用，只需要加載必要的資源就可以盡快展現用戶需要的頁面。進一步思考這些需求該如何解決，并對不同的解決方案進行評價需要的領域知識非常多，已經超過了本文的討論范圍。我在這里要做的只是帶你入門，讓你開始思考設計問題就夠了。這也是本文的核心目的：學會對新技術，新設計進行獨立的分析和判斷。至于結果么，現在小程序還處于一個早期的狀態，等公測了之后在下結論也不遲。微信小程序的未來？ 雖然現在小程序開放的功能并不豐富，處于一個早期的狀態，但結合上面的觀點去看微信小程序的設計，還是能從中讀到許多遠大的理想。而微信的核心愿景之一是“連接一切”，沒準小程序是騰訊實現這個愿景道路上的重要一步。有超過7億用戶的微信如果成為一個新的平臺，具有不可忽視的能量，下面讓我來對小程序的下一步動作做一些無責任的預測吧。假設一、微信小程序未來會解決應用內搜索的問題目前小程序規范的頁面結構很方便實現應用內搜索。以后使用微信的搜索功能可以直達小程序內部的某個特點內容頁面。這種規范的設計也方便實現小程序之間的互相訪問，可以通過一個類似wxapp://appid/pageid/的URL直接導航到另一個小程序的某個特定頁面。這是App時代的超連接系統，App的信息孤島也許就此打破。假設二、微信小程序會從本地數據讀取開始，進化出一定的云端API. 現在小程序只提供了前端的開發功能，但從整體邏輯上已經包含了應用的上傳，審核，發布流程。以后騰訊也許會為小程序提供托管服務（https://www.qcloud.com/act/event/yingyonghao.html），讓應用開發者可以用更少的精力完成一個完整小程序的開發，而不需要去管服務器申請，后臺開發，服務器運維等反繁瑣的工作，進一步降低一個真正小程序的開發門檻。我相信微信一定有團隊在為這個方向努力，但最終實現目標需要更有創造力的云端API設計，這是需要有大智慧的工作。假設三、使用小程序連接一切我并不認為小程序只是一個體驗更好的服務號。張小龍說小程序是“觸手可及”，“用完即走”，“無處不在”的。那么什么場景會需要這種能力? 我覺得“有復雜程序的低頻商業行為”會有這種需求。舉兩個實際的例子：例1：有一間智能會議室，入口處有一個二維碼。會議室的使用者掃描后可以打開一個小程序，通過這個小程序可以更好的訪問、控制會議室的各種設備，比如燈光，窗簾，幕布等。例2：去體檢，體檢表上有個二維碼，掃描后打開一個小程序，通過這個小程序可以更好的引導用戶自助完成自己的體檢項目。這兩個場景的需求能通過小程序解決，意味著小程序的種類極大豐富，硬件廠商對微信生態的極大支持。我們可以通過小程序簡單方便的進入各種陌生的環境，讓生活更加智能。未來已經悄悄敞開了大門。而如何更好更快的探索小程序的可能性，也將是我接下來創業的方向。我將以火速移動技術顧問的身份，和小伙伴們一起從微信小程序開始，去探索移動Web的可能性。感謝各位關心。

幾天了，沒心情細分代碼我猜測是，js->bridge->系統，然后，系統->bridge->jswebviewbridge這個東西，前端方面我稍微寫過一點，以這個為基礎猜的。微信應用號充當了bridge的功能如果是這樣，性能可以和客戶端媲美，但是組件的定制性差，因為組件是調取系統的不好改。也可能調用的不是系統組件而是微信寫在微信app內的組件，這樣的話定制問題就可以等微信慢慢開放接口了。待我睡醒細看。

塊級元素用了本地組件繪制，普通組件兼容WEB js封裝底層 提供接口 類似Hybird App 比普通web APP性能好 開發飛機大戰之類的社交小游戲 妥妥的 性能沒問題。

通過網頁代碼調用原生的api/控件，然后一堆限制，始終不理解為什么這些程序員不自己寫個移動網站，非要鉆微信的籠子，沒有性格沒有下限。

瞎猜的：用Native抹平了系統間的差異，搞套DSL把系統的API暴露給前端開發。可以理解為沒有編譯過程的React Native/Weex，有WebAPP的靈活性，又有接近Native的性能。

用js調用android和ios底層功能，用html5展示界面。性能比不上原生app

總結

以上是生活随笔為你收集整理的微信小程序底层的实现原理是怎样的? 财富值42的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。