优化Android工程中的图片资源

场景

在一些上古工程中，因为年久失修，架构演进跟不上业务发展须要，会衍生出很是多比较明显的性能问题，其中就包括工程中图片资源的问题。

最明显的例子就是，工程中的图片资源未经任何压缩，直接使用来自设计稿中的原图，很是占用安装包体积；其次，显示效果不理想，在对应分辨率的图片资源文件夹中放入了错误尺寸的图片，致使应用运行时 UI 图片出现模糊、大颗粒等状况。

优化方案

压缩图片资源文件夹的大小

优化工做每每要从业务入手，在业务发展方向明确的前提下，并非全部的 UI 效果都须要用图片文件的方式进行显示，对于一些简单的 UI，能够考虑使用代码进行绘制。使用代码绘制能够极其明显的减小图片对硬件资源的占用，一来能够减少包体积，二来一般能够减少运行时的内存。

对于一些必须须要经过图片文件来实现的 UI 效果，也须要对图片文件进行相应的压缩后再放入对应分辨率的文件夹，能够考虑无损压缩和有损压缩。

这里重点提下有损压缩，并非全部的有损压缩都会直接影响 UI 呈现的，若是事先获知应用所运行的设备屏幕硬件自己色彩还原度不好，尺寸较小，分辨率也较低，那么有损压缩每每是更具性价比的选择。

注意这里的压缩不仅仅指图片质量的压缩，同时也包括图片尺寸的缩放。对于一些特定设备屏幕尺寸，咱们能够限定一个最大的图片尺寸做为约束。

检查对应分辨率资源文件夹下的图片

种种缘由下，代码工程中每每会存在对于分辨率资源文件夹下放错图片资源的状况。

好比，在 drawable-xxhdpi 下放入了本应该放在 drawable-mdpi 的图片资源，那么最终的 UI 呈现就可能会出现模糊、大颗粒、锯齿感等状况。

好比下图，在一个 xhdpi 的设备中，实际加载了 mdpi 的图片资源，致使出现 UI 模糊状况。

定义一个 48dp×48dp 的控件，实际控件大小为 96px×96px

<ImageView    android:id="@+id/iv"    android:src="@mipmap/ic_launcher"    app:layout_constraintBottom_toBottomOf="parent"    app:layout_constraintTop_toTopOf="parent"    app:layout_constraintRight_toRightOf="parent"    app:layout_constraintLeft_toLeftOf="parent"    android:layout_width="48dp"    android:layout_height="48dp"/>
复制代码

若是放错了图片资源，则实际加载了 48px×48px 大小的图片。

将应用进行截图，放大后能够很明显看到模糊状况。

提供两种方案供参考。

第一种是运行时检查，结合 BitmapCanary 工具，判断应用运行时 UI 控件是否加载了对应尺寸的图片，若是加载的图片资源尺寸小于控件自身的尺寸，那么就须要特别关注，并返回代码工程中进行修改。

第二种是开发时检查，经过脚本工具遍历工程图片资源文件夹中的图片文件，逐一检查图片尺寸，结合咱们以前定义过的图片最大尺寸约束，能够剔除并发现放错的图片资源，再针对筛选出的这些特定的图片资源做压缩和缩放。

优化工具

为了让优化工具更加通用，我编写了 ImageRes361Tool 工具，它的工做流程和架构图以下。

架构图

• ImageRes361Tool 层：应用层，负责一键执行
• ImageFinder 层：负责查找工程中不合规的图片资源
• ImageSaver 层：保存图片
• Config 层：配置压缩等级、策略以及目标文件夹
• ImageCompressTool 层：包装图片压缩功能，简化压缩 API
• PIL、OpenCV 层：负责压缩、处理图片
• Logger 层：记录日志
• Thread 层：多线程操做，提高执行效率

工做流程

使用流程

python 环境

python3 环境要求

输入工程地址

回车运行

最终效果

以工程中其中一个 module 为例，清理掉超出图片最大尺寸约束的图片后，图片资源大小能够由 4.4Mb 锐减至 88Kb ；检查并修改对应分辨率的图片资源后，应用运行时再也不出现 UI 模糊的状况。

后记

优化类工做每每解决的不单单是技术问题，更是管理问题。

制定了开发标准可否顺利执行？架构演进可否跟上业务的不断发展？为了性能指标可否排除万难团结协做？......

管理类问题只能交由管理解决，毫不是某个技术工具就能解决得了的。

看着那些来自大厂的头部 APP，白屏、卡顿、高内存占用等都很是常见，再加上给用户定制的“私人专属”开屏广告，使得启动速度异常地慢。从用户体验的角度来讲，不可谓优秀。是它们的技术力不够吗？

应该不是。