浅谈跨端方案的演进

450 阅读6分钟
  1. 前言

跨端方案在业界一直是很热门的方向

并且在这么多年的发展历程中,诞生出非常非常多的方案,但是大体来说主要分为 4 类

  1. WAP

Native APP 搭载 H5 页面,交互能力较弱,性能较差,适合静态页面

  1. Hybrid

    1. 类 RN 方案

      主要以 RN 为代表,将渲染机制交还给了系统,性能相较于 WAP 来说,提升不少

      不同的大厂基于 RN 的思想,也研发出自己的一些方案,比如阿里的 Weex,字节的 lynx,蚂蚁的 mpass 等

    2. 类小程序方案

      主要以微信小程序,支付宝小程序为代表

      主要特点是每个小程序真的可以看做是一个小 APP

  2. 自绘渲染,以 Flutter 为代表

    前面的 WAP,Hybrid 方案,都需要掌握 Native 和部分跨端能力,对能力有一定的要求,那可不可以真的不含任何的Native 代码,实现一套代码,多端执行呢?

    Flutter 就是按照这个思路来进行开发的,能在一定程度上实现一个 Flutter 项目在双端执行

  1. APP 架构分类与演进

  1. 纯 Native

传统的 APP 开发模式,纯 Android 或纯 IOS

对于一个功能,我们需要开发 Android、iOS两份代码,成本来说相对较大

而且动态能力不足,Native的发版和铺量相对较慢,不适合快节奏的业务变化,比如说直播经常有主播的临时活动,是难以预估的,

所以这就是为什么我们需要动态化方案的原因

后面动态化 APP 架构的演进中,又分为了 H5 APP 和 Hybrid APP两种

  1. H5 APP

将前端的 H5 页面加载到 APP 中,比如:Android webView 去加载前端页面

适合相对静态的页面,如文档

优点:

  1. 不需要重新开发,只需要APP 加载现有的页面即可

  2. 没有额外的学习成本,前端只需要使用原来开发 H5 的技术即可

  3. 通用性好:维护一个 webView 容器,可以加载各种各样的 H5 页面

缺点:

  1. 交互能力弱,比较适合静态页面

  2. 需要各种各样的适配,比如不同的平台(Android、iOS),不同的 Native 版本

  3. 网络加载慢时,容易出现白屏

  4. Hybrid 混合 APP

在 Native APP 中开放一个动态化容器, 在该容器中支持动态化代码,实现该容器中业务一套代码,多端执行

因为一个 APP 中有 Native 代码,也有动态化代码,所以叫做 Hybrid 混合 APP

常见的 Hybrid 方案主要分为两种

  • 类 RN方案

  • 类小程序方案

优点:

  • 集合双方的优点,既能拥有 Native 强大的交互能力,也能提供实现跨平台的能力,一套代码双端执行

  • 能力完备,适用于各种各样的复杂业务

缺点:

底层要有一个功能强大、稳定的跨平台框架,所以技术难度大,维护成本高

暂时无法在飞书文档外展示此内容

  1. 跨端方案的演进

  1. 类 web方案

以 Web 为基础,实现成本最低,只是 Native 提供 WebView 运行 Web 页面,并提供相应的 API

平台兼容性问题,大部分交给 Web 来处理(Native 基本上只需要处理 API 层的兼容)

优点

  • 可以直接套用现有 JS 的基础能力与框架,如编码、构建、发布、组件库等

  • 对前端友好,和日常的 web 开发没有区别

缺点:

  • 性能差

  • 交互能力受限

方案

  • Cordova

  • AppCan

  1. Hybrid : 类 RN 方案

基础概念

类 RN 方案将渲染机制交给系统,可以理解为:代码层面还是一套代码,但是在运行时,会根据代码运行的平台自动转换为对应的原生组件,实现更好的性能

为了解决WebView性能差的问题,以 RN 为代表的一类框架将最终渲染工作交还给了系统

虽然同样使用类 HTML+JS 的 UI 构建逻辑,但是最终会生成对应的自定义原生控件,以充分利用原生控件相对于WebView的较高的绘制效率。

与此同时这种策略也将框架本身和App开发者绑在了系统的控件系统上,不仅框架本身需要处理大量平台相关的逻辑,随着系统版本变化和API的变化,开发者可能也需要处理不同平台的差异,甚至有些特性只能在部分平台上实现,这样框架的跨平台特性就会大打折扣

不同厂的方案

RN

React Native 原理与实践 - 掘金

基于 RN 的思路,不同的厂自研出不同的跨端方案,如 Weex ,mpass,lynx等

weex

阿里的 weex 方案

主要支持 VUE 的前端实现

rax

rax.js.org/docs/guide/…

weex 主要支持 VUE,阿里作为这么大的公司,肯定很多地方使用 RN,所以 rax 应运而生

mpass

支付宝的方案

lynx

字节的方案

  1. Hybrid : 类小程序方案

基础概念

小程序

  1. 纯跨端方案

基础概念

前面的类 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高得多。

参考: