Android性能优化-内存篇(其实内存优化也就这回事)

本文讨论了Android开发中的内存优化策略,如预估数组大小减少扩容、避免在for循环中频繁创建StringBuilder、控制枚举使用以减小DEX大小、利用ListView复用和减少布局层级以提高性能、序列化选择Protobuf、数据库减少AUTOINCREMENT使用、Bitmap优化及内存分配、LruCache和BitmapPool缓存管理,以及避免OOM的方法和学习资源分享。
摘要由CSDN通过智能技术生成

如果扩容次数多了,GC的次数也会频繁的增多。

如果我们预先能够知道需要,存储多少个元素,或者大概多少个元素,我们可以使用带参数的构造方法来创建出这个大小的数组,来减少数组扩容的次数。

(4):for循环中不要使用“+”号拼接字符串

“+”底层还是通过StringBuilder实现的,每一次for循环都会创建一个StringBuilder对象。

当我们使用for循环外部创建StringBuilder,内部使用它拼接字符串,内存图形很平稳。

在这里插入图片描述

for循环内部使用+号拼接字符串,图形抖动(内存抖动),一直在GC。

在这里插入图片描述

(5):尽可能少的使用枚举

使用 ENUM 将会增大 DEX 大小,并会增大运行时的内存分配大小。为了弥补 Android 平台不建议使用枚举的缺陷,官方推出了两个注解,IntDef和StringDef,用来提供编译期的类型检查。

在这里插入图片描述

枚举本质上是通过普通的类来实现的,只是编译器为我们进行了处理。每个枚举类型都继承自java.lang.Enum,并自动添加了values和valueOf方法。而每个枚举常量是一个静态常量字段,使用内部类实现,该内部类继承了枚举类。所有枚举常量都通过静态代码块来进行初始化,即在类加载期间就初始化。

(6):ListView复用,对象复用

这个就不多少了,我相信每个Android开发者都知道。

(7):减少布局的层级

减少View的个数,减少测量的时间(View显示在前台,经过三个阶段测量,布局和绘制)。能够减轻内存,CPU的负担。

(8):序列化可以使用Protobuf

Protobuf是谷歌推出的一款平台无关,语言无关,可扩展的序列化和反序列化技术。有兴趣的朋友可以自行了解一个,这里就不多说了。

(9):数据库减少使用AUTOINCREMENT关键字

AUTOINCREMENT关键字的作用保证主键是严格单调递增的。

public static final String CREATE_BOOK = “create table book (”

  • "id integer primary key autoincrement, "//大多数情况下可以去掉

  • "author text, "

  • "price real, "

  • "pages integer, "

  • “name text)”;

db.execSQL(CREATE_BOOK);

如果指定使用AUTOINCREMENT来创建表,会创建sqlite_sequence的内部表来记录该表使用的最大行号,UPDATE,INSERT和DELETE语句可能会修改sqlite_sequence的内容。会带来额外的开销。

SQLite官网:AUTOINCREMENT关键词会增加CPU,内存,磁盘空间和磁盘I/O

的负担,所以尽量不要使用,除非必需。通常情况下非必需。

(10):Bitmap优化

讲到内存优化必不可少的都要提及BitMap优化。因为Bitmap真的是内存占用的大头。

我们的Bitmap占用多大内存呢?下面介绍两个系统提供的api:

bitmap.getAllocationByteCount();

bitmap.getByteCount();

一般情况下两者是相等的;

如果通过复用Bitmap来解码图片,被复用的Bitmap的内存比待分配内存的Bitmap大,那么getByteCount()表示新解码图片占用内存的大小(并非实际内存大小,实际大小是复用的那个Bitmap的大小),getAllocationByteCount()表示被复用Bitmap真实占用的内存大小。

下面我们在说说BitMap的内存分配:

2.3 ~ 7.1:Bitmap的内存是分配在, 虚拟机的 java堆上。受系统分配的虚拟机的内存限制。超出限制OOM,应用程序crash。

8.0以后:内存分配在 native堆,不需要用户主动回收。不受系统分配的虚拟机的内存限制。

超出系统可用内存,进程直接挂掉,无crash弹窗,不会出现OOM。(不能因为内存分配在native上就肆无忌惮的使用图片。)

Android8.0之后源码里通过NativeAllocationRegistry这个类来回收Native层的内存,从而可以实现把bitmap的像素数据放到Native内存中并及时回收。

Java Heap,这部分的内存区域是由虚拟机管理,通过Java中 new 关键字来申请一块新内存。这块区域的内存是由GC直接管理,能够自动回收内存。这块内存的大小会受到系统限制,当内存超过APP最大可用内存时会OOM。

Native Heap,这部分内存区域是在C++中申请的,它不受限于APP的最大可用内存限制,而只是受限于设备的物理可用内存限制。它的缺点在于没有自动回收机制,只能通过C++语法来释放申请的内存。

8.0以前,我们也可以通过特殊的手段将Bitmap的内存分配移至native内存。

Fresco:将Bitmap内存分配至Ashmem内存。

Ashmem(Android匿名共享内存),这部分内存类似于Native内存区,但是它是受Android系统底层管理的,当Android系统内存不足时,会回收Ashmem区域中状态是 unpin 的对象内存块,如果不希望对象被回收,可以通过 pin 来保护一个对象

BitmapFactory.Options = new BitmapFactory.Options();

options.inPurgeable = true;(被废弃)

Bitmap bitmap = BitmapFactory.decodeByteArray(jpeg, 0, jpeg.length, options);

说完上面的我们说说在加载Bitmap的时候,我们通常要做的几个事:

1.计算合适的inSampleSize对图片进行压缩

设置BitmapFactory.Options类的inJustDecodeBounds属性为true,可在Bitmap不被加载到内存的前提下,获取Bitmap的原始宽高。然后通过原始宽高和需要显示控件的宽高计算出合适的inSampleSize(取2的整数次幂,如果不是的话,向下取得最大的2的整数次幂)。对图片进行压缩。

2.设置合适的inPreferredConfig 值

这里我只介绍三个属性:

ALPHA_8:每个像素点仅表示alpha的值,它不会存储任何颜色信息,占8位。

RGB_565:每个像素用5位R/6位G/5位G来表示,占16位。

ARGB_8888:每个像素分别用8位存储ARGB,占32位

如何设置呢?

png图片使用ARGB_8888。(不设置默认使用ARGB_8888)

jpg(24位,32位)使用RGB_565

jpg(8位)使用ALPHA_565

注意了并不是设置RGB_565解码的Bitmap所占用的内存就一定比ARGB_8888小。

下面我们做个小实验,找三张图片分别使用不同的值,去加载这个张图片

png图片在设置三种不同的值所占内存的大小

在这里插入图片描述

jpg(24位,32位)图片在设置三种不同的值所占内存的大小

在这里插入图片描述

jpg(8位)图片在设置三种不同的值所占内存的大小

在这里插入图片描述

第一行是使用ALPHA_565,第二行使用RGB_565,第三行使用ARGB_8888。看完三张图,在看看我上面说的,我相信就已经可以理解了。

3.图片放在合适的文件夹下

目录名称 Density

res/drawable 默认密度(跟随ROM)

res/drawable-hdpi 240

res/drawable-ldpi 120

res/drawable-mdpi 160

res/drawable-xhdpi 320

res/drawable-xxhdpi 480

Android系统在加载这些图片时,会先一步得到当前设备的显示密度,然后到相匹配的drawable的目录下寻找图片资源。如果不存在,会就近获取图片资源,然后将其所在的目录所代表的的密度与当前设备的密度相比,以这个比例来缩放图片。

获取屏幕密度方式:

DisplayMetrics dm = context.getResources().getDisplayMetrics();

int dpi = dm.densityDpi

如果一张大图放在了mdpi目录,而当前设备显示器为480dpi的超高密屏幕。

这时Android就会按照3倍大小来缩放这张图片,将它载入内存。

如果拿不准放入哪个目录,推荐使用Drawable.createFromStream替换getResources().getDrawable来加载,可以绕过Android上面说的默认规则。

4.设置inBitmap属性

4.4之前的版本inBitmap只能够重用相同大小的Bitmap内存区域。简单而言,被重用的Bitmap需要与新的Bitmap规格完全一致,否则不能重用。

4.4之后的版本系统不再限制旧Bitmap与新Bitmap的大小,只要保证旧Bitmap的大小是大于等于新Bitmap大小即可。

使用inBitmap前,每创建一个bitmap需要独占一块内存。

在这里插入图片描述

使用inBitmap后,多个bitmap会复用同一块内存。

在这里插入图片描述

5.缓存策略LruCache

LruCache 顾名思义就是使用LRU缓存策略的缓存,那么LRU是什么呢? 最近最少使用到的(least recently used),就是当超出缓存容量的时候,就优先淘汰链表中最近最少使用的那个数据。

在这里插入图片描述

enryRemoved方法:超出缓存容量的时候,调用的方法。

sizeOf:计算大小的方法。

6.淘汰掉的Bitmap的缓存池BitmapPool

可以使用软引用包装那些被淘汰的对象装载到一个集合中(被淘汰的对象不会被立马回收掉)。可以进行复用。

下面用一张图简单说明一下,图画的不好还请见谅:

在这里插入图片描述

(11):避免OOM

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

总结:

各行各样都会淘汰一些能力差的,不仅仅是IT这个行业,所以,不要被程序猿是吃青春饭等等这类话题所吓倒,也不要觉得,找到一份工作,就享受安逸的生活,你在安逸的同时,别人正在奋力的向前跑,这样与别人的差距也就会越来越遥远,加油,希望,我们每一个人,成为更好的自己。

  • BAT大厂面试题、独家面试工具包,

  • 资料包括 数据结构、Kotlin、计算机网络、Framework源码、数据结构与算法、小程序、NDK、Flutter

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!

,不仅仅是IT这个行业,所以,不要被程序猿是吃青春饭等等这类话题所吓倒,也不要觉得,找到一份工作,就享受安逸的生活,你在安逸的同时,别人正在奋力的向前跑,这样与别人的差距也就会越来越遥远,加油,希望,我们每一个人,成为更好的自己。

  • BAT大厂面试题、独家面试工具包,

  • 资料包括 数据结构、Kotlin、计算机网络、Framework源码、数据结构与算法、小程序、NDK、Flutter
    [外链图片转存中…(img-idc2HiOW-1712229297296)]

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!
  • 17
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值