-
前言
跨端方案在业界一直是很热门的方向
并且在这么多年的发展历程中,诞生出非常非常多的方案,但是大体来说主要分为 4 类
- WAP
Native APP 搭载 H5 页面,交互能力较弱,性能较差,适合静态页面
-
Hybrid
-
类 RN 方案
主要以 RN 为代表,将渲染机制交还给了系统,性能相较于 WAP 来说,提升不少
不同的大厂基于 RN 的思想,也研发出自己的一些方案,比如阿里的 Weex,字节的 lynx,蚂蚁的 mpass 等
-
类小程序方案
主要以微信小程序,支付宝小程序为代表
主要特点是每个小程序真的可以看做是一个小 APP
-
-
自绘渲染,以 Flutter 为代表
前面的 WAP,Hybrid 方案,都需要掌握 Native 和部分跨端能力,对能力有一定的要求,那可不可以真的不含任何的Native 代码,实现一套代码,多端执行呢?
Flutter 就是按照这个思路来进行开发的,能在一定程度上实现一个 Flutter 项目在双端执行
-
APP 架构分类与演进
-
纯 Native
传统的 APP 开发模式,纯 Android 或纯 IOS
对于一个功能,我们需要开发 Android、iOS两份代码,成本来说相对较大
而且动态能力不足,Native的发版和铺量相对较慢,不适合快节奏的业务变化,比如说直播经常有主播的临时活动,是难以预估的,
所以这就是为什么我们需要动态化方案的原因
后面动态化 APP 架构的演进中,又分为了 H5 APP 和 Hybrid APP两种
-
H5 APP
将前端的 H5 页面加载到 APP 中,比如:Android webView 去加载前端页面
适合相对静态的页面,如文档
优点:
-
不需要重新开发,只需要APP 加载现有的页面即可
-
没有额外的学习成本,前端只需要使用原来开发 H5 的技术即可
-
通用性好:维护一个 webView 容器,可以加载各种各样的 H5 页面
缺点:
-
交互能力弱,比较适合静态页面
-
需要各种各样的适配,比如不同的平台(Android、iOS),不同的 Native 版本
-
网络加载慢时,容易出现白屏
-
Hybrid 混合 APP
在 Native APP 中开放一个动态化容器, 在该容器中支持动态化代码,实现该容器中业务一套代码,多端执行
因为一个 APP 中有 Native 代码,也有动态化代码,所以叫做 Hybrid 混合 APP
常见的 Hybrid 方案主要分为两种
-
类 RN方案
-
类小程序方案
优点:
-
集合双方的优点,既能拥有 Native 强大的交互能力,也能提供实现跨平台的能力,一套代码双端执行
-
能力完备,适用于各种各样的复杂业务
缺点:
底层要有一个功能强大、稳定的跨平台框架,所以技术难度大,维护成本高
暂时无法在飞书文档外展示此内容
-
跨端方案的演进
-
类 web方案
以 Web 为基础,实现成本最低,只是 Native 提供 WebView 运行 Web 页面,并提供相应的 API
平台兼容性问题,大部分交给 Web 来处理(Native 基本上只需要处理 API 层的兼容)
优点
-
可以直接套用现有 JS 的基础能力与框架,如编码、构建、发布、组件库等
-
对前端友好,和日常的 web 开发没有区别
缺点:
-
性能差
-
交互能力受限
方案
-
Cordova
-
AppCan
-
Hybrid : 类 RN 方案
基础概念
类 RN 方案将渲染机制交给系统,可以理解为:代码层面还是一套代码,但是在运行时,会根据代码运行的平台自动转换为对应的原生组件,实现更好的性能
为了解决WebView性能差的问题,以 RN 为代表的一类框架将最终渲染工作交还给了系统
虽然同样使用类 HTML+JS 的 UI 构建逻辑,但是最终会生成对应的自定义原生控件,以充分利用原生控件相对于WebView的较高的绘制效率。
与此同时这种策略也将框架本身和App开发者绑在了系统的控件系统上,不仅框架本身需要处理大量平台相关的逻辑,随着系统版本变化和API的变化,开发者可能也需要处理不同平台的差异,甚至有些特性只能在部分平台上实现,这样框架的跨平台特性就会大打折扣
不同厂的方案
RN
基于 RN 的思路,不同的厂自研出不同的跨端方案,如 Weex ,mpass,lynx等
weex
阿里的 weex 方案
主要支持 VUE 的前端实现
rax
weex 主要支持 VUE,阿里作为这么大的公司,肯定很多地方使用 RN,所以 rax 应运而生
mpass
支付宝的方案
lynx
字节的方案
-
Hybrid : 类小程序方案
基础概念
小程序
-
纯跨端方案
基础概念
前面的类 web 方案, Hybrid 方案, 都是在 Native App 的基础上, 实现了部分动态化容器, 支持了跨端的能力
这个就要求开发者需要两个技术栈: Native + 跨端
开发和维护成本比较大, 对开发者也有一定的要求
那有没有一种方案可以实现一个项目, 不用任何的 Native 代码, 就可以实现在 Android 和 iOS 中呢?
其实有的,目前 Flutter
就可以实现一个 Flutter 项目在 Android 和 iOS 中执行
flutter
为了解决WebView性能差的问题,以React Native为代表的一类框架将最终渲染工作交还给了系统,虽然同样使用类HTML+JS的UI构建逻辑,但是最终会生成对应的自定义原生控件,以充分利用原生控件相对于WebView的较高的绘制效率。
与此同时这种策略也将框架本身和App开发者绑在了系统的控件系统上,不仅框架本身需要处理大量平台相关的逻辑,随着系统版本变化和API的变化,开发者可能也需要处理不同平台的差异,甚至有些特性只能在部分平台上实现,这样框架的跨平台特性就会大打折扣。
Flutter则开辟了一种全新的思路,从头到尾重写一套跨平台的UI框架,包括UI控件、渲染逻辑甚至开发语言。渲染引擎依靠跨平台的Skia图形库来实现,依赖系统的只有图形绘制相关的接口,可以在最大程度上保证不同平台、不同设备的体验一致性,逻辑处理使用支持AOT的Dart语言,执行效率也比JavaScript高得多。
参考: