HeartBeats

大佬，我尝试使用一个 Manager 对象管理多个 PPS， 发现还是还是会有同样的问题：  manager 实现主要部分如下：  所以好像当使用一个 `Manager ` 时，在不同的 PPS 中加载插件和在一个 PPS 中加载插件会有同样的问题，是我的使用方式哪里出了问题吗？

> 像这样的Cannot cast A to B的错误可以这样排查： > 1. 确定Cannot cast 异常是根异常，没有进一步的caused by。 >2. 检查A的字节码，确认其.super字段确实是B或B的子类。 >3. 在运行时，拿到A的对象a，获取其ClassLoader，用这个加载A的ClassLoader查找B类。再拿到抛出cast异常的代码所属类的ClassLoader，用它也查找B类。对比两次查找到的B类是否是同一个对象。如果不是，注意它们的ClassLoader，进一步确定其所属的jar包、dex文件。这一检查流程关注的重点是JVM加载类的机制是用当前类的ClassLoader加载其引用的其他类。如果有多个ClassLoader中加载了同名的类，那它们对于JVM来说是不同的类。因此就算抛出异常Cannot cast X to X也是常见的情况。 我看异常产生时没有其他的问题产生，错误信息：com.youma.cjspro.PluginSplashActivity cannot be cast to com.tencent.shadow.core.runtime.PluginActivity， 我反编译查看 `PluginSplashActivity ` 代码继承自...

大佬， 我在一个 Issue 里看你介绍的关于 `PluginManagerThatSupportMultiLoader ` 的使用方式： https://github.com/Tencent/Shadow/issues/961#issuecomment-1134393024 所以感觉还是我之前的使用方式没按您的设计来： 我是实现了 `PluginManagerThatSupportMultiLoader` 的子类，以为是只需要一个子类对象，然后调 PPS 的方法传入不同的 PluginKey 就可以实现插件中 `runtime`、`loader` 的加载以及拿到对应的 `PluginLoader`， 看了介绍的使用方式豁然开朗，因此 https://github.com/Tencent/Shadow/issues/1061#issue-1387505196 这里提到的前两点问题应该是不存在的，我来试试您设想的使用方式来进行使用看看。 至于我的想法应该也是可以实现相关需求，但经过自己几天调试运行，看到相关错误信息感觉自我能力还是不够，放弃设想的实现方案

使用 `PluginManagerThatSupportMultiLoader` 的不同子类对象启动不同的插件包，和我之前的实现方式表现还是一样，都只能单个插件包启动，切换插件包即出错，出错没有本质区别，主要有两个错误类型： 1. `isIllegalIntent`， 报错堆栈如下：  这里看过设置 `loaderVersion` 的地方始终都为 local， 不能理解为何会被改为 2.3.0 ？ 2. 之前的类转换异常：`xxx(启动的插件 Activity) cannot be cast to com.tencent.shadow.core.runtime.PluginActivity`， 具体出错堆栈位置：  目前原因仍然未知，我看 PluginClassLoader 对象是没问题的，不知问题是否在 RuntimeClassLoader 与其之间？

这几天把 Shadow 插件化的原理给看了下，然后整个启动插件相关的源码（runtime、loader、以及插件的加载）都给看了一下，按相关设计修改了插件的实现，通过 `delegateProviderKey` 使 `ShadowPluginLoader` 与 `PluginContainerActivity` 一一对应，启动单个插件包时无问题，但切换启动另一个插件包时即会报错，具体报错堆栈如下： ```shell Process: com.hl.baseproject.demo:pluginMulti, PID: 22307 java.lang.LinkageError: While checking class com.hl.my_runtime.CJSXTPluginProxyActivity method android.content.Context com.tencent.shadow.core.runtime.container.GeneratedHostActivityDelegator.createContext(android.content.ContextParams) signature against interface com.tencent.shadow.core.runtime.container.GeneratedHostActivityDelegator: Failed to resolve arg...

不急用，只是昨天发现这个问题然后排查了一下向您反馈该问题，目前 litepal 我将数据库存储到 内部目录中也可以使用

哇得一声哭出来，这两天升级一些库也踩了这个坑，一个一个试才试出来在 AGP 7.2.1 上没生成这个 `PluginManifest` 这个类，正准备提 issue， 搜了一下发现已经提过了，插眼等待大佬解决

大佬，EasyHttp 的定位是网络请求框架但是目前已经集成了上传和下载功能，这两个功能对于现在的 APP 都是不可或缺的，而且对于用户体验来说，断点续传相关的功能现在也很普遍，如果大佬觉得这两个真实属于不同的类别可以考虑将下载上传功能抽离出来，作为 EasyHttp 的扩展库，同时由于已有的功能存在，其实开发续断点续传也不是非常的复杂

大佬您好，我在整理项目使用二维码方面的库时，发现该库的功能和扩展性都挺全面的，但是我在接入使用时还是发现有一些问题需要优化，首先文档有些地方需要优化一下：  这里整个使用方式我觉得应该放在引入的下面，版本说明应该放在最后，然后针对每种使用方式需要分开说明一下，就比如第三点，只能查看代码发现 CameraScan 这个抽象类有个默认实现类 DefaultCameraScan， 既然这样三四是不是应该属于同一种方式？ 而且第一种方式集成使用时首先需要声明 com.king.zxing.CaptureActivity ，但是这个可以在代码层面优化的，作为依赖的 module，module 内部可以声明，这样使用方就无需再次声明，其次使用时默认缺少 androidx.camera.view.PreviewView 这个依赖库，我认为使用方有时不知道缺少库的相关地址，这个应该在打包发布时默认提供依赖比较好，目前还没有深入使用，仅在接入时发现的问题，希望大佬可以考虑优化一下

> > 大佬您好，我在整理项目使用二维码方面的库时，发现该库的功能和扩展性都挺全面的，但是我在接入使用时还是发现有一些问题需要优化，首先文档有些地方需要优化一下：  > > 这里整个使用方式我觉得应该放在引入的下面，版本说明应该放在最后，然后针对每种使用方式需要分开说明一下，就比如第三点，只能查看代码发现 CameraScan 这个抽象类有个默认实现类 DefaultCameraScan， 既然这样三四是不是应该属于同一种方式？ > > 而且第一种方式集成使用时首先需要声明 com.king.zxing.CaptureActivity ，但是这个可以在代码层面优化的，作为依赖的 module，module 内部可以声明，这样使用方就无需再次声明，其次使用时默认缺少 androidx.camera.view.PreviewView 这个依赖库，我认为使用方有时不知道缺少库的相关地址，这个应该在打包发布时默认提供依赖比较好，目前还没有深入使用，仅在接入时发现的问题，希望大佬可以考虑优化一下 > > 首先感谢你的建议反馈；下面根据你提到的几个点一一答复下： > > > 截图中提到的关于 **快速实现扫码的几种方式** 的说明 和...