首页 > 移动平台 > 详细

ios下UIImage相关开发经验总结

时间:2014-06-30 13:01:01      阅读:567      评论:0      收藏:0      [点我收藏+]

iOS下做和UIImage相关功能有段时间,这里总结列下相关经验。

1. 基本框架image IO

    image IO可以通过URL或者data Provider来生成CGImageSourceRef,然后可以在source上获取第几张图片或者缩略图;根据http://www.mindsea.com/2012/12/downscaling-huge-alassets-without-fear-of-sigkill/文中所讲,使用这种方式比直接加载fullsolutionimage,然后利用core graphics处理要占用更少的内存;这点我还没有明显的发现出来。

    另外,image IO可以做图片的逐渐显示,也就是说明了图片可以逐步解压缩的。

    image IO还可以导出图片,CGImageDestinationAddImage方法可以设置内容及图片相关属性,例如exif、gps等属性,这些属性其实也就是ALAssetRepresentation中的metadata属性;http://zacwe.st/blog/saving-jpegs中给出了一个分别使用UIImageJPEGRepresentation和image IO导出图片的比较,image IO相对UIImageJPEGRepresentation节省的比例和我测试差不多,2000*2000的图平均在20%左右,但时间没有那么大差距,基本上接近,最多10%的差距,有时候image IO反而更少。

   导出图片主要有几个问题,UIImageJPEGRepresentation方法不会导出图片的metadata,而image IO的导出则没有Color Profile,这也就是为什么image IO版本会更小点的原因。UIImageJPEGRepresentation方式会丢失EXIF等信息,一种方式是通过image IO再加回来,一种是自己读取图片二进制,自己手动写bytes,这种一般是利用开源软件,比较麻烦且容易丢掉信息,不推荐使用。image IO这种方式似乎是最好,但是我发现一个比较蛋疼的问题,等传送到应用服务端,服务端再次做处理后,居然比UIImageJPEGRepresentation产生的还大;比较奇怪,需要分析下服务端的实现。

2. UIImage的展示

    UIImage展示在列表中的性能方面,占比较重的分量。个人认为主要影响方面CPU消耗、内存消耗,GPU方面主要保证不要出现blending就可以了;以UIImageView显示为例:

    a. UIImageView并不使用backingstore,而是使用CGImageRef作为CALayer的content。(这里CGImageRef应该是存在RAM内存中的吧)

    b. 通过CATransaction提交改变,在下一个Runloop中,分配内存、读取文件、解压缩、形成bitmap传送给GPU

    在FIC中,讲到iOS 7图片硬件解压缩是没有开放给第三方的,不过个人认为如果说让GPU解压缩的话,解压缩好的图片最好能够缓存,不然可能会存在反复解压缩的情况。所以,通常是异步加载和解压缩,然后再丢给UIImageView做显示。在一些低端设备中,可以异步线程再做一次drawInRect(个人认为这里处理了诸如尺寸拉伸、字节对齐等),这样内存上会比较消耗,但效率会更好点。

  所以,在FIC中提出了针对性的解决方案,它的存储类似sprite sheets,io文件打开只需要一次;直接存储解压缩好的数据,而且还做了字节对齐,CA做字节对齐Copy,我个人理解是保证GPU渲染时不需要对bitmap做额外的数据补齐操作,因为这样的话无论是移动、部分重绘等,都是整齐的,无需额外处理;mmap减少了内存的copy工作(至少减少了kernel到ram),另外使用的是vm,对内存占用有帮助;不过mmap总的来讲,是对大的文件有效率,小的零碎文件效率反而不好。

   FIC的缺陷在于比较适合同样尺寸的小文件,如果文件比较大,解压缩后的数据占用空间比较大。适用场景不普遍,目前不规则的大图片,还是用使用CALayer的方式处理,辅助控制展示时机和drawInRect等方式。

3. 图片格式

    jpg和gif是目前主流格式,不过也有替代品。引用一段知乎上的:“Mozilla 社区推崇带有动画的APNG .... Chrome 则推崇自己的 WebP 格式,Animated WebP 则是可以支持动画的 WebP,它包括了真正的(8bit)alpha通道,每一帧还可以按照需要设置成有损或无损,而Gif 只有1bit,相比Gif文件体积可以压缩的更小。 ...  所以Gif 迟迟没有被新的格式取代也是各个社区对各自利益相持的结果,最终还是会被逐步取代。”。目前又出现了用mp4的格式代替gif,真是苦了程序猿。

    不知道谁有Webp的实际应用,有没有什么切身的感受。

4. 图片上传

    图片上传的重点是上传方式,目前了解到的就是分块上传,通讯使用socket / http / http pipeline 等,效率最好的应该就是直接使用socket,但是控制起来麻烦点;http的方式最耗流量,时间上也是最长的;在网络情况比较好的情况下,这几种方式差别不大;在网络条件比较差得情况下,socket和http pipeline的双工应该会更好点。

5. 图片处理

    个人倾向图片处理方面客户端做展示图的处理效果,服务器端做真正图片的处理;节省客户端的资源;不过滤镜等技术,我基本上没有经验,iOS 7倒是带了不少滤镜的功能,不过这块定制性比较强。

 

ios下UIImage相关开发经验总结,布布扣,bubuko.com

ios下UIImage相关开发经验总结

原文:http://www.cnblogs.com/wtndcs/p/3813898.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!