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

摘要：当小程序的生态也饱和的时候，这个成本还低吗点开你微信里的订阅号，刺目的红色数字有没有亮瞎你的眼而你又认真去阅读的文章有几篇大量刷来的用户那不叫用户，想获取一个真实的用户的成本从来都不低。

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

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

具体到开发效率上，很遗憾，在现阶段，开发一套完整逻辑的应用程序，小程序的开发效率是低于APP的。小程序独立出了一个封闭的生态。

我们经常说不要重复的造轮子，可小程序现在是裸奔，你得自己去造轮子。而iOS和Android经过经年的累积，已有大量的成熟组件可以使用。

相反，小程序目前还处于内测阶段，没有任何优秀的第三方组件可以使用。而官方提供的组件，接口非常的少，实现功能没问题，但你想自己去定义组件属性、样式是很困难的（这点真的很奇怪，所有组件没有任何设置样式的接口）。

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

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

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

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

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

编写工具，用正则表达式解析HTML，并转化成小程序的标签。这个过程很繁琐，不仅要处理标签还要处理样式。比如html中的 ul 签，处理起来就很棘手；再比如小程序里的中是不能嵌套的（嵌套后内部的text样式无效），而这样的嵌套在html中太常见了。

编写一个针对wxml的文本编辑器，用这样的编辑器重新录入和格式化文本（这就是小程序带来的一个挺好的机会）

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

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

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

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

谁知道呢？

APP获取用户成本高的一个根本原因是用户手机里的APP已经饱和了，我们不能拿一个新兴生态的用户获取成本和一个已经饱和的生态做对比。

当小程序的生态也饱和的时候，这个成本还低吗？点开你微信里的订阅号，刺目的红色数字有没有亮瞎你的眼？而你又认真去阅读的文章有几篇？大量刷来的用户那不叫用户，想获取一个真实的用户的成本从来都不低。

这里还是建议各位开发者，把精力真正的放在产品上，不要一味的盯着着微信的传播优势和平台优势。小程序由于门槛较低，竞争的激烈程度将远超iOS和Android。

Web发展这么多年, 积累的大量前端人才，极有可能被这波热潮释放。把精力投入在打磨产品上，结合自己产品的特点适度营销，这才是王道。

「H5程序俱乐部」是一个专注微信小程序学习交流的微信公众号
每天发布微信小程序设计/开发/运维知识，小程序最新资讯
H5程序俱乐部微信号：wxappclub