android性能分析

android性能分析

对于一个app的性能,我们可以通过以下几个点去分析:

  • 内存
  • CPU
  • GPU
  • 网络

而这些性能直接影响到手机耗电量,发热量,界面的流程度,以及流量的消耗,所以通过对这些点的分析,可以很好的改善app的整体性能。

对于这四个维度的分析,android studio提供如下四种监测工具:

  • Memory Monitor
  • CPU Monitor
  • GPU Monitor
  • Network Monitor

通过以上工具,app的运行情况都会直观,实时的显示在图表中。根据图表,可以初步判断是否存在内存抖动,cup负荷过大等问题,但如果需要进一步分析,就需其详细的数据,尤其是memory和cpu中,由于代码实现的不合理导致性能低下且不易被发现的问题。

屏幕快照 2017-06-28 下午2.30.00.png

接下来将进一步介绍工具等使用,获取性能相关的数据,以及对这些数据的分析。

*在android studio3.0版本中,Monitor系列工具全新升级为Profiler,功能更加强大。

Memory Monitor

内存的使用分析,即对其堆的使用,可以通过Memory Monitor直接获取.hprof(堆转储)和.trac文件。利用这些数据确定是否存在内存泄漏的问题以及对应方法的内存占用情况。

*堆转储

hprof(堆转储)是应用堆中所有对象的快照。

在Memory Monitor中,有一套完整,高效的内存分析工具,使用也非常简单。

  1. 在 Memory 监视器的顶部,点击

    Dump Java Heap.

    Android Studio 会创建一个文件名为 application-id_yyyy.mm.dd_hh.mm.hprof 的堆快照文件,在 Android Studio 中打开文件,然后将文件添加到 Captures 标签的 Heap Snapshot 列表中。

  2. 在 Captures 标签中,右键点击文件,然后选择 Export to standard .hprof。

    在视图中,你可以查看堆中的使用情况,也可以方便的查看引用tree。

  3. 使用Analyzer Task工具,点击运行按钮获取堆中存在泄露的Activity,也可以监测重复的String类.型

屏幕快照 2017-06-28 下午3.38.09.png

以未来域为例,如图所示,可以迅速的检测出存在一个内存泄漏的对象,在MyHouseActivity类中的RetrofitClient对象,进行了网络请求,问题在于未在Activity退出的时候进行销毁。

跟踪内存分配

Allocation Tracker(跟踪内存分配)可以让您更好地了解分配占用内存的对象的位置,跟踪内存分配位于哪些线程上,以及内存分配来自何处。

  1. 在内存监视器工具栏中,点击“Allocation Tracker” 开始内存分配。

  2. 与您的应用交互。

  3. 再次点击“Allocation Tracker” 停止分配跟踪。

    Android Studio 会创建一个文件名为 application-id_yyyy.mm.dd_hh.mm.alloc 的分配文件,在 Android Studio 中打开该文件,然后将文件添加到 Captures 标签内的 Allocations 列表中。

  4. 在分配文件中,确定您的应用中哪些操作可能会引起过多分配,并确定应在应用中什么位置尝试减少分配和释放资源。

屏幕快照 2017-06-28 下午4.21.42.png

该图显示了未来域的“首页”模块中的内存发布,上半部分是线程中方法所占的内存比,下部分用图表来展示对象的内存占比,圆形弧度越大内存占用越大,可以看出,BGABanner占用了较大比重的内存,其原因在于banner中涉及到了大图以及切换动画等。

CPU Monitor

android studio提供了一套cup使用追踪工具CPU Monitor,通过该工具可以实时显示cup使用使用率。

am-cpumon2.png

图中可以看到,cup的使用分为两种类型

  • User:代码需要系统接口才能服务硬件和内存,出现崩溃是可恢复的,
  • Kernel:可直接访问硬件和物理内存,出现崩溃往往会导致设备停止运行。

一般情况下我们需要关注的是User类型,以及进行相应的代码调优。

在CPU Monitor中,我们可以获取.trace(Method Tracer)文件来进行性能分析。

  1. 在CPU Monitor中,点击

    Start Method Tracing。

  2. 在交互完成后,再次点击

    以停止跟踪。

此时会生成package_yyyy.mm.dd_hh.mm.ss.trace的文件,Android Studio会默认打开该文件,展示入下图:

屏幕快照 2017-06-28 下午5.06.58.png

图中给出了方法对应的CPU使用时间。但该工具无法查看方法等调用栈,即方法的parent和其child方法,同时给的列类型太少,比如realtiem,cputime以及递归调用次数等等。因此,我们需要其他的分析工具,比如SystraceTraceview

Systrace

Systrace用于UI性能的分析,通过在浏览器中打开trace.html文件可以看到每一帧所执行的方法以及需要的时间,是否达到60的帧率。

有三种方式可以获取trace.html:

  • 使用SDK中的python脚步

    android4.3+

    $ cd android-sdk/platform-tools/systrace
    $ python systrace.py --time=10 -o mynewtrace.html sched gfx view wm
    

    android4.2-

    $ cd android-sdk/platform-tools/systrace
    $ python systrace.py --set-tags=gfx,view,wm
    $ adb shell stop
    $ adb shell start
    
  • 添加代码块(android4.3+ only)

    Trace.beginSection() 开始,以 Trace.endSection() 结束。

  • 使用DDMS工具

最终获取到的以trace.html为结尾的文件,可直接通过浏览器打开

屏幕快照 2017-06-27 下午4.01.50.png

以上是未来域的首页列表滑动过程的System trace。

从图中,我们可以看到在中间红框中有多个'F',在表格里每一个'F'都表示一帧,绿色的表示在16ms内完成了所有的存在的处理。黄色表示该未在16ms内完成处理,但没消耗太多时间,可能影响接下来的一帧数据。红色表示性能很差,消耗了过多时间,可能会丢弃接下来的多帧数据。

我们可以看到在中间一部分出现了多个黄色和几个红色帧,
对于这些出错帧,我们可以点击对应的'F',然后按'M'按钮可以高亮显示该帧区域,查看窗口关于出现该现象的原因以及解决建议。你也可以直接点击右边红框Alerts来查看错误的类型。可以看到存在33个Scheduling delay。关于该提示,大致是存在需要被处理的特定片段的线程,未及时的被cpu处理,而导致线程需要更长时间去处理。

我们可以直观的确定当前操作是否存在掉帧的情况,但在trace.html中我们无法定位到特定方法,也看不到具体的执行时间,如果需要进一步确认出现问题的方法,就需要使用TraceView

TraceView

TraceView是一个强大的性能分析工具,使用该工具加载trace文件,以图形的形式展示代码的执行时间、次数及调用栈,便于我们分析。

使用TraceView前,我们需要获取.trace文件,可以通过以下三种方法获取:

  • 使用代码块

    在对应的代码区间内输入如下代码块:

     // start tracing to "/sdcard/calc.trace"
    Debug.startMethodTracing("calc");
    // ...
    // stop tracing
    Debug.stopMethodTracing();
    
  • 使用CPU Monitor

    CPU Monitor段落中的1,2两步操作。

  • 使用DDMS工具

获取到trace文件后,可以在Android Device Monitor中打开,会展示出如下图表

屏幕快照 2017-06-28 下午11.22.07.png

图中可按顺序分为线程面板1,时间面板2,数据分析面板3。

线程面板展示了在记录时间区间内活动的线程,我们可以看到常见的main线程,对应的时间面板中,有很多色块组成,这些色块表示采集过程中方法调用时间线,每一个色块代表一个方法。当点击色块的时候,会在数据分析面板中显示对应的方法,以及其调用栈和相关性能数据。该面板中的列字段大致意义如下:

列名 描述
Name 该线程运行过程中所调用的函数名
Incl Cpu Time 某函数占用的CPU时间包含内部调用其它函数的CPU时间
Excl Cpu Time 某函数占用的CPU时间但不含内部调用其它函数所占用的CPU时间
Incl Real Time 某函数运行的真实时间以毫秒为单位内含调用其它函数所占用的真实时间
Excl Real Time 某函数运行的真实时间以毫秒为单位不含调用其它函数所占用的真实时间
Call+Recur Calls/Total 某函数被调用次数以及递归调用次数/总调用次数
Real Time/Call 同CPU Time/Call类似只不过统计单位换成了真实时间

要定位到问题,就需要结合这些数据来获取不同类型的潜在可优化的热点,然后进行优化,具体可参考TraceView工具的使用中的处理技巧。

GPU Monitor

GPU Monitor显示视图的渲染情况,与直接在手机开发者模式中开启GPU分析视图一样。

am-gpumon2.png

每一帧最好的状态是保持在绿线以内。

Network Monitor

在Studio中,通过该工具可以直观的检测网络的使用情况,及其上传和下载的流量。在Android Studio3.0中的升级版Monitor本中,提供了抓包功能!android可以不再需要设置代理,使用第三方抓包工具了!强大!

networkprofiler_2x.png

选择2区域进行你需要抓包的区域, 会在3窗口会显示接受或发送的文件信息,包括文件名,大小,类型,状态和时间等信息。点击3中的链接名,会在4窗口展示更详细的信息,可以查看response,消息头等数据。

获取当前top的Activity

linux:

adb shell dumpsys activity | grep "mFocusedActivity"

windows:

adb shell dumpsys activity | findstr "mFocusedActivity"

相关文章

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,126评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,254评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,445评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,185评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,178评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,970评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,276评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,927评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,400评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,883评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,997评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,646评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,213评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,204评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,423评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,423评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,722评论 2 345

推荐阅读更多精彩内容