0

我在我的 Android 应用程序上运行了 Traceview，结果很糟糕：2200 毫秒。我与很多人交谈过，并被告知向上或向下堆栈并找到有问题的代码。问题是，当我一路向上或一路向下时，没有明显的迹象表明为什么（我知道你在嘲笑，因为你是对的，这是有原因的，但请阅读-我是新人）。

如果我查看 Excl CPU 时间，BitmapFactory.nativeAssetDecode 会花费大量时间，远远超过 1400 毫秒。显然，这是我的 Activity 问题的主要部分，但是，确定它的来源一直是一场噩梦。我的“直接”代码都没有在堆栈的这一部分附近（不是孩子，也不是父母），事实上，我所有的“直接”方法似乎都表现良好，仅在 0-4 毫秒内触发和完成将是预期的。

我发现的一件事是，如果我在 setContentView() 之后启动 Traceview，Traceview 日志下降到只有 90 毫秒。老实说，我太新了，无法理解这个结果，我知道这是误导性的，因为 setContentView() 当然需要时间，但也许我的布局导致花费太多时间？我的布局真的会导致 2110 毫秒吗？

这就是我感到困惑的地方。我的布局的透支为零，并且似乎是一个格式良好且非冗余的 XML 文件。我最大的布局中有 41 个视图小部件，我发誓我见过许多性能良好的活动，其中包含 100 多个视图小部件。我的视图基本上由 4 个布局和 36 个视图小部件（TextViews 等）设计，每个项目都有一个从 Style.xml 分配给它们的样式。我希望我没有占便宜并创造了一个怪物视图？

也许如果有人可以扩展理论以跟踪不是由您编写的直接代码引起的问题，或者隔离“失控”方法的 CPU 时间原因背后的理论，我将能够更好地帮助自己（上帝知道我已经试过了，事实上整个周末）。

TL;DR如果我在 onCreate 的 setContentView() 之后启动 Traceview，加载我的活动所需的时间比我在 setContentView() 之前少 2110 毫秒。不过，我的 Activity 视图并不十分复杂，所以我很困惑。

我非常感谢，瑞恩

4

2 回答 2

1

真正伤害您的一件事是布局的测量会相互影响。我会是你在你的布局中使用了很多“权重”，因为这些计算起来有点费时。

您可以使用hierarchyviewer 分析您的慢速布局。它位于 IntelliJ 或 Eclipse 的 Android 工具菜单中。它只能在测试设备上运行，或者与添加了 ViewServer 的应用程序一起运行（有关说明，请参阅此内容）

一个注释——绿色、黄色和红色与您当前的视图层次结构相关。这是文档中的注释：

这些指示器可以是红色、黄色或绿色，并表示每个视图相对于树中其他视图的呈现方式。它们本身并不是坏或好观点的严格表示。

A red dot means that this view renders the slowest, compared to all views in your hierarchy.
A yellow dot means that this view renders in the bottom 50% of all views in your hierarchy.
A green dot means that this view renders in the top 50% of all views in your hierarchy.

这实际上只是表明您应该尝试解决的问题。

于 2013-06-11T05:18:27.597 回答
1

好吧，我发现了问题，而且很苦。这很好，因为不是我的代码或布局导致了问题，而是使用 loadAdOnCreate="true" 来创建广告的 admob AdView。这很痛苦，因为如果我不能消除 AdView 造成的加载延迟，我现在可能不得不转换收入来源！

于 2013-06-12T01:57:23.137 回答