分享一个线上疑难问题的排查过程
在某个版本上线后，这个异常的量突然变大了，log如下
通过log，可以知道是imageview使用了被回收的bitmap导致的，可以具体看下崩溃地方的源码
android.graphics.BaseRecordingCanvas$drawBitmap
frameworks/base/graphics/java/android/graphics/BaseCanvas$throwIfCannotDraw
崩溃的原因，是很清晰的，就是使用的bitmap被回收了，由于log只有系统层级的log，没有项目的log，那该如何进一步定位呢？
可以分成三个步骤
1、定位发生错误的activity
崩溃是发生在draw方法内部，draw方法一般都是在当前Activity可见的时候触发，就是onResume跟onPause的生命周期中，我们可以在崩溃后台，标记最新可见的activity，当发生崩溃时候，把当前可见的activity一起上报，可以通过后台查看，崩溃那一刻，在前台的是哪个activity
可以连续查看几条，看下是否都是同个activity，我这边验证，崩溃的信息，都是固定的一个activity，于是可以基本确定，崩溃是发生在这个activity
2、定位错误的view
定位到activity，范围还是太大，我们接下来进一步缩小，定位到具体的view，具体是哪个imageview崩溃
可以在崩溃堆栈入手，发现view的onDraw方法，调用其实就是view的布局一步步调用下来的
通过上图的分析，可以知道崩溃imageview的布局层级关系，用图表示如下
可以通过activity的布局，定位到符合这个布局层级关系的imageview
到这里应该可以基本确定异常的imageview了，如果还不行，继续看步骤3
3、准确定位异常imageview 如果上面的两个步骤，还是无法定位修复问题，可以继续看
比如发现有多个imageview都满足条件，如何进一步定位到具体崩溃的是哪个imageview 可以用如下的方式，替换下所有怀疑的imageview
class BitmapRecycledImageView(context: Context, attrs: AttributeSet?) : GlideNoFlickerImageView(context, attrs) { var drawException: RuntimeException? = null override fun onDraw(canvas: Canvas?) { try { super.onDraw(canvas) } catch (e: RuntimeException) { //代表bitmap被回收了，发送到bugly，用于后续定位分析 //错误的log大概这个样子：image bitmap Recycled com.meitu.meitupic.modularembellish.filter.ActivityFilter@76184c8 imageID 2131298607，可以方便定位到问题 if (drawException == null) { //onDraw是个高频调用的场景，只上报一次就可以了，避免大量的上报 drawException = RuntimeException("image bitmap Recycled $context imageID $id") CrashReport.postCatchedException(drawException) } } }}
这样的话，当发生错误后，就触发上报，收集上报的log，收集到的log类似如下
image bitmap Recycled com.meitu.meitupic.modularembellish.filter.ActivityFilter@b24f0b7 imageID 2131298604com.mt.material.filter.BitmapRecycledImageView.onDraw(BitmapRecycledImageView.kt:30)
定位到了发生崩溃的activity，包括错误的imageview的ID
接下来，通过imageview id找到具体的imageview
我们知道，我们在xml中给每个view定义的ID值，其实都会被编译成一个16进制的值，而这个值跟我们代码定义的值有一个映射关系，可以通过解析apk来获取
Log上报的ID值是十进制的，转成16进制后，就是：0x7f09092c，跟apk的资源比对，找到对应的value值
这样就知道了具体崩溃的imageview
最终发现，出现问题的是因为外部应用了Glide加载的bitmap
接下来，就是分析，为什么会出现这个崩溃，
从源码角度，一步步分析下，为什么会出现这个问题
先说结论
因为外部引用了glide加载的bitmap，而这个bitmap又被glide内部主动recycle导致的
示例代码
比如上面这个代码，通过onResourceReady，引用了glide加载的bitmap，而这个bitmap有可能被glide内部recycle，从而导致开始说的异常
下面从glide源码的角度，了解下这个过程
首先，glide加载的图片，是有生命周期感知的，在页面A加载的图片，在退出页面A后，会自动清空，进入内存缓存，其对应的代码如下
com.bumptech.glide.request.SingleRequest#clear
继续往下走，然后调用了
com.bumptech.glide.load.engine.EngineResource#release
void release() { boolean release = false; synchronized (this) { if (acquired <= 0) { throw new IllegalStateException("Cannot release a recycled or not yet acquired resource"); } if (--acquired == 0) { release = true; } } if (release) { listener.onResourceReleased(key, this); } }
这里的acquired，其实是判断，其他页面有没有也在加载这个图片，如果都没有了，才会进入内存缓存
继续调用到这里
com.bumptech.glide.load.engine.Engine#onResourceReleased
public void onResourceReleased(Key cacheKey, EngineResource resource) { activeResources.deactivate(cacheKey); if (resource.isMemoryCacheable()) { //加入到内存缓存中了 cache.put(cacheKey, resource); } else { resourceRecycler.recycle(resource, /*forceNextFrame=*/ false); } }
到这里，可以看到资源已经被加入内存缓存中了
由于内存缓存是有上限的，到了上限后，会根据LRU的算法，把早期的资源移除掉，我们继续看下代码
被释放的资源，会调用到com.bumptech.glide.load.resource.bitmap.BitmapResource#recycle方法
@Override public void recycle() { //最终释放的资源进入了bitmapPool bitmapPool.put(bitmap); }
这里有疑惑了，这个bitmapPool到底是个什么东西，先看下官方的描述
原来是为了bitmap复用，那到底是用在什么场景
其实是用在transform场景，对于圆角或者居中等，需要新的bitmap做圆角处理，为了避免每次都new一个bitmap，就用被回收的bitmap来复用
而且复用的时候，会清空bitmap的内容
当然，bitmapPool也有缓存上限，当达到上限后，也会依据LRU算法，清空早期的bitmap
而且在清空的时候，调用了bitmap.recycler()方法，这个调用，就是导致trying to use a recycled bitmap的罪魁祸首
整理一个流程图如下
那如果我就是就是想用glide加载一张bitmap，一般都是这样写
Glide.with(activity).asBitmap().load(Url).into(object : CustomTarget() { override fun onResourceReady(resource: Bitmap, transition: Transition?) { //resource就是要加载的bitmap } override fun onLoadCleared(placeholder: Drawable?) { //收到这个回调，之前的resource不能再引用了，需要置为null }})
这样写，需要注意的是，当收到onLoadCleared的回调后，就不能引用resource了，不然就有可能导致trying to used a recycled bitmap错误了
当然，我们还有更好的写法
WorkScope.launch { val bitmap = Glide.with(this@MainActivity).asBitmap().load(R.drawable.dot).submit().get() //bitmap就是我们要的结果，而且这个结果也不会后续被加到内存缓存，可以自己随意使用 }
我们开一个异步线程去bitmap，由于是异步线程，glide内部都会强制采用application的context，用application去加载，是没有生命周期感知的，就算退出了页面，也不会被加入到内存缓存中，也就不用担心被glide recycle了
如果只是单纯通过glide去获取bitmap，建议用这个写法