大家最关注的几个“微信小程序”话题

小程序出来之后，各界存在这些疑问：

• App 和服务号会不会消失；是否会颠覆 App Store；安卓、iOS 工程师要面临下岗？

• 苹果为何不让叫“应用号”；小程序如何盈利；小公司是否能享受到流量红利？

• 什么样的产品适合接入小程序；HTML 5 的小程序体验不如原生 App？

  小程序是否会取代 App：

潘欣：

我不觉得微信应用和 App 之间是非此即彼的二选一关系。对于绝大多数企业来说，必然是两手抓两手都要硬的。资源相对匮乏的初创企业更适合从低成本微信应用号切入会更快速。

很遗憾看到各路评论家一边倒的激动地讴歌微信小程序颠覆 App Store，以及颠覆这颠覆那的，总之颠覆了全世界。我深深的怀疑你们绝大多数人肯定没经营过一个企业，我也深深的怀疑张小龙自己是否有你们一样的“小程序大梦想”。

QQ 也曾经探索过 Widget 类似的模式甚至 QQ 桌面，从结果看不是很成功。相比当年，我肯定更看好微信小程序的前景。但谈颠覆，现在还为时尚早。

  小程序和服务号的关系；是否会给个人开放？

laurence：

服务号是否可以转为应用号？这个不得而知，但我相信肯定有大批的服务号是想转变为应用号的，一些服务号的功能属性远大于媒体属性，例如有硬件设备连接需求的服务号、京东购物的服务号、滴滴出行等服务号，如果让这些服务号主体再去开发小程序未免太折腾，主体下的服务号和小程序之间功能也会有重叠，浪费资源，也占用用户的资源，所以我的猜测是认证的服务号是可以转（升级）为小程序的。在之前订阅号是可以“升级”为服务号的，如果有这个可能，微信可能也会给出是否“升级”的选择；因为从得到的消息来看，微信的态度是订阅号、服务号、企业号、小程序是完全并行的四种形态，所以服务号的继续存在一定还有其服务号的意义，但如何升级不得而知，例如粉丝迁移？

小程序是可以与 APP 打通，但并没有提与服务号的打通，其实与服务号的打通是完全没有问题的，但微信并没有提这一点，猜测服务号是可以升级小程序的。但不支持小程序与 App 的直接跳转。（能做的都在小程序内做就好了，搞那么多跳转没有意义）

小程序是否开放给个人？

在全面开放申请之后，主体类型包括个人、企业、政府、媒体或其他组织，这一点很有意思，小程序是有个人主体类型的，我们知道订阅号是可以申请个人主体的，但服务号不可以为个人主体的，对此我有很多的疑问，小程序是有微信支付能力的，而小程序可以面向个人开放？税务问题呢？对于个人来言的可信度整体来说一定要小于企业的可信度的，或者小程序的开放也是对不同组织有区别对待？例如个人开发者是没有微信支付功能的，不然收款到哪里？个人账户？服务号的微信支付都是关联企业对公账户的，微信不会给你提供逃税的能力。

 “应用号”无法通过的原因

张骁懿：

据悉，应用号的入口是在发现 tab 购物游戏下面，之所以叫小程序是因为 App Store 审核不通过应用号三个字，并且已经和苹果约法三章应用号不能做游戏产品，以及，一个用户只能添加 20 个。

作为一个只写 Script 语言的人我是很支持腾讯干掉 PhoneGap/Cordova/Ionic。不过我就想问一件事，苹果能允许么？

小程序安装或者升级的话要不要苹果再审核一遍？这就跟用 ReactJS Live Update 一样，属于苹果的灰色地带，一个普通 App 这么做可以睁一只眼闭一只眼，有潜力做成 OS 的话苹果能答应么？

Apple’s guidelines explicitly permit you to push executable code directly to your app, bypassing the App Store, under these two conditions:

The code is run by Apple’s built-in WebKit framework or JavascriptCore.

The code does not provide, unlock or enable additional features or functionality.

安装一个 App 就相当于微信不用苹果审核就*增加*一项功能，这比加个 Patch 快速修复一个 Bug 可*过份*多了。
鉴于微信在苹果发布会上出现的频率，微信团队很可能跟苹果沟通过了，所以像 360 那样被下架的可能性比较小，不过如果别的厂子看见了也蠢蠢欲动，那可是动摇了 App Store 的根基啊【反 X 亡 A，不反 X 亡 B 的感觉】

  关于小程序商业化

laurence：

小程序是否会对开发者收费？对比 iOS 开发者，iOS 开发者是收费的，两者都是需要经过审核的，虽然现在没有任何关于小程序是否面相开发者收费的消息，但这并不是不可能，服务号、订阅号的认证是收费的，认证之后获得了未认证所没有的能力，比如微信支付；我猜测小程序是会有收费的通道，类似认证费一样（但可能不会叫认证费），然后获得未认证所没有的能力，或者叫其他名字的费用，按年收取。

潘欣：

各路安卓应用市场已经被商业化玩烂了，App Store 也开始了广告的探索。未来，微信小程序会不会也如此商业化呢？估计会的，但相信不会如安卓市场那样的泛滥。

  小程序红利先到谁手上？

三节课：

大家最期待的，是微信的关系链，而关系链本身，则是微信的命根子，这次的小程序关系链会开放吗？

首先，关系链并非不可以开放，是有条件的开放。下图可以看到，这大致就属于微信的三个开放逻辑。

只开放公开信息：昵称、头像，其实也就是登陆 ID，所有的开发者都可以接入，比如航旅纵横。

有条件开放：开放共同使用的好友。比如大众点评。所以基于大众点评，你可以看到有好友去哪。比如美团外卖，可以看到好友头条，比如 58 同城旗下的转转，能看到好友在卖，但很抱歉，这个关系链的开放，目前只有腾讯投资的公司，才能享受如此特权。

更大程度的开放：除了登陆和好友关系，还开放了朋友圈权限，能把一些操作直接输送到朋友圈做动作，这个很抱歉，只有腾讯自由的产品才有，比如，QQ 音乐、腾讯视频等。

大概的逻辑是：

• 亲儿子，能得到全部关系。

• 干儿子，能得到重合的关系，你用，我也用，相互能看到，我用你不用，我不能跟你发生联系。

• 外人，只能刷个脸，其他的免谈。

所以，大家先别激动的太早，小程序目前的开放程度还是很低的，离 Facebook 的全能力开放还是有差距的。

潘欣：

微信小程序一定还是有红利期的，我做出这样的预测：

• 第一波红利的获得者是昨天和今天写评论文章的微信订阅号上的自媒体们；

• 第二波红利的获得者是干微信小程序培训的“老师”们，他们应该大多数是从微信营销培训迅速转型过来的；

• 第三波红利的获得者应该是那些获得内测邀请资格的人们，毕竟上架时间早啊。

再往后，就难说。任何好东西拼得都是执行力。

当然，好东西永远是稀缺的。我不相信你开发一个 App 是垃圾，现在开发一个微信小程序就不是垃圾了。 App Store 和微信平台都只是一个载体，你的产品是不是用户需要的，是不是用户喜欢的才是核心。以微信小程序远低于 App 的开发成本，可以想象未来提交审核的小垃圾程序是多如牛毛的，衷心希望微信能有比 App Store 更加严格的审核程序，否则，微信用户真的要遭殃了。

  什么类型的产品适合接入小程序

李明骏：

这就和 Native App 时期有了一定的区别，小程序更欢迎的是服务性 App，也就是张小龙所说的用完即时走。微信要做的是一个长尾市场，聚合那些无法承担成本去独立做成 App 的服务。就像当年的亚马逊一样，几乎没有什么商品你在亚马逊上找不到一样。而现在微信就相当于是把商品变成了服务这种非标的东西。

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

小而美的服务是什么？低频、非刚需基于场景的服务，在特定场景下（也就是够垂直）可以较好得解决用户需求。许多付费的服务可能借力因此焕发出第二春，教育、医疗、家政、求职招聘、二手买卖、旅游、票务、金融理财、汽车后市场等等。

三节课：

不是所有的服务都适用小程序，但大部分的服务和几乎所有的初创业务都是可以接入小程序的。

哪些服务是可以接入，哪些又是不可以接入的呢？我先看一个模型。按照重要/不重要，高频/低频，我们将互联网产品分别放入四个象限。

然后，我们分别看这 4 个象限的拥抱策略，应该说，如果你的服务是很高频的，而且对于交互和界面体验的要求很高的话，还是要用原生（Native）来做。但如果你是低频/中频且重要的服务的话，你应该毫不犹豫地加入微信小程序的申请队伍。

象限 1：大玩家、高频应用不应该接入和拥抱小程序。如，3BA（360、百度、阿里巴巴）。

因为用户经常打开，而且交互频次很高，对应用的体验要求很高，比如直播、游戏、视频等。对数据安全度比较高的不应该接入。虽然微信只是读取了接口，不会直接让服务者提交数据，但因为小程序一定会提供缓存功能，开发者的服务虽然基于 H5，但你是跑在微信这个原型框架内的。

象限 2：应该毫不犹豫拥抱小程序。

这个象限包含了大量的服务类产品。教育、医疗、家政、求职招聘、二手买卖、旅游、票务、金融理财、汽车后市场.

总之，但凡用户一年用个一两次之后就再也想不起来的，是不应该用一个原生引用的方式让用户下载，而应该是通过微信小程序来解决。初创型企业也应该通过小程序来试探 MVP 产品，因为微信拥有天然的传播能力和获客能力，而原生应用除了开发比较复杂外，推广成本极高，获客成本极高，这些都阻碍了 MVP 的产品探索。

从这个角度来说，小程序能让中国初创的互联网公司减少试错成本，提升成功概率。

象限 3：慎重接入，利用微信的开放能力，引入用户到自有产品中。

MVP 后，尽快引导到自由产品，因为自有产品能提供更好的服务，并且能留下用户，比如知乎、网易云音乐。内容型的产品，通过微信获得新用户，然后转移到自有平台，也是一个很好的策略。

象限 4：视情况接入，主要看开发能力。

基本上很多都是个人兴趣产品、工具产品，可以从 MVP 的角度来做，或者以兴趣的角度来做，不考虑太多的商业产出，只考虑情怀，但这些开发者有个明显的问题，就是产品设计能力和开发能力有限，所以，如果你的人是做 APP 的，那就还是 APP 吧，如果是 H5 的，那就微信小程序呗。

  小程序 与 Native App 的优劣之争

yseternal：

HTML 5、JS 以及相关技术替代原生大家喊了很久了，就是大热的 React Native 目前看来也依然很不完善。微信的应用应该都是运行在腾讯浏览器的X5内核里，这东西怎么样大家心里也都有数。我感觉还是只能做一些低交互的应用，大概也就是比网页快捷方式高一级别，要利用 OS 的炫酷特性，原生还是跑不掉，而且目前原生开发很成熟了，框架库很多，门槛也很低。

三节课：

小程序不同于服务号，服务号的功能需要全部在 Web APP 中提供，而小程序是微信中的 Native 程序，是有缓存能力的，C 端用户订阅（暂且这样说）某小程序后，当有缓存的时候不仅会提高用户体验，同时也加快了程序加载速度，用户在网速不佳的时候的等待时间将大大减少。

小程序是基于 H5 开发的程序，但用了类似于 JS-SDK 的框架（百度以前是clouda框架），提供了更多的接口和组件，让程序更加流畅，体验接近Native App。能够云端发布程序（当然也需要微信审核），同时也能缓存数据，实现了借助微信这个最大的 Native App 来让 H5 App 更强大的目的。

以上是大家最关注的几个“微信小程序”话题的详细内容。更多信息请关注PHP中文网其他相关文章！