使用AlamofireImage裏面的UITableViewCell

Question

我已經讀了很多的answers這裏說，通過使用AlamofireImage輔助方法（如af_setImageWithURL()）或任何同等庫中，你不需要擔心電池再利用的東西（另外，許多出版教程其實只是這樣做）。也就是說，我不必保留對單元格的弱引用，也不必通過使用tableView的cellForRowAtIndexPath()方法在後臺下載完成後更新其imageView，就像我們通常在手動請求時所做的那樣。

首先，這是真的嗎？如果是這樣，它是如何在庫內完成的，因爲我試圖追蹤AlamofireImage的af_setImageWithURL()代碼，並且我找不到任何努力來確保我們仍在使用我們提出請求的單元格。我錯過了什麼嗎？

如果聽起來很愚蠢，我很抱歉，但我真的很困惑。

Answer 1

假設你正在談論UIImageView類別，是的，它確實解決了許多問題困擾着天真的異步圖像檢索問題，即：

• 如果電池插入上面或下面的單元格在問題中，NSIndexPath已更改的事實不會影響所討論單元的image的異步更新。

• 如果您快速滾動到第100行，因爲在重用單元上調用af_setImageWithURL，以前與此重用單元關聯的先前行的請求將被取消。的這個

  • 一個含義是，它避免了對可見行得到與先前使用該重用小區相關聯的行的圖像的圖像請求更新圖像視圖。 （這可以避免簡單實現可能遇到的緩慢連接上的圖像「閃爍」。）

  • 這樣做的另一個含義是，它避免了與單元100關聯的圖像可能會在圖像請求第1-99行。

• AlamofireImage還提供圖像縮放程序中，示出了用於細胞的縮略圖圖像時，這是很重要的。如果您不調整圖像大小，如果使用大型資源（特別是在可以看到許多縮略圖圖像的收集視圖中），則可能會產生過多的內存使用情況。

在該AlamofireImage可能不是正常，因爲我們想處理UITableViewCell問題方面，它包括：

• 關於緩存，AlamofireImage依賴於底層NSURLCache而不是做自己的緩存通過NSCache或本地永久存儲。雖然我理解作者爲什麼這樣做（有一定的直觀上訴，只要NSURLCache應能夠優雅地做到這一點），你應該知道NSURLCache可能有問題，只緩存根據記錄不佳的規則（如果資源超過總高速緩存大小的5％，不會被緩存;如果HTTP標頭不正確，則不會高速緩存等）。所以在緩存問題上必須小心。

• 關於預熱（預取與可見行相鄰的單元格的圖像），AlamofireImage在這裏沒有太多的工作。您可能想要查看與可見行相鄰的單元格的一些低優先級請求管理，以便可見單元格的性能不會受到負面影響，但也可以在用戶滾動時與這些行關聯的圖像已經存在。

底線，這是一個誇張地說：「你不用擔心電池再利用的東西」使用UIImageView類別時。您仍然需要仔細設計您的單元複用邏輯，例如：

• 確保您沒有繞過圖像視圖更新的任何路徑，即使相關行可能沒有要顯示的圖像;
• 確定是否需要調整圖像大小;
• 確認NSURLCache在您的情況下正確緩存;
• 決定是否要創建和緩存縮略圖;
• 等等

但是這是事實，一個良好的執行UIImageView類別可以防止過於簡單化的異步圖像檢索程序的許多陷阱。但它不是銀彈。