带你寻找谷歌的bug

一、需求

这两天遇到这样一个事情，因为某测试任务，需要在操作过程中连续的截图，最终分析截图。之前同事用的工具兼容性特别的不好，需要root，并且只适配固定几个版本的机型，因此我决定自己实现一个。首先最先想到的就是使用Uiautomator 1中自带的API来截图。

这里我在Uiautomator（对Uiautomator还不熟悉的同学请参考我的Uiautomator系列的三篇文章，可以查看公众号的历史文章）中实现了如下的代码：

　　我们去手机的目录(/storage/emulated/0)下看看这两个图片：

我们去手机的目录下看看这两个图片：

　　我们可以看到图片的大小是一样大的，咦真是奇怪，打开图片看看图片的真实效果如何呢？

　　对比了下两张图片的清晰度，几乎没什么区别，那怎么回事呢？因此我决定看看这块的代码一探究竟。

二、源码剖析

拿到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哦~