这两天遇到这样一个事情,因为某测试任务,需要在操作过程中连续的截图,最终分析截图。之前同事用的工具兼容性特别的不好,需要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。我们执行一下看看结果:
可以看到大小还是一样的,并且我自己打开后发现清晰度也是一样的。这就奇怪了,究竟是怎么回事呢?
在图片压缩还不生效的情况下,我们就得仔细看看压缩的代码了。这里我们重点看下高亮的那句代码:
我勾选出的这一句话就是最核心的关键,我们先去查一下这个函数的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哦~