（第一次在这里问一个问题，原谅我的礼节错误）
基本情况：我有多张图片可以在屏幕上移动。
简单解决方案＃1 ：
主循环将跨越对象数组，告诉每个对象自己移动，然后告诉视图刷新自己[self.view setNeedsDisplay]。然后视图将获取数组并跨过它并在屏幕上的点处绘制对象。
非常简单的示例项目，在NSArray中放置200个箭头并将它们移动到here。
简单解决方案＃2 ：
然后我开始尝试让对象拥有自己的视图作为属性。
将对象添加到主NSArray后，视图将添加到主图纸视图中。 [self.view addSubView:newThing.view]。
主循环将跨过对象并告诉它们移动。在对象类中，移动将导致视图的frame.origin移动，这将导致它们在主视图上移动。
这样做的另一个好处是，如果需要，对象可以将子视图添加到其图像中，例如粒子效果或相关的子视图。
缺点是它似乎将更多类似视图的代码放入模型中并隐藏了一些视图工作。
简单示例项目here 注意：两个示例项目都吸引了更多我期望在真实模拟器中需要的东西。
我的“问题？”
解决方案＃2导致代码更清晰，并且进行一些简短的分析表明，在我获得数千个对象之前似乎没有太多性能或内存差异，因此绘图版本节省了大量的内存开销。但即使在400个物体上，也不是那么多额外的记忆来容纳所有这些观点。
是否有一些原因我不应该使用我失踪的解决方案＃2？通过让模型对最终绘制的内容更加智能，可以“破坏”VMC吗？
答案 0 :(得分：0)
你可以通过在对象和视图之间添加另一个层来解决MVC违规，其中的对象既知道模型对象又知道视图，并告诉视图如果有什么变化就会移动。
解决方案＃2需要更多的内存和计算，特别是如果你有很多对象。它还可以减少对绘图的控制，如果您想要特殊效果，这可能是一个问题。出于这个原因，至少对于游戏来说，通常不使用它。但最后，如果它确实让你的生活更轻松，而你对表现感到满意，那就没有理由不去挑选它。
不过，看看核心动画可能是个好主意。它允许您实现类似的模式（然后每个对象都有自己的层而不是视图），但对于特殊效果更快，更灵活。