之前在做一個記憶體優化的時候，使用到了MemoryFile，由此發現了MemoryFile的一些特性以及一個非常trickly的使用方法，因此在這裡記錄一下
What is it
MemoryFile是android在最開始就引入的一套框架，其內部實際上是封裝了android特有的記憶體共享機制Ashmem匿名共享記憶體，簡單來說，Ashmem在Android核心中是被註冊成一個特殊的字元裝置，Ashmem驅動通過在核心的一個自定義slab緩衝區中初始化一段記憶體區域，然後通過mmap把申請的記憶體對映到使用者的程式空間中（通過tmpfs），這樣子就可以在使用者程式中使用這裡申請的記憶體了，另外，Ashmem的一個特性就是可以在系統記憶體不足的時候，回收掉被標記為”unpin”的記憶體，這個後面會講到，另外，MemoryFile也可以通過Binder跨程式呼叫來讓兩個程式共享一段記憶體區域。由於整個申請記憶體的過程並不再Java層上，可以很明顯的看出使用MemoryFile申請的記憶體實際上是並不會佔用Java堆記憶體的。
MemoryFile暴露出來的使用者介面可以說跟他的名字一樣，基本上跟我們平時的檔案的讀寫基本一致，也可以使用InputStream和OutputStream來對其進行讀寫等操作：
|
1 2 3 4 |
MemoryFile memoryFile = new MemoryFile(null, inputStream.available()); memoryFile.allowPurging(false); OutputStream outputStream = memoryFile.getOutputStream(); outputStream.write(1024); |
上面可以看到allowPurging這個呼叫，這個就是之前說的”pin”和”unpin”，在設定了allowPurging為false之後，這個MemoryFile對應的Ashmem就會被標記成”pin”，那麼即使在android系統記憶體不足的時候，也不會對這段記憶體進行回收。另外，由於Ashmem預設都是”unpin”的，因此申請的記憶體在某個時間點內都可能會被回收掉，這個時候是不可以再讀寫了
Tricks
MemoryFile是一個非常trickly的東西，由於並不佔用Java堆記憶體，我們可以將一些物件用MemoryFile來儲存起來避免GC，另外，這裡可能android上有個BUG：
在4.4及其以上的系統中，如果在應用中使用了MemoryFile，那麼在dumpsys meminfo的時候，可以看到多了一項Ashmem的值：
可以看出來雖然MemoryFile申請的記憶體不計入Java堆也不計入Native堆中，但是佔用了Ashmem的記憶體，這個實際上是算入了app當前佔用的記憶體當中
但是在4.4以下的機器中時，使用MemoryFile申請的記憶體居然是不算入app的記憶體中的：
而且這裡我也算過，也是不算入Native Heap中的，另外，這個時候去系統設定裡面看程式的記憶體佔用，也可以看出來其實並沒有計入Ashmem的記憶體的
這個應該是android的一個BUG，但是我搜了一下並沒有搜到對應的issue，搞不好這裡也可能是一個feature
而在大名鼎鼎的Fresco當中，他們也有用到這個bug來避免在decode bitmap的時候，將檔案的位元組讀到Java堆中，使用了MemoryFile，並利用了這個BUG然這部分記憶體不算入app中，這裡分別對應了Fresco中的GingerbreadPurgeableDecoder和KitKatPurgeableDecoder，Fresco在decode圖片的時候會在4.4和4.4以下的系統中分別使用這兩個不同的decoder
從這個地方可以看出來，使用MemoryFile，在4.4以下的系統當中，可以幫我們的app額外”偷”一些記憶體，並且可以不計入app的記憶體當中
Summary
這裡主要是簡單介紹了MemoryFile的基本原理和用法，並且闡述了一個MemoryFile中一個可以幫助開發者”偷”記憶體的地方，這個是一個非常trickly的方法，雖然4.4以下使用這塊的記憶體並不計入程式當中，但是並不推薦大量使用，因為當設定了allowPurging為false的時候，這個對應的Ashmem記憶體區域是被”pin”了，那麼在android系統記憶體不足的時候，是不能夠把這段記憶體區域回收的，如果長時間沒有釋放的話，這樣子相當於無端端佔用了大量手機記憶體而又無法回收，那對系統的穩定性肯定會造成影響