Создавайте клиент-серверные приложения с помощью gRPC.

gRPC — это современная высокопроизводительная платформа RPC с открытым исходным кодом, которая может работать в любой среде. Он может эффективно соединять сервисы в центрах обработки данных и между ними благодаря подключаемой поддержке балансировки нагрузки, отслеживания, проверки работоспособности и аутентификации. Он также применим на последней миле распределенных вычислений для подключения устройств, мобильных приложений и браузеров к серверным службам. Вы можете найти документацию на официальном сайте gRPC и получить поддержку от сообществ открытого исходного кода. В этом руководстве представлены решения для создания приложений Android с использованием gRPC.

grpc.io — официальный сайт проекта gRPC. Дополнительные сведения о том, как работает gRPC, см. в разделе Что такое gRPC? и концепции gRPC . Чтобы узнать, как использовать gRPC в приложении Android, см. пример Hello World в кратком руководстве по gRPC Android Java . Вы также можете найти несколько других примеров gRPC для Android на GitHub .

Функции

Вызов процедуры упрощает задачу
Поскольку это RPC, модель программирования представляет собой вызовы процедур: сетевой аспект технологии абстрагирован от кода приложения, благодаря чему он выглядит почти так, как если бы это был обычный вызов функции в процессе. Ваше взаимодействие клиент-сервер не будет ограничено семантикой методов HTTP-ресурсов (таких как GET, PUT, POST и DELETE). По сравнению с REST API ваша реализация выглядит более естественно, без необходимости обработки метаданных протокола HTTP.
Эффективная передача по сети с помощью HTTP/2
Передача данных с мобильных устройств на внутренний сервер может оказаться очень ресурсоемким процессом. При использовании стандартного протокола HTTP/1.1 частые подключения мобильного устройства к облачной службе могут привести к разрядке аккумулятора, увеличению задержки и блокировке подключения других приложений. По умолчанию gRPC работает поверх HTTP/2, что обеспечивает двунаправленную потоковую передачу, управление потоком, сжатие заголовков и возможность мультиплексирования запросов по одному соединению TCP/IP. В результате gRPC может сократить использование ресурсов, что приведет к сокращению времени отклика между вашим приложением и службами, работающими в облаке, уменьшению использования сети и увеличению срока службы батареи для клиентов, работающих на мобильных устройствах.
Встроенная поддержка потокового обмена данными.
gRPC с самого начала был разработан с учетом поддержки HTTP/2 для полнодуплексной двунаправленной потоковой передачи. Потоковая передача позволяет запросу и ответу иметь сколь угодно большой размер, например операции, требующие загрузки или выгрузки большого объема информации. Благодаря потоковой передаче клиент и сервер могут одновременно читать и записывать сообщения, а также подписываться друг на друга без отслеживания идентификаторов ресурсов. Это делает реализацию вашего приложения более гибкой.
Бесшовная интеграция с протоколом Buffer
gRPC использует буферы протокола (Protobuf) в качестве метода сериализации/десериализации с плагином для генерации кода, оптимизированным для Android ( Protobuf Java Lite ). По сравнению с текстовым форматом (таким как JSON), Protobuf предлагает более эффективный обмен данными с точки зрения скорости маршалинга и размера кода, что делает его более подходящим для использования в мобильных средах. Кроме того, краткий синтаксис определения сообщений/сервисов Protobuf значительно упрощает определение модели данных и протоколов приложения для вашего приложения.

Обзор использования

Следуя руководству «Основы gRPC — Android Java» , использование gRPC для приложений Android включает четыре шага:

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

В демонстрационных целях в приведенном примере байты передаются в виде обычного текста. Однако ваше приложение всегда должно шифровать сетевые данные в рабочей среде. gRPC обеспечивает поддержку шифрования SSL/TLS, а также обмен токенами OAuth (OAuth2 со службами Google) для аутентификации. Дополнительные сведения см. в разделах TLS на Android и Использование OAuth2 .

Транспорт

gRPC предоставляет два варианта реализации транспорта для клиентов Android: OkHttp и Cronet.

Выбрать транспорт (расширенный)

  • ОкHttp
    OkHttp — это легкий сетевой стек, предназначенный для использования на мобильных устройствах. Это транспорт gRPC по умолчанию для работы в среде Android. Чтобы использовать OkHttp в качестве транспорта gRPC для вашего приложения, создайте канал с помощью AndroidChannelBuilder , который обертывает OkHttpChannelBuilder и зарегистрирует сетевой монитор в ОС Android для быстрого реагирования на изменения в сети. Пример использования можно найти в gRPC-Java AndroidChannelBuilder .
  • Кронет (экспериментальный)
    Cronet — это сетевой стек Chromium, упакованный в виде библиотеки для мобильных устройств. Он предлагает надежную сетевую поддержку с использованием современного протокола QUIC, который может быть особенно эффективен в ненадежных сетевых средах. Дополнительные сведения о Cronet см. в разделе «Выполнение сетевых операций с помощью Cronet» . Чтобы использовать Cronet в качестве транспорта gRPC для вашего приложения, создайте канал с помощью CronetChannelBuilder . Пример использования приведен в gRPC-Java Cronet Transport .

Вообще говоря, мы рекомендуем приложениям, ориентированным на последние версии SDK, использовать Cronet, поскольку он предлагает более мощный сетевой стек. Недостатком использования Cronet является увеличение размера APK, поскольку добавление двоичной зависимости Cronet добавит к размеру приложения > 1 МБ по сравнению с ~ 100 КБ для OkHttp. Начиная с версии GMSCore v.10, актуальную копию Cronet можно загрузить из сервисов Google Play. Размер APK больше не может вызывать беспокойства, хотя устройства без установленной последней версии GMSCore могут по-прежнему предпочитать использовать OkHttp.