Ответы на частые вопросы от начинающих Android-разработчиков

В этом случае естественным образом может возникнуть состояние гонки, когда кто-то из кэша читает данные на одном потоке и в это же самое время другой поток сходил в сеть и решил этот кэш обновить. Отсюда потребность в потокобезопасной коллекции, например ConcurrentHashMap.

Потокобезопасная хешмапа помогает в вашем сценарии постольку поскольку, потому что всё равно остается проблема синхронизации бизнес-логики. Если нужно разложить данные не в одну хешмапу, а в две — то у вас моментально наступает рассинхрон, и читающий поток прочитает мешанину из старых и новых данных. "Низкоуровневый" ReadWriteLock решает проблему на ура.

Более простой пример — когда мы храним вместе с данными TTL. Два потока идут читать, видят протухший кеш, идут на бэк. Никаких ConcurrentModificationException, но налицо гонка.

В оставшихся случаях достаточно использовать «высокоуровневые» инструменты вроде потокобезопасных коллекций

Как мы видим, недостаточно

Я могу привести два аргумента

Три: стектрейсы от Rx должны быть запрещены Женевской конвенцией.

Замечу только, что лично не встречался с проектами, на которых это было бы драматическое количество времени, или хотя бы настолько серьезное, чтобы поднять вопрос о том стоят ли compile-time гарантии потери в скорости сборок.

В этом месте у меня появляются вопросы, потому что kapt довольно прожорливый. Либо у вас зашкаливающий уровень модуляризации, где спасает кеширование, либо микропроекты, где и генерить толком нечего. В моем проекте kapt на холодной сборке съедает треть всего времени.

С KSP, говорят, будет повеселее, но он пока в бете.

Резюмируя ответ на изначальный вопрос — использовать ли в проекте с Dagger сабкомпоненты — важно понимать зачем вообще они используются.

В ответе вообще никак не затронут вариант использования component dependencies, так что неясно, как тут можно резюмировать.