筆者注：本文[配圖7]app.json 小程序配置： 小程序里一共包含哪些頁面。頁面套在一個怎么樣的 window里顯示。window是否需要支持多tab,支持的話每個tab的默認page是什么。一些底層組件的默認參數(shù)。app.js（可以理解為入口函數(shù)）處理app的幾個關(guān)鍵事件:onLaunch,onShow定義了app級（可以在不同的頁面之間共享）的數(shù)據(jù)的格式app.wxss 公用樣式表每個頁面的樣式表，都是從這個應(yīng)用級公有樣式表繼承下來的。 MINA一個最主要的核心概念是Page，一個Page是應(yīng)用內(nèi)可以導(dǎo)航到的最小粒度的界面。而如何構(gòu)建Page是與大家過去猜測差別最大的地方。微信并沒有使用HTML5，而是提供了一套新的設(shè)計。新的設(shè)計要求每個 Page由3個文件構(gòu)成：index.js :包含Page的邏輯處理代碼其中比較重要的就是定義Page的數(shù)據(jù)（wxml可以通過數(shù)據(jù)綁定機制直接訪問） index.wxml : Page的布局文件隨便從demo中選一個布局文件來看，其整體結(jié)構(gòu)非常簡介清晰，即使沒有提供任何資料也大概能看出來表達了一個什么樣的頁面。.wxml不算是完全的靜態(tài)布局文件，還支持條件渲染和列表渲染。.wxml使用{{}}語法來簡單直接的支持數(shù)據(jù)綁定。可以通過template的方法進行復(fù)用index.wxss: 樣式表決定了在wxml中定義的各種組件最終應(yīng)該如何顯示。官方文檔并沒有列出wxss的selector語法和支持的style，只是說“具有CSS的大部分特性”，wxss樣式表里也擴展了一些微信小程序?qū)Ｓ玫臉邮绞菍傩浴age的整體設(shè)計上有比較明顯的“反應(yīng)式”編程風(fēng)格，相信有vue.js,angularJS，reactive.js開發(fā)經(jīng)驗的同學(xué)可以很快上手。由于沒有內(nèi)測資格所以沒法在手機上測試性能，不清楚小程序的這套框架有沒有反應(yīng)式編程常見的性能問題。這個等公測后寫個有10萬條數(shù)據(jù)的列表，看看滾動流不流暢就知道了。目前demo沒有使用ES6，所以看起來沒那么“現(xiàn)代化”，這也可能是因為小程序這個項目立項比較早的緣故吧。不過ES6是大勢所趨，相信未來小程序會支持使用ES6開發(fā)。一個基于MINA的小程序最后是如何跑起來的呢？官方這么說：“開發(fā)者寫的所有代碼最終將會打包成一份 JavaScript，并在小程序啟動的時候運行，直到小程序銷毀。類似 ServiceWorker，所以邏輯層也稱之為 App Service。”網(wǎng)上已經(jīng)有不少人通過琢磨開發(fā)工具的實現(xiàn)的方法，做了比較深度的研究了，推薦閱讀：(微信小程序「官方示例代碼」剖析【下】：運行機制 微信小程序「官方示例代碼」剖析【下】：運行機制)簡單的總結(jié)一下：wxml文件通過編譯會得到html，wxss 文件通過編譯會得到css，分離的各個頁面的JS和App的主JS文件最終會打包在一起得到App Service。 開發(fā)狀態(tài)下運行小程序，基于blink內(nèi)核，每個html會加載一些moko js用來支持框架功能。生產(chǎn)環(huán)境在手機上估計是運行在一個專用，定制的瀏覽器內(nèi)核中。為什么是MINA? 業(yè)界對目前微信使用的UI框架，有兩種截然相反的觀點：微信“小程序”帶動HTML5發(fā)展 數(shù)據(jù)波來助力 微信“小程序”帶動HTML5發(fā)展 數(shù)據(jù)波來助力-CSDN.NET“微信小程序的本質(zhì)說來就是一個HTML5應(yīng)用”“以后互聯(lián)網(wǎng)的發(fā)展方向可能更偏重于HTML5” 而有的人又認為我們真的需要“小程序”么？| HTML5老兵如是說 我們真的需要“小程序”么？“微信雖然用了 HTML5 技術(shù)來做應(yīng)用號（正式名稱：小程序），但是它并沒有真正用到 HTML5 的精髓——開放、互聯(lián)，也就決定了它可能無法實現(xiàn)“微信OS”的最終野心。”這兩個觀點是矛盾的，那么，到底那種觀點是正確的呢？首先簡化一下問題，微信小程序是基于HTML5開發(fā)的么？ 通過分析小程序的運行原理，這個答案是明確的：小程序的開發(fā)過程會用到大量HTML5相關(guān)的技術(shù),但并不是使用HTML5開發(fā)。有 HTML5經(jīng)驗的前端工程師學(xué)習(xí)微信小程序的開發(fā)相對會更容易一些。微信小程序的運行并不需要一個完整支持HTML5特性的標準瀏覽器內(nèi)核，但也可以通過添加一些輔助設(shè)施，讓小程序在個完整支持HTML5標準的瀏覽器上運行起來。 “由于框架并非運行在瀏覽器中，所以 JavaScript 在 web 中一些能力都無法使用，如 document，window 等。” 也就是說，一個已存在的HTML5頁面，并不能通過自動轉(zhuǎn)換工具變成一個合法的Page，而需要有工程師根據(jù)HTML5頁面的功能，使用MINA框架再實現(xiàn)一次。[配圖 HTML5與MINA在功能上有交集，但并不相等]搞清楚MINA和 HTML5的關(guān)系后，我們還是沒有搞清楚為什么微信要提供一個新的MINA框架 。事實上這個問題是一個討論設(shè)計的問題，所以要回答這個問題，需要具備一定的設(shè)計能力，而不是只是停留在研究MINA實現(xiàn)的層面。而設(shè)計能力，是一種比較稀缺的能力。想要系統(tǒng)的提升自己的設(shè)計能力，簡單的來說就是“多看+多想”，那么如何多想呢？我有一套還算完整的方法的，簡單來說有如下幾步：首先，在研究一個新東西以前，先想想這個新東西，是為了解決什么樣的問題出現(xiàn)的。問題要多提，往深了提，反復(fù)提煉，最后得到幾個好問題。或則從一個問題，引申出一些子問題。很多時候只要問題提對了，設(shè)計就明白了大半。下一步就是試著自己解決一下，回答一下自己提的問題，并比較不同的解決思路的優(yōu)劣，形成一個對問題解的標準。比如說問題是“如何在一個超長文本中查找子串？” 那么對問題的評價標準就可以是查找速度，以及查找過程中的內(nèi)存占用。接下里就是看別人是如何解決這些問題的了。如果和自己的設(shè)計差不多，一邊竊喜一邊開始按自己預(yù)先設(shè)計的評價標準對別人的設(shè)計的好壞進行判斷。如果是自己完全沒想到過的解法（這通常會出現(xiàn)在第一次接觸某個領(lǐng)域問題），可以按圖索驥的補充一些基礎(chǔ)知識，再回來看。如果這個領(lǐng)域或解法非主流到不是常見范式，那么可以安下心來好好搞清楚，想明白。 這樣帶著問題研究設(shè)計，才能有效的提高自己的設(shè)計能力。介紹完套路后咱們回到正題：我們?nèi)绾蝸碓u價微信小程序選擇MINA框架？讓我來持續(xù)提問吧。第一個問題：“為什么微信小程序不使用HTML5而是使用MINA來構(gòu)建Page？”不用HTML5我可以提供一個非技術(shù)答案：微信需要通過這種方法來轉(zhuǎn)化開發(fā)者，這些開發(fā)者未來會逐漸演變成“微信OS平臺”的忠實開發(fā)者。其實開發(fā)者通常都有患有“斯德哥爾摩綜合癥”，一旦在一個平臺上投入了智力資源進行學(xué)習(xí)，就會開始下意識的維護這個平臺（比如看不到平臺的缺點，只看到平臺的優(yōu)點）。如果使用HTML5作為開發(fā)方式，那么現(xiàn)在小程序聚攏的開發(fā)者都是為了流量來的，并沒有投入額外的學(xué)習(xí)成本，對平臺不夠忠誠。而微信要成為OS是一個長期的演變過程，那么現(xiàn)在就要通過要求學(xué)習(xí)一個新的開發(fā)框架的方法開始多轉(zhuǎn)化一些忠誠的開發(fā)者。 當然是不是這個原因也只有張小龍自己知道了，這是一個揣摩動機的答案，所以沒有評價標準。問題終結(jié)。為什么不用HTML5的技術(shù)答案可以是非常庸俗的。畢竟業(yè)界對于HTML5技術(shù)的優(yōu)劣討論已經(jīng)持續(xù)了一段很長的時間了。但基本上，大家認為HTML5的主要缺點集中在性能上：同樣的交互，用HTML5實現(xiàn)需要更多的系統(tǒng)資源，也可能會不夠流暢。同時，應(yīng)用還需要集成一個非常巨大的瀏覽器內(nèi)核。這個答案盡管能讓大部分人滿意，但實際上是非建設(shè)性的（這些對HTML5性能的結(jié)論，是別人告訴你的）。大家一邊相信HTML5的美好前景，一邊把對性能問題的解決寄托于幾家傳統(tǒng)的瀏覽器廠商。按我們的套路，這個性能問題再往深了問是這樣的：“渲染指定頁面最少需要多少資源？”，“在當前硬件水平下，渲染指定頁面最快需要多少時間？”，“實現(xiàn)一個完整支持HTML5標準的瀏覽器內(nèi)核，需要大概多少代碼？”。要回答這些問題就需要了解瀏覽器的實現(xiàn)了，這不會是一件容易的事情，在閱讀瀏覽器的實現(xiàn)的時候，肯定會持續(xù)提出針對HTML的設(shè)計問題。最終你會對瀏覽器廠商什么時候能解決性能問題，得到一個更合理的預(yù)期：至少在5年內(nèi)，HTML5的性能是不夠的。雖然SAY NO的理由，有一條就夠了。但如能從其它角度思考一下為什么不是HTML5,可以得到一些更有建設(shè)性的答案。第二個問題：“MINA作為一個新框架，為什么會設(shè)計成現(xiàn)在的樣子？”可以肯定的是，這是MINA的架構(gòu)師在綜合了多個因素后，拿出來的一個自己最滿意的答案。所以這是一個非常有建設(shè)性的問題，思考這個問題的時候，就開始逐步代入MINA的架構(gòu)師視角了。讓我們一起進入MINA架構(gòu)師的角色，首先在否決了HTML5后，要設(shè)計一個什么樣的框架來支持小程序的交互開發(fā)？第一步就是要給這個新框架提一些基礎(chǔ)性的目標與需求。這是一個現(xiàn)代化的框架，在最終表現(xiàn)力上要足夠好。小程序跑在微信里，所以必然是和android,iOS的具體平臺特性無關(guān)的。要面向更多的非專業(yè)開發(fā)者，所以學(xué)習(xí)門檻要低。大規(guī)模的專業(yè)團隊進行團隊開發(fā)時，能有足夠的工程支持。工程支持包括：模塊化代碼易于長期維護和修改。這意味著基于框架的實現(xiàn)具體需求的結(jié)果要足夠清晰，好讀。可復(fù)用性設(shè)計。小程序不需要安裝就可以快速開始使用，只需要加載必要的資源就可以盡快展現(xiàn)用戶需要的頁面。進一步思考這些需求該如何解決，并對不同的解決方案進行評價需要的領(lǐng)域知識非常多，已經(jīng)超過了本文的討論范圍。我在這里要做的只是帶你入門，讓你開始思考設(shè)計問題就夠了。這也是本文的核心目的：學(xué)會對新技術(shù)，新設(shè)計進行獨立的分析和判斷。至于結(jié)果么，現(xiàn)在小程序還處于一個早期的狀態(tài)，等公測了之后在下結(jié)論也不遲。微信小程序的未來？ 雖然現(xiàn)在小程序開放的功能并不豐富，處于一個早期的狀態(tài)，但結(jié)合上面的觀點去看微信小程序的設(shè)計，還是能從中讀到許多遠大的理想。而微信的核心愿景之一是“連接一切”，沒準小程序是騰訊實現(xiàn)這個愿景道路上的重要一步。有超過7億用戶的微信如果成為一個新的平臺，具有不可忽視的能量，下面讓我來對小程序的下一步動作做一些無責任的預(yù)測吧。假設(shè)一、微信小程序未來會解決應(yīng)用內(nèi)搜索的問題目前小程序規(guī)范的頁面結(jié)構(gòu)很方便實現(xiàn)應(yīng)用內(nèi)搜索。以后使用微信的搜索功能可以直達小程序內(nèi)部的某個特點內(nèi)容頁面。這種規(guī)范的設(shè)計也方便實現(xiàn)小程序之間的互相訪問，可以通過一個類似wxapp://appid/pageid/的URL直接導(dǎo)航到另一個小程序的某個特定頁面。這是App時代的超連接系統(tǒng)，App的信息孤島也許就此打破。假設(shè)二、微信小程序會從本地數(shù)據(jù)讀取開始，進化出一定的云端API. 現(xiàn)在小程序只提供了前端的開發(fā)功能，但從整體邏輯上已經(jīng)包含了應(yīng)用的上傳，審核，發(fā)布流程。以后騰訊也許會為小程序提供托管服務(wù)（https://www.qcloud.com/act/event/yingyonghao.html），讓應(yīng)用開發(fā)者可以用更少的精力完成一個完整小程序的開發(fā)，而不需要去管服務(wù)器申請，后臺開發(fā)，服務(wù)器運維等反繁瑣的工作，進一步降低一個真正小程序的開發(fā)門檻。我相信微信一定有團隊在為這個方向努力，但最終實現(xiàn)目標需要更有創(chuàng)造力的云端API設(shè)計，這是需要有大智慧的工作。假設(shè)三、使用小程序連接一切我并不認為小程序只是一個體驗更好的服務(wù)號。張小龍說小程序是“觸手可及”，“用完即走”，“無處不在”的。那么什么場景會需要這種能力? 我覺得“有復(fù)雜程序的低頻商業(yè)行為”會有這種需求。舉兩個實際的例子：例1：有一間智能會議室，入口處有一個二維碼。會議室的使用者掃描后可以打開一個小程序，通過這個小程序可以更好的訪問、控制會議室的各種設(shè)備，比如燈光，窗簾，幕布等。例2：去體檢，體檢表上有個二維碼，掃描后打開一個小程序，通過這個小程序可以更好的引導(dǎo)用戶自助完成自己的體檢項目。這兩個場景的需求能通過小程序解決，意味著小程序的種類極大豐富，硬件廠商對微信生態(tài)的極大支持。我們可以通過小程序簡單方便的進入各種陌生的環(huán)境，讓生活更加智能。未來已經(jīng)悄悄敞開了大門。而如何更好更快的探索小程序的可能性，也將是我接下來創(chuàng)業(yè)的方向。我將以火速移動技術(shù)顧問的身份，和小伙伴們一起從微信小程序開始，去探索移動Web的可能性。感謝各位關(guān)心。

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

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

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

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

Update: 據(jù)說應(yīng)用號的入口是在發(fā)現(xiàn)tab購物游戲下面，之所以叫小程序是因為AppStore審核不通過應(yīng)用號三個字，并且已經(jīng)和蘋果約法三章應(yīng)用號不能做游戲產(chǎn)品，以及，一個用戶只能添加20個。噫…不愧是企鵝爸爸作為一個只寫Script語言的人我是很支持騰訊干掉PhoneGap/Cordova/Ionic的【重要的事情要說三遍不過我就想問一件事…蘋果能允許么…小程序安裝或者升級的話要不要蘋果再審核一遍？這就跟用ReactJS Live Update一樣，屬于蘋果的灰色地帶，一個普通App這么做可以睜一只眼閉一只眼，有潛力做成OS的話蘋果能答應(yīng)么？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快速修復(fù)一個bug可*過份*多了…鑒于微信在蘋果發(fā)布會上出現(xiàn)的頻率，微信團隊很可能跟蘋果溝通過了，所以像360那樣被下架的可能性比較小，不過如果別的廠子看見了也蠢蠢欲動，那可是動搖了AppStore的根基啊【反X亡A，不反X亡B的感覺

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。