前言
笔者在最近在做截屏分享的功能，采用getDrawingCache()发现了两个问题，特此记录一下。
View生成Bitmap的两种方式。
- 利用Canvas绘制出bitmap （测量后）
public static Bitmap getBitmapFromView(View view) {
final Bitmap bitmap = Bitmap.createBitmap(view.getWidth(), view.getHeight(),
Bitmap.Config.ARGB_8888);
final Canvas canvas = new Canvas(bitmap);
view.draw(canvas);
return bitmap;
}
- 利用Canvas绘制出bitmap （测量前 不需要展示布局）
public static Bitmap getBitmap(View view) {
final int screenWidth = ScreenUtil.getScreenWidth(view.getContext());
final int screenHeight = ScreenUtil.getScreenHeight(view.getContext());
final int widthSpec = View.MeasureSpec.makeMeasureSpec(screenWidth, MeasureSpec.EXACTLY);
final int heightSpec = View.MeasureSpec.makeMeasureSpec(screenHeight, MeasureSpec.EXACTLY);
view.measure(widthSpec, heightSpec);
view.layout(0, 0, screenWidth, screenHeight);
Bitmap bitmap = Bitmap.createBitmap(screenWidth, screenHeight, Config.RGB_565);
final Canvas canvas = new Canvas(bitmap);
view.draw(canvas);
return bitmap;
}
- View # getDrawingCache()
public static Bitmap getBitmapFromView(View view) {
view.measure(MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED), MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED));
view.layout(0, 0, view.getMeasuredWidth(), view.getMeasuredHeight());
view.setDrawingCacheEnabled(true);
return view.getDrawingCache();
}
public static Bitmap getBitmapFromView(View view) {
view.measure(MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED), MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED));
view.layout(0, 0, view.getMeasuredWidth(), view.getMeasuredHeight());
view.buildDrawingCache();
return view.getDrawingCache();
}
最终采用了第一种方案，没什么可说的，不过第二种方案有一定学习价值。笔者当时在使用如下写法时，发现最终返回的Bitmap结果为null。
public static Bitmap getBitmapFromView(View view) {
view.setDrawingCacheEnabled(true);
return view.getDrawingCache();
}
不知道为什么，所以就看下源码。
public void setDrawingCacheEnabled(boolean enabled) {
mCachingFailed = false;
setFlags(enabled ? DRAWING_CACHE_ENABLED : 0, DRAWING_CACHE_ENABLED);
}
设置标记位，没啥说的。getDrawingCache()最终会走到buildDrawingCacheImpl(boolean autoSize)方法中。
private void buildDrawingCacheImpl(boolean autoScale) {
// 省略...
final long projectedBitmapSize = width * height * (opaque && !use32BitCache ? 2 : 4);
final long drawingCacheSize = ViewConfiguration.get(mContext).getScaledMaximumDrawingCacheSize();
if (width <= 0 || height <= 0 || projectedBitmapSize > drawingCacheSize) {
if (width > 0 && height > 0) {
Log.w(VIEW_LOG_TAG, getClass().getSimpleName() + " not displayed because it is"
+ " too large to fit into a software layer (or drawing cache), needs "
+ projectedBitmapSize + " bytes, only "
+ drawingCacheSize + " available");
}
destroyDrawingCache();
mCachingFailed = true;
return;
}
}
这里if判断中会判断当前要生成Bitmap的目标View的位图大小与系统默认支持的最大可生成的缓存大小做对比若目标Bitmap大小大于系统的最大缓存大小，则直接返回Null。我们看下系统最大的支持的缓存Bitmap大小是如何计算的。
final Display display = win.getDefaultDisplay();
final Point size = new Point();
display.getRealSize(size);
mMaximumDrawingCacheSize = 4 * size.x * size.y;
从上述代码上讲，最大缓存大小是 4 * 屏幕宽高 得出。
因此，我们第一个思考，如何去修改最终得目标Bitmap的最终大小呢？使得这个大小小于系统所支持的大小呢？
view.measure(MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED), MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED));
view.layout(0, 0, view.getMeasuredWidth(), view.getMeasuredHeight());
结论就是提前将测量的尺寸设置为零，然后重新布局一下即可，就绕过去了判断大小的限制。
那么引发的第二个思考就来了，既然有大小判断，Google肯定考虑到OOM的问题。那么我们继续往下读源码。
private void buildDrawingCacheImpl(boolean autoScale) {
boolean clear = true;
Bitmap bitmap = autoScale ? mDrawingCache : mUnscaledDrawingCac
if (bitmap == null || bitmap.getWidth() != width || bitmap.getH
Bitmap.Config quality;
if (!opaque) {
switch (mViewFlags & DRAWING_CACHE_QUALITY_MASK) {
case DRAWING_CACHE_QUALITY_AUTO:
case DRAWING_CACHE_QUALITY_LOW:
case DRAWING_CACHE_QUALITY_HIGH:
default:
quality = Bitmap.Config.ARGB_8888;
break;
}
} else {
quality = use32BitCache ? Bitmap.Config.ARGB_8888 : Bit
}
if (bitmap != null) {
bitmap.recycle();
}
try {
// 1
bitmap = Bitmap.createBitmap(mResources.getDisplayMetri
bitmap.setDensity(getResources().getDisplayMetrics().de
if (autoScale) {
mDrawingCache = bitmap;
} else {
mUnscaledDrawingCache = bitmap;
}
if (opaque && use32BitCache) {
bitmap.setHasAlpha(false);
}
} catch (OutOfMemoryError e) {
if (autoScale) {
mDrawingCache = null;
} else {
mUnscaledDrawingCache = null;
}
mCachingFailed = true;
return;
}
clear = drawingCacheBackgroundColor != 0;
}
}
代码1 处发现在创建Bitmap的时候，try了创建Bitmap过程，然后catch了OutOfMemoryError这个错误，笔者在工作中，基本没有对OOME进行catch过，认为OOM是无法被捕捉的，因为他所属一种错误，继承于VirtualMachineError这个父类。然后就写了一个Demo，发现OOM是可以被捕捉的。
try{
varbyte = ByteArray( 10000000* 1024* 1024)
} catch(ignore: OutOfMemoryError) {
// 主动释放一些内存资源
}
因此就引发了一个思考，什么时候需要将OOM捕捉一下呢？
https://www.processon.com/view/5ec74b817d9c08156c58f2b3#map
理论上，Java若抛出了Error的异常，那就说明它的执行状态已经无法恢复了，此时需要终止线程甚至是终止虚拟机。这是一种不应该被我们应用层去捕获的异常。
那么产生OOM，原因之一结合我们本文来说，就是Bitmap过大导致，结合需求，若发现View生成的Bitmap过大，那么就不进行将View转换成Bitmap的操作即可。所以是否需要捕捉OOM，有两个先决条件：
- 触发 OOM 的代码是开发者可控的。
- 在Try包围的代码块中需要进行大段的内存分配，并且有可能导致OOM。
有关于VitualMachineError可以参考这里。
