achartengine准备好实时绘图吗？

Question

我试图绘制一些实时数据,"实时"这里意味着<10毫秒数据,理想情况下尽可能低.我已经能够让Android快速获取和处理数据,但ACE看起来并不是为了实时使用而设计的.最初的症状是垃圾收集器像没有明天一样开始并完全杀死应用程序.我正在以"滑动窗口"的方式可视化数据,所以我不希望ACE能够实时绘制数万分之一的点数.我已经看了一下它,onDraw for XYChart肯定会分配非常多的情况,它看起来很方便,可能使代码更具可读性,但并不是真正需要的.这甚至可能比以前更糟,所以它可能还没有被注意到.我看到问题#225的bugfix解决了并发问题的变化:

return mXY.subMap(start, stop);

对于:

return new TreeMap<Double, Double>(mXY.subMap(start, stop));

这会创建巨大的分配(仍然由原始子映射支持),当onDraw正在进行时排队更新可能会更好,并且稍后在原子更新或该行上的某些事情处理它们以避免并发问题.

在实在可惜这里是ACE肯定是足够快的我需要什么.它可以完美地完成我在硬件上所需要的东西,但由于它在重绘Android上的分配如此严重,因为它对GC很疯狂.它很快开始分配,而GC正在运行,所以它必须等待,我的应用程序开始看起来像一个定格动画电影.

真正的问题是:期望能够使用ACE实时重绘(平板电脑应用程序)4或6个线性图表是否合理(或者是200毫秒的刷新率),还是没有为这种滥用做好准备？如果答案是否定的.你推荐的其他选择吗？

编辑20130109: 修订版471为小数据集改进了很多东西.2.000点/ 4个图表/ 100毫秒刷新率是可行和平滑的.日志仍然看到"GC_CONCURRENT释放"像疯了一样(大约10 /秒),但没有"WAIT_FOR_CONCURRENT_GC被阻止"这些是使你的应用程序停止运动的showstoppers.在3.000点/ 1图表/ 100毫秒,它显然不顺利.我们再次在logcat和口吃应用程序上发生了"WAIT_FOR_CONCURRENT_GC阻塞"的雪崩.再次看起来我们没有速度问题,只有内存管理问题.

可能看起来我可能会要求ACE做魔法,但是在重构我的所有代码以检索和存储1KHz的遥测数据之后我碰到了这堵墙.一旦我终于看到我的应用程序检索并存储了所有这些实时而没有触发GC,我试图绘制时用ACE拉我的头发:)

Answer 1

经过巨大努力优化我的应用程序上的其他所有内容后，我仍然无法按照我所理解的“实时”进行绘制。这个库很棒，而且速度非常快，但是每个 onDraw 分配内存的方式不可避免地会触发大量的垃圾收集，这与它自己的分配发生冲突，因此 android 会暂时冻结您的应用程序，从而导致卡顿，这与“实时”绘图完全不兼容。这里的“卡顿”范围可以是 50-250 毫秒（是的，毫秒），但这足以杀死一个实时应用程序。

AChartengine 将允许您创建“动态”图表，只要您不要求它们是“实时”的（10 帧/秒，（<100ms 刷新率）或您所说的“平滑”）。

如果有人需要有关此处核心问题的更多信息，或者为什么我说该库足够快但内存分配模式最终会导致性能问题，请查看Google I/O 2009 - 为 Android 编写实时游戏