Android 内存优化 2

转载 2016年08月31日 13:03:38

【前段时间接到任务着手进行app的内存优化,从各种各样的渠道搜索相关资料,最后汇总整理如下。】


一、Android 内存管理

1.1 Dalvik

Dalvik虚拟机是Android程序的虚拟机,是Android中Java程序的运行基础。其指令集基于寄存器架构,执行其特有的文件格式——dex字节码来完成对象生命周期管理、堆栈管理、线程管理、安全异常管理、垃圾回收等重要功能。

Dalvik虚拟机的内存大体上可以分为 Java Object Heap、Bitmap Memory和Native Heap三种。

Java Object Heap:用于分配对象

Bitmap Memory:用来处理图像,≥Android 3.0, 归到Object Heap中

Native Heap: malloc分配,受系统限制

1.2 查看最大内存限制

ActivityManager mActivityManager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
int memoryClass = am. getMemoryClass();              //96MB [Mi2S,Android 4.1]

可以通过在AndroidManifest.xml文件中设置来扩大内存限制:(不过不建议使用此参数,建议节省内存)

int largeMemoryClass = am. getLargeMemoryClass();            //384MB  [Mi2S,Android 4.1]

1.3 垃圾回收(GC)

作用:自动回收不再被引用的Java Object

         


1.4 垃圾回收机制

在2.3之前:

1. Stop-the-world :也就是垃圾收集线程在执行的时候,其它的线程都停止;

2. Full heap collection:一次收集完全部的垃圾;

3. Pause time:≥100ms:一次垃圾收集造成的程序中止时间通常都大于100ms。

在2.3以及更高的版本中:

1. Cocurrent:大多数情况下,垃圾收集线程与其它线程是并发执行的;

2. Partial collection:一次可能只收集一部分垃圾;

3. Pause time:≤5ms:一次垃圾收集造成的程序中止时间通常都小于5ms。

1.5 OutOfMemory Error

主要原因:

1.内存泄露:程序中存在对无用对象的引用,导致GC无法回收。

2.内存超限:保存了多个耗用内存过大的对象(如Bitmap)。

二、内存优化

  • Coding
  • Bitmap
  • ListView
  • SoftReference & WeakReference
  • UI

2.1 Coding

 Tip 1:使用优化过的数据容器。

如SparseArray,SparseBooleanArray,LongSparseArray,代替HashMap

前提:Key为Integer类型

原因:

HashMap 是内存低效的,因为每一个mapping都需要单独的entry(如下图)。

每个元素多占用8byte内存(多了next和hash两个成员变量)。AutoBox【int转Integer,导致产生另一个对象】也会额外加4byte。Entry对象本身至少16byte。

SparseArray可以避免AutoBox,查找方法为二分查找,效率比HashMap低一些,但百量级以内性能差距不大。

 

HashMap<Integer, E> hashMap = new HashMap<Integer, E>();

替换为

SparseArray<E> sparseArray = new SparseArray<E>();、

Tip 2:使用IntentService替代Service。

IntentService优势:

•新开线程;
•顺序处理Intent;
•执行完自动退出。

 说明:

Service是一个没有界面的服务,但其实它不是后台的,所有的代码默认在UI线程执行。若要执行耗时操作,需要新开线程或者使用AsyncTask。

IntentService继承自Service,所以它也是一个服务。

IntentService使用队列的方式将请求的Intent加入队列,然后开启一个worker thread(线程)来处理队列中的Intent,对于异步的startService请求,IntentService会处理完成一个之后再处理第二个,每一个请求都会在一个单独的worker thread中处理,不会阻塞应用程序的主线程。

IntentService与Service区别:
1,Service默认在UI线程执行;而IntentService的onHandleIntent方法在后台执行。
2,Service在start后,如果没有手动stop会一直存在;而IntentService在执行完后自动退出。

Tip 3:尽量避免使用Enum。

枚举相对于静态常量来说,需要两倍甚至更多的内存。如下是Enum的类型定义:

Tip 4:使用混淆器移除不必要的代码。

       ProGuard工具通过移除无用代码,使用语意模糊来保留类,字段和方法来压缩,优化和混淆代码。可以使你的代码更加完整,更少的RAM 映射页。

Tip 5:尽量不要因一两个特性而使用大体积类库。

Tip 6:频繁修改时使用 StringBuffer(Thread-Safe)或 StringBuilder(Thread-Unsafe)。

使用String修改字符串时,若修改后字符串在字符串常量区不存在,便会新生成一个String对象。

Tip 7: 对于常量,请尽量使用static final。

如果使用final定义常量之后,会减少编译器在类生成时初始化<clinit>方法调用时对常量的存储,对于int型常量,将会直接使用其数值来进行替换,而对于String对象将会使用相对廉价的“string constant”指令来替换字段查找表。虽然这个方法并不完全对所有类型都有效,但是,将常量声明为static final绝对是一个好的做法。

Tip 8:对象不用时最好显式置为Null。

对象不用时最好显式置为Null可以减少GC开销。

警惕:静态变量引起内存泄露

这段代码中有一个静态的Resources对象。代码片段mResources = this.getResources()Resources对象进行了初始化。这时Resources对象拥有了当前Activity对象的引用,Activity又引用了整个页面中所有的对象。

如果当前的Activity被重新创建(比如横竖屏切换,默认情况下整个Activity会被重新创建),由于Resources引用了第一次创建的Activity,就会导致第一次创建的Activity不能被垃圾回收器回收,从而导致第一次创建的Activity中的所有对象都不能被回收。这个时候,一部分内存就浪费掉了。

警惕:使用Activity Context引起内存泄露。

 应该尽量使用Application Context。

Android中,Application Context的生命周期和应用的生命周期一样长,而不是取决于某个Activity的生命周期。如果想保持一个长期生命的对象,并且这个对象需要一个Context,就可以使用Application对象。

看使用的周期是否在activity周期内,如果超出,必须用application;常见的情景包括:AsyncTaskThread,第三方库初始化等等。

还有些情景,只能用activity:比如,对话框,各种View,需要startActivity的等。总之,尽可能使用Application


上面由于静态变量导致的内存泄露问题,可以修改如下:

2.2 Bitmap

Tip:捕获异常

因为Bitmap是吃内存大户,为了避免应用在分配Bitmap内存的时候出现OutOfMemory异常以后Crash掉,需要特别注意实例化Bitmap部分的代码。通常,在实例化Bitmap的代码中,一定要对OutOfMemory异常进行捕获。

OutOfMemoryError是一种Error,而不是Exception

Tip:缓存通用的图像【该方法测试无效】

应用场景:默认头像。有时候,可能需要在一个Activity里多次用到同一张图片。比如一个Activity会展示一些用户的头像列表,而如果用户没有设置头像的话,则会显示一个默认头像,而这个头像是位于应用程序本身的资源文件中的。

此方法无效!因为:

因为Android自带资源文件缓存机制:

在Resource.java类中有LongSparseArray<WeakReference<Drawable.ConstantState> > mDrawableCache

每次会new 一个Drawable,但内部bitmap还是指向cache中的。

Tip:压缩图片

BitmapFactory.Options options = new BitmapFactory.Options();

options.inSampleSize = 2;

如果图片像素过大,使用BitmapFactory类的方法实例化Bitmap的过程中,就会发生OutOfMemory异常。

 使用BitmapFactory.Options设置inSampleSize就可以缩小图片。属性值inSampleSize表示缩略图大小为原始图片大小的几分之一。即如果这个值为2,则取出的缩略图的宽和高都是原始图片的1/2,图片的大小就为原始大小的1/4

 如果知道图片的像素过大,就可以对其进行缩小。那么如何才知道图片过大呢?

 使用BitmapFactory.Options设置inJustDecodeBoundstrue后,再使用decodeFile()等方法,并不会真正的分配空间,即解码出来的Bitmapnull,但是可计算出原始图片的宽度和高度,即options.outWidthoptions.outHeight。通过这两个值,就可以知道图片是否过大了。

先获取图片真实的宽度和高度,然后判断是否需要跑缩小。如果不需要缩小,设置inSampleSize的值为1。如果需要缩小,则动态计算并设置inSampleSize的值,对图片进行缩小。

Tip:及时回收Bitmap的内存 (≤Android 2.3.3,API10)

    Bitmap类的构造方法都是私有的,所以开发者不能直接new出一个Bitmap对象,只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap

    仔细查看BitmapFactory的源代码可以看到,生成Bitmap对象最终都是通过JNI调用方式实现的。所以,加载Bitmap到内存里以后,是包含两部分内存区域的。简单的说,一部分是Java部分的,一部分是C部分的。这个Bitmap对象是由Java部分分配的,不用的时候系统就会自动回收了,但是那个对应的C可用的内存区域,虚拟机是不能直接回收的,这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到,recycle()方法里也的确是调用了JNI方法了的。

Tip: BitmapFactory.Options.inBitmap (≥Android 3.0,API11)

作用:内存重用

定义和存储:

Set<SoftReference<Bitmap>> mReusableBitmaps;        //声明
private LruCache<String, BitmapDrawable> mMemoryCache;
 
// If you're running on Honeycomb or newer, create a
// synchronized HashSet of references to reusable bitmaps.
if (Utils.hasHoneycomb()) {         //Android版本判断
    mReusableBitmaps =
            Collections.synchronizedSet(new HashSet<SoftReference<Bitmap>>());      //定义
}
 
mMemoryCache = new LruCache<String, BitmapDrawable>(mCacheParams.memCacheSize) {
 
    // Notify the removed entry that is no longer being cached.
    @Override
    protected void entryRemoved(boolean evicted, String key,
            BitmapDrawable oldValue, BitmapDrawable newValue) {
        if (RecyclingBitmapDrawable.class.isInstance(oldValue)) {
            // The removed entry is a recycling drawable, so notify it
            // that it has been removed from the memory cache.
            ((RecyclingBitmapDrawable) oldValue).setIsCached(false);
        else {
            // The removed entry is a standard BitmapDrawable.
            if (Utils.hasHoneycomb()) {
                // We're running on Honeycomb or later, so add the bitmap
                // to a SoftReference set for possible use with inBitmap later.
                mReusableBitmaps.add
                        (new SoftReference<Bitmap>(oldValue.getBitmap()));    //存入从LRUCache中删除的对象
            }
        }
    }
....
}

使用方法详见:https://developer.android.com/training/displaying-bitmaps/manage-memory.html#inBitmap

限制: 

 before Android 4.4 (API level 19):宽度及高度必须完全相等

 after:尺寸小于等于既有内存

2.3 ListView

Tip:从ContentView获取缓存的view

如果不使用缓存convertView的话,调用getView时每次都会重新创建View,这样之前的View可能还没有销毁,加之不断的新建View势必会造成内存泄露。

Tip:使用ViewHolder模式来避免没有必要的调用findViewById()

ViewHolder模式通过getView()方法返回的视图的标签(Tag)中存储一个数据结构,这个数据结构包含了指向我们要绑定数据的视图的引用,从而避免每次调用getView()的时候调用findViewById()。

2.4 SoftReference & WeakReference

 

软引用

 

只有当内存空间不足了,才会回收这些对象的内存。

 

软引用可用来实现内存敏感的高速缓存。

 

Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();

弱引用

 

被垃圾回收器扫描到后即被回收。

 

Map<String,WeakReference<Bitmap>> cacheMap = new HashMap<String, WeakReference<Bitmap>>();

 

只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中,一旦发现了只具有 弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。不过,由于垃圾回收器是一个优先级很低的线程,因此不一定会很快发现那些只具有弱引用的对 象。

 

 案例:异步加载网络图片

详见:http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2013/0920/1554.html

2.5 UI

Tip 1:利用系统资源

 

说明:

Android系统本身有很多的资源,包括各种各样的字符串、图片、动画、样式和布局等等,这些都可以在应用程序中直接使用。这样做的好处很多,既可以减少内存的使用,又可以减少部分工作量,也可以缩减程序安装包的大小。

Android中没有公开的资源,在xml中直接引用会报错。除了去找到对应资源并拷贝到我们自己的应用目录下使用以外,我们还可以将引用“@android”改成“@*android”解决。

Tip 2:通用模块抽离

<include layout="@layout/navigator_bar" /> 

  • 背景
  • 头部标题栏
  • 底部导航栏
  • ListView

Tip 3:ViewStub

ViewStub是一个隐藏的,不占用内存空间的视图对象,它可以在运行时延迟加载布局资源文件。

定义:

使用:

三、Android 内存监测方法

3.1 adb

adb root
adb shell procrank | grep "com...."【包名】查看概要内存使用情况
或者
adb shell dumpsys meminfo com.*【包名】查看较详细内存使用情况

我们比较关注的几项:
Pss列的TOTAL是APP使用的总内存,也就是在设置中正在运行里面看到的进程使用内存。
Pss列的Dalvik表示APP使用的堆内存。
Pss列的Other dev表示其它设备(如显卡)使用的内存,4.2系统上,开启硬件加速后,这个值会变得很大。

3.2 DDMS

3.3 Memory Analyzer(MAT)

Android性能优化-内存泄漏2

Android使用handler时的内存问题 上篇文章http://blog.csdn.net/qiaoqiao_miss/article/details/52096839 已经介绍来关于And...

android的内存优化分析2【转,超级推荐】

五、超级大胖子Bitmap 可以说出现OutOfMemory问题的绝大多数人,都是因为Bitmap的问题。因为Bitmap占用的内存实在是太多了,它是一个“超级大胖子”,特别是分辨率大的...
  • tonyyxm
  • tonyyxm
  • 2013年06月07日 11:10
  • 761

工作中遇到的Android内存优化问题(2)

Android内存泄露问题,大部分都是对象(Activity,Fragment..)不能被回收,对象中的资源占用内存引起。还有一些包括cursor未关闭,文件流未关闭等(这些可以用StrictMode...

Android 性能优化、内存优化(2) 工具使用

性能调试及定位 主要使用Traceview、monkey、monkey runner调试,traceview类似Java Web调优的visualvm Traceview是Androi...
  • xwqqq
  • xwqqq
  • 2016年07月05日 23:32
  • 995

iOS和android游戏纹理优化和内存优化(cocos2d-x)

1、2d游戏最占内存的无疑是图片资源。 2、cocos2d-x不同平台读取纹理的机制不同。ios下面使用CGImage,android和windows下是直接调用png库。我测试了下,使用png库直...
  • five50
  • five50
  • 2013年07月27日 23:29
  • 1952

iOS和android游戏纹理优化和内存优化(cocos2d-x)

(未完成) 1、2d游戏最占内存的无疑是图片资源。 2、cocos2d-x不同平台读取纹理的机制不同。ios下面使用CGImage,android和windows下是直接调用png库。我测...

OS和android游戏纹理优化和内存优化(cocos2d-x)

1、2d游戏最占内存的无疑是图片资源。 2、cocos2d-x不同平台读取纹理的机制不同。ios下面使用CGImage,android和windows下是直接调用png库。我测试了下,使用png...

android内存优化5—对界面UI的优化(2)

在一个应用程序中,一般都会存在多个Activity,每个Activity对应着一个UI布局文件。一般来说,为了保持不同窗口之间的风格统一,在这些UI布局文件中,几乎肯定会用到很多相同的布局。如果我们在...

[安卓]iOS跟android游戏纹理优化和内存优化(2dx)

原文:http://www.myexception.cn/operating-system/1129989.html 1、2d游戏最占内存的无疑是图片资源。 2、cocos2d-x不同...

iOS和android游戏纹理优化和内存优化(cocos2d-x)

(未完成) 1、2d游戏最占内存的无疑是图片资源。 2、cocos2d-x不同平台读取纹理的机制不同。ios下面使用CGImage,android和windows下是直接调用png库。我测试了下,...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Android 内存优化 2
举报原因:
原因补充:

(最多只允许输入30个字)