关于flutter:移动端跨平台技术之下的变与不变

一. 跨平台，是想跨哪些平台？

目前（2020/7/18）来看，挪动端跨平台需要次要集中在：

• 跨 PC 端与挪动端：PC 向无线过渡的晚期，心愿 PC Web 与挪动 Web 复用同一套代码
• 跨 Native 与 Web：商品详情页等要求有一套性能差不多的 Web 页可能在端外拜访，须要跨 Native App 与 Web
• 跨 Native 双端：出于开发效率等起因，心愿 Android、iOS 双端复用一套业务代码
• 跨 App：一些产品性能冀望能在多个渠道投放上线，以工具类需要为主，如打车、买票、点餐

在可预感的将来，可能还会有这些跨平台需要：

• 跨轻利用：零碎级即用即走的轻量级利用，如 Android 快利用、iOS App Clips
• 跨 IoT 设施：各种有显示屏的设施都会成为新的“端”，如车载设施、智能家居
• 跨所有客户端：可能是伪需要，同一产品在不同平台的侧重点不同，或者并不需要把所有性能残缺地搬到各式各样的客户端设施 / 平台渠道上，例如快利用与 Native App 的定位显然不一样

在这样的时代背景下，无论从资源老本、开发效率，还是从产品迭代、技术演进的角度来看，跨平台开发都是强需要，所以才有了层出不穷的各种跨平台计划摸索

二. 层出不穷的跨平台技术

细数近几年业界支流的挪动端跨平台计划，可大抵分为 3 类：

• Web 生而跨平台：只有有浏览器或 WebView，依靠 Web 技术即可轻松跨平台，如 Web App、PWA（Progressive Web Apps）、Hybrid App、PHA（Progress Hybrid App）
• 容器化 Native 跨端：将 Native App 革新成标准化的容器，进而容许一套代码跨多端规范容器运行，如 React Native/Weex、Flutter
• 小程序一码多投跨 App：国内市场中，越来越多的超级 App 反对了小程序，但各自的小程序框架并没有统一标准，于是有了 Taro、kbone、uni-app 等一系列跨小程序框架的计划来满足跨 App 投放产品性能的需要

跨平台：Web 与生俱来

跨平台是 Web 与生俱来的劣势，浏览器和 WebView 都是 W3C 标准下的标准化 Web 容器，因而 Web 页面可能轻松投放到端外浏览器、端内 WebView、以及其它 App 提供的 WebView 中

单从老本角度来看，Web 计划是跨平台的不二之选：

• 没有额定的学习老本：一套根底技术吃遍端内、端外、甚至 PC 浏览器、电视机顶盒
• 不依赖非凡的配套设施：开发、调试、构建、公布、监控、运维等所有工程化环节都是通用的
• 坐拥宏大的既有生态：npm 百万模块，包罗万象
• Web 基于凋谢规范：走进来引进来都不是难事

并且，Web 自身就是一个平台，退可守，技术危险更低

但在另一些方面，依附 Web 技术跨端也存在其 局限性：

• 平台能力：受限于 Web 规范容器，无奈满足平台能力相干的需要，如相机、蓝牙、多媒体等
• 体验：挪动端 Web 体验远不迭 Native，次要体现在首屏加载慢、动画卡顿、长页滚动闪动等场景
• 性能：内存耗费大、GPU 利用率低

加上 Web 规范更迭慢，新个性兼容性差（如 Push API 过来许多年了，依然无奈放心使用），Web 根底能力难以满足 Native 端的需要。因而，在传统 Web App 的根底上，开展了更多的摸索：

• PWA（Progressive Web Apps）：离线缓存、零碎告诉、主屏图标等类 Native App 能力加持之下的 Web App，但兼容性并不乐观
• Hybrid App：Web 与 Native 混合的计划，将由 Native 实现的平台能力（比方扫描二维码）注入到 WebView 环境供 Web App 应用，以扩大 Web 的平台能力
• PHA（Progressive Hybrid App）：PWA 与 Hybrid 思维的联合，通过 Hybrid 伎俩让 Web 的性能和体验靠近 Native

PWA 标准化仿佛走不通，即使走通了可能真正释怀用起来可能也是数年之后了。Hybrid App 解决了一部分问题（平台能力扩大），但还不够。PHA 是这两种思路的连续，借助 Native 技术实现 PWA 的幻想

但无论 PHA 还是 HA，引入 Native 依赖都意味着 Web 开放性的损失，继而带来跨端、跨 App 方面的问题

跨端：容器化 Native

除 Web 人造跨端之外，另一种对立多端的思路是 将 Native 定制成规范容器，让同一份代码跑在一个个规范容器中，例如：

• Android 容器：Native 壳 App
• iOS 容器：Native 壳 App
• Web 容器：Web Runtime

React Native 跨 Android、iOS、Web、Windows 四端，Weex 跨 Android、iOS、Web 三端，Flutter 以相似的形式跨 Android、iOS、Web、Linux 四端

从技术角度来看，RN 与 Weex 在 Native 容器中提供了 JavaScript 运行环境，以及布局引擎，渲染层都采纳 Native 控件，因而 UI 交互上依然存在零碎差别。而 Flutter 计划更彻底一些，连渲染层也换成了基于图形引擎自绘 UI 控件，从而保障 UI 交互的跨端一致性

然而，因为 容器化 Native 的计划是从 Native 登程，没有跨端天才，除了要想方法反对 Web，还面临一个更难解决的问题——跨 App

跨 App：小程序一码多投

技术视角下，小程序跨 Native App 依然是依附 Web 计划，那么，为什么不间接用 Web App 呢？

因为商业竞争等因素，闯入他人家地盘的 Web App 通常会受到一些限度，如平安正告、权限管制、甚至罗唆禁止拜访（所以才有了口令分享等弯弯绕绕的形式）

小程序则不同，其初衷是凋谢的，欢送大家入驻（当然，也要遵守规则），并且国内的许多大型 App 也都相继凋谢了小程序能力，小程序逐步成为跨 App 的正规形式。但小程序平台多起来之后，框架规范不对立的问题也裸露了进去，都叫小程序，但都大同小异，于是，如何疾速产出多种小程序变成了一个值得摸索的技术课题

实现原理上分为两种，编译转换与运行时适配，前者可能达到等同于原生小程序的性能但带来了诸多限度（编译期难以辨认的写法都不反对），现有的 Web App 不那么容易迁徙成跨 App 小程序，例如 Taro、uni-app 等。后者就义性能换取了更多的可能性，现有的 Web App 可能绝对容易地迁徙过去，例如 Taro Next、kbone 等

P.S. 当然，也能够有动静联合的思路，现实状况下，绝大多数根底业务走运行时平迁，个别高性能要求的局部走编译转换

三. 重重变动之中，什么才是不变量？

渠道 / 端 / 平台、业务代码、工程化配套设施仿佛都在疾速地发生变化，没有哪个是稳固不变的

既然全都在变，就换个角度看，哪个局部肯定会发生变化？

• 容器：新的渠道 / 端 / 平台都是新的容器
• 跨容器技术：新容器的呈现，意味着新的跨容器技术要求

哪个局部是不必要跟着变的？

• 业务代码：技术计划的更迭、新渠道 / 端 / 平台的呈现，通常随同着业务代码的迁徙，Native 切 React Native 切 Flutter……乐此不疲，但从老本上看，业务代码并不一定也并不应该跟着变
• 工程化配套设施：大多与技术栈强相干，例如 Web App 的开发、调试、构建、公布、监控、运维与 Native App 存在诸多差别，但其中更根底的局部是技术无关，而流程相干的，例如构建 - 公布流程、监控运维服务等并不需要跟着变
• 容器中的平台能力：无论何种跨容器的计划，平台能力扩大需要都是统一的，对应的 Native 模块封装不应该跟着变

业务代码迁徙的老本是十分高的（波及技术栈变动时更痛），配套设施的推倒重建也相对是大工程，那么，有没有方法把这些不应该跟着变的局部固定下来？

有，将变动的局部形象进来。依赖形象而不依赖具体，下层就不必跟着变了：

规范框架   \
---------  |  配套设施
规范容器   /

在这样的形象模型下，下层业务代码依赖规范业务框架，而不间接依赖容器能力，从而容许业务框架以下的局部可能替换。业务框架依赖形象的规范容器，而不与具体的特定容器相绑定，可替换为遵循容器规范的其它容器

基于规范框架，可能提供配套的脚手架、组件库、可视化搭建等配套开发工具。基于规范容器，可能建设性能诊断、事件追踪等配套调试能力，从而笼罩到工程化的整个链路，配套设施也简直不必跟着变了

至于平台能力扩大，作为规范容器中的重要局部，也应该形象出规范 API（类比浏览器提供的 BOM 系 API），供下层业务应用

四. 跨平台技术的将来

预感不到将来，所以这里抛出几个可能性：

• 挪动跨端只跨 Native 两端：对许多挪动产品而言，体验细腻、性能优异的 Native App 仍是目前最重要的利用状态，并且 双端性能完全一致，等同重要，所以只跨 Android、iOS 两端，对立挪动端 Native 开发是绝对正当的计划
• 小程序跨 App 自成一体：如果小程序不能真正标准化，跨 App 投放需要催生出的跨小程序框架计划就有必要存在
• Web 仍是 Web，Hybrid 仍将继续：Web 个性更迭周期太长，挪动设施的更迭太慢，等不及 Web 以年为单位的进化速度，依附 Native 加强 Web 的 Hybrid 过渡计划很可能长期“过渡”上来

P.S. 小程序曾经在标准化过程中了，小程序框架成为标准化的容器也不是没有可能，毕竟小程序框架不存在 WebView、浏览器一样的慢周期阻力

不看好一招吃遍天下的跨全端的计划，因为无论 universal 组件还是 universal API 都是最小交加，无奈满足理论须要。并且，真的须要让一套代码运行在所有渠道、端、平台上吗？

同一产品在不同平台的侧重点不同，或者并不需要把所有性能残缺地搬到各式各样的客户端设施 / 平台渠道上，例如快利用与 Native App 的定位显然不一样

参考资料

• Why Rax?

有所得、有所惑，真好

关注「前端向后」微信公众号，你将播种一系列「用 心原创」的高质量技术文章，主题包含但不限于前端、Node.js 以及服务端技术

本文首发于 ayqy.net，原文链接：http://www.ayqy.net/blog/%e7%…