在基於Windows Mobile應用程式中儲存管理的最佳策略[翻譯]

起源: 前幾天編了個小程式,要將一個文字檔放到數組中,雖然都讀進去了,但是後來運行出錯無法搜尋檔案的後面部分,弄了半天才發現原來是啟動並執行時候記憶體不足,故把數組都改為動態申請,後面就 OK了. 於是,不得不考慮記憶體的使用以及運行效率的問題.前幾天在微軟的MSDN上看到Windows Mobile SDK的更新文檔(即使我在8月初期就看到了微軟MSDN上的更新,當時只是看到了一些),發現了以下的文章,把他翻譯成中文:
(翻譯不對的地方，還請多多指教)

Best Practices for Managing Storage in a Windows Mobile-based Application

    儲存硬體和整體的系統設計對儲存的效能影響很大.目前,Pocket PC裝置使用基於RAM的檔案系統,而Smartphone裝置使用基於快閃記憶體(falsh)的永久隱藏檔系統.想對儲存硬體技術有更深的理解,可以看:
System Memory Management in Windows CE .NET

儲存硬體效能考慮

    下表是基於快閃記憶體(Flash)的永久隱藏檔系統與基於RAM的檔案系統的各種操作效能的相關比較：

操作	基於Flash	基於RAM
局部讀	較慢	較快
局部寫	很慢	較快
網路(Network)讀	較快	較慢
網路寫	較快	較慢
是否有備份電池硬體	否	是
永久註冊表？	比基於RAM更優越	是

儲存軟體效能的最佳策略

    遵循以下的最佳策略能夠協助您最小化任何的效能影響， 為此您的應用程式必須:

• (1) 最小化應用程式的大小，即應用程式要儘可能的小
• (2) 最小化永久儲存資料的數量。 由於檔案系統的資源可能是有限的，所以必須確保您的應用程式能夠容忍並不總是啟動並執行儲存系統。
• (3) 最小化更新資料的頻率。不要經常更換資料。
• (4) 最小化任何對註冊表的周期性的寫。不要經常對註冊表進行寫操作。
• (5) 最小化動態連結資料庫(DLLs)的數量。如果不是經常調用,動態載入庫比靜態載入庫更為優越，但要記住的一點是當你使用完動態連結程式庫後，記得要卸載，釋放動態連結程式庫。
• (6) 最小化迴圈檢測。使用事件驅動設計，能夠使您的應用程式檢測到所需要的任何變化，而不是使用while迴圈語句來檢測。  
     運行少量的代碼。代碼在ROM中是壓縮儲存的，因此在代碼能夠運行之前，代碼必須先解壓。而對代碼進行解壓影響效能。比如：在一個典型的Smartphone開發平台，解壓一頁的代碼需要3毫秒(ms)。另外，代碼執行要消耗電源，除非絕對需要（必須），盡量不運行代碼。
• (7) 只在合適的時候運行代碼。例如：當應用程式對使用者來說不可見的時候，停止它的活動。
• (8) 最小化對閃寸硬體的讀寫。在一個典型的Smartphone開發平台，往快閃記憶體硬體中寫一頁的代碼需要83毫秒（ms)的時間。用儘可能地往RAM中寫資料，來取代往快閃記憶體裡寫（註：由上一部分的表格可知，往RAM中進行局部寫要比往快閃記憶體中寫快）。如果對快閃記憶體的寫是不可避免的，那麼應該儘可能地延遲寫的時間。對快閃記憶體的寫比對RAM的寫要花費更多的電量，因此儘可能地減少對快閃記憶體的寫以達到減少電量消耗的目的。
• (9) 儘可能地把驅動程式標記為可調頁的(Pageable)。只要驅動程式在掛起或恢複的期間不運行，並且驅動程式沒有在維護頁錯誤（缺頁？），我們就可以把驅動程式標記為可調頁的。RAM包含所有可調頁的驅動程式和DLL檔案。在啟動的時候，所有的不可調頁的驅動程式和DLL檔案必須被解壓進RAM。（註：而上文中說到解壓需要時間的）

  原文：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/moconbestpracticesformanagingstorageinwindowsmobileapplication.asp