大家好，我是Beta007. 最近一直在研究小程式，會在這裡整理出一系列的文章，和大家交流。

第一篇文章首發在了知乎專欄：小樓昨夜又秋風：https://zhuanlan.zhihu.com/p/22891188

知乎ID：七月在夏天  （頭像是隻喵~）

不一樣的角度 解讀微信小程式

前段時間看完了雨果獎中短篇獲獎小說《北京摺疊》。很有意思的是，張小龍最近也要把應用摺疊到微信裡，這些應用被他稱為：小程式。

含著金鑰匙的小程式，還未展現全貌，就已經成了開發界的頭條大事兒。有人不以為然、嗤之以鼻，有人奉若神明、投懷送抱。敢於嚐鮮的已經開始動手了——不管合不合適，先借這個熱度來一波關注是不錯的選擇：

所謂“不登高山,不知天之高；不臨深溪,不知地之厚“。我生怕看不清小程式這座大山，滾去做了個demo。放上幾張demo圖，一起感受下小程式的魅力：

如果不考慮效能以及各類複雜的動效，小程式的體驗已經很接近原生App了。

已經有很多的主流媒體對小程式進行了解讀，本文將從一些不一樣的角度來解讀一下小程式的特性。

1 小程式 VS APP

我們先舉個例子來直觀感受下小程式和APP有什麼不同。大家都用過支付寶，在其內部包含著很多小的服務：手機充值、城市服務、生活繳費、信用卡還款、加油服務，吧啦吧啦一大堆服務。這些細小的、功能單一的服務放在支付寶這個超級App裡，你並不覺得有什麼問題，而且用起來也很方便。那如果這些小的應用都單獨拿出來，成為一個獨立的App，你每用一個服務都需要從AppStore裡下載安裝，而他們其中很多服務，你可能幾個月才使用一次，甚至只會使用一次，但卻要長時間的佔用你的手機空間。這樣的模式，可能多數人都不會喜歡。

微信小程式有些類似於上面寄生在支付寶裡的各類服務。他們具有業務簡單、明確，使用頻率較低（你不可能每天都交話費、也不可能天天都交水電費）等特點。這類服務，如果單獨做成App，一是開發成本高，二是使用者的手機空間有限，所以把這些小的服務都“摺疊”進微信中，無需下載安裝，使用者想用時就搜一下，用完即走。

輕量級、功能單一的服務適合小程式；而業務複雜的應用適合用App。這裡不太認同主流媒體們說的：低頻適合小程式，高頻適合App。這個說法太絕對，低頻高頻不應該成為合適不合適的分界線 。微信本來就是超高頻應用，很多人一天要開啟十幾次吧，我在使用微信的時候順手就使用了小程式服務，這個場景是不是也合情合理？我認為微信的超高頻使用次數可以彌補小程式入口較深的缺點（而且入口究竟在哪裡官方並沒有給出準確的位置）。此外，低頻高頻是個非常模糊的概念，很難去界定，一天用一次算低頻還是高頻？支付寶算低頻還是高頻？

所以，不要被低頻和高頻限制你的思維，這個真的不是關鍵。

輕和重是從小程式和App的特性上在區分兩者的差異，這裡我提出一個按產品規模劃分小程式和App的觀點： 絕大多數創業者將在MVP階段，採用小程式方案；而當產品發展到一定的規模，創業者依然會開發自己的App。

美味不用等最初只在微信裡向用戶提供“排隊叫號”服務。你只需掃描一下店家的二維碼，就可以去逛街了。這個服務號會在快排到你的時候向你傳送一條微信提醒，你不需要守在店裡排隊。 這樣的一個場景放在現在，非常適合使用小程式來開發，它滿足業務簡單、頻率不高的特點（你不可能一日三餐都在餐館吃飯，又恰恰每次都要排隊）。在使用者數量達到一定的規模後，美味不用等迅速推出了自己的App，嘗試將使用者向自己App內轉移。 圍繞著“排號”這個核心功能，美味不用等App增加了點評、實景拍照、排行榜、美食專題等一些列附加功能。這樣從一個簡單的MVP產品切入使用者某一痛點，成功後旋即推出一系列被“連結的功能”，這在網際網路產品裡太常見了。滴滴從線上打出租車切入，發展到專車、快車、拼車、代駕、班車、巴士；羅輯思維從一個每天推送一條語音的自媒體，到在微信裡賣書，再到現在推出自己的App得到。為什麼美味不用等和羅輯思維在微信生態中做的相當成功後還要推出App？就在微信內部深化產業鏈不好嗎？可能有以下三點原因：

第一：單一的服務在中國極難產生回報，產品需要不斷的連結。國內的付費習慣還沒有養成，想靠出售服務盈利在目前情況下很困難，尤其是To C的產品。大多數產品會依靠一款拳頭產品切入市場，在獲取使用者後，開闢一系列增值業務和附加功能，這才可能有盈利的想象空間。任何一個產品都很難保持克制和不膨脹，這是資本、模式的需要。張小龍一直講剋制，一直和騰訊內部諸多“勢力”博弈，但微信還是成為了一個超級App，日漸臃腫。由簡單到複雜，由低階到高階，這是商業模式的趨勢，也是萬物進化的規律。如果你熟悉成熟網際網路公司的業務分佈是多麼的廣泛，就會對這個結論不足為奇。

那麼小程式有可能承載這些附加的增值業務，允許開發者逐漸完善自己的產品及商業佈局嗎？目前看來，可能性比較小，因為這和小程式的初衷是相違背的。即使微信放開政策，可以 想象的空間也很小，你只能在微信給你劃定的一個小範圍內做流量的變現，這遠遠不及獨立出一個App所帶來的價值。

第二：對於微信生態的不信任感，導致了這種“逃離”。最近和一個創業者聊天，我問他，小程式來了，你還考慮做APP嗎？他說：做，小程式和APP都會考慮做。我問他為什麼？他說：我總感覺小程式不是我自己的，而APP會給我一種踏實的感覺，我會覺得我對APP有絕對的控制權，即使做小程式也只是為了給我的APP引流。 有這樣感覺的人應該不在少數，可能是對Web App技術的不信任，可能是對於將應用建立在另一個應用這種模式的不信任，也有可能是對騰訊的不信任。

騰訊對於自己利益保護是毫不手軟的， U步、蝦米音樂、微軟小冰，都曾被微信封殺過。淘寶就更不用說了，相愛相殺，鬥智鬥勇，年年都是大戲。孰是孰非，很難界定。這些產品由於只是藉助微信的關係鏈，而並非完全寄生於微信，被封殺也只是少了一個推廣途徑，沒有了微信還有微博等其他媒介。 而完全根植於微信生態的小程式，如果被封殺或是被規則打壓，幾乎沒有退路可走。

那App就很可靠嗎？目前看來確實比小程式要靠譜很多。主要一點還是生態主宰者的格局 。無論谷歌還是蘋果，都是科技界的頂尖公司，這樣的公司盈利手段、業務方向、產品級別都要高出普通公司若干個等級，他們關注的是科技趨勢和標準發展，很少在消費業務上同創業者競爭。此外，谷歌與蘋果對於開發者更多的是抱有“合作心態”，我需要你幫我壯大生態，你需要我為你提供平臺。這些引領科技方向的公司，更容易給創業者們足夠的信心。相反，騰訊投資了很多的C端消費領域公司：京東、滴滴、餓了麼、人人車、SuperCell、盛大文學、龍珠直播，幾乎覆蓋了電商、金融、娛樂文化、O2O、線上教育等各個領域，創業者幾乎不可能繞開騰訊的利益圈。騰訊既是裁判也間接的是運動員，能否保持一個公正和開放的態度，還需要時間來驗證。

第三：生存在AppStore和微信夾縫中的小程式將承受更多規則壓力。在微信內不僅會受到微信的政策壓力，還會受到蘋果的壓力，小程式的政策環境只可能比AppStore更加苛刻。小程式雖然支援HTML5的Canvas，但據說蘋果不允許在小程式裡做遊戲；每個使用者可能最多隻能安裝20個小程式；這些限制是外部規則的第一個壓力。畢竟微信是寄託在另一個生態上的App，本身就會受到約束。 隨著小程式生態的演進，這樣的內外部壓力會逐漸增強，創業者們再次選擇App也就不是什麼稀罕事兒了。

所以，小程式更多的會和原生App互補，服務於產品的不同階段。建議創業者在產品早期用MVP思維來構建一個小而美的產品，開發成小程式來試錯，利用微信天然的獲客能力和傳播鏈條來推廣。後期再考慮將流量引到原生APP中進行流量變現。

雖然有以上諸多不穩定因素，但小程式生態的出現對於整個中國網際網路的發展依然是個利好，它給了獨立開發者以及初創團隊更多的想象空間，以前不敢嘗試的idea都可以藉助小程式這個平臺進行試錯，我們期待更多小而美的產品在微信中爆發。

2 已存在的眾多App將如何應對小程式的到來？

按照目前小程式的定位，位於AppStore榜首的中大型應用，不是小程式的“那盤菜”。小程式更適合輕量級且功能單一、操作簡單的產品。大部分的產品還是會以原生APP為主。

但我預計，各類應用（阿里系的產品除外）大部分都會推出相應的小程式版本 。適合小程式的順其自然開發一個小程式版本的應用；超大型應用也會想辦法將自己的業務拆分出一部分來開發成小程式。原因有以下3點：

1. 蹭熱點，刷存在。難得的無公害、低成本營銷手段，何樂而不為？
2. 多一個流量的入口，微信的關係鏈還是不容小覷的。
3. 也是最重要的一點：小程式的未來是星光璀璨還是黯淡無光，誰都不能肯定。那麼面對不確定的因素，做好防禦性的姿態是很重要的。沒有比率先在新生態推出自己的產品更好的防禦措施。尤其對那些沒有技術和資料壁壘的公司，產品很容易被取代，必須做好一些列的防禦措施。支付寶、QQ、微信等超級應用都曾以觀望的姿態在WP平臺推出自己的產品，那產品質量和版本更新速度差的簡直不忍直視，“察言觀色”的態度不言而明。反正這個平臺有我的產品，平臺發展的好使用者量多我就加大投入，完善版本；有競爭對手的產品出現，我就快速迭代迅速扼殺；如果平臺發展的不好，反正也沒投入多少，揮一揮手跟微軟說拜拜就是了。

3 張小龍說的搜一下即可開啟小程式到底是個什麼鬼？

張小龍在那段被髮爛的微信截圖中提到：使用者掃一下或者搜一下即可開啟小程式。掃一下這個場景很容易想象到，將二維碼附加在各類營銷活動中，使用者掃描或者長按二維碼即可開啟小程式享受服務。但我更感興趣的是“搜一搜”這個動作。這個搜一搜的搜尋物件是什麼？可以利用語義分析、人工智慧來分析使用者的行為資料（微信掌握著海量的使用者資料）並向用戶提供精準的服務嗎？

使用者做搜尋時，其本意是去獲取他所需要的資訊（服務），而非獲取App，他並不關心這個服務來自於哪個APP。現在的原生APP，在資訊和服務上加上一層殼，成為一個封閉的孤島。而使用者需要使用服務時，不能直達服務，使用者與服務之間隔著一個“殼”，這也是為什麼APP會讓人覺得很“重”的原因之一。百度當年的“框計算”，也是為了解決資訊孤島的問題，直接以服務為搜尋物件，即搜即得、即搜即用（這和現在小程式的理念何其相似），從而拔掉應用這層蓋在服務之上的殼，解決資訊孤島的問題。

小程式是雲端應用，理論上可以消除這樣的資訊孤島，直達應用內部。我很期望小程式的搜尋是語義化的搜尋，搜尋的是使用者的需求，而不是簡單的去搜索的小程式的關鍵字。那麼小程式能實現這樣的或者類似這樣的理念嗎？我們來看看百度“框計算”的技術結構：

最難的部分應該是需求識別和精準分析這個框裡的技術。目前人工智慧及機器學習都還停留在理論階段，並沒有很好的商業化案例，小程式想實現這樣的能力，挺難。 
那如果不能實現，小程式所謂的“搜一搜”依然還是同AppStore一樣在搜尋“應用”的關鍵字和熱詞，那麼這和做應用分發又有什麼區別？騰訊說不做應用市場的說法很值得商榷，無論如何一個隱形的應用市場依然存在。SEO、ASO等概念很可能再次出現在小程式的生態圈裡。

4 小程式的開發成本真的比原生App低嗎？

考慮兩個方面，開發成本和推廣成本。

原生APP一般要同時開發iOS和Android兩套，而小程式只需要做一套。毫無疑問，這點是小程式最大的優勢，從這個角度來看，小程式是“跨平臺“的。

具體到開發效率上，很遺憾，在現階段，開發一套完整邏輯的應用程式，小程式的開發效率是低於APP的。小程式獨立出了一個封閉的生態。我們經常說不要重複的造輪子，可小程式現在是裸奔，你得自己去造輪子。而iOS和Android經過經年的累積，已有大量的成熟元件可以使用。 相反，小程式目前還處於內測階段，沒有任何優秀的第三方元件可以使用。而官方提供的元件，介面非常的少，實現功能沒問題，但你想自己去定義元件屬性、樣式是很困難的（這點真的很奇怪，所有元件沒有任何設定樣式的介面）。

我們團隊做了個簡單的對比，開發同樣一款簡單的天氣應用。iOS拿到UI設計稿後，輕車熟路兩天搞定，各種互動不需要UE，都是iOS常用動畫。web前端這邊，拿著設計稿去找UI：

這個透明的狀態列我沒法實現，因為小程式的狀態列必須要有 。 
底部的Tab欄我只能設定顏色和圖片，設計稿裡的樣式我做不出來。 
Banner輪播的指示點我改不了。

UI一臉懵逼的看著他。

我們在小程式開發中遇到最棘手的2個問題：

1. 缺少統計、繪圖元件，以前的echarts和hightcharts都無法使用，只能用canvas去繪製，耗費的時間之多可想而知。我們目前正在著手修改一款基於canvas的開源繪圖元件，讓其支援小程式。
2. 小程式不支援WebView，大量已被靜態化好的HTML頁面完全沒辦法在小程式上展示。如果要支援格式化的文字顯示，目前思路有二種： 
   
   • 編寫工具，用正則表示式解析HTML，並轉化成小程式的標籤。這個過程很繁瑣，不僅要處理標籤還要處理樣式。比如html中的 ul 籤，處理起來就很棘手；再比如小程式裡的中是不能巢狀的（巢狀後內部的text樣式無效），而這樣的巢狀在html中太常見了。
   • 編寫一個針對wxml的文字編輯器，用這樣的編輯器重新錄入和格式化文字（這就是小程式帶來的一個挺好的機會）

小程式原生支援WebView的可能性很小。如果支援WebView，那以前用HTML5開發的各類WebApp又可以在小程式裡跑了，iOS —-> 微信—-> 小程式—-> WebView，這複雜的結構是要逆天的。但有可能微信會開放一個只支援CSS+HTML的WebView，不能執行Javascript。

開發者在開發小程式之前一定要預先對這些技術問題做充分的瞭解，並在設計上、功能規劃上儘可能的規避。

現階段，你想按照你的UI設計去開發，困難不小。有人說目前小程式還在內測，未來會有大量的元件出現。會有元件出現我毫不懷疑，但元件的質量怎麼樣，開發者的熱情有多高，能不能形成一個良好的社群氛圍，這些都是未知數。中國能夠靜下心來做開源的開發者，真的挺少。

至於推廣成本和使用者獲取上，很多人都認為小程式會有絕對的優勢，它處於微信內部，理應離微信關係鏈條更近。可微信至今沒有給小程式分享的介面，也許以後會給新的介面，也許會將小程式繫結到公眾號，藉助公眾號來傳播，也許根本不給小程式提供分享的介面。

誰知道呢？

APP獲取使用者成本高的一個根本原因是使用者手機裡的APP已經飽和了，我們不能拿一個新興生態的使用者獲取成本和一個已經飽和的生態做對比。當小程式的生態也飽和的時候，這個成本還低嗎？點開你微信裡的訂閱號，刺目的紅色數字有沒有亮瞎你的眼？而你又認真去閱讀的文章有幾篇？大量刷來的使用者那不叫使用者，想獲取一個真實的使用者的成本從來都不低。

這裡還是建議各位開發者，把精力真正的放在產品上，不要一味的盯著著微信的傳播優勢和平臺優勢。小程式由於門檻較低，競爭的激烈程度將遠超iOS和Android。Web發展這麼多年, 積累的大量前端人才，極有可能被這波熱潮釋放。把精力投入在打磨產品上，結合自己產品的特點適度營銷，這才是王道。

5 訂閱號、服務號、企業號、小程式以後會如何發展？

預測一下，訂閱號、小程式會並存; 服務號和企業號會慢慢的“死去”。

留存訂閱號和小程式是因為他們具備不同的屬性：訂閱號具有媒體屬性，小程式具有服務屬性。從目前微信對於小程式在傳播、分享上的限制來看，小程式就是做服務，他不具有很強媒體屬性，所以這兩個不同屬性的“號”應該會共存。 

而服務號本身就是個怪胎，是微信為平衡使用者體驗和高階功能的一箇中間產物。大多數的微信媒體、商戶、創業團隊都同時擁有訂閱號和服務號2個號，用服務號的高階介面做服務，然後將連結附加到訂閱號的模板訊息或者選單中推廣，怎麼樣都可以繞開服務號的限制。這樣的平衡，對開發者沒什麼好處，對使用者來講，也不見得有什麼體驗上的巨大提升。既沒有訂閱號的每天可以群發一條訊息的能力，又不具備小程式接近原生的體驗（大多數服務號的體驗真是差差差差差，你不繫結微信每次進去就要做身份驗證，毫無快取能力，比如招商銀行的服務號，每次進去都要輸入十幾位的身份證號或者卡號，你煩不煩？），那服務號有什麼存在的價值。小程式完全可以融合到訂閱號中，何苦搞那麼多號。當然，張小龍直接砍掉服務號的可能性不大，這個任務交給開發者去選擇，自然淘汰就可以了。

至於企業號，本身價值就在於微信提供了一個便捷的企業員工關係鏈匯入和管理工具，僅此而已。用過企業號的都知道，體驗是真的差。本身移動端就只適合做資訊的展示，不太適合做資訊的錄入，而企業號又偏偏有大量的資訊錄入操作，操作極度困難。既然企業號的價值在於便捷的員工關係鏈管理，那隻需要將員工關係鏈對小程式開放，並給企業的小程式一個沙箱環境，用小程式取代企業號即可。

相比於小程式帶來的機會與紅利，我更認同小程式的理念，簡單、乾淨、用完即走。而這恰恰是目前網際網路產品形態所缺少的，也是使用者急需的。小程式在產品理念上給我們的產品經理上了一課：有時候，少就是多，讓使用者觸手可及，才能讓創業者和使用者站的更近，更容易傳遞你的商業價值。

作者：七月

個人部落格：碼 藝

轉載請註明原文出處及作者資訊