- 在内存引用上做些处理,常用的有软引用、弱引用
- 在内存中加载图片时直接在内存中作处理,如:边界压缩
- 动态回收内存
- 优化Dalvik虚拟机的堆内存分配
- 自定义堆内存大小
内存优化
核心思想:减少内存使用,能不new的不new,能少分配的少分配。因为分配更多的内存就意味着发生更多的GC,每次触发GC都会占用CPU时间,影响性能。
- 集合优化:Android提供了一系列优化过后的数据集合工具类,如SparseArray、SparseBooleanArray、LongSparseArray,使用这些API可以让我们的程序更加高效。HashMap工具类会相对比较低效,因为它需要为每一个键值对都提供一个对象入口,而SparseArray就避免掉了基本数据类型转换成对象数据类型的时间。
- Bitmap优化:读取一个Bitmap图片的时候,千万不要去加载不需要的分辨率。可以压缩图片等操作。
- 尽量避免使用依赖注入框架。
- 避免创作不必要的对象:字符串拼接使用StringBuffer,StringBuilder。
- onDraw方法里面不要执行对象的创建.
- 重写onTrimMemory,根据传入的参数,进行内存释放。
- 使用static final 优化成员变量。
作者:Maat红飞
链接:http://www.jianshu.com/p/89f19d67b348
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
1.2:软引用
软引用是主要用于内存敏感的高速缓存。在jvm报告内存不足之前会清除所有的软引用,这样以来gc就有可能收集软可及的对象,可能解决内存吃紧问题,避免内存溢出。什么时候会被收集取决于gc的算法和gc运行时可用内存的大小。
上面两种方式第一种直接使用边界压缩,第二种在使用边界压缩的情况下间接的使用了软引用来避免OOM,但大家都知道,这些函数在完成decode后,最终都是通过java层的createBitmap来完成的,需要消耗更多内存,如果图片多且大,这种方式还是会引用OOM异常的
1. InputStream is = this.getResources().openRawResource(R.drawable.pic1);
BitmapFactory.Options options=new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = 10; //width,hight设为原来的十分一
Bitmap btp =BitmapFactory.decodeStream(is,null,options);
2. if(!bmp.isRecycle() ){
bmp.recycle() //回收图片所占的内存
system.gc() //提醒系统及时回收
}
大家可以选择在合适的地方使用以下代码动态并自行显式调用GC来回收内存:
if(bitmapObject.isRecycled()==false) //如果没有回收
bitmapObject.recycle();
4:这个就好玩了,优化Dalvik虚拟机的堆内存分配,听着很强大,来看下具体是怎么一回事
对于Android平台来说,其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理,比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理,使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率