筆者注：本文[配圖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的可能性。感謝各位關心。

我個人并不是很看好。html5，js以及類似的技術替代原生大家喊了很久了，就是大熱的react native目前看來也依然很不完善。微信的應用應該都是運行在騰訊瀏覽器的X5內核里，這東西怎么樣大家心里也都有數。我感覺還是只能做一些低交互的應用，大概也就是比網頁快捷方式高一級別，要利用os的炫酷特性，原生還是跑不掉，而且目前原生開發很成熟了，框架庫很多，門檻也很低。對于不用下app省空間我不是很理解，只不過是把app浪費的空間挪動到微信里而已。微信所倡導的用完即走的理念也只有騰訊有資本裝b才會這么說，其它公司無論如果始終還是會想辦法更多的占用用戶的時間。騰訊現在原本就掌握了渠道，現在連app的審核等生殺大權也都掌握，你說蘋果惡心，但他起碼還勉強算公平，而騰訊可以隨便打著為了用戶（和你媽說為了你好）進行系統抖動，非騰訊系全都會抖，想怎么搞你怎么搞你。結局都是類似的，中小型公司都很激動，以為有了小應用他們就有了騰訊爸爸的幾億用戶，這種幻覺很美好，但他們可能會面臨更加慘烈的競爭，變成臨時解決用戶欲望的千斤頂，以及騰訊渠道那可怕的推廣分成費用。大公司肯定都很不情愿的跟進，又沒辦法，估計會簡單開發一些應用，然而盡可能的往自己原生的app上導入，心態很微妙，不過短期內肯定會先爆發一波星座血型算命起名你的前世今生顏值計算能活多少歲等一些QQ空間喜聞樂見的低質量辣雞應用，目前也不知道騰訊審核時是否會做一些限制。微信也許已經不是聊天軟件了，我朋友偶爾用了一下QQ，驚嘆的說，QQ真好用呀，聊天記錄都能自動存下來! 微信當初也許吸引大家的是我們只想要一個廣聊天的QQ，現在已經要變成微信os了，是不是以后也要走和當年QQ一樣的路？整個騰訊系全壓在這款app中？ 我不知道，在集團利益，業績增長的車輪下，什么張小龍王小龍，什么鬼的用戶體驗，什么產品經理說不的堅持，有多少碾碎多少。僅是個人一點感悟和粗淺看法，不太對請見諒

昨晚一推出應用號內測的消息，群里、朋友圈里就像陷入了一場狂歡一樣，仿佛每個人都是時候靠著這一波微信新機會逆襲了。然而我并不是太看好，我覺得顛覆世界是大部分人的YY，從入口的層級上來說就有問題。在對應的環境中做正確的事情才是對的，順勢而為，遵守這個系統的游戲規則，做這個生態里主人是更歡迎的事情，我這里會給出一些我的思考。----------------------------------------------------------------------------------------------------------------------關于微信昨晚推出內測小程序，我想大家已經在微信上看了足夠多的東西了，我這邊說說一些別人沒有思考到的點。應用號入口在哪里？這是各種文章中對于應用號的入口的預測。以“發現”版和“我”版為主要猜測方向如果是這樣一個入口我覺得是非常深了，讓我們來算一算如果是這樣一個入口，對于一個應用來說疊加了幾個層級第一層：消息界面 + 第二層：發現/我 界面 +第三層：應用號選擇界面 + 第四層：進入真正的應用里 +讓我們從用戶的使用場景來想象一下這個情況會造成的后果場景一：你正在操作一個應用然后收到一個人的消息，你去回復一下，然后回去再次進入這個頁面回到之前的位置，你的操作直至少需要4+x步（x為你操作到的位置），當然有一定的緩存（很有限），所以可能是4+x-n對比一下Native App你會發現層級多了不是一點點，而懶是用戶的天性，這樣的操作體驗無疑會大大減小使用率。場景二：你在手機上有多高的頻率切換自己的應用？如果每一次切換都要重新從首頁開始操作是怎樣一種體驗？你是不是感覺要崩潰了。你們在使用微信的第三方的時候應該有過類似的體驗，這種難受你懂。說一個我的看法：從“界面設計”上來說應用號將可能成為除了“消息，通訊錄，發現，我”這四個tab后“第五個Tab按鈕”這個點很多人表示無法贊同，甚至覺得可笑，參考上面說的場景你就能感覺到每少一個層級帶來的操作簡化有多少，這個重要性不言而喻，直接放在TAB5，直接相當于減少了2個層級，當用戶操作多的時候，每次以2個層級疊加，簡化的操作將不止一點點。然而這個不太可能在內側或者正式發布的前期就去這樣做，更有可能在后期再給出更前端的入口，也就是tab‘，早期基本就應該是在“發現界面”或者“我界面”那些說藏在錢包里的朋友我就不吐槽了，你腦補一下自己的產品體驗的畫面吧。為什么應用號對于創業者來說是福音 成本native的成本到底有多高？推廣：平均成本5元一個下載 ，100萬的下載量，月留存能有10w的都是少數中的少數 開發：安卓，ios要分開做，大量的機型、os版本差異、交互特殊等就這兩項能承受起的就不多了，最低起步價30w+左右，巨額的成本將大量的idea扼殺在搖籃里而這些死掉的idea大部分就是因為市場小，盈利跟不上巨大的成本而看不到未來從外部走進微信生態內部服務更加快捷方便，用戶的使用門檻大大降低。通過微信生態的流量轉化更有效率，多少app的用戶是通過微信文章推廣流量帶去的？一旦你就在這個生態里，只需要簡單的操作，比如掃碼，這個效率高了多少？微信想為創業者提供怎樣的價值微信做的就是把開發和推廣這兩項成本盡可能的降低，推掉成本這座大山，改變移動互聯網應用的規則，讓創造者能把核心資源（錢和時間）關注到用戶體驗上，去真正為用戶創造價值應用號到底適合做什么？微信已經做好了人與人的連接又做好了支付，現在微信希望的就是通過應用號將人和服務深度連接連接上人與服務后微信的價值那就更是不可估量的了服務是核心！這就和native app時期有了一定的區別，這里更歡迎的是服務性的app，也就是他說的用完即時走。早在8個月前，我就說微信要做的是一個長尾市場，聚合那些無法承擔成本去獨立做成app的服務。就像當年的亞馬遜一樣，幾乎沒有什么商品你在亞馬遜上找不到一樣。而現在微信就相當于是把商品變成了服務這種非標的東西。“小而美”的產品更適合應用號，能獲取較多的紅利，真正高頻常用的還是在原生app那邊更好，當然像同程旅行火車票這種剛需路徑短的還是很適合微信生態的。小而美的服務是什么？答：低頻、非剛需基于場景的服務，在特定場景下（也就是夠垂直）可以較好得解決用戶需求。許多付費的服務可能借力因此煥發出第二春，教育、醫療、家政、求職招聘、二手買賣、旅游、票務、金融理財、汽車后市場等等最后再潑點涼水，讓你冷靜一下，給一些重要的建議1.你所能獲取的用戶數據將非常有限，微信給你開放的用戶數據基本就是頭像和昵稱還有一定的好友關系。數據對你自己的重要性一定要考慮清楚！2.商業模式與native app將發生巨大改變，拿native app的思路去套，做好的可能性幾乎為零，你要重新構思并快速去驗證你的模式。我覺得思考比行動更重要，在正式開發之前需要在，你要知道先入者不一定是先驅，更有可能是先烈！3.免費的模式不一定就好，多考慮付費形式，不僅只是因為微信已經幫你做好了方便的支付接口，而是因為應用號的形態和設計初衷更適合基于場景需求的快速實現。4.還是那句話，小而美，做垂直，功能復雜度有限制，如果想做成龐大的獨角獸，必須是高頻剛需但復雜度又不是太高，就像“同程旅游的火車票服務”一樣。5."用完即走"……因為沒辦法多任務處理，你的產品如果不能在一定時間內完成特定場景的需求并且達成自己的目標，你就比較難做。6.產品層級不要深，操作路徑要短，沒法記錄你操作到了什么地方，如果用戶被打斷，第二次進去是沒法回到上一次操作的位置的(有一定的緩存)7.應用號是一個流量孤島，應用號之間的流量不能流通，自身產生不了什么流量，單在微信生態內來說比較依賴訂閱號的文章帶來的流量導入我并不覺得會有太大的顛覆作用，等時間去驗證把

1. 微信小程序不會取代大型App，應用市場該怎么做怎么做。Native App 更不會消亡。這個跟性能無關。2. 低頻應用 是最有可能轉入到 小程序 平臺的。掃碼搞活動也會更方便。3. 小程序 是否能做起來，要看 微信 對其開放什么樣的入口，比如：朋友圈直接顯示界面？ 聊天窗口直接顯示界面？ 聊天窗口直接發起游戲？ 多帶帶的小應用 Tab？ 如果這些都不開，跟現在的H5沒本質區別。4. 估計會興起一批“聊天窗口”游戲/應用

微信小程序這個東西的出現早有苗頭：在客戶端/瀏覽器集成一個運行環境，用js去驅動native ui，這個事情騰訊QQ瀏覽器早就做過。這種做法我認為它有反 web 反開放的嫌疑。Web 是最開放最容易被解析被索引的技術，網站的內容可以被用戶隨意選取和分享，可以被搜索引擎收錄，甚至在網站已經死亡之后其內容仍然能存活在 http://archive.org 這種數字檔案館里。而 App 則自給自足，很難去解析去索引，如果一個 App 死了，它的用戶和內容就會流失。如果市場上越來越多的部分都被 App 占據，每一個 App 都是封閉的王國，互聯網會越來越封閉，搜索引擎也將毫無用武之地。正是看到這種趨勢， Google 急得像熱鍋上的螞蟻。現在 Google 正在大力推廣的 PWA 技術，就是以 HTML 為主， JS 漸進增強的 Web App 方案，在保證內容開放性（discoverable） 的同時又具有 App-like 的體驗。關于這一點，可以看看 Google 的介紹： https://developers.google.com/web/progressive-web-apps/從這一點來說，我是對微信小程序這種技術是有反感的，雖然它確實大大擴展了 JS 的業務范圍。但在現實中，它又確實有可取之處，微信的巨大用戶量、輕型應用的可傳播性、相對較好的性能和一致性的用戶體驗，時時刻刻吸引著應用開發者來使用這種技術。時代的洪流浩浩蕩蕩，我們每個人都只能順勢而為。＝＝＝＝雖然微信這一次的代碼和文檔質量都還不錯，小程序的特性也令人印象深刻，卻也并非完美。以下吐槽一下微信小程序目前的一些問題。Android 下，input 組件中輸入文字，切換鍵盤顯示/不顯示狀態，文字會錯位。Android 下 Canvas demo 剛開始動畫時丟幀。而且大部分涉及動畫的組件，如 swiper/progress 等，都有丟幀的現象（驍龍650 啊，不應該啊在 scroll-view 上用手指滑一下然后松開，界面發生滾動，但手指松開后會錯誤地觸發 click 。getApp() 、Page() 等框架函數沒有放在命名空間下。tabBar 分割線只能用黑白兩種顏色，且圖標不支持 svg 。HexColor 只支持 RGB，不支持 alpha。swiper 組件的 indicate dots 好丑，也沒法定制 - -API 不如 Vue.js 優雅。趕工的痕跡還是挺明顯的，比如 <map> 組件，我傳進去參數了，顯示出來的地圖上也打點了，但是用戶在地圖上操作的行為呢？沒有事件傳出來，業務代碼沒法獲取到用戶操作。IDE 沒有實現 live reload ，在 IDE 里需要手動刷新，在手機上需要反復掃碼。不開放編譯和打包過程，沒有集成 babel 支持。不會將引用的 npm 包打包到項目里，需要自己另想辦法。好像沒有提供遠程調試？反正我沒找到真機調試打斷點的地方。沒有提供真正的退出小程序的功能，無論是返回鍵還是菜單中的“離開”，都只是睡眠和隱藏而已。沒有提供刪除小程序本地緩存的功能，改了后臺配置之后用戶端的沒有更新，我只好 root 之后進 /data 分區手動刪除緩存文件。文檔中有一些錨點鏈接點了沒反應，比如配置里的 tabBar。wx.request() 這個 API 的限制非常嚴格，比 Web 里的 http request 限制嚴格得多。wxml 是寫死在源碼里的，那么如何在運行時動態生成頁面結構？似乎沒有 webview 組件。js 和 wxml 的引入是方式是不一樣的，js 用 require() ，wxml 用 <import>/<include> 。這就很尷尬了，既不能像 vue 那樣整個 .vue 文件作為組件一塊引入，又不能像 react 那樣，一切皆是hyperscript 。在微信小程序里把 wxml + js 組件化會非常麻煩。文檔里說了“規定屏幕寬為750rpx”，我試了之后發現不是，此處應有黑人問號臉。在 wxss 規則里寫 vw 單位會各種bug，現在還沒找出規律。但在 wxml 元素的 style 屬性里用 vw 單位又是ok的。黑人問號臉。小程序與小程序之間如何跳轉？占位，慢慢修改個人觀點：總的來說，亮點有，但在 Android 上暫時還并未表現出來秒殺 Web App 的特點；開發不算復雜，但開發體驗有待改進；性能不算太差，也并非極好，自由度和表現力離 Web 尚有一些差距；微信小程序捆綁的 js 框架降低了新手入門的門檻，但增加了業務遷移的成本；bug極多。微信小程序尚且是一個新玩意，亮點和缺點共存。而由于微信的封閉性，這種技術并不能完全替代 Web App 。在手機性能越來越高、Web 技術進化越來越快的今天，微信小程序到底能在多大程度上挑戰 Web 的地位，還有待觀察。對于開發者，個人建議是不要太著急上火，把玩一下即可，繼續觀望也無妨。如果你的業務嚴重依賴微信、希望在用戶體驗上精益求精、在客戶端技術上探索一些未來的可能性，那么你可以嘗試一下這個技術，用在一些新的、輕型的業務上，做一個快速試錯，看看后續的結果再決定是不是增加投入。但要在倉促之間把已經成熟的業務搬到一個新的技術平臺上，恐怕不是一件容易的事情，也沒有多大必要。

Update: 據說應用號的入口是在發現tab購物游戲下面，之所以叫小程序是因為AppStore審核不通過應用號三個字，并且已經和蘋果約法三章應用號不能做游戲產品，以及，一個用戶只能添加20個。噫…不愧是企鵝爸爸作為一個只寫Script語言的人我是很支持騰訊干掉PhoneGap/Cordova/Ionic的【重要的事情要說三遍不過我就想問一件事…蘋果能允許么…小程序安裝或者升級的話要不要蘋果再審核一遍？這就跟用ReactJS Live Update一樣，屬于蘋果的灰色地帶，一個普通App這么做可以睜一只眼閉一只眼，有潛力做成OS的話蘋果能答應么？Apple’s guidelines explicitly permit you to push executable code directly to your app, bypassing the App Store, under these two conditions:The code is run by Apple’s built-in WebKit framework or JavascriptCoreThe code does not provide, unlock or enable additional features or functionality安裝一個app就相當于微信不用蘋果審核就*增加*一項功能，這比加個patch快速修復一個bug可*過份*多了…鑒于微信在蘋果發布會上出現的頻率，微信團隊很可能跟蘋果溝通過了，所以像360那樣被下架的可能性比較小，不過如果別的廠子看見了也蠢蠢欲動，那可是動搖了AppStore的根基啊【反X亡A，不反X亡B的感覺

總結

以上是生活随笔為你收集整理的如何评价 9 月 21 日开始内测的「微信小程序」? 财富值85的全部內容，希望文章能夠幫你解決所遇到的問題。

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