我安装了最新版本的SDK (API 16)
并得到了最新的ADT。 现在我在logcat中看到这些消息,我敢肯定,我以前从未见过。 有没有人有这个想法?
06-29 23:11:17.796:I /编舞(691):跳过647帧! 该应用程序可以做它的主线程的工作太多了。
我做了搜索,发现此链接: http://developer.android.com/reference/android/view/Choreographer.html 。 这是API 16引入了一个新的类。
我需要知道我怎么能确定什么是我的全部过程都在做“太辛苦了”我的应用程序可以做AsyncTask
秒。
编舞让应用程序将自己连接到垂直同步,并掌握好火候的东西来提高性能。
Android设备上查看动画在内部使用编导为了同样的目的:正确的时间动画,可能会提高性能。
由于编导讲述每一个VSYNC事件,我可以告诉大家,如果的Runnable的一个传递沿由Choreographer.post * API的犯规完成一帧的时间,从而导致被跳过帧。
在我的理解编导只能检测跳帧。 它没有告诉为什么发生这种情况的方式。
消息“应用程序可能会做太多的工作在其主线程。” 可能会产生误导。
我迟到了,但希望这是一个有用的除了这里其他的答案...
回答这个问题/ TL:博士;
我需要知道我怎么能确定什么是我的全部过程都在做AsyncTasks“太辛苦了”我的应用程序可以做的事情。
以下是所有候选人:
- IO或主线程上昂贵的处理(装载图形内容充气布局和设置
Uri
'S上ImageView
的所有构成的主线程上IO) - 渲染大/复合/深
View
层次 - 一个无效的大部分
View
层次 - 昂贵
onDraw
在自定义的方法View
的 - 在动画昂贵的计算
- 运行“工人”线程在过高的优先级被认为是“背景”(
AsyncTask
的是‘背景’在默认情况下, java.lang.Thread
不算 ) - 产生大量的垃圾,造成垃圾收集器“阻止世界” - 包括主线程 - 而它清理
实际确定具体的原因,您需要配置您的应用程序。
更多详情
我一直在试图通过实验和看明白编导代码 。
编排的文档与打开“坐标动画,输入和图中的时刻”。 这实际上是一个很好的说明,但其余的那张过分强调动画。
编舞是执行3种类型的回调,在这种顺序运行的实际负责:
- 输入处理回调(处理用户输入,如触摸事件)
- 对于帧之间补间,供给稳定的帧开始时间到任何动画回调/所有动画正在运行。 运行这些回调2日是指任何与动画相关的计算(例如改变视图的位置)已经由第三类型的回调,被调用时提出...
- 查看遍历回调绘制视图层次结构。
其目的是,以匹配在该无效视图重新绘制(和动画补间)与屏幕垂直同步的速率 - 通常是60fps的。
约跳过的帧的警告看起来像一个事后的想法:如果在单次通过3个步骤的时间超过30倍的预期帧持续时间,因此,最小数,你可以期望在日志消息,以查看记录的信息是“跳过30帧” ; 如果每个通需要更长的时间50%比它应该你仍然会跳过30帧( 淘气!),但你不会被警告了。
从3个步骤涉及其明确表示,它不仅是动画,可以触发报警:无效大量的显著部分View
层次或View
具有复杂的onDraw方法可能是不够的。
例如,这将反复触发警告:
public class AnnoyTheChoreographerActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.simple_linear_layout);
ViewGroup root = (ViewGroup) findViewById(R.id.root);
root.addView(new TextView(this){
@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
long sleep = (long)(Math.random() * 1000L);
setText("" + sleep);
try {
Thread.sleep(sleep);
} catch (Exception exc) {}
}
});
}
}
...产生记录是这样的:
11-06 09:35:15.865 13721-13721/example I/Choreographer﹕ Skipped 42 frames! The application may be doing too much work on its main thread.
11-06 09:35:17.395 13721-13721/example I/Choreographer﹕ Skipped 59 frames! The application may be doing too much work on its main thread.
11-06 09:35:18.030 13721-13721/example I/Choreographer﹕ Skipped 37 frames! The application may be doing too much work on its main thread.
您可以在堆栈中看到onDraw
的编舞是无论您是动画的参与:
在example.AnnoyTheChoreographerActivity $ 1.onDraw(AnnoyTheChoreographerActivity.java:25)在android.view.View.draw(View.java:13759)
......相当多的重复...
在android.view.ViewGroup.drawChild(ViewGroup.java:3169)在android.view.ViewGroup.dispatchDraw(ViewGroup.java:3039)在android.view.View.draw(View.java:13762)在android.widget。 FrameLayout.draw(FrameLayout.java:467)在com.android.internal.policy.impl.PhoneWindow $ DecorView.draw(PhoneWindow.java:2396)在android.view.View.getDisplayList(View.java:12710)在安卓.view.View.getDisplayList(View.java:12754)在android.view.HardwareRenderer $ GlRenderer.draw(HardwareRenderer.java:1144)在android.view.ViewRootImpl.draw(ViewRootImpl.java:2273)在android.view。 ViewRootImpl.performDraw(ViewRootImpl.java:2145)在android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1956)在android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1112)在android.view.ViewRootImpl $ TraversalRunnable.run (ViewRootImpl.java:4472) 在android.view.Choreographer $ CallbackRecord.run(Choreographer.java:725)在android.view.Choreographer.doCallbacks(Choreographer.java:555)在android.view.Choreographer.doFrame(CHO reographer.java:525)在android.view.Choreographer $ FrameDisplayEventReceiver.run(Choreographer.java:711)在android.os.Handler.handleCallback(Handler.java:615)在android.os.Handler.dispatchMessage(Handler.java :92)在android.os.Looper.loop(Looper.java:137)在android.app.ActivityThread.main(ActivityThread.java:4898)
最后,如果从降低主线程能完成的工作量其他线程争,跳帧的几率大大增加,即使你实际上并没有这样做在主线程的工作。
在这种情况下,它可能会被认为是误导性的,以表明应用程序做太多的主线上,但Android的真正想要的工作线程在低优先级运行 ,使它们挨饿主线程阻止。 如果你的工作线程是低优先级触发编排警告的唯一方法真的是做过多的主线程上。
这如果Info消息,可以在您的logcat的流行在许多情况下。
在我的情况下,它发生了,当我以编程方式从充气XML布局文件几点看法。 该消息是由本身是无害的,但可能是,将使用所有的应用程序被允许使用,并引起特大恶势力关闭的情况发生RAM以后问题的征兆。 我已经成长为一个喜欢看他的日志WARN /信息/无差错的那种开发的。 ;)
所以,这是我自己的经验:
我得到的消息:
10-09 01:25:08.373: I/Choreographer(11134): Skipped XXX frames! The application may be doing too much work on its main thread.
......当我用从静止的响应数据来充气XML格式的视图和填充其字段(图片,文字等)创建自己的自定义“超复杂的多部分名单” / JSON Web服务(无分页功能)这个意见将加入他们都以正确的顺序到的LinearLayout(与滚动型内垂直方向)作为行,子章节标题和章节标题。 所有这一切都以模拟点击元素列表视图......但好,那是另一个问题。
至于你想在App真正与系统资源的高效负责的开发人员,所以列出的最佳实践(当你的名单并没有那么复杂)是使用ListActivity或ListFragment与装载机,并用适配器填补的ListView,推测这是更有效的,其实这是你应该做这一切的时候,再重复一次,如果您的列表没有那么复杂。
解决方案:我实现了我的REST / JSON的Web服务,以防止“大的反响大小”寻呼和我包的是添加上的AsyncTask的“行”,“节标题”和“分节标题”的意见,以保持主代码线程酷。
所以...我希望我的经验可以帮助其他人认为是破解他们的头与此信息邮件打开。
快乐的黑客攻击!
此使用仿真器,这是众所周知的是缓慢的反正调试时通常发生。
在我来说,我有这些消息时,我告诉了福尔摩斯的动作条inderterminate进度。 因为它不是我的图书馆,我决定隐藏编舞输出。
可以隐藏编排输出到logcat的视图,使用该过滤器表达式:
标签:^((?!编舞)。*)$
我用正则表达式的其他地方解释: 正则表达式匹配不包含字线?