Android: колбэки, корутины и бенчмарк отладочной сборки

Разработчику

Проблемы использования корутин в Kotlin

7 Gotchas When Explore Kotlin Coroutine — статья о проб­лемах, с которы­ми мож­но стол­кнуть­ся при исполь­зовании корутин в Kotlin. Вот наибо­лее инте­рес­ные тезисы.

1. runBlocking может под­весить при­ложе­ние

Рас­смот­рим сле­дующий код:

Выг­лядит безобид­но, но он при­ведет к фри­зу при­ложе­ния. Почему так про­исхо­дит, под­робно опи­сано в статье How runBlocking May Surprise You. Если крат­ко, то проб­лема воз­ника­ет из‑за самого прин­ципа работы runBlocking. Он запус­кает новую корути­ну, а затем бло­киру­ет текущий поток. Но если запус­тить runBlocking с дис­петче­ром Main из основно­го потока, то порож­денная корути­на ока­жет­ся в том же потоке и в ито­ге не смо­жет получить управле­ние, так как текущий поток будет заб­локиро­ван.

По‑хороше­му эта проб­лема реша­ется отка­зом от исполь­зования runBlocking. Это инс­тру­мент для юнит‑тес­тов, а не для про­дак­шена. Но если очень хочет­ся, мож­но убрать имя дис­петче­ра из вызова фун­кции:

2. Корути­ну нель­зя завер­шить в любой момент

Не­опыт­ные раз­работ­чики счи­тают, что если выз­вать метод cancel() корути­ны, то она будет завер­шена сра­зу. На самом деле это не так и в ряде слу­чаев корути­на может успеть пол­ностью отра­ботать, перед тем как обра­бота­ет сиг­нал завер­шения.

Про­исхо­дит так потому, что корути­ны реали­зуют модель коопе­ратив­ной мно­гоза­дач­ности. Ког­да одна корути­на посыла­ет сиг­нал завер­шения дру­гой корути­не, пос­ледняя может либо обра­ботать этот сиг­нал, либо про­игно­риро­вать его. Хорошая новость сос­тоит в том, что все стан­дар­тные suspend-фун­кции (yield(), delay(), withContext() и дру­гие) уме­ют самос­тоятель­но обра­баты­вать этот сиг­нал и завер­шать корути­ну. Пло­хая новость — бла­года­ря такой невиди­мой авто­мати­зации раз­работ­чики быва­ют удив­лены, что одни корути­ны в их коде завер­шают­ся поч­ти мгно­вен­но в ответ на cancel(), а дру­гие про­дол­жают работать.

Проб­лему реша­ем так: про­веря­ем зна­чение свой­ства isActive меж­ду вычис­лени­ями и завер­шаем корути­ну, если получи­ли зна­чение false.

3. Отме­нен­ный coroutine scope нель­зя исполь­зовать пов­торно

Взгля­ни на сле­дующий код:

Дан­ный код не будет работать. Если выз­вать cancel() на coroutine scope, он ста­новит­ся неп­ригод­ным для даль­нейше­го исполь­зования. Выхода из этой ситу­ации два: соз­дать новый scope на мес­те ста­рого и завер­шать не сам scope, а все при­над­лежащие ему корути­ны:

Используем колбэки в последовательном коде

Suspending over Views — хорошая статья о том, как прев­ратить кол­бэки в suspend-фун­кции с помощью suspendCancellableCoroutine().

В Android кол­бэки пов­сюду, и UI фрей­мворк не исклю­чение. Кол­бэки исполь­зуют­ся для все­го под­ряд:

• AnimatorListener — что­бы запус­тить код по окон­чании ани­мации;
• RecyclerView.OnScrollListener — что­бы выпол­нить код сра­зу пос­ле про­мот­ки RecyclerView;
• View.OnLayoutChangeListener — что­бы узнать, ког­да View был перери­сован пос­ле изме­нения.

В целом кол­бэки не очень удоб­ны и могут прев­ратить код в труд­нопере­вари­ваемую кашу (callback hell). Фун­кции‑рас­ширения из биб­лиоте­ки android-ktx час­тично реша­ют эту проб­лему: пре­обра­зуют кол­бэки на осно­ве клас­сов в лям­бды (doOnLayout() вмес­то OnLayoutChangeListener()), но всем нам хотелось бы писать код в пос­ледова­тель­ном сти­ле, как и пред­лага­ет язык Kotlin и suspend-фун­кции. Но мож­но ли это­го дос­тичь, имея дело с фрей­мвор­ком Android, написан­ным с помощью кол­бэков?