Tencent
BasePluginManager 的 UnpackManager 初始化可否优化？
大佬我写了个 ProcessPluginManager 期望快速实现不同的多 PPS，主要实现相关抽象方法如下：
期望从外部传入不同的 managerName 以及 ppsName 快速实现多 PPS 的实现，
但 BasePluginManager 初始化时就会获取 managerName ，如下图：
ProcessPluginManager 又连续继承自 BasePluginManager ，所以 ProcessPluginManager 初始化时 UnpackManager 的 mAppName 为 null, mInstalledDao 也会有此问题， 因此 mUnpackManager 和 mInstalledDao 可否设计为懒加载或者加上校验机制
我非常不建议在这种需求场景下，将这种把父类本来是final的状态修改为可变状态。mUnpackManager实际上也漏了final修饰。将本来不可变的状态改为可变状态可不是一种优化。
出现这种要改父类的冲动，可以先判断一下，子类确实需要继承父类吗？在没有向上转型的需求时，任何继承都是不必要的。这里原本那串BasePluginManager子类的继承其实也都是不必要的，只是这些继承影响不大。
这里BasePluginManager的子类实际上要实现的是PluginManagerImpl接口。所以当新增的类ProcessPluginManager无法在自身构造时就满足父类BasePluginManager的构造器条件时，说明它们的生命周期不一致，不能继承。
所以ProcessPluginManager应该改为持有BasePluginManager的子类，实现PluginManagerImpl接口。这时ProcessPluginManager就不需要在构造时就初始化BasePluginManager的子类了。它可以在onCreate()时初始化，甚至可以异步的初始化，只要在初始化好之前令enter()方法始终返回一个调用方可以接受的失败，或者等待进度就可以了。
实现PluginManagerImpl接口也意味着你的ProcessPluginManager可以完全不依赖BasePluginManager。
大佬，我这边的 ProcessPluginManager 与 示例代码中的实现有点不同，为了便于快速接入以及调试，我去除了 PluginManager 的动态化加载，我将 ProcessPluginManager 放在了一个 libary 模块中，为了快速实现多 PPS 所以我期望用一个类就可以进行实现，因为无法确定调用方需要多少个 PPS，为了快速便于获取 PluginManager 对象，抽出了一个公共类以及相关方法如下：
所以是期望获取 PluginManager 对象然后进入插件的，因此 ProcessPluginManager 采用继承的方式，而且即使采用组合 BasePluginManager 子类的方式，也还是需要在每个子类中具体实现 getName() 这个抽象方法，还是无法达到用一个 子类实现启动多个 PPS 实例， 所以 BasePluginManager 是不是用 kotlin 重构，然后 mUnpackManager 和 mInstalledDao 这两个属性用 by lazy 进行懒初始化更好，也不会让 mUnpackManager 以及 mInstalledDao 从不可变状态改为已变，已有的相关逻辑以及设计并不会产生改变
我不能理解你为什么要挑战用一个类实现功能。你不加上这个目标不是很容易就实现了么？
另外Manager和PPS的一对一关系是由BaseDynamicPluginManager限定的，你想Manager支持多PPS，不是应该改这个类么？多个PPS应该是可以共用一个BasePluginManager的，BasePluginManager的Name只是决定数据库的存储位置。如果多个PPS只是为了区分多个插件进程，那好像也没必要搞出多个BasePluginManager实例吧？因为Manager不是在PPS进程的，它是在管理进程的，一般是宿主的主进程吧。
好哒，谢谢大佬的解惑。因为之前目前的不同的插件包中有共通的依赖内容，接手改造时间紧，尝试使用一个 PPS 加载不同的插件包，在 mPluginLoader.loadPlugin(partKey) 时将 mPpsController 的 UUID 改为要加载对应插件包的 UUID, 但发现实际好像没生效就没慢慢细查下去，因为领导想要快速看到启动不同插件的效果，所以就采用最差的方案，不同的插件包采用不同的 PPS，怕又会有其他问题就想着干脆也使用多个 Manager 了，不过听大佬说可以使用一个 Manager 支持多个 PPS， 那的确是不需要我用一个类实现不同的 Manager 实例。
另外，我看 issue 中说到可以使用 MultiLoaderPluginProcessService 在同一个进程中隔离加载不同的插件包，但是 PluginManagerThatSupportMultiLoader 没有看到相关的使用示例代码，因此不知道该如何正确使用它，应该使用此方式目前是解决相关需求的最好方式，无需使用多个 PPS 加载多个插件同时插件包也是相互隔离。
MultiLoaderPluginProcessService是因为宿主对插件进程管理很严格，不能每个插件都分配一个进程。所以一堆不相关的插件要运行在同一个进程里。这些插件的开发都是独立的，所以它们会有不同版本的PluginLoader，所以才需要那么一个类。这个使用场景有点复杂，也就没写示例。如果要用的话，应该也很好调试使用的。
大佬，我尝试使用一个 Manager 对象管理多个 PPS， 发现还是还是会有同样的问题：
manager 实现主要部分如下：
所以好像当使用一个 Manager 时，在不同的 PPS 中加载插件和在一个 PPS 中加载插件会有同样的问题，是我的使用方式哪里出了问题吗？