1. Android2.x及以下的系统优化:
Bitmap被解码后的像素被存储在Native Heap中,
Dalvik Heap有个external计数,记录了Bitmap所占用的内存。
当 Dalvik Allocated + External Allocated + new Allocated>= 允许分配最大值时,就会引发OutOfMemoryError异常,
销毁的时候必须要调用recycle()
。BitmapFactory.Options
参数,隐藏了inNativeAlloc
属性,
可以使Bitmap的内存不算在Dalvik Heap中。
2. Android 3.x及以上的系统优化:
Bitmap被解码后的像素被存储在Java Heap,只要Bitmap没有
被引用,在内存紧张时就会被回收,不需要主动调用recycle。只有当 Dalvik Allocated + new Allocated>= 允许分配最大值时,
就会引发OutOfMemoryError异常,BitmapFactory.Options参数,有个inPurgeable属性,开启后像素会存储在Native Heap中,
有个缺陷就是,在Bitmap显示时如何Native Heap中没有缓存,又需要重新解码,会阻塞UI线程。
可以在jni层通过AndroidBitmap_lockPixels把解码后的内存锁住,防止被回收,然后在不适用时通过AndroidBitmap_unlockPixels(env, zBitmap)
来取消加锁(可以参考Fresco的实现)
3. AndroidManifest.xml设置largeHeap=true
ActivityManager.getMemoryClass()
可以获取dalvik.vm.heapgrowthlimitd
的值,单位MBActivityManager.getLargeMemoryClass()
可以获取dalvik.vm.heapsize
的值,单位MBRuntime.getRuntime().maxMemory()
获取当前VM的最大可用内存,单位Byte
4. 对Bitmap的创建封装统一的入口
使用LruCache减少Bitmap频繁的create
尽量使用decodeStream代替decodeResource decodeFile
使用catch,当发生OOM时,主动执行GC,降低图片灰度值,再次创建
根据view的实际大小来解码相应大小的bitmap
5. 防止内存泄露
避免使用生命周期长的对象应用生命周期短的对象(使用 static关键字,单例中的引用)
注意注册与反注册配对使用
使用leakcanary工具来动态追踪内存泄露,使用MAT来静态分析内存泄露。
6.不要频繁的分配大内存对象,不适用的对象提前置NULL,提前回收。