iOS 如何避免 图像 解压缩的 时间 开销.docVIP

iOS 如何避免 图像 解压缩的 时间 开销 转:如何避免图像解压缩的时间开销#more-722 这是一篇译文，(原文AvoidingImageDecompressionSickness在此)，原文是我看过的非常不错的一篇关于iOS图片显示的一些文章，解决了我的一些疑惑和问题，因此翻译过来分享，为保证一定的通顺性其中一部分内容与原文有些许出入，但我尽量保证了意思的一致性，欢迎指正批评，横线之间为译文，略挫，见谅: 当开始iCatalog.framework的工作时，我发现使用大尺寸图片会引起一些恼人的问题，大意味着这个图片有足够大的分辨率(1024×768)来覆盖iPad的整个屏幕，或者覆盖未来RetinaDisplayiPad(如果有的话)的双倍分辨率(2048×1536)屏幕。 想像一个杂志类型的App，一个分页的UIScrollView，每页显示一个UIImageView，一旦某一页进入屏幕区域你就要为这个页创建或者重用一个UIImageView并把它放到scrollView的当前显示区域，即使这个页只有一个像素进入到屏幕区域，你还是要做这些工作。这在模拟器上运行得非常好，但在真机上进行测试，你会发现每次进入下一页时都会有一个明显的延迟。这个延迟来自于将图片从文件解压缩并渲染到屏幕上这一系列的工作。不幸的是UIImage仅在图片将要显示的时候做这个解压工作。 因为添加一个view到当前的view层次结构中必须在主线程上进行，所以图片的解压缩和之后渲染到屏幕上的工作也在主线程进行，这就是这个延迟产生的原因，这个问题也可以在store里的其他有类似这种效果的app中发现。 一般我们使用的图片有两种主要格式，jpeg和png。Apple通常推荐你使用png作为用户界面的图片格式，这些图片会被一个叫pngcrush开源的工具优化(译者注:这个工具就在/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush)，这样对于iOS设备就可以在显示时更快地进行解压和渲染。iPad平台上首批出现的杂志应用，比如Wired，就曾用过png作为杂志内容图片的格式，这导致了这个应用的某一版本大小超过了500MB(link)[ 虽然png格式的图片会被事先优化好，但是这并不意味着在所有情况下png都是最佳的图片格式，png对于那些app中自带的图片来说非常好，但是对于要从internet上down下来的图片来说又会怎样呢。png和jpeg这两种格式都有各自的优缺点: png格式的图片有alpha通道，jpeg则没有。png无损压缩，jpeg允许你选择0-100%的压缩质量。如果需要alpha通道(透明)，就只能用png格式。但是如果你不需要一个完美的图片，就可以使用jpeg格式，jpeg格式会忽略那些你看不到的信息，对于大部分的图片可以使用60-70%的压缩质量而不对图片造成明显的影响，对于比如文字那样有sharppixels的图片就可能需要较高的压缩质量，对于照片可以使用较低的压缩质量。 来看一下一个图片的空间消耗: 磁盘空间或者通过internet传输所消耗的空间 解压缩空间，通常是长X宽X高X4字节(RGBA) 当显示在一个view中时，view本身也需要空间来存储layer 对于这里的第一个问题，有一个可能的优化方法:将压缩的文件拷贝到内存中不如映射到内存中，NSData有能力来假设一块磁盘空间是在内存中的，这样当访问这个图片时实际上就是从磁盘访问而不是从内存。据说CGImage知道哪种访问方式是最高效的，UIImage只是将CGImage封装了一下。 对于将这些像素显示到屏幕上最快要多久?这个问题，显示一个图片所消耗的时间由以下三个因素决定: 从磁盘上alloc/initUIImage的时间 解压缩的时间 将解压缩后的比特转换成CGContext的时间，通常需要改变尺寸，混合，抗锯齿工作。 要逐一解答各个问题，我们需要一个benchmark来测量。 测试环境和测试内容 我做了一个在iOS设备上运行的benchmarkapp。对优化和未优化的png图片以及不同尺寸的图片进行了测试，最小时间单位为1ms，不是特别精确，但已经有足够的参考价值了。 测试包括128×96,256×192,512×384,1024×768和2048×1536这几种比较有代表性的分辨率，以及优化过的png，未优化的png，压缩质量从10-100%的jpeg这几种格式。benchmark运行在iPad1+2，iPhone3G，iPhone3G，iPhone4上。 以下为各个设备的硬件参数，来自Wikipedia: iPhone3G:Samsung32-bitRISCARM11620MHz处理器(降