【发布时间】：2014-03-27 16:33:21
【问题描述】：
所以，我一直在玩 Core Plot（iOS，1.5 版），看看我能多好地集成到我的应用程序中。我正在 iPad 3 上测试它，这通常是我的图形基础设备。
这里是绘图配置，而不是粘贴大量代码：
- 1 个图表，使用纯白色主题
- 1 个绘图空间
- 2 个单独的散点图，每个图 3 个数据点。
- 2 轴：
- XAxis：范围：2013 年 12 月，2014 年 3 月 (NSTimeInterval)。 3 个标签、3 个主要刻度和大约 90 个次要刻度（每天 1 个）
- Y 轴：范围：0、250。3 个标签，3 个主要刻度，12 个次要刻度。 YAxis 在图表的右侧浮动。
- 每个轴有 1 个标题
所以，我的应用通常占用 33-34 mb 左右的空间。如果显示一些图像，它可能会飙升至 50 mb，但通常它会在 33-34 mb 范围内。但是，加载 Core Plot 会使内存跃升至 63 mb 左右。如果我启用缩放并在图表上捏合以缩放它或我只需拖动图表，内存使用量会飙升至 ~ 143 mb，然后又回到 84mb。当我关闭图表时，内存下降到大约 22mb，我认为这是因为其他缓存因内存压力而被清除。
另外，也许相关的是，捏和拖动图表非常慢。也许平均 2-3 FPS 下降到 2 SPF（每帧秒数……说真的）。
看起来 Core Plot 占用了大量内存，而且速度非常慢。
我是否遗漏了什么，或者这只是核心情节的方式？除非我可以加快速度并使用更少的内存，否则我无法在生产中使用 Core Plot。
更新
我已经使用 Instruments 分析了我的应用程序。除了所有的内存增益都在 Core Plot 对象中（或从它们派生）之外，这里没有太多要说的。 Time Profiler 显示，当我调整绘图大小或移动绘图时，大部分时间都花在源自 drawInContext: 方法的各种核心绘图渲染方法之一上。具有讽刺意味的是，该方法的第一行是self.useFastRendering = YES;。
我要补充一点，情节几乎是全屏的。我还有其他几个控件可以编辑绘图字段、图形类型等，仅此而已。
说实话，我有点希望我会错过一些与性能相关的属性，但事实似乎并非如此。 Core Plot 可能适用于静态图，但在交互性和性能方面落后。
我花了一些时间查看Shinobi Controls 并查看他们的 iOS 演示。这正是我在图表中想要的那种交互性和性能。但我对在我的应用程序中包含昂贵、封闭的第 3 方代码持怀疑态度...
我可能会花时间手工创建图表。
【问题讨论】：
-
Core Plot 确实存在已知的性能问题，尤其是在 iPad 3 等旧硬件上，但这听起来非常极端。您是否对应用进行了分析以了解瓶颈在哪里？
-
是的，我分析了应用程序（见上文）。问题几乎完全出在核心情节上。
-
我也有同样的问题 Aaron.. 简单的饼图.. 3 个部分.. 我正在查看设备方向通知，内存溢出，经过几次旋转后应用程序崩溃设备.. 也在看忍者图表.. 可能不得不自己为忍者分叉..！