消除UIImage圖像命名：FUD請注意，這個問題可以追溯到iOS 2.0！從那時起，圖像要求和處理已經(jīng)發(fā)生了很大變化。Retina使圖像更大，加載它們稍微復雜一些。內(nèi)置支持iPad和視網(wǎng)膜圖像，您當然應該在代碼中使用ImageNamed。我看到很多人都說imageNamed不好，但同樣數(shù)量的人說性能很好 - 特別是在渲染時UITableView。例如，在iPhoneDeveloperTips.com上查看此SO問題或本文UIImageimageNamed用于泄漏的方法因此最好避免，但在最近的版本中已得到修復。我想更好地理解緩存算法，以便做出合理的決定，我可以信任系統(tǒng)來緩存我的圖像，以及我需要加倍努力并自己完成。我目前的基本理解是它是一個簡單NSMutableDictionary的UIImages文件名引用。它變得越來越大，當內(nèi)存耗盡時，它會變得更小。例如，有沒有人確切知道后面的圖像緩存imageNamed沒有響應didReceiveMemoryWarning？Apple似乎不太可能不這樣做。如果您對緩存算法有任何了解，請在此處發(fā)布。
2 回答
炎炎設計
TA貢獻1808條經(jīng)驗 獲得超4個贊
根據(jù)我的經(jīng)驗，imageNamed創(chuàng)建的圖像緩存不響應內(nèi)存警告。我有兩個應用程序，就像我可以得到它們一樣精簡到內(nèi)存管理，但由于缺乏內(nèi)存，仍然莫名其妙地崩潰。當我停止使用imageNamed加載圖像時，兩個應用程序都變得非常穩(wěn)定。
我承認這兩個應用程序都加載了大量的圖像，但沒有任何完全不同尋常的版本。在第一個應用程序中，我只是完全跳過緩存，因為用戶不太可能兩次回到同一圖像。在第二個中，我構(gòu)建了一個非常簡單的緩存類，正如你所提到的那樣 - 將UIImages保存在NSMutableDictionary中，然后在收到內(nèi)存警告時刷新其內(nèi)容。如果imageNamed：要像那樣緩存，那么我不應該看到任何性能升級。所有這一切都在2.2上運行 - 我不知道是否有任何3.0的影響。
你可以在我的第一個應用程序中找到關(guān)于這個問題的另一個問題： StackOverflow關(guān)于UIImage緩存的問題
另一個注意事項 - InterfaceBuilder使用了圖像命名。如果遇到這個問題，請記住一些事情。
- 2 回答
- 0 關(guān)注
- 633 瀏覽
添加回答
舉報
0/150
提交
取消