快应用与小程序
快应用与小程序
tags
小程序
快应用
看法
date
Jul 14, 2020
source
status

不论是快应用,还是微信小程序、QQ 小程序、支付宝小程序、百度小程序等等,都属于小程序类别。
2018 年 3 月,九大第三方 Android 手机厂商在北京联合推出了「快应用」标准。在 2020 年的今天,我们或多或少都在这些厂商的手机上直接或间接的使用过快应用。2020 年 6 月,苹果宣布 iOS 14 也推出自家原生快应用。

新时代下的移动端软件

1995 年之前的程序员都在使用 C、C++、Pascal 这些面向过程、半面向对象语言,他们编程时需要花费大量的精力去做很多重复性劳动,而且一旦项目架构复杂起来,面向过程的弊端都会显现:架构耦合严重。
1995 年 5 月,Java 面向对象编程语言诞生了,Java 语言在设计上就去其糟粕取其精华,吸收了 C++ 语言的各种优点,摒弃了 C/C++ 里不利于理解的多继承、指针等概念。在随后十多年来,智能手机兴起,手机应用的开发语言基本都是那个强大易用的 Java。
2007 年 1 月,iOS 带着它超前的设计面世,从此世界上只剩下两大手机系统阵营竞争:Android、iOS。而在 2015 年往后的日子里,开发者们意识到如果用 JavaScript 来开发应用,这样前端的技术栈都能够统一,还能节约开发成本,由 React Native 引领的跨平台框架逐渐浮现。随着 4G 的普及、短视频、快节奏的生活,安装应用这个动作变得极为昂贵,智能手机的生态好像陷入了一个怪圈,既要让开发者开发新的应用来维持生态运转,但用户又不肯去安装应用,50% 的用户平均一个月安装的新应用还不到一个。

微信小程序打破泥潭

「我就只用个 XX 功能,为什么还要下载安装整个应用?」
在微信小程序面世之前,人们都会碰到这个问题,而没有解决这个问题的办法。在微信小程序面世之后,这些问题都迎刃而解。
2016 年 9 月微信小程序开始内测,2017 年 1 月微信小程序正式发布,一经面世就掀起了国内移动开发的浪潮,诸多企业开始支持微信小程序、诸多学校开始开设微信小程序课程,同年微信小程序直接带动就业 104 万人,社会效应不断攀升。腾讯用它10亿的活跃用户的微信作为平台,开启了自己的生态圈。从此查询、打车、订票、外卖这些单一功能不再需要下载安装对应的应用,而是在微信里搜索出来后即可打开,体现了“用完即走”的理念。移动手机用户的使用体验直线上升,进而刺激了消费。
微信小程序,使用 JavaScript 编程语言、自定义类 Vue 语法、HTML 与 CSS 这些前端网页老技术,搭配 V8 渲染引擎,完成了平台统一的壮举,当然也仅仅局限于微信上。随后支付宝、百度等互联网企业也开始利用自家应用的用户数优势,开始推出自家的小程序来试图抢占市场份额。

快应用与微信小程序的博弈

2018 年 3 月九大手机厂商(华为、小米、OPPO、vivo、中兴、金立、联想、魅族、努比亚)联合在北京推出了「快应用」标准。随后快应用服务框架开始集成进各手机厂商的手机系统中,可以在操作系统层面实现用户需求与应用服务间的无缝连接,提升用户的使用体验和应用服务的转化效率,同时支持生成桌面图标等留存能力。
快应用也是使用的前端技术栈开发、V8 引擎渲染、也同时具备 H5 页面和原生应用的部分优点。逐步在手机系统中的负一屏、信息流等开始应用,随后为一些互联网大厂软件提供了入口,如淘宝、菜鸟驿站、美团、饿了么等,当用户点击到相关的网页链接时,会跳转开启对应的快应用,这是手机系统层面上的手段,是微信小程序做不到的,快应用对于手机用户拥有更强的控制能力。不想使用微信小程序可以不点击开启,或者不使用微信即可,但是快应用早已存在于国产第三方厂商深度定制的 Android 系统中,你没有不使用的权利

小程序应用与原生应用的抨击

当小程序们在猛烈发展的时候,原生开发们又在干什么呢?
Google 与著名开发软件生产商 JetBrains 联合推出了 Kotlin 语言,简化自身 SDK 架构,升级为 AndroidX,发布 Jetpack 组件,大大提升了 Android 开发效率和架构性能。苹果推出 Swift 语言联合 Object-C 语言共同用于 iOS、iPadOS、macOS 的开发,一套代码全平台发布。
在跨平台方面有 FaceBook 推出的使用 JavaScript、HTML 语法、CSS 语法、基于 V8 引擎渲染的 React Native 框架。还有 Google 推出的使用 Dart 语言,Skia 引擎渲染的 Flutter 框架。
那么小程序、原生应用、跨平台应用究竟是个什么定位?什么样的应用该用小程序开发?什么样的应用该用原生开发?
快应用
微信小程序
跨平台应用(RN、Flutter)
原生应用(Android、iOS)
JavaScript、TypeScript+类HTML、CSS
JavaScript、TypeScript+类HTML、CSS
RN:JavaScript、TypeScript+类HTML、CSS。Flutter:Dart
Android:Java、Kotlin。iOS:Object-C、Swift
运行于国内手机厂商的第三方Android深度定制系统
运行于Android、iOS、iPadOS三个版本的微信APP应用
运行于iOS、Android系统
运行于iOS、Android系统
较高
较高
极高
一般
较多
较多
所有
一般
繁荣
较繁荣
繁荣
通过各项指标的对比,可以发现它们的定位:
  • 微信小程序拥有 10 亿以上的用户量,腾讯利用微信这个软件的平台去吃掉系统这个硬件的平台开发市场,维持微信自身的生态,并且利用自家的 X5 浏览器内核,保证 Android 与 iOS 上的渲染效果基本一致,有跨平台的特性,只不过是软件层面上的。经过一次 JavaScript 转译,再经过一次 X5 内核渲染,性能两度折损。并且受限于微信 APP,如果微信 APP 开发不当,会导致所搭载的小程序性能再次折损。高度隔离,所有功能均通过微信 APP 发出,如果用户不给予微信 APP 相关权限,那么所有微信小程序将无法正常使用。拥有较多腾讯云服务,如:定位、推送等。
  • 快应用框架搭载于国内第三方深度定制 Android 系统上,可以说国内有多少用户使用 Android 手机,那么它就可以拥有多少市场。采用 V8 引擎 + 原生渲染,性能较优于微信小程序,具体看各手机系统厂商的针对优化,可能个别系统性能有偏差。在个别系统上拥有系统自家云服务支持,如:华为、小米等。
  • 跨平台应用是既想拥有原生应用的运行方式,又想一套代码发布 Android、iOS 两个终端的解决方法。开发方式与小程序相似,但是运行效果却又和原生应用相似,拥有大部分系统服务支持,也通过插件使用互联网厂商的云服务,性能要比小程序们高得多。值得一提的是 React Native 转译发生在编译打包期,Flutter 则是使用 Dart 虚拟机(类似 Java 虚拟机)在运行期转译,使用 Skia 引擎渲染(类似游戏渲染引擎),拥有非常高的性能。
  • 原生应用拥有极高的性能和操作系统级别的运行支持,拥有最繁荣的开发社区,无数的 SDK 生态,只要是这个世界上有的功能,原生开发都能做出来。缺点就是原生开发一套代码只能用于自家原生系统中,而且需要经过下载安装流程,与小程序们的「用完即走」的概念相反,而是「留着常用」

快应用与微信小程序的灵魂

快应用与微信小程序的出生理念就是用完即走,无需下载
快应用的问世就是要对标微信小程序,在华为推出的自家快应用 IDE 中,同微信小程序一样采用了微软的 VSCode 编辑器开源项目,并且提供了微信小程序转快应用功能,快应用的开发语法设计上就和微信小程序如出一辙,为的就是能够与微信小程序打通,引来开发者进行应用迁移。华为快应用 IDE 中的微信小程序转快应用功能仅仅是语法上的翻译,部分语法需要自己手动替换,复杂架构的项目通过转换功能迁移的过程应该不会顺利,牵扯得越多,问题就越多。
快应用不但在开发上为微信小程序开发者提供一定的便利,还有华为自家的云服务支持(仅限华为快应用)。快应用的野心很大,它可以设置链接规则,当在国内 Android 系统中点击到相关规则链接时,系统将不会跳转至浏览器,而是直接开启快应用跳转到相应界面,并且退出后可选择留存于桌面,这样一来快应用不仅仅要对标微信小程序,还想吃下部分国内原生市场,一箭双雕。甚至已经有类似 Google Play 的快游戏在开发中,也将直接对标微信小游戏。
当然快应用的缺点也很明显,比微信小程序出得晚,并且大多数都是转换后的二次开发项目,从头开发的极少,有许许多多的坑需要人踩,性能比原生应用要低很多,并且功能非常受限,只能完成上层的操作,对于操作系统底层的功能无法实现。
互联网大厂的快应用、小程序简直就是整个行业的标杆,它们会将一些碎片功能,比如看视频、打车、点餐、查快递、地图等重复使用率、分享率高的碎片页面做到快应用、小程序里,提供 APP 打开的入口,最核心的用户社区、投稿这些有高留存用户能力的模块会仅限在原生 APP 中。微信小程序不是用来做为跨平台的工具、它只是人们利用碎片时间的产物,设计理念里处处露出了「用完即走」的概念,需要做跨平台开发的应用会有专门的跨平台方案,而不是为了跨平台而去跨平台,更别说快应用仅仅只支持九大厂商的深度定制 Android 系统,iOS 会推出自家的、截然不同的快应用,国外的原生 Android 系统同样不会支持国内快应用。
到现在应该明白,不管是快应用还是微信小程序,它们应该是我们复杂应用的一个缩影,而不是我们应用本身,我们应该把重复使用率、分享率高的碎片页面做到快应用和微信小程序里,让用户点击分享链接时可以体验到「用完即走」的理念。原生应用才应该是那个复杂应用本身,最复杂的逻辑、最核心的场景,才是那个应该做进原生应用里的模块,最重要的模块,享受操作系统级别的支持,发挥着最优秀的性能,才能让用户「留着常用」

💡
以上纯属个人主观观点