Android中Bitmap内存优化
Android开发中,Bitmap是经常会遇到的对象,特别是在列表图片展示、大图显示等界面。而Bitmap实实在在是内存使用的“大客户”。如何更好的使用Bitmap,减少其对App内存的使用,是Android优化方面不可回避的问题。因此,本文从常规的Bitmap使用,到Bitmap内存计算进行了介绍,最后分析了Bitmap的源码和其内存模型在不同版本上的变化。
Bitmap的使用
一般来说,一个对象的使用,我们会尝试利用其构造函数去生成这个对象。在Bitmap中,其构造函数:
// called from JNI Bitmap(long nativeBitmap, byte[] buffer, int width, int height, int density, boolean isMutable, boolean requestPremultiplied, byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets)
通过构造函数的注释,得知这是一个给native层调用的方法,因此可以知道Bitmap的创建将会涉及到底层库的支持。为了方便从不同来源来创建Bitmap,Android中提供了BitmapFactory工具类。BitmapFactory类中有一系列的decodeXXX方法,用于解析资源文件、本地文件、流等方式,基本流程都很类似,读取目标文件,转换成输入流,调用native方法解析流,虽然Java层代码没有体现,但是我们可以猜想到,最后native方法解析完成后,必然会通过JNI调用Bitmap的构造函数,完成Java层的Bitmap对象创建。
// BitmapFactory部分代码: public static Bitmap decodeResource(Resources res, int id) public static Bitmap decodeStream(InputStream is) private static native Bitmap nativeDecodeStream
native层的代码稍后我们在看,先从Java层来看看常规的使用。典型的一个例子是,当我们需要从本地Resource中加载一个图片,并展示出来,我们可以通过BitmapFacotry来完成:
Bitmap bitmapDecode = BitmapFactory.decodeResource(getResources(), resId); imageView.setImageBitmap(bitmapDecode);
当然,这里简单的使用imageView.setImageResource(int resId)
也能实现一样的效果,实际上setImageResource方法只是封装了bitmap的读入、解析的过程,并且这个过程是在UI线程完成的,对于性能是有所影响的。另外,也对接下来讨论的内容,Bitmap占用的内存有影响。
Bitmap到底占用多大的内存
Bitmap作为位图,需要读入一张图片每一个像素点的数据,其主要占用内存的地方也正是这些像素数据。对于像素数据总大小,我们可以猜想为:像素总数量 × 每个像素的字节大小,而像素总数量在矩形屏幕表现下,应该是:横向像素数量 × 纵向像素数量,结合得到:
Bitmap内存占用 ≈ 像素数据总大小 = 横向像素数量 × 纵向像素数量 × 每个像素的字节大小
单个像素的字节大小
单个像素的字节大小由Bitmap的一个可配置的参数Config来决定。
Bitmap中,存在一个枚举类Config,定义了Android中支持的Bitmap配置:
Config | 占用字节大小(byte) | 说明 |
---|---|---|
ALPHA_8 (1) | 1 | 单透明通道 |
RGB_565 (3) | 2 | 简易RGB色调 |
ARGB_4444 (4) | 4 | 已废弃 |
ARGB_8888 (5) | 4 | 24位真彩色 |
RGBA_F16 (6) | 8 | Android 8.0 新增(更丰富的色彩表现HDR) |
HARDWARE (7) | Special | Android 8.0 新增 (Bitmap直接存储在graphic memory)注1 |
注1:关于Android 8.0中新增的这个配置,stackoverflow已经有相关问题,可以关注下。
之前我们分析到,Bitmap的decode实际上是在native层完成的,因此在native层也存在对应的Config枚举类。
一般使用时,我们并未关注这个配置,在BitmapFactory中,有:
* Image are loaded with the {@link Bitmap.Config#ARGB_8888} config by default. */ public Bitmap.Config inPreferredConfig = Bitmap.Config.ARGB_8888;
因此,Android系统中,默认Bitmap加载图片,使用24位真彩色模式。
Bitmap占用内存大小实例
首先准备了一张800×600分辨率的jpg图片,大小约135k,放置于res/drawable文件夹下:
并将其加载到一个200dp×300dp大小的ImageView中,使用BitmapFactory。
Bitmap bitmapDecode = BitmapFactory.decodeResource(getResources(), resId); imageView.setImageBitmap(bitmapDecode);
打印出相关信息:
图中显示了从资源文件中decode得到的bitmap的长、宽和占用内存大小(byte)等信息。
首先,从数据上可以验证:
17280000 = 2400 1800 4
这意味着,为了将单张800 * 600 的图片加载到内存当中,付出了近17.28M的代价,即使现在手机运存普遍上涨,这样的开销也是无法接受的,因此,对于Bitmap的使用,是需要非常小心的。好在,目前主流的图像加载库(Glide、Fresco等)基本上都不在需要开发者去关心Bitmap内存占用问题。
先暂时回到Bitmap占用内存的计算上来,对比之前定义的公式和源图片的尺寸数据,我们会发现,这张800 600大小的图片,decode到内存中的Bitmap的横纵像素数量实际是:2400 1800,相当于缩放了3倍大小。为了探究这缩放来自何处,我们开始跟踪源码:之前提到过,Bitmap的decode过程实际上是在native层完成的,为此,需要从BitmapFactory.cpp#nativeDecodeXXX方法开始跟踪,这里省略其他decode代码,直接贴出和缩放相关的代码如下:
if (env->GetBooleanField(options, gOptions_scaledFieldID)) { const int density = env->GetIntField(options, gOptions_densityFieldID); const int targetDensity = env->GetIntField(options, gOptions_targetDensityFieldID); const int screenDensity = env->GetIntField(options, gOptions_screenDensityFieldID); if (density != 0 && targetDensity != 0 && density != screenDensity) { scale = (float) targetDensity / density; } } ... int scaledWidth = decoded->width(); int scaledHeight = decoded->height(); if (willScale && mode != SkImageDecoder::kDecodeBounds_Mode) { scaledWidth = int(scaledWidth * scale + 0.5f); scaledHeight = int(scaledHeight * scale + 0.5f); } ... if (willScale) { const float sx = scaledWidth / float(decoded->width()); const float sy = scaledHeight / float(decoded->height()); bitmap->setConfig(decoded->getConfig(), scaledWidth, scaledHeight); bitmap->allocPixels(&javaAllocator, NULL); bitmap->eraseColor(0); SkPaint paint; paint.setFilterBitmap(true); SkCanvas canvas(*bitmap); canvas.scale(sx, sy); canvas.drawBitmap(*decoded, 0.0f, 0.0f, &paint); }
从上述代码中,我们看到bitmap最终通过canvas绘制出来,而canvas在绘制之前,有一个scale的操作,scale的值由
scale = (float) targetDensity / density;
这一行代码决定,即缩放的倍率和targetDensity和density相关,而这两个参数都是从传入的options中获取到的。这时候,需要回到Java层,看看options这个对象的定义和赋值。
BitmapFactory#Options
Options是BitmapFactory中的一个静态内部类,用于配置Bitmap在decode时的一些参数。
// native层doDecode方法,传入了Options参数 static jobject doDecode(JNIEnv* env, SkStreamRewindable* stream, jobject padding, jobject options)
其内部有很多可配置的参数,下面的类图,列举出了部分常用的参数。
我们先关注之前提到的几个密度相关的参数,通过阅读源码的注释,大概可以知道这三个密度参数代表的涵义:
- inDensity:Bitmap位图自身的密度、分辨率
- inTargetDensity: Bitmap最终绘制的目标位置的分辨率
- inScreenDensity: 设备屏幕分辨率
其中inDensity和图片存放的资源文件的目录有关,同一张图片放置在不同目录下会有不同的值:
density | 0.75 | 1 | 1.5 | 2 | 3 | 3.5 | 4 |
---|---|---|---|---|---|---|---|
densityDpi | 120 | 160 | 240 | 320 | 480 | 560 | 640 |
DpiFolder | ldpi | mdpi | hdpi | xhdpi | xxhdpi | xxxhdpi | xxxxhdpi |
inTargetDensity和inScreenDensity一般来说,很少手动去赋值,默认情况下,是和设备分辨率保持一致。为此,我在手机(红米4,Android 6.0系统,设备dpi 480)上测试加载不同资源文件下的bitmap的参数,结果见下图:
以上可以验证几个结论:
- 同一张图片,放在不同资源目录下,其分辨率会有变化,
- bitmap分辨率越高,其解析后的宽高越小,甚至会小于图片原有的尺寸(即缩放),从而内存占用也相应减少
- 图片不特别放置任何资源目录时,其默认使用mdpi分辨率:160
- 资源目录分辨率和设备分辨率一致时,图片尺寸不会缩放
因此,关于Bitmap占用内存大小的公式,从之前:
Bitmap内存占用 ≈ 像素数据总大小 = 横向像素数量 × 纵向像素数量 × 每个像素的字节大小
可以更细化为:
Bitmap内存占用 ≈ 像素数据总大小 = 图片宽 × 图片高× (设备分辨率/资源目录分辨率)^2 × 每个像素的字节大小
对于本节中最开始的例子,如下:
17,280,000 = 800 600 (480 / 160 )^2 * 4
Bitmap内存优化
图片占用的内存一般会分为运行时占用的运存和存储时本地开销(反映在包大小上),这里我们只关注运行时占用内存的优化。
在上一节中,我们看到对于一张800 * 600 大小的图片,不加任何处理直接解析到内存中,将近占用了17.28M的内存大小。想象一下这样的开销发生在一个图片列表中,内存占用将达到非常夸张的地步。从之前Bitmap占用内存的计算公式来看,减少内存主要可以通过以下几种方式:
- 使用低色彩的解析模式,如RGB565,减少单个像素的字节大小
- 资源文件合理放置,高分辨率图片可以放到高分辨率目录下
- 图片缩小,减少尺寸
第一种方式,大约能减少一半的内存开销。Android默认是使用ARGB8888配置来处理色彩,占用4字节,改用RGB565,将只占用2字节,代价是显示的色彩将相对少,适用于对色彩丰富程度要求不高的场景。
第二种方式,和图片的具体分辨率有关,建议开发中,高分辨率的图像应该放置到合理的资源目录下,注意到Android默认放置的资源目录是对应于160dpi,目前手机屏幕分辨率越来越高,此处能节省下来的开销也是很可观的。理论上,图片放置的资源目录分辨率越高,其占用内存会越小,但是低分辨率图片会因此被拉伸,显示上出现失真。另一方面,高分辨率图片也意味着其占用的本地储存也变大。
第三种方式,理论上根据适用的环境,是可以减少十几倍的内存使用的,它基于这样一个事实:源图片尺寸一般都大于目标需要显示的尺寸,因此可以通过缩放的方式,来减少显示时的图片宽高,从而大大减少占用的内存。
前两种方式,相对比较简单。第三种方式会涉及到一些编码,目前也有很多典型的使用方式,如下:
BitmapFactory.Options options = new BitmapFactory.Options(); options.inPreferredConfig = Bitmap.Config.RGB_565; options.inJustDecodeBounds = true; BitmapFactory.decodeResource(getResources(), resId,options); options.inJustDecodeBounds = false; options.inSampleSize = BitmapUtil.computeSampleSize(options, -1, imageView.getWidth() * imageView.getHeight()); Bitmap newBitmap = BitmapFactory.decodeResource(getResources(), resId, options);
原理很简单,充分利用了Options类里的参数设置,也可以从native底层源码上看到对应的逻辑。第一次解析bitmap只获取尺寸信息,不生成像素数据,继而比较bitmap尺寸和目标尺寸得到缩放倍数,第二次根据缩放倍数去解析我们实际需要的尺寸大小。
// Apply a fine scaling step if necessary. if (needsFineScale(codec->getInfo().dimensions(), size, sampleSize)) { willScale = true; scaledWidth = codec->getInfo().width() / sampleSize; scaledHeight = codec->getInfo().height() / sampleSize; }
上图是使用上述手段优化后的结果,可以看到现在占用的内存大小大约为960KB,从优化后的宽高来看,第三种方式并没有效果。应为目标ImageView尺寸也不小,而inSampleSize的值必须是2的整数幂,因此计算得到的值还是1。
PS: Bitmap内存占用的优化还有一个方式是复用和缓存
不同Android版本时的Bitmap内存模型
我们知道Android系统中,一个进程的内存可以简单分为Java内存和native内存两部分,而Bitmap对象占用的内存,有Bitmap对象内存和像素数据内存两部分,在不同的Android系统版本中,其所存放的位置也有变化。Android Developers上列举了从API 8 到API 26之间的分配方式:
API级别 | API 10 - | API 11 ~ API 25 | API 26 + |
---|---|---|---|
Bitmap对象存放 | Java heap | Java heap | Java heap |
像素(pixel data)数据存放 | native heap | Java heap | native heap |
可以看到,最新的Android O之后,谷歌又把像素存放的位置,从java 堆改回到了 native堆。API 11的那次改动,是源于native的内存释放不及时,会导致OOM,因此才将像素数据保存到Java堆,从而保证Bitmap对象释放时,能够同时把像素数据内存也释放掉。
上面两幅图展示了不同系统,加载图片后,内存的变化,8.0的截图比较模糊。途中浅蓝色对应的是Java heap使用,深蓝色对应的是native heap的使用。
跟踪一下8.0的native源码来看看具体的变化:
// BitmapFactory.cpp if (!decodingBitmap.setInfo(bitmapInfo) || !decodingBitmap.tryAllocPixels(decodeAllocator, colorTable.get())) { // SkAndroidCodec should recommend a valid SkImageInfo, so setInfo() // should only only fail if the calculated value for rowBytes is too // large. // tryAllocPixels() can fail due to OOM on the Java heap, OOM on the // native heap, or the recycled javaBitmap being too small to reuse. return nullptr; } // Graphics.cpp bool HeapAllocator::allocPixelRef(SkBitmap* bitmap, SkColorTable* ctable) { mStorage = android::Bitmap::allocateHeapBitmap(bitmap, sk_ref_sp(ctable)); return !!mStorage; } // https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/hwui/Bitmap.cpp static sk_sp<Bitmap> allocateHeapBitmap(size_t size, const SkImageInfo& info, size_t rowBytes) { void* addr = calloc(size, 1); if (!addr) { return nullptr; } return sk_sp<Bitmap>(new Bitmap(addr, size, info, rowBytes)); }
还是通过BitmapFactory.cpp#doDecode方法来跟踪,发现其中tryAllocPixels方法,应该是尝试去进行内存分配,其中decodeAllocator会被赋值为HeapAllocator,通过一系列的调用,最终通过calloc方法,在native分配内存。
至于为什么Google 在8.0上改变了Bitmap像素数据的存放方式,我猜想和8.0中的GC算法调整有关系。GC算法的优化,使得Bitmap占用的大内存区域,在GC后也能够比较快速的回收、压缩,重新使用。
(native存放) | 退出Activity | 退出App |
---|---|---|
onStop中主动调用gc()和recycler() | 内存不释放 | 内存释放 |
无调用 | 内存不释放 | 内存不释放 |
(gpu存放) | 退出Activity | 退出App |
---|---|---|
onStop中主动调用gc()和recycler() | 内存释放 | 内存释放 |
无调用 | 内存释放 | 内存释放 |
总结
// 8.0源码 Bitmap(long nativeBitmap, int width, int height, int density, boolean isMutable, boolean requestPremultiplied, byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) // 7.0源码 Bitmap(long nativeBitmap, byte[] buffer, int width, int height, int density, boolean isMutable, boolean requestPremultiplied, byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets)
一开始看两者java代码不同,少了存放像素的buffer字段,查阅相关资料到native源码对比,最终总结了下Bitmap内存相关的知识。另外,在Android 8.0中,关于Bitmap的改动有两方面还需深入探究的:1、Config配置为Hardware时的优劣。Hardware配置实际上没有改变像素的位储存大小(还是默认的ARGB8888),但是改变了bitmap像素的存储位置(存放到GPU内存中),对实际应用的影响会如何?;2、Bitmap在8.0后又回归到native存放bitmap像素数据,而这部分数据的回收时机和触发方式又是如何?一般测试下,可以通过native分配Bitmap超过1G的内存数据而不发生崩溃。
作者:Dragon_Boat
链接:https://www.jianshu.com/p/3f6f6e4f1c88
来源:简书
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
五分钟学Java:一篇文章带你搞懂spring全家桶套餐
原创声明 本文作者:黄小斜 转载请务必在文章开头注明出处和作者。 本文思维导图 spring全家桶里都有哪些食物 上期我们讲了spring和springmvc两个框架的基础知识和学习路线,而这期内容,我们将围绕着spring全家桶展开来讨论。 大家应该都知道,按照出现的顺序,spring全家桶大概包含了spring、springmvc、springboot以及springcloud,从开胃小菜spring到满汉全席springcloud,spring全家桶可谓Java工程师的必备大餐,那么,我们不妨先来看看,spring全家桶是如何从光杆司令spring发展到如今的庞大家族的。 目前,Spring生态中包含22个主要活跃的项目。 你会发现,这些项目几乎涵盖了日常开发所有的场景,只不过你不一定会用到而已,除了spring和springmvc,springcloud和springboot之外,还有很多开源的spring生态项目持续在spring社区维护,比如springdata,用于解决spring中的统一数据方案,spring integration,顾名思义,适用于集成外部服务。 还有...
- 下一篇
发轫于危机,数字化办公将成新常态
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 从古时候的驿站送信、飞鸽传书到如今的互联网通讯,随着沟通工具的演变,通讯效率也在被不断刷新。而正由于这些技术演变,才能让我们眼下在面对新冠疫情这样的突发状况时,可以突破空间的限制,把生活和工作尽可能地拉回正轨。 我们看到,如今远程办公软件不仅正在被广泛使用,甚至已经成了企业内部沟通的“刚需”,与此同时,企业的许多对外业务开展也正在基于其数字化系统和平台陆续得到恢复。 微软将这总结为线上线下“双核心”复工方式,即基于云计算+云协作、物联网+边缘计算、大数据+人工智能以及混合现实等创新技术,一方面,通过远程办公、远程教育、远程医疗等场景解决方案,助力数字化成为新常态;另一方面,从供应链、生产制造、客户服务、市场营销、人力资源和财务等环节入手,加速企业数字化升级。 复工、看病、上课,在线全搞定 其中,远程办公是各行各业复工最基本的一项需求。对此,微软认为,远程办公不仅仅是远程会议,更包含协作、共享、安全、企业文化等诸多方面。因此,微软提供的是一站式的企业级远程业务及平台,不仅可以使企业一线业务...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装