ios下UIImage相关开发经验总结

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处理要占用更少的内存；这点我尚未明显的发现出来。2014.07.01，今天测试了下，在itouch 4 ios 6上，使用这种方式，内存飙升到50m，相反使用通常加载NSData方式，反而保持在20m。关于这块文件加载方面，我的认为不管是NSData仍是前面一种方式，都没法处理超大图片，能够处理的方式应该有两种: a. 使用mmap，会使用虚拟内存 b. 逐步读取，划分块逐步解压缩，逐步缩略。这两种我都没有试，前面一种应该没有问题，后面一种要看相关接口，理论上是能够的。

    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反而更少。2014.07.02，我目前发现老外的文章也不靠谱啊，目前这点存疑。

   导出图片主要有几个问题，UIImageJPEGRepresentation方法不会导出图片的metadata，UIImageJPEGRepresentation方式会丢失EXIF等信息，一种方式是经过image IO再加回来，一种是本身读取图片二进制，本身手动写bytes，这种通常是利用开源软件，比较麻烦且容易丢掉信息，不推荐使用。image IO这种方式彷佛是最好，可是我发现一个比较蛋疼的问题，等传送到应用服务端，服务端再次作处理后，竟然比UIImageJPEGRepresentation产生的还大；比较奇怪，须要分析下服务端的实现。

2. UIImage的展现

    UIImage展现在列表中的性能方面，占比较重的份量。我的认为主要影响方面CPU消耗、内存消耗，GPU方面主要保证不要出现blending及离屏绘制，离屏渲染能够被Core Animation 自动触发或是应用程序手动触发；以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等方式。

   Core Animation为何会触发离屏渲染，由于动画是单独线程作的；mask和shadow也有一样的问题，就是mask和shadow并不是cpu绘制，从而会触发离屏绘制

3. 图片格式

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

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

Like BPG, it's actually a keyframe format from a video stream - in this case Google's ownWebM/VP8 format.

4. 图片上传

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

5. 图片处理

    我的倾向图片处理方面客户端作展现图的处理效果，服务器端作真正图片的处理；节省客户端的资源；不过滤镜等技术，我基本上没有经验，iOS 7却是带了很多滤镜的功能，不过这块定制性比较强。