白夜追凶：手 Q 图片的显示和发送逻辑

腾讯云开发者

于 2017-10-27 17:19:34 发布

阅读量2.3k

点赞数

分类专栏：前端文章标签： android 图像处理图片开发

本文链接：https://blog.csdn.net/QcloudCommunity/article/details/78367108

版权

前端专栏收录该内容

19 篇文章 0 订阅

订阅专栏

欢迎大家前往腾讯云社区，获取更多腾讯海量技术实践干货哦~

作者：陈舜尧

导语： “这张图片在快捷发图栏背景是黑色的，为啥发到AIO（会话窗口）里背景就变成白的了？” 通过一个bug单，对黑白背景问题跟进的过程中发现了手q中很多奇怪的表现。一层层看代码，整理总结了手q中图片的显示和发送逻辑，以及对透明通道图片的特殊处理。

一、黑背景？白背景？

这张图片在快捷发图栏背景是黑色的，发到AIO里背景就变成白的了。拿到问题，分析有两种可能原因：展示view的背景色不一致；选中的png图片的透明通道在AIO和快捷发图栏两个不同的场景下过滤规则不一致。

很容易就能发现两个场景处理图片的不同：快捷发图栏将png图片获取为bitmap，再压缩成jpeg，这个过程直接忽略了透明通道，android默认处理的结果就是一张黑色背景的jpeg。快捷发图栏所有图片的字节流持久化到同一个文件里，这样做的目的是下次从本地加载多张图片时，会共用同一个文件IO，提高加载效率；

AIO中的缩略图也是由原图压缩成jpeg，在处理的代码中，我发现了人为加白色背景的逻辑，原来这都是产品的策略，可能考虑到AIO中png图片黑色背景视觉上不太美观，所以进行了特殊处理。然而快捷发图栏和AIO中视觉上没做到统一，有道是产品拍头一时爽，开发解bug火葬场

二、都是png，怎么有黑又有白！

既然问题找到了，美滋滋的准备加个鸡腿，然而事情并没有那么简单！回归问题的时候我用了另外一张png图片测试，咦，怎么这张图片在AIO中背景是黑色的？

有两个怀疑方向：1、png压缩成jpeg的过程，丢失透明通道导致AIO中这张图片为黑色背景；2、有没有可能是在canvas上绘制白色背景失败导致的该问题？

先从第一个方向分析，通过BitmapFactory.decode把png输出为bitmap，再把白底、bitmap依次绘到canvas上，期间旋转信息的处理、对长图的特殊处理、subSample这里就不展开了。这里怀疑png输出为bitmap时，透明通道丢失。

我们知道ARGB指的是一种色彩模式，里面A代表Alpha，R表示red，G表示green，B表示blue，其实所有的可见色都是右红绿蓝组成的，所以红绿蓝又称为三原色，每个原色都存储着所表示颜色的信息值，Bitmap.Option中config的值有下面几种，ALPHA_8 代表8位Alpha位图，ARGB_4444 代表16位ARGB位图，ARGB_8888 代表32位ARGB位图，RGB_565 代表16位RGB位图。有没有可能是png输出为bitmap的过程中，有奇葩的策略调整config的值导致ALPHA通道遗失？于是一步步断点跟踪这块的代码，很遗憾没发现异常。

再看看第二个方向，我们review下加白色背景的代码（见上图），Paint设置了Xfermode。PorterDuff.Mode能设置canvas绘图时不同图层的混合方式，下图展示了不同的混合方式。我们处理是将图片bitmap叠加到白色背景上，这里SRC_OVER看上去也没问题。。。

啪啪啪打脸，看来不是怀疑的两个方向出了问题。于是病急乱投医把锅甩给了图片。。。。。

“会不会是png格式的问题，png某个参数导致转化过程中bitmap背景不同？？？？”

在查阅资料、用工具分析对比了两张png图片的结构，欣喜得发现问题跟png格式并没有半毛钱关系。冷静下来，还是用老办法，一步一步跟代码！！！！

游戏图压缩后P2大于P1（是的你没看错，压缩后图片反而大，压缩步骤取bitmap，再绘制，最后质量压缩成jpeg），所以是拿原始图片当作大图P3去生成缩略图P4，原始图片有透明通道，所以对应的缩略图能加上白色背景；骰子图片压缩后发现比原图小，所以用压缩图P2当作大图P3去生成缩略图P4。P2是质量压缩png生成的jpeg，已经丢失透明通道，是一张黑色背景的图。即使在P4加上白色背景也被上层图层覆盖，我们看到的就是黑色骰子缩略图。

我之前分析的过程中忽略了压缩原始图片生成P2这一步。一叶障目，理清了思路，问题就显而易见了！