http://blog.csdn.net/guolin_blog/article/details/42238627
(-)
节制地使用Service
当界面不可见时释放内存
@Override
public void onTrimMemory(int level) {
super.onTrimMemory(level);
switch (level) {
case TRIM_MEMORY_UI_HIDDEN:
// 进行资源释放操作
break;
}
}
使用优化过的数据集合
如SparseArray,SparseBooleanArray,以及LongSparseArray等Android高效加载大图、多图解决方案,有效避免程序OOM 。http://blog.csdn.net/guolin_blog/article/details/9316683
- 使用枚举通常会比使用静态常量要消耗两倍以上的内存,在Android开发当中我们应当尽可能地不使用枚举。
- 任何一个Java类,包括内部类、匿名类,都要占用大概500字节的内存空间。
- 任何一个类的实例要消耗12-16字节的内存开支,因此频繁创建实例也是会一定程序上影响内存的。
- 在使用HashMap时,即使你只设置了一个基本数据类型的键,比如说int,但是也会按照对象的大小来分配内存,大概是32字节,而不是4字节。因此最好的办法就是像上面所说的一样,使用优化过的数据集合。
谨慎使用抽象编程
尽量避免使用依赖注入框架
使用ProGuard简化代码
使用多个进程
<service android:name=".PlaybackService"
android:process=":background" />
(二)
ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getMemoryClass();
系统每进行一次GC操作时,都会在LogCat中打印一条日志
D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <Pause_time>
首先第一部分GC_Reason,这个是触发这次GC操作的原因,一般情况下一共有以下几种触发GC操作的原因:
- GC_CONCURRENT: 当我们应用程序的堆内存快要满的时候,系统会自动触发GC操作来释放内存。
- GC_FOR_MALLOC: 当我们的应用程序需要分配更多内存,可是现有内存已经不足的时候,系统会进行GC操作来释放内存。
- GC_HPROF_DUMP_HEAP: 当生成HPROF文件的时候,系统会进行GC操作,关于HPROF文件我们下面会讲到。
- GC_EXPLICIT: 这种情况就是我们刚才提到过的,主动通知系统去进行GC操作,比如调用System.gc()方法来通知系统。或者在DDMS中,通过工具按钮也是可以显式地告诉系统进行GC操作的。
接下来第二部分Amount_freed,表示系统通过这次GC操作释放了多少内存。
然后Heap_stats中会显示当前内存的空闲比例以及使用情况(活动对象所占内存 / 当前程序总内存)。
最后Pause_time表示这次GC操作导致应用程序暂停的时间。关于这个暂停的时间,Android在2.3的版本当中进行过一次优化,在2.3之前GC操作是不能并发进行的,也就是系统正在进行GC,那么应用程序就只能阻塞住等待GC结束。虽说这个阻塞的过程并不会很长,也就是几百毫秒,但是用户在使用我们的程序时还是有可能会感觉到略微的卡顿。而自2.3之后,GC操作改成了并发的方式进行,就是说GC的过程中不会影响到应用程序的正常运行,但是在GC操作的开始和结束的时候会短暂阻塞一段时间,不过优化到这种程度,用户已经是完全无法察觉到了。
但是目前MAT还是无法打开这个文件的,我们还需要将这个HPROF文件从Dalvik格式转换成J2SE格式,使用hprof-conv命令就可以完成转换工作,如下所示:
- hprof-conv dump.hprof converted-dump.hprof
hprof-conv命令文件存放于<Android Sdk>/platform-tools目录下面。另外如果你是使用的插件版的MAT,也可以直接在Eclipse中打开生成的HPROF文件,不用经过格式转换这一步。
Histogram可以列出内存中每个对象的名字、数量以及大小。List objects -> with incoming references
如果想要查看内存泄漏的具体原因,可以对着任意一个MainActivity的实例右键 -> Path to GC Roots -> exclude weak references
Dominator Tree会将所有内存中的对象按大小进行排序,并且我们可以分析对象之间的引用结构。 Path to GC Roots -> exclude weak references
(三)
http://blog.csdn.net/guolin_blog/article/details/42318689
避免创建不必要的对象
- 如果我们有一个需要拼接的字符串,那么可以优先考虑使用StringBuffer或者StringBuilder来进行拼接,而不是加号连接符,因为使用加号连接符会创建多余的对象,拼接的字符串越长,加号连接符的性能越低。
- 在没有特殊原因的情况下,尽量使用基本数据类来代替封装数据类型,int比Integer要更加高效,其它数据类型也是一样。
- 当一个方法的返回值是String的时候,通常可以去判断一下这个String的作用是什么,如果我们明确地知道调用方会将这个返回的String再进行拼接操作的话,可以考虑返回一个StringBuffer对象来代替,因为这样可以将一个对象的引用进行返回,而返回String的话就是创建了一个短生命周期的临时对象。
- 正如前面所说,基本数据类型要优于对象数据类型,类似地,基本数据类型的数组也要优于对象数据类型的数组。另外,两个平行的数组要比一个封装好的对象数组更加高效,举个例子,Foo[]和Bar[]这样的两个数组,使用起来要比Custom(Foo,Bar)[]这样的一个数组高效得多
静态优于抽象
对常量使用static final修饰符
使用增强型for循环语法
多使用系统封装好的API System.arraycopy()方法将会让执行效率快9倍以上
避免在内部调用Getters/Setters方法
<四>