# 换个角度，再来看一下微信小程序的开发与发展

- 作者：爱范儿
- 发布时间：2016-10-20 10:40
- 分类：新创
- 原文：https://www.ifanr.com/734178

![xiaochengxu](https://s3.ifanr.com/wp-content/uploads/2016/10/xiaochengxu-1.png)

> 本文转载于知乎专栏[“小楼昨夜又秋风”](https://zhuanlan.zhihu.com/p/22891188)，作者“七月在夏天”，转载时已获得授权。

前段时间看完了雨果奖中短篇获奖小说《北京折叠》。很有意思的是，张小龙最近也要把应用折叠到微信里，这些应用被他称为：小程序。

含着金钥匙的小程序，还未展现全貌，就已经成了开发界的头条大事儿。有人不以为然、嗤之以鼻，有人奉若神明、投怀送抱。敢于尝鲜的已经开始动手了——不管合不合适，先借这个热度来一波关注是不错的选择：

![v2-8c6ddff7837935a4b40c06911584bb62_b](https://s3.ifanr.com/wp-content/uploads/2016/10/v2-8c6ddff7837935a4b40c06911584bb62_b.png)

所谓 “不登高山, 不知天之高；不临深溪, 不知地之厚”。我生怕看不清小程序这座大山，滚去做了个 demo。放上几张 demo 图，一起感受下小程序的魅力：

![demo1](https://s3.ifanr.com/wp-content/uploads/2016/10/demo1.jpg)

![demo2](https://s3.ifanr.com/wp-content/uploads/2016/10/demo2.jpg)

如果不考虑性能以及各类复杂的动效，小程序的体验已经很接近原生 app 了。

已经有很多的主流媒体对小程序进行了解读，本文将从一些不一样的角度来解读一下小程序的特性。

### 小程序 VS app

我们先举个例子来直观感受下小程序和 app 有什么不同。大家都用过支付宝，在其内部包含着很多小的服务：手机充值、城市服务、生活缴费、信用卡还款、加油服务，吧啦吧啦一大堆服务。这些细小的、功能单一的服务放在支付宝这个超级 app 里，你并不觉得有什么问题，而且用起来也很方便。那如果这些小的应用都单独拿出来，成为一个独立的 app，你每用一个服务都需要从 App Store 里下载安装，而他们其中很多服务，你可能几个月才使用一次，甚至只会使用一次，但却要长时间的占用你的手机空间。这样的模式，可能多数人都不会喜欢。

微信小程序有些类似于上面寄生在支付宝里的各类服务。他们具有业务简单、明确，使用频率较低（你不可能每天都交话费，也不可能天天都交水电费）等特点。这类服务，如果单独做成 app，一是开发成本高，二是用户的手机空间有限，所以把这些小的服务都 “折叠” 进微信中，无需下载安装，用户想用时就搜一下，用完即走。

轻量级、功能单一的服务适合小程序；而业务复杂的应用适合用 app。这里不太认同主流媒体们说的：低频适合小程序，高频适合 app。这个说法太绝对，低频高频不应该成为合适不合适的分界线。微信本来就是超高频应用，很多人一天要打开十几次吧，我在使用微信的时候顺手就使用了小程序服务，这个场景是不是也合情合理？我认为微信的超高频使用次数可以弥补小程序入口较深的缺点（而且入口究竟在哪里官方并没有给出准确的位置）。此外，低频高频是个非常模糊的概念，很难去界定，一天用一次算低频还是高频？支付宝算低频还是高频？

所以，不要被低频和高频限制你的思维，这个真的不是关键。

轻和重是从小程序和 app 的特性上在区分两者的差异，这里我提出一个按产品规模划分小程序和 app 的观点： 绝大多数创业者将在 MVP 阶段，采用小程序方案；而当产品发展到一定的规模，创业者依然会开发自己的 app。

“美味不用等”最初只在微信里向用户提供“排队叫号”服务。你只需扫描一下店家的二维码，就可以去逛街了。这个服务号会在快排到你的时候向你发送一条微信提醒，你不需要守在店里排队。 这样的一个场景放在现在，非常适合使用小程序来开发，它满足业务简单、频率不高的特点（你不可能一日三餐都在餐馆吃饭，又恰恰每次都要排队）。在用户数量达到一定的规模后，美味不用等迅速推出了自己的 app，尝试将用户向自己 app 内转移。 围绕着 “排号” 这个核心功能，美味不用等 app 增加了点评、实景拍照、排行榜、美食专题等一些列附加功能。这样从一个简单的 MVP 产品切入用户某一痛点，成功后旋即推出一系列被 “链接的功能”，这在互联网产品里太常见了。滴滴从在线打出租车切入，发展到专车、快车、拼车、代驾、班车、巴士；罗辑思维从一个每天推送一条语音的自媒体，到在微信里卖书，再到现在推出自己的 app 得到。为什么美味不用等和罗辑思维在微信生态中做的相当成功后还要推出 app？就在微信内部深化产业链不好吗？可能有以下三点原因：

第一，单一的服务在中国极难产生回报，产品需要不断的链接。国内的付费习惯还没有养成，想靠出售服务盈利在目前情况下很困难，尤其是 To C 的产品。大多数产品会依靠一款拳头产品切入市场，在获取用户后，开辟一系列增值业务和附加功能，这才可能有盈利的想象空间。任何一个产品都很难保持克制和不膨胀，这是资本、模式的需要。张小龙一直讲克制，一直和腾讯内部诸多 “势力” 博弈，但微信还是成为了一个超级 app，日渐臃肿。由简单到复杂，由低级到高级，这是商业模式的趋势，也是万物进化的规律。如果你熟悉成熟互联网公司的业务分布是多么的广泛，这个结论就不足为奇。

那么小程序有可能承载这些附加的增值业务，允许开发者逐渐完善自己的产品及商业布局吗？目前看来，可能性比较小，因为这和小程序的初衷是相违背的。即使微信放开政策，可以想象的空间也很小，你只能在微信给你划定的一个小范围内做流量的变现，这远远不及独立出一个 app 所带来的价值。

第二，对于微信生态的不信任感，导致了这种 “逃离”。最近和一个创业者聊天，我问他，小程序来了，你还考虑做 app 吗？他说：做，小程序和 app 都会考虑做。我问他为什么？他说：我总感觉小程序不是我自己的，而 app 会给我一种踏实的感觉，我会觉得我对 app 有绝对的控制权，即使做小程序也只是为了给我的 app 引流。 有这样感觉的人应该不在少数，可能是对 Web App 技术的不信任，可能是对于将应用建立在另一个应用这种模式的不信任，也有可能是对腾讯的不信任。

腾讯对于自己利益保护是毫不手软的，Uber、虾米音乐、微软小冰，都曾被微信封杀过。淘宝就更不用说了，相爱相杀，斗智斗勇，年年都是大戏。孰是孰非，很难界定。这些产品由于只是借助微信的关系链，而并非完全寄生于微信，被封杀也只是少了一个推广途径，没有了微信还有微博等其他媒介。 而完全根植于微信生态的小程序，如果被封杀或是被规则打压，几乎没有退路可走。

那 app 就很可靠吗？目前看来确实比小程序要靠谱很多。主要一点还是生态主宰者的格局 。无论 Google 还是苹果，都是科技界的顶尖公司，这样的公司盈利手段、业务方向、产品级别都要高出普通公司若干个等级，他们关注的是科技趋势和标准发展，很少在消费业务上同创业者竞争。此外，Google 与苹果对于开发者更多的是抱有“合作心态”，我需要你帮我壮大生态，你需要我为你提供平台。这些引领科技方向的公司，更容易给创业者们足够的信心。相反，腾讯投资了很多的 C 端消费领域公司：京东、滴滴、饿了么、人人车、SuperCell、盛大文学、龙珠直播，几乎覆盖了电商、金融、娱乐文化、O2O、在线教育等各个领域，创业者几乎不可能绕开腾讯的利益圈。腾讯既是裁判也间接的是运动员，能否保持一个公正和开放的态度，还需要时间来验证。

第三，生存在 App Store 和微信夹缝中的小程序将承受更多规则压力。在微信内不仅会受到微信的政策压力，还会受到苹果的压力，小程序的政策环境只可能比 App Store 更加苛刻。小程序虽然支持 HTML5 的 Canvas，但据说苹果不允许在小程序里做游戏；每个用户可能最多只能安装 20 个小程序；这些限制是外部规则的第一个压力。毕竟微信是寄托在另一个生态上的 app，本身就会受到约束。 随着小程序生态的演进，这样的内外部压力会逐渐增强，创业者们再次选择 app 也就不是什么稀罕事儿了。

所以，小程序更多的会和原生 app 互补，服务于产品的不同阶段。建议创业者在产品早期用 MVP 思维来构建一个小而美的产品，开发成小程序来试错，利用微信天然的获客能力和传播链条来推广，后期再考虑将流量引到原生 app 中进行流量变现。

虽然有以上诸多不稳定因素，但小程序生态的出现对于整个中国互联网的发展依然是个利好，它给了独立开发者以及初创团队更多的想象空间，以前不敢尝试的 idea 都可以借助小程序这个平台进行试错，我们期待更多小而美的产品在微信中爆发。

### 已存在的众多 app 将如何应对小程序的到来？

按照目前小程序的定位，位于 App Store 榜首的中大型应用，不是小程序的 “那盘菜”。小程序更适合轻量级且功能单一、操作简单的产品。大部分的产品还是会以原生 app 为主。

但我预计，各类应用（阿里系的产品除外）大部分都会推出相应的小程序版本。适合小程序的顺其自然开发一个小程序版本的应用；超大型应用也会想办法将自己的业务拆分出一部分来开发成小程序。原因有以下 3 点：

1. 蹭热点，刷存在。难得的无公害、低成本营销手段，何乐而不为？
2. 多一个流量的入口，微信的关系链还是不容小觑的。
3. 也是最重要的一点：小程序的未来是星光璀璨还是黯淡无光，谁都不能肯定。那么面对不确定的因素，做好防御性的姿态是很重要的。没有比率先在新生态推出自己的产品更好的防御措施。尤其对那些没有技术和数据壁垒的公司，产品很容易被取代，必须做好一些列的防御措施。支付宝、QQ、微信等超级应用都曾以观望的姿态在 WP 平台推出自己的产品，那产品质量和版本更新速度差得简直不忍直视，“察言观色” 的态度不言而明。反正这个平台有我的产品，平台发展的好用户量多我就加大投入，完善版本；有竞争对手的产品出现，我就快速迭代迅速扼杀；如果平台发展的不好，反正也没投入多少，挥一挥手跟微软说拜拜就是了。

### 张小龙说的搜一下即可打开小程序到底是个什么鬼？

张小龙在那段被发烂的微信截图中提到：用户扫一下或者搜一下即可打开小程序。扫一下这个场景很容易想象到，将二维码附加在各类营销活动中，用户扫描或者长按二维码即可打开小程序享受服务。但我更感兴趣的是“搜一搜”这个动作。这个搜一搜的搜索对象是什么？可以利用语义分析、人工智能来分析用户的行为数据（微信掌握着海量的用户数据）并向用户提供精准的服务吗？

用户做搜索时，其本意是去获取他所需要的信息（服务），而非获取 app，他并不关心这个服务来自于哪个 app。现在的原生 app，在信息和服务上加上一层壳，成为一个封闭的孤岛。而用户需要使用服务时，不能直达服务，用户与服务之间隔着一个 “壳”，这也是为什么 app 会让人觉得很 “重” 的原因之一。百度当年的 “框计算”，也是为了解决信息孤岛的问题，直接以服务为搜索对象，即搜即得、即搜即用（这和现在小程序的理念何其相似），从而拔掉应用这层盖在服务之上的壳，解决信息孤岛的问题。

小程序是云端应用，理论上可以消除这样的信息孤岛，直达应用内部。我很期望小程序的搜索是语义化的搜索，搜索的是用户的需求，而不是简单的去搜索的小程序的关键字。那么小程序能实现这样的或者类似这样的理念吗？我们来看看百度 “框计算” 的技术结构：

![v2-3ab1e137723837242ea5d43a8f49d051_b](https://s3.ifanr.com/wp-content/uploads/2016/10/v2-3ab1e137723837242ea5d43a8f49d051_b.jpg)

最难的部分应该是需求识别和精准分析这个框里的技术。目前人工智能及机器学习都还停留在理论阶段，并没有很好的商业化案例，小程序想实现这样的能力，挺难。

那如果不能实现，小程序所谓的 “搜一搜” 依然还是同 App Store 一样在搜索 “应用” 的关键字和热词，那么这和做应用分发又有什么区别？腾讯说不做应用市场的说法很值得商榷，无论如何一个隐形的应用市场依然存在。SEO、ASO 等概念很可能再次出现在小程序的生态圈里。

### 小程序的开发成本真的比原生 app 低吗？

考虑两个方面，开发成本和推广成本。

原生 app 一般要同时开发 iOS 和 Android 两套，而小程序只需要做一套。毫无疑问，这点是小程序最大的优势，从这个角度来看，小程序是“跨平台”的。

具体到开发效率上，很遗憾，在现阶段，开发一套完整逻辑的应用程序，小程序的开发效率是低于 app 的。小程序独立出了一个封闭的生态。我们经常说不要重复的造轮子，可小程序现在是裸奔，你得自己去造轮子。而 iOS 和 Android 经过经年的累积，已有大量的成熟组件可以使用。相反，小程序目前还处于内测阶段，没有任何优秀的第三方组件可以使用。而官方提供的组件，接口非常的少，实现功能没问题，但你想自己去定义组件属性、样式是很困难的（这点真的很奇怪，所有组件没有任何设置样式的接口）。

我们团队做了个简单的对比，开发同样一款简单的天气应用。iOS 拿到 UI 设计稿后，轻车熟路两天搞定，各种交互不需要 UE，都是 iOS 常用动画。web 前端这边，拿着设计稿去找 UI：

> 这个透明的状态栏我没法实现，因为小程序的状态栏必须要有 。  
> 底部的 Tab 栏我只能设置颜色和图片，设计稿里的样式我做不出来。  
> Banner 轮播的指示点我改不了。

UI 一脸懵逼的看着他。

我们在小程序开发中遇到最棘手的 2 个问题：

1\. 缺少统计、绘图组件，以前的 echarts 和 hightcharts 都无法使用，只能用 canvas 去绘制，耗费的时间之多可想而知。我们目前正在着手修改一款基于 canvas 的开源绘图组件，让其支持小程序。

2\. 小程序不支持 WebView，大量已被静态化好的 HTML 页面完全没办法在小程序上展示。如果要支持格式化的文本显示，目前思路有二种：

- 编写工具，用正则表达式解析 HTML，并转化成小程序的标签。这个过程很繁琐，不仅要处理标签还要处理样式。比如 HTML 中的 ul 签，处理起来就很棘手；再比如小程序里的中是不能嵌套的（嵌套后内部的 text 样式无效），而这样的嵌套在 HTML 中太常见了。
- 编写一个针对 WXML 的文本编辑器，用这样的编辑器重新录入和格式化文本（这就是小程序带来的一个挺好的机会）

小程序原生支持 WebView 的可能性很小。如果支持 WebView，那以前用 HTML5 开发的各类 WebApp 又可以在小程序里跑了，iOS——微信——小程序——WebView，这复杂的结构是要逆天的。但有可能微信会开放一个只支持 CSS+HTML 的 WebView，不能运行 JavaScript。

开发者在开发小程序之前一定要预先对这些技术问题做充分的了解，并在设计上、功能规划上尽可能的规避。

现阶段，你想按照你的 UI 设计去开发，困难不小。有人说目前小程序还在内测，未来会有大量的组件出现。会有组件出现我毫不怀疑，但组件的质量怎么样，开发者的热情有多高，能不能形成一个良好的社区氛围，这些都是未知数。中国能够静下心来做开源的开发者，真的挺少。

至于推广成本和用户获取上，很多人都认为小程序会有绝对的优势，它处于微信内部，理应离微信关系链条更近。可微信至今没有给小程序分享的接口，也许以后会给新的接口，也许会将小程序绑定到公众号，借助公众号来传播，也许根本不给小程序提供分享的接口。

谁知道呢？

app 获取用户成本高的一个根本原因是用户手机里的 app 已经饱和了，我们不能拿一个新兴生态的用户获取成本和一个已经饱和的生态做对比。当小程序的生态也饱和的时候，这个成本还低吗？点开你微信里的订阅号，刺目的红色数字有没有亮瞎你的眼？而你又认真去阅读的文章有几篇？大量刷来的用户那不叫用户，想获取一个真实的用户的成本从来都不低。

这里还是建议各位开发者，把精力真正的放在产品上，不要一味的盯着着微信的传播优势和平台优势。小程序由于门槛较低，竞争的激烈程度将远超 iOS 和 Android。Web 发展这么多年, 积累的大量前端人才，极有可能被这波热潮释放。把精力投入在打磨产品上，结合自己产品的特点适度营销，这才是王道。

### 订阅号、服务号、企业号、小程序以后会如何发展？

预测一下，订阅号、小程序会并存；服务号和企业号会慢慢的“死去”。

留存订阅号和小程序是因为他们具备不同的属性：订阅号具有媒体属性，小程序具有服务属性。从目前微信对于小程序在传播、分享上的限制来看，小程序就是做服务，他不具有很强媒体属性，所以这两个不同属性的“号”应该会共存。

而服务号本身就是个怪胎，是微信为平衡用户体验和高级功能的一个中间产物。大多数的微信媒体、商户、创业团队都同时拥有订阅号和服务号 2 个号，用服务号的高级接口做服务，然后将链接附加到订阅号的模板消息或者菜单中推广，怎么样都可以绕开服务号的限制。这样的平衡，对开发者没什么好处，对用户来讲，也不见得有什么体验上的巨大提升。既没有订阅号的每天可以群发一条消息的能力，又不具备小程序接近原生的体验（大多数服务号的体验真是差差差差差，你不绑定微信每次进去就要做身份验证，毫无缓存能力，比如招商银行的服务号，每次进去都要输入十几位的身份证号或者卡号，你烦不烦？），那服务号有什么存在的价值。小程序完全可以融合到订阅号中，何苦搞那么多号。当然，张小龙直接砍掉服务号的可能性不大，这个任务交给开发者去选择，自然淘汰就可以了。

至于企业号，本身价值就在于微信提供了一个便捷的企业员工关系链导入和管理工具，仅此而已。用过企业号的都知道，体验是真的差。本身移动端就只适合做信息的展示，不太适合做信息的录入，而企业号又偏偏有大量的信息录入操作，操作极度困难。既然企业号的价值在于便捷的员工关系链管理，那只需要将员工关系链对小程序开放，并给企业的小程序一个沙箱环境，用小程序取代企业号即可。

相比于小程序带来的机会与红利，我更认同小程序的理念，简单、干净、用完即走。而这恰恰是目前互联网产品形态所缺少的，也是用户急需的。小程序在产品理念上给我们的产品经理上了一课：有时候，少就是多，让用户触手可及，才能让创业者和用户站的更近，更容易传递你的商业价值。