代码之家 › 专栏 › 技术社区 › Craig

在iPhone上缩放和裁剪巨大的图像

crop scale tiles image iphone

Craig · 技术社区 · 15 年前

在过去的几周里,我一直在努力让一个瓷砖机制在iPhone上工作。我需要缩放和裁剪大约150MB的图像,以便将它们保存为滚动视图所请求的分片,允许用户以高分辨率查看图像。

问题是,这些图片真的推动了iPhone所能处理的范围。看起来很容易将这些巨大的图像缩小到1000左右,然后进行平铺,但是对于较大的缩放级别,我需要在中间进行缩放,比如说4000左右,这太大了。所以我突然想到用全尺寸的图像制作中等尺寸的块,并将这些块和中等变焦进行平铺。

通过在内部循环周围创建一个自动释放池,并在每个循环后将其排出,我基本上可以控制内存,但有时,在我看来,这似乎是随机的,内存正在泄漏,或者至少没有被耗尽。我在一个二级线程上执行所有这些操作,当它返回到该线程中的第一个函数时,我会释放该线程自己的autoreleasePool,然后才清除最后一个内存工件。它似乎不打扰模拟器,但iPhone的宽容度要低得多,它在完成整个平铺过程之前就崩溃了。我使用的裁剪代码来自hive05

http://www.hive05.com/2008/11/crop-an-image-using-the-iphone-sdk/

以前有没有其他人必须处理如此庞大的图像?预生成瓷砖是最好的方式吗?对于为什么某些循环会增加内存而有些不会增加内存,或者如何强制每个自动释放的对象清除内部池,而不是等待外部池,有什么建议吗?

谢谢你读到这里。

对于got-to-add,这些图像是tif,因此直接读取位图信息可能比缩放和裁剪整个图像要好。

2 回复 | 直到 15 年前

luvieere 15 年前

首先,我严重怀疑150MB的图像是否适合存储在设备的内存中,即使我们谈论的是3GS。第三方应用程序的可用内存约为128 MB 最大限度 . 看到设备控制台消息并寻找内存警告,我想您会看到在崩溃之前,应用程序在尝试加载图像时会发出警告。以块形式读取位图信息似乎更明智,因为您将一次管理较小的部分。我认为Cocoa没有随机访问文件API,所以您必须使用C函数。

Craig 15 年前

我已经成功地编写了循环遍历1024x1024瓷砖的循环,我的iPhone3G能够完成处理。虽然这需要30分钟,所以它不是很好,但这就是你在手机上使用150MB TIF所能得到的。

为了保持低内存使用率,我必须在每次迭代后耗尽自动恢复池。苹果技术支持人员指出,由于iPhone是一个参考计数的环境,而不是垃圾收集的环境,因此最好在每个内部循环开始时创建一个新的自动恢复池,并在每个循环结束时将其排出,而不是在任何循环开始之前创建它,将其多次排出,然后在循环结束后释放它。一个。在我做了那个改变之前,我的应用程序会使iPhone崩溃,但在模拟器上运行良好。