<>写在前头
在之前的一篇文章《Flutter的探索与实践》 <https://juejin.im/post/5ba9a74ce51d450e99432608>
中关于Flutter如何构建到现有项目这一节没有详细说,这篇文章将会介绍Flutter在混合项目中的构建和集成方面踩过的坑以及解决方案。
<>目标
扇贝现有的项目是原生混合React
Native,并且是以组件化的架构存在,现在想在一些页面上用Flutter进行重构,想要在新的Flutter项目上集成以前的所有代码肯定是不现实的,同时又不想将Flutter项目直接侵入到我们的项目结构中去,于是我们选择将重构好的Flutter代码单独编译成aar,以组件的形式被主工程依赖。
这样做的好处是显而易见的:
对Flutter进行探索开发的同学可以在自己的Flutter工程内编写dart代码,独立运行调试,发布版本的时候打包成aar集成到主工程中让写native代码的同学接入,两方可以协同工作,不会产生耦合。
<>探索过程
下面的构建和集成是以Android项目为例。
首先用Android Studio或者命令行新建一个Flutter Application项目。
得到如下项目结构
在命令行输入命令flutter build apk
会编译生成apk文件,位于build/app/outputs/apk/release/文件夹下。
将apk解压缩后就可以看到里面的结构组成。
这个apk里的产物实际上是在Android的app/build.gradle构建代码里引入了Flutter的构建代码。
apply from: "$flutterRoot/packages/flutter_tools/gradle/flutter.gradle"
通过阅读flutter构建源码我们发现在构建apk文件的时候,会将需要的文件构建到apk中。
<>1.assets文件夹
assets文件夹下面有flutter_assets文件夹、flutter_shared文件夹、isolate_snapshot_data、isolate_snapshot_instr、vm_snapshot_data、vm_snapshot_instr文件。
* flutter_assets里是flutter工程产生的assets文件
* flutter_shared里是封装在flutter.jar里面的处理字符编码的ICU库
*
isolate_snapshot_data、isolate_snapshot_instr、vm_snapshot_data、vm_snapshot_instr为特定平台的数据和指令
<>2.lib文件夹
lib文件夹下是特定平台(arm或者x86)的so文件。
flutter在Android平台下会默认生成arm-v7架构的的so库,flutter.gradle源码中会根据target-platform
属性判断平台动态生成对应的so,官方注释目前flutter只支持在debug模式下生成x86的so。
扇贝应用集成了一部分三方的so库,而且只选用了arm架构的so库,x86的设备只占到1%左右,因此下面的操作都是默认为arm架构。对需要x86
so的同学下文会做说明。
<>抽取aar
上面通过编译命令得到了apk,那想要打包成aar,理论上只要把app/build.gradle中的apply plugin:
'com.android.application'修改为apply plugin: 'com.android.library',同时删除
applicationId "com.shanbay.flutterapp"再次执行flutter build apk命令,便可以得到
app-release.aar文件。
<>集成到现有项目
我们将得到的aar文件集成到现有的Android工程中供native的小伙伴使用,但是打开flutter页面却闪退了,同时flutter报出了error,错误是说aar里面缺少icudtl.dat文件。
解压缩aar查看文件结构,可以发现其中的问题。
在aar文件夹下的assets里面缺少了flutter_shared文件夹,icudtl.dat文件正是在该文件夹里面,也就是说flutter.gradle在编译流程中并没有将icudtl.dat文件打进aar包里面,这一点从flutter库的issue里面得到了证实,我们的办法是将apk里面得到的flutter_shared文件夹手动copy到flutter工程中,再次编译aar,这样就可以得到有icudtl.dat的aar文件。再次集成到Android项目中便可以成功运行,不会产生错误。
<>总结
这个方案需要两个步骤,第一步是先编译成apk取得icudtl.dat文件放入到工程中,第二步修改apply plugin:
'com.android.library'再次编译取得aar。
<>优点
*
完全依赖flutter自己的编译流程,不会对其源码进行修改,侵入flutter编译流程,定制化的成分较少,适用于绝大部分场景,同时随着flutter更新,需要对这套流程做修改的可能性也比较小。
* 可以直接接入CI系统,最小修改。
* 在android工程中可以编写sample代码,通过flavor构建在release aar时移出sample代码,不需要另外建立host工程运行调试。
热门工具 换一换