iphone - 在 drawRect 中绘制对象与添加子视图并移动它们的框架

Question

（第一次在这里问问题，所以请原谅我的礼仪错误）

基本情况：我有多个可以在屏幕上移动的图像。

简单的解决方案#1：
主循环将遍历对象数组，告诉每个对象移动自己，然后告诉视图刷新自己[self.view setNeedsDisplay]。然后视图将获取数组并跨过它并在屏幕上的点绘制对象。

简单的解决方案#2：
然后我开始尝试让对象拥有自己的视图作为属性。

当对象被添加到主 NSArray 时，视图被添加到主绘图视图中。[self.view addSubView:newThing.view].

主循环将跨过对象并告诉它们移动。在对象类中，移动将导致视图的 frame.origin 移动，这将导致它们在主视图上移动。

这还有一个优点，即对象可以在需要时将子视图添加到其图像中，例如粒子效果或相关子视图。

缺点是它似乎将更多类似视图的代码放入模型中并隐藏了一些视图工作。

简单的示例项目在这里。
注意：这两个示例项目都绘制了我期望在我的真实模拟器中需要的更多东西。

我的问题？”
解决方案 #2 导致代码看起来更清晰，并且做一些简短的分析表明在我处理数千个对象之前似乎没有太大的性能或内存差异，然后绘图版本节省了大量的内存开销。但即使是 400 个对象，也没有那么多额外的内存来保存所有这些视图。

是否有某些原因我不应该使用我缺少的解决方案＃2？通过让模型更聪明地了解最终将要绘制的内容，是否可以“打破”VMC？

score 0 · Accepted Answer

您可以通过在对象和视图之间添加另一层来绕过 MVC 违规，对象知道模型对象和视图，并告诉视图在发生变化时移动。

解决方案 #2 需要更多的内存和计算，尤其是在您有很多对象的情况下。它还使您对绘图的控制较少，如果您想要具有特殊效果，这可能是一个问题。出于这个原因，至少对于游戏来说，它通常不被使用。但最后，如果它确实让您的生活更轻松并且您对性能感到满意，那么没有理由不选择它。

不过，看看 Core Animation 可能是个好主意。它允许您实现类似的模式（然后每个对象都有自己的层而不是视图），但对于特殊效果更快、更灵活。

1 回答 1