本文基於Java版專案javaewah。

首先

首先要知道，EWAHCompressedBitmap是完全基於行程壓縮演算法壓縮的。

結構就是這樣，看起來很簡單。

在構造EWAHCompressedBitmap時，內部會初始化一個RunningLengthWord，來儲存EWAH壓縮演算法必需的兩個資料結構：

    /**
     * The array of words.
     */
    final Buffer buffer;

    /**
     * The position in array.
     */
    int position;

其中Buffer根據實現的不同可能是

• LongArray，內部為long[]，使用預設構造方法構造Bitmap時就會構造LongArray
• LongBufferWrapper， 內部為java.nio.LongBuffer，這樣可以直接使用NIO的特性。在使用java.nio.ByteBuffer構造Bitmap時會構造LongBufferWrapper

不管什麼實現，我們把Buffer直接理解為儲存了一堆long的陣列即可。

RunningLengthWord

RunningLengthWord儲存了EWAHCompressedBitmap的全部資料，是整個專案中的核心。

其原理為：

將整個（未經過任何壓縮的）bitmap每64位拆分為一個最小單元（long

1. 64位全都是相同的位元，要麼全都是1，要麼全都是0，這樣的資料可以被run-length壓縮。尤其是當這種情況發生在連續的多個long上的時候，壓縮效果更為明顯。
2. 64位範圍內既有0又有1，這樣的資料不進行壓縮，而是直接儲存字面量，這樣的資料在論文中叫做Dirty Word，生動形象。其實如果整個bitmap中大量出現Dirty Word的話，壓縮效果會大打折扣。

根據上面的原理，RunningLengthWord使用了這樣的實現：

如果所示，在初始化時，Buffer中下標為0的位置一定是一個run-length，其64位被拆分成了三部分：

• 最低位（Running Bit
  ）：表示當前的run-length壓縮的是0還是1。
• 中間32位（Running Length）： 表示當前的run-length壓縮了幾個64位（long）的連續相同bit。如果這個部分值為0，那麼最低位的取值沒有實際意義。
• 高31位（Number of Literal Words ）：表示當前run-length後面緊接著未壓縮的字面量（Dirty Words）的數量。

如果Buffer中下標為N的位置為run-length，且其高位31位表示的Number of Literal Words為2，則Buffer中下標為N+1和N+2的兩個位置一定是字面量。

另外有一個性能相關的措施，就是設定一個position，始終指向整個Buffer中最後一個run-length，避免始終從頭開始定址。

舉個栗子

先插入9

因為要插入9，導致[0, 63]範圍變成了Dirty Word，需要儲存為字面量，因此會發生下面這些步驟：

1. 將Buffer中第0個run-length的高位Number of Literal Words部分改為1，表示後面的一個long為字面量；
2. 在Buffer中下標為1的位置插入一個表示字面量的long，表示[0, 63]範圍的值。因為插入了9，所以第9位的位置需要設為1（最低位為第0位）。

再插入666

再插入666的話，如果不壓縮，那麼將會形成這樣的陣列：

[640, 703]：Dirty Word，包含值666
[576, 639]：全0
[512, 575]：全0
[448, 511]：全0
[384, 447]：全0
[320, 383]：全0
[256, 319]：全0
[192, 255]：全0
[128, 191]：全0
[ 64, 127]：全0
[  0,  63]：Dirty Word，包含值9

可以看到，除了[0, 63]和[640, 703]兩個Dirty Word，中間的9個long全都是0，是可以進行run-length壓縮的。步驟如下：

1. 在Buffer中下標為2的位置插入一個run-length，其中Running Bit為0（壓縮的是0），Running Length為9（壓縮了9×64位），Number of Literal Words為1（後面有一個Dirty Word）；
2. 將position指向2，保持始終指向最後一個run-length；
3. 在Buffer中下標為3的位置插入一個字面量，表示[640, 703]，其中第26位為1，表示插入了值666。
4. 目前Buffer已滿，將陣列大小由4擴充套件為8，以備後用。

run-length和字面量的轉換

對於一個字面量

字面量代表的64位範圍內既有0又有1，如果經過某些操作後，恰好所有0都變成了1，或者所有的1都變成了0，那麼這個字面量就會被轉換為run-length。

需要進行以下操作：

• 因為自己不再是字面量了，所以需要減少前一個run-length的Number of Literal Words的值。
• 檢查前後相鄰的long是不是run-length，如果是的話能不能與自己合併。如果合併的話，合併後當前位置將會變成空位，需要將後面的資料整體前移。
• 如果轉換後自己變成最後一個run-length，需要將position指向自己。

對於一個run-length

run-length代表了至少一個、多則成百上千個64位區間全都是相同的bit。如果某些操作導致其中出現一個異常值，將會切斷當前run-length，插入至少一個字面量。

需要進行以下操作：

• 如果異常值出現在run-length的前64位或末尾64位，則需要收縮run-length的大小，在前面或後面插入一個字面量。
• 如果異常值出現在run-length的中間，則會將當前run-length切成兩個較短的run-length，中間插入一個字面量。
• 如果當前run-length只包含64位，則直接將當前run-length替換為一個字面量。
• 上述操作完成後，更新發生變動的字面量前面的Number of Literal Words值。

總結

• 儲存結構簡單，只有一個大大的long[]，在bitmap較大時對GC不太友好。
• 除了有一個position指向最後一個run-length，其他再沒有能幫助隨機訪問的措施了，這就意味著，基本上所有的對bitmap的隨機訪問全都要從頭開始過一遍，時間是線性的。不過，人家是完全的行程壓縮，說隨機訪問有點欺負人，這種bitmap本身就不適合隨機訪問，大家也不要這樣用。
• 總覺得壓縮差那麼點意思。。在極端情況下，壓縮率甚至是負的。比如，你每隔64插入一個值試試。。

其實我不應該先研究RoaringBitmap再來研究EWAH的，現在看起來怎麼都不如RoaringBitmap了。。

後面我會專門寫一篇來比較RoaringBitmap和EWAHCompressedBitmap的效能指標，用資料來說話。