iOS中使用c函式快速獲取乙個目錄所佔的空間大小

轉至：

在編寫ios應用時，我們都會大量把伺服器的介面呼叫資料或者資料進行快取，為了更好的使用體驗，有時候我們也會把各種快取的資料所佔的空間大小告訴使用者，提供給使用者參考，並讓使用者可以手動清除快取資料，就像我們在千尋影視中也就提供了這樣乙個設定項。但是當資料多了之後，就會發現所佔空間的大小計算非常耗時，因為快取下來的是大量的小檔案，這就會造成介面很久沒有反映的狀況。為了解決這種情況，當然是可以通過多執行緒的方法來做到的，但是在乙個簡單的設定介面做這麼複雜的事情，我倒認為是乙個拿起牛刀來殺雞的行為了。本篇就是來探求一些優化手段，把目錄的大小計算耗時降到可以接受的程度。

首先，在ios當中，要實現乙個功能，肯定想到去找objective-c的官方庫中是否提供了相關功能，如果有，那就直接用objective-c**來實現了，通過搜尋，很容易就寫出這樣乙個函式：

+ (long long) filesizeatpath:(nsstring*) filepath
return 0;
}

簡單可行，但是，我們這裡**效能，要優化，很容易想到直接使用c**，跳過objective-c的封裝來做，於是，我們這個函式就變成了：

+ (long long) filesizeatpath:(nsstring*) filepath
return 0;
}

迴圈1000次，我們就可以發現兩者之間巨大的效能差距了，在我的測試環境中，結果如下，c函式的耗時僅是第一種方法的5%

2011-12-31 14:17:22.165 otest[85861:903] [0.041] 使用nsfilemanager獲取檔案大小
2011-12-31 14:17:22.168 otest[85861:903] [0.002] 使用unix c函式獲取檔案大小

要獲取乙個目錄的總大小，我們就可以寫這麼乙個函式了：

// 迴圈呼叫filesizeatpath來獲取乙個目錄所佔空間大小
+ (long long) foldersizeatpath2:(nsstring*) folderpath
return foldersize;
}

但是，通過測試，目錄遍歷本身所帶來的時間消耗大大的弱化了我們改進過的filesizeatpath函式所帶來的優勢，導致後者的測試耗時僅是前者的1/2到1/3之間：

2011-12-31 14:17:23.233 otest[85861:903] [0.932] 使用subpathsatpath然後迴圈呼叫nsfilemanager獲取目錄總大小
2011-12-31 14:17:23.582 otest[85861:903] [0.348] 使用subpathsatpath然後迴圈呼叫unix c函式獲取目錄總大小

既然檔案大小的獲取可以使用c函式，那麼目錄的遍歷當然可以使用c函式來進行的了，一不做二不休，繼續修改優化，**我就不在繼續貼了，附件中有包含了自動測試的整個專案檔案，優化後，最終的效果如下：

2011-12-31 14:29:08.520 otest[87180:903] [0.915] 使用subpathsatpath然後迴圈呼叫nsfilemanager獲取目錄總大小
2011-12-31 14:29:08.860 otest[87180:903] [0.339] 使用subpathsatpath然後迴圈呼叫unix c函式獲取目錄總大小
2011-12-31 14:29:08.953 otest[87180:903] [0.092] 使用純unix c遞迴獲取目錄總大小

iOS中使用c函式快速獲取乙個目錄所佔的空間大小

iOS中使用c函式快速獲取乙個目錄所佔的空間大小

IOS中使用的C語言unlink函式

C 中使用事件只啟動乙個例項

iOS中使用c函式快速獲取乙個目錄所佔的空間大小

iOS中使用c函式快速獲取乙個目錄所佔的空間大小

IOS中使用的C語言unlink函式

C 中使用事件只啟動乙個例項

相關推薦