Android View转Bitmap引发的思考

前言

笔者在最近在做截屏分享的功能，采用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可以参考这里。