Flutter動態(tài)化-Android（一）
上篇我們講了flutter engine編譯環(huán)境搭建颠黎，這篇我們正式來看下如何修改flutter engine源碼，實現(xiàn)動態(tài)化滞项。
本篇文章將分為兩部分來講狭归，本篇講述有哪些核心代碼需要修改的，如何編譯engine源碼文判，以及在flutter應用中該如何使用过椎；下一篇會講解如何打包編譯成aar，以方便混合開發(fā)時使用戏仓。
一潭流、flutter engine核心代碼修改
思路：分析libapp.so和flutter_assets的加載過程，在加載之前修改源碼替換需要成自己的路徑
1.1柜去、FlutterLoader的ensureInitializationComplete
從前面的文章我們可以知道灰嫉，這個方法主要是構建shellArgs列表，在C層代碼中會調(diào)用此配置初始化參數(shù)
先看下面這段代碼：
if (BuildConfig.DEBUG || BuildConfig.JIT_RELEASE) {
String snapshotAssetPath =
PathUtils.getDataDirectory(applicationContext) + File.separator + flutterAssetsDir;
kernelPath = snapshotAssetPath + File.separator + DEFAULT_KERNEL_BLOB;
shellArgs.add("--" + SNAPSHOT_ASSET_PATH_KEY + "=" + snapshotAssetPath);
shellArgs.add("--" + VM_SNAPSHOT_DATA_KEY + "=" + vmSnapshotData);
shellArgs.add("--" + ISOLATE_SNAPSHOT_DATA_KEY + "=" + isolateSnapshotData);
}
在debug和JIT模式時會配置flutter_assets嗓奢、vm_snapshot_data讼撒、isolate_snapshot_data的位置，我們知道在libapp.so文件的本質(zhì)是相當于vm_snapshot_data股耽、isolate_snapshot_data的打包合集根盒，從這里我們可以找到想到將libapp.so和flutter_assets文件放到debug或者JIT模式時的文件路徑下，也就是PathUtils.getDataDirectory(applicationContext)目錄下物蝙。
我們再來看如何修改這個代碼對應的else部分的代碼：
// 查看/user/0/package/app_flutter目錄是否存在libapp.so文件炎滞，如果存在就傳遞這個新的路徑，否則就還使用默認路徑（也就是lib/arm/或者lib/arm64/）的libapp.so文件
File appFile = new File(PathUtils.getDataDirectory(applicationContext) + File.separator + aotSharedLibraryName);
String aotSharedLibraryPath = applicationInfo.nativeLibraryDir + File.separator + aotSharedLibraryName;
if(appFile.exists()){
aotSharedLibraryPath = appFile.getPath();
}
shellArgs.add("--" + AOT_SHARED_LIBRARY_NAME + "=" + aotSharedLibraryPath);
如果不需要動態(tài)替換flutter_assets文件诬乞，其實上面就修改就足夠動態(tài)替換libapp.so了册赛。還有一種不用修改engine源碼的方法就是在繼承FlutterActivity時重寫getFlutterShellArgs方法钠导，把AOT_SHARED_LIBRARY_NAME傳遞成自定義的路徑，親測有效森瘪，小伙伴們自行嘗試牡属，有問題可以在留言區(qū)交流。
附上AOT_SHARED_LIBRARY_NAME在C層使用的代碼
// 代碼位置shell-->common-->switches.cc
if (aot_shared_library_name.size() > 0) {
// 循環(huán)會導致最后一個shellArgs中AOT_SHARED_LIBRARY_NAME生效扼睬，不用擔心設置了多個AOT_SHARED_LIBRARY_NAME
for (std::string_view name : aot_shared_library_name) {
settings.application_library_path.emplace_back(name);
}
}
1.2逮栅、FlutterJNI的nativeAttach
這是一個調(diào)用
libflutter.so的jni方法，通過這個方法窗宇，我們可以傳遞一個路徑到C層措伐，在C層的初始化AndroidShellHolder之前將自定義的路徑配置進去
修改后的nativeAttach方法體以及相關代碼，如下
private native long nativeAttach(@NonNull FlutterJNI flutterJNI, String dynamicPath, boolean isBackgroundView);
public void attachToNative(String dynamicPath, boolean isBackgroundView) {
ensureRunningOnMainThread();
ensureNotAttachedToNative();
// 因為當前類中無法獲得Contenxt军俊，所以需要FlutterNativeView和FlutterEngine調(diào)用attachToNative方法時傳入路徑
nativePlatformViewId = nativeAttach(this, dynamicPath, isBackgroundView);
}
1.3废士、platform_view_android_jni.cc修改
// 1. jni映射方法新增參數(shù)類型
bool RegisterApi(JNIEnv* env) {
static const JNINativeMethod flutter_jni_methods[] = {
// Start of methods from FlutterJNI
{
.name = "nativeAttach",
// 新增一個String參數(shù)類型
.signature = "(Lio/flutter/embedding/engine/FlutterJNI;Ljava/lang/String;Z)J",
.fnPtr = reinterpret_cast<void*>(&AttachJNI),
},
。蝇完。官硝。
// 2. AttachJNI方法修改
static jlong AttachJNI(JNIEnv* env,
jclass clazz,
jobject flutterJNI,
jstring dynamicPath,
jboolean is_background_view) {
fml::jni::JavaObjectWeakGlobalRef java_object(env, flutterJNI);
const auto dynamic_path = fml::jni::JavaStringToString(env, dynamicPath);
// 獲取配置
Settings settings = FlutterMain::Get().GetSettings();
if(dynamic_path.size() > 0) {
settings.application_library_path.clear();
// 再AndroidShellHolder初始化前設置新路徑
settings.application_library_path.emplace_back(dynamic_path + "/libapp.so");
settings.assets_path = dynamic_path + "/flutter_assets";
}
FML_LOG(INFO) << "settings.assets_path:" << settings.assets_path;
// 將修改后的settings傳遞進去
auto shell_holder = std::make_unique<AndroidShellHolder>(
settings, java_object, is_background_view);
if (shell_holder->IsValid()) {
return reinterpret_cast<jlong>(shell_holder.release());
} else {
return 0;
}
}
1.4、FlutterNativeView中相關修改的代碼
private void attach(FlutterNativeView view, boolean isBackgroundView) {
mFlutterJNI.attachToNative(PathUtils.getDynamicPath(mContext), isBackgroundView);
dartExecutor.onAttachedToJNI();
}
1.5短蜕、FlutterEngine中相關修改的代碼
// 1. 構造函數(shù)中
attachToJni(context);
// 2. attachToJni方法修改
private void attachToJni(Context context) {
Log.v(TAG, "Attaching to JNI.");
// TODO(mattcarroll): update native call to not take in "isBackgroundView"
flutterJNI.attachToNative(PathUtils.getDynamicPath(context), false);
if (!isAttachedToJni()) {
throw new RuntimeException("FlutterEngine failed to attach to its native Object reference.");
}
}
1.6氢架、PathUtils新增getDynamicPath方法
// 獲取動態(tài)化資源文件路徑
public static String getDynamicPath(Context applicationContext){
String packagePath = getDataDirectory(applicationContext);
String aotLibFile = packagePath + File.separator + FlutterLoader.DEFAULT_AOT_SHARED_LIBRARY_NAME;
String flutterAssetsPath = packagePath + File.separator + FlutterLoader.DEFAULT_FLUTTER_ASSETS_DIR;
File aotFile = new File(aotLibFile);
File flutterAssetsFile = new File(flutterAssetsPath);
if (!aotFile.exists() && !flutterAssetsFile.exists()) {
packagePath = "";
}
return packagePath;
}
到此，動態(tài)化所需要的方法基本都修改完了朋魔，具體代碼請看https://github.com/panmin/engine/tree/feature_my_engine岖研，歡迎star和watch，代碼會不定期優(yōu)化更新警检。
二孙援、編譯本地engine
修改完engine的代碼，這一小節(jié)我們就來看看如何將修改后的engine編譯成
flutter.jar和libflutter.so
2.1扇雕、編譯相關基礎知識
-
CPU架構
編譯結果包括
arm拓售、arm64、x86這幾種架構镶奉，arm對應Android的armeabi-v7a础淤，arm64對應Android的arm64-v8a，x86還是x86一般是模擬器上用的哨苛。 -
是否優(yōu)化
未優(yōu)化的engine包是可以添加打印出C層的代碼的鸽凶，engine的C++里用
FML_LOG(INFO)打印log；優(yōu)化后的包體積也更小建峭。 -
運行模式
根據(jù)flutter的模式是分為
debug玻侥、profile、release這三種模式的亿蒸。
2.2凑兰、常用的編譯參數(shù)
-
--android-cpu: CPU架構掌桩，對應arm、arm64票摇、x86，如：gn --android-cpu arm -
--runtime-mode: 運行模式砚蓬，對應debug矢门、profile、release灰蛙，如：gn --runtime-mode debug -
--unoptiimized: 是否優(yōu)化祟剔，帶上這個參數(shù)就說明是不優(yōu)化的情況
2.3、編譯開始
# 1摩梧、定位到`engine/src`目錄
cd engine/src
# 2物延、編譯Android對應平臺已優(yōu)化的release代碼，這里大家根據(jù)自己的實際使用情況仅父，合理的使用2.2中提到的編譯參數(shù)
./flutter/tools/gn --android --runtime-mode release --android-cpu arm
# 通過2中的命令會在src目錄下生成一個out/android_release的目錄
# 3叛薯、編譯2中生成的代碼成為flutter.jar和libflutter.so，這一步就最耗時的笙纤，有快有慢耗溜，看電腦性能了
ninja -C out/android_release
# 如果2中使用的CPU架構是arm64時，3中的這一步就要用android_release_arm64文件夾了
# 4省容、編譯Android打包時需要的代碼
./flutter/tools/gn --runtime-mode release --android-cpu arm
# 5抖拴、同樣編譯一下
ninja -C out/host_android
# 如果4中使用的是arm64，這里就需要用host_android_arm64文件夾了
通過上的編譯腥椒，我們可以看到out/android_release文件夾中已經(jīng)生成了flutter.jar和里面已經(jīng)包含了libflutter.so
三阿宅、使用本地engine
這一小節(jié)只講解純flutter項目時如何使用；至于混合開發(fā)的項目中如何使用笼蛛，因為牽扯到一些gradle腳本的修改洒放，我會單獨抽出一篇文章來講。
3.1滨砍、使用本地engine打包apk
# 打包arm平臺的apk
flutter build apk --target-plarform android-arm --split-per-abi --local-engine-src engine/src --local-engine=android-release
# 打包arm64平臺的apk
flutter build apk --target-plarform android-arm --split-per-abi --local-engine-src engine/src --local-engine=android-release_arm64
3.2拉馋、修改代碼后如何查看新的libapp.so和flutter_assets文件
對于已經(jīng)安裝完使用本地engine打包的apk的手機來說，想動態(tài)更新新的代碼惨好，需要找到修改后代碼打包生成的
libapp.so和flutter_assets文件煌茴，這個文件怎么生成和找到的呢？
- 修改dart代碼
- 使用3.1中的命令打包apk
- 在跟
lib同級別的目錄build/app/intermediates/flutter/release下找到對應CPU架構的app.so文件日川，將其改名成libapp.so蔓腐，然后在app啟動時復制到PathUtils.getDataDirectory(applicationContext)對應的目錄下，也就是user/0/package/app_flutter目錄下龄句；把build/app/intermediates/flutter/release目錄下的flutter_assets也復制到這個目錄下回论。 - 待下次重啟app時即可生效
四散罕、總結
本篇文章講解了flutter engine代碼實現(xiàn)動態(tài)化的代碼修改，以及編譯和使用本地的engine傀蓉，下一篇我會詳細講解在混合開發(fā)時使用本地engine欧漱，以及如何修改bulid aar時的腳本，打包成aar供業(yè)務方使用葬燎，也是伸手黨們的福利误甚，歡迎大家關注和點贊。
