快应用和小程序

2016 年 9 月微信小程序开始内测，2017 年 1 月微信小程序正式发布，一经面世就掀起了国内移动开发的浪潮。2018 年 3 月，九大第三方 Android 手机厂商也在北京联合推出了「快应用」标准。

互联网时代下的移动端软件

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 框架。

那么小程序、原生应用、跨平台应用究竟是个什么定位？什么样的应用该用小程序开发？什么样的应用该用原生开发？

通过各项指标的对比，可以发现它们的定位：

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

小程序的灵魂

小程序的出生理念就是用完即走，无需下载。

快应用的问世就是要对标微信小程序，在华为推出的自家快应用 IDE 中，同微信小程序一样采用了微软的 VSCode 编辑器开源项目，并且提供了微信小程序转快应用功能，快应用的开发语法设计上就和微信小程序如出一辙，为的就是能够与微信小程序打通，引来开发者进行应用迁移。华为快应用 IDE 中的微信小程序转快应用功能仅仅是语法上的翻译，部分语法需要自己手动替换，复杂架构的项目通过转换功能迁移的过程应该不会顺利，牵扯得越多，问题就越多。

快应用不但在开发上为微信小程序开发者提供一定的便利，还有华为自家的云服务支持（仅限华为快应用）。快应用的野心很大，它可以设置链接规则，当在国内 Android 系统中点击到相关规则链接时，系统将不会跳转至浏览器，而是直接开启快应用跳转到相应界面，并且退出后可选择留存于桌面，这样一来快应用不仅仅要对标微信小程序，还想吃下部分国内原生市场，一箭双雕。甚至已经有类似 Google Play 的快游戏在开发中，也将直接对标微信小游戏。

当然快应用的缺点也很明显，比微信小程序出得晚，并且大多数都是转换后的二次开发项目，从头开发的极少，有许许多多的坑需要人踩，性能比原生应用要低很多，并且功能非常受限，只能完成上层的操作，对于操作系统底层的功能无法实现。

互联网大厂的快应用、小程序做得就比较讨巧，它们会将一些碎片功能，比如看视频、打车、点餐、查快递、地图等重复使用率、分享率高的碎片页面做到快应用、小程序里，提供 APP 打开的入口进行引流，最核心的用户社区、投稿这些有高留存用户能力的模块会仅限在原生 APP 中。

小程序不是被用来作为跨平台的工具，它只是人们利用碎片时间的产物，设计理念里处处透露出了 「用完即走」 的概念，需要做跨平台开发的应用会有专门的跨平台方案，而不是为了跨平台而去跨平台。

到现在应该明白，不管是快应用还是微信小程序，它们应该是我们复杂应用的一个缩影，而不是我们应用本身，我们应该把重复使用率、分享率高的碎片页面做到快应用和微信小程序里，让用户点击分享等链接时可以体验到「用完即走」的理念。原生应用才应该是那个复杂应用本身，最复杂的逻辑、最核心的场景，才是那个应该做进原生应用里的模块，最重要的模块，享受操作系统级别的支持，发挥着最优秀的性能，才能让用户「留着常用」。