Kotlin сопрограммирует диспетчер как по умолчанию, но без основного потока (пользовательского интерфейса)

#android #kotlin #kotlin-coroutines

#Android #kotlin #kotlin-сопрограммы

Вопрос:

Есть ли способ создать (или как-то получить) диспетчер сопрограмм Kotlin на Android, который действует как по умолчанию, но исключает касание ядер потоков пользовательского интерфейса?

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

При Dispatchers.Default этом я извлекаю максимум ресурсов из системы, но в то же время мой пользовательский интерфейс становится более медленным.

Какие лучшие практики можно применить здесь?

Комментарии:

1. Вместо Dispatcher этого вы можете использовать Executers для предоставления ThreadPools .

2. Как я могу заставить потоки потоков касаться только ядер процессора, отличных от пользовательского интерфейса?

3. Проверьте это руководство: medium.com/capital-one-tech /…

4. Dispatchers.Default не затрагивает поток пользовательского интерфейса. Ваш пользовательский интерфейс отстает, потому что вы используете 100% CPU. Использование другого пула потоков не изменит ситуацию. Нет такого понятия, как «ядро потока пользовательского интерфейса».

5. Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors() - 1).asCoroutineDispatcher()

Ответ №1:

Вы можете использовать диспетчер с пользовательским пулом потоков следующим образом:

 val threads = 4
val dispatcher = Executors.newFixedThreadPool(threads).asCoroutineDispatcher()
  

Комментарии:

1. вы могли бы использовать фабрику потоков, которая создает потоки с фоновым приоритетом.

2. Как только вы согласитесь с тем, что в Android нет такого понятия, как «ядро потока пользовательского интерфейса» , вы будете в лучшем положении для рассмотрения решений, которые приводят к благоприятным результатам.

Ответ №2:

Оказывается, решение моих проблем было не в области JVM, а в NDK. Собственные библиотеки загружали процессор до 100%, и в основном похоже, что я ничего не могу с этим поделать с Java / Kotlin. Похоже, ответ находится где-то в коде C, что выходит за рамки моей компетенции.

Также я должен упомянуть Executors.newFixedThreadPool((Runtime.getRuntime().availableProcessors() - 1).coerceAtLeast(1)).asCoroutineDispatcher() решение. Мне кажется, что это может быть полезно для кого-то, у кого есть проблема с подобной проблемой.