Android 内存优化测试

最新推荐文章于 2023-04-03 13:37:43 发布
最新推荐文章于 2023-04-03 13:37:43 发布
阅读量794 收藏
点赞数
分类专栏： android 内存

关注我的新浪微博,了解更多有用的信息. http://weibo.com/u/1791263207?topnav=1&wvr=5

今天做了个内存优化的小测试，包括两点

 

1，  比较Drawable与Bitmap占用内存大小

2，  比较BitmapFactory类的decodeResource方法与decodeStream方法的效率

 

 

 

 

好吧，先来看第1个测试！

以下这个是测试加载1000个Drawable对象的代码，很简单的，我就不解释了！

 

public class Main extends Activity

{

    int number = 1000;

    Drawable[] array;

 

    @Override

    public void onCreate(Bundle savedInstanceState)

    {

       super.onCreate(savedInstanceState);

       setContentView(R.layout.main);

 

        array = new BitmapDrawable[number];

                     

        for(int i = 0; i < number; i++)

        {

            Log.e("", "测试第" + (i+1) + "张图片");

            array[i] = getResources().getDrawable(R.drawable.img);

        }

    }

}

 

 

输出结果：

04-07 21:49:25.248: D/szipinf(7828): Initializing inflate state

04-07 21:49:25.398: E/(7828): 测试第1张图片

04-07 21:49:25.658: D/dalvikvm(7828): GC_EXTERNAL_ALLOC freed 48K, 50% free 2692K/5379K, external 0K/0K, paused 24ms

04-07 21:49:25.748: E/(7828): 测试第2张图片

04-07 21:49:25.748: E/(7828): 测试第3张图片

………………

………………

04-07 21:49:26.089: E/(7828): 测试第998张图片

04-07 21:49:26.089: E/(7828): 测试第999张图片

04-07 21:49:26.089: E/(7828): 测试第1000张图片

 

程序没有报错，正常运行，加载1000个Drawable对象没问题。

 

下面再来看一下加载1000个Bitmap对象的代码，同样的，代码很简单的，我就不解释了！

public class Main extends Activity

{

    int number = 1000;

    Bitmap bitmap[];

 

    @Override

    public void onCreate(Bundle savedInstanceState)

    {

       super.onCreate(savedInstanceState);

       setContentView(R.layout.main);

 

       bitmap = new Bitmap[number];

 

       for (int i = 0; i < number; i++)

       {

           Log.e("", "测试第" + (i+1) + "张图片");

           bitmap[i] = BitmapFactory.decodeResource(getResources(), R.drawable.img);

       }

    }

}

 

输出结果：

04-07 22:06:05.344: D/szipinf(7937): Initializing inflate state

04-07 22:06:05.374: E/(7937): 测试第1张图片

04-07 22:06:05.544: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 51K, 50% free 2692K/5379K, external 0K/0K, paused 40ms

04-07 22:06:05.664: E/(7937): 测试第2张图片

04-07 22:06:05.774: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 1K, 50% free 2691K/5379K, external 6026K/7525K, paused 31ms

04-07 22:06:05.834: E/(7937): 测试第3张图片

04-07 22:06:05.934: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 12052K/14100K, paused 24ms

04-07 22:06:06.004: E/(7937): 测试第4张图片

04-07 22:06:06.124: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 18078K/20126K, paused 27ms

04-07 22:06:06.204: E/(7937): 测试第5张图片

04-07 22:06:06.315: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 24104K/26152K, paused 26ms

04-07 22:06:06.395: E/(7937): 测试第6张图片

04-07 22:06:06.495: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 30130K/32178K, paused 22ms

04-07 22:06:06.565: E/(7937): 测试第7张图片

04-07 22:06:06.665: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 36156K/38204K, paused 22ms

04-07 22:06:06.745: E/(7937): 测试第8张图片

04-07 22:06:06.845: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 2K, 51% free 2689K/5379K, external 42182K/44230K, paused 23ms

04-07 22:06:06.845: E/dalvikvm-heap(7937): 6170724-byte external allocation too large for this process.

04-07 22:06:06.885: I/dalvikvm-heap(7937): Clamp target GC heap from 48.239MB to 48.000MB

04-07 22:06:06.885: E/GraphicsJNI(7937): VM won't let us allocate 6170724 bytes

04-07 22:06:06.885: D/dalvikvm(7937): GC_FOR_MALLOC freed <1K, 51% free 2689K/5379K, external 42182K/44230K, paused 25ms

04-07 22:06:06.885: D/AndroidRuntime(7937): Shutting down VM

04-07 22:06:06.885: W/dalvikvm(7937): threadid=1: thread exiting with uncaught exception (group=0x40015560)

04-07 22:06:06.885: E/AndroidRuntime(7937): FATAL EXCEPTION: main

04-07 22:06:06.885: E/AndroidRuntime(7937): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.nativeCreate(Native Method)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.createBitmap(Bitmap.java:477)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.createBitmap(Bitmap.java:444)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.Bitmap.createScaledBitmap(Bitmap.java:349)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:498)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:473)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:336)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:359)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:385)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at bassy.test.drawable.Main.onCreate(Main.java:37)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.access$1500(ActivityThread.java:123)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.os.Handler.dispatchMessage(Handler.java:99)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.os.Looper.loop(Looper.java:130)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at android.app.ActivityThread.main(ActivityThread.java:3835)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at java.lang.reflect.Method.invokeNative(Native Method)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at java.lang.reflect.Method.invoke(Method.java:507)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605)

04-07 22:06:06.885: E/AndroidRuntime(7937):   at dalvik.system.NativeStart.main(Native Method)

 

 

看看上面的输出，才加载到第8张图片，程序就报错了“java.lang.OutOfMemoryError: bitmap size exceeds VM budget”。

 

通过上面的例子，可以看清楚地看出来，使用Drawable保存图片对象，占用更小的内存空间。

而使用Biamtp对象，则会占用很大内存空间，很容易就出现OOM了！

 

下面我们再来看一个例子，这个也是加载Bitmap对象。

只不过，之次不是使用BitmapFactory的decodeResource方法，

而是使用decodeStream方法，看代码。

public class Main extends Activity

{

    int number = 1000;

    Bitmap bitmap[];

 

    @Override

    public void onCreate(Bundle savedInstanceState)

    {

       super.onCreate(savedInstanceState);

       setContentView(R.layout.main);

 

       bitmap = new Bitmap[number];

 

       for (int i = 0; i < number; i++)

       {

           Log.e("", "测试第" + (i+1) + "张图片");

           bitmap[i] =BitmapFactory.decodeStream(getResources().openRawResource(R.drawable.img));//这里换了方法

       }

    }

}

 

 

输出结果：

04-07 22:16:12.676: E/(8091): 测试第561张图片

04-07 22:16:12.756: E/(8091): 测试第562张图片

04-07 22:16:12.826: E/(8091): 测试第563张图片

04-07 22:16:12.906: E/(8091): 测试第564张图片

04-07 22:16:12.906: D/skia(8091): ---------- mmap failed for imageref_ashmem size=2744320 err=12

04-07 22:16:12.906: E/(8091): 测试第565张图片

04-07 22:16:12.906: D/skia(8091): ---------- mmap failed for imageref_ashmem size=2744320 err=12

04-07 22:16:12.906: E/(8091): 测试第566张图片

04-07 22:16:12.916: E/filemap(8091): mmap(0,416798) failed: Out of memory

04-07 22:16:12.916: D/filemap(8091): munmap(0x0, 0) failed

04-07 22:16:12.916: W/asset(8091): create map from entry failed

04-07 22:16:12.916: D/AndroidRuntime(8091): Shutting down VM

04-07 22:16:12.916: W/dalvikvm(8091): threadid=1: thread exiting with uncaught exception (group=0x40015560)

04-07 22:16:12.936: E/AndroidRuntime(8091): FATAL EXCEPTION: main

04-07 22:16:12.936: E/AndroidRuntime(8091): java.lang.RuntimeException: Unable to start activity ComponentInfo{bassy.test.drawable/bassy.test.drawable.Main}: android.content.res.Resources$NotFoundException: File res/drawable-mdpi/img.png from drawable resource ID #0x7f020001

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1768)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.access$1500(ActivityThread.java:123)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.os.Handler.dispatchMessage(Handler.java:99)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.os.Looper.loop(Looper.java:130)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.main(ActivityThread.java:3835)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at java.lang.reflect.Method.invokeNative(Native Method)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at java.lang.reflect.Method.invoke(Method.java:507)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at dalvik.system.NativeStart.main(Native Method)

04-07 22:16:12.936: E/AndroidRuntime(8091): Caused by: android.content.res.Resources$NotFoundException: File res/drawable-mdpi/img.png from drawable resource ID #0x7f020001

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.Resources.openRawResource(Resources.java:860)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.Resources.openRawResource(Resources.java:836)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at bassy.test.drawable.Main.onCreate(Main.java:43)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722)

04-07 22:16:12.936: E/AndroidRuntime(8091):   ... 11 more

04-07 22:16:12.936: E/AndroidRuntime(8091): Caused by: java.io.FileNotFoundException: res/drawable-mdpi/img.png

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.AssetManager.openNonAssetNative(Native Method)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.AssetManager.openNonAsset(AssetManager.java:429)

04-07 22:16:12.936: E/AndroidRuntime(8091):   at android.content.res.Resources.openRawResource(Resources.java:857)

04-07 22:16:12.936: E/AndroidRuntime(8091):   ... 15 more

 

从上面可以看出，程序在加载到第566张的时候，就出现了OOM错误。

不过，跟第2个例子比起来，你会发现，程序可以加载更多的图片。

这说明了使用BitmapFactory的decodeResource方法会占据大量内存，

而使用使用decodeStream方法，则占据更小的内存。

 

从时间上来说，看看日志输出，大概估算了一下加载一张图片所需要的时间，发现，

decodeResource加载图片需要约0.17秒的时间，

而使用decodeStream方法，只需要约0.08秒的时间！

这说明了，decodeStream无论是时间上还是空间上，都比decodeResource方法更优秀！！

 

 

从上面三个例子，可以看出，用第一种方法（即用Drawable加载图片）可以加载更加的图片，加载32张图片的时间约为0.01秒！

我试着把Drawable的数量调至1000000，程序在运行时，停在了153761张图片里，手机提示，“应用程序无响应…”

个人猜测，Drawable应该不属于常驻内存的对象，不然的话，不可能不会出现OOM的～～

 

网上关于Drawable与Bitmap的资料太少，不能深入学习，真是遗憾～

 

 

刚才又做了个测试，把第一个例子中的

array[i] = getResources().getDrawable(R.drawable.img);

方法换成了

array[i] = Drawable.createFromStream(getResources().openRawResource(R.drawable.img), null);

结果和第三个例子一样，在第566张图片中，出现了OOM错误！

而且，加载的时间都是一样～～

这样一来，我就更加迷惑了～～


http://blog.csdn.net/ygc973797893/article/details/7620352

金笛子
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Android内存优化杂谈
01-04
Android内存优化是我们性能优化工作中比较重要的一环，这里其实主要包括两方面的工作： 1、优化RAM，即降低运行时内存。这里的目的是防止程序发生OOM异常，以及降低程序由于内存过大被LMK机制杀死的概率。另一方面，...
详解Android性能优化之内存泄漏
01-05
综述 内存泄漏（memory leak）是指由于疏忽或错误造成程序未能释放已经...那么我们在这就来分析一下导致内存泄漏的常见因素并且如何去检测内存泄漏。 导致内存泄漏的常见因素 情景一：静态Activity和View 静态变量Activ
android启动错误,android 启动错误
weixin_35006125的博客
05-26 1471
错误如下：09-30 13:40:05.042 4628-4628/com.lyf.ai.demo E/AndroidRuntime: FATAL EXCEPTION: mainProcess: com.lyf.ai.demo, PID: 4628java.lang.RuntimeException: Unable to start activity ComponentInfo{com.lyf.a...
Android runtime机制（二）zygote进程的启动流程
Gory的专栏
05-18 2703
在这一章里，我们将继续跟进zygote进程的启动过程。在zygote进程启动过程中,虚拟机的创建、jni functions注册及java层ZygoteInit是我们需要关注和理解的，这有助于我们开发更加高效的Android程序。
Android Zygote系统进程启动过程分析(Android N)
Do Better Every Day
02-20 6042
在Android系统中，所有的应用程序进程以及系统服务进程SystemServer都是由Zygote进程孕育（fork）出来的，因为Android系统是基于Linux内核的，而在Linux系统中，所有的进程都是init进程的子孙进程，也就是说，所有的进程都是直接或者间接地由init进程fork出来的。Zygote进程也不例外，它是在系统启动的过程，由init进程创建的，在系统启动脚本system/
Android的死机、重启问题分析方法
风和先行的专栏
09-26 1087
目录 1.死机现象 1.1死机定义 1.2死机表现 1.系统简图 2.可能死机的原因 2. 死机分析数据 Backtrace 系统运行环境 程序执行环境 其他的一些资讯 3. 几种典型的异常情况 3.1 Deadlock 3.2 执行JNI native code后一直不见返回 ...
Android性能优化之利用强大的LeakCanary检测内存泄漏及解决办法
09-01
本篇文章主要介绍了Android性能优化之利用LeakCanary检测内存泄漏及解决办法，有兴趣的同学可以了解一下。
记一次Android OOM问题
z9722的博客
04-02 6017
问题背景： 新平台固件测试后，反馈一个OOM的问题。问题日志如下： 3944 3959 I: Clamp target GC heap from 280MB to 256MB 3944 3959 I: Alloc concurrent copying GC freed 0(0B) AllocSpace objects, 0(0B) LOS objects, 0% free, 256MB/256MB, paused 173us total 383.632ms 3944 3944 I: WaitFo
Android 内存溢出问题分析
ujswml的专栏
09-17 1362
Android 内存溢出问题分析
android低内存补丁,Android – 从低内存条件恢复
weixin_36135382的博客
05-31 147
我正在开发一个非常强烈的图像处理应用程序,我在水平FragmentStatePagerAdapter中有多个ListFragments.我积极地采用几乎每一个窍门和建议,我能够在这里和其他地方找到.我下载位图并将其保存到SD和软参考存储器缓存.然而,当我在某些时候使用该应用程序,我开始在LogCat中看到消息,就像下面一样11-05 15:57:43.951: I/dalvikvm-heap(54...
Android系统问题及日志分析
gqg_guan的博客
04-03 4214
android 系统问题及日志分析
三步解决帧动画图片过多造成的OOM
Hana_one的博客
09-30 1259
主要三个步骤： 说明：我只测试了63张，蛮好用，推荐给大家 1.首先我们导入一个我们需要的   commons-io-1.4.jar 2.新建一个 工具类MyAnimationDrawable.Java   () package com.example.frame.demo; import java.io.IOException;     import java.util.Ar
android测试内存的软件下载,华为p10内存测试软件(androbench) v5.0.1 免费版
weixin_35203943的博客
05-26 2435
华为p10内存测试软件(androbench)其实是androbench这款内存测试软件，可以用于测试你的华为p10，是一款不错的华为p10内存测试软件，可以测试你的手机闪存性能，其他的手机也可以免费测试哦。华为p10内存测试软件介绍AndroBench是衡量Android设备存储性能的基准测试应用程序。现在我们提供免费的，无广告的Micro基准测试，SQLite基准测试和宏基准测试功能。随时检查...
【测试领域-性能测试】安卓与OpenHarmony的内存测试与分析
weixin_45484755的博客
03-25 390
无
一次内存泄漏的问题记录
热门推荐
lucky_tom的专栏
09-23 1万+
项目场景： 同事在开发一款人脸识别app时，在多次执行，打开--》人脸识别--》关闭--》打开循环测试过程中会耗尽内存。 问题描述： 测试同学通过用monkey脚本测试，遇到OOM内存溢出的问题。 日志片段1：可以看到系统一直在频繁gc，已经超过设定的512mb上限。 09-22 13:53:23.045 3052 3806 I zygote : Waiting for a blocking GC Alloc 09-22 13:53:23.502 3052 5107 I zy...
android性能测试 内存,测试基础之Android性能测试一：内存
weixin_33894886的博客
05-27 1303
手机系统内存是一种随机存取存储器(RAM),高速存取,读写时间相等,且与地址无关。存储单元的内容可按需随意取出或存入，且存取的速度与存储单元的位置无关的存储器。这种存储器在断电时将丢失其存储内容，故主要用于存储短时间使用的程序。分类手机内存一般分为：RAM和ROMRAM运行内存通常是作为操作系统或其他正在运行程序的临时存储介质，也称作系统内存。就好比计算机中的内存条，如果内存条容量越大，计算机就有...
zygoteinit.java_android 中把别人的代码添加到我的程序中运行出现如下错误：
weixin_39709367的博客
02-13 215
08-0902:02:03.846:ERROR/AndroidRuntime(249):Uncaughthandler:threadmainexitingduetouncaughtexception08-0902:02:03.923:ERROR/AndroidRuntime(249):java.lang.RuntimeException:...08-09 02:02:03.846: ERROR/A...
Android Studio4.0内存检测
最新发布
07-28
在 Android Studio 4.0 中，内存检测是一个非常重要的工具，它可以帮助开发人员发现和解决应用程序中的内存泄漏和性能问题。 Android Studio 提供了几种内存检测工具： 1. Memory Profiler：它可以帮助你监测应用...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值