我目前正在编写一个应用程序,它应该以滚动的方式显示实时测量曲线(比如心电记录仪或示波器)。UI-线程中的意外系统调用会使显示结结巴巴。
数据通过蓝牙进入。所有的功能都很好,显示是相当平稳的滚动,平均更新率为26帧/秒。但是,显示是显着的口吃。
我使用traceview来获得更多的洞察力,根据traceview的说法,口吃是调用android/view/ViewRoot.handleMessage的结果,每次通话平均持续131 ms。如果我在traceview中深入挖掘,android/view/ViewRoot.performTraversals内部的循环就会被烧毁。92%的这些CPU周期是在对android/view/View.measure的大部分递归调用中消耗的。
从这里开始,由于递归调用结构,它变得复杂起来。但是我可以找到对LinearLayout、FrameLayout和RelativeLayout的LinearLayout()方法的调用。每种布局类型的onMeasure()方法消耗的CPU周期大致相同。这是非常奇怪的,因为在我的活动中,我只使用了一个只有2个元素的简单LinearLayout。我只是不明白为什么一个假定的带有2个元素的LinearLayout重新布局会调用不使用的布局,需要131 ms才能完成。
更多信息:
textField.
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);.
在做了这么长的解释之后,以下是一些问题:
toplevel -> android/os/Message.clearForRecycle() -> android/os/MessageQueue.nativePollOnce() -> android/os/SystemClock.uptimeMillis() -> com/htc/profileflag/ProfileConfig.getProfilePerformance() -> android/os/Handler.dispatchMessage() -> android/view/ViewRoot.performTraversals() 发布于 2011-12-13 11:01:19
好的,我找到了长时间呼叫android/view/ViewRoot.handleMessage的原因。这确实是我的申请造成的。
我的应用程序有两个屏幕(活动),一个是复杂的状态信息布局,另一个是输入数据的实时显示。
通过蓝牙输入的数据包含混合的实时数据和状态数据。当我切换到实时活动时,在启动新的实时活动后,我将使用finish();停止状态活动。不幸的是,这还不足以停止消息处理程序,该处理程序接收UI线程中的新状态信息,并在不可见和已完成的活动中继续更新状态数据。该活动的中继导致了实时数据的口吃。
这个问题现在已经解决了。显示滚动现在是合理的平滑。
谢谢你的耐心。希望它对任何在堆叠溢出上绊倒这个线程的人都有帮助。
杰波
https://stackoverflow.com/questions/8340766
复制相似问题