Зачем изучать java.util.concurrent, если пишешь под Android?
Проходил недавно собеседование на должность Team Lead под Android. Было два технических собеседования с разными людьми, на которых активно интересовались знаниями в Java Concurrency. Я сразу честно сказал, что java.util.concurrent я даже не рассматривал и о его содержимом имею весьма смутное представление (собеседование я прошёл, но речь не об этом).
Зачем мне, как разработчику приложений (именно приложений, а не библиотек широкого применения), могут понадобиться знания этого пакета?
Нужно запустить какую-нибудь тяжеловесную задачу в бэкграунде? Service+HandlerThread.
Нужно запускать множественные REST-запросы? Подключим Robospice+Retrofit, там уже всё до нас написано. Или изучим RxJava, и будем раскидывать задачи по разным потокам с помощью subscribeOn()/observeOn().
И так далее и тому подобное.
Я, конечно, решил получить-таки общее представление, для чего прочёл первый том Core Java (с пристальным изучением последней главы), на очереди - "Java Concurrency in Practice", и, до кучи, "7 Concurrency Models in 7 Weeks" (это не совсем про Java, это скорее для общей картины), но вопрос остаётся. Как часто возникают в Android-приложениях задачи, для которых нужны хорошие знания именно стандартных в Java техник и примитивов параллельного программирования - volatile, ReentrantLocks, syncronizers, concurrent collections, ExecutorServices и так далее? Может это я сижу в своём болотце, и занимаюсь очень уж простыми задачами, не зная этого?
P.S. Даже в Core Java Кэй Хорстманн пишет, что многие задачи могут быть сведены к использованию concurrent collections, и трюки с volatile/implicit locks/etc пригождаются очень редко.
P.P.S. Интересуют не общие ответы вроде: "Применяется часто, учи давай", или: "Применяется редко, бросай ты это дело, иди лучше unit-testing подучи", а именно примеры задач, в которых вам понадобилось воспользоваться упомянутым выше пакетом.
1 BlockingQueue музыкальный плеер, есть очередь откуда проигрываются треки, плеер снизу забирает трек, сверху пользователь накидывает в очередь новые треки. работа с очередью идет из разных потоков.
2 качалка файлов, очередь файлов для закачки, настройками могу регулировать кол-во одновременно качающих потоков
3 CountDownLatch отличный инструмент для отсчета оставшегося времени
4 CyclicBarrier чумовой механизм ожидания завершения работы нескольких потоков, парсинг сайта,
закачка файлов, обработка текстов, подсчет данных или игр
5 Executors и ExecutorService быстрая организация пула потоков использую для работы с sqlite,
а также ScheduledExecutorService для организации таймера для проверки изменения чего либо у пользователя на девайсе
6 полезная штука Exchanger, моментальная реализация задачи producer - consumer
7 ConcurrentHashMap вообще классика для организации хешей, это сейчас есть LRU, а раньше не было. А было WeakReference и эксперементы с очередями и хешами WeakHashMap
8 Atomic, легко позволяют создавать потоко-безопасные переменные, использовал AtomicBoolean, как межпотоковый стейт
Я знаю, что есть конторы, как крупные так и мелкие не используют Retrofitы robospicы DI фреймвори и так далее.
Учитывая проблемы с 65к dex, из-за тучи либ сторонних и особенно play services, собрать уже сложно.
И для мелкой задачи стоит ли с собой тащить либу, вопрос холиваный
И стоит знать java.util.concurrent потому что, это используется в либах. Тот же volley, там три чистых потока Thread для выполнения http, а в ui пробрасывается через хендлер и Executor
LeEnot: недавно был проект использующий сторонний sdk, который должен был видеть fb sdk, при включении multiDex не видел .... а google service + fb+еще по мелочи сервисов которые требовал заказчик ... печально все было ) хотя это конечно не повод отказываться от retrofit ))
LeEnot: количество танцев с бубном вокруг sdk отбивало всякое желание копаться + сроки горели ... выкинул часть библиотек без которых можно было обойтись
LeEnot: Например, все что связано сокетным программированием. Сокетное соедение оборачивается в поток, и необходимо понимать, например, как данные из этого потока доставать и обновлять из внешнего потока. Так же есть масса алгоритмов которые требуют параллельного выполнения кода. Android это обычная операционная система, и скажу вам по секрету, под нее разрабатывают не только email клиенты, todo списки и приложения для соц. сетей. И далеко не всегда можно обойтись готовыми фреймворками вроде RXJava которые, кстати основаны все на тех же потоках.
FoxInSox: нет, в качестве ответа на вопрос ТС. Вообще, я в основном AsyncTask имел ввиду. А на счет Thread, сокеты, да, пожалуй, не подумал об этом, а алгоритмы, требующие параллельного выполнения, вероятнее всего, оптимальнее в NDK писать.
Robert: ну, на самом деле не так уж и важно, на какую должность я собеседовался, эту информацию я в принципе мог бы и опустить. Важнее было понять, в каких задачах мне может выйти боком незнание стандартных механизмов, и как часто эти задачи всплывают, без абстрактного: "Ну, сторонних библиотек и Android SDK может не хватить, поэтому нужно учить".
Извиняюсь, но... Не знаю... А хочу спросить... Чисто из эгоизма)))) человека с какими навыками ты хотел бы видеть в своей команде? Просто, мучительно больно смотреть на огромное разнообразие технологий в вакансиях (помимо sdk/ndk)
повторяетесь уважаемый )) основные компоненты android sdk ─ activity, fragment, servise, reciver ... must have
Знание основных компонентов туда же
Навык разработки ui ─ верстка xml layout, общего понимания работы ресурсов
База данных ─ хелперы, провайдеры, лоадеры
Навыки работы с сетью (тут от команды к команде отличается, но понимать что пальцы в розетку совать нельзя, то есть слатть запросы из ui потока нельзя ))), ну и здравый смысл естественно ─ понимать что такое rest и как лучше организовать работу с ним )
это некий минимум, все специализации начинаются после )
gadfi: повторяюсь, знаю. Потому и вопросом на вопрос, как бы, незаметно попытался спросить. Да и вообще, у меня по некоторым причинам наступила депрессия, и хочется найти выход))) А в паническом состоянии я просто нуждаюсь в какой-либо поддержке. Так что, прошу прощения за некоторые глупые поступки) И вообще, лично Вам, спасибо. Я никогда не забуду хуификтор)))
Александр Василенко: не надо депрессии )))этот список на самом деле не такой большой и если разобраться то все сатнвоится на порядок проще чем кажется на первый взгляд )
gadfi: да депрессия не из-за этого))) это на самом деле всё достаточно просто. Есть кое что в жизни, весьма угнетающее, от чего хочется поскорей убежать, а никак. Это, впрочем, другая никому не интересная история.
Учи, ибо знание того как работает тот-же Services и диспетчиризация в Rx сильно поможет если столкнешся с ситуацией, в которой требуется не описанное в User Guide использование того или иного элемента.
Самого долго мучали подобные вопросы (некоторые даже до сих пор).
В Android-е все асинхронные механизмы базируются на Thread. Однако крайне желательно (все практики об этом говорят) использовать более высокоуровневые "родные" Android-механизмы.
И все же при всем желании, избежать столкновения с java-concurrency не получится.
Примеры из своей практики: Service - который все время в работе (например, стрим-видео, vpn и тд) и еще и управлять этим процессом налету надо(приостановить/прервать/продолжить итд)
При внимательном изучении ServiceHandler - ты поймешь, что это неподходящее решение в данном случае. Тут только от Service наследоваться - ну и дальше по цепочке -
- в главном потоке (onStartCommand) - нельзя, нужен Thread, а если еще одна команда придет - то не плодить же потоки - уж лучше Executor и тд. и тп
Далее - Content Provider, который ходит не в базу, а в сеть(тут меня ждал большой облом)
Оказывается NetworkOnMainThreadException - это не только про сеть в активити,
это вообще про сеть в главном(пусть даже не UI-ном треде) - поэтому в любом случае(хоть Service, хоть Content Provider и тд) - ты должен отдупляться от главного потока (по крайнее мере для запросов в сеть)
Касаемо Content Provider - пойти в сеть прям в методе(qeury/openFile/и тд) нельзя (NetworkOnMainThreadException) но и дождаться респонса надо прям тут (синхронно)- вот те и пляски Callable's, Future's
Так что при всем твоем (и моем тоже) желании поступать высокоуровнево, без велосипедов - увы не всегда возможно
Простой
