Flutter混合开发框架（二）——FlutterEngineGroup使用及原理分析

前序

要解决的问题以及现在的常用解决方案就不再详细叙述，主要就是要做混合开发这件事。

背景

FlutterEngineGroup是由官方推出的Flutter+Native混合开发解决方案，与FlutterBoost不同的是，使用的是多引擎的处理方式，并优化了每个引擎的大小以及数据处理方式，让大部分数据实现共享，只有部分生命周期等内容做了隔离。

实现方式

相较于单Engine形式，多Engine无需关心页面栈等问题，但新增了一个问题，就是多Engine中的数据共享。

多Engine的方式，如果我们自己设计，那需要解决一下三个重点问题：
1、Engine 资源共享
2、与Native的数据传递方式
3、native插件的调用方式

2、3问题可以看做是同一个问题，有两种不同的实现，一种是每个Engine对应一个Native Channel，另一张是对于Native只对应一个Native Channel，明显第二种方法更能直接解决问题，一会儿我们可以看一下FlutterEngineGroup是如何做的。

Engine资源共享

为什么要做共享

如果不共享数据空间，每个Engine的资源独立，Flutter页面间的信息同步以及全局变量的响应都会变得很麻烦。

处理方式

1、多Engine的数据共享，开发者经常用的是通过Native进行中转，大部分的数据内容都可以存在于Native中，然后由Native发起数据同步，实现方案也比较简单直接
2、为所有Engine做一个数据缓存池，不同Engine的数据直接与缓存池中数据同步。最大的问题在于多Engine意味着多线程，数据同步时需要考虑线程安全问题。

接下来我们看一下Flutter Engine Group究竟是如何实现的。

具体实现

    if (activeEngines.size() == 0) {
      engine = createEngine(context);
      engine.getDartExecutor().executeDartEntrypoint(dartEntrypoint);
    } else {
      engine = activeEngines.get(0).spawn(context, dartEntrypoint);
    }
    
    private native FlutterJNI nativeSpawn(
      long nativeSpawningShellId,
      @Nullable String entrypointFunctionName,
      @Nullable String pathToEntrypointFunction);

// Signature is similar to RunBundleAndSnapshotFromLibrary but it can't change
// the bundle path or asset manager since we can only spawn with the same
// AOT.
//
// The shell_holder instance must be a pointer address to the current
// AndroidShellHolder whose Shell will be used to spawn a new Shell.
//
// This creates a Java Long that points to the newly created
// AndroidShellHolder's raw pointer, connects that Long to a newly created
// FlutterJNI instance, then returns the FlutterJNI instance.
static jobject SpawnJNI(JNIEnv* env,
                        jobject jcaller,
                        jlong shell_holder,
                        jstring jEntrypoint,
                        jstring jLibraryUrl) {
  jobject jni = env->NewObject(g_flutter_jni_class->obj(), g_jni_constructor);
  if (jni == nullptr) {
    FML_LOG(ERROR) << "Could not create a FlutterJNI instance";
    return nullptr;
  }

  fml::jni::JavaObjectWeakGlobalRef java_jni(env, jni);
  std::shared_ptr<PlatformViewAndroidJNI> jni_facade =
      std::make_shared<PlatformViewAndroidJNIImpl>(java_jni);

  auto entrypoint = fml::jni::JavaStringToString(env, jEntrypoint);
  auto libraryUrl = fml::jni::JavaStringToString(env, jLibraryUrl);

  auto spawned_shell_holder =
      ANDROID_SHELL_HOLDER->Spawn(jni_facade, entrypoint, libraryUrl);

  if (spawned_shell_holder == nullptr || !spawned_shell_holder->IsValid()) {
    FML_LOG(ERROR) << "Could not spawn Shell";
    return nullptr;
  }

  jobject javaLong = env->CallStaticObjectMethod(
      g_java_long_class->obj(), g_long_constructor,
      reinterpret_cast<jlong>(spawned_shell_holder.release()));
  if (javaLong == nullptr) {
    FML_LOG(ERROR) << "Could not create a Long instance";
    return nullptr;
  }

  env->SetObjectField(jni, g_jni_shell_holder_field, javaLong);

  return jni;
}

总体来讲步骤很简单，就是使用了shell_holder生成了一个新的shell在处理后续的记载等。

结论

FlutterEngineGroup依旧使用的是第一种处理方式实现数据同步的。总结原因应该是由于第二种实现方案对于引擎的改造过大，同步机制也有有较大变化，从个人角度出发还是比较期待第二种实现方案。
当前方案，对于数据生命周期与页面生命周期不一致时，即多页面使用相同数据等场景，无法支持，只能通过Native Channel进行数据同步。这就需要约束相关开发者，页面就是一个APP，全局变量等内容只能由Native去做。

问题2 和 问题3的解决方式

由刚才的实现逻辑可以看出，每个Engine独立一个Method Channel进行与Native的交互。

    fun attach() {
        DataModel.instance.addObserver(this)
        channel.invokeMethod("setCount", DataModel.instance.counter)
        channel.setMethodCallHandler { call, result ->
            when (call.method) {
                "incrementCount" -> {
                    DataModel.instance.counter = DataModel.instance.counter + 1
                    result.success(null)
                }
                "next" -> {
                    this.delegate.onNext()
                    result.success(null)
                }
                else -> {
                    result.notImplemented()
                }
            }
        }
    }

在每次Activity启动时，重新注册一次对应的Channel方法。

总结

FlutterEngineGroup的方案，感觉比较仓促，相当于只是简单的把Engine每次启动的内容变少了，而数据共享等问题没有得到实现。这就导致单独Flutter环境无法适配数据生命周期比页面生命周期长的情况，需要Native来做桥接。