jep*_*epo 3 graphics android scroll system real-time
我目前正在编写一个应该以滚动方式显示实时测量曲线的应用程序(想想ECG记录仪或示波器).UI-Thread中的意外系统调用会使显示结果不稳定.
数据通过蓝牙输入.一切正常,显示平滑滚动,平均更新速率为26帧/秒.但是,尽管如此,显示器仍然很明显.
我使用traceview来获得更多的洞察力,并且根据traceview,口吃是一个呼叫的结果,android/view/ViewRoot.handleMessage
平均每次呼叫持续131毫秒.如果我在traceview中进一步挖掘,周期就会被烧毁android/view/ViewRoot.performTraversals
.这些CPU周期中的92%主要用于递归调用android/view/View.measure
.
从那里它由于递归调用结构而变得复杂.但我可以找到对LinearLayout,FrameLayout和RelativeLayout的onMeasure()方法的调用.每种布局类型的onMeasure()方法消耗大约相同的CPU周期.这很奇怪,因为在我的活动中我只使用一个简单的LinearLayout只有2个元素.我只是没有理由为什么假设重新布局一个带有2个元素的LinearLayout执行对未使用的布局的调用,并且需要高达131毫秒才能做到这一点.
更多信息:
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()
好的,我找到了长时间通话的原因android/view/ViewRoot.handleMessage
.这确实是由我的申请引起的.
我的应用程序有2个屏幕(活动),一个具有复杂的状态信息布局,另一个具有传入数据的实时显示.
通过蓝牙进入的数据包含混合的实时数据和状态数据.当我切换到实时Activity时,我finish();
在启动新的实时Activity后停止了状态Activity.不幸的是,这还不足以阻止消息处理程序,它在UI线程中接收新的状态信息,并继续在不可见和完成的Activity中更新状态数据.此活动的重新布局导致实时数据的断断续续.
现在已经解决了.显示滚动现在合理平滑.
谢谢你的耐心.对于任何在stackoverflow上遇到此Thread的人来说,它可能会有用.
jepo
归档时间: |
|
查看次数: |
1425 次 |
最近记录: |