imageIO完成漸進加載圖片

一、常見漸進加載圖片模式
 
　　目前我們看到的漸進加載主要有以下三種實現(xiàn)方式:
 
　　1)  依次從web上加載不同尺寸的圖片，從小到大。最開始先拉取一個小縮略圖做拉伸顯示，然后拉取中等規(guī)格的圖，拉取完畢直接覆蓋顯示，最后拉取原圖，拉取完成后顯示原圖。
 
　　2）直接從web上拉取最大的圖片，每接受一點兒數(shù)據(jù)就顯示一點兒圖片，這樣就會實現(xiàn)從上到下一點點刷新出來的效果。
 
　　3）結(jié)合第1種和第2種，先拉取一個縮略圖做拉伸顯示，然后采用第二種方法直接拉取原圖，這樣即可以實現(xiàn)漸進加載，也可以節(jié)省幾次中間的網(wǎng)絡(luò)請求。
 
 
 
二、通過imageIO實現(xiàn)圖片的漸進加載
 
　　imageIO的guide中原話是這么說的: "If you have a very large image, or are loading image data over the web, you may want to create an incremental image source so that you can draw the image data as you accumulate it. "
 
　　翻譯過來就是: "如果你想加載一副特別大的圖片，或者從網(wǎng)絡(luò)上加載一副圖片，你可以通過創(chuàng)建一個imageSource實現(xiàn)漸進加載的效果。"翻譯的不是很地道，大概就是這么個意思，以前在做PowerCam的時候，當時為了在iOS上處理超大圖的時候也試過這種方法，當時測試使用的是一副中國地圖，分辨率為10000*8000的，結(jié)果是當整幅圖片加載到內(nèi)存時，內(nèi)存吃不消，于是就放棄了?，F(xiàn)在想想對于這種超大圖片的處理，我們可以采用分片的方式進行，每次只需要處理一小塊圖片即可，這個問題就留給大家思考吧。
 
　　今天我們要討論的是CGImageSource實現(xiàn)從web端漸進加載圖片，要達到這個目的我們需要創(chuàng)建一個URLConnnection，然后實現(xiàn)代理，每次接收到數(shù)據(jù)時更新圖片即可。下面主要的實現(xiàn)源碼:
 

　　從上面代碼中我們可以看到，一開始我們根據(jù)傳入的URL創(chuàng)建一個URLConnection，同時創(chuàng)建一個空的CGImageSource，然后在每次收到數(shù)據(jù)的時候調(diào)用CGImageSourceUpdateData更新imageSource的數(shù)據(jù)，接著調(diào)用CGImageSourceCreateImageAtIndex獲取最新的圖片即可。
 
　　怎么樣，看到上面的實現(xiàn)是不是感覺實現(xiàn)從web上漸進加載圖片很簡單，雖然imageIO幫我們做了很多事情，但是我們也應(yīng)該了解它的原理。我們知道文件都是有格式的，一般文件的頭部會記錄一些關(guān)于文件格式的數(shù)據(jù)，后面就是實際的文件數(shù)據(jù)。
 
　　拿最簡單的BMP圖片文件舉例:
 
　　1)  最開始的BITMAPFILEHEADER，這部分主要記錄文件的大小，以及實際的圖像數(shù)據(jù)離文件頭的距離。
 
　　2)  接著是BITMAPINFOHEADER，這部分主要記錄圖片的寬，高，位深等信息
 
　　3）可選的調(diào)色板信息
 
　　4）最后一部分就是實際的圖片數(shù)據(jù)。
 
　　前三部分的信息很小，一般加起來不會超過100個字節(jié)，獲取到這寫信息以后，我們就可以很輕松的根據(jù)后面的數(shù)據(jù)構(gòu)建出圖片，當數(shù)據(jù)獲取的越來越完整的時候，我們構(gòu)造出的圖片就會越完整，直至全部加載完成。
 
　　BMP格式是簡單的圖片格式，其他的JPG，PNG雖然結(jié)果更加復(fù)雜，但是總體構(gòu)成都差不多。imageIO正是幫助我們完成了眾多圖片格式的編解碼，然后一步步構(gòu)造出最終的圖片。

使用imageIO獲取圖片的exif信息
一幅圖片除了包含我們能看見的像素信息，背后還包含了拍攝時間，光圈大小，曝光等信息。UIImage類將這些細節(jié)信息都隱藏了起來，只提供我們關(guān)心的圖片尺寸，圖片方向等。我們可以通過imageIO框架獲取到圖片背后的所有信息，下面就讓我們一起看看。
 
　　imageIO框架是iOS中偏底層一點兒的框架，它內(nèi)部提供的接口都是C風格的，關(guān)鍵數(shù)據(jù)也都是使用CoreFoundation進行存儲。慶幸的是CoreFoundation中有很多數(shù)據(jù)類型都可以上層的數(shù)據(jù)Foundation框架中的數(shù)據(jù)類型進行無縫橋接。這也就大大方便了我們對圖片信息的操作。
 
　　CGImageSourceRef是整個imageIO的入口，通過它我們可以完成從文件的加載圖片。加載完成以后我們就得到一個CGImageSourceRef，通過CGImageSourceRef我們就可以獲取圖片文件的大小，UTI(uniform type identifier)，內(nèi)部包含幾張圖片，訪問每一張圖片以及獲取每張圖片對應(yīng)的exif信息等。
 
　　你可能會有一個疑問，為什么會有幾張圖片呢？
 
　　這塊兒我解釋一下，imageSourceRef和文件是一一對應(yīng)的，通常我們見到的圖片文件(例如jpg，png)內(nèi)部都只有一張圖片，這種情況我們通過CGImageSourceGetCount方法得到的就會是1。但是不能排除一個圖片文件中會有多種圖片的情況，例如gif文件，這個時候一個文件中就可能包含幾張甚至幾十張圖片。前面我寫的一片博客《IOS中如何解析并顯示Gif》就是通過imageSource實現(xiàn)加載和解析gif的功能。
 
　　下面是系統(tǒng)相機拍的照片的exif信息:

　　目前市面上的大部分數(shù)碼相機和手機都會內(nèi)置一個方向感應(yīng)器，拍出的照片中會寫如方向信息，但是通常都只會有前四種方向。這幾種Mirrored方向通常都是手機前置攝像頭自拍的時候才會設(shè)置。
 
　　exif為什么要搞這么一個方向呢？
 
　　幾乎所有的攝像頭在出場的時候成相芯片都是有方向的，拍出來的照片的像素都是默認方向的。如果每拍一張照片就對這些像素進行旋轉(zhuǎn)，如果數(shù)碼相機每秒連拍20張來算，旋轉(zhuǎn)操作將會非常耗時。更聰明的做法是拍照時只記錄一個方向，然后顯示的時候按方向顯示出來即可。因此exif定義了一個標準的方向參數(shù)，只要讀圖的軟件都來遵守規(guī)則，加載時候讀取圖片方向，然后做相應(yīng)的旋轉(zhuǎn)即可。這樣既可以達到快速成像的目的，又能達到正確的顯示，何樂而不為呢。
 
　　常見的圖片瀏覽和編輯軟件都遵守這個規(guī)則，但是有一個我們最常用的看圖軟件(windows自帶的看圖程序)不會去讀這個方向，因此我們將數(shù)碼相機和手機拍出來的圖片導(dǎo)入windows上時，會經(jīng)常遇到方向錯誤的問題。不知道windows帝國是怎么想的，或許和定義exif的組織有什么過節(jié)吧。
 
　　圖片信息中除了上面看提到的那些，還有拍攝的GPS信息，iOS自帶的相冊軟件中的地點tab就是按照GPS信息實現(xiàn)的。還有很多其他的信息，感興趣的可以自己寫個程序研究研究，這里就不展開了。

最新評論