构建属于自己的构建属于自己的Flutter混合开发框架混合开发框架
所谓混合开发,指的是 App 的整体架构以原生技术栈为基础,将 Flutter 运行环境嵌入到原生 App 工程中,然后由原生开发人员为 Flutter 运行提供宿主容器及基础能力支撑,而
Flutter 开发人员则负责应用层业务及 App 内大部分渲染工作。
在这种开发模式下,好处十分明显。对于工程师而言,跨平台的 Flutter 框架减少了对底层环境的依赖,使用完整的技术栈和工具链隔离了各个终端系统的差异,无论是 Android、
iOS 甚至是前端工程师,都可以使用统一而标准化的能力进行业务开发,从而扩充了技能栈。而对于企业而言,这种方式不仅具备了原生 App 良好的用户体验,以及丰富的底层能
力,还同时拥有了跨平台技术开发低成本和多端体验一致性的优势,直接节省研发资源。
那么,在原生工程中引入 Flutter 混合开发能力,我们应该如何设计工程架构,原生开发与 Flutter 开发的工作模式又是怎样的呢?
混合开发架构混合开发架构
与纯 Flutter 工程能够以自治的方式去分拆软件功能、管理工程依赖不同,Flutter 混合工程的功能分治需要原生工程与 Flutter 工程一起配合完成,即:在 Flutter 模块的视角看来,一
部分与渲染相关的基础能力完全由 Flutter 代码实现,而另一部分涉及操作系统底层、业务通用能力部分,以及整体应用架构支撑,则需要借助于原生工程给予支持。
我们可以通过四象限分析法,把纯 Flutter 应用按照业务和 UI 分解成 4 类。同样,混合工程的功能单元也可以按照这个分治逻辑分为 4 个维度,即不具备业务属性的原生基础功能、
不具备业务属性的原生 UI 控件、不具备 UI 属性的原生基础业务功能和带 UI 属性的独立业务模块,如下图所示。
从图中可以看到,对于前 3 个维度(即原生 UI 控件、原生基础功能、原生基础业务功能)的定义,纯 Flutter 工程与混合工程并无区别,只不过实现的方式由 Flutter 变成了原生;对
于第四个维度(即独立业务模块)的功能归属,考虑到业务模块的最小单元是页面,而 Flutter 的最终呈现形式也是独立的页面,因此我们把 Flutter 模块也归为此类,我们的工程可
以像依赖原生业务模块一样直接依赖它,为用户提供独立的业务功能。当我们把这些组件及其依赖按照从上到下的方式进行划分,然后再整体看,就是一个完整的混合开发架构了,
整个架构下图所示。