背景介绍
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技术的倒退，并视业务场景的需要进行正当的利用和推广。
（本文作者：田克雨）