Android上Flutter动态化设计与实践
Flutter作为一种跨平台的解决方案被越来越多的人认可，各种类型的Flutter应用也纷纷上线。作为一款成熟上线的App，能否在少干扰用户的情况下及时修复bug，快速让用户体验到新功能一直是开发人员的研究方向。考虑到iOS平台的限制以及目前团队的主要诉求是快速上线新设计，对平台要求不大，所以我们先在Android平台上做了产物动态化的尝试和实践。
方案设计
对于一个Flutter应用，动态化主要考虑三个部分：
Dart代码
Asset资源文件
Java代码
Flutter应用中Java代码的动态化方案和普通的Android应用中方案一致，目前已经有很多成熟的优秀框架，在此不再赘述。接下来将重点分析Flutter应用中如何动态化Dart代码及Dart代码中用到的本地资源文件。
Dart代码产物libapp.so
在Flutter 1.7.8版本之前release包中产物文件有assets/isolate_snapshot_data，assets/isolate_snapshot_instr，assets/vm_snapshot_data，assets/vm_snapshot_instr，而从1.7.8版本开始产物变成了libapp.so，同时支持了32位和64位架构同时打包。所以现在讨论动态化Dart代码产物实际上也就是讨论如何让Flutter应用加载动态下发的libapp.so包。
先来了解下Dart代码产物libapp.so是如何设置给底层使用的。查看FlutterActivty的onCreate方法：
public class FlutterActivity extends Activity implements Host, LifecycleOwner {protected void onCreate(@Nullable Bundle savedInstanceState) {......this.delegate = new FlutterActivityAndFragmentDelegate(this);this.delegate.onAttach(this);this.delegate.onActivityCreated(savedInstanceState);......}}
在FlutterActivityAndFragmentDelegate的onAttach方法中会对FlutterEngine做检查，未做特殊设置的情况下会走到构建FlutterEngine的流程，FlutterEngine的构造方法中会调用到flutterLoader.ensureInitializationComplete(context, dartVmArgs); ：
/io/flutter/embedding/engine/loader/FlutterLoader.java
public void ensureInitializationComplete( Context applicationContext, String[] args) {......List<String> shellArgs = new ArrayList<>();......if (args != null) {Collections.addAll(shellArgs, args);}String kernelPath = null;if (BuildConfig.DEBUG || BuildConfig.JIT_RELEASE) {......} else {shellArgs.add("--" + AOT_SHARED_LIBRARY_NAME + "=" + aotSharedLibraryName);shellArgs.add("--" + AOT_SHARED_LIBRARY_NAME + "=" + applicationInfo.nativeLibraryDir + File.separator + aotSharedLibraryName);}......FlutterJNI.nativeInit(applicationContext, shellArgs.toArray(new String[0]), kernelPath, appStoragePath, engineCachesPath);......}
重点看一下这个AOT_SHARED_LIBRARY_NAME参数，它取值为aotSharedLibraryName，默认值为libapp.so，也就是在这里将Dart代码产物libapp.so设置给了底层，注意这里AOT_SHARED_LIBRARY_NAME参数除了简单设置libapp.so值外，也支持设置so的完整路径：
applicationInfo.nativeLibraryDir + File.separator + aotSharedLibraryName在这里得到启发，如果把这个路径替换成动态下发下载到本地的so路径是不是就可以实现Dart代码产物动态化呢？后面我们经过探索和实践也证明了这个想法的可行性。
那现在的问题是如何去设置这个AOT_SHARED_LIBRARY_NAME参数呢，可以看到这个参数是拼接传递给了List<String> shellArgs这个局部变量，然后传递给了FlutterJNI去做初始化，外界并没有直接途径去更改shellArgs。但我们发现在设置AOT_SHARED_LIBRARY_NAME参数前，做了额外一些参数的插入：
if (args != null) {Collections.addAll(shellArgs, args);}
很自然的想到是不是可以利用这个args参数来重新设置AOT_SHARED_LIBRARY_NAME? 有了这个思路后，接下来有两个问题：
在args中设置AOT_SHARED_LIBRARY_NAME参数会不会被之后的
shellArgs.add("--" + AOT_SHARED_LIBRARY_NAME + "=" + aotSharedLibraryName)覆盖掉？如何在args中设置AOT_SHARED_LIBRARY_NAME参数？
验证加载顺序
先来看第一个问题，查看FlutterJNI.nativeInit对应的底层源码，根据flutter_main.cc中的Register方法，可以看到FlutterJNI.nativeInit方法对应到了Init方法：
/shell/platform/android/flutter_main.cc
bool FlutterMain::Register(JNIEnv* env) {static const JNINativeMethod methods[] = {{.name = "nativeInit",.signature = "(Landroid/content/Context;[Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V",.fnPtr = reinterpret_cast<void*>(&Init),},......};jclass clazz = env->FindClass("io/flutter/embedding/engine/FlutterJNI");......}
Init方法中将外界传入的参数（对应到Java层的shellArgs）进行解析，构建Settings对象，并将我们Java层设置的AOT_SHARED_LIBRARY_NAME参数传递给setting.application_library_path，然后settings.application_library_path会被作为native_library_path参数传递给SearchMapping方法：
/runtime/dart_snapshot.cc
static std::shared_ptr<const fml::Mapping> SearchMapping(MappingCallback embedder_mapping_callback,const std::string& file_path,const std::vector<std::string>& native_library_path,const char* native_library_symbol_name,bool is_executable) {......for (const std::string& path : native_library_path) {auto native_library = fml::NativeLibrary::Create(path.c_str());auto symbol_mapping = std::make_unique<const fml::SymbolMapping>(native_library, native_library_symbol_name);if (symbol_mapping->GetMapping() != nullptr) {return symbol_mapping;}}......return nullptr;}
看一下这里对native_library_path的查找过程，遍历列表找到对应值就返回。这就回答了我们之前提到的第一个问题，在FlutterLoader的ensureInitializationComplete方法参数args中设置AOT_SHARED_LIBRARY_NAME参数是会优先被查找的，而不会被之后的shellArgs.add("--" + AOT_SHARED_LIBRARY_NAME + "=" + aotSharedLibraryName);覆盖掉。
如何设置libapp.so的路径
那接下来看第二个问题，如何在ensureInitializationComplete参数args中加入AOT_SHARED_LIBRARY_NAME来指定动态化下发的Dart代码产物即libapp.so路径？
FlutterActivity.java中有一个getFlutterShellArgs方法：
io/flutter/embedding/android/FlutterActivity.java
public class FlutterActivity extends Activity implements FlutterActivityAndFragmentDelegate.Host,LifecycleOwner{......public FlutterShellArgs getFlutterShellArgs() {return FlutterShellArgs.fromIntent(getIntent());}}
跟踪发现这里的FlutterShellArgs会作为参数传递给FlutterEngine构造方法，并在构造方法中传递给FlutterLoader的ensureInitializationComplete方法。
所以我们只需要重写FlutterActivity的getFlutterShellArgs方法，包装上AOT_SHARED_LIBRARY_NAME参数，即可指定libapp.so的路径。
Assets资源文件
Flutter应用中除了Dart代码资源，另外一部分经常需要更新的是Dart中用到的本地图片资源。简单回顾一下Flutter中如何加载本地图片：
创建存放图片资源的文件目录比如images，根据需要在此目录下创建Nx文件夹，比如2.0x，3.0x等，并放入需要的图片如icon.png
在pubspec.yaml中配置资源目录，现在已经支持配置整个文件夹
flutter:assets:- images/代码中使用
Image.asset("images/icon.png")来加载图片资源
要找到动态化图片资源的方法，先了解下通过Image.asset是如何加载出本地图片资源的，跟踪代码
image.asset->AssetImage->AssetBundleImageProvider->AssetBundleImageKey->PlatformAssetBundle看一下load方法：
/services/asset_bundle.dart
class PlatformAssetBundle extends CachingAssetBundle {Future<ByteData> load(String key) async {final Uint8List encoded = utf8.encoder.convert(Uri(path: Uri.encodeFull(key)).path);final ByteData asset =await defaultBinaryMessenger.send('flutter/assets', encoded.buffer.asByteData());if (asset == null)throw FlutterError('Unable to load asset: $key');return asset;}}
可以看出Flutter加载本地图片资源其实最终是通过BinaryMessager通知给了Platform，对应的channel名字为flutter/assets，message通常为1）AssetManifest.json 2)资源名，如 image/3.0x/icon.png （注意这里是处理过的资源名，而非代码中的原始参数值image/icon.png）。
AssetManifest.json是自动生成的文件，以json结构的形式描述了asset资源信息，在apk包中路径为 assets/flutter_assets/AssetManifest.json。对于message为AssetManifest.json的情况，flutter/assets这个channel和Platform通信是为了获取AssetManifest.json中资源项，可以断点看一下这种情况下获取到的map结构内容：
获取到AssetManifest.json中的所有资源结构后，通过painting/image_resolution.dart中的_chooseVariant方法将原始的资源名image/icon.png根据当前设备的像素密度匹配出合适的资源名chosenName: image/3.0/icon.png：
final String chosenName = _chooseVariant(keyName, configuration,manifest == null ? null : manifest[keyName], );然后根据这个chosenName再次调用PlatformAssetBundle的load方法，利用flutter/asset这个channel通知给Platform去取对应资源。那Platform对应的channel收到请求后是怎么取资源的呢？先看一下消息接收：
/shell/common/engine.cc
static constexpr char kAssetChannel[] = "flutter/assets";void Engine::HandlePlatformMessage(fml::RefPtr<PlatformMessage> message) {if (message->channel() == kAssetChannel) {HandleAssetPlatformMessage(std::move(message));} else {delegate_.OnEngineHandlePlatformMessage(std::move(message));}}
收到flutter/assets这个channel发来的消息后，调用HandleAssetPlatformMessage -> asset_manager_的GetAsMapping(asset_name) 方法：
engine/src/flutter/shell/platform/android/apk_asset_provider.cc
std::unique_ptr<fml::Mapping> APKAssetProvider::GetAsMapping(const std::string& asset_name) const {std::stringstream ss;ss << directory_.c_str() << "/" << asset_name;AAsset* asset =AAssetManager_open(assetManager_, ss.str().c_str(), AASSET_MODE_BUFFER);if (!asset) {return nullptr;}return std::make_unique<APKAssetMapping>(asset);}
重点注意这里的AAssetManager_open方法。在Android ndk api level 9之后，提供了一套称为AssetManager的api，这个api核心是通过JNI将Android端getAssets得到的AssetManager传递给c层，c层通过传过来的这个AssetManager对象可以操作Assets资源，这里涉及到的方法
AAsset * AAssetManager_open( AAssetManager *mgr, const char *filename, int mode)作用是读取对应名称的asset资源。
至此，可以明确Image.asset('images/icon.png')方法底层实际上是通过Platform的AssetManager对象去获取对应的图片资源。
结合之前Android项目中资源动态化经验，反射使用AssetManager的addAssetPath方法即可设置指定的asset资源目录，核心代码如下：
AssetManager assetManager = context.getAssets();Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class);addAssetPath.setAccessible(true);addAssetPath.invoke(assetManager, downloadAssetPath);
在实际的Asset动态化实践中，踩过几个坑：
context.getAssets()获取AssetManager时，这个context需要使用FlutterActivity而不要使用Application。因为传递给c底层的是FlutterActivity对应的AssetManager。不能保证各机器上这两个context是同一个对象。
addAssetPath方法传递参数直接设置压缩包路径就行，如果设置成解压路径，在华为荣耀9青春版等机器上资源会加载失败。
下发资源包中带上AssetManifest.json，如之前分析，Flutter会根据这个文件来匹配最合适当前像素密度的图片尺寸。
下发资源包中带上AndroidManifest.xml，因为addAssetPath方法底层会去校验是否有AndroidManifest.xml文件，如果没有则会添加资源路径失败，导致动态化下发的图片加载失败（motorola XT1581 Android5.1.1）。
实践
根据以上分析，在Android上的Flutter项目动态化产物组成如下图（目前只讨论Dart代码和资源的动态化，如需要Java代码相关，可参考目前成熟的Android热修复框架）：
来试验一下实际效果吧~
动态化前，假设apk包为app-old.apk：
将底部tab的icon换成新添加的images/icon.png，修改tab文案，然后打包成app-new.apk。脚本比对app-new.apk和app-old.apk中的资源差异，提取有变化的资源项，结合app-new.apk中的AssetManifest.json，AndroidManifest.xml以及新的libapp.so，组成动态化产物包bundle.zip。对app-old.apk版本下发bundle.zip，解压校验成功后，加载新的libapp.so文件并添加新的asset路径，即可在无需进行app版本升级的情况下更新用户体验。动态化效果如下：
可以看到底部第一个tab的icon和文案已经被成功替换了。
总结
这个方案简单易处理，但弊端也很明显，动态化产物的包体积会比较大，有点浪费用户流量。所以，在这个方案基础上做进一步优化，可以将产物做差分以减小产物包体积。目前微信的Tinker方案已经很成熟了，而且也支持对so的差分。了解了Android上Flutter应用动态化原理后，再结合Tinker方案思路，就可以很方便的使用Tinker做Flutter的动态化了。接入Tinker后，下发包体积大小有很明显的减少。
关于Android上Flutter应用动态化的设计和实践就介绍到这里。