jacobchow

使插件的android:process生效还需要很多的开发工作。 首先需要一个工作于manager中插件process管理器，由它获取到插件的组件对应的process后，转调到对应process的PPS上。 读取插件组件的process也还需要一定的开发量。目前已经有编译期解析Manifest的代码了，最终可以把插件的process信息写到插件apk中的一个class中。如果保持这个设计，那就需要在manager所在进程就要加载一次apk，从中读取class了。所以还需要将组件的process信息优化到一个单独的持久化文件中。 插件内部的组件启动调用也需要重新设计，先将调用发回manager中的process管理器上，以便识别出跨进程的调用。 最后如果需要插件新增的process也能生效，我们还需要开发一套编译期工具自动生成宿主中所需的Manifest声明。 基于以上考虑，单一业务很难会选择开发这样一套通用的代码。因为单一业务一般process是比较固定的，宿主Manifest也不便动态更新。 _Originally posted by @shifujun in https://github.com/Tencent/Shadow/issues/1037#issuecomment-1229126616_ 我理解上述通过多pps实现多进程管理的思路，只适用于activity和service的启动，对于provider的多进程特性是否有优雅的实现思路呢？ 目前我能想到的修改思路如下： 1、在onBindContainerContentProvider中根据插件provider的process信息，将业务provider和用于进程占位的容器Provider建立映射关系 2、如果插件进程A中发起请求，转调给容器Provider（业务Provider和容器Provider均定义在进程B），则在B进程中分发给业务Provider前，需要加载loader和plugin。

关于Service解绑时onServiceDisconnected调用的疑问

1

[https://github.com/Tencent/Shadow/pull/935/files](url) 这笔提交中在正常解绑service时回调了onServiceDisconnected，但是按官方文档说法，此回调只有服务丢失时才会被调用： [https://developer.android.com/reference/android/content/ServiceConnection](url) > Called when a connection to the Service has been lost. 这里是否与原生逻辑不同？还是有其他考虑