-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
插件卸载不干净导致无法重新安装插件 #691
Comments
我重新CR了一下这块的代码,确实是设计层面的问题。我先记录一下问题。 这里有一个 但是对于BasePluginManager(更具体到InstalledPluginDBHelper中的表结构)来说,已安装的插件是没有安装时来源的记录的,也就没有zip解压的概念了。所以删除插件时,BasePluginManager不可能知道该去清除 所以,在不谈重构UnpackManager设计的前提下,应该这样修复:
|
这个bug已经在最新版本解决了么 |
没呢,解决的话会关联提交到这个issue的,也会关闭的。可以帮忙修复一下。我可能得晚点再看这个了。 |
我在想是用uuid来处理这个bug还是用文件的MD5,其实我们的插件每次都没有去改uuid,不改的话有啥影响么? |
uuid是用来标记一组apk可以协同工作的。这组apk包括runtime、loader和插件。如果每次发布都使用同样的uuid,显然会失去uuid的检查能力。各apk出现不兼容情况时,你就很难第一时间发现是因为它们版本不兼容导致的。 md5对于每个文件来说都不一样,不能用来替代uuid。即便可以,运行时计算md5也很慢。 |
更改UnpackManager文件的unpackPlugin方法,这样改可以把?那个文件我没有删除,用来存储对应的uuid,到时候就不是判断文件是否存在了,加了个条件,判断是否一致
// PluginConfig pluginConfig = getDownloadedPluginInfoFromPluginUnpackedDir(pluginUnpackDir, zipHash);
|
@BruceLiuTao 你们的场景是怎样的?我理解删除插件,就应该要把该插件相关的内容都清理干净 |
单独提取zip中的config.json后先生成PluginConfig。 PluginConfig添加的isUnpacked方法根据各目标文件是否均已存在来判断是否已解压。 如果文件缺失,则会重新解压文件。 fix Tencent#691
单独提取zip中的config.json后先生成PluginConfig。 PluginConfig添加的isUnpacked方法根据各目标文件是否均已存在来判断是否已解压。 如果文件缺失,则会重新解压文件。 fix #691
大神好,我可以这样理解吗: 卸载插件,其实并不是真正从内存里面移除掉这些插件的类,而是仅仅删除了文件以及插件对应关系的存储,让外部调用不到这个classloader而已; 实际上这些插件已经加载过的类,依然是存于内存中,对吗? |
这个issue讨论的是 你理解的内存相关的加载时 |
复现条件:
使用deleteInstalledPlugin方法卸载插件,再重新安装会失败。
原因分析:
deleteInstalledPlugin方法只会卸载插件、runtime、loader三个apk,而安装插件时回去查找插件目录下的UNPACK_DONE_PRE_FIX + pluginUnpackDir.getName()文件进行判断,如果存在就是已经安装过不解压缩包。加载插件的loader.apk时会失败抛出找不到这个文件异常。
这里有个issue也提到了这个问题:
#621
这个issue解决方法感觉不够简洁,我这里简化了下,自测解决自己场景是没问题,但是还是希望官方能提供更优雅的解决方案。
The text was updated successfully, but these errors were encountered: