Question

我担心这是邪恶的代码：

CGRect iRect = CGRectMake(0.0f, 0.0f, 320.0f, 400.0f);
UIImageView *imgView = [[UIImageView alloc] initWithFrame:iRect];
imgView.animationImages = [NSArray arrayWithObjects:
                [UIImage imageNamed:@"b0001.png"],
                [UIImage imageNamed:@"b0002.png"],
                // 150 more
                [UIImage imageNamed:@"b0152.png"],
                nil];

我稍微记得imageNamed：是邪恶的。如果我这样做，并且提供UIImage对象，那么那些UIImage对象会立即将这些图像文件加载到内存中，对吗？而且，除此之外，所有这些152块厚厚的UIImage对象在内存中占了很大的优势，因为它们是自动释放的，不是吗？

总而言之，使用这种技术很糟糕。可以？我不知道。在我这个年纪久远的第一代iPod touch上，这似乎在25 fps时没有延迟。非常顺利和美好。我唯一担心的是，其他一些设备可能会对此有所不同。虽然我有最弱的可编程ipod触控功能。

无论如何，有没有人看到有任何改善的可能性？或者我应该不使用它并在自己的算法中使用setImage：UIImageView，它会使用那个粗糙的imageWithContentsOfFile（可能命名为不同）加载和设置带有延迟选择器的图像，没有自动释放？也许一些聪明的家伙为高性能的拇指视频写了一个小的lib，它由图像序列组成？

（不，视频不是iphone上的一个选项;苹果框架只支持全屏，我不知道还有什么可以做到的）

Answer 1

你对imageNamed是正确的...你不应该在很多情况下使用它，因为它在内部缓存图像。使用：

[UIImage imageWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"image1" ofType:@"png"];

您唯一想要使用imageNamed的时间是

1）你一遍又一遍地重复使用一个图标（tableviews等......）
2）您尚未实施your own caching system

Answer 2

我不想尝试将如此多的图像加载到UIImageView数组中。类似的问题是asked here。我在那里描述的缓冲方法也应该适用于你的情况。

是否有更高效的动画图像序列方式？

2 个答案: