AnotherJack

是会有这种问题的，但是一直没想到什么好办法

@asiontang 你好，刚看了一下您的代码，是采用在Base类中收集所有的回调，然后在onActivityResult中根据requestCode分发回调，关于activity被回收的情况是在onSaveInstanceState把所有回调的classname存起来，在onRestore中再把classname取出来，通过反射创建回调对象进行恢复，整体的思路应该是这样的。是个很不错的思路，但是有一点，我看反射创建listener的时候使用的是带有外部Activity的一个参数的构造器，如果没猜错的话这个构造器的存在是因为内部类持有外部类的引用吧，那如果我创建listener的代码是在点击事件中，在OnClickListener中，是不是这个构造器的参数类型就不是外部Activity而是OnClickListener了，所以我觉得这一点有待考究。 再抛开以上这种情况，我觉得只是把当前的activity传进去也是不够的，考虑一种情况，有一个列表页面，分页加载的，有个全局的List存着列表的数据，比如已经加载了100条了，我点击第100条想startForResult获取一些数据，回来的时候还要用到这第100条数据，按您现在的代码的话，回来的时候页面应该只加载了第一页，可能这时候这个list并没有第100条数据，可能就出错了。当然，可以在onSaveIns的时候把这个list也存储上，onRestore的时候再恢复，应该就可以了，也就是说需要把listener中用到的数据都存起来。我觉得按您的思路再完善完善，应该可以尝试一下的。

又做了一些改动，ProgressManager中之前是对url使用弱引用，现在改为对listener使用弱引用，即由原来的List改为Set，其中此set是由Collections.newSetFromMap(new WeakHashMap())创建的，不会对listener有leak。 现在的listener是使用一次就会被回收的，在example中点击下载，下载完成后，过一会儿（等待gc）再点下载会不改进度，因为在上次下载完成后listener不再被引用而被回收。所以使用中要注意在业务代码中处理好对listener的引用

> 所以我不是很清楚去掉 mRequestListeners.containsKey(key) 的必要性，还是说这次更新有什么地方必须要保证 listeners 不为空，是否可以在继续保留 if (mRequestListeners.containsKey(key)) 的情况下，将 Listener 改为弱引用 这个当时是这样考虑的，如果一个请求开始的时候没有添加listener，而是进行到一半的时候才添加，这样可以让后边加的listener起作用

> 但是为了完成这个需求，代价太过庞大，需要监听的 URL 在项目中是少数，想实现请求之前未监听但中途需要监听的 URL 更是少数，为了实现这个需求，付出让全部 URL 的 RequestBody 都被重写的代价，个人认为这样不是很好，性价比不是很高。 > > 可以使用文档告诉用户，如果想实现让之前未实现监听，但在请求中途突然需要添加监听的需求，就需要在 URL 开始之前随便添加个空实现的监听器占位，这样只需要让 ProgressRequestBody 中的数组变成 List，就可以实现请求中途添加监听器的需求。 > > 所以我想问下，在这个 PR 中能否只保留对弱引用和数组的优化，去掉对 mRequestListeners.containsKey(key) 的优化，或者你还有什么更好的方案 可以，让使用者主动添加一个空的listener占位可以解决这个问题