После сборки — доработать напильником. Фиксим Retrofit для Корутин

Всем привет, это Полина Широбокова, android-разработчик в компании 65apps. При выходе Retrofit версии 2.6.0 нам озвучили официальную поддержку корутин, а значит — теоретически больше не было необходимости использовать специальный адаптер для вызова suspend-функций, у разработчиков появилась возможность обращения к API «из коробки». 

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

(Не совсем) асинхронные запросы в сеть

В changelog-е корутиновского обновления Retrofit указано, что под капотом suspend-функции обрабатываются как обычные, к примеру, fun user(…): Call<User>, с вызовом Call.enqueue(). 

В свою очередь, метод enqueue() выполняет асинхронный запрос в сеть, обращаясь к Dispatchers от OkHttp. Можно предположить, что отправляя запрос с использованием корутин, заботиться о том, чтобы главный поток не блокировался — больше не нужно, все уже написано за нас.

Тем не менее, при разработке одного из проектов нашей компании однажды мы заметили небольшой фриз UI сразу после отправки запроса по сети:

* дизайн экрана проекта изменен 

Как видите, при нажатии на кнопку и отправке запроса, перед тем как “прибиться” к низу экрана вслед за скрытой клавиатурой, кнопка подтормаживает на прежнем месте. Лаг исчез, когда вызов suspend-функции API обернули в withContext(Dispatchers.IO).

Возникает вопрос: каким образом заявленный асинхронный enqueue() может нагружать главный поток приложения и вызывать подвисание UI?

Ответ: сами запросы, конечно, OkHttp отправляет в другом потоке. А вот подготовка данных перед тем, как отправить их на другой поток, занимает какое-то время. И эта подготовка по тем или иным причинам не вынесена в отдельный поток и происходит на главном. 

Какой из этого следует вывод? Клиентский код всё-таки должен обеспечить изначальную асинхронность, даже делая запросы через enqueue()

Но прежде чем помянуть добрым словом «те или иные причины», что оставили подготовку в главном потоке, неплохо бы проверить на простейшем чистом примере, что вообще происходит.  Соберем одноэкранное приложение без архитектуры и всего, на что можно сослаться как на причину подвисания интерфейса. Сверстаем аналогичный UI и обратимся к какому-нибудь открытому API, не переключая диспатчер.

Да, внешне никаких фризов нет. Кнопка после нажатия и отправки запроса моментально оказывается внизу экрана после скрытия клавиатуры. Однако пройдемся по коду и расставим логи.

Во-первых, создадим CoroutineScope с Unconfined диспатчером. Грубо говоря, этот диспатчер продолжает выполнение в том потоке, в котором отработала корутина — в нашем случае речь про MainThread:

private val scope = CoroutineScope(Dispatchers.Unconfined)

Далее в функции makeQuery() создадим корутину на созданном ранее скоупе и обратимся к API. Заодно в логах будем ожидать ответ, полученный с сервера и время, которое проработает корутина, через measureTimeMillis(): 

private fun makeQuery() {         val time = measureTimeMillis {             scope.launch {                 val result = provideApiService().getSomethingFromApi()                 Timber.tag("RetrofitIssueLogs").d("result = $result")             }         }         Timber.tag("RetrofitIssueLogs").d("time = $time")     }

Помимо этого вызовем скрытие клавиатуры и также выведем начало работы функции в логи (для скрытия используется самописная extension-функция, ее вы легко найдете в гугле)

private fun hideKeyboard() {         Timber.tag("RetrofitIssueLogs").d("start hideKeyBoard()")         binding.root.hideKeyboard()     }

И, наконец, вызовем makeQuery() и hideKeyboard() при нажатии на кнопку, и, конечно, не забудем про лог

binding.btnTap.setOnClickListener {              Timber.tag("RetrofitIssueLogs").d("button clicked")             makeQuery()             hideKeyboard()         }

Запускаем приложение, жмем на кнопку и смотрим:

С момента нажатия на кнопку до начала скрытия клавиатуры прошло 546 миллисекунд. Такую длительность вывела в переменную time функция measureTimeMillis(). Стоит упомянуть о том, что время выполнения может меняться на разных устройствах и с поправкой на периодически возникающие системные операции под капотом. В конечном итоге информация о времени нужна нам для сравнения результатов.

А теперь обернем вызов апи в withContext(Dispatchers.IO):

scope.launch {                 withContext(Dispatchers.IO) {                     val result = provideApiService().getSomethingFromApi()                     Timber.tag("RetrofitIssueLogs").d("result = $result")                 }             }

Получаем следующий результат:

Внешне на UI разница обращения к API с Dispatchers.IO и без него была незаметна. Однако на самом деле, с IO переход к следующей операции на UI произошел быстрее в 10.92 раз! 

На самом деле эти числа — пиковые значения, которые нам удалось получить. Существуют еще разные нюансы вроде “перегретой” JVM с подгруженными классами и различными оптимизациями, поэтому иногда разница  может быть и меньше. Но это не отменяет главного — разница есть, и она существенная.

Главный вывод из вышеизложенного: переключать диспатчер, работая с Retrofit, всё-таки нужно.

Давайте сформулируем задачу

Практически во всех туториалах по использованию корутин и Retrofit, методы сервисного интерфейса оборачиваются в уже упомянутую withContext(Dispatchers.IO). На некоторых наших проектах мы поступаем так же.

Но после обнаружения вышеупомянутого UI-фриза мы решили переосмыслить этот подход и вынесли несколько его минусов:

• легко ошибиться, забыв обернуть suspend-функцию. Остается полагаться на code review, но было бы здорово автоматизировать переключение диспатчеров, сняв немного ответственности с ревьюеров.

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

• таким образом мы пишем бойлерплейт. Даже если бойлерплейт занимает всего лишь одну строчку при каждом вызове, он не перестает быть таковым.

Знакомьтесь, Retrofit-fix

Если есть возможность от бойлерплейта каким-либо способом избавиться — это стоит хотя бы попробовать сделать. Так и родилась идея написания Retrofit-фикса для корутин, который переключал бы за нас диспатчер один раз, снимая головную боль от сохранения вызовов в сеть в main-safe состоянии. 

RetrofitFix — это прокси-объект, позволяющий сразу установить необходимый диспатчер при реализации интерфейса вашего API с помощью Retrofit.

private typealias Invoke = suspend (method: Method, args: Array<*>) -> Any?  object RetrofitFix {       fun <T> create(retrofit: Retrofit, context: CoroutineContext, service: Class<T>): T {         val delegate = retrofit.create(service)          val invoke: Invoke = { method: Method, args: Array<*> ->             applyDispatcher(context) {                method.invoke(delegate, *args)             }         }          val invocationHandler = suspendInvocationHandler(invoke)          return Proxy.newProxyInstance(             service.classLoader,             arrayOf<Class<*>>(service),             invocationHandler         ) as T     }      private suspend inline fun applyDispatcher(         context: CoroutineContext,         crossinline method: () -> Any?     ) {         withContext(context) {             method()         }     }      private fun suspendInvocationHandler(block: Invoke): InvocationHandler {         return InvocationHandler { _, method, args ->             val cont = args?.lastOrNull() as? Continuation<*>             if (cont == null) {                 /* TBD                 Нерабочее решение:      val methodArgs = args.orEmpty()                 runBlocking {                     block(proxy, method, methodArgs)                 } */                 throw RuntimeException("Не используйте RetrofitFix при вызове не suspend функций")             } else {                 @Suppress("UNCHECKED_CAST")                 val suspendInvoker = block as (Method, Array<*>?, Continuation<*>) -> Any?                 suspendInvoker(method, args, cont)             }         }     } }

При создании объекта в параметры метода create() необходимо передать уже созданный объект Retrofit (Retrofit.Builder() … .build()), диспатчер, на котором вы хотите вызывать сетевые запросы и, наконец, ссылку на java class самого интерфейса API

fun provideApiServiceWithRetrofitFix() = RetrofitFix.create(provideRetrofit(), Dispatchers.IO, ApiService::class.java)

Наша задача состояла в том, чтобы вызывать все методы API на предопределенном диспатчере. Для этого мы использовали java.lang.reflect.Proxy, так как прокси-объект перехватывает вызовы методов интерфейсов, которые этот объект реализует, позволяя нам добавить новый функционал во время, собственно, вызовов этих самых методов.

Вернемся к реализации фикса. Нашему будущему прокси-объекту необходим InvocationHandler для добавления новой функциональности. Можно было бы просто создать объект InvocationHandler-а и в методе invoke() обернуть приходящий в прокси Method API в нужный диспатчер. Но поскольку всё-таки планируется, что фикс будет поддерживать и обычные, и suspend функции, из-за различий в контекстах их вызовов, реализацию мы разделили под каждый из двух случаев.

В функции suspendInvocationHandler() мы проверяем аргументы, пришедшие в Invoke, на наличие объекта типа Continuation

private fun suspendInvocationHandler(block: Invoke): InvocationHandler {         return InvocationHandler { proxy, method, args ->             val cont = args?.lastOrNull() as? Continuation<*>             if (cont == null) {                // TBD             } else { // code             }         }

Это сделано как раз для разделения вызовов suspend и не-suspend-функций. Как мы знаем, в Java корутин нет. При преобразовании кода из Kotlin в Java, в конец списка аргументов корутиновских suspend-функций добавляется еще один параметр — объект Continuation. Этот объект позволяет “продолжить” выполнение корутины по возвращении из suspend-функции. На StartAndroid есть базовое описание принципов работы Continuation на русском языке. Погрузиться в детали реализации каждый может самостоятельно, нам же важно отметить, что Continuation служит своеобразным маркером suspend-функции. Поэтому, чтобы корректно обработать вызов апи, для начала определяем, какую функцию мы получили.

В хендлере мы используем переменную block — аргумент типа Invoke, который сами и создали:

private typealias Invoke = suspend (method: Method, args: Array<*>) -> Any?

Invoke — это typealias для suspend-функционального типа, который принимает Method (его мы получим в хендлере) и аргументы метода — args.

В методе create(), при создании объекта фикса, мы присваиваем объекту новоиспеченного типа Invoke, по сути, “выполнение” будущего метода (Method) у прокси-объекта, обернув вызов метода в диспатчер.

val delegate = retrofit.create(service)          val invoke: Invoke = { method: Method, args: Array<*> ->             applyDispatcher(context) {                 @Suppress("SpreadOperator")                 method.invoke(delegate, *args)             }         }

А вот и функция обертка — applyDispatcher(). Она простая, но выполняет главную задачу фикса:

 private suspend inline fun applyDispatcher(         context: CoroutineContext, // диспатчер, который мы передаем в create() при инициализации RetrofitFix          crossinline method: () -> Any?     ) {         withContext(context) { // просто оборачиваем полученную функцию в диспатчер             method()         }     }

Вернемся к Continuation и разделению вызовов функций в хендлере. Поскольку suspend-функцию нельзя вызвать из обычной функции, мы расширяем наш тип Invoke, и кастим его к не-suspend функциональному типу, передавая Continuation, как “провод”, по которому suspend-обертка сможет вернуть результат своего выполнения обратно к месту вызова API.

val suspendInvoker = block as (Method, Array<*>?, Continuation<*>) -> Any?                 suspendInvoker(method, args, cont)

Вы можете заметить, что аргументы нашего функционального типа Invoke практически идентичны аргументам, приходящим в функцию invoke() в InvocationHandler. Не хватает только proxy: Any! в начале. Более того, выше в method.invoke() мы передаем не прокси, чей метод, по идее, будет вызван, а заново создаем объект сетевого интерфейса через retrofit.create(service) и используем его. 

Дело в том, что Retrofit при создании объекта интерфейса API сам создает прокси, при этом выполняя свои дополнительные операции (можете посмотреть в исходниках библиотеки). Поэтому, если бы при обращении к API внутри invoke() мы оборачивали в диспатчер  метод нами же созданного прокси, мы бы не имели никакой связи с Retrofit. 

А сейчас получается следующее: мы создаем прокси-объект сетевого интерфейса, при обращении к методам которого будет создаваться объект сетевого интерфейса через Retrofit, и его методы будут вызываться из нужного диспатчера. 

Прокси над прокси — к сожалению, в текущей версии Retrofit не предусмотрена возможность расширения функционала через прокидывание диспатчеров.

Остается дело за малым: создаем InvocationHandler, передавая ему диспатчер-обертку Invoke

val invocationHandler = suspendInvocationHandler(invoke)

и возвращаем из метода create() заветную прокси, передавая в инстанс-метод интерфейс API и ранее переопределенный InvocationHandler.

return Proxy.newProxyInstance(             service.classLoader,             arrayOf<Class<*>>(service),             invocationHandler         ) as T

Подведем итоги

Retrofit версии 2.6.0 предоставляет поддержку корутин, однако у существующего решения «из коробки» есть существенный недостаток — необходимо принудительно уходить с main-thread’а в клиентском коде, а разработчики по-прежнему вынуждены писать бойлерплейт в виде переключения корутиновских диспатчеров при запросах в сеть (например, с использованием withContext(Dispatchers.IO)). 

Retrofit-fix позволяет забыть о переключении диспатчеров, обращаясь к API.

Важное уточнение: мы хотим, чтобы фикс работал как с suspend-методами API, так и с обычными. К сожалению, пока удалось реализовать поддержку только suspend-функций и только при вызове их из launch() билдера. Если у вас будут идеи как можно исправить это и реализовать поддержку работы с async()/await()  — пишите в соцсети нашей компании или прямо здесь в комментариях. Предложение рабочего решения — пропуск технического собеседования в компанию 🙂