Flutter在混合项目中的构建和集成

写在前头

在之前的一篇文章《Flutter的探索与实践》中关于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工程运行调试。