初始化壳子类的时候无法找到 #505
Comments
|
你的这个 另外，如果不关心宿主方法数增量，也可以直接把 |
|
好的，我再看看，不行就放宿主中，谢谢 |
|
您好： 我在研究调用流程时测试自己的APK发现一个问题，主要代码在如下位置： // FastPluginManager 类
public InstalledPlugin installPlugin(String zip, String hash, boolean odex) throws IOException, JSONException, InterruptedException, ExecutionException {
...... //加载解压插件操作
onInstallCompleted(pluginConfig);
return getInstalledPlugins(1).get(0);
}首先说一下我的前置操作： 发现 BasePluginManager 调用 onInstallCompleted(pluginConfig) 时，会向数据库插入插件的配置信息： db.beginTransaction();
try {
for (ContentValues contentValues : contentValuesList) {
db.replace(InstalledPluginDBHelper.TABLE_NAME_MANAGER, null, contentValues);
}
//把最后一次uuid的插件安装时间作为所有相同uuid的插件的安装时间
ContentValues values = new ContentValues();
values.put(InstalledPluginDBHelper.COLUMN_INSTALL_TIME, pluginConfig.storageDir.lastModified());
db.update(InstalledPluginDBHelper.TABLE_NAME_MANAGER, values, InstalledPluginDBHelper.COLUMN_UUID + " = ?", new String[]{pluginConfig.UUID});
db.setTransactionSuccessful();
} finally {
db.endTransaction();
}这时如果插件压缩包始终未修改时，每次加载插件调用仍会向数据库中插入数据，数据库会变成如下图所示： 可以看到 sample-plugin 的安装时间（即修改时间）比较新，随后 getInstalledPlugins(1).get(0) 会获取最后安装的插件，这样就会导致即使加载 my-plugin 插件，但获取到的安装插件仍为 sample-plugin 插件，即使 getInstalledPlugins(1) 传入的参数比较大也不好获取到想要的插件，所以我不清楚这个限制是不是设计如此？ 是否设计时就要求每个插件包必须要有一个 PluginManager 还是目前逻辑上有些缺陷？
期待您的解惑，谢谢！ |
|
或者插件的安装时间进行修改？不以插件文件的修改时间为准，而以插入数据库的时间为准。 |
|
wiki里有一篇Shadow对插件包管理的设计可以读一下。 注意一下，在 在这个设计中考虑的是一组插件是一起构建发布的，它们之间的版本关系是1对1的，可以通过ClassLoader关系相互依赖。但是它们和宿主之间的版本关系是1对多的，不能任意引用宿主中的内容。 所以只要考虑好版本对应关系，这个Manager的逻辑可以自己根据业务的需要定义。只需要参考 |
|
好的，谢谢您的解惑，我已可以成功加载启动插件 APK 中的 Activity，当前使用 还有问题是我这边尝试在一个插件包中通过 partKey 使用多插件，结构如下：
shadow {
packagePlugin {
pluginTypes {
debug {
loaderApkConfig = new Tuple2('my-loader-debug.apk', ':my-loader:assembleDebug')
runtimeApkConfig = new Tuple2('my-runtime-debug.apk', ':my-runtime:assembleDebug')
pluginApks {
pluginApk1 {
businessName = 'test-debug'
//businessName相同的插件，context获取的Dir是相同的。businessName留空，表示和宿主相同业务，直接使用宿主的Dir。
partKey = 'test'
buildTask = ':test:assembleDebug'
apkName = 'test-debug.apk'
apkPath = '/plugin/test/build/outputs/apk/debug/test-debug.apk'
//hostWhiteList = ["com.tencent.shadow.sample.host.lib"]
}
pluginApk2 {
businessName = 'sunflower-debug'
//businessName相同的插件，context获取的Dir是相同的。businessName留空，表示和宿主相同业务，直接使用宿主的Dir。
partKey = 'sunflower'
buildTask = ':sunflower:assembleDebug'
apkName = 'sunflower-debug.apk'
apkPath = '/plugin/sunflower/build/outputs/apk/debug/sunflower-debug.apk'
//hostWhiteList = ["com.tencent.shadow.sample.host.lib"]
}
}
}
}使用如下方式来分别打开不同的插件： 结果：test 可以正常启动，但 sunflower 启动报错： 期待您的再次回复解惑，谢谢！ |
|
看起来就是你那个 确实只有 |
|
这是 sunflower 中还需要加入其他的配置吗？ |
|
看起来是API 29的onActivityPreCreated新生命周期适配错误，是Bug。我晚点看看怎么修复。 这个回调早于onCreate了。插件之前是在onCreate里初始化的，所以会报找不到插件的那个字段crash。 建议先在低于29的机器上测试。 |
|
嗯嗯，我这边在 Android 9 (API 28) 的模拟器上测试确实没有此问题，我自己的手机是 Android 10 的切换插件时会闪退，大佬有时间可以修复下此问题。 |
|
已经抽时间在写了。修复代码容易，就是写自动化测试比较费时间。 |
|
确实，写测试 case 比写代码还麻烦，一般也只有大佬才会特别注重这个方面，像我这样的小菜鸟实现个逻辑功能没啥 bug 就感到比较舒服了，还有看大佬写的代码真是如浴春风，设计层次分明、代码逻辑清晰、注释简单易懂... |
API 29以上ActivityLifecycleCallbacks有一个默认实现的接口onActivityPreCreated， 这个方法回调早于onCreate方法，也是唯一一个。此时PluginActivity尚未构造，因此不能正常工作。 统一ActivityLifecycleCallbacks映射实现到ShadowActivityLifecycleCallbacks.Holder， 由它持有所有ActivityLifecycleCallbacks。 ShadowActivityDelegate在PluginActivity onCreate之前通知Holder分发onActivityPreCreated事件。 Tencent#505
API 29以上ActivityLifecycleCallbacks有一个默认实现的接口onActivityPreCreated， 这个方法回调早于onCreate方法，也是唯一一个。此时PluginActivity尚未构造，因此不能正常工作。 统一ActivityLifecycleCallbacks映射实现到ShadowActivityLifecycleCallbacks.Holder， 由它持有所有ActivityLifecycleCallbacks。 ShadowActivityDelegate在PluginActivity onCreate之前通知Holder分发onActivityPreCreated事件。 Tencent#505 Tencent#519
API 29以上ActivityLifecycleCallbacks有一个默认实现的接口onActivityPreCreated， 这个方法回调早于onCreate方法，也是唯一一个。此时PluginActivity尚未构造，因此不能正常工作。 统一ActivityLifecycleCallbacks映射实现到ShadowActivityLifecycleCallbacks.Holder， 由它持有所有ActivityLifecycleCallbacks。 ShadowActivityDelegate在PluginActivity onCreate之前通知Holder分发onActivityPreCreated事件。 #505 #519
运行时总是报错：
宿主中定义的壳子类如下：
壳子类定义如下图：
插件的 applicationId 已与宿主保持一致，不知道为啥会出现此问题，希望可以指点迷津，提前谢谢！
The text was updated successfully, but these errors were encountered: