Android Bitmap转换WebP图片导致损坏的分析及解决方案

96
Abel_Joo
0.1 2016.06.19 22:23* 字数 1885

0x00 背景

作为移动领域所力推的图片格式,WebP图片在商业领域证明了其应有的价值。基于其他格式的横向对比,其在压缩性能表现,及还原度极为优秀,节省大量的带宽开销。基于可观的效益比,团队早前已开始磋商将当前图片资源迁移至.webp资源。

然而对于Android而言,加载.webp图片所消耗的时间比.jpg.png要慢数倍。对于这点而言是无法忍受的。因此解决方案是:

从网络拿到.webp数据流 -> Bitmap通过.png格式保存到本地

注意,整个过程必须在子线程执行。这样,在使用了WebP节省了带宽的同时,下一次加载图片的速度也不会受到影响。

但在客户端实现的最后阶段,出现了一些问题。

图片来自 glennrobinsononline.com

0x01 问题重现

对于上述的解决方案,隐去业务复杂性,我用以下示例来展示:

private void saveImage(String uri, String savePath) throws IOException {

    // 创建连接
    HttpURLConnection conn = createConnection(uri);
    
    // 拿到输入流,此流即是图片资源本身
    InputStream imputStream = conn.getInputStream();

    // 指使Bitmap通过流获取数据
    Bitmap bitmap = BitmapFactory.decodeStream(imputStream);

    File file = new File(savePath);

    OutputStream out = new BufferedOutputStream(new FileOutputStream(file.getCanonicalPath()), BUFFER_SIZE);

    // 指使Bitmap以相应的格式,将当前Bitmap中的图片数据保存到文件
    if (bitmap.compress(Bitmap.CompressFormat.PNG, 100, out)) {
        out.flush();
        out.close();
    }
}

上述代码意图明显:拿到流,将该流通过decodeStream(InputStream)方法传送到Bitmap,随后以.png格式存储到本地。

在很长一段时间内,该代码运作良好。直到有一天,在某国产机型上做测试的时候,发现图片保存到本地后出现了损坏。

那些保存到本地出现损坏的图片,长这样:

损坏的图片

在这张样图中,图片的下半部分出现了缺失。在随后的循环测试中,每张图片的缺失程度大小不一,从完整到全黑都有。

0x02 分析

对于这种情况,第一猜想可能是网络返回的数据流有问题。但在随后的排查中,发现InputStream数据流是完整的。随后开始对图片本身进行分析。

对文件差异进行分析是一种好办法。在这里,使用Beyond Compare以不同的方式进行分析。于是准备了两张图片,一张成功从.webp转为.png,另一张也从.webp转为.png,但是出现缺失黑块。

现在,通过Picture Compare模式直观地对比两张图片:

通过Picture Compare模式对比图片

在这里,左侧为完整图片,右侧为存在数据缺失的图片,下方为差异标记:红色区域为两张图片的差异之处。

可以观察到,相对于完整图片而言,存在数据缺失的图片并非零散地缺失数据,而是从某一刻开始,数据便不复存在了。

为了进一步考究导致差异的根本原因,可以通过Hex Compare模式进行对比。也就是说,以十六进制的方式对比文件。现在,通过Hex Compare模式进行文件对比:

通过Hex Compare模式进行文件对比

左侧的红条表示两个文件中二进制数据不一致的地方。

其中,左侧为完整的.png文件,右侧为存在缺失黑块的.png文件。观察缺失文件的十六进制数据,存在着大量的空值块(0x00000000),并且数据长度是短于完整文件的。同时,此现象与早前出现黑块的规律相似:大块的数据丢失,并非零散的缺失。

但是,文件的分析尚未结束。有一个非常重要的问题不要忽略了:

我们是打开了一张数据损坏的图像吗?

我们知道,如果一个图像文件的关键数据块出现损坏,该图像是无法被打开的。也就是说,如果一个图像文件能够被打开,说明该图像文件结构完整。

那么,如何分析一张图像的数据块是否完整?在这里,我们关心的是:那张缺失的图像,文件末尾写入成功了吗?

在这里有必要解释一下PNG文件末尾的数据块是个什么东西。引用PNG格式标准的官方说法(PNG格式块简述:w3.org):

Chunks can appear in any order, subject to the restrictions placed on each chunk type. (One notable restriction is that IHDR must appear first and IEND must appear last; thus the IEND chunk serves as an end-of-file marker.) Multiple chunks of the same type can appear, but only if specifically permitted for that type.

解释:在整个PNG文件中,用以标记文件开始的IHDR标记必须在文件的最开始,标记文件结束的IEND标记必须在文件的最末端。对于其他数据块则没有顺序要求。

也就是说,如果一张PNG图片能够被打开,那么它在文件的最后,必定存在IEND标记。

回到刚才的Hex Compare,拉到最底部,于是发现:

完整的文件末尾写入

没错。两张图片的末端都有IEND标记。

也就是说,那张存在黑块的.png文件,IO写入并没有问题。随后与手机厂商沟通,问题也近乎尘埃落定:该手机ROM在处理BitmapFactory的底层出现问题。

0x03 解决方案

现在的问题很明确,BitmapFactory中某些native方法存在bug。那是不是所有的native方法都有问题呢?

BitmapFactory.decodeStream(InputStream)方法最终调用的是native方法nativeDecodeStream(InputStream, byte[], Rect, Options)。尝试绕开它试试看。

可否尝试将网络数据流保存到内存,随后再将其指向BitmapFactory?答案是肯定的。我们尝试替换一部分代码。将此部分代码:

// 拿到输入流,此流即是图片资源本身
InputStream imputStream = conn.getInputStream();

// 指使Bitmap通过流获取数据
Bitmap bitmap = BitmapFactory.decodeStream(imputStream);

替换成:

// 拿到输入流,此流即是图片资源本身
InputStream imputStream = conn.getInputStream();

// 将所有InputStream写到byte数组当中
byte[] targetData = null;
byte[] bytePart = new byte[4096];
while (true) {
    int readLength = imputStream.read(bytePart);
    if (readLength == -1) {
        break;
    } else {
        byte[] temp = new byte[readLength + (targetData == null ? 0 : targetData.length)];
        if (targetData != null) {
            System.arraycopy(targetData, 0, temp, 0, targetData.length);
            System.arraycopy(bytePart, 0, temp, targetData.length, readLength);
        } else {
            System.arraycopy(bytePart, 0, temp, 0, readLength);
        }
        targetData = temp;
    }
}

// 指使Bitmap通过byte数组获取数据
Bitmap bitmap = BitmapFactory.decodeByteArray(targetData, 0, targetData.length);

BitmapFactory.decodeByteArray(byte[], int, int)方法最终调用了native方法nativeDecodeByteArray(byte[], int, int, Options),与通过InputStream处理所指向的native方法不同。

经过测试,使用这种方法所保存的.png文件不存在黑块问题。我们无法得知厂商ROM中对于这两种方法有什么差异对待,但至少可以明确:上文中提到的那台国产机子,通过InputStream传递WebP数据并存储为.png图像这一过程存在可预知的bug。

至此,问题分析及解决方案阐述完毕。

0x04 后记

对于这种结论我是跪了一地的。。。

毕竟不是第一次遇到这种问题。每当厂商ROM出现bug,这种锅就得开发者来背。

你总不能等厂商去修复吧?你的App新版还要不要上线?再说了,厂商修复了,用户也未必会去升级。除了少数几个厂商把ROM品牌玩的飞起,其他厂商即使更新ROM版本,能够主动升级的用户也并非多数。

所以,我很讨厌那种所谓“深度定制”的系统。

你说优化系统好不好,我当然支持。但是拜托,要有把握才去改。埋的坑,以后填都填不上,何必呢。老大哥Google写的代码你说不好要去改,改完搞不好就没人维护了。

机友们说得好:Nexus大法好

Abel 的研发路
Web note ad 1