По горячим следам DroidCon Moscow 201527.10.2015 11:18

С 25 по 27 сентября в Москве проходил DroidCon, крупнейшая евразийская конференция для Android-разработчиков. Гости и выступающие собрались в офисе Mail.ru, занимающем одну из 27-этажных башен бизнес-центра. Сама конференция шла три дня, и программа выступлений каждого дня была рассчитана на разную целевую аудиторию.

Tech day

Первый и самый интересный день. Для того, чтобы зарегистрироваться, необходимо было пройти простенький тест, который отсекал людей, напрямую не имеющих отношения к Android-разработке. Было открыто два зала — кинотеатр и meeting room, в которых параллельно читались доклады.

Bussines day

Во второй день на конференцию мог попасть любой желающий, что привело к наплыву огромного количества людей, но офис Mail.ru смог их всех вместить. Было открыто три зала — Атриум, Кинотеатр и meeting room. Также в этот день открылась выставка различных новинок, так или иначе относящихся к Android. Выставка проходила два дня.

Sony показывала телевизоры с обычным Android и рассказывала, как разрабатывать под них с помощью обычных смартфонов и специальных образов Android, созданных для продукции компании. С помощью обычного джойстика от PS4 можно было поиграть в Asphalt и выиграть новый Sony Xperia Z5. Для этого нужно было в течение дня пройти трассу на лучшее время. Затем они брали лучших игроков и проводили состязание между ними. Очень странно выглядит ES Explorer на 40-дюймовом экране :)

Epson хвасталась своими очками дополненной реальности. Из минусов можно отметить следующее:

• очки довольно громоздкие,
• нужно носить с собой «телефон без экрана», который заменяет тачпад,
• устаревший Android. На демонстрационном устройстве была версия 4.0.4, но представитель компании обещал обновления до 5, и даже до 6.

Intel представили новое железо для часов, телефонов и планшетов, которые были сделаны на базе процессора Intel Atom x3. Проводили розыгрыш часов со всеми модными штуками, наподобие трекеров сна, датчиков пульса и т.д.

3D.RU: их площадка имела мало отношения к Android. Они демонстрировали возможности 3D-печати и рассказывали о технологиях, которые сейчас активно используются в этой области.

Voximplant рассказывали о своей разработке. Ключевые особенности продукта:

• дешевые звонки,
• возможность звонить с любого устройства на любое устройство, в том числе на обычный телефон, на страничку в браузере и т.д.,
• доступно нативное SDK для Android и iOS,
• доступно SDK для React Native для Android и iOS,
• видео чат.

Community day

Посетителей было меньше всего. Было открыто три зала — Атриум, Кинотеатр и meeting room. В этот день проводились воркшопы, демокемпы и баркемпы.

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

DemoCamp: различным стартапам давалось две минуты на презентацию своего проекта. Далее жюри высказывалось и давало свои советы, как улучшить проект.

BarCamp: на второй день конференции слушателям предложили маркером написать на стене в meeting room интересующие их темы. А на следующий день устраивались холивары, если находились и противники, и сторонники этой темы.

За время конференции мы посетили следующие доклады:

Секреты успеха в Google Play

Алексей Конин начал свой доклад с общей статистики о Google Play. Доклад делился на три части:

• Новые возможности в Google Play.
  
  • Новые разделы Android for family и Android for kids.
  • Новый раздел для корпоративных пользователей Google Play for work. У руководителей появилась возможность устанавливать приложения своим сотрудникам.
  • Поменялась страничка с приложениями разработчика. Теперь есть возможность немного ее кастомизировать.
  • Cloud test lab: возможность тестировать приложения удаленно на большом количестве устройств.
  • Появилась реклама в самом Google Play. Теперь результат поиска будет содержать одно рекламное предложение.
  • Появилась возможность узнать, откуда пришел пользователь, откуда он узнал о вашем приложении.
  • Появилась возможность тестировать метаданные.
  • Оплата приложений средствами оператора сотовой связи (без использования банковской карты).
  
  
• Разработка первоклассных приложений. Представитель компании рассказал о том, что у каждого приложения есть параметр, видимый только сотрудникам Google. По этому параметру система оценивает приложение, размещенное в Google Play. Он зависит от качества приложения, дизайна, использования нового API, поддержки нового SDK и различных устройств. От этого параметра зависит, получите ли вы значок «Top developer» и удостоится ли ваше приложение фичеринга.
• Рост приложения.
  
  • Он чрезвычайно зависит от локализации метаданных в Google Play и локализации цены на приложение. Рекомендуется избегать автоматической конвертации и выставлять цену без десятичного разделителя. Также появилась возможность выставлять цену на приложение меньше 1$, но пока что в режиме бета-тестирования и только в Индии.
  • Рекомендуется использовать подписки как средство монетизации приложения.

К релизу Android M готов!

Денис Неклюев рассказал, как сделать существующие приложения совместимыми с Android M. Также докладчик сообщил о главных нововведениях в Android M, которые коснутся разработчиков. Основные изменения:

• Runtime permission. Google переделала систему разрешений в Android. Теперь пользователь может управлять разрешениями через настройки приложения. При установке будут запрашиваться только самые необходимые из них, а при выполнении кода, который требует того или иного разрешения, необходимо проверять, было ли оно дано. Если нет, то запрашивать. Докладчик советовал объяснять пользователю, зачем вам необходимо это разрешение и быть готовым к тому, что пользователь не согласится его дать.
• Doze. Google предложил новую систему энергосбережения. Теперь после засыпания устройства многие процессы будут блокироваться. В Doze-режиме:
  
  • блокируется доступ к сети,
  • игнорируются WackLock’и,
  • запрещена работа Sync Adapter’ов,
  • запрещена работа JobScheduler,
  • AlarmManager работает лишь частично.
  
  В режиме Doze возможны голосовые вызовы и push-уведомления. Также для приложений будут выдаваться окна некоторой длительности, в которых они смогут делать что-то важное. В ADB добавлена возможность тестировать новый режим. При необходимости можно добавлять приложения в White list, это даст им возможность работать в Doze-режиме.Приложение может попасть в White list, только если пользователь сам его туда добавит.
• Apache HTTP Client исключен из состава SDK. Если он необходим приложению, то его можно подключить как библиотеку. Вместо него предлагается использование HttpUrlConnection.
• Управление Wi-Fi-сетью возможно, только если она была подключена приложением.
• Нельзя при поиске получать MAC-адреса Bluetooth и Wi-Fi. Методы WifiInfo.getMacAddress() и Bluetooth.getAddress() будут всегда возвращать 02:00:00:00:00:00.

Google App Indexing

Тимур Ахметгареев рассказал еще об одном способе взаимодействия приложений. Сам Google App Indexing предлагает несколько вариантов взаимодействия:

• В поисковой выдаче Google. Теперь если ваше приложение может отобразить информацию по пользовательскому запросу, то оно будет отображаться первым в поисковой выдаче.
• Подсказки при вводе запроса. Если пользователь по аналогичному запросу уже переходил в ваше приложение, то в подсказке оно будет отображаться последним.
• Некий фичеринг в виде карусельки из приложений в Google Play, которые могут обработать запрос пользователя.
  Для использования этой технологии Google требует:
  
  1. При нажатии в приложении на кнопку «Назад» возвращаться в результаты поиска (опционально, но настоятельно рекомендуется для обеспечения хорошего UX).
  2. Сразу открывать запрашиваемый контент.
  3. Обеспечивать бесплатный доступ к запрашиваемому контенту (иначе Google не сможет его проиндексировать).
  4. Включить Search Console для сайта.
  5. Указывать сайт в Developer Console.
  6. Не злоупотреблять этой технологией.

Настоящий Build должен делать 3 вещи: собрать, проверить и развернуть

Кирилл Харьков рассказал о своем опыте использования Gradle-сборки приложений.

Во-первых, он наладил работу команды с Git:

• Git flow — идеология, при которой на каждое изменение создается отдельная ветка в репозитории. По завершении она объединяется с основной веткой разработки, а затем из нее уже сливается с мастер-веткой. Эту идеологию рекомендуется использовать в любом проекте.
• Использование Branch updater. При заливке в ветку разработки в ее дочерние ветки подтягиваются все изменения. Это нужно для минимизации конфликтов при слиянии после завершения фичи.

Далее Кирилл рассказывал про build-скрипт на примере их проекта. Сборка собирает три разных приложения (у каждого свой пакет, ресурсы и т.д.), которые могут одновременно устанавливаться на одно устройство. Реализовано это через flavours. Также есть 8 разных buildType (обычно их два):

1. Debug
2. Release
3. Alpha
4. Branch
5. Beta
6. Corp Beta
7. Unit test
8. UI Test

После запуска полной сборки получается 24 разных apk-файла. Отличаются они настройками приложения, ресурсами, тестами, отключением или тех или иных фич.

Например:

• Аналитика для debug-версии не нужна.
• Логи в релизной версии не нужны.
• Не нужны всякого рода префетчеры при модульном тестировании.

Использование ресурсов тоже является довольно-таки интересной идеей. Проблема в том, что некоторые ресурсы могут использоваться в приложении A, некоторые — в Б, а часть ресурсов может использоваться сразу в нескольких приложениях. Предлагается следующая структура папок:

• res — общие файлы для всех приложений.
• res_a — ресурсы, которые предназначены только для приложения A.
• res_ab — общие ресурсы для обоих приложений.

Но и тут имеется проблема. Так как ресурсы для приложения А будут формироваться из res + res_a + res_ab, то возможны конфликты идентификаторов ресурсов, за этим нужно внимательно следить.

Помимо этого, Кирилл давал рекомендации по использованию статических анализаторов. Суть в том, чтобы писать правила для того же lint-a по мере code review. В дальнейшем это поможет тратить меньше времени на анализ кода и будет гарантией соблюдения общего стиля кода по всему приложению.

Также докладчик вкратце рассказал о новой Test Support Library. По словам автора, теперь можно использовать все удобные решения без необходимости выбора одного конкретного фреймворка. Пример — тестирование перехода по пушу.

Последний этап сборки — развертывание. В приведенном на выступлении примере билд сам занимается развертыванием на разных площадках: Google Play, Hockey App, соцсети, форумы, корпоративные сайты и т.д.

Dagger2: практический ликбез по работе с кинжалами

Автор доклада — Дмитрий Полищук, разработчик Android-клиента Яндекс.Такси. Выступление было посвящено основам Dependency Injection, применяемого для уменьшения связанности кода. Был рассмотрен пример с Network Client, этот класс зачастую используется по всему приложению. Обычно при разработке мы либо каждый раз создаем новый инстанс, либо используем singletone. Также мы сталкиваемся с проблемами, когда нам необходимо иметь разные вариации Network Client в одном приложении. Например, когда у нас не готов backend и нам нужно использовать mock’и. Или же для тестирования правильного реагирования нашего кода на те или иные ответы от API. Как сказал автор, при таком подходе у нас растет снежный ком из сильно связанного кода, монолитного кода приложения и явно и не явно связанного кода.

Проблемы при использовании singletone’ов:

• Сильная зависимость от самих singletone’ов.
• Мало возможности переиспользовать код. Дело в том, что при переиспользовании кода приходится тянуть за собой все зависимости.
  При использовании Dependency Injection нижестоящие зависимости ничего не знают о вышестоящих. Это позволяет делать код модульным, что, в свою очередь, убирает связанность и упрощают переиспользование кода.

Для использования этой технологии нужно:

• Вынести переиспользуемый код в модули.
• В классах, которые его используют, создать поле и пометить аннотацией @Inject.
• Создать интерфейс с указанием всех классов, в которых будут использоваться @Inject-ы.

Главные преимущества Degger2 перед другими библиотеками для Dependency Injection:

• Использование кодогенерации. Сгенерированный код остается читабельным.
• Есть плагин для Android Studio для перехода по зависимостям injection.
• Остается рабочая обфускация, без дополнительного вмешательства в конфиги proguard.
• Полное отсутствие рефлексии.
• Ошибки всплывают еще на этапе компиляции, а не на этапе выполнения.

Data Binding и Custom Views

На этой лекции мы ожидали услышать про новинку от Google — Data Binding, позволяющую заполнять экран обычными Pojo-объектами путем указания прямо в XML, какие поля и куда должны записаться. Технология также позволяет создавать обработчики для действий и даже выполнять маленькие куски кода, написанные на XML.

Автор оказался противником этой технологии, аргументировав это так:

• Довольно специфический синтаксис. На самом деле, синтаксис не специфический, просто из-за ограничений XML приходится вместо спецсимволов использовать их коды.
• Если в ходе разработке возникла необходимость сначала сделать дизайн приложения, а затем уже прикручивать логику, то программисту все-равно понадобится лезть в файлы разметки. Т.е. логика отображения находится в нескольких местах, а не в одном. Это несколько усложняет множество процессов, такие как code review, рефакторинг и разработку в целом.

Взамен этого автор рассказал о своем понимании паттерна MVVM (Model-view-view Model). Используя обсерверы и кастомные view можно реализовывать логику заполнения видов данными. Виды получаются полностью самодостаточными, благодаря чему у нас очень сильно разгружается activity или фрагмент. В нем значительно сокращается количество кода.

Android NDK. Стоит ли игра свеч

Осенью этого года наконец-то состоялся релиз Android Studio с поддержкой NDK. Часть лекции была посвящена как раз этой теме.

Доклад был разбит на вопросы:

1. Зачем использовать NDK.
   
   • Части приложения, где критично быстродействие. Работа с аудио, видео, распознавание образов и написание игр. Т.к. в Java и Android существует такое понятие как heap size, то обработка того же видео становится очень большой проблемой. Она решаема с помощью NDK.
   • Использование уже написанных библиотек. Снова пример с обработкой видео: есть очень популярная библиотека ffmpeg, большинство разработчиков под Android думают именно о ней, когда речь заходит об интеграции работы с видео.
   • Один код на несколько платформ. Довольно-таки интересный подход, но требующий знания программистом С\С++. Это дает много преимуществ: нужен только один тест, код будет вести себя одинаково на всех планируемых платформах. До релиза новой Android Studio эта фича была труднореализуемой, т.к. процесс интеграции, дебага и работы с нативным кодом в целом был очень трудоемким, что сводило на нет все преимущества такого подхода.
2. Механизм работы.
   
   • JDK — набор инструментов для запуска нативного Java-кода.
   • NDK — набор инструментов для использования JNI в Android.
   • В APK кладутся apk-файлы, скомпилированные под определенную платформу.
   • Приложение можно полностью реализовать на нативном коде, но это очень редко бывает целесообразно.
3. Экспериментальный Gradle-плагин. Его возможности:
   
   • Интеграция NDK.
   • Отладка нативного кода.
   • Рефакторинг (переименование в нативном коде и в Java).
   
   Пока не поддерживается:
   • Интеграция с внешними системами сборки.
   • Сборка статических библиотек.
   • Чистые NDK-модули.
4. Производительность.
   
   • Сам Google рекомендует использовать NDK только тогда, когда без него не обойтись. Существует такое понятие как Overhead. Время вызова нативного метода гораздо больше вызова Java-метода из Java-кода. Нужно минимизировать количество вызовов нативных методов.
   • Есть возможность использовать различные компиляторы. Например, код, скомпилированный компилятором Intel, покажет лучшую производительность на процессоре x86.
5. Где искать проблемы и как с ними бороться.
   
   • Обязательно освобождать память, выделенную в нативном коде, и обязательно обнулять слушатели, передаваемые в нативные методы.
   • Важно понимать отличие локальных ссылок от глобальных. Время жизни локальных ссылок — пока не закончится метод. Время жизни глобальных — пока их явно не освободят.
   • Количество локальных ссылок ограничено, их также нужно освобождать, если они больше не используются.
   • По умолчанию сборщик мусора не трогает нативный код. Если в нем есть глобальная ссылка на Java-объект, то она не будет очищена, пока это не сделает кто-то явным образом. То есть мы получаем два лика памяти из Java и из NDK.
   • Меньше обращаться из нативного кода в Java и обратно.
   
   В нативных потоках также есть своя специфика:
   • Локальные ссылки никогда не очищаются сами.
   • Не работает метод по поиску JNI-классов. Решение: кэшировать классы или class loader при инициализации.
   • Крэши в нативном коде. Они обычно приносят много проблем, так как у нас, скорее всего, будет малоинформативный лог, либо его вообще может не быть. Для решения этой проблемы написано несколько библиотек:
     
     • Coffecatch — проблемная интеграция в приложение.
     • Breakpad — неудобная интеграция, т.к. очень мало документации.
     • Обертки на Breakpad, такие как Crashlitics, Hockey App и т.д.
   • Размер APK и использование Apk Splits для решения проблемы больших apk-файлов. По умолчанию, при сборке приложения APK содержит в себе библиотеки для всех платформ. Соответственно, приложение значительно увеличивается в размере. Решить это проблему можно с помощью Gradle, путем описания splits с указанием разного versionCode для каждой платформы.
   
   

Nearby: новые возможности взаимодействия рядом

Возможность взаимодействия между двумя устройствами появилась в Android 4.0. Называлась эта технология Wi-Fi P2P, взаимодействие осуществлялось через Wi-Fi. Потом появился Network Service Security. В нем использовались Multicast DNS и DNS-SD. Технология позволяла избегать взаимодействия на низком уровне, но были проблемы с необходимостью поддержки постоянного подключения.

Nearby — библиотека в составе Google Play Services, решающая проблему взаимодействия довольно-таки интересными способами. Сама библиотека состоит из двух частей:

1. Nearby Connections API. Оно появилось в начале 2015 года и позволяет устройствам соединяться по локальной сети. Например, для совместного редактирования файлов, для игр по локальной сети, либо для игр на нескольких экранах, когда одно устройство используется для управления, а второе — для отображения самой игры.

   Существует два вида устройств — хосты и клиенты. На одном устройстве мы создаем сервер, а другие подключаются как клиенты.

   После установки соединения с помощью Connection API появляется возможность отправлять сообщения. Они бывают двух видов:

   • Сообщения с гарантированной доставкой. Их пересылка занимает больше времени, поэтому целесообразно использовать их только тогда, когда нельзя допустить потерю данных.
   • Сообщения без гарантированной доставки. Их хорошо применять при стриминге аудио\видео.
   
   Плюсы этой технологии:
   • Возможность обеспечить хороший UX.
   • Не требуется подключение к интернету.
   • Низкая задержка.
   • Большое количество поддерживаемых устройств.
   • Простота интеграции.
   • Поддержка reliable- и unreliable-сообщений.
   • Возможность одновременно быть и сервером, и клиентом.
   • Возможность подключения нескольких клиентов.
   
   Недостатки:
   • Устройства должны быть в одной локальной сети.
   • Нужно учитывать, что устройства могут находиться достаточно далеко (главное, чтобы находились в одной локальной сети).
   • Возможность перехвата данных в незащищенных сетях.
2. Nearby Messages API. Технология появилась в сентябре 2015 года. Это еще один способ решить проблему передачи информации между устройствами с помощью отправки широковещательных сообщений на короткое расстояние.

   Главный минус технологии: данные идут не от устройства к устройству, а через облачный сервис Google. Сначала идет запрос к облаку на получение токена, далее с его помощью данные отправляются в облако, а затем другим устройствам, находящимся в 3-5 метрах от отправляющего устройства, отправляется широковещательный запрос. Токен передается через Bluetooth, Wi-Fi или ультразвуком. На последнем автор заострил внимание. Передача токена ультразвуком — ключевая особенность этой библиотеки. Звук не слышим для людей и большинство устройств поддерживают эту технологию. Данные отправляются циклично с периодом в 3 секунды и паузой в 1 секунду между циклами.

   Рекомендации по использованию:

   • Не передавать ничего секретного, даже в зашифрованном виде.
   • Давать пользователю четко понять, что он отправляет.
   • Добавлять явную кнопку включения/отключения Nearby.
   • Необходимо учитывать, что использование этой технологии очень сильно уменьшает заряд аккумулятора.
   • Использовать новую систему разрешений.
   
   Главным минусом технологии является малый размер сообщения — три килобайта.

Clean Architecture и MVP

C помощью логической разбивки кода на своеобразные слои уменьшается перегруженность activity и фрагментами. Также решается проблема переиспользования кода из-за сильной зависимости. Сам паттерн предполагает разбивку всего приложения на три модуля, которые слабо связаны между собой:

1. Model — тут хранится логика получения данных.
2. View — реализует логику отображения данных.
3. Presenter — этот модуль управляет всеми процессами, связанными с получением, обработкой и отображением данных. Хорошей практикой является внедрять их в view через Dependency Injection.

Плюсы использования этого паттерна:

• Модульность.
• Простота тестирования.
• Слабая связанность.
• Легкое распределение труда при разработке.
• Легкое переиспользование кода.
• Можно дополнительно использовать многие другие паттерны.

Автор в ходе доклада подчеркнул, что паттерн MVP все понимают по-разному.

#Beyond Install. User Acquisition & App re-engagement @Twitter

В этом докладе обсуждалась целесообразность и влияние добавления в своё приложение социальных сетей в целом и Twitter в частности. Допустим, у нас есть игра, в которой мы можем достигнуть какого-то уровня. Если дать пользователю возможность опубликовать своё достижение в Twitter, то его подписчики увидят твит вроде «Я набрал 500 очков в #игре такой-то». Можно еще добавить картинку, чтобы подписчики с большей вероятностью обратили на этот твит внимание.

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

Еще на докладе рассказывали про платные возможности Twitter как платформы для фичеринга своего приложения. Проблема в том, что пользователь с большой вероятностью узнает о вашем приложении из твита другого пользователя, а не из рекламы. И, соответственно, с большей вероятностью его установит. Поэтому, благодаря продуманной системе поощрений и UX, можно получить достаточно хорошую раскрутку вашего приложения без особых усилий.

Facebook для Android: Разработка мобильных приложений для медленных и перегруженных сетей

Автор доклада не углублялся в тонкости реализации, скорее подчеркивал, что их клиент хорошо работает в медленных сетях. Для этого они:

• Хорошо продумали процесс запуска и отмены выполнения запроса.
• Используют прогрессивную развертку изображений (визуально кажется, что картинка загружается быстрее).
• Пытаются предугадать действия пользователя и подгружают данные заранее.

Большое внимание уделялось тестированию приложений. Из ключевых особенностей запомнилось, что они отправляли разработчиков и тестировщиков в различные страны, где те должны были пообщаться с пользователями на тему UX, чтобы сделать приложение лучше.

В ходе этих поездок было выяснено, как целевая аудитория той или иной страны пользуется приложением, и на основе этих данных приложение было доработано.
Было рассказано об интересном подходе к исправлению багов и крешей. В Facebook собрали статистику по всем устройствам на Android (которых более 20 тысяч) и сделали вывод, что при разработке зачастую нет необходимости иметь все устройства. Они поделили все устройства на 4 основные группы по году выпуска и начинке устройства. Причем телефон, вышедший в 2015 году, мог с легкостью попасть в группу 2013 года из-за того, что впервые устройство с похожими характеристиками появилось в 2013 году. Из всего этого был сделан вывод: каждому разработчику достаточно выдать 4 устройства, на которых и для которых он может разрабатывать. Предполагается, что если на телефоне, выпущенном в 2013 году, приложение работает нормально, то и на всех устройствах из этой группы оно также должно работать.

Использование низкоуровневых мультимедиа API в Android

Разработчик официального мобильного клиента ВКонтакте рассказывал о том, какие сейчас есть проблемы при использовании текущего API, и как их решать:

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

Такие проблемы есть при воспроизведении и аудио, и видео.

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

Недавно Google представил ExoPlayer — фреймворк для работы с медиафайлами. Для аудио в нем есть три уровня:

1. MediaExtractor — занимается сетью, буферизацией и разделением.
2. MediaCodec — распаковка медиа.
3. AudioTrack — выведение.

ВКонтакте реализовали свой MediaExtractor, который также позволяет кэшировать данные. Кастомизация позволяет:

• Использовать OkHTTP как средство взаимодействия с сетью.
• Реализовать возможность докачки.
• Прогнозировать буферизацию.
• Переполучать ссылки при смене IP.

Раньше с видео было всё очень плохо, особенно если нужно было воспроизводить файлы с неподдерживаемыми из коробки кодеками. С выходом ExoPlayer ситуация немного улучшилась? опять же, из-за возможности кастомизации MediaExctractor. Теперь ВКонтакте могут уменьшать размер видео с помощью изменения разрешения. Это может пригодиться, например, при загрузке видео, для которого качество не играет значительной роли.

Learn to accelerate — hardware acceleration in Android

Израильский разработчик Royi Benyossef рассказывал о hardware acceleration в Android.

Что нам это дает:

• Большие возможности по реализации интерфейса.
• Более плавная анимация.
• Уменьшение нагрузки на RAM и CPU.

Hardware acceleration для отрисовки и расчетов использует GPU, который значительно быстрее связки CPU и RAM. За счет этого мы получаем бо̒льшую производительность, чем при использовании software acceleration.

Для разработчиков Hardware acceleration впервые стала доступна с 11 версии API. Начиная с 14 версии она по умолчанию включена для всех компонент.

При разработке необходимо:

• Уменьшать количество view. Чем их меньше, тем меньше слоев нужно обновлять.
• Использовать превьюшки изображений. Не нужно отрисовывать изображение, размер которого в разы превышает размер экрана.
• Управлять совмещением и удалением слоев.
• Следить за прозрачными пикселями в картинках.
• Никогда не создавать объекты в методе onDraw().
• Избегать изменений объектов. Например, каждое изменение bitmap влечет за собой перезагрузку ее в GPU.
• Будьте осторожны при использовании прозрачности. Нужно убедиться, что все view рендерятся на hardware.

В заключение доклада было сказано следующее:

• Использование Hardware acceleration не всегда оправдано.
• Cоздавайте только то, что вам действительно нужно, и избегайте создания в методах отрисовки.
• Анализируйте и адаптируйте свои кастомные view.

Каким должно быть приложение, чтобы претендовать на фичеринг в Google Play

Здесь было рассказано об опыте фичеренга для приложения Chaos Control. В Google Play во всех категориях есть всякого рода топы, рекомендации, тематические подборки. У разработчика может быть иконка «Топ разработчик».

Как приложения попадают во все эти рейтинги? Все очень просто. Для того, чтобы туда попасть, необходимо:

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

У самого фичеринга есть несколько этапов:

1. Номинация приложения на фичеринг кем-то из сотрудников Google, занимающихся работой с сообществом разработчиков.
2. Прохождение приложением Quality Review.
3. Внесение изменений в приложение и его метаданные в Google Play по результатам прохождения Quality Review.
4. Повторное ревью и фичеринг, если все замечания устранены.

В реальности это происходит так: каким-то образом сотрудник компании Google узнает о вашем приложении, допустим, услышал на какой-то из конференций, либо сам нашел в Google Play. Далее он номинирует его на фичеринг внутри компании Google. Собираются ревьюеры и оценивают ваше приложение по следующим критериям:

• Функциональность и востребованность.
• Дизайн.
• Использование последних фишек Android SDK.
• Поддержка максимального количества устройств. Особое внимание планшетам и носимым устройствам.
• Метаданные в описании Google Play: картинки, описание, локализации.

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

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

Но не стоит надеяться на то, что вы напишете отличное приложение, соблюдая все best practices, и гарантировано получите фичеринг. Приложение должно расти и развиваться без надежды на это. Фичеринг можно воспринимать только как дополнительную раскрутку, а не как основную, ведь при номинации на фичеринг могут сыграть свою роль даже комментарии и оценки пользователей.

Honey-Money(6.0): Android как идеальная экосистема для корпоративных мобильных приложений

Корпоративные приложения — это те, что написаны для уменьшения или оптимизации затрат в какой-то компании. Такое приложение не обязательно должно быть в общем доступе.

Допустим у нас есть компания по ремонту автозаправок. Есть мастера, которые их ремонтируют, и есть операторы, которые принимают заявки на ремонт. С помощью простого приложения можно:

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

Благодаря всему этому можно сэкономить на:

• Простое мастеров.
• Коммуникации между мастерами и операторами.
• Потерях времени при неправильно составленных маршрутах.
• Превентивном расширении или уменьшении штата мастеров на основе статистики поломок в том или ином регионе.
• Внедрении онлайн-заявок на ремонт.

При написании такого приложения необходимо четко соблюдать следующие правила:

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

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

Заключение

В заключении хотелось бы отметить полезность такого рода мероприятий. Благодаря конференции мы обогатились знаниями о том, как устроен процесс разработки в других компаниях, какие технологии они используют, на какие грабли наступили, каких успехов они достигли. Также мы узнали, как те или иные команды разработчиков организовывают свою работу. Подобная информация помогает в будущих проектах, ведь лучше учиться на чужих ошибках. Благодаря разнообразию материалов и мастерству докладчиков, конференция мотивировала к обучению, что тоже немаловажно.

© Habrahabr.ru