图片放错位置后引发的Drawable内存溢出问题

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/lixuce1234/article/details/78920411

最近再项目开发的时候遇到了一个内存溢出的问题,害怕被祭天,所以赶紧检查出问题的地方,在网上查到了很多资料,说是由切图的放置位置导致,原来我把一张大图直接放到了drawble文件夹下面,没有放到相应的drawble分辨率下面,界面View加载图片的时候,会造成图片占用内存过大,然后就导致部分机型打开引用这张大图这个界面的时候特别卡,甚至有的会直接Crash掉。

那么导致这个问题的根本原因是什么呢?通过在网络上面查资料,和自己亲自实验,得出了一些结论,下面给大家分享一下



实验内容


因为网上有人说是因为图片没有放到相应的分辨率包下面,加载内存过大导致的,所以我觉得把同一张图片放到不同的分辨率的包下面,然后运行再同一设备上,看看对图片的大小以及内存占用有什么影响。


测试环境


采用华为荣耀5C手机(1080*1960,xxhdpi)进行测试

对于内存的查看,使用AS自带的内存查看工具。

图片大小使用如下代码获取




研究过程

下面就是测试的过程,我会用截图来说明过程

我测试用的是一张750 *1334分辨率的png图片,占用磁盘内存260.89kb,

下面给出测试代码


1.没有设置图片的情况下  APP图片资源占用内存是11.81MB截图如下


2.将图片放到drawable文件夹下面,然后图片的大小为2250*4002 ,图片资源占用内存是46.98MB

3.将图片当道drawable-hdpi文件夹下面,图片的大小为1500*2668

图片资源Graphics占用内存是27.39MB

4.将图片当道drawable-xhdpi文件夹下面,图片的大小为1125*2001

图片资源Graphics占用内存是20.66MB

5.将图片当道drawable-xxhdpi文件夹下面,图片的大小为750*1334(原图大小一致)

Graphics占用内存是15.7MB

6.将图片当道drawable-xxxhdpi文件夹下面,图片的大小为563*1001,Graphics占用内存14.1MB




结果分析


从上面的测试结果,我们可以得出如下结论:


  1. 同一张图片,放在不同目录下,会生成不同大小的Bitmap

  2. Bitmap的长度和宽度越大,占用的内存就越大

  3. 图片在硬盘上占用的大小,与在内存中占用的大小完全不一样


下面我会对上面几个问题一一解释。

我们以放在drawable文件夹下面的图片为例,加载到内存之后,2250*4002 大小的Bitmap占用的内存为

2250*4002  * 4 = 3601,8000 byte = 3,5173kb = 34.34944 M

所以drawable文件夹下的App内存占用 = 原始内存11.81MB+图片内存34.34944MB= 46.16MB ,与实际内存占用46.98MB存在0.1755%的误差,在误差范围之内。

先简单解释一下上面的计算公式,长*宽是图片的像素总数,乘以4则是因为一个像素占用A、R、G、B四个通道,每个通道占用8位,所以描述一个像素需要32位即4个字节。

一个颜色通道需要8位描述,2^8=256,所以每个颜色通道就有256种状态。如果把彩色图转化成灰阶图的话,也有256种状态分割从白色到黑色之间的过渡颜色。

当然,也并不是所有格式的图片每个像素占用4字节,这和图片在加载时设置的Bitmap.Config有关,默认的是Bitmap.Config.ARGB_8888,其他类型如下:

Bitmap.Config.ALPHA_8 此时图片只有alpha值,没有RGB值,
一1个像素占用一个字节

Bitmap.Config.ARGB_4444 一个像素占用2个字节,alpha(A)值,Red(R)值,Green(G)值,Blue(B)值各占4个bites共16bites,即2个字节

Bitmap.Config.ARGB_8888 一个像素占用4个字节,alpha(A)值,Red(R)值,Green(G)值,Blue(B)值各占8个bites,共32bites,即4个字节。这是一种高质量的图片格式,在电脑上普通采用。它也是Android手机上一个Bitmap的默认格式。

Bitmap.Config.RGB_565 一个像素占用2个字节,没有alpha(A)值,即不支持透明和半透明,Red(R)值占5个bites ,Green(G)值占6个bites ,Blue(B)值占5个bites,共16bites,即2个字节。对于没有透明和半透明颜色的图片来说,该格式的图片能够达到比较的呈现效果,相对于ARGB_8888来说也能减少一半的内存开销。因此它是一个不错的选择。

那么为啥在硬盘上存储只需要200多k,放到内存里面就需要30多M呢?

因为这根本不是一回事呀~

存放在硬盘上的图片文件,会根据各自的压缩规则进行压缩,比如Jpeg这种有损压缩的图片格式,最常使用可变字长编码的哈弗曼编码,会使用哈弗曼树,也就是最优二叉树,根据某些数据出现的频率对数据段编码,从而减少占用的硬盘大小。

比如说“10111”这个序列在图片的二进制数据中出现的概率最大,那我们可以用“01”来代替这一段数据,原来5位的数据,用2位就可以表示了,这就是压缩率60%。当然这只是打个比方,在实际操作中需要考虑“异前缀原则”等编码的基本原则。

而如果把图像读取到内存中就不一样了,因为我们需要每一个像素都能在屏幕上显示,所以会把每个像素点都加载至内存中,不会对相同像素进行压缩或者是替换,所以你也应该能明白前面提到的Bitmap占用内存大小的计算公式的由来了。

说到这里,其实后两个结论已经解释清楚了,那么为什么“同一张图片,放在不同目录下,会生成不同大小的Bitmap”呢?


我的测试设备为华为荣耀5C,1080*1960,xxhdpi,所以说,如果把这张放置在xxhdpi的话,应该不会对图像进行放缩,也就是原始大小,所以我们在前面得到drawable-xxhdpi文件夹下,图片大小为750 * 1334是完全可以理解的,就是图片本身的大小。

当图片放置在drawable-hdpi中时,图片大小为1500*2668,长宽变为原来的两倍,这是因为不同分辨率之间的倍数关系导致的,来一张图

我们可以很明显的看到xxhdpi是hdpi的2倍,所以如果单独放置在某个drawable文件夹,手机会自动根据当前的屏幕密度对图片进行放缩。

比如上面,当把图片放置在xxxhdpi里面的时候,在xxhdpi的设备上,图片长 = 750 * (3/4) =563,图片宽 = 1280 * (3/4) = 1001,这与上面的测试结果是完全一致的。

至于为什么在前面的测试中,drawable和drawable-mdpi是一样的大小,是因为drawable-mdpi是系统默认的像素密度,其他像素密度都以它为基数,当只在drawable中存在图片时,如果使用该图片,那么将按照drawable-mdpi的放缩比例进行放缩。



最后的结论

从上面的测试我们可以得出以下几个结论:


  1. 当图片放置在不同drawable文件夹中,且只有这一张图片时,运行设备会根据自身的屏幕密度,对图片进行放缩,放缩比例符合前面图上的规则

  2. 图片文件的大小与在内存中占用的大小没关系,内存中实际占用大小与图片分辨率、像素显示参数有关


所以,在一个App里面使用一套UI理论上应该是没有问题的,但是要注意

最好使用较高分辨率的切图,并且放置在正确的drawable文件夹中,比如按照xxhdpi的分辨率进行切图,放置在drawable-xxhdpi中

对于可以使用.9格式的图片,最好使用.9,减少资源大小

如果有条件,最好提供多套UI切图。如果只有一套切图,系统需要对图片进行压缩,会进行大量运算,影响设备性能。同时,在某些情况下,系统对图片的压缩会可能会出现锯齿,造成信息的丢失

如果是多套切图的话,最好不要直接用工具按照比例放缩,这样小图标会丢失一些细节。当然,这部分是美工来做的,

说到这里大家就明白我上面说的那个Crash问题了,思考一下,如果把一个本来应该放在drawable-xxhdpi里面的图片放在了drawable文件夹中会出现什么问题呢?

在xxhdpi设备上,图片会被放大3倍,图片内存占用就会变为原来的9倍!



下面还有一个小提示,因在再网上查询资料的时候,有些人说把图片放到mipmap下面就没事了,通过上面的实现说明这个说法是不科学的,然后又通过查看官方API,看到了这样一段话

在Android studio中,同时存在drawable目录和mipmap目录,二者没有明显区别,但是工作机制还是存在差别。

谷歌官方: 
drawable/ 
For bitmap files (PNG, JPEG, or GIF), 9-Patch image files, and XML files that describe Drawable shapes or Drawable objects that contain multiple states (normal, pressed, or focused). See the Drawable resource type. 
mipmap/ 
For app launcher icons. The Android system retains the resources in this folder (and density-specific folders such as mipmap-xxxhdpi) regardless of the screen resolution of the device where your app is installed. This behavior allows launcher apps to pick the best resolution icon for your app to display on the home screen. For more information about using the mipmap folders, see Managing Launcher Icons as mipmap Resources.

谷歌官方没有推荐图片放在mipmap中!!!

谷歌官方没有推荐图片放在mipmap中!!!

谷歌官方没有推荐图片放在mipmap中!!!

官方解释: 
mipmap——用于存放原生图片(图ic_launcher.png),缩放上有性能优化; 
drawable——存放图片、xml,和Eclipse没有区别;

总结起来意思就是  

使用上没有任何区别,你把它当drawable用就好了。

但是用mipmap系统会在缩放上提供一定的性能优化。

当你只有一套切图的时候,就把图片放到mipmap下面把,会对你的性能有所优化。


大家都有了以上相同的教程,但是人和人之间的区别在于:别人有颗更强大的内心,可怕的是比你聪明的人比你还要更努力!!

  • 当你下定决心,准备前行的时候,剩下的只有坚持了。。。


  • 大家如果觉得我写的还可以的话,请关注我的微信公众号


猜你喜欢

转载自blog.csdn.net/lixuce1234/article/details/78920411