建站
咨詢
售后
建站咨詢
新聞中心
之前在做一個內(nèi)存優(yōu)化的時候，使用到了MemoryFile，由此發(fā)現(xiàn)了MemoryFile的一些特性以及一個非常trickly的使用方法，因此在這里記錄一下。
What is it
MemoryFile是Android在最開始就引入的一套框架，其內(nèi)部實(shí)際上是封裝了android特有的內(nèi)存共享機(jī)制Ashmem匿名共享內(nèi)存，簡單來說，Ashmem在Android內(nèi)核中是被注冊成一個特殊的字符設(shè)備，Ashmem驅(qū)動通過在內(nèi)核的一個自定義slab緩沖區(qū)中初始化一段內(nèi)存區(qū)域，然后通過mmap把申請的內(nèi)存映射到用戶的進(jìn)程空間中(通過tmpfs)，這樣子就可以在用戶進(jìn)程中使用這里申請的內(nèi)存了，另外，Ashmem的一個特性就是可以在系統(tǒng)內(nèi)存不足的時候，回收掉被標(biāo)記為”unpin”的內(nèi)存，這個后面會講到，另外，MemoryFile也可以通過Binder跨進(jìn)程調(diào)用來讓兩個進(jìn)程共享一段內(nèi)存區(qū)域。由于整個申請內(nèi)存的過程并不再Java層上，可以很明顯的看出使用MemoryFile申請的內(nèi)存實(shí)際上是并不會占用Java堆內(nèi)存的。
MemoryFile暴露出來的用戶接口可以說跟他的名字一樣，基本上跟我們平時的文件的讀寫基本一致，也可以使用InputStream和OutputStream來對其進(jìn)行讀寫等操作：
- MemoryFile memoryFile = new MemoryFile(null, inputStream.available());
- memoryFile.allowPurging(false);
- OutputStream outputStream = memoryFile.getOutputStream();
- outputStream.write(1024);
上面可以看到allowPurging這個調(diào)用，這個就是之前說的”pin”和”unpin”，在設(shè)置了allowPurging為false之后，這個MemoryFile對應(yīng)的Ashmem就會被標(biāo)記成”pin”，那么即使在android系統(tǒng)內(nèi)存不足的時候，也不會對這段內(nèi)存進(jìn)行回收。另外，由于Ashmem默認(rèn)都是”unpin”的，因此申請的內(nèi)存在某個時間點(diǎn)內(nèi)都可能會被回收掉，這個時候是不可以再讀寫了
Tricks
MemoryFile是一個非常trickly的東西，由于并不占用Java堆內(nèi)存，我們可以將一些對象用MemoryFile來保存起來避免GC，另外，這里可能android上有個BUG：
在4.4及其以上的系統(tǒng)中，如果在應(yīng)用中使用了MemoryFile，那么在dumpsys meminfo的時候，可以看到多了一項(xiàng)Ashmem的值：
可以看出來雖然MemoryFile申請的內(nèi)存不計入Java堆也不計入Native堆中，但是占用了Ashmem的內(nèi)存，這個實(shí)際上是算入了app當(dāng)前占用的內(nèi)存當(dāng)中
但是在4.4以下的機(jī)器中時，使用MemoryFile申請的內(nèi)存居然是不算入app的內(nèi)存中的：
而且這里我也算過，也是不算入Native Heap中的，另外，這個時候去系統(tǒng)設(shè)置里面看進(jìn)程的內(nèi)存占用，也可以看出來其實(shí)并沒有計入Ashmem的內(nèi)存的
這個應(yīng)該是android的一個BUG，但是我搜了一下并沒有搜到對應(yīng)的issue，搞不好這里也可能是一個feature
而在大名鼎鼎的Fresco當(dāng)中，他們也有用到這個bug來避免在decode bitmap的時候，將文件的字節(jié)讀到Java堆中，使用了MemoryFile，并利用了這個BUG然這部分內(nèi)存不算入app中，這里分別對應(yīng)了Fresco中的GingerbreadPurgeableDecoder(https://github.com/facebook/fresco/blob/master/imagepipeline/src/main/java/com/facebook/imagepipeline/platform/GingerbreadPurgeableDecoder.java)和KitKatPurgeableDecoder(https://github.com/facebook/fresco/blob/master/imagepipeline/src/main/java/com/facebook/imagepipeline/platform/KitKatPurgeableDecoder.java)，F(xiàn)resco在decode圖片的時候會在4.4和4.4以下的系統(tǒng)中分別使用這兩個不同的decoder
從這個地方可以看出來，使用MemoryFile，在4.4以下的系統(tǒng)當(dāng)中，可以幫我們的app額外”偷”一些內(nèi)存，并且可以不計入app的內(nèi)存當(dāng)中
Summary
這里主要是簡單介紹了MemoryFile的基本原理和用法，并且闡述了一個MemoryFile中一個可以幫助開發(fā)者”偷”內(nèi)存的地方，這個是一個非常trickly的方法，雖然4.4以下使用這塊的內(nèi)存并不計入進(jìn)程當(dāng)中，但是并不推薦大量使用，因?yàn)楫?dāng)設(shè)置了allowPurging為false的時候，這個對應(yīng)的Ashmem內(nèi)存區(qū)域是被”pin”了，那么在android系統(tǒng)內(nèi)存不足的時候，是不能夠把這段內(nèi)存區(qū)域回收的，如果長時間沒有釋放的話，這樣子相當(dāng)于無端端占用了大量手機(jī)內(nèi)存而又無法回收，那對系統(tǒng)的穩(wěn)定性肯定會造成影響
References
1. Android系統(tǒng)匿名共享內(nèi)存Ashmem(Anonymous Shared Memory)驅(qū)動程序源代碼分析
http://blog.csdn.net/luoshengyang/article/details/6664554
2. Android Kernel Features(Ashmem)
http://elinux.org/Android_Kernel_Features#ashmem
分享名稱：如何「偷」Android的內(nèi)存？
地址分享：http://fisionsoft.com.cn/article/dpjeohc.html
