這里提及高效稍許有些夸張，僅為應(yīng)景，因為本身就沒有太多高科技，權(quán)且作為一種有效的實現(xiàn)。

首先是圖片解碼器的選擇。一般來講有幾種選擇：1、組裝各種開源庫，如libpng, libjpg, giflib等，支持什么格式就得添加對應(yīng)的解碼器；2、開源解碼包，如freeimage，沒用過但聽說也很不錯；3、GDI+，支持圖片格式廣泛，接口簡單，性能一般。當然還有其它方式，大抵差不多。我選擇的是GDI+，圖簡便好用，且目前微軟支持的OS上都是自帶的，無需發(fā)布？!。對QQ的程序集DLL進行分析，發(fā)現(xiàn)其中貫穿了各種解碼技術(shù)，有直接采用開源庫的，也有依賴GDI+的，不知道是歷史遺留問題，還是各個部門之間技術(shù)偏好，抑或是另有玄機。扯到技術(shù)偏好，讓我頭疼的就是程序員在項目中隨意的引入庫，解決同一個問題，往往看到不同的人用不同的技術(shù)，甚至同一個人在不同的項目中造不同的輪子，有時候沒法說服別人，只能罷了。

GDI+的初始化需要注意一件事情：不要在DLL入口處加載或卸載GDI+，否則會發(fā)生鎖死現(xiàn)象，具體可查閱msdn。

考慮到高性能的界面中可能會采用多線程UI，因此我建立了ThreadState的TLS對象，所有的數(shù)據(jù)都存儲在這個對象中，同步線程消息是通過慣用手法之隱藏窗口來保證。時至今日，或者早1、2年，我才深刻理解mfc庫設(shè)計時的那些state管理結(jié)構(gòu)體的用處。GDI+的初始化在ThreadState構(gòu)造函數(shù)中調(diào)用，正好避免了加載沖突這個問題。TLS對象的銷毀技巧來自谷歌的chromium源碼中的base庫里的tls實現(xiàn)，原始出處來自CodeProject：http://www.codeproject.com/threads/tls.asp。嗯，其實牛逼的程序員也是縱覽乾坤，吸取精華。提到CodeProject，順帶提一下我的學習歷程，早期瘋狂的泡這個網(wǎng)站，幾乎VC方面的東西都把玩過，形成了自己的點狀知識積累，類似的有CodeGuru、vckbase（現(xiàn)在已經(jīng)成為廣告站了）；之后是 sourceforge、codegoogle、codeplex 找一些小的項目研究，形成自己的線狀知識結(jié)構(gòu)；再后來就是大型的源碼閱讀，偶爾會去谷歌討論組、微軟新聞組看一些疑難雜癥問題，構(gòu)成了自己的面狀知識體系。每個人都有自己的學習方法論，這里僅僅是分享我自己的。很多東西都已經(jīng)看上去有些過時，現(xiàn)在的年輕程序員可能接觸的是stackoverflow、github等。

GDI+中的Image是抽象接口，為了方便使用，增加了一層簡易封裝IMImage，主要接口如下：

通過uri加載圖片，GDI+對本地圖片的加載非常簡單，Image::FromFile可以直接返回；對于網(wǎng)絡(luò)圖片，需要先通過WinINet下載到本地，然后再加載。

由于使用了tls技術(shù)，這里的引用計數(shù)實現(xiàn)很簡單，就是++、-- 操作。曾經(jīng)有人告訴我引用技術(shù)是為了解決多線程中對象的生命周期問題，我欲與否認。引用計數(shù)只是為了解決對象的生命周期問題，而這種情況往往在多線程中出現(xiàn)，因此多線程中或多或少會用到引用計數(shù)。

IMImage類可以簡單的返回一些GDI+的Image對象提供的圖片信息，而GetImage需要多做一些事情。對于包含多幀圖片的文件，在繪制的時候需要通過GDI+的Image::SelectActiveFrame方法選擇當前幀，該操作非常耗時，因此在加載圖片的時候，發(fā)現(xiàn)如果是多幀的，我們需要額外的decode_image_來解碼存放每一幀圖像，這樣除第一次渲染比較耗時外，后面的獲取都是非常快的。

再增加一個IMImageService，管理整個系統(tǒng)中用到的IMImage對象，接口很簡單：

需要圖像就找它要，用完之后記得釋放即可。

這樣就完成了圖片的管理，目前來說足夠用，也非常簡單，不是么？