---

微信的一举一动，张小龙的一言一行，都是互联网上的大新闻。今天，在微信公开课 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 吗？

当然干不死 App，都说微信想做一个操作系统，但是 HTML5 的局限性还是很大，预计应用号对整个 App 的市场冲击会比较有限，应用号的适用场景以及想象空间都不如 Native App，比如，现在的微信 JS-SDK 还没有开放视频录制的 API。并且，很多 App 的死掉，根本就不是外部竞争导致的，App Store 里面一大半的应用都是僵尸应用。

应用号比“轻应用”好在哪儿？

相比于浏览器，搜索以及应用商店，微信使用的频率高，时间长，黏性强，应用号达到用户的可能性也大很多。应用号和订阅号之间可以配合，形成闭环，解决“轻应用”服务之后还是会脱离浏览器或搜索服务的问题，比如用完后还是需要切出到短信通知或系统通知等。简而言之，应用号和订阅号的客服通知体验好太多。

应用号能解决 Web App 加载慢的问题吗？

事实上，我觉得 Web App 体验最大的痛点就是加载慢，而微信内部的一些服务也是如此，比如购买电影票。如果微信不对应用号进行缓存处理的话，我对应用号解决 Web App 加载慢的问题保持怀疑态度，尤其是加载一些复杂页面的时候。但是，在处理一些小页面的时候，这个问题不会太夸张。这也呼应了上面那个“会干死 App”的问题。

微信网页开发者工具发布和应用号有何关系？

在微信网页开发者工具发布之前，前端开发适配微信页面的调试极其不便，必须通过非常多的服务端 Hacking 达到模拟线上环境，从而进行功能测试。而刚刚发布的微信网页开发者工具能够极大地提高调试效率，方便应用号的开发。