意外的android系统调用可以平滑显示滚动图形的口吃

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毫秒才能做到这一点.

更多信息:

  • 平台HTC渴望HD与Android 2.3.1.
  • 我使用处理程序在UI线程中执行绘图.
  • Layout是一个简单的LinearLayout,包含2个元素:自定义视图和textField.
  • 状态栏隐藏了getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);.
  • 对每个新的数据块执行绘图,该数据块大约到达.每50毫秒.
  • 绘图本身使用画布,其性能足以跟上传入的数据.

经过长时间的解释,以下是问题:

  1. 什么是调用android/view/ViewRoot.handleMessage?(调用每隔850毫秒相对相等,没有明显的链接(没有直接调用,调用次数和相对位置没有链接到绘图的消息处理程序)到我的Activity的任何活动)
  2. 如何抑制对android/view/ViewRoot.handleMessage的调用,或者如何让它们更快(我的LinearLayout中只有2个元素)
  3. 对未使用的布局的调用首先让我想到状态栏或一些隐藏的活动(例如主屏幕),它们可能会使用这样的布局.但是为什么这些电话是我活动的一部分呢?据我所知,跟踪应该只跟踪活动进程.例如,产生实时数据的服务调用不是跟踪的一部分.
  4. 是否有可能跟踪某些系统组件的单个调用?当我放大traceview时,我看到这个调用顺序: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()
  5. 关闭主题:是否有可能导出除了截图以外的traceview(parents-children-CPU time等)内显示的数据?

jep*_*epo 5

好的,我找到了长时间通话的原因android/view/ViewRoot.handleMessage.这确实是由我的申请引起的.

我的应用程序有2个屏幕(活动),一个具有复杂的状态信息布局,另一个具有传入数据的实时显示.

通过蓝牙进入的数据包含混合的实时数据和状态数据.当我切换到实时Activity时,我finish();在启动新的实时Activity后停止了状态Activity.不幸的是,这还不足以阻止消息处理程序,它在UI线程中接收新的状态信息,并继续在不可见和完成的Activity中更新状态数据.此活动的重新布局导致实时数据的断断续续.

现在已经解决了.显示滚动现在合理平滑.

谢谢你的耐心.对于任何在stackoverflow上遇到此Thread的人来说,它可能会有用.

jepo