对于大图像,UIImage 的 imageNamed 是否仍然会导致 iOS4 上的内存问题?

发布于 2024-10-07 07:15:30 字数 445 浏览 2 评论 0原文

我发现几篇内存管理文章提到当内存中有大量大图像时,UIImage 的 imageNamed 会导致问题。

http://akosma.com/2009/01/28/ 10-iphone-内存管理-提示/ http://www.alexcurylo.com/blog/2009/ 01/13/imagenamed-is-evil/

这两个都是为操作系统版本 <= 3.0 编写的。

有谁知道这些在 iOS 4 中是否仍然存在问题?

I found a couple of Memory Management articles that mentioned UIImage's imageNamed causing problems when you have a lot of large images in memory.

http://akosma.com/2009/01/28/10-iphone-memory-management-tips/
http://www.alexcurylo.com/blog/2009/01/13/imagenamed-is-evil/

Both of these were written for OS version <= 3.0.

Does anyone know if these are still a problem in iOS 4?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

酷到爆炸 2024-10-14 07:15:30

不再是问题,请参阅此处也许在这里

No longer a problem, see here, and maybe here.

遗心遗梦遗幸福 2024-10-14 07:15:30

如果您查看此链接:消除 UIImage imageNamed: FUD 您会看到那里大图像和 imageNamed 确实是两个问题:

  1. 在 iOS 3.0 之前,imageNamed 的缓存例程存在一个错误:即使收到内存警告,它也不会释放缓存。这是一个相当大的问题,对我个人来说也是很多内存崩溃的根源,因为在使用 imageNamed: 加载它之后你无法恢复内存。这不再是问题,因为这似乎已在 3.0 中修复。
  2. imageNamed:在其缓存中保留未压缩的图像数据本身。对于非常大的图像(就屏幕上的尺寸 - 宽度 x 高度而言),此数据可能非常大。 width * height * 4 是我经常看到的未压缩大小。如果您使用相当大的图像,这对您来说仍然可能是一个问题 - 如果您不需要经常重新绘制它们,则尤其要避免。

回顾一下:1 不再是问题,2 可能是问题。

If you look at this link: Dispelling the UIImage imageNamed: FUD you'll see there are really two problems with large images and imageNamed:

  1. Prior to iOS 3.0 was a bug in the caching routines of imageNamed: such that it would not let go of its cache even when it received a mem warning. This was a pretty major issue and was the source of a lot of memory crashes for me personally, as there's no way you could get memory back after using imageNamed: to load it. This is NOT an issue anymore, as this seems to have been fixed in 3.0.
  2. imageNamed: keeps, in its cache, the uncompressed image data itself. For really large (in terms of their size on screen - width x height) images, this data can be really large. width * height * 4 is what I've commonly seen cited for its uncompressed size. This would still potentially be a problem for you if you are using rather large images - and is especially to be avoided if you don't need to redraw them often.

So to recap: 1 is no longer a problem, 2 might be.

昨迟人 2024-10-14 07:15:30

确实如此。
与 UIPageViewController 结合使用,确实如此。
尝试构建一个显示动物声音和卡通关键帧动画的儿童应用程序
所有个体动物的详细信息都在自己的 UIViewController 中
所有视图都显示在 UIPageViewController 中(Transition:scroll)。
不知道 imageNamed bug,近一个月以来,一直以为这是 UIPageViewController 引起的问题。 ARC 从未释放过内存。
ASA 我切换到 imageWithContentsOfFile 而不是 imageNamed,所有问题都解决了。
UIPageViewController 实际上是无辜的。现在工作顺利。不存在未释放内存的问题。

it does.
In combination with UIPageViewController, definitely it does.
trying to build a kids application displaying animal's sound and cartoon keyFrame animation
all individual animal details are in their own UIViewController
All views are displayed in UIPageViewController (Transition:scroll).
Didn't know about imageNamed bug and for nearly a month , thought it was a problem caused by UIPageViewController. Memory was never being released by ARC.
ASA i switched to imageWithContentsOfFile instead of imageNamed, all problems solved.
UIPageViewController was innocent in real. It works smooth now. No unreleased memory problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文