环境

• Flutter：v1.9.1-hotfixes
• FlutterBoost：0.1.61

背景

Flutter可以算是当下最火热的新技术之一，我现在所在团队也准备将Flutter技术应用到线上工程中。
关于混合工程，官方文档其实写的已经比较清楚了，按着文档走一般问题不大，

文档：将 Flutter module 集成到 Android 项目

但是有一点值得注意的是，Flutter工程引入的库的gradle的buildTypes要与原工程保持一致，如果不一致需要手工添加。

进入正题，现在Flutter官方默认只提供armeabi-v7a、arm64-v8a、x86和x86-64，其中x86和x86-64是为模拟器准备的。目前我们使用的SDK大部分只使用了armeabi架构，直接使用我们会遇见找不到libflutter.so，libapp.so的情况，所以我们需要对FlutterSDK做一定的改造。

armeabi 适配

首先我们要了解下Flutter编译产物，因为不同版本产物是不同的，这里我们只针对Flutter 1.9.1-hotfixes来说。除了资源文件之外，Flutter打包会生成两个非常重要的so库，他们分别是libflutter.so，libapp.so。其中libflutter.so是Flutter的SDK产物而libapp.so正是我们编写的dart文件的产物。默认情况下，这两个文件都会出现在armeabi-v7a中，因此我们要作出对应的改造。

libflutter.so与libapp.so

libflutter.so

libflutter.so位于FlutterSDK中，这里顺带提一句，除了这对不同CPU架构，它还分为Debug版和Release版，它们的区别在于Debug是为JIT编译方式打造的，体积较大而Release是为AOT编译方式打造的，体积很小。对libflutter.so的改造，只要将其移动文件路径即可，运行以下脚本即可，此脚本来自美团分享的Flutter文章。

cd $FLUTTER_ROOT/bin/cache/artifacts/engine
for arch in android-arm android-arm-profile android-arm-release; do
  pushd $arch
  cp flutter.jar flutter-armeabi-v7a.jar # 备份
  unzip flutter.jar lib/armeabi-v7a/libflutter.so
  mv lib/armeabi-v7a lib/armeabi
  zip -d flutter.jar lib/armeabi-v7a/libflutter.so
  zip flutter.jar lib/armeabi/libflutter.so
  popd
done

libapp.so

移动完了libflutter.so之后我们打包发现，libapp.so仍然会出现在armeabi-v7a中，所以第二部我们就是移动libapp.so。这个需要更改flutter.gradle，我们在flutter.gradle的45行可以看到如下定义，它定义了我们的环境。

class FlutterPlugin implements Plugin<Project> {
    // The platforms that can be passed to the `--Ptarget-platform` flag.
    private static final String PLATFORM_ARM32 = "android-arm";
    private static final String PLATFORM_ARM64 = "android-arm64";
    private static final String PLATFORM_X86 = "android-x86";
    private static final String PLATFORM_X86_64 = "android-x64";

    // The ABI architectures.
    private static final String ARCH_ARM32 = "armeabi-v7a";
    private static final String ARCH_ARM64 = "arm64-v8a";
    private static final String ARCH_X86 = "x86";
    private static final String ARCH_X86_64 = "x86_64";

    // Maps platforms to ABI architectures.
    private static final Map PLATFORM_ARCH_MAP = [
            (PLATFORM_ARM32) : ARCH_ARM32,
            (PLATFORM_ARM64) : ARCH_ARM64,
            (PLATFORM_X86)   : ARCH_X86,
            (PLATFORM_X86_64): ARCH_X86_64,
    ]

在524行我们可以看到，abiValue的取值就是根据上述定义值。

 def compileTasks = targetPlatforms.collect { targetArch ->
                String abiValue = PLATFORM_ARCH_MAP[targetArch]
                String taskName = toCammelCase(["compile", FLUTTER_BUILD_PREFIX, variant.name, targetArch.replace('android-', '')])
                FlutterTask compileTask = project.tasks.create(name: taskName, type: FlutterTask) {
                ...

所以结论很简单，只要将

private static final String ARCH_ARM32 = "armeabi-v7a";

改为

private static final String ARCH_ARM32 = "armeabi";

就可以完成对与libflutter.so的移动。

aar打包

前期工作我们都做好了，打成aar就非常简单了
直接使用 flutter build aar --target-platform android-arm
打出来后可以解压检查下libflutter.so，libapp.so是否都在armeabi文件夹下即可。

FlutterBoost

说完了armeabi适配问题，这里下说下有关于有关于FlutterBoost的接入。这个东西接入有两点要注意。

Support库冲突

在主app内加上即可，常规操作，强制统一support包的版本号

 subprojects {
        //为了统一support包的版本号
        project.configurations.all {
            resolutionStrategy.eachDependency { details ->
                if (details.requested.group == 'com.android.support'
                        && !details.requested.name.contains('multidex') ) {
                    details.useVersion "27.1.0"
                }
            }
        }
    }

flutter.gradle编译报错

注释flutter.gradle第655行。因为编译过程中，会去初始化插件项目的buildType下面的debug配置，而插件项目下并未配置debug，导致报错。

 pluginProject.android.buildTypes {
        profile {
                initWith debug
                }
 }

总结

如果发现文章中有错误或者有更好的解决方案欢迎指正留言，当然如果本篇文章帮助你解决了问题，也不要吝啬你的感谢。谢谢各位。