Android Traceview -它持有我的反应迟钝的应用程序的答案..。我认为

Question

昨天，我花了12个小时成为Traceview的学生。在此之前，我甚至不知道它的存在(羞愧地垂着头)。

现在我已经克服了它产生的数据的绝对冲击，我发现Traceview可以归结为几个简单的概念：

1. 按“CPU时间以外的时间”进行排序，以准确确定每个方法单独使用的使用量。
2. 查看呼叫的频率和每个呼叫的cpu时间/实时时间。显然，应该研究更高的要求。在我的大部分经验中，如果您按照上面的#1进行排序，那么调用太多且花费太多时间的方法也将位于列表的首位(因为它们也使用最多的CPU)。

无论如何，在上面的这两个步骤中，我发现3-4种方法总是占用我90%的CPU，并且占用了我的应用程序中的大部分实时延迟。唯一的问题是，这些方法中没有一个是我编写的方法，它们是系统方法，例如：

1. BitmapFactory方法
2. WebKit方法
3. 和其他系统方法

话虽如此，假设最大的资源消耗是系统方法，那么它一定与我的布局设计有关吗？我不知道为什么BitmapFactory会如此之高，我的布局并不是非常复杂，尽管在一个活动中，BitmapFactory本身占用了95%的资源。

TL;DR -如果我运行一个Traceview，如果我发现顶级的资源都是系统方法，这是否意味着这是一个布局问题？或者，我如何知道为什么系统方法如此之高，以至于它与我的自定义方法没有直接关系。

谢谢你，瑞恩

Answer 1

嗯，我发现了问题，这是苦甜的。这很贴心，因为这不是我的代码或布局造成问题的原因，而是admob AdView使用loadAdOnCreate="true“创建广告。这是痛苦的，因为我现在可能不得不切换收入来源，如果我不能消除加载延迟造成的AdView！这是一个很难找到的，但我应该预料到这一点！

Answer 2

我发现Traceview可以归结为几个简单的概念：

这些概念不是最好的，IMHO。

按“不包括CPU时间”进行排序，以准确确定每个方法单独使用的使用量。

特别是，这个概念相当糟糕的国际水文学组织。是的，这是有用的数据。但是，您需要对调用堆栈进行备份，试图找出是什么触发了调用堆栈。有时，它将直接成为您的代码。有时，您会发现它是框架的一部分(例如，onDraw() of a View)。仅仅知道一些随机的方法占用了大量的时间，在您确定是什么触发了要被调用的方法之前，这是没有好处的。

如果我运行一个Traceview，如果我发现最重要的资源都是系统方法，这是否意味着这是一个布局问题？

不是的。

或者，我如何才能知道为什么system方法如此高，因为它与我的自定义方法没有直接关系。

在调用堆栈上工作，找出是谁这么频繁地调用这些方法，或者是在不合适的时候。

例如，在BitmapFactory示例中，您可能会发现您(或您正在使用的库)正在调用BitmapFactory，并且可能正在主应用程序线程上这样做。

要在调用堆栈上工作，请单击行左侧边缘的三角形，表示感兴趣的方法。然后你会看到下面的两个分支：“父母”和“孩子”。“父级”表示从方法到调用堆栈的下一个级别，您可以继续在父级链上工作，直到找到您认可的内容为止。

这就是为什么，IMHO，按包含时间进行排序更好，因为您的代码(它直接是罪魁祸首)将倾向于向顶部冒泡。