每日更新关注:http://weibo.com/hanjunqiang  新浪微博！iOS开发者交流QQ群： 446310206

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

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

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

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

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

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

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

蹭热点，刷存在。难得的无公害、低成本营销手段，何乐而不为？

多一个流量的入口，微信的关系链还是不容小觑的。

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

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

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

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

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

这个透明的状态栏我没法实现，因为小程序的状态栏必须要有 。 

底部的Tab栏我只能设置颜色和图片，设计稿里的样式我做不出来。 

Banner轮播的指示点我改不了。

UI一脸懵逼的看着他。

我们在小程序开发中遇到最棘手的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发展这么多年, 积累的大量前端人才，极有可能被这波热潮释放。把精力投入在打磨产品上，结合自己产品的特点适度营销，这才是王道。

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

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

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

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

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