所以，我一直在玩核心剧情（iOS版本1.5），看看我可以如何融入我的应用程序。我正在iPad 3上测试它，这通常是我的基本图形设备。核心绘图使用大量内存
而是粘贴一吨的代码，这里的情节配置：
- 1图，采用了纯白色主题
- 1剧情空间
- 2个独立散点图，每小区3个数据点。
- 2轴：
- X轴：范围：2013年12月，2014年3月（NSTimeInterval）。 3个标签，3个主要蜱和约90个次要蜱（每天1个）
- YAxis：范围：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对象中（或者从它们衍生而来）之外，这里没有太多要说的。时间分析器显示，当我调整大小或移动绘图时，大部分时间都花费在源自drawInContext:方法的各种核心绘图方法之一中。具有讽刺意味的是，该方法的第一行是self.useFastRendering = YES;。
我会补充说情节几乎是全屏。我有几个其他控件来编辑绘图字段，图形类型等，但就是这样。
说实话，我很希望我会错过某些与表演有关的财产，但似乎并非如此。核心图可能适用于静态图，但它在交互性和性能方面落后。
我花了一些时间看看Shinobi Controls并检查他们的iOS演示。这正是我想要的图表中交互性的一种交互性。但我很怀疑在我的应用中包含昂贵的，封闭的第三方代码......
可能我会花时间手工创建我的图表。
核心绘图确实存在已知的性能问题，特别是在像iPad 3这样的旧硬件上，但这听起来非常极端。你有没有分析应用程序，看看瓶颈在哪里？ –
是的，我介绍了这个应用程序（见上文）。这个问题几乎完全在核心剧情中。 –
我有同样的问题亚伦..简单的饼图.. 3节..我正在观看设备定位通知和内存穿过屋顶，在设备的几次旋转后崩溃的应用程序..看着Shinobi图表也许..可能必须为Shinobi自己分出..！ – jheneghan