android分析工具,安卓apk分析工具

Android UI 布局分析三大工具

一： HierarchyView 

老牌分析工具，在早期的SDK中是有快捷方式的，新版的找不到快捷方式了，后来找了很久才找到入口

首先找到Android Device Monitor

可以进入到sdk的安装目录下 从tools目录下点击monitor.bat 启动 Android Device Monitor

然后找到下图红框位置 点击 HierarchyView 按钮就可以打开 如果没有HierarchyView 按钮就点击DDMS按钮左边的更多按钮，里面会列出来HierarchyView 按钮

HierarchyView 最大的好处是以这种结构树图的方式展示ViewTree 能够一目了然的看清结构，并且可以评估绘制时间

但是在新的android版本里面 HierarchyView会提示找不到Service 遇到这种情况 参照如下文章解决

二：UI Automator

比较常见的工具，在很长一段时间内，找不到HierarchyView用的就是他，但是这个工具不是很好用，有时候显示的层级也不准，可能是我不太会用

入口如下图

点击红框处进入

三：Layout Inspector

入口

打开之后是这个样子

三种工具各有各的特点，大家可以根据自己的需求进行选择

相关问答

Q1: Android-trace分析工具

1.TraceView

官方说明文档:

android CPU profiler

CPU profiler可以实时检查应用的CPU使用率和线程activity,并记录函数跟踪，以便于您可以优化和调试您的应用程序.

Flame Chart如果出现问题 颜色也会加深

2.systrace

简介:

systrace是Android4.1版本之后推出的，对系统Performance分析的工具。systrace的功能包括跟踪系统I/O操作,内核工作队列,CPU负载以及Android各个子系统的运行状况等。

主要由三部分构成:

1.内核部分

systrace采用了linux Kernel的ftrace功能，所以如果要使用systrace的话，必须开启Kernel和ftrace相关的模块.

2.数据采集部分

Android中定义了一个trace类,应用程序可以使用该类把统计信息输出给trace,同时，android有一个atrace程序，它可以从ftrace中读取统计信息然后交给数据分析工具来处理.

3.数据分析工具

Android提供一个systrace.py用来配置数据采集的方法(如采集数据的标签，输出文件名等)和收集ftrace统计数据并生成一个结果网页文件供用户查看。

简单的说,当机器以60帧/秒显示，用户会感知机器流畅。如果出现显示时丢帧的情况，就需要知道系统在做什么?Systrace是用来收集系统和应用的数据信息和一些中间生成数据的细节，在Android4.1和4.2系统之后出现。Systrace在分析一些显示问题上特别有用，如应用画图慢，显示动作或者动画时变形。

抓取systrace

进入本地Android/Sdk/platform-tools/systrace目录下,执行python systrace.py view --time = 10

python脚本的option

Q2: Android 布局分析工具（二）Layout Inspector使用

如果仍需使用以前的DDMS，可以双击文件夹下的  Android-SDK--tools--monitor.bat 即可 。

既然AS 不提供 DDMS面板了那肯定有替代的工具啊，经过查找总结如下：

DDMS 和 Systrace、Hierarchy Viewer都不用了。使用Android Profiler替代DDMS 和 Systrace ，Layout Inspector 替代Hierarchy Viewer

下面进入正题，简单说下  Layout Inspector 工具简单使用，

1、首先要打开 layout inspector 工具呀 直接上截图吧

2、选择要分析的应用id，选中后点击 “OK” 如图 

3、通过下拉按钮选择要分析的界面后点击“OK”（如：loginActivity、MainActivity等）

4、这样就可以查看界面的 布局情况了最后的截图就不贴了吧，太丑

Q3: Android 分析OOM工具介绍

如图1所示, 步骤

** 1, 2, 3** 为打开Android Monitor并切换标签到monitor的过程

4, 5, 6 对应的图标和文字含义分别是

MAT 工具识别，并解析hprof文件,

有两种方式可以获得hprof文件

MAT并不能直接打开这两个hprof, 必须通过hprof-conv来转换一次

如图3所示，选中(过滤出MainActivity), 然后通过Objects可以看出它有8个实例

接着选中 com.example.wowo.MainActivity 然后右键选择

Merge shortest paths to GC Roots - exclude week references

因为弱引用是会被回收的，所以排除掉更加容易发现OOM.

什么是OOM out-of-memory？

Android下的APP运行在VM中(Dalvik or ART), 一个APP需要的内存是有限，这个值在不同的平台, 不同的手机上是不同的，当APP需要的内存超过了内存上限，就会引起OOM.

下面给出一个最基本的Android APP显示HelloWorld的例子.

这时如果不停的旋转屏幕, 这时通过观察Android Monitor里的Free和allocated的memory会发现 allocated 的memory会不断增加，而Free的memory会不断减小

这时通过图1中步聚5 dump java heap, 然后filter到MainActivity, 会发现MainActivity有多个实例

接着再通过MAT来分析， 图4所示

发现有很多FinalizerReference， 应该是与GC有关，由于旋转屏幕会导致MainActivity销毁并重新创建实例，而JVM在创建MainActivity实例时还有free的memory, 所以并没有触发GC，即原来的MainActivity的实例并没有被回收，所以多次旋转后，在free memory还有的情况下就会保存多个MainActivity的实例造成内存泄露的假象。当free memory 不够时，这时会触发GC, 会回收之前销毁的MainActivity的实例。

所以在查看OOM问题时，当allocated内存不断增大时，应该人为先触发GC(点击图1的4)。

如果allocated的内存没有下降，说明当前并没有可回收的实例占据内存了。

而在该例中，如果点击了initiate GC后，allocated的内存立即减少了。

Android Monitor看到MainActivity也就只有一个实例了。