IT思维

微信应用号本质上是定义了一系列 HTML5 标签，来实现一些可以在微信里面展示的页面组件，同时通过微信作为中间层，提供一些原来只有 Native 应用才能实现的调用系统资源的能力。从技术角度上来讲，这并非是什么改变世界的创新，在很久以前，有个东西叫做 Weight ，再后来，还有个东西叫浏览器插件，再再后来，Facebook之类的开放平台，用的都是类似的技术。而在移动端，PhoneGap 之类的工具也早就提供了用 HTML5 实现 App 的能力。唯一令人激动的是，今天做这件事情的是一个拥有几亿用户量的超级应用。

刷了一下朋友圈，发现了很多人在说，哎呀 Native 程序员要失业了，未来是 JavaScript 的天下了，招个前端就全能搞定了，持这种观点的人通常是在阿里月饼事件中站在阿里一边的那群非技术人士。这时我总喜欢搬出老罗的例子来讲：外行总是喜欢以他们乐于见到的结果来轻视内行持久的技术积累。应用号并不是提供了原生应用的替代品，微信管这个东西叫“小程序”，而不是“微信应用”，是合适且贴切的。指望应用号能替代所有原生应用可以实现的功能，是不可能的，微信自己也并没有这么说过。

微信有自己的优势，国民级应用，几乎是世界最大的装机量带来看上去几乎无限的流量红利，应用号本身又屏蔽掉了一些开发原生应用的复杂度，大概80%的业务，只要不是与系统调用密切相关，且以内容、数据的流动为主要目的的应用，几乎都可以用应用号很好的实现了。

而从业务角度上来看，作为一个企业，做原生应用，还是利用微信平台来发展自己的用户，不是今天才有的问题，也从来不只是个技术问题，而是需要结合业务状况，想清楚你要的是什么，再来做决定的。而这件事情的坑在于，如果你只关注应用号，相信了再也不需要开发原生应用的说法，你就会将业务的未来完全交给了一个你控制不了的平台。当然我相信腾讯是一个在中国最有节操且没有之一的公司，但尽管如此，Uber 的“系统抖动”事件仍然历历在目，加之中国特色的监管问题，实在没有太多理由来信任微信作为中间层，把控住从用户到系统调用能力的玩法。

从来没有一个互联网公司能持续火十年，全民微博的时代历历在目，而现在的微博几乎变成了二三线网红和锥子脸的天下（吕欣欣语）。五年后，微信会变成什么样，不大好说。当然，IM 工具有它独有的“续命”逻辑，但长期看总会出现下滑的，到时候你让用户先装个微信，注册成为微信用户才能用你的业务么？我看这可能挺难的。如果不提前做一些工作的话，到时候面临的可能是几个平台的用户割裂问题。

当然了，当下看来，相信作为一个超级渠道，过几天会涌现出无数的“微信小程序”出来，但流量红利迟早会被瓜分干净的。现在获取一个原生应用安装的成本，已经是惊人的高了，应用号未来也会出现类似的问题，一旦玩家增多，流量和注意力必然就不够分的了，获取成本就随之上升。微信早期的订阅号，很容易就能达到一篇上千甚至上万的阅读，而今天一个新公众号，能达到这一水平的显然要付出更多的努力甚至成本。结合微信现在的安装量以及公众号的流量积累，应用号的红利期恐怕会更短且会自然集中在一些已有的大号身上。

有人问了，你说了这么一大堆有的没的，到底我要不要做应用号呢？我的建议是当然要做，毕竟用户在那摆着呢，但请结合自己的业务需求来做，把应用号当成一个渠道，而不是唯一入口是更靠谱的选择，目前我还没有看到应用号的具体文档，以微信以往的风格来猜测，可能需要注意以下几点：

• 微信的单点登录非常方便，但也非常鸡贼，给你的用户信息里面并没有任何真实信息。如果应用号也是如此，请自己做一个用户绑定的过程，尽量把用户的真实信息拿到。否则，一旦微信不高兴，你会发现数据库里面只有一堆形似乱码的 openid ，没有任何办法再联系到用户。

• 尽量把后台接口统一起来，不管从应用号，还是网站，或者是未来的什么号里面，拿到的数据应该是一致的，而不应该是割裂的。在国内，用户体系不要交给第三方来管理是个无奈但必要的选择。

• 系统级别的调用，会依赖用户对微信的授权，且必然会存在效率问题，如果你的应用依赖过多的系统调用，原生应用可能仍然是个不得不的选择。
• 最关键的，一定要保有除了微信以外的业务入口，万一 “系统抖动” ，真心伤不起啊。

最后，以创业的思维来看，用什么来做 App 不重要，关键是你的业务是不是足够吸引用户，应用号本身并不是一个创业机会，背后的业务才是。

回到技术本身，如果想要用 JavaScript 写移动应用，并不一定需要借助微信应用号，最近比较火的 React Native 就可以很好的解决，而且不会出现对第三方平台的依赖，系统调用更加全面、直接、高效。

微信公众号：乱槽之巅