微信的一舉一動，張小龍的一言一行，都是互聯網上的大新聞。昨天，在微信公開課 Pro 活動上，騰訊微信事業群張小龍罕見地現身並演講，闡述了微信的四個價值觀，然後，宣布了微信的一個 “應用號” 的規劃：“我們將開發一個新的形態，叫做應用號。用戶關注了一個公眾號，就像安裝了一個 App 一樣，他要找這個公眾號的時候就像找一個 App 一樣。”
至於更多的信息，張小龍和微信團隊的其他人就沒有透露更多了。但是，愛範兒還是找到了曾經參與過應用號早期項目的第三方人士，了解到了不少的信息。
提到這個不甚明了的 “應用號”，很多人肯定會想到兩三年前著名的 Web App 和 Native App（原生應用 / 本地應用）之爭，由於 HTML 5 的興起，加之 Native App 需要耗費大量人力來開發維護適配，給許多人以做 Web App 希望，然而，Web App 不可能單獨存在，必須有一個依托，因此，國內一些互聯網廠商就有了以 Web App 為雄兵，稱霸移動互聯網的想法。在國內，Web App 有了新的叫法和變種，也就是我們俗稱的輕應用。而正兒八經要去推廣輕應用的，是百度、360 和 UC，這三家都是在國內移動互聯網中很有話語權的廠商，然而，從大家的使用習慣也都看到了，這三家在這兩年時間裏力推的 “輕應用” 並沒有落地，隻是一個出師未捷身先死的概念。現在，人們提起兩三年前的 Web App 和 Native App 之爭，不過報以嗬嗬，HTML 5 是很棒，但是基於 HTML 5 的 Web App 在體驗上完全無法和 Native App 相比，至少整體上是這樣的。前情大概如此，回過頭來說微信，其實在其他幾個國內互聯網巨頭想推輕應用的時候，微信也不是沒有想法，事實上，微信在兩年多前就已經埋下了應用號的伏筆——JS-SDK：“微信 JS-SDK 是微信公眾平台麵向網頁開發者提供的基於微信內的網頁開發工具包。通過使用微信 JS-SDK，網頁開發者可借助微信高效地使用拍照、選圖、語音、位置等手機係統的能力，同時可以直接使用微信分享、掃一掃、卡券、支付等微信特有的能力，為微信用戶提供更優質的網頁體驗。”據消息人士透露，兩年前，微信應用號立項的時候，構想的邏輯是這樣的：主要是 JS-SDK 提供的 Native API，可以讓一個 Web App （HTML5）在保持網頁的輕便的同時，擁有音頻錄製播放、照片拍攝、掃碼、搖一搖等原生應用的功能。因此，這套微信 JS-SDK 其實就是兩年多前微信為應用號埋下的伏筆。而在微信重新撿起應用號之前，微信又在訂閱號之外，推出了服務號，為的是鏈接商家和用戶，提供相關的服務。但是，張小龍自己也承認，服務號沒有達到預期。這個沒有達到預期原因很簡單，服務號和訂閱號形態非常類似，都是自定義菜單加對話框的模式，層級深且不明顯，效率太低，最後，服務號就變成了一個每月隻能推送四次消息的訂閱號，反而沒有突出 “服務” 的概念。從而，服務號沒做好也可以算作是微信的一個敗筆，尤其引發的，則是訂閱號和服務號合並的消息在滿天飛。
微信應用號的形態？
在討論微信應用號的形態的時候，則需要引入第二個概念：Hybrid App（混合應用 / 雜交應用 /……），Web App 優點很多，當然，缺點也很多，就此的討論一抓一大把，比如純 Web 前端架構，很多重要手機特性無法訪問，例如聯係人以及 Push Notification（消息推送非常重要）之類的。某種程度上說，微信應用號的形態就是一種 Hybrid App。此處 Hybrid App 和 Web App 最主要最核心的區別，就是能不能調用底層的 API，實現特定功能，比如上麵的獲取聯係人信息，讀取存儲文件等等。比如最著名的 Hybrid App 開發平台 PhoneGap 的插件能夠幫助開發者快速地抵達手機的其他 API 上麵，直接使用 Javascript 來操控這些底層的 API。例如調用 Push Notification 的相應發生的事件。但是應用號有所不同的是，它依托於微信平台，而不用像其他的一些 Hybrid App 那樣跑到應用市場分發，也就是說，常規的 Hybrid App 其實解決了開發上的難點（主要是跨平台的問題），但是無法解決分發的問題。應用號此處的優點是，關注即可使用，分發成本很低，幾乎等同於公眾號獲取粉絲的成本。具象到微信應用號上，其界麵就已經完全脫離了之前訂閱號和服務號的形態，最直觀的，就是沒有了對話框和自定義菜單，轉而是將 Web App（HTML5）提到公眾號的第一層級，讓功能更為直觀地抵達到用戶，用戶的學習成本更低，使用效率更高，應用號直觀的形式遠比服務號下麵不點開就不知道是什麽的自定義菜單好。說到這裏，其實關於微信應用號已經有了非常好的展示雛形，微信 “發現” 中的 “購物”，“錢包” 裏的 “美麗說”、“吃喝玩樂（大眾點評）” 等等，就可以理解為微信應用號的一種形態。至於應用號，與合並之後的 “訂閱號 + 服務號” 的區別和分工，應該是這樣的：應用號並不屬於公眾號的一種，而是與之並列的。微信內的京東購物和京東服務號來講，在 “購物” 內買了商品，這邊的京東服務號就會推送交易信息詳情。二者之間的合作就好像這邊我在格瓦拉應用上買了電影票，然後短信接受到票務信息。好了，上麵已經說了，JS-SDK 提供的 Native API，可以讓一個 Web App （HTML5）在保持網頁的輕便的同時，擁有音頻錄製播放、照片拍攝、掃碼、搖一搖等原生應用的功能。那麽我們可以預想一下，利用這些 API 接口完成的一個應用號，暫且稱之為 “有聲賀卡”，進入了這個應用號之後，用戶可以調用相機拍照得到照片，然後調用麥克風錄製音頻，生成一張有聲賀卡分享到朋友圈或者發給朋友。
Q&A
前麵已經說到，應用號和公眾號是並列關係，因此入口就值得深思，如果入口太深，是一個類似於購票轉賬的三級菜單，勢必會影響使用效率，但是它的重要性也不及 “微信、通訊錄、發現和我” 這四個一級菜單，合理的推斷是在 “發現” 或者 “我” 之下新開一個二級菜單，並且在搜索框下有提示。當然幹不死 App，都說微信想做一個操作係統，但是 HTML5 的局限性還是很大，預計應用號對整個 App 的市場衝擊會比較有限，應用號的適用場景以及想象空間都不如 Native App，比如，現在的微信 JS-SDK 還沒有開放視頻錄製的 API。並且，很多 App 的死掉，根本就不是外部競爭導致的，App Store 裏麵一大半的應用都是僵屍應用。相比於瀏覽器，搜索以及應用商店，微信使用的頻率高，時間長，黏性強，應用號達到用戶的可能性也大很多。應用號和訂閱號之間可以配合，形成閉環，解決 “輕應用” 服務之後還是會脫離瀏覽器或搜索服務的問題，比如用完後還是需要切出到短信通知或係統通知等。簡而言之，應用號和訂閱號的客服通知體驗好太多。事實上，我覺得 Web App 體驗最大的痛點就是加載慢，而微信內部的一些服務也是如此，比如購買電影票。如果微信不對應用號進行緩存處理的話，我對應用號解決 Web App 加載慢的問題保持懷疑態度，尤其是加載一些複雜頁麵的時候。但是，在處理一些小頁麵的時候，這個問題不會太誇張。這也呼應了上麵那個 “會幹死 App” 的問題。在微信網頁開發者工具發布之前，前端開發適配微信頁麵的調試極其不便，必須通過非常多的服務端 Hacking 達到模擬線上環境，從而進行功能測試。而剛剛發布的微信網頁開發者工具能夠極大地提高調試效率，方便應用號的開發。 