imageIO完成渐进加载图片

一、常见渐进加载图片模式
　　目前我们看到的渐进加载主要有以下三种实现方式:
　　1)  依次从web上加载不同尺寸的图片，从小到大。最开始先拉取一个小缩略图做拉伸显示，然后拉取中等规格的图，拉取完毕直接覆盖显示，最后拉取原图，拉取完成后显示原图。
　　2）直接从web上拉取最大的图片，每接受一点儿数据就显示一点儿图片，这样就会实现从上到下一点点刷新出来的效果。
　　3）结合第1种和第2种，先拉取一个缩略图做拉伸显示，然后采用第二种方法直接拉取原图，这样即可以实现渐进加载，也可以节省几次中间的网络请求。
二、通过imageIO实现图片的渐进加载
"如果你想加载一副特别大的图片，或者从网络上加载一副图片，你可以通过创建一个imageSource实现渐进加载的效果。"翻译的不是很地道，大概就是这么个意思，以前在做PowerCam的时候，当时为了在iOS上处理超大图的时候也试过这种方法，当时测试使用的是一副中国地图，分辨率为的，结果是当整幅图片加载到内存时，内存吃不消，于是就放弃了。现在想想对于这种超大图片的处理，我们可以采用分片的方式进行，每次只需要处理一小块图片即可，这个问题就留给大家思考吧。
　　今天我们要讨论的是CGImageSource实现从web端渐进加载图片，要达到这个目的我们需要创建一个URLConnnection，然后实现代理，每次接收到数据时更新图片即可。下面主要的实现源码:

　　怎么样，看到上面的实现是不是感觉实现从web上渐进加载图片很简单，虽然imageIO帮我们做了很多事情，但是我们也应该了解它的原理。我们知道文件都是有格式的，一般文件的头部会记录一些关于文件格式的数据，后面就是实际的文件数据。
　　拿最简单的BMP图片文件举例:
　　1)  最开始的BITMAPFILEHEADER，这部分主要记录文件的大小，以及实际的图像数据离文件头的距离。
　　3）可选的调色板信息
　　4）最后一部分就是实际的图片数据。
　　前三部分的信息很小，一般加起来不会超过100个字节，获取到这写信息以后，我们就可以很轻松的根据后面的数据构建出图片，当数据获取的越来越完整的时候，我们构造出的图片就会越完整，直至全部加载完成。
　　BMP格式是简单的图片格式，其他的JPG，PNG虽然结果更加复杂，但是总体构成都差不多。imageIO正是帮助我们完成了众多图片格式的编解码，然后一步步构造出最终的图片。

使用imageIO获取图片的exif信息 一幅图片除了包含我们能看见的像素信息，背后还包含了拍摄时间，光圈大小，曝光等信息。UIImage类将这些细节信息都隐藏了起来，只提供我们关心的图片尺寸，图片方向等。我们可以通过imageIO框架获取到图片背后的所有信息，下面就让我们一起看看。

　　从中我们可以看出最开始的几项分别显示了当前图片的颜色模式，色深，x，y方向的DPI，实际像素以及图片的方向。我最开始看到这个方向时，心中一喜这不是UIImage中的imageOrientation，但是实验发现这个方向和UIImage中的imageOrientation并不相等，此处的方向是exif标准定义的方向，从1到8分别对应这UIImage中的8个方向，只是顺序不一样，它们对应关系如下:

　　目前市面上的大部分数码相机和手机都会内置一个方向感应器，拍出的照片中会写如方向信息，但是通常都只会有前四种方向。这几种Mirrored方向通常都是手机前置摄像头自拍的时候才会设置。
　　exif为什么要搞这么一个方向呢？
　　几乎所有的摄像头在出场的时候成相芯片都是有方向的，拍出来的照片的像素都是默认方向的。如果每拍一张照片就对这些像素进行旋转，如果数码相机每秒连拍20张来算，旋转操作将会非常耗时。更聪明的做法是拍照时只记录一个方向，然后显示的时候按方向显示出来即可。因此exif定义了一个标准的方向参数，只要读图的软件都来遵守规则，加载时候读取图片方向，然后做相应的旋转即可。这样既可以达到快速成像的目的，又能达到正确的显示，何乐而不为呢。
　　常见的图片浏览和编辑软件都遵守这个规则，但是有一个我们最常用的看图软件(windows自带的看图程序)不会去读这个方向，因此我们将数码相机和手机拍出来的图片导入windows上时，会经常遇到方向错误的问题。不知道windows帝国是怎么想的，或许和定义exif的组织有什么过节吧。
　　图片信息中除了上面看提到的那些，还有拍摄的GPS信息，iOS自带的相册软件中的地点tab就是按照GPS信息实现的。还有很多其他的信息，感兴趣的可以自己写个程序研究研究，这里就不展开了。

本文主要探讨一些常用多任务的最佳实践。包括Core Data的多线程访问，UI的并行绘制，异步网络请求以及一些在运行态内存吃紧的情况下处理大文件的方案等。??其实编写异步处理的程序有很多坑！所以，本文所涉及的样例都尽量采用简洁直观的处理方式。因为越是简单的逻辑结构，越能彰显代码的脉络清晰，越易于理解。打个比方，如果在程序中使用多层次的嵌套回调，基本上这个它会有很大的重构空间。

input stream通过主线程向代理发送消息，代理接受后再把数据处理任务添加到operation queue中：

数据处理过程中会不断的从buffer中获取已读入的数据。然后把这些新读入的数据按行分开并存储。

就这样，样例工程在运行时响应事件非常迅速，内存的开销也很低（测试数据显示，不管待读入的文件本身有多大，堆占用始终低于800KB）。所以，处理大文件，还是应该采用逐块处理的方式。

上面举了几个例子来展示如何异步执行一些常见任务。需要强调的还是：在所涉及的所有方案中，我们都尽量采用清晰明了的代码实现，因为对于多线程编程，稍不留神就会搞出一堆麻烦来。大多数情况下，为了规避麻烦，你可能会选择让主线程打理一切活计。但是一旦出现了性能问题，建议还是尽量采用相对简单的多线程处理方法来解决问题。我们样例中提到的各种处理方式都是比较安全且不错的选择。总之，在main queue中接收事件或数据，在其他线程或队列中做详细的处理并且将处理结果回传给main queue。

在iOS开发中，比较常用的切换视图的方式主要有以下几种：

使用举例（ViewController假设为需要跳转的控制器）：

使用举例（ViewController假设为需要跳转的控制器）：

使用举例（ViewController假设为需要跳转的控制器）：

4. 将另一个控制器的视图添加为当前控制器视图的子视图

简要介绍下各种方式的优点和不足：

优点：控制器切换是可逆的，且原始图不会销毁

缺点：依赖于UINavigationController，故需要有一个导航控制器，与某些界面不需要导航控制器有可能会冲突

push操作是可逆的，即控制器的切换时可逆的。

优点：控制器切换是可逆的，且原始图不会销毁

缺点：跳转没有push方式自由，dismiss方式只能按顺序返回，不能跳跃， 从前一个modal到后一个时候，前一个控制器不会消失，一直在内存中

优点：跳转直接迅速，而且可以销毁前一个控制器，因为将window的强引用改为当前控制器，故前一个控制器会消失（ARC环境）

4、将一个控制器的视图添加到当前视图上面

优点：通过一个控制器将另一控制器设置为属性，自由读取其他控制器中的视图从而能够实现复杂UI界面

缺点：复杂，多数场合不适用

视图切换的方式各有利弊，需要根据我们的需求选择使用的方式，以上就是本文的全部呢荣，水平有限，若有不正确之处，望各位批评指正，共同学习，共同提高！