小程序技术演进史
2020-01-13
145

1. 中国特色的移动互联网时代

伴随着QQ小程序面向用户开放,这个手机端月活7 亿的巨无霸正式入场。小程序,终于成为了超级app的标配。

盘点下已经支持小程序的超级app:

微信、企业微信、QQ、支付宝、高德地图、手机淘宝、百度、百度贴吧、百度地图、今日头条、抖音……

这些璀璨耀眼的名字,背后都是巨大的流量。

在这群超级app的支持下,中国的移动互联网格局被彻底改变。

这个有中国特色的移动互联网时代,被称为「小程序时代」。

这是继手机支付后,中国的移动互联网领先世界的第二个代表事物。

中国的技术标准、开发者生态,第一次得到大规模的普及应用,而且很明显,小程序在功能和体验上均超过了HTML5。

中国人能建立开发者生态吗?这个命题曾一度让人怀疑。

小程序完成了这一步突破,这是一场值得歌颂的中国技术生态发展史。

让我们来回顾下这场技术生态革命,是如何开始,又将要去向何方。

2. 罗马不是一天建成的,小程序不是一天发明出来的

HTML5于 2007年在W3C立项,与iPhone发布同年。

乔布斯曾期待HTML5能帮助iPhone打造起应用生态系统。

但HTML5的发展速度并不如预期,它虽然成功地实现了打破IE+Flash垄断局面的目标,却没有达到承载优秀的移动互联网体验的地步。

于是在iPhone站稳脚跟后,发布了自己的app Store,开启了移动互联网的原生应用时代。

随后的Android,本来是基于Linux的 OS,与之同期的MeeGo等竞争对手采用C +HTML5的双模应用生态策略,然而C 的开发难度太大,HTML5体验又不行。Android依靠Java技术生态,在竞争中脱颖而出。

于是在移动互联网初期,应用生态被定了基调——原生开发。

在那个时候,硬件不行,也没有其他办法,原生开发才能在低配硬件上带来商用体验。

但大家都在怀念HTML,那种无需安装更新、即点即用,直达二级页面的特点,一直让人迷恋。

国内有一批做浏览器的厂商,尝试去改进HTML5,他们提出了轻应用的概念。

通过给WebView扩展原生能力,补充JS API,让HTML5应用可以实现更多功能。

不过这类业务没有取得成功,HTML5的问题不止是功能不足,性能体验是它更严重的问题,而体验问题,不是简单地扩展JS能力能搞定的。

这类业务发展的顶峰,是微信的JS SDK。

作为国内事实上最大的手机浏览器,微信为它的浏览器内核扩充了大量JS API,让开发者可以用JS调用微信支付、扫码等众多HTML5做不到的功能。

▲ 微信JS SDK说明文档

但微信团队对这套方案的体验仍然不满意,微信钱包栏目里打车、理财等很多应用虽然嵌入了JS SDK,但每次点击要等半天白屏,让人用着很痛苦,他们在业内开始寻找新的解决方案。

业内早有专业团队看到了相同的问题。

与浏览器不同,Hybrid应用是另一个细分领域。它们为开发者提供使用JS编写跨平台应用的工具,为了让JS应用更接近原生应用的功能体验,这个行业的从业者做出了很多尝试。

笔者所在的DCloud即是其中之一,我们提出了改进HTML5的「性工能」障碍的解决方案 —— 通过工具、引擎优化、开发模式调整,让开发者可以通过JS写出更接近原生app体验的应用。

多WebView模式,原生接管转场动画、下拉刷新、Tab分页,预载WebView……各种优化技术不停迭代,终于让Hybrid应用取得了性能体验的突破。

Hybrid应用和普通的轻应用相比,还有一个巨大的差别:一个是Client/Server,一个是Browser/Server。简单来说,Hybrid应用是JS编写的需要安装的app,而轻应用是在线网页。

C/S的应用在每次页面加载时,仅需要联网获取JSON数据;而B/S应用除了JSON数据外,还需要每次从服务器加载页面DOM、样式、逻辑代码,所以B/S应用的页面加载很慢,体验很差。

可是这样的C/S应用虽然体验好,却失去了HTML5的动态性,仍然需要安装、更新,无法即点即用、直达二级页面。

那么C/S应用的动态性是否可以解决呢?对此,我们提出了流应用概念,把之前Hybrid应用里的运行于客户端的JS代码,先打包发布到服务器,制定流式加载协议,手机端引擎动态下载这些JS代码到本地,并且为了第一次加载速度更快,实现了应用的边下载边运行。

就像流媒体的边下边播一样,应用也可以实现边用边下。

在这套方案的保障下,终于解决了之前的各种难题:让JS应用功能体验达到原生,并且可即点即用、可直达二级页面。

如今看来,这已经变成了常识。但在当年,先驱们做了无数艰辛探索。

这套技术,需要让客户端引擎提前预置在手机上,就像流媒体的普及,建立在Flash的装机量巨大的基础上,那么普及这个客户端引擎就变得很重要。

2015年,360和 DCloud合作,在360手机助手里内嵌了这个客户端引擎,推出了业内第一个商用的小程序,360称之为360微应用。

微应用实现了在360手机助手的应用下载页面,同时出现了「秒开」按钮,点击后直接使用。

并且在360手机助手的扫码里,应用的分享里,都实现了扫码获得一个应用,点击分享消息获得一个应用。

为了做大生态,DCloud把这套技术标准,捐献给了HTML5中国产业联盟,随后,联盟开始推动更多的超级app和手机厂商加入,共同推进动态app产业的发展。

然而事情并不顺利,巨头们有自己的利益诉求。虽然有一批厂商同意加入联盟共建生态,但最关键的角色,真正的国民应用「微信」,最终决定自立标准、自研引擎,当然技术原理与流应用是基本一致的。

2016年 1月 11日,微信公开课,张小龙罕见露面,公布了微信应用号的计划,为这个大事件亲自站台。

2016年 9月 21日,微信宣布更名应用号为小程序,面向首批开发者内测。从此,这个词被正式定了下来,「小程序」,成为后续一个时代的代名词。而「流应用」、「微应用」则淹没在历史长河中成为一个令人唏嘘的故事。

2017年 1月 9日,微信公开课,小程序面向用户正式推出。

从此后,阿里巴巴、手机厂商联盟、百度、今日头条,陆续推出了自己的小程序平台,其中也有很多波折与故事,在有偶然、有必然的过程中,形成了今天的局面。

小程序大潮卷入了更多人,并形成了更大的浪潮,最终迎来了不可逆转的小程序时代。

3. 生态难,难于上青天

发明能解决功能体验和动态性的技术方案,虽然难,但不是最难的事情。

最难的是开发者生态的建设。

最初HTML5中国产业联盟的策略是在HTML5上扩展强化,复用现有的HTML5生态。

当微信的标准完全自立重建时,业内人士都悬着一颗心。

在全球,基于Web的技术生态已经非常成熟,各种开发工具、框架、组件、模板...提升着开发者的效率。

小程序丢弃了国际标准组织W3C的 DOM和 Window标准,仅仅采用基础JavaScript。这意味着HTML5生态的各种轮子无法复用,要完全重造一个新的小程序开发生态。

当初微信推广JS SDK时,是那么地顺其自然,开发者纷纷开始使用,因为对于开发者,只是在他们的H5版本上补充一些API而已。

而小程序初期,充满了开发者的质疑声:我的业务迭代那么久,让我重新做一个版本,你的生态到底能不能支撑我的投入?

微信用持续而快速的版本升级、高管的站台,告诉大家微信做小程序的决心,并最终通过2017年底的跳一跳,引爆了小程序。

从此大家的问题不再是我要不要做小程序了,而转向了:既然要做,怎么才能提升小程序的开发效率、降低开发成本?

任何一种技术,或者开发模式的演进,在不断成熟的过程中,都遵循着类似的成熟规律:

技术标准 -> 基础平台 -> 开发工具 -> 培训市场 -> 框架诞生 -> 周边生态逐步完善 -> 轮子之上的轮子

在HTML5生态里,已经发展到最终极的形态,比如Vue是一个重要框架,而基于Vue的各种丰富的UI库、测试框架,则是轮子之上的轮子。

多层轮子代表着生态的繁荣,也意味着开发者的开发效率更高。

可微信的全新标准出现时,它把开发者推回了原始社会,一切都要重来。

这在当时看来,并不是一个必然会成功的事情(其实直到现在,比如图表类轮子,小程序仍然比不过HTML5)。

时至今日,讨论这个标准的选择对错已经没有意义。当支付宝、百度、今日头条都开始参考这个标准做小程序时,时代已经不可阻挡。

所幸,最终的结果是,中国人做成了。在国际标准之外,在中国,终于建立起了自己的技术生态。

并且这个生态,给用户带来了更好的体验,给开发者带来了更多流量和变现效率的提升,这是一个比HTML5更优秀的生态。

4. 野蛮的技术生态成长速度

两年时间,中国的小程序开发者如何从原始社会进阶到现代文明?这也是一段有趣的历史。

我们来看看小程序技术生态是如何快速成长,走完上面所说的这套技术成熟路线,也就是从技术标准到轮子之上的轮子的。

在Web世界里,已经成熟到了原生JS用量很少的时代了,开发人员大量使用Vue等框架,并且在Vue的基础之上,又有更多轮子。

当中国的开发人员面临重头开始时,他们感受到效率对比的差距,既然时代已不可阻挡,那就拥抱它。勤劳的中国技术人开始蓬勃地建设起了小程序各种周边技术生态。

其中比较重要的是开发框架的迭代,我们看看每个小程序开发框架为什么会诞生、流行和衰落。

最初的微信小程序,一片荒蛮,一份文档 + 一个难用的IDE,很多效率工具比如npm、预处理器这些都不支持,而这些已经是大型项目离不开的工具。

于是,第一个标志性的框架出现了 ——WePY。

WePY紧随微信小程序在2017年发布,原本是腾讯其他部门的一个个人工程师的作品。在那个年代,WePY有效地解决了小程序不支持npm、预处理器的痛点,被引爆后,腾讯官方才把这个框架收编到官方的GitHub下。

不过WePY也面临很多问题,它使用了私有语法,这让它在生态建设上面临很大难度,IDE着色、语法提示、语法校验、格式化、人员招聘培训等各方面问题制约着它的流行和普及。

面对这些问题,人们开始思考,有什么更好的方式,可以复用现有技术生态来快速完善小程序生态?

这时候下一个重要框架借势诞生,美团前端在2018年初开源了MPVue。

MPVue采用Vue语法来开发小程序,通过对Vue.js的底层改造,实现了编译到微信小程序。

MPVue良好地借助了Vue的技术生态,周边工具如IDE、校验器、格式化等支持直接复用、人员招聘培训等生态建设压力大幅下降,受到了大量开发者的欢迎。

看着熟悉Vue的开发者终于有了趁手的轮子,那熟悉React的开发者怎会无动于衷?

京东团队是React的重度用户,还自研了JDreact,于是他们开发了Taro框架,一款基于React语法编写小程序的框架。

但Taro并不是想简单做一个MPVue在 React世界里的翻版,Taro相比MPVue,想要解决更多重要问题。

Taro面世较晚,此时微信、支付宝、百度、头条都已发布或宣传了自己的小程序,开发者面临一个多端开发和适配的问题。

于是Taro率先支持多端开发,它甚至还能发布到H5和 app。

当时小程序领域还有一个重要变化,微信开始支持小程序自定义组件。

组件是一个成熟框架不可缺的东西,不管是Vue还是React都有丰富的组件生态。

在过去,MPVue时代,是把Vue组件也编译成页面模板,这带来一个很大的性能问题,在复杂页面里(比如长列表)使用组件,更新组件状态会导致整个页面的数据全部从JS逻辑层向视图层通讯一次,大量数据通讯会非常卡顿。

注意:小程序的逻辑层运行在V8或 JSCore下,和视图层是分离的,通讯阻塞很容易引发性能问题。

于是Taro把 React组件编译为新出的微信小程序自定义组件,这种组件在数据更新时,只会更新组件内部的数据,而不是整个页面更新数据,从而大幅减少了数据通信量。

这一轮的后浪推前浪很猛,Taro在性能和多端支持上,都超越了MPVue。

看着React阵营取得如此成绩,Vue阵营自然会继续追击。

我们基于Vue开发了uni-app,它实现了自定义组件编译模式,并在算法上做了很多优化。另外,之前MPVue对 Vue的语法支持度不太完善,比如过滤器等不支持,在uni-app中我们进行了解决。

同样,uni-app也看到了前浪的其他问题:Taro虽然迈出了多端的第一步,但多端支持能力比较弱,每个平台仍然各自开发大量代码。核心原因,是Taro在 H5端和app端,并不是一个完整的小程序技术架构,无法保持最大程度的统一。

于是uni-app在 app端,使用了一个技术架构相同的小程序引擎,本身就可以直接运行小程序应用,这个引擎搭配小程序代码打包为app,开发者一行代码不用改,可以同时发布小程序和app。

当然,其app引擎从Hybrid应用起家,它提供的API要比小程序多很多,因为app的需求会比小程序丰富,它还支持把WebView渲染引擎替换为Weex渲染引擎。

之后uni-app又发布了H5版的小程序引擎,原理与小程序的PC模拟器相同,实现了良好的跨H5版的发布。于是uni-app比较完美地实现了开发一次,7个平台发布。

第一层轮子就这样迅速发展了起来,Web世界里最成熟的Vue、React技术生态被导入了小程序开发生态中。然后轮子之上的轮子开始如火如荼的建设。

以UI库为例,之前的UI库,有Vue库、React库,有PC库、H5库和小程序库,种类繁多,甚至说混乱。

比如在Vue阵营中,Vant和 iView这两个UI库,都是同时维护两个版本,它们即有H5版,又有小程序版。

不止框架作者麻烦,开发者想在多端使用这些UI库时,会发现在不同端还需要引入不同的UI库,写法都不一样,这让开发者很崩溃。

既然已经可以多端开发应用,于是在多端开发的领域里,开始出现轮子之上的轮子,多端UI库。

首先是Taro推出了Taro UI,实现了H5和小程序UI库的统一,不过可惜Taro UI不支持app端。

然后uni-app推出了uni UI,这个UI库同时支持多家小程序、H5、app。

由于uni-app和 MPVue同属Vue阵营,它们的组件是互通的。于是这两家联合举办了一场插件大赛,建立了插件市场。

在中国的前端开发者领域,有很多和国外不一样的地方:一个是国内有小程序,第二个是国内Vue的开发者体量远超过React和 Angular。这里面很大的原因,是Vue.js的作者尤雨溪,是中国人。

在庞大的Vue用户体量支持下,uni-app和 MPVue的周边生态迅速发展起来,开发工具、周边轮子、教育培训等生态快速完善。目前在Vue阵营下,开发者在Web生态下所需的轮子,在多端开发下基本也都有了。

短短两年时间,小程序开发生态里几拨迭代,轮子之上的轮子不断涌现,快速进入了成熟期。

5. 结语

产业还在继续发展,每当底层有重大技术变更时,上层框架世界就会发生新机会。

当年HTML5标准不统一,浏览器兼容性问题严重,诞生了jQurey的机会。而在移动互联网下半场,浏览器兼容已经不再是核心问题,jQurey的地位被更适合移动互联网的Vue替代。

我们不知道未来还会有什么新的框架出世,但我们知道方向:

对于开发者而言,总是会向着更高的开发效率、更高的性能、更高的投入产出比前进。

对于开发商,目前的小程序,虽然发展了2 年,但流量增长空间仍然巨大,微信之外,很多超级app的势能将逐渐释放,整个小程序产业的日活总量有数亿的提升空间。

如果开发商能追上这拨红利,就能获得更多增长。而多端框架的出现,可以帮助开发商更好的把握这拨红利。

30 +
专业成员
50 +
覆盖城市
300 +
全球客户
1000 +
完成项目
选择联系我们
小草互联,您值得信赖的合作伙伴!
联系我们