environment類中提供了幾個靜態常量用於標識外部儲存的狀態，這些狀態都是string型別
media_bad_removal 在沒有掛載前儲存**已經被移除。
media_checking 正在檢查儲存**。
media_mounted 儲存**已經掛載，並且掛載點可讀/寫。
media_mounted_read_only 儲存**已經掛載，掛載點唯讀。
media_nofs 儲存**是空白或是不支援的檔案系統。
media_removed 儲存**被移除。
media_shared 儲存**正在通過usb共享。
media_unmountable 儲存**無法掛載。
media_unmounted 儲存**沒有掛載。
可以通過靜態方法getexternalstoragestate()來獲取外部儲存的狀態，如果程式需要在外部儲存裡面讀寫資料，必須要先判斷：
if(environment.media_mounted.equals(
environment.getexternalstoragestate())
|| !environment.i***ternalstorageremovable())
然後，新增外部儲存讀和寫的許可權：?
1
2
在environment中還提供了android標準目錄的路徑，以string型別提供。
directory_alarms 系統提醒鈴聲存放的標準目錄。
directory_downloads
的標準目錄。
directory_movies 電影存放的標準目錄。
directory_music **存放的標準目錄。
directory_notifications 系統通知鈴聲存放的標準目錄。
directory_pictures 存放的標準目錄
directory_podcasts 系統廣播存放的標準目錄。
directory_ringtones 系統鈴聲存放的標準目錄。
static file getdatadirectory() 獲得data的目錄（/data）。
static file getexternalstoragedirectory() 獲得外部儲存**目錄。（/mnt/sdcard or /storage/sdcard0）
static file getrootdirectory() 獲得系統主目錄（/system）
除了用environment獲取儲存目錄之外，還可以通過把路徑寫死的方式，比如要讀取外部儲存/mnt/sdcard目錄下的檔案，可以在程式中直接用全路徑，
但是這樣做是很不好的，應該
android
實在是太開放了，外部儲存的目錄的什麼還是要韌體製作商才知道，但是有一點是毋庸置疑的，就是android框架層裡面
已經是指定好了environment.getdownloadcachedirectory()的返回路徑。所以，盡量用這種方式來獲取和儲存資料，以免韌體廠商不同而造成路徑的差異。
android的實際開發中還用了兩個非常重要的快取目錄，乙個是應用程式自己的快取空間，另乙個是外部儲存為該應該程式提供的快取空間。有什麼差別？
使用過lrucache和dislrucache的童鞋應該知道。
這兩個方法是通過上下文物件context獲取的，只要應用程式被解除安裝，這兩個目錄下的檔案都要被清空。
context.getcachedir() 獲取應用程式自己的快取目錄
context.getexternalcachedir() 獲取應用程式在外部儲存的儲存目錄
Android記憶體管理
low memory killer android的low memory killer是在標準linux kernel的oom out of memory 基礎上修改而來的一種記憶體管理機制，當系統記憶體不足時，殺死bad程序釋放其記憶體。bad程序的選擇標準有兩個 oom adj和占用記憶體的大小...
聊聊Android記憶體管理
聊聊對記憶體洩漏的認識?1.延時性的記憶體洩漏2.覆蓋式記憶體洩漏3.累加式記憶體洩漏沒有用的物件無法 的現象就是記憶體洩露 記憶體洩露會導致什麼後果?1.應用可用的記憶體減少,增加了堆記憶體的壓力2.降低了應用的效能，比如會觸發更頻繁的 gc3.嚴重的時候可能會導致記憶體溢位錯誤，即 oom er...
Android 記憶體管理機制
無意中在miui看到的文章，感覺不錯，轉了過來。原文如下 這種設計本來就是乙個非常好的設計，下次啟動程式時，會更快，因為不需要讀取介面資源。android系統這樣的設計不僅非常適合移動終端的需要，而且減少了系統崩潰的可能，確保了系統的穩定性。老想著清理記憶體的同學完全是因為被塞班或者windows毒...