我们去手机的目录下看看这两个图片：
我们可以看到图片的大小是一样大的，咦真是奇怪，打开图片看看图片的真实效果如何呢？
对比了下两张图片的清晰度，几乎没什么区别，那怎么回事呢？因此我决定看看这块的代码一探究竟。
二、源码剖析 拿到Uiautomator1.0版本的源码后，我们去找UiDevice。
这里可以看到不带参数的tackscreenshot就是调用了带参数的，只不过给了个默认值而已，那么两张图更应该一样啊，我们接着再往后看：
这里说一下 Tracer 是用来记录跟踪log的，可以忽略。因此我们继续跟进 getAutomatorBridge()：
我们看看这个函数返回的变量是什么：
这里在源码中，我没看到这个类，不过看到了一个 abstract 的UiAutomatorBridge 一个抽象类，那么基本上就确定这二者是集成的关系了，于是打开UiAutomatorBridge，继续寻找 takeScreenshot 函数，果然就找到：
这里面第一步获得Bitmap对象是核心，而获取Bitmap的方法，又和下面这个变量有关系：
看它初始化的位置，那么我们自己构造就有点难了，因此我决定这里按照这个思路来进行反射。
三、反射获取 如果还不懂反射的话，建议先看看我的另一篇讲反射的文章《反射技术引入》。这里我的思路是这样的：
从提供的API getUiDevice()入手，直到拿到Bitmap对象。话不多说，直接看整个的代码实现的过程吧。
拿到Bitmap对象后，我们也参考谷歌的写法，保存到本地，这里可以看到（66行）quality的值我依然给传5。我们执行一下看看结果：
可以看到大小还是一样的，并且我自己打开后发现清晰度也是一样的。这就奇怪了，究竟是怎么回事呢？
四、Google工程师的bug 在图片压缩还不生效的情况下，我们就得仔细看看压缩的代码了。这里我们重点看下高亮的那句代码：
我勾选出的这一句话就是最核心的关键，我们先去查一下这个函数的API用法，不查不知道，一查全明白了：
图中我勾选中的这句话的意思是，对于一些无损的PNG的图片，会忽略quality这个属性的设置。但是我们在源码中却可以看到，谷歌的工程师对于PNG还是使用了压缩，看来得给他提个bug了，哈哈。知道了PNG不能压缩，那么我们把压缩的方式切换成JPEG试试：
screenshot.compress(Bitmap.CompressFormat.PNG,quality, bos);
这句替换为
screenshot.compress(Bitmap.CompressFormat.JPEG,quality, bos);
修改完后，我们运行看看结果：
压缩终于生效了，我们看看真实两张图片的效果：
五、总结 上面已经很详细的描述了如何拿到截图的过程，而然我们在很多图像处理的时候经常会遇到OOM，在深入了解了Bitmap的原理之后才知道，Bitmap对象在内存中的占用非常的高，原因是图片按照长*宽存储，并且每个像素点上可能还有多个位元素，因此加在一起就多了。我们可以看看占内存的情况：
一张1920*1080的图，原始的Bitmap占用为
7.9MB，因此一般对于Bitmap在内存中我们都需要通过BitmapFactory.Options来进行压缩，具体做法我这里就不再赘述了，可以查阅谷歌文档，当然在查阅谷歌问题的时候也要留心他们是否会再写出bug哦~
版权所属，禁止转载
