最近对客户端进行内存泄漏排查，绝大部分内存泄漏的地方都很容易找出来，对着Android Studio分析的结果，一步步点开Depth 为0 的引用，然后Jump to Source 分析分析就行了。
但是有个内存泄漏比较诡异：
mCallerContext in com.facebook.imagepipeline.cache.BitmapMemoryCacheKey |
一个缓存的key居然引用了Activity，对着Depth为0的引用也找不出有什么异常的地方。然后去看了半天fresco源码分析BitmapMemoryCacheKey里面Context 的来源，但是传入Context 的地方太多，分析源码的时候突然想到打个断点不就行了。。
思路对了就很简单了，在创建缓存key的地方(getBitmapCacheKey)打了几个断点，Context为Activity 的情况下顺着调用栈就找到了泄漏的地方。
找到问题的根源之后又看了下fresco的源码，作为callerContext 传入的Context 都会被静态引用。所以解决办法有两个：
- 所有的
callerContext只传入ApplicationContext - 在每个
Activity.onDestroy()的地方调用clearCache相关方法cleanCacheForUri()cleanAllData()