0910 – iPaste 搞定資料壓縮

atJason發表於2019-01-24

在 iPaste 資料結構中,有個很重要的環節:壓縮資料(即剪貼簿內容);鬼使神差的,竟然一直沒有做。在準備發 Beta 2 時,做吧。

簡單瞭解下後,發現Apple 內建了 libcompression library 壓縮庫。而且,也有一些使用 Swift 的封裝,比如 NSData-CompressionDataCompression;我使用了後者,不過應該差不多。

進一步,這個庫中包含了 4 種壓縮演算法:

  • LZFSE
  • LZ4
  • LZMA
  • ZLIB

如何選擇呢?蘋果也給出了官方建議:

Choice of Compression Algorithm:

  • Use LZ4 if speed is critical, and you are willing to sacrifice compression ratio to achieve it.
  • Use LZMA if compression ratio is critical, and you are willing to sacrifice speed to achieve it. Note that – LZMA is an order of magnitude slower for both compression and decompression than other choices.
  • Otherwise, if speed and compression are more or less equally important, use LZFSE unless you require interoperability with non-Apple devices. If you do require interoperability with non-Apple devices, use ZLIB.
  • LZFSE is faster than ZLIB, and generally achieves a better compression ratio. However, it is slower than LZ4 and does not compress as well as LZMA, so you will still want to use LZ4 if speed is critical or LZMA if compression ratio is critical.

簡單的說:

**- LZMA 壓縮效果最好

  • LZ4 壓縮速度最快
  • LZFSE 是蘋果自己開發的、綜合表現好
  • ZLIB 應該被 LZFSE 取代**

當然,不能道聽途說,我也拿自己的實踐資料測試了一把:

最後,我選擇了蘋果自己的 LZFSE 壓縮演算法。

除了壓縮本身,還有件很重要的事:相容已有的、未壓縮的資料。事實上也還算好做,關鍵是有一點:如果資料未壓縮,解壓是無法得到有效資料。這一點可以用於區分資料是否壓縮,而暫時不用新增 v1/v2 這樣的資料結構版本號。

再次得到教訓:優先做資料結構相關的事情。等資料結構做完善、做穩定了,UI、業務邏輯等內容,隨意換。


部落格原文:0910 – iPaste 搞定資料壓縮

相關文章