Improving App Performance With Custom Thread Pools
summary
A small app that fetches Flickr images every 200m reveals dozens of threads: coroutines ~5, OkHttp ~5, Room ~4 plus OS and Google services — easily 60+ threads when counting default and IO dispatchers. The demo replaces per-library pools with a shared ThreadPoolExecutor configured with corePoolSize = Runtime.getRuntime().availableProcessors() and keepAlive = 60s; coroutines and OkHttp thread counts disappear while Room keeps its threads. It reduces memory/CPU but risks thread starvation and lost task priority.
AI-written summary · about
chapters (10)
- 0:00Thread pool impact on performance
- 1:08Default and IO sizes in coroutines
- 2:32Library thread pools overlap
- 3:36Measuring threads offline
- 5:24Custom thread pool executor
- 6:32Integrating with coroutines
- 7:56Disadvantages of shared pools
- 8:59Avoid shared thread pools
- 9:43Refactoring library instances
- 10:23Thread pool optimization
related talks
54mLooming in the cores
31mJava Virtual Threads
48mVisualiser l'API de concurrence Java
01h 02mThread pools: variety of algorithms and features
33mUntangle your App: Efficient Threading in Android
15mWhen, why, and how to multithread in Flutter
01h 08mBetter Code: Concurrency
37mPrepare for what "Loom"s ahead