UIImageView 没有调用drawRect
我的 IB 中有一个 UIImageView，并且我使用一个方法 drawRect 创建了 UIImageView 的子类：
@implementation UIImageViewLine
- (void)drawRect:(CGRect)rect
{
NSLog(@"CALLED");
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetStrokeColorWithColor(context, [UIColor redColor].CGColor);
CGContextSetLineWidth(context, 1.0f);
CGContextMoveToPoint(context, 0, 0);
CGContextAddLineToPoint(context, self.frame.size.width, self.frame.size.height);
CGContextStrokePath(context);
}
@end
我已将 UIImageView 的类更改为该子类，但是从未调用过 drawRect。知道为什么吗？
I have a UIImageView in my IB and I created a subclass of UIImageView with one method drawRect:
@implementation UIImageViewLine
- (void)drawRect:(CGRect)rect
{
NSLog(@"CALLED");
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetStrokeColorWithColor(context, [UIColor redColor].CGColor);
CGContextSetLineWidth(context, 1.0f);
CGContextMoveToPoint(context, 0, 0);
CGContextAddLineToPoint(context, self.frame.size.width, self.frame.size.height);
CGContextStrokePath(context);
}
@end
I have changed the class of the UIImageView to this subclass, however the drawRect is never called. Any idea why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
UIImageView在子类化时不会调用drawRect。来自 文档：
您只需将
UIImageView替换为普通的UIView并在UIView的drawRect 方法或在子层中。The
UIImageViewdoesn't calldrawRectwhen subclassed.From the documentation:
You can simply replace the
UIImageViewby a normalUIViewand draw the image and your custom drawings in theUIView'sdrawRectmethod or in child layers.除了 sch 的答案之外，值得注意的是 UIImageView 的使用方式与 UIView 的不同。
ImageView 的方法是更改其 .image 属性。这意味着图像缓存在视图堆栈上。如果图像每一帧都发生变化，那么这不会给你带来太多。但如果没有，这也是一个相当大的进步。在大多数游戏/应用程序中，大多数对象不会每帧都发生变化。
您可以通过调用底层 CALayer 来更改 UIView 的位置、旋转和不透明度。这只是对变换矩阵的更改，因此几乎没有/没有时间损失。
我强烈建议任何不熟悉这个论点的制作实时 2D 图形的人阅读 https://developer.apple.com/library/ios/qa/qa1708/_index.html 它更好地解释了这个论点并给出了示例代码。做起来非常简单。
将游戏对象包装在 UIImageView 中的想法似乎违反直觉，因为您不想将游戏逻辑与表示级别分开，这将它们绑定在一起。然而，在根据苹果的建议修改了我的游戏原型后，我获得了双倍的帧速率，所以我非常愿意牺牲我的架构纯粹性。
In addition to sch's answer, it is worth noting how UIImageView can be used differently to UIView.
The approach with ImageView is that you change its .image property. This means that the image is cached on the view stack. If the image changes every frame, then this doesn't give you much. But if it doesn't, it is a considerable improvement. In most games/apps most objects don't change every frame.
You can change the location, rotation, and opacity of the UIView through calls to the underlying CALayer. This is just a change to a transformation matrix so incurs little/no time penalty.
I strongly recommend that anybody making real time 2D graphics who isn't familiar with this argument reads https://developer.apple.com/library/ios/qa/qa1708/_index.html which explains the argument much better and gives sample code. It is surprisingly simple to do.
The idea of wrapping your game object in a UIImageView seems counterintuitive, because you wan't to separate the game logic from the presentation level and this binds them together. However, having just modded my game prototype according to Apple's recommendation, I'm getting double the frame rate, so I'm very willing to compromise my architectural purity.