Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
由于#38 发现#40 所以有了这个PR。
首先Review了 84f55d2 当时的改动原因。当时主要是为了解决继承PackageManager实现时,不得不兼容OEM厂商对PackageManager添加的hide方法。这违背了Shadow的设计原则。于是找出了不需要继承PackageManager实现的方法。所以当时实现完就应该把存在兼容OEM系统方法的类删除,当时漏删了,因此有 8be2a83 提交。
接下来为了较为可靠的重构这个实现,首先需要为ApplicationInfo做一个自动化测试。因为要拿到原本宿主不应该关心的信息,所以加一个TestManager模块,让动态加载的Manager和Loader都有能力向宿主中的类塞数据。这样单元测试就可以在宿主这一侧拿到一些内部信息了。这里暂时需要的是插件的uuid。因此有提交 623d26e 。
提交 921f071 撰写单元测试,将#38 #40 的问题先通过单元测试暴露出来。见
com.tencent.shadow.test.cases.plugin_main.application_info.ApplicationInfoTest
。提交 27b9f5c 是为了厘清PluginPackageManager的作用,简化了代码。
然后发现PackageManagerTransform中也写了PackageItemInfo的处理,虽然处理手段是完全一样的。但是这里的设计是希望按功能将文件分开,因此先将这两部分修改分成了两个文件。以保证本次重构对PackageItemInfo没有影响。因此有提交 15baf69 。
最后通过提交 0757192 重构ApplicationInfo获取的实现。主要设计如下:
插件的ApplicationInfo来自于最初通过
android.content.pm.PackageManager#getPackageArchiveInfo
获得的PackageInfo
,代码在com/tencent/shadow/core/loader/blocs/LoadPluginBloc.kt:63
。然后将这个ApplicationInfo保存在插件专有的PluginPackageManager中。每个插件都有自己的PluginPackageManager,但这个PluginPackageManager不会直接交给插件中的代码使用,插件中的代码拿不到这个PackageManager,也就不会把它交给系统,系统也就不会对这个PackageManager调用hide方法。
每个插件的PluginPackageManager都能向ShadowPluginLoader要到当前已经加载的所有插件的PackageInfo,这样在PluginPackageManager中就能查询其他插件的ActivityInfo等信息了。
每个插件的PluginPackageManager还持有宿主的PackageManager,在当前插件和其他插件中都找不到所需信息时,最后从宿主的PackageManager中查找。
专门在PackageManagerTransform转调到Runtime层的PackageManagerInvokeRedirect时,将原本被调用的PackageManager对象从参数中删去。这个对象确实是宿主的PackageManager,但传过来没有用,因为PluginPackageManager在构造时就拿到宿主的PackageManager了。把这个参数传过来对后续维护造成困扰。我这次就花了些时间专门确认了这个参数是什么,有什么用。
fix #40