一.背景：

随着哈啰出行发展，移动端业务场景越来越丰富，业务需求量逐步增加。如何提升开发效率，节省人力已成为我们面临的真实问题。我们思考如何借助原生端已支持的跨端平台引擎，来统一移动端业务逻辑开发，消除两端逻辑差异，保证业务逻辑代码两端只写一次，完成需求开发的提效，缩短问题排查时间。

现状：

例如消息平台的端内Push数据处理逻辑，站内信历史数据筛选逻辑，支付平台的支付方式的复杂判断逻辑，还有用户平台的登录流程，一键登录等处理两端逻辑大部分都是重复的，以及业务侧新需求，很多都是相同逻辑两端分别开发或同时修改原有业务逻辑，两端技术栈上的实现需要2倍的人力成本，两套实现逻辑对应的出错概率也会相应增加。

上述的数据处理逻辑，筛选逻辑以及判断逻辑等业务逻辑为交互上的状态更新，逻辑流转等。数据聚合等还是尽量由服务端或者BFF层来处理。BFF在B端的实践就是主要处理不同域之间的数据聚合，保证给到的model是面向UI的。

总结：

1.相同业务场景，业务逻辑两端分别实现。逻辑开发对应人力*2；

2.方案设计环节可能缺失。由于信息不对称等因素，不合理的设计可能导致健壮性，扩展性，复用性等打折扣；

3.两端的业务逻辑细节实现方式不一致；

4.不规范的代码设计导致业务逻辑跟页面强耦合。

Lumos混合栈提效方案：

结合目前团队内的跨端语言使用情况以及CI等基础建设，我们使用Dart来完成业务逻辑的跨平台建设。通过混合栈框架实现：

1.相同的业务场景，业务逻辑两端只实现一份。逻辑开发对应人力*1；

2.统一业务逻辑开发的前提是 合理一致的方案设计，反向保证方案设计环节；

3.统一两端业务逻辑细节的实现方式，为后续问题排查提升效率；

4.实现业务逻辑剥离，减少页面与逻辑的耦合。

(Lumos原为《哈利波特》中的照明咒—荧光闪烁，寓意更开阔明朗的未来)

二.方案设计

1.架构图-业务视角：

• 业务UI：业务需求开发只需要专注于两端的UI开发；

• Lumos业务逻辑：提供统一的对外通信协议，保证可扩展的情况下，规定了通信数据格式以及通信方式。内部借助跨平台引擎完成统一的业务逻辑处理，同时提供可扩展的通用业务能力；

• 支撑工具：复用已有基础建设完成快速开发，CI集成；

• 监控平台：Lumos在线上运行时，通过性能监控平台来获取运行状况，日志平台和埋点信息发现问题并及时响应。

2.时序图：

Native调用Flutter流程

Flutter调用Native流程(复用已有原生能力)

3.性能监控和异常捕获：

监控指标：

1.方法调用效率：针对API入口做调用效率的监控，抽样上传。根据实际性能数据完成分析对比；

2.数据传递，回传效率 ：针对不同数据量级做分层评估模型（参考维度：数据层级深度，数据属性个数，数据长度3个维度加权计算）统计数据传递，回传时间；

3.内存，CPU占用：复用FlutterAPM能力，监控线上Lumos引起的内存，CPU占用变化情况；

4.异常捕获：复用FlutterAPM能力，完成异常捕获和上报，确保及时响应和排查问题。

4.通信协议：

协议规定：

action moduleName methodName                        (Lumos定义） __|__   __|__   ____|____ /     \ /    \  /         \                               action:/login/getUserName/

参数描述：

三.实践

针对业务逻辑迭代频繁的模块，例如用户平台，支付平台，使用Lumos逻辑逻辑跨平台容器可以大大提升迭代速度，配合容器配置化平台方案，可以将业务验证成本最小化。实现业务稳定的前提下，快速迭代试错。

1.业务场景技术架构：

• 提效容器输入：Dart文本，参数，回调，错误处理，数据模型；

• 通信协议：负责规定原生与Dart之间的通信，数据传递的协议；

• 通用能力：一些常用场景，功能的Dart封装，例如网络请求，数据转换，定时器等；

• 提效容器能力：解析执行，中间态管理，模型转换，回调处理；

• 通信实现方式：通过MethodChannel未完成跨端通信；

• FlutterEngine:基于目前C端,B端单引擎模式，Lumos将复用UIEngine，减少资源占用；利用已有的CI，向日葵等集成流程，降低工程化成本。

2.混合栈实现一次业务逻辑开发

场景一：基于目前订单中心的业务迭代频率与迭代内容以及业务风险把控，我们首选这里做AB接入。订单中心页面数据由配置中心下发，不同类型的订单对应不同type。这里就涉及数据下发，数据匹配和数据筛选。整套数据处理由于两端统一的type类型约定，所以逻辑上是一致的。这里在统一定义好数据返回格式后，在Dart侧完成一次业务逻辑开发即可。

简化流程图：

场景二：支付组件涉及页面较简单-支付收银台，待支付收银台，但是对于不同星级用户以及不同场景环境，支付选项是多种多样的。

目前的痛点是：支付平台业务需求迭代频繁，90%以上的迭代内容为支付流程优化，逻辑修改或新增类型。配置化程度低，且iOS,Android两端修改，耗时耗力。

在对高可用高稳定追求更高的支付业务，结合支付后续业务规划，Lumos可以用来承载抽象出的业务规则和业务逻辑。配合配置平台，支付平台的需求迭代可以又稳又快的转起来。

3.提效数据统计：

1.案例一：[交易平台][订单中心改造]

开发资源：iOS,Android每端各需3人日，共计6人日

开发比例：全部为逻辑开发

使用Lumos节省：3人日

2.案例二：[消息平台][IM消息推送]

开发资源：iOS,Android每端各需8人日，共计16人日

开发比例：逻辑开发量:UI开发量为1：3

使用Lumos节省：6人日

例如一个iOS,Android每端各需6人日，共计12人日的业务需求：

如果将联调，测试，埋点，验证环节计算入内，提效数据效果会更明显。

-联调只需针对Dart业务逻辑完成联调即可

-针对业务逻辑的埋点，两端只需完成一次

-测试，产品验收只需对一段做业务逻辑完整回归，另一端可快速验证页面即可

四.未来与展望

未来的规划中，Lumos的使用场景不只局限于业务逻辑的开发提效。业务所处领域的数据，流程，规则等是可以通过Lumos统一集中在一起，通过状态集中管理来更新，监听，并维护我们的应用。使用Lumos来黑盒管理业务模型，仅对业务逻辑做必要的参数输入，而不去关心状态的流转，这样可以更专注于业务逻辑的开发。

这种基于状态模式的主要优点在于封装了转换规则，并枚举可能的状态，它将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 同时抛开所有展示层，这一层也可以不依赖于展示层而独立运行。

终极模式，我们希望借助Lumos托管业务模型层，负责统一方案设计后的领域数据流转和业务流程，业务规则的整合，使App层次更清晰合理，保证迭代速度和质量的大前提下，灵活有序的对接各个平台。

The End