极客时间的专栏读者你好,我是邱岳。从今天开始,我们一起来聊聊与微信小程序相关的话题。
我们的团队算是微信小程序比较早期的实践者,做了一些小程序,有不怎么成功的,也有数据还凑合的,在这个过程中,我也有一些思考和经验,在这里跟大家分享。
微信小程序从两年前推出至今,已经有大量的人才和资本流进来,同时相关的争议一直没断过,每个阶段看好看衰的人都有很多,前几天,我看到还有文章在讨论是不是小程序被高估了。
我觉得,各方观点都应该去听一听,了解一下,但没有必要被这些观点左右了自己的判断。而且小程序的实施成本比 App 低了不少,完全可以自己下水做做看,试一下温度。
说到实施成本,这是小程序带来的最显而易见的收益。过去我们做 App,iOS 和 Android 俩平台、客户端服务端,各种兼容问题,还有版本管理等等一系列的限制。
这里说个题外话,虽然说可以通过一些技术框架去做跨平台的开发,但随着业务复杂度增加,终究还是要去解决各种各样技术上的细节问题。
据我所知,有很多用类似框架的团队在业务发展到一定程度之后,都在谋求回归或部分回归 Native 技术方案。
比如今年六月份 Airbnb 刚刚宣布放弃了 React Native。目前极客时间还在使用 Weex,我感觉随着业务发展和个性化需求的增加,当框架带来的限制开始影响效率时,说不定也会有变化。
我们回到小程序,小程序降低了多终端开发成本,几乎可以忽略 iOS 和 Android 之间的差异,开发效率得以大幅度提高,成本也相对低了一些。当然导致这个行业的门槛也低了不少,这个我们后面再说。
我们可以猜测一个趋势,随着智能手机的普及,这个生态其实趋于饱和,如果你不是做产品设计的,那么估计已经很少会去发现并下载一个新应用了,用户的时间可能会逐渐被几个高频的覆盖基础场景的应用所占据。
最终一些独立的服务提供商是透过这些超级 App 去服务用户,完成这一个服务的过程,或许就是通过类似小程序这样的机制。当然大家也看到了,目前微信、支付宝和头条系,以及百度都开始做小程序。
除此之外,作为大的平台提供方苹果,也一直在跟这些绕开自己的应用市场的超级 App 博弈。
比如从最早从应用号改名小程序,到反复不断的 iOS 支付相关的政策调整,都能看到苹果的警惕,毕竟 App Store 是苹果公司重要的生态环节,大家都不做 App 转去做小程序了,苹果会很不好受。
支付宝、头条系和百度的小程序我没有深入研究,没有发言权,我们的讨论也会集中在微信小程序的生态中。但一定要说清楚的一件事情是,不同的环境中做小程序的思路和逻辑是会有很大差异的。
微信小程序的价值在于藏在其中的关系链,支付宝小程序应该是其中的信用体系和支付管道,头条和百度的小程序很可能会跟分发有关系,这会是不同生态结构的东西。
我看到网上有些表格在对比不同小程序之间的功能差异,支持什么技术特性之类的,我认为这不是最重要的,他们之间的差异一定不是技术特性的差异,而是环境和用户场景的差异。
我们还是回到微信小程序,刚才说微信小程序的价值在于:藏在其中的关系链,这是什么意思呢?就是说微信其实是通过小程序,把它其中人与人之间错综复杂的连接关系开放给了我们。
我们通过这张网迅速触及到了大量我们原来很难触及的人,比如举个极端一点的例子,我们怎样通过一个一线城市的白领迅速触及大量四五线城市的人群?
想象一下,其实北京高级写字楼上班的 David 可能同时还是微信里“家和万事兴”群里的狗剩儿,同时还是“XX 级 2 班青春不散场”群的老五。这就形成了一种奇妙的关系折叠,让一个人身上衍生出不同的关系类型,也可以触达到不同的人群,让我们通过这个渠道把信息传递下去。
当然,这个事情从原理上说,原来用 HTML 5 加上微信提供的 JS-SDK 也可以做,为什么非要用小程序呢?这其实也是小程序刚出现时很多人的疑问,而且如果我们往底层去看,往技术上去看,小程序也是通过 WebView 做的渲染,有什么不同呢?
我的观点是有两个不同,一是体验上不同。 基于 Web 做一些事情,比如做一些系统级的调用会受到限制,而且Web使用上总会感受一个加载刷新的过程,不顺滑,体验比较糟糕。
虽然小程序最终还是用 WebView 在渲染,但我觉得它算是在体验和灵活这件事情上,在 Native 和 WebApp 之间,又取了一个平衡。一定程度上保有WebApp 的跨平台灵活性,另一方面让小程序开发者能够更深度地分享微信的一系列原生能力。
同时小程序还在一定程度上保障了体验的统一,各种元素和控件之类的设计,包括流程和结构,不同的小程序都遵循微信的设计规范,保证了用户在整个小程序体系中的感受一致,不大会出现打开一个 Web 页面,半天不知道点哪里的状况。
第二个不同,我觉得是用户归属的不同。这个东西说起来有点微妙,就是过去我们做 WebApp 的时候,在微信打开一个页面,我们会觉得这个用户进到了我们的产品体系中,所以我们会让他注册登录,然后来使用我们自己的产品。
而在小程序的体系下,感觉用户还是在微信里,我们是给微信提供应用插件的,除了少数小程序之外,大部分小程序可能就简单地要一个授权便可以正常工作了。
其实按理说在 Web 上利用微信的 JS-SDK 去做授权,也是一样的效果,可是这两个差异确实存在,Web 上我们会想方设法引导用户去下 App,或者去关注公众号,好像是在努力把微信体系中的用户抢夺到自己手里。
而小程序中,由于微信做了非常严格的限制,所以大家都不得已变得很淡然,既然抢不走,那就到微信的地盘上好好服务用户,这样导致用户开始使用一个应用的门槛,降低了很多,打开小程序的时候心理负担也小了不少。
比如我打开小程序的卡片,就顺手可以开始使用了,而看到了Web页的时候,我就可能会预期它让我输入用户名和密码开始登陆。在技术上虽然没什么差距,但是在心态和体验上,确实会不一样。
说完 WebApp 和小程序之间的这点差异,我们今天的内容就先到这里,我们从小程序的实施成本开始说起,提到小程序可能成为一些超级 App 与开发者分享用户的方式。提到微信小程序的厉害在于变相向开发者开放了微信的关系链,最后提到了 WebApp 和小程序差异。
接下来我们会展开来分享微信小程序是如何向我们提供关系链,以及我们应当如何利用这一点。虽然这很可能不是微信的本意,但这个特性在当前阶段却被开发者放大了。
你能想象到的,小程序和传统的 WebApp 之间有什么差异呢?欢迎留言讨论,我们下次继续。
评论