共计 4545 个字符，预计需要花费 12 分钟才能阅读完成。
背景介绍
Android 利用采纳 Java 或 Kotlin 编写，iOS 利用采纳 Objective- C 和 Swift 编写，但当咱们要去开发反对多端的利用，每一端都须要独立研发、测试，直到上线。为了解决多端独立开发的问题，跨端技术的计划备受青眼。
两轮跨端技术的尝试要追溯到 2019 年，过后整个互联网行业都在提效的大背景推动下开始各种跨端计划的尝试，而前身还是两轮助力车团队的两轮大前端也开始了跨端技术计划的摸索。过后可供选择的跨端计划有 React Native 计划、Weex 计划，H5 离线化计划以及过后较火的 Flutter 技术计划，而咱们的指标是心愿可能找到稳固、适宜咱们业务个性，并且能够持续进行深耕的技术计划进行调研和尝试。
思考和调研
支流的跨端计划次要分为两种，一种是将 JavaScriptCore 引擎当作虚拟机的计划，代表的框架是 React Native。另一种应用自渲染引擎的计划，代表框架是 Flutter。
框架层 + 原生渲染计划
它的开发语言选择了 js，应用的语法和 React 完全一致，不用于个别 React 利用，它须要借助原生的能力来进行渲染，组件最终都会被渲染为原生组件。尽管给用户带来比拟好的体验，但性能方面不会很高。
以 Web 为根底的 H5 Hybrid 离线化计划
相对来说这是开发成本最小的一种计划，因为它实际上是在写前端的界面，和一般开发 H5 网页并没有太大的区别。这一计划所面临的次要考验就是性能问题以及因为网络提早而带来的用户体验问题。在此基础上咱们引入了离线化的计划，咱们打算是通过 CRM 平台发放 H5 离线包达到本地，应用 WebView 进行本地资源加载，来突破性能问题。
框架层 + 自渲染引擎计划
这种计划和下面的区别就是，它并没有间接借用原生能力去渲染组件，而是利用了更底层的渲染能力，本人去渲染组件。这种形式显然链路会比拟短，性能方面也会更突出，同时在放弃多端渲染一致性下面，也会比后面两种计划更加牢靠，这类框架的典型例子就是 Flutter。
计划比照与抉择
咱们在抉择跨端计划的时候，不只是要思考常见的几种重要指标，如编程语言、性能、技术架构等来判断是否适宜咱们团队和产品，更多还要去思考开发效率、社区反对等工程化方面的指标，同时还要思考团队现状、所选计划的生态和技术将来的倒退方向。
比照计划制订
在社区、成熟度趋于统一的时候，跨平台计划的性能就成了重要的思考因素和指标。性能更佳的 Flutter 当然是首选。另一方面，对于本来是 Native 开发的人来说，React Native 与 Flutter 开发成本是相差不大的，从久远角度来看，抉择 Flutter 技术计划仿佛是较为适合的抉择。
同时联合过后组内的状况，咱们抉择了 H5 Hybrid 离线化和 Flutter 作为比拟计划进行端测的尝试。H5 Hybrid 离线化计划相对来说比较简单，而且自主性比拟强，计划逻辑简略危险较小。如果试验胜利咱们能够走出一条自主翻新的跨端路线，而 Flutter 技术计划性能较高，社区也比拟沉闷，UI 渲染框架做的较为彻底，也是过后跨端技术计划的代表方向。所以咱们综合以上的思考，心愿通过实际拿到要害的比照数据，为后续最终的计划抉择提供反对。
Flutter 是什么
Flutter 是 Google 的挪动 UI 框架，能够疾速在 iOS 和 Android 上构建高质量的原生用户界面，它是 Google 一个新的用于构建跨平台的手机 App 的 SDK。写一份代码，能够多端运行，Flutter 同时能够与现有的代码一起工作，被越来越多的开发者和组织应用，并且 Flutter 是完全免费和开源的。
从官网的介绍来看，Flutter 的特点能够总结成三点。一是跨平台，当初 Flutter 3 根本能够实现跨 6 种平台，甚至反对嵌入式开发。到目前为止 Flutter 算是反对平台最多的框架了，良好的跨平台性，间接带来的益处就是缩小开发成本。二是原生用户页面，让咱们的体验更好，性能方面也会更好。用官网的话就是平滑而天然的滑动成果和平台感知，为用户带来全新的体验。三是开源收费，同 Android 零碎一样，这些都是收费开源的。
计划线上验证
通过一段时间的调研和剖析当前，咱们基本上确定了两轮跨端计划的技术选型和比照计划。本着审慎的准则，咱们破费了肯定的精力在这两个计划的验证比照、以及跨端技术计划的推动办法摸索上。
H5 Hybrid 离线化计划
针对该计划，咱们的打算是分两期执行。第一期是实现框架的外围代码，并在 BOS 端实现一个页面的革新上线，拿到线上运行数据。第二期是在第一期数据的根底上打造 CRM 平台，欠缺计划的零碎利用。
该计划的根本构造分为代码层、协定层、Hybrid 离线 SDK 层以及离线包管理系统。其中的代码层是合乎特定规范的 H5 工程开发产生的代码。当 H5 页面产生资源或款式的申请时，容器层会检测资源申请事件，并依据资源协定寻找本地资源包对应地位的资源并进行加载。本地资源加载实现后，造成数据流申请响应返回 H5 页面。
数据的流转在框架中经验了数据散发、协定解析、指标执行、后果反馈几个阶段。通过在端侧建设协定层的封装，保障了协定规定对立。整个协定过程做了 SDK 化的封装，保障了外围框架层的稳固。
Flutter 计划
针对 Flutter 计划的尝试，咱们须要在一开始优先解决工程构造、打包构建、上线集成和原生工程混合开发的问题。
针对于工程构造，Flutter 在业务上的利用须要一个 Host 载体，咱们抉择了 Flutter Module 工程作为 Flutter 业务工程的 Host 工程。向上输入构建产物对原生工程的继承，向下组装和汇合业务工程，造成对立的模块注入、页面注册的模式。
针对 Flutter 我的项目打包构建、上线集成和混合开发的问题，咱们须要联合过后公司产物构建和治理规定进行 Flutter 产物的构建。咱们的计划是在 Jinkens 下面创立独自的 Job 进行 Flutter module 产物的构建，最终把生成的 Android 和 iOS 产物集成到原生工程中，实现 Flutter 环境和代码的集成。以上便初步搭建实现了 Flutter 业务开发工程构造，并实现了在原生工程中混合开发、构建上线的一系列流程。
比对试验
在页面上线后，咱们很快拿到了一手数据。在稳定性方面两种计划体现都比拟好，没有呈现页面 crash 的状况。在加载性能、白屏或者异样方面，Flutter 计划要比 H5 Hybrid 离线化计划体现得更好。综合以上运行状况比照，咱们根本确定了 Flutter 作为次要的大前端实际计划。
Flutter 利用推动
框架 1.0 阶段
咱们对 Flutter 技术工程化利用生产了各种轮子，以求达到对 Flutter 标准、高效利用的目标，比方数据的流转散发、网络模块的封装、MVVM 构造的组织等。这一阶段的框架次要分为页面路由治理、数据总线、工程框架、网络申请、资源管理和组件治理。总体来说在这一阶段，咱们对于 Flutter 利用根本造成了初具雏形的工程构造体系和根底能力建设。
框架 2.0 阶段
在这一阶段 Flutter 的利用算是进入了深水区，随着利用场景的减少，各种问题裸露进去，其中比拟辣手的问题有 Flutter 状态治理、页面生命周期和混合插件缺失问题。针对 Flutter 状态治理、页面生命周期的问题，咱们基于原生开发的教训，搭建了一套合乎 MVVM 规范的 Flutter 代码根底构造。
这套根底构造次要分为 Page 与 VM 两局部，组织关系如图所示。Page 与 VM 逻辑离开，Page 是对 VM 的封装，VM 是业务逻辑的独立单元，蕴含了残缺的 UI 以及逻辑层 Module。
上面是 Page 根底构造性能定义阐明。在这一构造中，咱们是以 PageRoute 为根底进行扩大封装。PageLifecycle 定义了生命周期和生命周期状态值；LifecycleEventNotify 负责生命周期事件的传递；LifecycleNotifyManager 是生命周期框架的外围枢纽，所有的事件汇总到这里向下调用生命周期 API；LifecycleFromFlutter 和 LifecycleFromBoost 收集 flutter 原生和 flutter boost 的生命周期的调用，总结调整后依照新的生命周期标准发送事件；PageAnimation 是页面动画的集成工具；WidgetProviderRender 是页面 UI 搭建的工具类，负责 provider、widget 的创立和组装，最终造成残缺的页面；ModuleBinder 是页面对 Module 的绑定工具，实现了 module 宿主的绑定，当宿主销毁时 module 能感知到并做出相应的反馈。
上面是 VM 层根底构造。VM 层和 Page 层根本相似，不同的是它会依据 VM 的特点进行本身生命周期的感知和解决，解决形式绝对 Page 会更加简单。
Flutter Map 组件
针对以地图为代表的原生混合组件能力的建设，过后 flutter 社区的能力反对有余，没有适合的轮子应用，然而咱们的业务场景又是比拟重地图的。在这种状况下，咱们就须要本人去开发一套地图组件。
如图是 Flutter Map 的总体结构图，咱们利用的是 flutter 框架的 PlatformView 机制，在原生层实现 view 的实例化创立，再交给 flutter 进行 UI 的渲染，实现了原生 view 在 flutter 体系中的渲染和展现。接下来咱们须要在 flutter 层与原生 view 进行操控，这里须要咱们可能精确找到对应的原生 view，并通过 channel 通道传播相干的指令。原生 view 收到指令当前，会依据规定做出相应的动作，并产生后果原路返回给调用方。原生 view 产生一些事件状态时，比方地图的拖动、加载实现等事件，须要及时传递给 flutter 端，同时 flutter 端有一些状态也须要传递给原生端，以便业务侧和原生 view 侧都可能及时做出相应的反馈。这里咱们以 channel 为根底建设了双工通道，实现了 flutter 与 platform 两端实现实时进行事件告诉的能力。
Flutter 规范体系化建设阶段
在这一阶段咱们的 flutter 在两轮大量的业务场景的利用实际下，根本趋于稳定的状态，通过咱们在这一阶段对 flutter 的体系化革新，造成了汇合 flutter 工程搭建、开发调试、根底能力积淀以及开发规范输入的体系化构造。
Git 仓库整顿
在仓库构造方面，咱们整合了散乱的 flutter 仓库保护状态，造成了当初对立、规范、聚合的仓库汇合。目前的仓库叫 HBFlutter，包含中间件子分组、根底组件子分组、native 能力子分组和其余子分组。
组件分类
在根底能力积淀方面，咱们对现有根底组件进行了梳理和标准化革新，根本造成了一套体系化的 flutter 根底能力建设。
技术总结
Flutter 技术目前在两轮失去了利用和推广，在哈啰 App 两轮业务场景下根本实现了全量 Flutter 化革新，Bos App 也在往年开启了 Flutter 技术改造，目前曾经根本实现大部分流程的 Flutter 化革新，目前线上运行绝对安稳。两轮业务在利用 Flutter 技术后实现了开发效率的大幅度晋升，同时也很大水平上解决了 Android 和 iOS UI 不统一的问题。后续咱们将持续追踪 Flutter 技术的倒退，并视业务场景的需要进行正当的利用和推广。
（本文作者：田克雨）