如何理解Android SDK配置文件traceview...?
我有一些代码使用 Jsoup 来获取和解析一些 html 页面,然后操作 html 树,然后将其传递给绘制它的 WebView。如果我绕过我的操作,代码在 Android SDK 模拟器上的运行时间可以接受(2-3 秒),但是当我进行操作时,时间会跳到不可接受的程度(仅加载单个页面约 60 秒!)。
我使用 Eclipse 和 Android SDK 进行了一次运行分析,现在我尝试解释结果。从这里 http://android-developers.blogspot.com/2010 /10/traceview-war-story.html 根据提示对“独占 Cpu 时间 %”的配置文件进行排序。令我惊讶的是,我自己的代码甚至没有列出 1%。消耗时间最多的是 android.view.ViewGroup.drawChild(),占 11.9%。列出的第一个非 Android 函数(按独占 cpu % 排序)是 java.lang.ref.Reference.get(),它列在 0.4% 处。
但我想最奇怪的是我自己的代码,我只能找到我的 AsyncTask 的 doInBackground() 列出;尽管我可以通过调试输出看到它们被调用,但依次调用的函数甚至不存在。为什么那些没有列出?
我不明白这一切是怎么回事。非常感谢任何提示。
I have some code that uses Jsoup to get and parse some html pages, and then I manipulate the html tree, before passing it to a WebView that draws it. If I bypass my manipulations, the code runs in acceptable times (2-3 seconds) on the Android SDK simulator, but when I do my manipulations the time jumps to unacceptable (~60 seconds to just load a single page!).
Using Eclipse and the Android SDK I had a run profiled, and now I'm trying to interpret the results. from here http://android-developers.blogspot.com/2010/10/traceview-war-story.html took the tip to sort profile on the "Exclusive Cpu Time %". To my surprise, my own code did not even list at 1%. The biggest time consumer is android.view.ViewGroup.drawChild() at 11.9%. The first non-android function listed (as sorted by exclusive cpu %) is java.lang.ref.Reference.get() and it lists at 0.4%.
But I guess teh strangest thing is that of my own code, I can only find my AsyncTask's doInBackground() listed; the functions this calls in turn are not even present, even though I can see by the debug output that they are called. Why are those not listed?
I don't understand what to make of any of this. Any hints are very much appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

虽然我手头没有参考资料,但我认为可以安全地假设 Android 在优先级为 android.os.Process.THREAD_PRIORITY_BACKGROUND 的线程中执行 AsyncTask.doInBackground()
这意味着该线程是在 Linux 上下文中调度的cgroup(调度类) - 总是或在频繁的情况下,我不确定并且已经阅读了各种声明 - 常见 CPU 时间的上限为 5% 或 10% ——同样,不同的来源提出不同的说法——被应用。
换句话说,所有后台线程必须共享 5% 或 10% 的可用 CPU 时间。再次,我读到了这样的说法:如果前台和实时任务空闲,这是动态调整的,但我很高兴自己指出可靠的来源。另外,我不会指望它,因为用户可以在使用我的应用程序时收听实时音频流。
如果您调整后台线程的优先级,如下所示:
那么您将实现两件事。
但是,您也可能更改底层 AsyncTask 执行器为您的 AsyncTask 提供的线程的优先级。该线程将被回收,它可能是单个线程或从池中选择。因此,在应用程序中所有 AsyncTasks 的所有 doInBackground() 方法中设置优先级可能是个好主意。
Although I don't have a reference at hand, I think it's safe to assume that Android executes AsyncTask.doInBackground() in a Thread with priority android.os.Process.THREAD_PRIORITY_BACKGROUND
This means that this Thread is scheduled in the context of a Linux cgroup (scheduling class) for which -- always or under frequent circumstances, I'm not sure and have read various claims -- an upper bound of common CPU time of 5% or 10% -- again, different sources make different claims -- is applied.
In other words, all background threads have to share 5% or 10% of the available CPU time. Again, I have read claims that this is dynamically adjusted if the foreground and real time tasks are idle, but I'd be happy to be pointed to a credible source myself. Also, I wouldn't count on it since the user can listen to a real time audio stream while using my app.
If you adjust the background Thread's priority, like so:
then you achieve two things.
However, you also probably change the priority of the Thread which the underlying AsyncTask executor provides for your AsyncTask. This Thread is going to be recycled, and it may be a single Thread or chosen from a pool. So it might be a good idea to set the priority in all doInBackground() methods in all AsyncTasks in your app.