百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 文章教程 > 正文

Android Studio下的应用性能优化总结-内存优化

xsobi 2024-12-24 16:26 11 浏览

上一篇文章总结的布局优化的问题,如果对布局优化不是很熟悉的,可以看一下Android Studido下的应用性能优化总结–布局优化 , 这周一直筹划总结一下内存优化的问题,因为现在对于应用优化的文章很多,但是还是想完善一下才想分享这篇文章的,我会从项目中遇到的一个问题,通过解决问题的过程来分享知识,希望大家有所收获。

“A small leak will sink a great ship.” - Benjamin Franklin

小楼不修补,大船也会翻。——本杰明 富兰克林

出现的问题(What)

  • 场景(Scene): Y君某年某月某日碰到一个奇怪的问题:A页面跳转到B页面,然后跳转到其他页面没有问题,但是在A跳转B,然后B跳转到A页面,就开始发生卡顿,程序也不崩溃!!OMG,这是什么问题,Y君当时确实有点懵逼了,这是肿么一个情况,但是Y君毕竟也是上过刀山下过火海,在bug堆里走出来的人(突然想起了那句话,我要成为海贼王的男人…),扯远了,还是回到问题上来.

分析问题(Why)

由于出现卡顿现象,大部分都出自内存的问题上,所以我们开始分析自己应用的内存使用情况,但是问题来了,用什么工具查看应用的内存使用情况?

因为以前Ecliplse的内存查看略显繁琐,而且Goole推出的新的开发工具Android Studio,有很多我们方便我们安卓开发程序猿调试和分析问题,在这里我就介绍一下Android Studio中的内存分析工具Memory,如果不熟悉的可以按照箭头指示,点击应用相对应的包名,就可以查看该应用内存情况,分析截图如下

  • Y君处理内存还是有稍许经验的,不急不缓的亮出自己珍藏已久的内存分析三剑客:

  1. LeakCanary

  2. Memory Analyzer Tool(MAT)

  3. TraceView

  • 那么我们开始分析问题出在哪里吧 ,Are You Ready? Go!

  • LeakCanary的使用方法

    LeakCanary的GitHub地址

    工具介绍:LeakCanary是Square开源的一个内存泄露自动探测神器,它是一个Android和Java的内存泄露检测库,可以大幅度减少了开发中遇到的OOM问题,对于安卓开发者来说,无疑是个福音。

    GitHub里边介绍的已经很详细了,我这里也简短的介绍一下使用方法!

    在项目的build.gradle文件添加:

    dependencies {

    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'

    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'

    testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'

    }1234512345

    在Application里边初始化

    public class ExampleApplication extends Application {

    @Override public void onCreate() { super.onCreate();

    LeakCanary.install(this);

    }

    }12345671234567

    当正常接入的情况下,测试应用出现内存不足的时候会接受到通知,截图如下

    但是Y君的这个bug出现这种分析,没有接到通知,截图如下

    • Leakcanary是的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心,缺点在于还存在一些bug,不过正常使用百分之九十情况是OK的,然后我就成了那百分之十,具体问题我也不清楚,但是不妨碍这是一个很好的检查工具。

    Memory Analyzer Tool(MAT)的使用方法

    MAT独立版内存检测工具下载

    工具介绍:MAT(Memory Analyzer Tool)工具在分析 大内存的dump文件时,可以非常直观的看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系、利用OQL对象查询,以及可以很方便的找出对象GC Roots的相关信息,当然最吸引人的还是能够快速为开发人员生成内存泄露报表,方便定位问题和分析问题。

    测试Demo:我写了一个Demo来模拟当时我遇到的情况!让计时器一直发送消息到Handler刷新时间,代码如下

    private void getCurrentTime() { //为了测试更加明显

    new Thread() { @Override

    public void run() { super.run(); while (flag) {// SystemClock.sleep(1000);

    long endTime = System.currentTimeMillis(); long time = endTime - mStartTime;

    String result = new SimpleDateFormat("mm:ss").format(new Date(time));

    Message message = handler.obtainMessage();

    message.what = MessageConstants.UPDATETIMEFLAG;

    mFinallyTime = result;//为了跳转携带数据

    message.obj = result;

    handler.sendMessage(message);

    }

    }

    }.start();

    }123456789101112131415161718192021123456789101112131415161718192021

    • 步骤一:我只讲Android Studio下如何抓取内存使用的情况,点击左上角的箭头提示,会抓取你相对应的位置的内存使用情况,如图4

    • 步骤二:稍等一会,生成的文件会出现在captures中,然后选择文件,点击右键转换成标准的hprof文件,就可以在MAT中打开了。

      再次我解释一下,MAT分两种类型,一种是用于Eclispse插件版,一种是独立版,因为我们用是Android Studio所以只能使用用独立版的MAT.

    • 步骤三:在MAT中打开抓取到的文件后,截图如下

      MAT中提供了非常多的功能,这里我们只要学习几个最常用的就可以了。上图最中央的那个饼状图展示了最大的几个对象所占内存的比例,这张图中提供的内容并不多,我们可以忽略它。

      图片中红色框有使我们经常使用的模块,它们的职责分别是:

    • Histogram可以列出内存中每个对象的名字、数量以及大小。

    • Dominator Tree会将所有内存中的对象按大小进行排序,并且我们可以分析对象之间的引用结构。

    MAT中的Dominator Tree 的分析

    现在点击Dominator Tree,截图如下:

    这张图包含的信息非常多,我来带着大家一起解析一下。首先Retained Heap表示这个对象以及它所持有的其它引用(包括直接和间接)所占的总内存,因此从上图中看,前两行的Retained Heap是最大的,我们分析内存泄漏时,内存最大的对象也是最应该去怀疑的。

    另外大家应该可以注意到,在每一行的最左边都有一个文件型的图标,这些图标有的左下角带有一个红色的点,有的则没有。带有红点的对象就表示是可以被GC Roots访问到的,根据上面的讲解,可以被GC Root访问到的对象都是无法被回收的。那么这就说明所有带红色的对象都是泄漏的对象吗?当然不是,因为有些对象系统需要一直使用,本来就不应该被回收。我们可以注意到,上图当中所有带红点的对象最右边都有写一个System Class,说明这是一个由系统管理的对象,并不是由我们自己创建并导致内存泄漏的对象。

    那么上图中就无法看出内存泄漏的原因了吗?确实,内存泄漏本来就不是这么容易找出的,我们还需要进一步进行分析。上图当中,除了带有System Class的行之外,最大的就是第一行的MessageQueue对象了,虽然MessageQueue对象现在不能被GC Roots访问到,但不代表着Bitmap所持有的其它引用也不会被GC Roots访问到。现在我们可以对着第二行点击右键 -> Path to GC Roots -> exclude weak references,为什么选择exclude weak references呢?因为弱引用是不会阻止对象被垃圾回收器回收的,所以我们这里直接把它排除掉,结果如下图所示:

    最终我们找到了罪魁祸首,开启的很多个线程,while死循环没有停止,我跳转的时候也没把循环关掉,所以有这么多的Thread。

    MAT中的Histogram 的分析

    首先我们学习一下Histogram的用法,回到Overview界面,点击Histogram,结果如下图所示

    这里是把当前应用程序中所有的对象的名字、数量和大小全部都列出来了,需要注意的是,这里的对象都是只有Shallow Heap而没有Retained Heap的,那么Shallow Heap又是什么意思呢?就是当前对象自己所占内存的大小,不包含引用关系的,比如说上图当中,String对象的Shallow Heap最高,说明我们应用程序中用了很多String类型的数据,我们不断的发送Handler不断的创作String对象。可以通过右键 -> List objects -> with incoming references来查看具体是谁在使用这些String,分析如图下,发现然并卵。

    那么通过Histogram又怎么去分析内存泄漏的原因呢?当然其实也可以用和Dominator Tree中比较相似的方式,即分析大内存的对象,比如上图中byte[]对象内存占用很高,我们通过分析byte[],最终也是能找到内存泄漏所在的,但是这里我准备使用另外一种更适合Histogram的方式。大家可以看到,Histogram中是可以显示对象的数量的,那么比如说我们现在怀疑MainActivity中有可能存在内存泄漏,就可以在第一行的正则表达式框中搜索“MainActivity”,如下所示:

    可以看到,这里将包含“MainActivity”字样的所有对象全部列出了出来,其中第一行就是MainActivity的实例。但是大家有没有注意到,当前内存中是有30个MainActivity的实例的,这太不正常了,通过情况下一个Activity应该只有一个实例才对。其实这些对象就是由于我们刚才不断地横竖屏切换所产生的,因为横竖屏切换一次,Activity就会经历一个重新创建的过程,但是由于LeakClass的存在,之前的Activity又无法被系统回收,那么就出现这种一个Activity存在多个实例的情况了。

    接下来对着MainActivity右键 -> List objects -> with incoming references查看具体MainActivity实例,如下图所示

    发现跟上边的效果一样,但是对比起来上边的方法比较方便,如果你无法判断是哪一个Acitivity出的问题,你就无法处理了,所以推荐用Dominator Tree分析问题。

    总结: 这大概就是MAT工具最常用的一些用法了,当然这里还要提醒大家一句,工具是死的,人是活的,MAT也没有办法保证一定可以将内存泄漏的原因找出来,还是需要我们对程序的代码有足够多的了解,知道有哪些对象是存活的,以及它们存活的原因,然后再结合MAT给出的数据来进行具体的分析,这样才有可能把一些隐藏得很深的问题原因给找出来。

    TraceView的使用方法

    借鉴了许多关于TraceView的分析,发现都是抄来抄去,最终都是一种解决办法,不是针对各种问题解决问题,针对我这次碰到的这个问题,我慢慢琢磨了这么工具的使用,发现直接可以分析出具体那个方法占用CPU的时间,个人认为从CPU角度思考内存优化,可以考虑使用这个工具来分析。

    如何使用打开DDMS,然后如图

    先按下Start Method Profiling(箭头所指,开始有红点),点击后红点变成灰色小方块,然后过一会可以按Stop Method Profiling,然后出现这种跟答题卡一样的,我们只看下部分的分析

    显而易见,分析Intel Cpu Time 属性,点击它按照从大到小的排序后,我们清晰发现run()方法居然占了93%的CPU运行内存,并且直接具体到哪一个类里边的方法。剩下的一些属性估计有用,在这里我也就不一一介绍了!如果你想详细了解,点击文章最后的参考链接即可。

    解决问题(How)

    通过这三种方法分析的分析结果:

    1. LeakCanary反馈的信息没有,无法分析

    2. Memory Analyzer Tool(MAT)反馈的信息是MainAcitity中创建了很多的Thread,可以直接分析到死循环的毛病

    3. TraceView通过CPU的使用情况非常直观的显示出,MainAcitivity中的run()方法占用95%的使用,干净利索的分析出问题的所在

    最后解决办法:加1s的sleep时间,A跳转到B页面的时候,关掉循环!!

    总结

    文章也写到了最后:

    如果遇到卡顿问题的时候,推荐分析的步骤:

    1. 先用Memory产看内存使用情况

    2. 在用LeakCanary看是否能直接分析出那一个类出的错误

    3. 如果LeakCanary分析的步骤不够清晰,导出文件用MAT具体分析

    4. 如果在MAT你也没有检查出哪里出的错误,可以尝试TraceView来分析内存使用情况,因为他可以具体到哪一个方法。

订阅是一种态度,关注微博、微信平台是一种欣赏!

微博:丶杨哲丶

微信:杨哲丶

相关推荐

大模型技术:详解LangGraph,从基础到高级

图片来自DALL-E3LangChain是构建由Lardge语言模型提供支持的应用程序的领先框架之一。借助LangChain表达语言(LCEL),定义和执行分步操作序列(也称为链)变得更加简...

SQL知识大全三):SQL中的字符串处理和条件查询

点击上方蓝字关注我们今天是SQL系列的第三讲,我们会讲解条件查询,文本处理,百分比,行数限制,格式化以及子查询。条件查询IF条件查询#if的语法IF(expr1,expr2,expr3)#示例S...

聊聊Spring AI Alibaba的PdfTablesParser

序本文主要研究一下SpringAIAlibaba的PdfTablesParserPdfTablesParsercommunity/document-parsers/spring-ai-alibab...

SpringBoot数据库管理 - 用Liquibase对数据库管理和迁移?

Liquibase是一个用于用于跟踪、管理和应用数据库变化的开源工具,通过日志文件(changelog)的形式记录数据库的变更(changeset),然后执行日志文件中的修改,将数据库更新或回滚(ro...

MySQL合集-单机容器化

MySQL单机容器化mkdir-p/opt/mysql/{data,etc}cpmy.cnf/opt/mysql/etc#dockersearchmysqldockerpullm...

差异基因分析不会做?最简单的火山图做法,一秒学会

最近很多刚了解生信的同学问喵学姐:看了一些文献,文献里的各种图怎么看呀,完全看不懂。今天喵学姐就来给大家讲一讲我们平时做的最基础的差异分析——火山图火山图(Volcanoplot)是散点图的一种,它...

每分钟写入6亿条数据,携程监控系统Dashboard存储升级实践

一、背景概述框架Dashboard是一款携程内部历史悠久的自研监控产品,其定位是企业级Metrics监控场景,主要提供用户自定义Metrics接入,并基于此提供实时数据分析和视图展现的面板服务,提供...

高效开发库:C++ POCO库开发者使用指南

目录POCO库简介POCO库的特点POCO库的模块分类POCO库的应用场景各模块功能详解与代码示例1.POCO库简介POCO(PortableComponents)是一个开源的C++类库,旨在为开...

Oracle中JDBC处理PreparedStatement处理Char问题浅析

最近碰到一个奇怪的问题,同样的Java代码,在不同的数据库执行,结果集却不同?代码片段如下:表的定义:SAMPLE_TABLE(IDINTEGER,NAMECH...

mp4封装格式各box类型讲解及IBP帧计算

mp4封装格式各box类型讲解及IBP帧计算目录;总结送学习大纲零基础到实战boxftypboxmoovboxmvhdbox(MovieHeaderBox)trakbox(Track...

「猪译馆」ASFV在不同基质中的存活时间(一)

作者Author欧洲食品安全署EuropeanFoodSafetyAuthority(EFSA),AndreaGervelmeyer欧盟委员会委托欧洲食品安全署对非洲猪瘟病毒在不同基质中...

视频封装格式:MP4格式详解

1.MP4格式概述1.1简介MP4或称MPEG-4第14部分(MPEG-4Part14)是一种标准的数字多媒体容器格式。扩展名为.mp4。虽然被官方标准定义的唯一扩展名是.mp4,但第三方通...

音视频八股文(10)-- mp4结构

介绍mp4文件格式又被称为MPEG-4Part14,出自MPEG-4标准第14部分。它是一种多媒体格式容器,广泛用于包装视频和音频数据流、海报、字幕和元数据等。(顺便一提,目前流行的视频编码格式...

大数据ClickHouse进阶(九):ClickHouse的From和Sample子句

#头条创作挑战赛#ClickHouse的From和Sample子句一、From子句From子句表示从何处读取数据,支持2种形式,由于From比较简单,这里不再举例,2种使用方式如下:SELECTcl...

一文读懂MP4封装格式

简介MP4或称MPEG-4第14部分(MPEG-4Part14)是一种标准的数字多媒体容器格式。扩展名为.mp4。虽然被官方标准定义的唯一扩展名是.mp4,但第三方通常会使用各种扩展名来指示文件的...