全面掌握移動端主流圖檔格式的特點、性能、調優等

1、引言

圖檔通常是移動端應用流量耗費最多的部分，并且占據着重要的視覺空間。以大家最常用的即時通訊IM應用為例，應用中存在大量的圖檔資料往來（比如圖檔消息、使用者相冊、使用者頭像等等）。合理的圖檔格式選用和優化不僅能減小圖檔傳遞過程中的資料量、提升視覺效果，還能顯著降低服務端的帶寬、計算資源等基礎設施成本，一舉多得。

本文我們一起全面分析學習目前主流和新興的幾種圖檔格式的特點、性能、調優等，以及相關開源庫的選擇，希望能為您的移動端應用（包括本社群主要讨論的即時通訊應用）中的圖檔優化帶來一些啟發。

學習交流：

- 即時通訊開發交流3群： 185926912

[推薦]

- 移動端IM開發入門文章：《

新手入門一篇就夠：從零開發移動端IM 》

（本文同步釋出于：

http://www.52im.net/thread-1802-1-1.html

）

2、關于作者

郭曜源：

畢業于哈爾濱工程大學，現為優酷iOS開發工程師，是iOS上的熱門開源工程

YYWebImage

、

YYText

等的作者，個人github位址：

https://github.com/ibireme/

。

3、相關文章

《

騰訊技術分享：社交網絡圖檔的帶寬壓縮技術演進之路 QQ音樂團隊分享：Android中的圖檔壓縮技術詳解（上篇） QQ音樂團隊分享：Android中的圖檔壓縮技術詳解（下篇） 騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖檔傳輸速度和成功率 騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇） 騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（下篇） 基于社交網絡的Yelp是如何實作海量使用者圖檔的無損壓縮的？ 騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖檔壓縮篇)

4、認識主流的圖檔格式

首先談一下大家耳熟能詳的幾種老牌的圖檔格式吧。

JPEG

 是目前最常見的圖檔格式，它誕生于 1992 年，是一個很古老的格式。它隻支援有損壓縮，其壓縮算法可以精确控制壓縮比，以圖像品質換得存儲空間。由于它太過常見，以至于許多移動裝置的 CPU 都支援針對它的寫死與硬解碼。

PNG

 誕生在 1995 年，比 JPEG 晚幾年。它本身的設計目的是替代 GIF 格式，是以它與 GIF 有更多相似的地方。PNG 隻支援無損壓縮，是以它的壓縮比是有上限的。相對于 JPEG 和 GIF 來說，它最大的優勢在于支援完整的透明通道。

GIF

 誕生于 1987 年，随着初代網際網路流行開來。它有很多缺點，比如通常情況下隻支援 256 種顔色、透明通道隻有 1 bit、檔案壓縮比不高。它唯一的優勢就是支援多幀動畫，憑借這個特性，它得以從 Windows 1.0 時代流行至今，而且仍然大受歡迎。

在上面這些圖檔格式誕生後，也有不少公司或團體嘗試對他們進行改進，或者創造其他更加優秀的圖檔格式，比如 JPEG 小組的 JPEG 2000、微軟的 JPEG-XR、Google 的 WebP、個人開發者釋出的 BPG、FLIF 等。它們相對于老牌的那幾個圖檔格式來說有了很大的進步，但出于各種各樣的原因，隻有少數幾個格式能夠流行開來。下面三種就是目前實力比較強的新興格式了：

APNG

 是 Mozilla 在 2008 年釋出的一種圖檔格式，旨在替換掉畫質低劣的 GIF 動畫。它實際上隻是相當于 PNG 格式的一個擴充，是以 Mozilla 一直想把它合并到 PNG 标準裡面去。然而 PNG 開發組并沒有接受 APNG 這個擴充，而是一直在推進它自己的 MNG 動圖格式。MNG 格式過于複雜以至于并沒有什麼系統或浏覽器支援，而 APNG 格式由于簡單容易實作，目前已經漸漸流行開來。Mozilla 自己的 Firefox 首先支援了 APNG，随後蘋果的 Safari 也開始有了支援， Chrome 目前也已經

嘗試開始支援

 ，可以說未來前景很好。

WebP

 是 Google 在 2010 年釋出的圖檔格式，希望以更高的壓縮比替代 JPEG。它用 VP8 視訊幀内編碼作為其算法基礎，取得了不錯的壓縮效果。它支援有損和無損壓縮、支援完整的透明通道、也支援多幀動畫，并且沒有版權問題，是一種非常理想的圖檔格式。借由 Google 在網絡世界的影響力，WebP 在幾年的時間内已經得到了廣泛的應用。看看你手機裡的 App：微網誌、微信、QQ、淘寶、網易新聞等等，每個 App 裡都有 WebP 的身影。Facebook 則更進一步，用 WebP 來顯示聊天界面的貼紙動畫。（騰訊技術團隊在《

》、《

》這兩篇文章中都有提到WebP格式的技術實踐）

BPG

 是著名程式員 Fabrice Bellard 在去年 (2014年) 釋出的一款超高壓縮比的圖檔格式。這個程式員有些人可能感覺面生，但說起他的作品 FFmpeg、QEMU 大家想必是都知道的。BPG 使用 HEVC (即 H.265) 幀内編碼作為其算法基礎，就這點而言，它毋庸置疑是當下最為先進的圖檔壓縮格式。相對于 JP2、JPEG-XR、WebP 來說，同等體積下 BPG 能提供更高的圖像品質。另外，得益于它本身基于視訊編碼算法的特性，它能以非常小的檔案體積儲存多幀動畫。 Fabrice Bellard 聰明的地方在于，他知道自己一個人無法得到各大浏覽器廠商的支援，是以他還特地開發了 Javascript 版的解碼器，任何浏覽器隻要加載了這個 76KB 大小的 JS 檔案，就可以直接顯示 BPG 格式的圖檔了。目前阻礙它流行的原因就是 HEVC 的版權問題和它較長的編碼解碼時間。盡管這個圖檔格式才剛剛釋出一年，但已經有不少廠子開始試用了，比如

阿裡

和

騰訊

5、移動端圖檔類型的支援情況

目前主流的移動端對圖檔格式的支援情況如何呢？

我們分别來看一下 Android 和 iOS 目前的圖檔編解碼架構吧：

Android 的圖檔編碼解碼是由 Skia 圖形庫負責的，Skia 通過挂接第三方開源庫實作了常見的圖檔格式的編解碼支援。目前來說，Android 原生支援的格式隻有 JPEG、PNG、GIF、BMP 和 WebP (Android 4.0 加入)，在上層能直接調用的編碼方式也隻有 JPEG、PNG、WebP 這三種。目前來說 Android 還不支援直接的動圖編解碼。

iOS 底層是用 ImageIO.framework 實作的圖檔編解碼。目前 iOS 原生支援的格式有：JPEG、JPEG2000、PNG、GIF、BMP、ICO、TIFF、PICT，自 iOS 8.0 起，ImageIO 又加入了 APNG、SVG、RAW 格式的支援。在上層，開發者可以直接調用 ImageIO 對上面這些圖檔格式進行編碼和解碼。對于動圖來說，開發者可以解碼動畫 GIF 和 APNG、可以編碼動畫 GIF。

兩個平台在導入第三方編解碼庫時，都多少對他們進行了一些修改，比如 Android 對 libjpeg 等進行的調整以更好的控制記憶體，iOS 對 libpng 進行了修改以支援 APNG，并增加了多線程編解碼的特性。除此之外，iOS 專門針對 JPEG 的編解碼開發了 AppleJPEG.framework，實作了性能更高的寫死和硬解碼，隻有當寫死解碼失敗時，libjpeg 才會被用到。

6、靜态圖檔的編碼與解碼

由于我目前主要是做 iOS 開發，是以下面的性能評測都是基于 iPhone 的，主要測試代碼可以在這裡看到。

測試素材很少，隻有兩個：

第一張是Dribbble 的 Logo，包含 Alpha 通道，用于測試簡單的、圖形類的圖像。第二張經典的 Lena 圖，用于測試照片類的、具有豐富細節的圖像。每個圖像都有 64×64、128×128、256×256、512×512 四種分辨率。測試素材過少可能導緻某些測試不夠準确，但作為參考大緻是沒問題的。

6.1 JPEG

目前比較知名的 JPEG 庫有以下三個：

1）

libjpeg

：開發時間最早，使用最廣泛的 JPEG 庫。由于 JPEG 标準過于複雜和模糊，并沒有其他人去實作，是以這個庫是 JPEG 的事實标準；

2）

libjpeg-turbo

：一個緻力于提升編解碼速度的 JPEG 庫。它基于 libjpeg 進行了改造，用 SIMD 指令集 (MMX、SSE2、NEON) 重寫了部分代碼，官網稱相對于 libjpeg 有 2 到 4 倍的性能提升；

3）

MozJPEG

： 一個緻力于提升壓縮比的 JPEG 庫。它是 Mozilla 在 2014 年釋出的基于 libjpeg-turbo 進行改造的庫，相對于 libjpeg 有 5% ~ 15%  的壓縮比提升，但相應的其編碼速度也慢了很多。

除了上面這三個庫，蘋果自己也開發了一個 AppleJPEG，但并沒有開源。其調用了晶片提供的 DSP 寫死和硬解碼的功能。雖然它不如上面這三個庫功能完善，但其性能非常高。在我的測試中，其編解碼速度通常是 libjpeg-turbo 的 1~2 倍。可惜的是，目前開發者并不能直接通路這個庫。

下面是 ImageIO (AppleJPEG/libpng) 在 iPhone 6 上的編解碼性能：

可以看到，JPEG 編碼中 quality 越小，圖檔體積就越小，品質越也差，編碼時間也越短。解碼時間并沒有很大的差距，可能是其大部分時間消耗在了函數調用、硬體調用上。蘋果在自己的相冊 Demo 中提供的 quality 的預設值是 0.9，在這個值附近，圖像品質和體積、編碼解碼時間之間都能取得不錯的平衡。

6.2 PNG

相對于 JPEG 來說，PNG 标準更為清晰和簡單，是以有很多公司或個人都有自己的 PNG 編碼解碼實作。但目前使用最廣的還是 PNG 官方釋出的 

libpng

 庫。iOS 和 Android 底層都是調用這個庫實作的 PNG 編解碼。

下面是 PNG 在 iPhone 6 上的編解碼性能：

可以看到，在編解碼圖形類型（顔色少、細節少）的圖檔時，PNG 和 JPEG 差距并不大；但是對于照片類型（顔色和細節豐富）的圖檔來說，PNG 在檔案體積、編解碼速度上都差 JPEG 不少了。

和 JPEG 不同，PNG 是無損壓縮，其并不能提供壓縮比的選項，其壓縮比是有上限的。目前網上有很多針對 PNG 進行優化的工具和服務，旨在提升 PNG 的壓縮比。

下面是常見的幾個 PNG 壓縮工具的性能對比： pngcrush

 是 Xcode 自帶的 PNG 壓縮工具，相對于設計師用 Photoshop 生成的圖檔來說，它能取得不錯的壓縮效果。

ImageOptim

 則更進一步，對每張圖用多種縮算法進行比對，選擇壓縮比更高的結果，進一步縮小了檔案體積。TinyPNG.com 相對于其他工具來說，壓縮比高得不像話。它啟用了類似 GIF 那樣的顔色索引表對 PNG 進行壓縮，是以會導緻顔色豐富的圖檔丢失掉一部分細節。如果使用 

TinyPNG

 的話，最好在壓縮完成後讓設計師看一下顔色效果是否可以接受。

6.3 WebP

WebP 标準是 Google 定制的，迄今為止也隻有 Google 釋出的 

libwebp

 實作了該的編解碼 。 是以這個庫也是該格式的事實标準。

WebP 編碼主要有幾個參數：

lossless: YES:有損編碼 NO:無損編碼。WebP 主要優勢在于有損編碼，其無損編碼的性能和壓縮比表現一般；

quality: [0~100] 圖像品質，0表示最差品質，檔案體積最小，細節損失嚴重，100表示最高圖像品質，檔案體積較大。該參數隻針對有損壓縮有明顯效果。Google 官方的建議是 75，騰訊在對 WebP 評測時給出的建議也是 75。在這個值附近，WebP 能在壓縮比、圖像品質上取得較好的平衡；

method: [0~6] 壓縮比，0表示快速壓縮，耗時短，壓縮品質一般，6表示極限壓縮，耗時長，壓縮品質好。該參數也隻針對有損壓縮有明顯效果。調節該參數最高能帶來 20% ～ 40% 的更高壓縮比，但相應的編碼時間會增加 5～20 倍。Google 推薦的值是 4。

對于編碼無損圖檔來說，quality=0, method=0~3 是相對來說比較合适的參數，能夠節省編碼時間，同時也有不錯的壓縮比。無損編碼圖檔，quality=75, method=2~4 是比較合适的參數，能在編碼時間、圖檔品質、檔案體積之間有着不錯的平衡。

WebP 解碼有三個參數：

use_threads: 是否啟用 pthread 多線程解碼。該參數隻對寬度大于 512 的有損圖檔起作用。開啟後内部會用多線程解碼，CPU 占用會更高，解碼時間平均能縮短 10%～20%；

bypass_filtering: 是否禁用濾波。該參數隻對有損圖檔起作用，開啟後大約能縮短 5%～10% 的解碼時間，但會造成一些顔色過渡平滑的區域産生色帶（banding）；

no_fancy_upsampling: 是否禁用上采樣。該參數隻對有損圖檔起作用。在我的測試中，開啟該參數後，解碼時間反而會增加 5～25%，同時會造成一些圖像細節的丢失，線條邊緣會增加雜色，顯得不自然。

通常情況下，這三個參數都設為 NO 即可，如果要追求更高的解碼速度，則可以嘗試開啟 use_threads 和 bypass_filtering 這兩個參數。而 no_fancy_upsampling 在任何情況下都沒必要開啟。

由于 WebP 測試資料較多，這裡隻貼一下 512x512 大小的一部分測試結果，感興趣的可以看看Excel附件（

附件下載下傳

）：

對于簡單的圖形類型的圖像（比如 App 内的各種 UI 素材），WebP 無損壓縮的檔案體積和解碼速度某些情況下已經比 PNG 還要理想了，如果你想要對 App 安裝包體積進行優化，可以嘗試一下 WebP。

對于複雜的圖像（比如照片）來說，WebP 無損編碼表現并不好，但有損編碼表現卻非常棒。相近品質的圖檔解碼速度 WebP 相距 JPEG 也已經相差不大了，而檔案壓縮比卻能提升不少。

6.4 BPG

BPG 是目前已知最優秀的有損壓縮格式了，它能在相同品質下比 JPEG 減少 50% 的體積。下面是經典的 Lena 圖的對比，你也可以

在這裡

看到大量其他圖檔的 BPG、JPEG、JPEG2000、JPEG-XR、WebP 壓縮效果的線上對比，效果非常明顯。

BPG 目前隻有作者釋出的 

libbpg

 可用。但作者基于 libbpg 編譯出了一個 Javascript 解碼器，很大的擴充了可用範圍。bpg 可以以無損和有損壓縮兩種方式進行編碼，有損壓縮時可以用 quality 參數控制壓縮比，可選範圍為 0～51，數值越大壓縮比越高。通常來說，25 附近是一個不錯的選擇，BPG 官方工具預設值是 28。

libbpg 目前并沒有針對 ARM NEON 做優化，是以其在移動端的性能表現一般。下面是 iPhone 6 上的性能測試：

由于 bpg 編碼時間太長，我并沒有将資料放到表格裡。可以看到相同品質下，BPG 的解碼速度還是差 JPEG 太多，大約慢了 3～5 倍。目前來說，BPG 适用于那些對流量非常敏感，但對解碼時間不敏感的地方。從網上的新聞來看，手機淘寶和手機QQ都已經有所嘗試，但不清楚他們是否對 BPG 解碼進行了優化。

7、動态圖檔的編碼與解碼

動圖在網絡上非常受歡迎，它近似視訊，但通常實作簡單、檔案體積小，應用範圍非常廣泛。動圖的始祖是 GIF，它自 Windows 1.0 時代就在網際網路上流行開來，直到今天仍然難以被其他格式取代。盡管它非常古老，但其所用的原理和今天幾種新興格式幾乎一樣。

下面是一張 GIF 格式的 QQ 大表情：

這張表情由 6 幅靜态圖構成，每幅圖檔有一定的存活時間，連貫播放就形成了動畫：

這幾張圖中，大部分内容是相近的，為了壓縮檔案體積，通常動圖格式都支援一些特殊的方式對相似圖檔進行裁剪，隻保留前後幀不同的部分（如下圖所示）：

在解碼動圖時，解碼器通常采用所謂“畫布模式”進行渲染。想象一下：播放的區域是一張畫布，第一幀播放前先把畫布清空，然後完整的繪制上第一幀圖；播放第二幀時，不再清空畫布，而是隻把和第一幀不同的區域覆寫到畫布上，就像油畫的創作那樣。

像這樣的第一幀就被稱為關鍵幀（即 I 幀，幀内編碼幀），而後續的那些通過補償計算得到的幀被稱為預測編碼幀（P幀）。一個壓縮的比較好的動圖内，通常隻有少量的關鍵幀，而其餘都是預測編碼幀；一個較差的壓縮工具制作的動圖内，則基本都是關鍵幀。不同的動圖壓縮工具通常能得到不同的結果。

除此之外，動圖格式通常有更為詳細的參數控制每一幀的繪制過程，下面是 GIF/APNG/WebP 通用的幾個參數。

Disposal Method (清除方式) ：

Do Not Dispose：把目前幀增量繪制到畫布上，不清空畫布；

Restore to Background：繪制目前幀之前，先把畫布清空為預設背景色；

Restore to Previous：繪制下一幀前，把先把畫布恢複為目前幀的前一幀。

Blend Mode (混合模式) ：

Blend None: 繪制時，全部通道（包含Alpha通道）都會覆寫到畫布，相當于繪制前先清空畫布的指定區域；

Blend over：繪制時，Alpha 通道會被合成到畫布，即通常情況下兩張圖檔重疊的效果。

上面這些技術，就是常見動圖格式的基礎了，下面分别介紹一下不同動圖格式的特點。

7.1 GIF

GIF 缺陷非常明顯：

它通常隻支援 256 色索引顔色，這導緻它隻能通過抖動、內插補點等方式模拟較多豐富的顔色；

它的 Alpha 通道隻有 1 bit，這意味着一個像素隻能是完全透明或者完全不透明。

上面這是騰訊部落格裡的一張示範圖，可以看到 GIF 由于 Alpha 通道的問題，産生了嚴重的“毛邊”現象。

目前通常的解決方案是在圖檔的邊緣加一圈白邊，以減輕這種視覺效果：

可以仔細觀察一下 QQ、微信等 App 裡面的動畫表情，幾乎每個表情都被一圈白邊所環繞，不得不說是一種很無奈的解決方案。

GIF 的制作工具有很多，但效果好、壓縮比高的工具非常少。對于已經制作好的 GIF 來說，用 

imagemagick

 處理一下可以把檔案體積壓縮不少。如果需要将視訊轉為 GIF，

Cinemagraph Pro

 是個不錯的傻瓜化工具。文章《

使用 FFmpeg 處理高品質 GIF 圖檔

》介紹了如何用 ffmpeg 壓縮 GIF，雖然參數調節有點麻煩，但效果非常理想。

下面是沒有經過優化的 GIF 和經過 ffmpeg 優化編碼的 GIF，可以看到差距非常大：

7.2 APNG

APNG 目前并沒有被 PNG 官方所接受，是以 libpng 并不能直接解碼 APNG。但由于 APNG 隻是基于 PNG 的一個簡單擴充，是以在已經支援 PNG 的平台上，可以很輕松的用少量代碼實作 APNG 的編解碼。Chromium 為了支援 APNG 播放，隻增加了

不到 600 行代碼

 ，我自己也用

大概 500 行 C 代碼

實作了一個簡單的 APNG 編解碼工具。另外，在支援 canvas 的浏覽器上，可以用 

apng-canvas

 直接顯示 APNG 動畫。APNG 壓縮最好的工具目前是 

apngasm

，大部分圖形化工具比如

騰訊的 iSparta

 都是基于這個工具開發的。

就目前而言， APNG 是 GIF 最好的替代了：實作簡單，可用範圍廣，壓縮比不錯，顯示效果好。

7.3 WebP

WebP 在 2010 年 釋出時并沒有支援動圖。2012 年 libwebp v0.2 的時候，Google 才開始嘗試支援動畫，但其實作有很多問題，性能也非常差，以至于 Chrome 團隊一直都沒有接受。直到 2013 年，libwebp v0.4 時，動畫格式才穩定下來才被 Chrome 所接受。

WebP 動圖實際上是把多個單幀 WebP 資料簡單打包到一個檔案内，而并不是由單幀 WebP 擴充而來，以至于動圖格式并不能向上相容靜态圖。如果要支援動圖，首先在編譯 libwebp 時需要加上 demux 子產品，解碼 WebP 時需要先用 WebPDemuxer 嘗試拆包，之後再把拆出來的單幀用 WebPDecode 解碼。為了友善編譯，我寫了個

腳本

用于打包 iOS 的靜态庫，加入了 mux 和 demux 子產品。

Google 提供了兩個簡單的指令行工具用于制作動圖：gif2webp 能把 GIF 轉換為 WebP， webpmux 能把多個 WebP 圖檔打包為動态圖，并且有着很多參數可以調節。這兩個工具對相近幀的壓縮并不太理想，以至于有的情況下壓縮比還不如 APNG，但除此以外也沒有其他什麼更好的工具可以用了 (update: 在最近的 libwebp v0.6.0 中， Google 新提供了一個 img2webp 指令專門用于制作動圖的，效果不錯)。

7.4 BPG

BPG 本身是基于 HEVC (H.265) 視訊編碼的，其最開始設計時就考慮到了動圖的實作。由于它充分利用了 HEVC 的高壓縮比和視訊編碼的特性，其動圖壓縮比遠超其他格式。

這裡

有幾張 BPG 動圖示例，可以看到相同品質下 BPG 動圖隻有 APNG/WebP/GIF 幾十分之一的大小。

我在

寫了個簡單的利用 libbpg 解碼動圖的方法，如有需要可以參考下。

8、動圖性能對比

我把下面這張 GIF 分别轉為 WebP、APNG、BPG 動圖，并在 iPhone 6 上對其所有幀進行解碼。

評測結果如下：

APNG 在檔案體積上比 GIF 略有優勢，解碼時間相差不多。WebP 在體積和解碼時間上都具有較大的優勢。BPG 在體積上優勢最大，但解碼時間也最長。這麼看來，APNG 和 WebP 都是不錯的選擇，而 BPG 還有待性能優化。

最後做一個小廣告：

如果你是 iOS 平台的開發者，可以試試我開發的 

，它支援 APNG、WebP、GIF 動圖的異步加載與播放、編碼與解碼，支援漸進式圖像加載，可以替代 SDWebImage、PINRemoteImage、FLAnimatedImage 等開源庫。

附錄：更多移動端即時通訊應用開發文章

移動端IM開發者必讀(一)：通俗易懂，了解移動網絡的“弱”和“慢” 移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結 從用戶端的角度來談談移動端IM的消息可靠性和送達機制 現代移動端網絡短連接配接的優化手段總結：請求速度、弱網适應、安全保障 小白必讀：閑話HTTP短連接配接中的Session和Token IM開發基礎知識補課：正确了解前置HTTP SSO單點登陸接口的原理 移動端IM中大規模群消息的推送如何保證效率、實時性？ 移動端IM開發需要面對的技術問題 開發IM是自己設計協定用位元組流好還是字元流好？ 請問有人知道語音留言聊天的主流實作方式嗎？ IM消息送達保證機制實作(一)：保證線上實時消息的可靠投遞 IM消息送達保證機制實作(二)：保證離線消息的可靠投遞 如何保證IM實時消息的“時序性”與“一緻性”？ 一個低成本確定IM消息時序的方法探讨 IM單聊和群聊中的線上狀态同步應該用“推”還是“拉”？ IM群聊消息如此複雜，如何保證不丢不重？ 談談移動端 IM 開發中登入請求的優化 移動端IM登入時拉取資料如何作到省流量？ 淺談移動端IM的多點登陸和消息漫遊原理 完全自已開發的IM該如何設計“失敗重試”機制？ 通俗易懂：基于叢集的移動端IM接入層負載均衡方案分享 微信對網絡影響的技術試驗及分析（論文全文） 即時通訊系統的原理、技術和應用（技術論文） 開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀 如約而至：微信自用的移動端IM網絡層跨平台元件庫Mars已正式開源 騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視訊技術篇) 為什麼說即時通訊社交APP創業就是一個坑？ 字元編碼那點事：快速了解ASCII、Unicode、GBK和UTF-8 深入學習移動端主流圖檔格式的特點、性能、調優等 >>  更多同類文章 ……