Ffimageloading: InvalidateCache Remove Similar does not work for image on multiple pages

Created on 1 Oct 2018  路  6Comments  路  Source: luberda-molinet/FFImageLoading

Description

When attempting to remove an entry from MemoryCache on Android and iOS using CachedImage.InvalidateCache(key, All, true) the code does not seem to remove the similar entries from the cache.

Expected Behavior

When calling InvalidateCache the base key and all similar entries (ie those with starting with the key followed by a semicolon should also get removed from the cache.

Actual Behavior

Only the base entry seems to get removed

Basic Information

  • Version with issue: 2.4.3.840
  • Last known good version: unknown
  • Platform: Xamarin.Forms (Android & iOS)

Verbose Logs

10-01 19:01:37.449 D/ViewRootImpl@63dced9MainActivity: ViewPostIme pointer 0
Remove from memory cache called for 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e10-01 19:01:37.491 I/mono-stdout( 6614): Remove from memory cache called for 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e

10-01 19:01:37.561 D/ViewRootImpl@63dced9MainActivity: ViewPostIme pointer 1
Remove from memory cache called for 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e10-01 19:01:39.542 I/mono-stdout( 6614): Remove from memory cache called for 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e

10-01 19:01:39.590 D/InputMethodManager( 6614): HSIFW - flag : 0 Pid : 6614
[MEMORY_CACHE] EntryNoLongerDisplayed: 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e;0x35010-01 19:01:39.621 I/mono-stdout( 6614): [MEMORY_CACHE] EntryNoLongerDisplayed: 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e;0x350

[MEMORY_CACHE] Cache hit from reuse pool for key: 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e;0x35010-01 19:01:39.646 I/mono-stdout( 6614): [MEMORY_CACHE] Cache hit from reuse pool for key: 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e;0x350

[MEMORY_CACHE] EntryDisplayed: 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e;0x350
Image loaded from cache: 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e;0x35010-01 19:01:39.647 I/mono-stdout( 6614): [MEMORY_CACHE] EntryDisplayed: 8c7c0366-37d5-40f5-981a-ef2f7a1a9e5e;0x350

Android more info needed

Most helpful comment

I have done some further investigation and the problem appears to happen given the following set of circumstances.

  • Base page with a list of images
  • Click on an image to display another page showing details of one image
  • Save the new image (reusing the same key) and invalidate the cache
  • Close the detail page and return to the previous page
  • Reload the list to update it with the changes

Because of the OnEntryNoLongerDisplayed event attached to the image when the base page reloads the old image is placed into the reuse_cache and then when it tries to show it again it finds the old image there rather than going back to the source to get the new image.

Ideally, if the cache is invalidated then all existing entries should likewise be invalidated, there needs to be some way for the DemoteDisplayedEntryToReusePool method to know that the entry being demoted has been evicted so that it forces a refresh from the source.

All 6 comments

From what I can see in the logs and from what I can tell by looking at the code is that the control seems to be moving the image out of the cache and placing it into the reuse_pool, and then immediately upon the next attempt to read that image is taking the result out of the reuse_pool rather than getting it back from the original source.

Should the InvalidateCache not be removing the entry from both the cache and the reuse_pool?

Is there some other command I should be calling to clear the item from all the memory caches completely?

I have done some further investigation and the problem appears to happen given the following set of circumstances.

  • Base page with a list of images
  • Click on an image to display another page showing details of one image
  • Save the new image (reusing the same key) and invalidate the cache
  • Close the detail page and return to the previous page
  • Reload the list to update it with the changes

Because of the OnEntryNoLongerDisplayed event attached to the image when the base page reloads the old image is placed into the reuse_cache and then when it tries to show it again it finds the old image there rather than going back to the source to get the new image.

Ideally, if the cache is invalidated then all existing entries should likewise be invalidated, there needs to be some way for the DemoteDisplayedEntryToReusePool method to know that the entry being demoted has been evicted so that it forces a refresh from the source.

reuse_cache is quite a different thing from memory cache. Those bitmaps are only used to accelerate decoding of image, nothing more. Read more here:

Android 3.0 (API level 11) introduces the BitmapFactory.Options.inBitmap field. If this option is set, decode methods that take the Options object will attempt to reuse an existing bitmap when loading content. This means that the bitmap's memory is reused, resulting in improved performance, and removing both memory allocation and de-allocation. However, there are certain restrictions with how inBitmap can be used. In particular, before Android 4.4 (API level 19), only equal sized bitmaps are supported. For details, please see the inBitmap documentation.

If that is the case then there is definitely something wrong. I have been unable to evict an image from cache if that image is currently displayed on another page. In order to work around this issue I have been forced to delete all instances of the image from all controls prior to calling the evict method so that when the pages pop back into view the old image is already gone before it tries to show it again.

I feel like there is something not quite right with the way the eviction is implemented.

See also #1164, here there is reference for removing the data from the reuse_pool in order to have the cache invalidated properly.

Fixed

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rredoh picture rredoh  路  17Comments

OpticNectar picture OpticNectar  路  19Comments

softsan picture softsan  路  32Comments

Tommigun1980 picture Tommigun1980  路  16Comments

stesvis picture stesvis  路  144Comments