環(huán)境

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

背景

Flutter可以算是當下最火熱的新技術(shù)之一，我現(xiàn)在所在團隊也準備將Flutter技術(shù)應用到線上工程中。
關(guān)于混合工程，官方文檔其實寫的已經(jīng)比較清楚了，按著文檔走一般問題不大，

文檔：將 Flutter module 集成到 Android 項目

但是有一點值得注意的是，F(xiàn)lutter工程引入的庫的gradle的buildTypes要與原工程保持一致，如果不一致需要手工添加。

進入正題，現(xiàn)在Flutter官方默認只提供armeabi-v7a、arm64-v8a、x86和x86-64，其中x86和x86-64是為模擬器準備的。目前我們使用的SDK大部分只使用了armeabi架構(gòu)，直接使用我們會遇見找不到libflutter.so，libapp.so的情況，所以我們需要對FlutterSDK做一定的改造。

armeabi 適配

首先我們要了解下Flutter編譯產(chǎn)物，因為不同版本產(chǎn)物是不同的，這里我們只針對Flutter 1.9.1-hotfixes來說。除了資源文件之外，F(xiàn)lutter打包會生成兩個非常重要的so庫，他們分別是libflutter.so，libapp.so。其中libflutter.so是Flutter的SDK產(chǎn)物而libapp.so正是我們編寫的dart文件的產(chǎn)物。默認情況下，這兩個文件都會出現(xiàn)在armeabi-v7a中，因此我們要作出對應的改造。

libflutter.so與libapp.so

libflutter.so

libflutter.so位于FlutterSDK中，這里順帶提一句，除了這對不同CPU架構(gòu)，它還分為Debug版和Release版，它們的區(qū)別在于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之后我們打包發(fā)現(xiàn)，libapp.so仍然會出現(xiàn)在armeabi-v7a中，所以第二部我們就是移動libapp.so。這個需要更改flutter.gradle，我們在flutter.gradle的45行可以看到如下定義，它定義了我們的環(huán)境。

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的取值就是根據(jù)上述定義值。

 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) {
                ...

所以結(jié)論很簡單，只要將

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適配問題，這里下說下有關(guān)于有關(guān)于FlutterBoost的接入。這個東西接入有兩點要注意。

Support庫沖突

在主app內(nèi)加上即可，常規(guī)操作，強制統(tǒng)一support包的版本號

 subprojects {
        //為了統(tǒng)一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
                }
 }

總結(jié)

如果發(fā)現(xiàn)文章中有錯誤或者有更好的解決方案歡迎指正留言，當然如果本篇文章幫助你解決了問題，也不要吝嗇你的感謝。謝謝各位。