注册

优化Android工程中的图片资源

场景


在一些上古工程中,由于年久失修,架构演进跟不上业务发展需要,会衍生出非常多比较明显的性能问题,其中就包括工程中图片资源的问题。


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


优化方案


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


优化工作往往要从业务入手,在业务发展方向明确的前提下,并不是所有的 UI 效果都需要用图片文件的方式进行显示,对于一些简单的 UI,可以考虑使用代码进行绘制。使用代码绘制可以极其明显的减少图片对硬件资源的占用,一来可以减小包体积,二来通常可以减小运行时的内存。


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


这里重点提下有损压缩,并不是所有的有损压缩都会直接影响 UI 呈现的,如果事先获知应用所运行的设备屏幕硬件本身色彩还原度很差,尺寸较小,分辨率也较低,那么有损压缩往往是更具性价比的选择。


注意这里的压缩不单单指图片质量的压缩,同时也包括图片尺寸的缩放。对于一些特定设备屏幕尺寸,我们可以限定一个最大的图片尺寸作为约束。


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


种种原因下,代码工程中往往会存在对于分辨率资源文件夹下放错图片资源的情况。


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


image.png


比如下图,在一个 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 大小的图片。


image.png 将应用进行截图,放大后可以很明显看到模糊情况。


image.png


提供两种方案供参考。


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


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


优化工具


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


架构图


image.png



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

工作流程


image.png


使用流程


python 环境


python3 环境要求


输入工程地址


image.png


回车运行


image.png


最终效果


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


后记


优化类工作往往解决的不仅仅是技术问题,更是管理问题。


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


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


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


应该不是。


作者:彭也
链接:https://juejin.cn/post/6983925947929985061
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

0 个评论

要回复文章请先登录注册