iOS 7 - UITableViewController大數據源 - 策略建議？

Question

Xcode中：5.0.2 iOS的：的7.0.x

我有一個是有條件所示的二次視圖當在我的應用程序在用戶登錄。此次要視圖顯示用戶必須選擇其中一個作爲其已驗證會話生命週期的「默認」值的項目列表。大多數我的用戶只會看到這種次要視圖。

項目列表以Web服務的JSON形式返回，可以從1項到1000項。如果返回，則次視圖將不會顯示。

該json將被再次構造兩個元素，每個項目，id和itemName。我估計在最壞的情況下會有幾百kb的下載 - 而且它只有一次下載。也許一個可搜索的API而不是數據轉儲會是更好的做法？

一旦結果返回，它們將被處理成兩個NSArray。一個NSArray的NSDictionary爲我檢索一次id和NSArray的NSString包含itemName - 用於填充UITableView並執行關鍵字搜索;

For retrieving ID reference: 
[ { id: 0, itemName: "one" }, { id: 1 itemName: "two" } ] 

For populating the UITableView data source 
[ "one", "two" ] 

現在我需要這個數據在我的UITableView。由於這是一次性操作（稍後可以改變，但用戶通常不會定期更改），因此我計劃將整個陣列添加到UITableView中。

通常情況下，您應該將什麼最大大小放入表視圖？這會導致我一些嚴重的記憶問題嗎？將如何對100的搜索時的關鍵詞檢索公平 - 1000

我也期待也許在更新UI遵循這一非常緊密的聯繫人應用程序（UILocalizedIndexedCollation？），這樣再次將對此產生影響。

感謝，

Answer 1

擁有JSON，相應的基金會表示將消耗大約 RAM的5倍以字節爲單位的長度。例如，如果您的JSON是300千字節（UTF-8），那麼NSJSONSerialization將創建一個可能消耗1.5 MB RAM的基礎層次結構。

這個數量很適合RAM。

當且僅當你不想堅持 JSON表示或相應的模型，並且不希望利用核心數據因爲其他原因（如編輯，撤消，回退等），我會使用核心數據強烈地反對與：因爲在最糟糕的情況下您的數據仍然「很小」，因此在假設它可以保證您的記憶的情況下不需要利用核心數據。

核心數據也不便宜，記憶明智。在你的情況下，使用核心數據實際上會導致你的應用程序消耗更多 RAM，因爲SQLite的緩衝區和緩存，核心數據緩衝區和緩存以及內部結構。在實踐中，如果您的場景中有1000個對象，則Core Data/SQLite方法將消耗約4 Mbyte。這比您的JSON表示大約多3倍。另一方面，當你的元素數量增加很多，並且還有內存壓力時，Core Data可能不會消耗更多的RAM。

Answer 2

我也會向您強烈推薦CoreData方法與UIFetchedResultController。這是針對您的問題制定的解決方案。當您從網絡上下載數據時，FetchedResultController將顯示空白表格視圖，當下載完成或「足夠」時，您可能會顯示數據而不會阻止用戶界面。更重要的是，如果你想一次顯示一個龐大的數據庫，當用戶向下滾動時，控制器會「自行」獲取更多的數據。

當然UILocalizedIndexedCollation也支持在這裏。