(第一次在这里真正提出问题，所以请原谅我的礼仪错误(
基本情况：我有多个可以在屏幕上移动的图像。
简单解决方案 #1：
主循环将单步跳过对象数组，告诉每个对象自行移动，然后告诉视图[self.view setNeedsDisplay]刷新自身。然后，视图将获取数组并单步执行该数组，并在屏幕上的点处绘制对象。
非常简单的示例项目，将 200 个箭头放入 NSArray 并将它们移动到此处。
简单解决方案#2：
然后，我开始尝试让对象将自己的视图作为属性。
将对象添加到主 NSArray 时，视图将添加到主工程视图中。 [self.view addSubView:newThing.view] .
主循环将跨过对象并告诉它们移动。在对象类中，移动将导致视图的 frame.origin 移动，从而导致它们在主视图上移动。
这也具有一个优点，即对象可以根据需要向其图像添加子视图，例如粒子效果或相关子视图。
缺点是它似乎将更多类似视图的代码放入模型中，并隐藏了一些视图工作。
简单的示例项目在这里.
注意：这两个示例项目都绘制了更多我期望在我的真实模拟器中需要的东西。
我的"问题？">解决方案 #2 导致代码看起来更干净，并且做一些简短的分析表明，在我得到数千个对象之前，似乎没有太大的性能或内存差异，然后绘图版本节省了大量的内存开销。但即使在 400 个对象中，保存所有这些视图也不是那么多的额外内存。
有什么原因我不应该使用我缺少的解决方案#2吗？是否可以通过让模型对最终绘制的内容更智能地"破坏"VMC？
对象和视图之间添加另一层来绕过 MVC 冲突，这些对象知道模型对象和视图，并在发生更改时告诉视图移动。
解决方案 #2 需要更多的内存和计算，尤其是在您有很多对象的情况下。它还使您可以减少对绘图的控制，如果您想获得特殊效果，这可能是一个问题。出于这个原因，至少对于游戏，它通常不被使用。但最后，如果它真的让你的生活更轻松，并且你对表现感到满意，那么没有理由不选择它。
不过，看看核心动画可能是个好主意。它允许您实现类似的模式(然后每个对象都有自己的图层而不是视图(，但对于特殊效果来说更快、更灵活。