flutter java混编_有赞 Flutter 混编方案

背景

目前准备试水 Flutter，但是多数native开发是不了解Flutter，因此需要设计一种比较“舒服”的集成方式。

混编方案

方案考量

如果直接采用 Flutter 工程结构来作为日常开发，那这部分 Native 开发也需要配置Flutter环境, 相当程度的了解 Flutter 一些技术，成本比较大。

同时如果工程耦合，对于开发过程也是很难受的

基于以上两点思考，针对 Android iOS 有如下方案：

Android

先看下官方的集成方式：

# setting.gradle

setBinding(new Binding([gradle: this]))

evaluate(new File(

'../managementcenter/.android/include_flutter.groovy'

))

# build.gradle

dependencies {

implementation project(':flutter')

...........

}

这种方式使得工程强耦合，虽然便于开发调试，但是违背了第一点，大多数 native 同学都需要配置 Flutter 环境, 成本很大。

iOS

官方 iOS 混编方案简介

在native项目Podfile中通过 eval binding特性注入 podhelper.rb脚本，在pod install/update 时执行此脚本，脚本主要处理：

Pod本地依赖Flutter引擎(Flutter.framework) 与Flutter插件注册表(FlutterPluginRegistrant)

Flutter插件通过flutter packages get指令安装后生成的 .flutter-plugins文件解析，然后Pod本地依赖所有的插件

在pod install执行完的钩子 post_install中，获取当前pod target工程对象，导入 Generated.xcconfig配置，其中都为环境变量的配置，主要为后续的xcode_backend.sh脚本执行做准备

在构建阶段Build Phases中注入构建是需要执行的xcode_backend.sh脚本，脚本主要完成Flutter产物的构建并将其添加到对应的native工程中去，后续会进一步介绍此脚本

优点

无缝开发，配置好后就可以只在 Flutter 工程内进行业务开发，无缝同步到 native 工程中

不需要单独拆分组件，免去管理组件的版本及发布成本

缺点

非常耦合，需要修改原有 native 工程配置，需要添加特定脚本去编译 Flutter

需要修改原有 pod 的 xcconfig 配置

所有团队开发成员都必须要配置 Flutter 开发环境才能编译成功

小结

基于以上思考，同时考虑到某个 Flutter 业务模块可能会引入到不同的 App 中，同时考虑到某个业务实现方式方面的解耦(某个业务可能用 native, flutter, weex 开发)，有以下方案(中间产物库每个 Flutter 业务模块都是独立的)：

Android：

iOS:

Flutter产物结构

Android

iOS