например - сетевая операция и растровое изображение, манипулирование загрузкой изображения и другие виды работы, могу ли я создать один TheadPoolExecuter для всего моего приложения и выполнить его.
если ответ отрицательный -> почему? и как создать thread pool для каждой отдельной операции?
или если да -> возникает ли проблема с производительностью?
заранее спасибо.
Enzkie, я тоже их видел, но мое замешательство неясно, потому что образец Google использует два пула для декодирования, а второй - для загрузки. так почему Google использовал два пула потоков вместо одного?
IMO они делают это, потому что хотят изолировать длительные задачи от тех задач, которые выполняются быстрее. Представьте, что у вас есть 4 потока в вашем пуле, и внезапно в пул загружаются 4 тяжелых сетевых запроса, в то время как простой запрос db в настоящее время ожидает, в этом случае это задерживает простой запрос.
@Enzokie Лучший способ определить разницу - это задачи, связанные с процессором, и задачи с блокировкой. Вам определенно нужен единый пул потоков для всей работы, связанной с процессором. Для блокировки вызовов вам понадобится больше потоков, которые ничего не делают. Однако на Android вам следует просто избегать блокировки сетевых API.
@MarkoTopolnik благодарит за полезные указатели.




Говоря теоретически, я думаю, что вы можете это сделать, и, согласно документация оракула, вы должны улучшить вашу производительность:
Thread pools address two different problems: they usually provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the resources, including threads, consumed when executing a collection of tasks. Each ThreadPoolExecutor also maintains some basic statistics, such as the number of completed tasks.
У обоих подходов есть свои преимущества и недостатки.
В случае однопоточного пула (я полагаю, одноэлементная реализация):
➕ у вас есть одна точка входа для отправки фоновой задачи
➕ легко реализовать и контролировать жизненный цикл
➖ если у вас много разных быстрых задач и какая-то длительная задача, долго выполняющиеся задачи могут удерживать весь поток в ограниченном пуле, пока пользователь ожидает каких-то быстрых действий в пользовательском интерфейсе
Различные пулы потоков (один пул для одного типа задач):
➕ пул потоков долго выполняемых задач может накапливать задачи, в то время как быстрая задача может выполняться в их собственном пуле потоков в зависимости
➕ вы знаете все о задачах в вашем приложении - вы можете точно настроить размер пула для каждого типа задач, настроить приоритет потоков, начальный размер стека и т. д. С помощью фабрики потоков
➕ если вы определяете группу потоков и имя потока, это может помочь вам в отладке
➖ задействовать разные пулы потоков для жесткого контроля их жизненного цикла
➖ такая реализация не даст больших преимуществ при плохом разделении по классам задач
В любом случае нужен компромисс и оценка преимуществ.
Предположим, у меня есть 5 разных типов задач и собственный пул потоков, когда я инициализирую этот пул потоков с минимальным и максимальным Runtime.getRuntime().availableProcessors(), является ли проблема производительности Couse? в android
availableProcessors() имеет смысл только для задач, связанных с процессором. Это не имеет отношения к блокировке задач.
@SKPanchal много потоков, конечно, не очень хорошо, но нужно помнить, что система в любом случае дает время для работы каждому потоку в зависимости от приоритета. Это означает, что короткие задачи в их собственном пуле не будут застревать в очереди и, как только это станет возможно, они будут обработаны.