对比微信小程序和微信服务号
从开发者的角度,做一些对比。
1、
最直观的,小程序比服务号多一些 API,包括选取或拍摄视频、音乐控制、监听陀螺仪和传感器、获取系统和网络信息等等。或者可以定制标题颜色之类。但这都这是细节,并不是关键变量。
2、
服务号调用微信支付(以及提升 API 调用数量)需要认证,需要有公司营业执照,或者政府、组织的证明,也有额外的认证年费,这些都是较高的门槛。
本文要义:从API能力、认证门槛、推送限制到开发依赖,逐条拆解微信小程序与服务号的七项核心差异,帮助开发者判断应选哪种形态。
但是小程序只需要微信审核,这大大降低了服务商(第三方开发者)利用微信支付/API并提供服务的成本,更明确地把资源向个人开发者延伸。在受控的情况下吸纳更广泛的第三方开发者。
顺便一说,和苹果应用商店一样,可能会出现破解微信+微信小程序生态(对于很多仅需要一次性付费的,或者内置解锁的)。
3、
利用 API 更方便快捷。
为了调用用户信息,服务号必须建立自己的 token 维护系统,然后封装微信 API,然后在自己的服务器上建立数据库缓存。当用户登录的时候,有很反复的跳转过程(并且可能导致延迟和出错),从自己的服务器跳转到微信的服务器,再从微信服务器跳回来,然后还需要再次校验登录……
但是在小程序里,只需要先调用 login,然后 getUserInfo 就好了,微信会通过小程序的框架帮你做好一切,这一切发生都发生在微信内部,速度、效率和安全性都很高。
4、
对部分开发资源依赖更低。
当获取到了用户信息,如前所述,服务号必须把用户信息储存在自己的服务器上,一方面避免频繁调用微信API(冒着广域网延迟的风险),另一方面也方便快速调用已经获得的信息。
小程序则不需要,它在微信客户端(也就是手机上)有自己的储存和缓存。所以小程序并不需要 Web 服务器、数据库服务器、缓存服务器……以及相关的设计、开发、测试、部署和维护等等。很多程序,是不需要联网的(比如计算器、游戏,或者仅需要下载内容的新闻阅读器),本地储存和缓存就足够了。
对于某一类的小程序,把服务器、数据库都扔掉,开发效率会高很多,门槛也低很多。这是服务号所做不到的。
所以,小程序对于部分开发资源的依赖程度降低了(文章最后会讨论反过来的一面,对开发资源高的部分)。
4、
推送能力不如服务号。
到目前为止,并不清楚小程序在微信内的暴露出口(可能是我消息不通)。除了在对话和朋友圈里触发分享,在什么场景下可以激活使用?
服务号在微信对话里占据很强力的位置,重新触发下发通知可以重新回到对话顶部(同时也增加被取消关注的几率)。
作为对比,微信开发文档指出,小程序下发的通知会聚合到一个专门的「服务通知」(见下图),这类似于被折叠的「订阅号」。从这个角度来说,小程序的推送能力低于服务号。
5、
服务号有对话框和对话能力,小程序没有。
在服务号里,用户可以在对话框里直接和服务商对话,而服务号可以在24小时内人工或者程序直接回复用户到服务号对话框,这个能力是小程序不具备的。
6、
小程序对模板消息的要求更严格。
模板消息并没有什么不同,一样需要通过审核,而不能自己随便定义,这让人有些失望,因为微信对于模板的审核非常严格。在服务好礼,微信审核团队明确回复:不支持「回复」、「赞」、「留言」等互动类的。
不知道小程序里这部分是否会放宽松(对此我很怀疑)。
小程序里下发模板消息比服务号更为严格。微信明确规定,需要有支付行为,或者特定的表单提交动作,然后才能换取1次7天内的推送权限。
服务号的模板消息推送下发,虽然微信明确要求,条件是:”保证用户不受到骚扰,在开发者出现需要主动提醒、通知用户时”,但技术上似乎并无限制,主要依赖于开发者的自我约束,以契合微信”避免打扰用户”的设计哲学。这方面的监管主要依赖于用户投诉和事后认定,而不是事前约束。
从这个角度来看,小程序对于推送的管控更为严格。
7、
开发。
小程序减轻了对服务器(Web 、数据库、缓存)的依赖,降低了开发成本。然而,对于开发者的资源依赖,小程序的要求变高了。
一个基于服务号的 Web 应用,开发者可以使用 jQuery、Zepto 或者任何他熟悉的 JS 框架。像我这样的初级程序员,还是更喜欢 $(“.img”).show() 这种直观而简洁的语义表达。
在小程序里,程序被抽象了,开发者必须在这个框架内使用原生程序来开发。渲染层、数据层、控制层相对独立,相互影响,不能使用现有的 JS 框架,对于处于传统开发领域的团队来说,这****提升了开发门槛,有利于技术积累比较前沿****的开发团队。
不需要公司、政府、组织机构的认证,就可以发布微信小程序挣钱,这降低了门槛;对开发者本身的技能要求,这个门槛提高了。短期来说,这两者相互扯平,长远来看,这可能是件好事。
至于封闭生态后的影响,已超出本文的讨论范围。
可以对比的地方还有很多,先简单写到这里。