微信小程序即將在春節前推出了，“微信稍微掀一下裙底，整個互聯網都高潮了”！自從年初公佈小程序以來，對於小程序的評論分析非常多，自己也看了許多分析，對於微信小程序的分析，我覺得一下的分析最爲透徹。
目錄
目錄
1. ”應用號“是什麼？
首先，先來看三張圖：
第一張：官方微信
![1240]()
官方圖
第二張：微信創始人張小龍
張小龍朋友圈
第三張：官方回答
Paste_Image.png
從上面的圖可以看出：應用號是內置於微信的雲端的應用程序。
官方稱爲：小程序，可以理解爲”鑲嵌在微信的App“
與訂閱號、服務號和企業號屬於同級體系。由此，小程序、訂閱號、服務號、企業號形成了並行的微信生態四大體系。
2. ”應用號“的作用
首先，我們來看開放了內測資格開發的界面：
開發界面
然後是微信小程序的開發設計文檔，詳細請點擊
開發設計文檔
從上圖可以看出：
應用號的重心會首先體現在開發者層面
通過爲開發者提供基本的SDK（組件、框架API以及開發者調試工具），向開發者開放多種服務及支撐能力
3. 應用號的特點
通過上面的描述，你大概瞭解到應用號是什麼了，那麼：
應用號對於不同使用者有什麼特點？
和現在的WebApp、原生APP有什麼區別？
請看下面分析：
3.1 對於用戶
性能比WebApp好
微信爲開發者提供基本SDK（組件、框架API以及開發者調試工具）同時開放後臺服務器，這使得應用號的性能和流暢度遠高於WebApp但性能和流暢度還是不及原生App
使用成本更低
無需安裝，不佔內存，在微信內即搜即用，使用成本相對於安裝App來說降低了很多
3.2 對於開發者
學習門檻低
微信應用號的底層技術支持和HTML技術有很多相似之處，前端技術相對於其他技術來說無論是入門和學習門檻都較低開發成本低
相比於開發成本和維護成本居高不下的App來說，在滿足功能需求、性能需求的前提下，“應用號”基於其跨平臺的屬性，無疑開發成本和維護成本更加低
3.3 對於產品策劃者
基於微信的社交關係鏈和生態系統的產品矩陣，讓產品形式的創新有了更進一步的想象空間
當然這取決於微信本身的開放程度。
基於應用號開發成本和性能體驗的平衡特點，讓產品策劃者在設計產品解決方案時多了一種極具性價比的產品解決方案
特別是用於MVP試錯、快速驗證產品模式
3.4 對於產品運營者
應用號可憑藉微信的用戶基數、高頻使用率和活躍時長入口優勢，充分享受這部分紅利並解決拉新、活躍和留存問題
絕大部分的App都會面臨用戶獲取成本太高、活躍不足和留存難的問題，特別是現在用戶需求基本被滿足的時代，流量的獲取和轉化成本越來越高
當然，這個觀點僅存在於紅利期。
當紅利期過去後，隨着應用號會越來越多，隨即會形成“即時通訊功能+訂閱號+服務號+企業號+應用號”的微信生態產品矩陣，依舊會出現用戶獲取成本高、活躍不足和留存難的問題，因爲：
關於拉新：微信對小程序並不提供如同應用商店一樣的營銷推廣支持，用戶只能通過掃一掃或應用內搜索才能找到產品，在茫茫產品矩陣中如何能觸達用戶是首要解決的問題，這個問題對於初創品牌被無限放大
（特別是微信對營銷的剋制。）關於活躍和留存：對於微信對應用號的剋制：用完即走，這意味着你無法對用戶進行羣Push或過多的營銷動作，如何做好用戶留存和用戶維繫更是一大難點
這個預測正確嗎？具體請參考App應用分發市場的發展軌跡
3.4 總結
應用號是WebApp和原生App的一種中間產品形態：在開發成本和性能體驗之間取得了很好的平衡
對於開發者、產品/運營者有機遇也有挑戰，具體情況要看具體操盤
對於用戶來說，應用號是一種新的技術解決方案，最後目的還是爲了滿足用戶日益變化的需求
4. 應用號的應用場景
在瞭解其功能和特點後，那麼，應用號適用於什麼需求場景呢？請看下圖：四象限需求層次圖：
橫軸=需求剛性，縱軸=需求頻次，象限=需求類別
四象限需求層次圖
4.1 象限1：高頻、剛需
對於高頻、剛需的使用場景，由於用戶使用頻次很高，對於產品形態要求：
尋找產品的成本要低
性能和流暢度要求非常高
應用號並不使用高頻、剛需的使用場景，因爲應用號：
尋找產品成本高：每次都必須在微信內重新搜索，成本比固定在手機某個位置高得多
性能和流暢度不及原生App
結論：應用號不適用於高頻、剛需的需求場景，該場景下應採用原生App
4.2 象限2：高頻、非剛需
對於高頻、非剛需的使用場景，由於裏面涉及的產品類型較多（內容型、工具型、社區型、遊戲型），要試情況而定：
娛樂類需求（閱讀、音樂、視頻、遊戲、社區）
閱讀類的內容型產品
需要深度閱讀環境和較高的交互、視覺體驗，建議使用原生App；當然你也可以先用訂閱號或服務號進行導流
偏工具的內容型產品（如音樂類和視頻類）
功能和性能滿足的前提下，基於開發成本和使用成本，建議採用應用號社區類產品
鑑於微信擁有強大的關係鏈，建議先用應用號進行快速試錯 / 作爲入口，待嘗試成功後再將流量導入到原生App遊戲類產品
鑑於遊戲要求很高的交互、視覺體驗和沉浸感，建議採用原生App當然小遊戲類別的產品，採用應用號是非常不錯的，因爲微信有着天然的獲客和傳播能力
日常工具類產品
在功能和性能滿足的前提下，基於開發成本和使用成本，建議採用應用號假如野心足夠大，有足夠的戰略佈局成爲平臺級產品的話，如美圖秀秀，可以先做應用號，再導流到原生App
偏運營爲主或帶有媒體屬性的產品
根據張小龍對應用號的定義：用完即走，可以預測微信對於應用號在推送消息、運營方面會非常剋制，這有區別於訂閱號/服務號推送消息、App推送消息，所以，假如你的產品是以運營爲主或帶有一定的媒體屬性產品，建議你還是優先採用訂閱號或服務號（具備發送消息功能），甚至是原生App
特別提到
由於高頻、剛需場景市場已經被巨頭壟斷，所以很多創業者基本會選擇在高頻次、非剛需的場景切入
區別於“原生App開發難度大、週期長、獲客成本極高、推廣成本極高”的現狀，應用號在開發成本和性能體驗取得了較好的平衡+微信天然的傳播能力和獲客能力，所以創業者應該通過應用號來進行MVP產品的嘗試
結論
對於高頻、非剛需的使用場景，採用的產品形態試情況而定，應用號主要適用於：
偏工具的內容型產品
日常工具類產品
社區類產品（作爲導流作用）
遊戲類產品（小遊戲）
創業者進行MVP產品形式的探索
4.3 象限3：低頻、非剛需
對於低頻、非剛需需求，基本是屬於小衆的需求，一般有兩種情況：
開發者自身興趣 / 專業級產品，面向某領域專業用戶
對於第一種情況，就看開發者本身的能力，如果你是移動端開發者，那就開發原生App；如果你是前端，就開發應用號
對於第二種情況，由於專業級產品一般對於性能和交互體驗較高，所以優先採用原生App
4.4 象限4：低頻、剛需
對於低頻、剛需的需求場景，這裏涵蓋了大量長尾的生活服務需求，比如說各種旅遊需求、各種上門服務等等。這類長尾需求的現狀是：
原生App：大量使用頻次過低（一個月甚至半年才1、兩次）的原生App卻佔據着手機大量內存
訂閱號 / 服務號：WebApp的性能和流暢體驗無法滿足功能需求
是的，這類長尾需求的的解決方案正是處於原生App和訂閱號 / 服務號 進退兩難的地步，而應用號是WebApp和原生App的一種中間產品形態：在開發成本和性能體驗之間取得了很好的平衡。所以說，應用號正好是解決這樣需求場景的解決方案
結論：應用號非常適用於低頻、剛需的長尾生活服務需求
4.5 總結
應用號場景總結：（以按優先級排序）
基本涵蓋所有低頻、剛需的長尾生活服務需求場景
初創企業進行產品模式的探索
作爲增量渠道，爲原生App進行導流
小部分高頻、非剛需場景
具體看下圖：
結論
5. 應用號的初衷
對不起，下面不會有”微信要做操作系統“諸如此類的長篇大論，僅僅只是同樣作爲產品人，對於騰訊、張小龍開發應用號的初衷分析
同樣作爲產品人，我一直堅持做產品的信仰：勿忘初衷。對於騰訊、對於微信、對於張小龍我相信亦是一樣：連接一切
微信作爲騰訊的拳頭產品，自然擔任着這種重要任務，我們先來看下微信的發展歷程：
微信1.0
目的：連接人與人
功能形式：即時通訊、搖一搖、朋友圈和附近的人微信2.0
目的：連接人與信息
功能形式：訂閱號、朋友圈熱文搜索微信3.0
目的：連接人與服務
功能形式：企業號、服務號
顯然，微信對於1.0時代和2.0時代的任務已經完成得無可挑剔，堪稱現象級產品策略和操盤。
但是，對於微信3.0 連接人與服務呢？微信爲搭建連接人與服務平臺試過了微信服務號，微信企業號，然而都沒有達到預期的效果。
同時，通過上面的四象限需求場景分析，你會發現，服務號作爲產品解決方案的需求場景基本被應用號所取代。
所以，應用號顛覆的並不是原生App，而是服務號。
請你把上面把應用號的作爲解決方案的需求場景換成服務號，你會相信便是現在市場現狀
雖然原生App的應用場景受到了一定的衝擊，但原生App的需求場景依舊無法被取代
騰訊又一次顛覆了自己，就像當年微信顛覆QQ一樣
再加上日常增顯的用戶關於長尾生活服務的需求：
原生App：大量使用頻次過低（一個月甚至半年才1、兩次）的原生App卻佔據着手機大量內存
訂閱號 / 服務號：WebApp的性能和流暢體驗無法滿足功能需求
是的，這類長尾需求的的解決方案正是處於原生App和訂閱號 / 服務號 進退兩難的地步，而應用號是WebApp和原生App的一種中間產品形態：在開發成本和性能體驗之間取得了很好的平衡。所以說，應用號正好是解決這樣需求場景的解決方案。
於是，在我看來，微信開發應用號的初衷是：
從公司戰略（初衷）出發，應用號實際上是微信在服務號的基礎上對提高企業服務能力的一次嘗試，更進一步連接人與服務。
從用戶需求角度出發，解決”大量使用頻次過低（一個月甚至半年才1、兩次）的原生App卻佔據着手機大量內存“+“WebApp性能無法滿足生活服務需求”的問題，爲了囊括市場大量高頻、非剛需的長尾生活服務需求場景，將海量用戶與海量服務進行對接，更進一步連接人與服務
在滿足用戶需求的前提下實現公司戰略和商業模式，勿忘初衷，這正是張小龍讓我佩服的地方
分析到這裏，相信大家已經明白：什麼場景下我該開發微信“小程序”，什麼場景下該開發原生App
6. 碎碎念
6.1 App是不是不用活了？
每當一種新技術的出現，人們往往會將其與之前技術對比，並採用”非此即彼“的做法。
一般出現上面這種言論的人，基本上是開發者：前端 Vs 移動端 。
我先問個問題哈
民國年代，人們基本以自行車代步；之後，當汽車甚至是飛機面世後，請問，自行車這種出行方式還存在嗎？
相信你應該能明白我的意思：任何撇開需求場景而空談解決方案都是沒有意義的，應用號僅僅只是作爲一種新的技術解決方案出現。
同時，從上面四象限需求層次分析可以看出：
原生App和應用號的應用需求場景不同，所以無謂說顛覆
真的要說顛覆，那麼應用號顛覆的是服務號，而不是原生App
應用號實際上是提供了一種新的產品解決方案，微信是在鼓勵H5開發，但依舊開放了App的接口能力，這說明未來H5和App並不是‘你死我活’的狀態，應該是混合應用的趨勢。
對於開發者、產品/運營者，要做的應該是正確判斷需求場景，然後選擇合適的解決方案更好地去服務用戶
而不是一味叫喧App將死、開發應用號就足夠了這些浮躁的言論。
6.2 應用號會不會成功？
早在微信做應用號之前，這種基於H5的“輕應用”模式已經被國內幾家巨頭所嘗試。
2013年，百度正式推出“輕應用”平臺。李彥宏當時對其寄予厚望，“未來搜索引擎在智能識別用戶需求後將實現無需任何下載安裝，直接調起應用”。
同樣的問題也出現在更早之前的瀏覽器“網頁應用”上。UC瀏覽器、360瀏覽器、百度瀏覽器等早在百度提出“輕應用”概念之前，就已經開始推廣“網頁應用”了，三者都基於客戶端或者手機瀏覽器進行架構。
但是，他們都失敗了。原因主要是：
“輕應用分發平臺”、“網頁應用”極大程度上依賴於主產品的屬性認知和使用場景：
搜索和瀏覽網頁的工具屬性太強，無法喚起人們進去使用其他服務的認知
搜索和瀏覽網頁屬於非剛需、中低頻需求，用戶使用頻率和活躍時長較低，無法撐起整個服務生態
但是，對於微信來說：
已從”即時通訊工具“轉變成‘生活服務平臺”：各種城市服務+生活服務，使用場景早已拓寬
本身社交屬於高頻、剛需的需求，保證了用戶的使用頻率和活躍時長
所以說，微信一定會成功嗎？我覺得倒不一定。
但是，假設有一天，如果有一款產品能在“輕應用”領域上取得成功的，我相信一定是微信。
最後再嘮叨幾句：
微信稍微掀了一下裙底而已，不要一下子都高潮了
對於用戶來說，我建議你的手機清多幾個G內存來迎接應用號的到來
對於產品 / 運營者來說，要做的應該是正確判斷需求場景，然後選擇合適的解決方案更好地去服務用戶。跟風最可怕
對於開發者來說，興趣最重要。跟風最可怕
文／Carson_Ho（簡書作者）
原文鏈接：http://www.jianshu.com/p/fea74033717a
最近的微信公開課上，小龍哥又再一次解釋了小程序，可以概括爲“微信as新型瀏覽器，小程序as新型網頁”。個人感覺，小程序能夠作爲用戶的入口，可以佔領一席之地，但稱霸天下幾乎不大可能，小程序正如上面分析，也有其限制性，只能說很好地滿足用戶某些使用情景。儘管只是一席之地啊，但這個地可不少啊！有戲！！