shifujun
shifujun
> 反注册的时候未在mReceiverWrapperMap中的的还会往mReceiverWrapperMap中put一个，且反注册的时候没有remove掉相应的Receiver 设计如此。而且这里是WrapperMap，即便有bug，影响也应该是内存泄漏。不应该出现对应Wrapper没有注册的情况。 WrapperMap保存的是receiver和wrapper两个对象的映射关系，这个映射关系和receiver是否被注册到系统了没有关系。 这里采用WeakHashMap实现的原因就是只要receiver还被业务代码或者系统持有，那就是还有可能需要被重新映射为之前一样的wrapper对象。 最好还是在sample上复现一下有问题的场景，否则我暂时理解不了bug是怎么产生的。
我猜应该是这个错误导致的：#867 可以测一下能不能复现问题了。
添加了一个 82fd26231156b3565e2cd379913cddf89cbbc9cb 修复了
> > 添加了一个 [82fd262](https://github.com/Tencent/Shadow/commit/82fd26231156b3565e2cd379913cddf89cbbc9cb) 修复了 > > 好了，另外反注册时mReceiverWrapperMap不移除一下么，要不然Map长度会一直增长 不需要。这个map跟receiver是否注册了没有关系。它是弱引用实现的，只要有其他强引用，就说明还有可能需要转换wrapper对象。如果不需要再转换了，外面一定也没有强引用了，也就自动释放了。
如果按你的#866 修改没有问题的话，那应该是原本的BroadcastReceiver被直接注册到系统过。那它是怎么注册的呢？
如果还有问题再打开吧。
你能在Shadow的sample上复现问题吗？可以的话把代码push上来看看。 关于`AppComponentFactory`，Shadow是像处理`Activity`一样，把插件中的全部`AppComponentFactory`类型都替换成`ShadowAppComponentFactory`了。所以预期中`androidx.core.app.CoreComponentFactory`的父类也会被修改为`ShadowAppComponentFactory`。那么它就不会出现"Cannot cast androidx.core.app.CoreComponentFactory to com.tencent.shadow.core.runtime.ShadowAppComponentFactory"这样的异常了。 这个设计有一个自动化测试: `com.tencent.shadow.test.cases.plugin_androidx.ComponentFactoryTest`。你可以调试这个自动化测试，要是能复现问题就非常好定位了。
这是开源交流，你们不分享代码，我也没法帮你们啊。
设置为透明的原因是我们开发时观察到如果不设置成透明的，插件将无法再设置透明背景。所以考虑都设置成透明的，插件如果不需要透明，就主动设置一个不透明的颜色作为背景就行了。毕竟manifest里的设置是不能动态更新的。
参考下这个看看？https://github.com/shifujun/Shadow/commit/b2f8c2cdf31e34c95ff4947deaacb09d4c34228b