Android中的HashMap,ArrayMap和SparseArray

Android開發者都知道Lint在我們使用HashMap的時候會給出警告——使用SparseArray會優化內存。這可是一件好事情。那現在我們有幾個類要學習去使用。比如:ArrayMap和SimpleArrayMap,當然還有各種類型的SparseArray。這篇文章將講解這些類及它們的原理。
先從如何使用它們開始吧。

java.util.HashMap<String, String> hashMap = new java.util.HashMap<String, String>(16);
hashMap.put("key", "value");
hashMap.get("key");
hashMap.entrySet().iterator();

android.util.ArrayMap<String, String> arrayMap = new android.util.ArrayMap<String, String>(16);
arrayMap.put("key", "value");
arrayMap.get("key");
arrayMap.entrySet().iterator();

android.support.v4.util.ArrayMap<String, String> supportArrayMap =
        new android.support.v4.util.ArrayMap<String, String>(16);
supportArrayMap.put("key", "value");
supportArrayMap.get("key");
supportArrayMap.entrySet().iterator();

android.support.v4.util.SimpleArrayMap<String, String> simpleArrayMap =
        new android.support.v4.util.SimpleArrayMap<String, String>(16);
simpleArrayMap.put("key", "value");
simpleArrayMap.get("key");
//simpleArrayMap.entrySet().iterator();      <- will not compile

android.util.SparseArray<String> sparseArray = new android.util.SparseArray<String>(16);
sparseArray.put(10, "value");
sparseArray.get(10);

android.util.LongSparseArray<String> longSparseArray = new android.util.LongSparseArray<String>(16);
longSparseArray.put(10L, "value");
longSparseArray.get(10L);

android.util.SparseLongArray sparseLongArray = new android.util.SparseLongArray(16);
sparseLongArray.put(10, 100L);
sparseLongArray.get(10);

接下我們一個一個的討論。java中的集合基本都是基于數組。在我們了解這些替代類之前我們需要理解HashMap是怎么樣工作的。

java.util.HashMap

HashMap本質上是一個HashMapEntry構成的數組。每個Entry的實體都包括:

  • 一個非基本類型的key
  • 一個非基本類型的value
  • 一個key的Hashcode
  • 指向下一個Entry的指針
    如下代碼(因為是泛型所以不能是基本類型)
  final K key;
  V value;
  HashMapEntry<K,V> next;
  int hash;

需要注意的是key和value都不是基本類型的。這是Java工程師做出的設計決策。所以我們不得不容忍它。當插入一個基本類型的時候會產生自動裝箱的消耗。
當HashMap插入一個object時:

  • key的Hashcode會被計算出來并賦值到Entry類的變量中。
  • java.util.HashMap.indexFor()這個方法依賴于hashcode。這個方法你也可以看成是利用Entry[]的size的取模函數。
 static int indexFor(int h, int length) {
        // assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";
        return h & (length-1);
    }

并用這個方法來決定當前的Entry放在Entry[]的哪個index,這個index叫做"bucket(桶)"

  • 如果這個桶已經存在了元素,那么新的元素會被插入到上一個元素中指針指定的位置——這個結構和LinkedList基本一樣。
    它查詢的復雜度是O(1):
  • 已經計算好了插入的Key的hashcode。
  • java.util.HashMap.indexFor() 這個方法是基于hashcode的,所以我們獲取Entry的bucket(位置)就像查詢一個數組。

O(1)的時間復雜度是所有的開發都樂意看到的,但是內存消耗也是應該考慮的因素。特別是在移動設備上。
HashMap的缺點:

  • 自動裝箱意味著需要產生額外的對象,這對于內存的使用和垃圾回收產生影響。
  • HashMapEntity自己本身也會產生額外的對象,這同樣會影響內存的使用和垃圾回收產生。
  • 每次HashMap的存儲對象減少或都增加的時候,這個開銷會隨著Hashmap的size增加而增加。
  • 哈希是很好的實現方案,但是如果實現的不好將會讓我們的開銷回到O(N)
  • 很多人都會忽略關于哈希的另外一個缺點:我們需要存儲它的key和對應的hash值。這種冗余有助于解決沖突。 非散列解決方案也可以在這方面有所幫助。

android.util.ArrayMap

ArrayMap 用了兩個數組。在它內部用了Object[] mArray來存儲Object,還用了int[] mHashes 來存儲hashcode,當存儲一對鍵值對的時候。

  • Key/Value會被自動裝箱。
  • key會存儲在mArray[]的下一個可用的位置。
  • 而value會存儲在mArray[]中key的下一個位置。(key和value在mArray中交叉存儲)
  • key的哈希值會被計算出來并存儲在mHashed[]中。
    當查找一個key的時候:
  • 計算key的hashcode。
  • 在mHashes[]中對這個hashcode進行二分法查找。也就意味著時間復雜度增加到了O(logN)
  • 一旦我們得到了這個哈希值的位置index。我們就知道這個key是在mArray的2index的位置,而value則在2index+1的位置。
    這個ArrayMap還是沒能解決自動裝箱的問題。當put一對鍵值對進入的時候,它們只接受Object,但是我們相對于HashMap來說每一次put會少創建一個對象(HashMapEntry)。這是不是值得我們用O(1)的查找復雜度來換呢?對于大多數app應用來說是值得的。

android.support.v4.util.ArrayMap

android.util.ArrayMap只能在api不小于19(Kitkat)的平臺才能使用。而Support library則支持在舊平臺上提供相同的功能。

android.support.v4.util.SimpleArrayMap

在之前發布的代碼片段中你可以看到,這個類沒有entrySet()這個支持迭代的方法。如果你查看它的文檔,你會發現很java標準集合的方法它都沒有。那我們為什么要用它呢。讓它失去與其它java容器的相互操作的特性來減小apk的大小。這樣的話,
Proguard(代碼優化和混沌工具:可能是你代碼構建生成的一部分)可以幫你減少大多數沒有使用的Collections API代碼從而減小你的apk大小。它的內部工作和android.util.ArrayMap是一樣的。

android.util.SparseArray

和ArrayMap一樣,它里面也用了兩個數組。一個int[] mKeys和Object[] mValues。從名字都可以看得出來一個用來存儲key一個用來保存value的。
當保存一對鍵值對的時候:

  • key(不是它的hashcode)保存在mKeys[]的下一個可用的位置上。所以不會再對key自動裝箱了。
  • value保存在mValues[]的下一個位置上,value還是要自動裝箱的,如果它是基本類型。
    查找的時候:
  • 查找key還是用的二分法查找。也就是說它的時間復雜度還是O(logN)
  • 知道了key的index,也就可以用key的index來從mValues中檢索出value。
    相較于HashMap,我們舍棄了Entry和Object類型的key,放棄了HashCode并依賴于二分法查找。在添加和刪除操作的時候有更好的性能開銷。
    KitKat以前的版本用android.support.v4.util.SparseArrayCompat

android.util.LongSparseArray

SparseArray只接受int類型作為key,而LongSparseArray我們就可以用long作為key。實現原理和SparseArray一致。

android.util.SparseIntArray, android.util.SparseLongArray and android.util.SparseBooleanArray

對于key是int類型而value是int 或者long再或者是boolean,我們可以對應使用SparseIntArray,SparseLongArray ,SparseBooleanArray 。它們使用方式是和SparseArray一樣的。它的好處是mValues[]是基本類型的數組。也就意味著無論是key還是value都不用裝箱。并且相對于HashMap來說我們節約了3個對象的初始化(Entry,Key和Value),但是我們將查看復雜度從O(1)上升到了O(logN)

結語

使用SparseArray和ArrayMap肯定會減少對象創建的數目。當集合的的數目多達幾百個的時候,性能差異也不會很明顯(少于50%)。將ArrayMap和SparseArray遷移到新代碼中是很有好處的。并且由于方法簽名匹配,所以遷移也很容易。

注意:即使它們聽起來像數組(Array),ArrayMap和SparseArray不能保證保留它們的插入順序,在迭代的時候應該注意。
其中二分法查找方法是 android.util.ContainerHelpers中的方法。

class ContainerHelpers {

    // This is Arrays.binarySearch(), but doesn't do any argument validation.
    static int binarySearch(int[] array, int size, int value) {
        int lo = 0;
        int hi = size - 1;

        while (lo <= hi) {
            final int mid = (lo + hi) >>> 1;
            final int midVal = array[mid];

            if (midVal < value) {
                lo = mid + 1;
            } else if (midVal > value) {
                hi = mid - 1;
            } else {
                return mid;  // value found
            }
        }
        return ~lo;  // value not present
    }

    static int binarySearch(long[] array, int size, long value) {
        int lo = 0;
        int hi = size - 1;

        while (lo <= hi) {
            final int mid = (lo + hi) >>> 1;
            final long midVal = array[mid];

            if (midVal < value) {
                lo = mid + 1;
            } else if (midVal > value) {
                hi = mid - 1;
            } else {
                return mid;  // value found
            }
        }
        return ~lo;  // value not present
    }
}

原文鏈接

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,362評論 6 544
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,577評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,486評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,852評論 1 317
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,600評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,944評論 1 328
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,944評論 3 447
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,108評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,652評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,385評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,616評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,111評論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,798評論 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,205評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,537評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,334評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,570評論 2 379

推薦閱讀更多精彩內容