如何看待微信将推应用号？

因为之前有参与做 messenger platform，所以一直也很关注微信的开发者平台。下面是我这半年来的一些小总结，抛砖引玉，希望大家能多多交流。

回答这个问题之前，我们先看张小龙大神是如何定义小程序（也就是应用号）的：（截图来自网络）

在微信之父的这条朋友圈里，很明显地表达了“小程序”的几个特点，下面一一来给大家进行解读：

1. “触手可及”、“不用下载和安装”

这个就不赘述，用过微信的人都明白不管订阅号还是服务号是比app更加轻量级的存在。不管是用户的使用成本，还是初创公司的开发成本，都要小很多。

2. “用完即走“、”无需安装卸载“

这点一直是我最为佩服微信和张小龙的地方，也是他本人一直强调的：对于工具类的产品：一个好的产品不是黏住用户，而是尽量让这个用户可以100%（甚至200%）高效地满足用户需求之后，让用户可以继续去干其他的事情。

引用小龙同学年初在腾讯公开课Pro里的演讲：

我们认为任何产品都只是一个工具，对工具来说，好的工具就是应该最高效率的完成用户的目的，然后尽快的离开。如果一个用户要沉浸在里面，离不开，就像你买一辆汽车，你开完了，你到了目的地，你说汽车里面的空调特别好，所以要待在里面，那不是它应该做的事情。所以业界很羡慕微信是用户的时间杀手，但是我们要考虑的则是怎么样更高效率帮助用户完成任务，而不是让用户在微信里面永远都有处理不完的事情，所以大家会看到微信的朋友圈会限制很严，各种营销在朋友圈里面我们都会很严格的对待。因为朋友圈的进入次数特别多，平均一个用户每天大概有30、40次进入朋友圈，这是一个反复的过程，我们希望每次进来用户都不是很快的刷屏，而是看到的都是他愿意看到的内容。在这一方面做的好的例子，我觉得是谷歌，谷歌在很多年前就提出来让用户搜完就走。在这点上，我们会希望微信里面的信息尽可能的少，少到只能满足你最基本的需求，这样你就明白微信为什么会有这样一些规则。

每次我重新读一遍他的演讲（甚至是2013年他的8小时分享），我都感觉会学习到新的东西。上面说的这些要点有点 counterintuitive，但有极为有道理，讲出了很多中国产品面临的浮躁和短视的问题。个人强烈建议：2013年小龙8小时分享也应该多温习一下。

=== 应用号推出的意义 ===

就我个人看法，微信这一步走得是太牛逼了；如果小程序的发展没有出现致命的问题（比如：安全性的大bug、或者性能出现大的问题、或者被Apple搞、等），微信在国内移动届唯一的超级app地位会进一步加强，变成名副其实的 Web OS，重要性不亚于 半个Android + 半个iOS。更厉害的是，在世界其他国家我还看不出来有这么一个app能达到这么高的penetration和user session length，这一点上Facebook + Whatsapp 也只是在后面苦苦追赶（当然，他们的用户数要比微信多不少）。

还记得在2012年底的时候，微信团队来过硅谷和我们这边的工程师交流，当时他们就问了大量的关于 facebook open platform 的问题，那时他们说他们想做平台。我小时候以为这是必然的路线：工具 -> 牛逼工具 -> 转平台，就好像从头牌要转成妈咪桑一样。Facebook 在方面做得还算比较成功，而反观微信在最初几年只是在模仿世界巨头做开放平台，甚至在一些细节上还栽过跟头，比如：微信开放平台开始还推出过在消息附件里来开发插件的功能（比如消息附件里直接放知乎图标），后来发现没法维护，就直接被叫停。再后来订阅号可谓是风生水起，再辅以服务号，微信其实在2014年就已经甩开世界上其他的主流 messenger 几条街。

我很同意现在流行的说法： WechatOS，微信这app在中国就仿佛一个操作系统的存在。我朋友、家人在上面，我和同事的同桌信息也在上面，我消遣和娱乐很多时候也在上面，最要命的是回国这两年，发现我的微信收藏夹里放了很多很重要的信息（好文章、个人信息、重要照片、还有一些工作上的纪要），我很难想象没有微信之后我的生活和工作要如何进行。猛然发现，我从US回到中国后，一个月不上Facebook不看news feed也不咋样，但是每年几年回美国的时候，一不上微信就感觉好像会错过很多消息一样。更有趣的是，很多时候我发现我对手机操作系统（比如iphone or android）其实是中性的，用哪个都无所谓，只要上面下载好了微信、知乎和邮件客户端即可。所以嘛，我一直认为这是一个明星应用开始rule the world的时代，就好像 Marc Andreessen 之前一直吹的那句话：“Software is eating the world."

真心希望张小龙和腾讯把应用号做好，这样我再也不想去多下其他低频的app。其实Apple应该在这里多检讨一下，不过是iphone还是mac上，那个app store的速度和在US没法比，而且是经常直接GG。Apple很多时候就是脑子不太转弯，鼠标如此，插口如此，最新出的“牛逼”耳机更是如此。所以，祝微信OS一统中国的江湖。

=== 小程序（应用号）的技术实现 ===

从各大公众号上画出的应用号SDK的图，可以看出主要的加强增加了存储、文件和websocket的支持，也就是说整体提供的功能更加地接近于原生app。

基于今天早些时候网上流传的小程序开发的IDE：

我自己也clone了一份下来玩玩，发现小应用平台的一些技术特点：

1. 首先是有一个像模像样的IDE给开发者们，就类似一个微信公众号的操作后台给运营一样。微信还算体贴的：

看左侧的显示图，整个小程序基于经典的 tab bar 结构，不同的tab里嵌入不同的网页页面。

2. 基于 HTML5 + 类HTML + 类CSS，当然微信这里洋气了一把，取名为：wxml + wxss。类似于Facebook的 React Native 里的 JSX + CSS flex（其实是CSS的一个子集）；微信这么做的原因也很直接明了：前端那一锅粥一样的js和css标准谁要兼容谁自讨苦吃，所以不如模仿Facebook就只实现一个子集 --- 简洁且现代化的子集。

具体来看：

小程序 Demo app 的目录结构很简单：根目录下是整个app相关的代码， app.js 是整个小程序的入口，就犹如iOS的 AppDelegate 一样，另外 app.json 配置一些全局属性（app环境变量），wxss设置布局样式，README.md你们猜！ 这里趁热看一下 app.js：

就是一个js的老式class；这里遗憾的是没有支持 es6，这个语法让我想起了我刚进FB的时候，写backbone app时的岁月，那时还是2011年初。具体的特点还有：

1. onLaunch, getUserInfo：函数顾名思义。wx依然是一个微信官方的全局接口；

2. StorageSync 可以在整个app里存储状态；

3. 代码还算清晰，另外用了2空格缩进，让我看起来觉得终于舒服了。这里提一点，我很不习惯国内的4空格缩进，在硅谷互联网公司大部分都是2空格缩进的，不管xcode、java、python、js、etc。另外不管facebook还是google所提倡的code format全部都是2空格缩进：

我2007年去Google实习后，就一直写2空格缩进的程序，写了7、8年了，我以为整个世界都是2空格的；其余人睁大眼睛看着我说：“啊？我从大学学习写程序以来就是4空格，你这个2空格是什么野规矩，你们海龟程序员就是不接地气。。。” 于是我也妥协到4空格。。。 从今天开始，我和我公司下面统一规范：2空格缩进，正式回到和国际、微信接轨的路线上来！o(︶︿︶)o

什么？你还在用4空格吗？什么你还在用J2EE？什么？你还在用SVN？你out了！！！我大声喊道！

好的，多说无益，我们继续看代码：

目录结构进一步打开：首先子目录分为: pages + utils， utils里当然就是一些 underscore 或者lo-dash 里常用方法（来，又是一个争论，underscore 和 lo-dash 哪个好？

），另外一个更加重要的目录就是 pages。这个demo中，pages下面有3个页面：index, logs, main，比较肯定就是对应于应用号下面的tab，这里定义了3个tab，每个tab一个page，分别是 index、logs 和 main。事实上，我们看根目录下的 app.json

清晰定义了 app 的pages： index 和 logs。

接下来看pages里的文件树，也是类似的格式：

- js 用来写逻辑代码，类似controller

- wxml 类似 html，写网页的view

- wxss 类似 css

- json 装属性

直接了当，简洁明了，赞一个。我最讨厌就是一些大公司（比如Facebook）喜欢在SDK里秀技术，最后搞得3rd party developers很难理解，经常处于一种边查SDK文档边骂娘的状态。

然后，我们依次看logs里的这4个文件：

--- logs.js ---

同样的风格和味道：data用来放internal state，onLoad顾名思义，它做得事情就是把app onLaunch时得到的logs从 storage 里取出来，存在data field里。

--- logs.json ---

不用解释

--- logs.wxml ---

类HTML的格式，同时自定义了一套微信自己提供的view tag，很好！这里还有一个 for 语法，来遍历来自controller的 logs 变量，然后将其显示出来。

--- logs.wxss ---

类似CSS；和Facebook React一样，支持 flex box 布局。（当然对于css只是一个子集的支持）

最后一句：（且从微信团队求证）最外面的tab是由原生控件来渲染之外，其余tab里的显示全部都是HTML5 page，也就是说 应用号的技术 是基于 html 网页的，和 Facebook React Native 有着本质的区别。另外代码风格上还是基于经典的 JS 语法，没有使用 ES6，另外和 React 的 js 中反写 html有着天壤之别。可以看出微信团队肯定是借鉴了 vue 和 react 的很多思路，但同时有着自己的独立判断，整个框架写得还是挺符合国人习惯的。

=== 对于创业团队的启示 ===

朋友圈里很多人开始宣称一个新的风口的到来，我个人的观点还是趋于保守（做风投的习惯？） 一方面是我认为应用号这种并不完全解决创业的本质：“product / market fit”，这点还需要创业者们自己去摸索，所以应用号并不是创业者的灵丹妙药。

假设产品已经找到 product / market fit 之后，这是应用号的威力逐步显现出来：

- 应用号的流量和推广红利无疑是显而易见的：无需安装、微信人人都有、且对于手机OS中立

- 开发程度相对于app要小不少，不需要做ios和android的双重开发

- 再分享和朋友圈引爆更加方便，可以运用之后我要说的growth hack来supercharge整个应用号的流量爆表。

所以，对于一些明显有用户且轻量且相对中高频的应用来说，这的确是一个绝佳的机会。我个人建议初创团队这样做技术选型：（注意，我不太同意一些文章里说的四象限的分法，相反，我觉得应该按照公司的阶段来）：

1. 初期：如果是媒体或者新闻类创业，使用订阅号，千万别赶时髦上应用号；其他类型创业，订阅号+应用号一起上（订阅号用来做内容推广和吸粉），应用号跟着腾讯的节奏逐步开发；网页依然要有，选用一个单页的landing page即可；
2. 中期：如果模式得到验证，可以转入 react native 的阵营，即做基于原生的 react native 应用。这里一方面是因为原生app可以更好地和用户进行更强的交互，另一方面则是 react native 基于 js + css，和应用号的技术栈有异曲同工之妙，所以切换相对简单。另外 react native 是一种桥接技术，所以在 app 上可以开发任何原生功能，只是这部分就用原生硬写。这里隆重推荐一个Facebook前同事的创业作品： Exponent IDE：一个用来生成、开发和维护 react native 应用的IDE：Exponent （感觉微信小程序的IDE是模仿它）
   

   

   

   一键式创建、集成、部署 react native 程序。
3. 成熟期：这个阶段公司的商业模式明确、融资也敲定，开发和产品团队也具有一定规模，理应采用国际通用的三板斧策略：即 HTML5网页 + iOS/Android原生 + 应用号/订阅号 都上。多说无意，可以参照：滴滴、美团、大众点评、京东等。

只不过我看到很多初创团队一上场就开始用三板斧策略开敲，沉浸在疯狂加班的自我陶醉中，然后一步步越走越重，还没来得及验证和转型，就因资金链断裂而亡。

我很同意朋友圈里看到的一句话：“其实微信小程序本身不牛逼，类似的百度直达号，chrome app早就出现了，然而这次这么火，是因为微信牛逼，当年公众号，服务号一出，养活了一大波公司，如今又有一次机会到来，还会有人想错过吗？很多idea本身其实没什么，但是做的人不一样，结果也大相径庭。” 所以，不是小程序猛，而是微信这个平台（载体）猛！

=== 应用号 + 微信OS 的短板和危机 ===

1. 是不是动了苹果的奶酪？会不会被苹果勒令禁止？

个人觉得有一定风险，但是问题不大。关键是要和apple把利害关系沟通好。Apple现在的发展并不被华尔街看好，另外来自android的冲击越来越大，Apple没有太多筹码来进行专制统治。另外，Facebook messenger早就在大肆推广自己的bot，比起这个小程序是有过之而无不及。其实当年Steve Jobs在世的时候，仗着 Zuck 和 Steve 私交好，各种 pre-release 的 Apple SDK 给FB先用；另外 Facebook main app 和 Paper 里引用了一些 private APIs，Apple也是真一只眼闭一只眼（当然，每次新版本开放之前，这边的一帮PM都先开车到Apple HQ，然后给他们先演示和预警下新版本的改动，打一个预防针。）

2. 应用号可能带来的问题？

能看到最麻烦的问题是 微信不是一个多任务的系统，功能之间的切换很是痛苦。举例：多少人看朋友圈，或者公众号的好文章的时候，觉得错过消息或者没法快速切看自己的消息很麻烦？遥想之前微信还有提示，左上角还有对于未读消息的计数，但是后来为了方便用户安静地看朋友圈，这些都取消。微信估计如此为之，肯定是有自己原因的；小龙自己说过给用户的导航和跳转必须是一维的，如果做成像之前Facebook的那种可以左滑右滑的app导航，那简直就是灾难。那么现在问题出来，如果后续应用号蓬勃发展，微信变成OS之后，所有用户层面OS的问题微信都需要解决一遍：比如消息通知，比如多应用切换等等。其实我倒是推荐Facebook里之前尝试过的多应用下的消息查看方式：

学名叫做： chathead，就是对于新来的消息，直接弹出头像进行查看和回复：

而且在中国，微信可以直接嵌入到安卓和iOS的系统级别，成为一个游离在 OS 和 apps 之间的一项基础服务；也就是让 微信chathead 出现在整个OS里：

简直完美。

3. 微信的滑铁卢？

写这点只是为了让答案更加辩证统一。外界很多时候只看到了微信高歌猛进和光鲜亮丽的一面，但是微信背后出现的问题却因为微信在国内的成功而被忽视：“国际化惨败”

还记得这几张图吗？微信早在2012年就在硅谷和世界其他地方设立office；腾讯或者说pony同学一直就想让公司有一款国际化的产品，之前QQ国际版就是基于此目的出现。而2012年微信可是卯足了劲去做国际化，小马哥也认为这是腾讯最好的一次机会。现在4年过去，结果比较明显：

请看2015年 Mary Meeker 的互联网报告：

Whatsapp: 8亿用户，60%的年化增长；而微信 5.49亿用户（绝大部分在亚洲和华人），而年化增长率只有39%。微信的增长率已经开始放缓。在2015年微信的增长率已经放缓，微信用户量小于whatsapp不少，但是增长率只有其一半多点。在欧美非洲的非华人圈里，微信的 adoption rate 很低。

背后原因有很多呀，之前在北京和微信PM Dan 还单独聊了一会，有产品版本问题、有cross boarder office管理的问题、也有 cultural chasm 的问题，后续想写一篇专门分析的文章。所以，还是之前我说的那句话，各位一方面在嘲笑老外app幼稚简单的时候，是不是也应该对称地想想：每次我去叫老白同事试用中国app的时候，他们脱口而出一句：“this is fxcking complicated (or messy).” 我翻译下：”这些app简直复杂得一b“。 当然罗，如果在US住过工作过的话，你会哈哈大笑，的确，我们大到一些制度比如户口、出入境、签证、居住证、暂住证、驾照、XZY证小到修路、开车、电话和科学上网，全都比国外复杂得一b。天天想想多少人和公司的时间和精力都在处理一些本来不是问题的问题。（好忙呀！）

-------------

未完，持续更新。后续，小应用demo的试用和深度剖析。

昨晚一推出应用号内测的消息，群里，朋友圈里就热闹成了一锅粥，仿佛每个人都觉得自己的机会来了，要靠着这一波微信新机会逆袭。这个答案里的内容很多是你在微信上看不到的。

这个回答原本我一个8个月之前的答案，也就是张小龙在那场演讲后的一个月，我写的关于应用号未来的一个预测以及站在微信角度的一些思考。当时的答案是预测微信要去做一个长尾市场。

是原来的答案

那个老答案在昨晚就开始陆续有人点赞，一晚之间得到了100多人的关注，也收到了很多私信。现在应用号真实的出现了，我就删除了原回答，因为原回答时效性可能消失了，我把昨晚思考了很久的想法重新写成了新答案。这个新答案更多的会结合分析给出实用的建议。

当然现在还是内测阶段。我也会在应用号正式推出后继续更新

---------------------------------------------------------------------------------------------------------------------------------

关于微信昨晚推出内测小程序，我想大家已经在微信上看了足够多的东西了，我这边说说一些别人没有思考到的点。

应用号入口在哪里？

这是各种文章中对于应用号的入口的预测。以“发现”版和“我”版为主要猜测方向

如果是这样一个入口我觉得是非常深了，让我们来算一算如果是这样一个入口，对于一个应用来说叠加了几个层级

第一层：消息界面 +

第二层：发现/我 界面 +

第三层：应用号选择界面 +

第四层：进入真正的应用里 +

• 让我们从用户的使用场景来想象一下这个情况会造成的后果
  

场景一：你正在操作一个应用然后收到一个人的消息，你去回复一下，然后回去再次进入这个页面回到之前的位置，你的操作直至少需要4+x步（x为你操作到的位置），当然有一定的缓存（很有限），所以可能是x-n

对比一下Native App你会发现层级多了不是一点点，而懒是用户的天性，这样的操作体验无疑会大大减小使用率。

场景二：你在手机上有多高的频率切换自己的应用？如果每一次切换都要重新从首页开始操作是怎样一种体验？你是不是感觉要崩溃了。

你们在使用微信的第三方的时候应该有过类似的体验，这种难受你懂。

• 说一个我的看法：
  

从“界面设计”上来说应用号将可能成为除了“消息，通讯录，发现，我”这四个tab后“第五个Tab按钮”

这个点很多人表示无法赞同，甚至觉得可笑，参考上面说的场景你就能感觉到每少一个层级带来的操作简化有多少，这个重要性不言而喻，直接放在TAB5，直接相当于减少了2个层级，当用户操作多的时候，每次以2个层级叠加，简化的操作将不止一点点。

然而这个不太可能在内侧或者正式发布的前期就去这样做，更有可能在后期再给出更前端的入口，也就是'tab‘，早期基本就应该是在“发现界面”或者“我界面”

那些说藏在钱包里的朋友我就不吐槽了，你脑补一下自己的产品体验的画面吧。

为什么应用号对于创业者来说是福音

• 成本

native的成本到底有多高？

推广：平均成本5元一个下载 ，100万的下载量，月留存能有10w的都是少数中的少数

开发：安卓，ios要分开做，大量的机型、os版本差异、交互特殊等

就这两项能承受起的就不多了，最低起步价30w+左右，巨额的成本将大量的idea扼杀在摇篮里

而这些死掉的idea大部分就是因为市场小，盈利跟不上巨大的成本而看不到未来

• 从外部走进微信生态内部

服务更加快捷方便，用户的使用门槛大大降低。通过微信生态的流量转化更有效率，多少app的用户是通过微信文章推广流量带去的？一旦你就在这个生态里，只需要简单的操作，比如扫码，这个效率高了多少？

微信想为创业者提供怎样的价值

微信做的就是把开发和推广这两项成本尽可能的降低，推掉成本这座大山，改变移动互联网应用的规则，让创造者能把核心资源（钱和时间）关注到用户体验上，去真正为用户创造价值

应用号到底适合做什么？

微信已经做好了人与人的连接又做好了支付，现在微信希望的就是通过应用号将人和服务深度连接

连接上人与服务后微信的价值那就更是不可估量的了

服务是核心！

这就和native app时期有了一定的区别，这里更欢迎的是服务性的app，也就是他说的用完即时走。

早在8个月前，我就说微信要做的是一个长尾市场，聚合那些无法承担成本去独立做成app的服务。就像当年的亚马逊一样，几乎没有什么商品你在亚马逊上找不到一样。而现在微信就相当于是把商品变成了服务这种非标的东西。

“小而美”的产品更适合应用号，能获取较多的红利，真正高频常用的还是在原生app那边更好，当然像同程旅行火车票这种刚需路径短的还是很适合微信生态的。

小而美的服务是什么？

答：低频、非刚需基于场景的服务，在特定场景下（也就是够垂直）可以较好得解决用户需求。

许多付费的服务可能借力因此焕发出第二春，教育、医疗、家政、求职招聘、二手买卖、旅游、票务、金融理财、汽车后市场等等

最后再泼点凉水，让你冷静一下，给一些重要的建议

1.你所能获取的用户数据将非常有限，微信给你开放的用户数据基本就是头像和昵称还有一定的好友关系。数据对你自己的重要性一要考虑清楚！

2.商业模式与native app将发生巨大改变，拿native app的思路去套做好的可能性几乎为零，你要重新构思并快速去验证。我觉得思考比行动更重要，在正式开发之前需要在，你要知道先入者不一定是先驱，更有可能是先烈！

3.免费的模式不一定就好，多考虑付费形式，不仅只是因为微信已经帮你做好了方便的支付接口，而是因为应用号的形态和设计初衷更适合基于场景需求的快速实现。

4.还是那句话，小而美，做垂直，功能复杂度有限制，如果想做成庞大的独角兽，必须是高频刚需但复杂度又不是太高，就像“同程旅游的火车票服务”一样。

5."用完即走"……因为没办法多任务处理，你的产品如果不能在一定时间内完成特定场景的需求并且达成自己的目标，你就比较难做。

6.产品层级不要深，操作路径要短，没法记录你操作到了什么地方，如果用户被打断，第二次进去是没法回到上一次操作的位置的

7.应用号是一个流量孤岛，应用号之间的流量不能流通，自身产生不了什么流量，单在微信生态内来说比较依赖订阅号的文章带来的流量导入

（下面评论基本都是上次的答案的评论）