1. 加载流程分析
flutter sdk版本：v3.0.3
dart版本：v2.17.5
1.1 FlutterApplication启动流程
按照安卓原生启动流程，当继承FlutterApplication且在AndroidManifest.xml将application:name设置后，除Content Provider初始化，Application流程将首先执行，此时FlutterApplication代码如下：
FlutterApplication的onCreate只执行了FlutterLoader类下的startInitialzation，并把自己作为Context传入。
FlutterLoader对于startInitialzation有多个重载方法，此时将调用其中一个重载方法，并且生成了一个Settings传入。
这时能看见startInitialization(@NonNull Context applicationContext, @NonNull Settings settings)才是实际执行的方法，方法前半段限制了该方法只能运行在主线程，如运行在非主线程则直接抛出异常。
新建了一个initTask的Callable类型的回调，并提交给了线程池执行。此时可以看见flutterJni.loadLibrary()，这里就是在加载libflutter.so，flutterJni该成员变量是FlutterInjector.instance()生成单例时，通过工厂+建造者生成的一个实例。
initResultFuture将作为线程任务执行的结果进行返回。
这说明了FlutterApplication执行过程中，最重要的就是在子线程中System.loadLibrary("flutter")，并且在线程执行完成后生成了initResultFuture，提供给后续操作。
1.2 FlutterActivity启动流程
如果已继承FlutterActivity作为LaunchActivity，且没有设置自定义的Application，将不会执行1.1的流程。
FlutterActivity时序图如下所示：
（下图出自得物技术专栏，链接：Flutter启动流程分析之插件化升级探索_configureflutterengine_得物技术的博客-CSDN博客）
通过FlutterAcitivity的onCreate可以得知，大部分操作全部放在FlutterActivityAndFragmentDelegate中进行（代理模式）。
deletegate.onAttach将自己注入到方法。此时由于成员变量flutterEngine必定为空，则执行setupFlutterEngine()。
进入setupFlutterEngine方法，此时可以通过getCachedEngineId，从FlutterEngineCache.getInstance()的map中，取出已经生成的flutterEngine实例，getCachedEngineId(）方法具体实现在FlutterActivity。这里说明在FlutterActivity启动前预生成，可以有效减少onCreate()的时间。
当Cache和FlutterActivity子类中，都没有提供FlutterEngine时，将自己生成一个FlutterEngine，其参数将通过FlutterActivity子类提供。此时可以发现，通过FlutterActivity自动生成的Engine，automaticallyRegisterPlugins默认是为false的，这说明了此时需要手动注册插件，在预生成的Engine中可以设置为true。
通过FlutterEngine的构造方法，可以看见此时和FlutterApplication相似，生成了FlutterInjector的单例、flutterJni实例，并且初始化DartExecutor，生成了名为"flutter/isolate的channel，最后flutterJni与该executor的messager进行绑定。
此时由于flutterJni还未与Engine绑定，必定会执行FlutterLoader的startInitialzation方法，具体逻辑1.1中已经介绍。
之后将调用ensureInitialzationComplete的方法。
该方法执行必定要在主线程中执行，且Settings不能为空。
此时可以发现，initResultFuture.get将挂起线程，并等待startInitialzation方法中执行的子线程结果后，才会继续向下执行。
这时定义了一个shellArgs，用于存放执行dart vm时携带的参数，并且可以将外部的args传入。
此时可以通过vm的参数，发现JIT和AOT将加载不同的产物：
共同加载：libflutter.so
JIT：vm_snapshot_data、isolate_snapshot_data、kernel_blob.bin
AOT：libapp.so、libvmservice_snapshot.so（Profile)
在AOT的代码段，注释：
// Most devices can load the AOT shared library based on the library name
// with no directory path. Provide a fully qualified path to the library
// as a workaround for devices where that fails.
这里说明了当第一段
"--" + AOT_SHARED_LIBRARY_NAME + "=" + flutterApplicationInfo.aotSharedLibraryName 路径加载不到库时，将自动加载第二段绝对路径
"--"
+ AOT_SHARED_LIBRARY_NAME
+ "="
+ flutterApplicationInfo.nativeLibraryDir
+ File.separator
+ flutterApplicationInfo.aotSharedLibraryName
此时可以推断，"--" + AOT_SHARED_LIBRARY_NAME + PATH，当加载成功库，将不再执行同参数的后续加载。
最后将用flutterJni.init将参数传递给nativeInit的jni映射方法中，在jni层启动.
进入Jni层，可以通过flutter_main.cc文件下的Jni方法映射，找到实际引用的函数引用Init。
在Init方法中，将java层传输过来的args，增加了名叫flutter的参数
然后通过SettingsFromCommandLine生成了Settings类
Settings类中大部分都是作为设置的逻辑，在SettingsFromCommandLine方法中可以找到，aot_shared_library_name为数组，说明可以同时存在多个路径。
并且全部存到Settings类的application_library_path中。
通过注解：
// Path to a library containing the application's compiled Dart code.
// This is a vector so that the embedder can provide fallback paths in
// case the primary path to the library can not be loaded.
可以得知，该属性将作为默认加载路径无法加载后的备选路径。
通过dart vm的生命周期，dart_vm.cc文件中，Create方法会调用DartVMData的Create方法。
dart_vm_data.cc文件中的Create方法，将调用IsoSnapshotFromSettings函数，该函数中会调用SearchMapping函数。
SearchMapping函数中表明了会根据Path查找NativeLibrary，并且查找native_library_symbol_name符号名，如果查找到，则不会继续查找。此时可以证明只要Engine源码中，不改变该符号名的名称，则AOT产物替换加载方案为可行。
2. 热更新Android方案
根据加载流程分析来看，如果不修改jni代码，仅仅在java层进行改动，主要是在FlutterApplication与FlutterActivity上进行hook，将对于libapp.so的加载地址进行修改。
2.1 对于FlutterApplication的Hook
由1.1分析可以得出，FlutterApplication执行过程中，已经对于FlutterLoader进行了初始化，此时FlutterLoader的flutterInfoApplication属性已经填充了值，此时可以执行之后，使用Reflect替换掉flutterInfoApplication里的内容，将FlutterActivity加载库的地址指向新的文件地址即可。
方案1：
描述：继承FlutterApplication，修改flutterInfoApplication的aotSharedLibraryName属性
侵入性：中
结果：无效
原因：
1.原flutterApplicationInfo的nativeLibraryDir指向的是/data/app，只读不可写权限且属于私有文件目录，无法移动下载的补丁文件到nativeLibraryDir的路径下。
2.如将aotSharedLibraryName的绝对路径，通过../强制转成补丁文件目录，会触发jni路径检查错误。
错误信息如下：
library "/storage/emulated/0/Android/data/packagename/files/Download/-712256458372815974.so" ("/storage/emulated/0/Android/data/packagename/files/Download/-712256458372815974.so") needed or dlopened by "/data/app/~~F_tPgp6PDbt9Ug0opdFRsg==/packagename-W65G60j2V9GbWfwGQd_upw==/lib/arm64/libflutter.so" is not accessible for the namespace: [name="classloader-namespace", ld_library_paths="", default_library_paths="/data/app/~~F_tPgp6PDbt9Ug0opdFRsg==/packagename-W65G60j2V9GbWfwGQd_upw==/lib/arm64:/data/app/~~F_tPgp6PDbt9Ug0opdFRsg==/packagename-W65G60j2V9GbWfwGQd_upw==/base.apk!/lib/arm64-v8a", permitted_paths="/data:/mnt/expand:/data/data/packagename"]
从Log中可以看见libflutter.so文件对于加载的路径，除了default_library_paths的，还有/data:/mnt/expand:/data/data/packagename 这2个路径。
方案2:
描述：继承FlutterApplication，修改flutterInfoApplication的aotSharedLibraryName、nativeLibraryDir属性
侵入性：中
结果：无效
原因：原flutterApplicationInfo的nativeLibraryDir指向的是/data/app，只读不可写权限且属于私有文件目录，如将libflutter.so转移到公共目录，成本过高。且公共目录会出现jni路径检查错误。具体原因可见方案1。
2.2 对于FlutterActivity的Hook
由1.2分析可以得出，即使onCreate执行后，也不能完全保证flutterApplicationInfo的属性被填充，必须等到子线程完成后才会注入数据，所以不可以通过2.1的操作，对于flutterApplicationInfo通过反射注入自定义路径。
通过1.2分析startInitialzationComplete方法，可以得出，FlutterActivity的args参数，可以被传入到方法中，与方法内的参数进行合并，并传入到jni层。并且此时注入到args的路径，必定顺序在源代码定义lib加载路径之前，由此可以得出自定义路径可以替代原路径进行加载。
方案1:
描述：继承FlutterActivity，重写getFlutterShellArgs方法，使得vm args中加入一条指向新文件的路径
侵入性：低
结果：有效
原因：通过1.2分析表明，jni层在根据路径查找so文件时，如果查找到文件，且符号名正确，将不会继续查找，所以修改getFlutterShellArgs传入自定义的文件路径，可以完成热更新的操作。
注意：此时当下载到新文件时，必须将新文件从公共路径（转移/写入）到/data/user/0/packageName路径以下，由上面link的日志可以看出，/data/data路径是可允许的加载路径，而/data/data是/data/user/0的软连接，且data/user/0/packageName路径下是拥有可读可写权限的。
3.补丁下发方案设计
3.1补丁检查
方案1:
在登录账号时触发检测，通过登录时的接口来判定当时是否存在最新的补丁。
优点：结构简单
缺点：如app不关闭且不重新登录账号，则无法触发更新获取，时效性差。服务器无法保证即时通知到app进行更新。
流程图如下：
方案2:
在登录账号时建立长链接，通过服务器推送来判定是否存在补丁。
优点：即时性高，服务器可以确保补丁下发过程中状态是否正常。
缺点：结构复杂，依赖于长链接的是否稳定。
流程图如下：
3.2 版本管理
用户将上传自身的包版本、补丁包版本和包名。
补丁下发将存在2种模式：
1.全量下发
上传补丁后，将选择要发布的版本号，然后将上传补丁的分发至选择的版本号，如该版本用户本地补丁版本低于分发的补丁号，则将使用下发的补丁。
2.指定用户下发文章来源：https://www.toymoban.com/news/detail-470395.html
上传补丁后，将针对指定用户下发补丁。如该版本用户本地补丁版本低于分发的补丁号，则将使用下发的补丁。文章来源地址https://www.toymoban.com/news/detail-470395.html
到了这里，关于Flutter在Android上的热更新方案的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
