Multithreading Issue

Hi Dave - I seem to have come across an odd issue dealing with multithreading that results in Image View hanging.

Whenever there are multiple threads active in the app performing other tasks (eg running multiple network threads) it seems the Image View will hang and not load an image until previous threads complete or free up.

What I believe may be happening (pl. feel free to correct) is that the Image View internally uses AsyncTask - which has limited number of concurrent threads per app domain that can run depending on SDK version. I believe its around 5 threads, subsequent threads will be queued.

This could be a bit problematic for apps with lots of processing. What makes it worse is that the problem will not be evident on some SDKs/devices. There's also very little gained by going with AsyncTask VS. using Threads directly, other than syntactic convenience I suppose :)

Would it be possible to replace AsyncTask in the next library update ?

Thanks!

[davemorrissey]

I'm reluctant to do this unless I have to. This is the first problem like this that's been reported, and up to now it's been rock solid with AsyncTasks for a lot of users, so a move to threads would be a big step into the unknown. Besides the convenience, they are the standard method of doing work off the UI thread and they provide the concurrency control this view needs - I can safely queue up requests to load tiles even while the user is rapidly panning and zooming, and not worry if the activity is paused or stopped. It may actually be desirable that image loading is paused while the app is doing a lot of work in the background.

One option may be to execute AsyncTasks on the provided THREAD_POOL_EXECUTOR. This seems to work, but I don't know if BitmapRegionDecoder is guaranteed to provide thread safe decoding of images from all sources.

Actually AsyncTask is known to have many pitfalls and problems. You will find lots of material on this.

The issue I described can easily be reproduced by starting 4-5 async tasks, and then trying to use the Image View. You will see it will hang and not load any images.

[davemorrissey]

The worst issues with AsyncTasks either don't apply to the way I'm using them here, or I've already worked around using static inner classes, weak references and state checks. Implementing my own threading would require solving these problems and more, and I'm not keen on spawning threads within a view. Sharing the threads Android has already created for the app makes more sense. I'll consider making the parallel executor available as an option, which should solve this problem.

Just to update on the issue.

Now I am able to reproduce the issue even by spawning a single network thread (even without AsyncTask) and then trying to load the image file. As long as the thread is running the image will not load up.

So with this new bit of detail I'm not sure if a parallel executor would solve this. Ripping out AsyncTask and replacing with Threads and Handlers typically isn't that trivial. The only trick is not leaking memory but that's easily handled by making handlers static (if inner classes) and using WeakReferences for private members of the handler. Of course you know your logic better and what it would require but I did it for my whole app in about 2 days, I originally used async tasks but ran into issues.

Additionally I think this actually effects more people than we first assumed earlier in this post. Having a network thread run in the background is very common for modern apps now, syncing stuff and all. Likely reason why this was not reported much is because the issue just manifests itself as a slow load in most cases as the network thread will eventually will timeout, and the image will load right after.

Thanks for looking into this.

FYI for now I'm only seeing this on some test devices. I'll do another test targeting more devices tomorrow and post findings.

[davemorrissey]

Why wouldn't a parallel executor solve this? It would allow the view to load images on the parallel executor even while other AsyncTasks are using the single threaded executor. There would only be a delay if the parallel executor is busy running several other tasks, and in that scenario it might be desirable to avoid spawning more threads - besides the CPU load it increases the chances of getting an OOME while loading.

[davemorrissey]

I've pushed a new release (3.3.0) with support for AsyncTask.THREAD_POOL_EXECUTOR on SDK 11+. Give this a try and let me know if it helps. Call this before setting the image source:

imageView.setParallelLoadingEnabled(true);

[davemorrissey]

Any luck with this, can I close the bug?

[franciscofranco]

Sorry for bringing this from the dead, but instead of using reflection to access the POOL_EXECUTOR you can use https://github.com/android/platform_frameworks_support/blob/master/v4/java/android/support/v4/os/AsyncTaskCompat.java probably saving some overhead from the reflection.

[davemorrissey]

There is no dependency on support-v4 at the moment and I don't want to add one for this. The overhead of reflection is tiny.

[AlexVPerl]

Hi Dave - revisiting this after a long pause.

AsyncTask still remains an issue blocking images from loading if other AsyncTasks are running. The limitation is that only max of 5 tasks can run simultaneously.

AsyncTask.THREAD_POOL_EXECUTOR does not resolve this issue. All it does is execute tasks in parallel instead of serial order. It does nothing to address the limit of 5 tasks, rest will be queued.

I'm still constantly running into issues where images cannot be loaded for a while because other AsyncTasks are running.

Would it be possible to address this in near future by replacing AsyncTasks with regular Threads?

Thanks in advance!

[davemorrissey]

I think I'd have concerns about using an unbounded number of threads to load tiles, but it would be possible to send the AsyncTasks to a custom executor with more threads available, rather than rewriting the tasks as threads. I'd consider a PR that allows an Executor instance to be supplied, but would rather not have the view spawning and managing threads, especially because some apps have several on screen at once.

Are the executor's threads being kept busy by other apps? Simultaneously loading images on more threads than there are CPU cores is unlikely to make the view run faster. In my experience, with my phone probably not doing any significant background work, enabling parallel loading does nothing for performance.

[franciscofranco]

For the past couple months I've been using a dedicated Executor for AsyncTasks instead of the POOL_EXECUTOR for this exact reason. I use Executor.newCachedThreadPool() because it spawns whatever threads it needs, re-uses previously cached Threads and if they aren't used for 60 seconds they are destroyed.

Regarding your N5X, it's an odd case because it's very likely these jobs aren't queued into the A57 cores, but to the A53 cores which are ridiculously underpowered. I'll guess that the task scheduler will actively migrate threads to the A57 if there are a lot of them being created since the scheduler doesn't want to starve cores, so that might improve performance.