android - 图表引擎准备好实时绘图了吗？

Question

我正在尝试绘制一些实时数据的图表，这里的“实时”意味着 < 10 毫秒的数据，理想情况下尽可能低。我已经能够让 Android 如此快速地获取和处理数据，但 ACE 看起来似乎并不是为实时使用而设计的。第一个症状是垃圾收集器像没有明天一样启动并完全杀死应用程序。我正在以“滑动窗口”方式可视化数据，所以我并不期望 ACE 实时绘制千分之几十点。我看了一下它，XYChart 的 onDraw 在看起来很方便的情况下肯定会分配很多，并且可能使代码更具可读性但并不是真正需要的。这甚至可能比以前更糟，所以可能还没有引起注意。我看到问题 #225 的错误修正解决了一个并发问题:

return mXY.subMap(start, stop);

对于:

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

这会产生巨大的分配(虽然仍然由原始 subMap 支持)，当 onDraw 正在进行时将更新排队并稍后在原子更新或该行上的某些内容上处理它们以避免并发问题可能会更好。

这里真正的遗憾是ACE 对于我需要的东西肯定足够快。它可以在我的硬件上完美地完成我需要的事情，但由于它在重绘上分配了如此多的资源，Android 对 GC 变得疯狂。它很快就会在 GC 运行时开始分配，因此它必须等待，我的应用开始看起来像一部定格动画电影。

但真正的问题是:期望能够使用 ACE 实时(低于 200 毫秒的刷新率)重新绘制 4 或 6 个线图(平板电脑应用程序)是否合理，或者它是否根本没有为这种滥用做好准备？如果答案是否定的。您还有其他选择吗？

编辑 20130109:修订版 471 对小数据集做了相当多的改进。 2.000 点/4 个图表/100 毫秒刷新率可行且流畅。日志仍然疯狂地看到“GC_CONCURRENT freed”(大约 10/秒)，但没有看到“WAIT_FOR_CONCURRENT_GC blocked”，这是让您的应用停止运动的 showstoppers。在 3.000 点/1 个图表/100 毫秒时，它显然不平滑。我们再次在 logcat 和卡顿应用程序上遇到“WAIT_FOR_CONCURRENT_GC blocked”雪崩。同样看起来我们没有速度问题，只有内存管理问题。

我可能看起来像是在要求 ACE 施展魔法，但在重构我的所有代码以以 1KHz 的频率检索和存储遥测数据后，我碰壁了。当我终于看到我的应用程序实时检索和存储所有这些数据而根本没有触发 GC 时，我在尝试绘制图表时用 ACE 拉扯了我的头发 :)

Answer 1

首先感谢您提出的重要问题和观点。关于在 onDraw() 方法下完成的大量内存分配，您绝对是正确的。我修复了它并检查了 SVN 中的代码。我还在 onDraw() 方法中添加了一个同步块(synchronized block)，这样在重绘期间向数据集添加新数据时，它有望不会抛出 ConcurrentModificationException。

请从 SVN 检查代码并执行 ant dist 以构建新的 AChartEngine jar 文件并将其嵌入到您的应用程序中。请看说明书here .

回答您的问题:AChartEngine 绝对可以用于动态图表。您报告的问题是一个问题，但现在应该已修复。我已经使用它编写了动态图表。但是，您需要确保不要向数据集添加 100000 个数据值。可以从数据集中删除旧数据以获得性能。

5个左右的折线图，上千个点，画绝对合理。