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卻是帶了很多濾鏡的功能，不過這塊定製性比較強。