Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 47738 сообщений
Cообщения с меткой

android - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] AndroidAudit. Ваше Android-приложение как место преступления

Понедельник, 27 Июня 2016 г. 14:31 (ссылка)





От переводчика: оценка процесса и результата разработки — достаточно субъективная вещь, если не используется какая-либо мера весов. Можно долго спорить: табы или пробелы, git или mercurial, maven или gradle, но такие споры все равно скатываются к вкусовщине и каким-то частным случаям. Другое дело — соблюдение однородности проекта, вот это уже вполне себе измеримая величина.

Плохая методология лучше её отсутствия.
Помимо общих вещей, найдутся и специфические, присуще только мобильной разработке, только под Android. Pedro Vicente G'omez S'anchez из Karumi в своей работе разобрал по косточкам основные технические области и задал меткие вопросы для правильной, объективной оценки разработки для платформы Android. Если появится задача: оценить чужой проект, то рекомендую воспользоваться его методологией. Я воспользовался этой методологией, как чек листом. На выходе получился вполне понятный не профессионалу документ, где напротив каждой категории — конкретная величина соответствия правильности от 0 до 1.





Технический аудит iOS и Android приложений стал неотъемлемой частью нашей повседневной работы в Karumi. Хоть это и выглядит просто, имеется немало деталей реализации такой проверки, которые стоит рассмотреть. В этом документе мы рассмотрим то, что мы считаем наиболее важным при проведении аудита и разделим это по техническим областям.



Система контроля версий



Используется ли система контроля версий, какая система и как организованы рабочие процессы — это многое расскажет о процессе разработки.


  • Есть ли у вас правильно настроенный *ignore файл, чтобы файлы метаданных IDE и другие посторонние элементы не попадали в хранилище?


  • Сторонние библиотеки сконфигурированы в качестве внешних зависимостей или лежат в хранилище?


  • Достаточно ли краткие и выразительные комментарии к коммитам (commits) вы используете?


  • Является ли размер ваших коммитов обоснованным?


  • Все ли файлы в коммите связаны с одной и той же проблемой или функциональностью?


  • Используете ли вы какие-либо схемы ветвления типа "feature branch" или "git-flow"?


  • Достаточно ли информативны названия веток?


  • Используете ли вы систему pull request/code review до слияния кода в master?


    • Есть ли у вас какой-либо регламент относительно того, на что нужно обращать внимание при рассмотрении PR (pull request)?


    • Сколько комментариев в среднем приходится на каждый PR?


    • Сколько людей рассматривает каждый PR?


    • Сколько "+1" к PR вам нужно для слияния?


    • Кто несет ответственность за закрытие ветки?




  • Вы используете release branches для каждого релиза?


  • Как долго открыт процесс подготовки (staging process)?


  • Сколько исправлений вы вносите в release candidate, прежде чем выпустить его?


  • Имеется ли возможность переключиться на точный код какой-либо из опубликованных версий вашего приложения?


  • Сколько исправлений (hotfix) вы выпустили в прошлом году?


  • Вы объединяете (squash) коммиты до слияния (merging) его в master/develop ветку?


  • Готовы ли master/develop ветки к выпуску в любое время?





Инструменты сборки



Определяющим фактором является возможность запустить процесс сборки на машине разработчика и на любой другой внешней системе, например на системе непрерывной сборки (continuous integration).


  • Сколько библиотек используются в проекте?


  • Разделен ли проект на модули?


  • Используют ли модули Maven или Gradle для разрешения зависимостей, или используются локальные .jar-файлы?


  • На опасное ли расстояние приближен проект к лимиту количества методов в .dex файлах? Или уже за гранью?


  • Вы используете библиотеки, которые не нужны в проекте?


  • Используется ли multidex?


  • Все ли внешние зависимости обновлены до современных версий?


  • Все ли лицензии сторонних библиотек соблюдены?


  • Используются ли устаревшие или не поддерживаемые сторонние библиотеки?


  • Обусловлен ли минимальный SDK требованиями технического задания (product description)?


  • Актуален ли целевой SDK (target SDK)?


  • Используется ли ProGuard или любой другой инструмент обфускации (obfuscation — запутывание)? Он включен и правильно настроен?


  • Учетные данные хранилища ключей (keystore credentials) и учетные данные Google Play хранятся в надежном месте?


  • Хранилище ключей приложения (application keystore) и учетные данные хранятся в надежном месте?


  • Должным ли образом настроены build types?


  • Правильно ли используются flavors?


  • Правильно ли настроен релизный тип сборки?


  • Включена ли опция резервного копирования?


  • Включен ли Lint? Он успешно проходит проверку?


  • Имеется ли инструмент статического анализа? Он настроен и успешно проходит проверку?


  • Есть ли Checkstyle? Он настроен и успешно проходит проверку?


  • Правильно ли настроен id приложения и version name/code?


  • Вы используете какую-либо структуру или стратегию версионирования id?


  • Используется ли инструмент непрерывной сборки (continous integration), правильно ли он настроен?


  • Автоматизирован ли процесс выпуска новых версий?





Использование Android ресурсов



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


  • Существуют ли какие-либо недостающие ресурсы для densities, flavors и build types?


  • Требуется ли поддержка приложением экранов с различной плотностью пикселей (density) по техническому заданию?


  • Используются ли в приложении drawable/mipmap, шрифты или векторные ресурсы?


  • Существуют ли какие-либо недостающие переводы?


  • Автоматизирован ли процесс перевода?


  • Какой язык выбран по умолчанию для перевода?


  • Использует ли приложение сторонние шрифты?


  • Использует ли приложение значения конфигурации внутри файла строковых ресурсов?


  • Соблюдается ли соглашение для присвоения однородных имен ресурсам?


  • Есть ли параметры конфигурации, связанные с аппаратными средствами устройства, правильно ли они настроены?


  • Поддерживаются ли планшеты?





Использование Android Layout



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


  • Возникают ли проблемы с производительностью из-за количество слоев в макетах (layouts) приложения?


  • Используете ли вы темы и стили?


  • Используются ли повторно макеты (layouts) с использованием "include" тега?


  • Вы используете правильный тип группировок в макетах?


  • Учтены ли различные размеры экранов в макетах?


  • Используется ли какое-либо соглашение об именовании, чтобы присваиваемые имена макетам и виджетам оставались однородными?


  • Списки реализованы с использованием ListView или RecyclerView?


  • Правильно ли используется Android Support Library?





Права доступа



Запрос возможных действий приложения (permissions) увеличивает доверие пользователей к нему, а также расширяет его возможности за счет "прозрачной" интеграции с другими сервисами.


  • Все ли запрашиваемые разрешения (permissions) действительно необходимы?


  • Разрешение используется намеренно?


  • Есть ли отсутствующие разрешения?


  • Если целевой SDK больше, чем 23, то "опасные разрешения" запрашиваются с помощью системы разрешений совместимости (compatibility permissions system)?


  • Разрешение запрашиваются тогда, когда они будут использоваться?


  • Есть ли обратная связь с пользователем, объясняющая, почему какое-либо разрешение необходимо?





Проблемы с безопасностью



Как разработчики, мы должны сознательно относиться к безопасности наших приложений. Мы не хотим, чтобы данные наших пользователей "утекли" или их сессии были украдены.


  • Настроен ли HTTP клиент на использование HTTPS?


  • Настроен ли HTTP клиент на использование встроенного сертификата (certificate pinning) и сообщений аутентификации с HMAC?


  • Сохраняет ли приложение конфиденциальную информацию пользователя? Где?


  • Сохраняет ли приложение информацию вне внутренней системы хранения данных?


  • Логируется (logging traces) ли приложение при сборке релиза?


  • Обфусцирован (obfuscated) ли код приложения?


  • Предоставляет ли ваше приложение поставщика контента (Android content provider), приемника (receiver) или сервис другим приложениям?


  • Отключена ли опция "debuggable" в релизной сборке?





Push уведомления (Push Notifications)



Push — это отличный механизм для информирования наших пользователей в любое время, но это более сложная проблема, чем кажется на первый взгляд.


  • Используется ли сторонняя библиотека для реализации системы Push-уведомлений?


  • Используется ли система GCM для передачи информации приложению, или просто, чтобы показывать сообщения пользователю?


  • Как ведет себя приложение при получении Push-уведомления?


  • Как ведет себя приложение, когда связанная с Push-уведомлением информация не та, что ожидалась?


  • Показываются ли уведомления с использованием API совместимости (compatibility API)?





Производительность



Производительность имеет большое значение. Никто не захочет использовать на своих дорогих устройствах медленное приложение. Производительность — это деньги.


  • Есть ли в приложении какие-либо утечки памяти?


  • Настроен ли в develop сборке какой-либо анализатор памяти, как, например, "LeakCanary"?


  • Android Strict Mode подключен и настроен в develop сборке?


  • Как в приложении используются потоки? Вы используете async tasks, intent services или любые другие сторонние библиотеки?


  • Вызывает ли количество фоновых потоков проблемы с производительностью?


  • Используете ли вы какие-либо политики планировщика (scheduler policy) или просто создаются потоки по требованию?


  • Поддерживаете ли вы Android Doze Mode?


  • Прослушиваются ли события, связанные с состоянием сети или любого другого повторяющегося события от операционной системы?


  • Основной поток используется только для выполнения задач, связанных с кодом пользовательского интерфейса?


  • Имеются ли в приложении какие-либо политики кеширования?


  • Настроен ли клиент HTTP на использование тайм-аута?


  • Настроен ли клиент HTTP на использование GZIP?


  • Работает ли пользовательский интерфейс приложения со скоростью 60 кадров в секунду?


  • Нет ли таких custom view, для которых выделяется слишком большой объем памяти, или которые выполняют "дорогостоящие" задачи в потоке пользовательского интерфейса (UI thread)?


  • Вы тестируете ваше приложение на lower-end (бюджетных, непроизводительных) устройствах?


  • Не "тормозит" ли прокрутка recycler view?


  • Для загрузки изображений используется какая-либо сторонняя библиотека или у вас есть своё собственное решение?


  • Изображения масштабируются под размеры экрана или сразу загружаются под определенный экран устройства?


  • Разумно ли использование памяти?


  • Правильно ли используется модификатор "Static" в Java?


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


  • Работает ли система статистики в фоновом потоке и сконфигурирована ли она с правильным приоритетом?


  • Оптимизируется ли код в релизной сборке?





Структура Java Packages



Хорошая структура пакетов сделает наш код более масштабируемым.


  • Используются ли пакеты для разделения кода по функционалу (features) или концепциям (например, Login vs User)?


  • Используются ли модификаторы видимости Java, чтобы скрыть детали реализации внутри пакетов?


  • Все ли пакеты выходят из корневого пакета?


  • Повторяет ли директория с тестами структуру исходной папки?


  • Организованы ли различные функции (features) с помощью одной и той же структуры пакетов?


  • В правильных ли пакетах лежат классы?


  • Соблюдаются ли соглашения об однородном названии пакетов?


  • Связано ли название корневого пакета с именем компании?





Code Style



Согласованная с точки зрения стиля кодовая база помогает нашим инженерам читать код проще. Инженер читает ГОРАЗДО больше кода, чем пишет, так что это важное понятие.


  • Является ли codestyle однородным?


  • Используете ли вы венгерскую нотацию?


  • Есть ли какой-либо инструмент Checkstyle? Он настроен и работает?


  • Соответствует ли код Java codestyle?


  • Вы используете табуляцию или пробелы?


  • Правильно ли названы классы?


  • Используете ли вы "I" в качестве префикса интерфейсов или "Impl" как суффиксы реализации?


  • Используете ли вы правильные имена переменных?


  • Используете ли вы правильные имена для полей (fields)?


  • Используете ли вы правильные имена для методов?


  • Используются ли атрибуты и модификаторы видимости методов должным образом?


  • Код написан на английском языке?


  • Используете ли вы Javadoc?


  • Вы пишете комментарии к коду?


  • Используете ли вы константы или перечисления (enums), чтобы избежать дублирования литералов?





Offline реализация



Обеспечение хорошей работы в режиме offline является отличительным фактором наших приложений.


  • Может ли приложение использоваться, когда нет подключения к сети Интернет?


  • Каково поведение приложения при медленном сетевом соединении?


  • Какое поведение приложения при потере запроса из-за сбоя в сети?


  • Синхронизируются ли изменения данных приложения с бекэндом после того как соединение было восстановлено?


  • Настроен ли тайм-аут на сетевое соединение?


  • Настроена ли политика кеширования HTTP?


  • Сеанс пользователя восстанавливается автоматически?





Архитектура



Архитектура приложений, с точки зрения кода, является одной из частей аудита, которая дает нам более глубокое представление о приложении. В ходе обзора архитектуры приложения мы будем сосредоточены на понятиях, связанных с S.O.L.I.D и Clean Code принципами.



Реализация слоя представления (Presentation Layer Implementation)


  • Используется ли какой-либо паттерн, связанный с реализацией GUI (графического интерфейса пользователя)? Model View Presenter или Model View ViewModel два из наиболее часто используемых шаблонов для разработки приложений. Правильно ли они реализованы?


  • Связана ли реализация слоя представления (presentation layer) с реализацией вида (view implementation)?


  • Связана ли реализация вида (view implementation) c реализацией модели (model implementation)?


  • Включает ли слой представления бизнес-логику?


  • Правильно ли реализация вида использует Android SDK tools?


  • Используете ли вы сторонние библиотеки для упрощения реализации вида?


  • Разделена ли реализация разных функций по отдельным activities или fragments?


  • Однородно ли поведение пользовательского интерфейса?


  • Используете ли вы custom views для повторного использования кода пользовательского интерфейса?





Реализация предметной области (Domain Implementation)


  • Есть ли отдельный слой предметной области (domain layer) или вся бизнес-логика реализована в слое представления (presentation layer)?


  • Выражены ли правила предметной области и различные требования к приложению в основных объектах бизнес-логики?


  • Реализован ли слой предметной области с применением принципов ООП?


  • Связан ли слой предметной области с Android SDK или любой сторонней библиотекой?


  • Связан ли слой предметной области со слоем представления?


  • Является ли модель предметной области (domain model) "анемичной"?


  • Используете ли вы "толстые" модели предметной области?


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


  • Реализована ли обработка ошибок с использованием исключений или какого-либо другого механизма обработки ошибок?


  • Сопоставляются ли данные (mapped) между различными слоями?


  • Влияет ли архитектура внешних компонентов (например, схемы базы данных или парсинга JSON) на архитектуру модели предметной области?


  • Разработчики злоупотребляют наследованием?


  • Дублируется ли код?


  • Есть ли dependency injection библиотеки или сконфигурированный service locator?


  • Не слишком ли высока сложность классов и методов?





Реализация API


  • Привязана ли реализация API к Android SDK?


  • Происходит ли "утечка" через API каких-либо деталей реализации из-за клиента HTTP или используемой библиотекой для реализации сетевого слоя?


  • API клиент посылает правильные заголовки?


  • Каково поведение API клиента для различных ответов HTTP?


  • API клиента реализует механизм аутентификации?


  • Правильно ли реализован процесс возобновления сеанса?


  • Есть ли поддержка обфускации JSON?


  • Разделена ли реализация API для различных клиентов?





Реализация Хранения


  • Где хранится информация?


  • Используются ли транзакции при чтении и записи информации в хранилище?


  • Надежно ли хранение конфиденциальной информации пользователя?


  • Использует ли слой хранения какие-либо сторонние библиотеки?


  • "Утекают" ли детали реализации через слой хранения?


  • Правильно ли спроектированы tables/schemas?


  • Запросы, отправленные в хранилище, оптимизированы?


  • Используются ли Android SDK APIs для хранения данных в правильном месте? Сохраняются ли данные в базу данных, а настройки (preferences) и небольшие по объему данные в Shared Preferences и файлы на диске?





Тестируемость


  • Есть ли у приложения тесты?


  • Является ли приложение тестируемым?


  • В приложении используются различные виды (unit/integration/end-to-end) тестов?


  • Правильно ли названы тесты?


  • Достаточно ли тесты охватывают проект?


  • Есть ли чрезмерное документирование (overspecification) в тестах?


  • Время выполнения разумно?


  • Не слишком ли низко покрытие кода?


  • Существуют ли какие-либо игнорируемые тесты?


  • Есть ли нестабильные тесты (flaky tests)?


  • Используете ли вы современные фреймворки для тестирования?


  • Существуют ли какие-либо тесты без утверждений (tests without asserts)?


  • Тесты и продакшен код написаны одними и теми же разработчиками?


  • У вас есть команда QA?


  • У вас есть команда QA, автоматизирующая часть тестов?


  • Есть ли у вас какие-либо системы непрерывной интеграции (continuous integration system)?


  • Используете ли вы builders, factories или mothers, чтобы уменьшить затраты на создание некоторых объектов, которые необходимы для тестов?


  • Тесты утверждений (assertions) правильно написаны?


  • Проводите ли вы более одного логического утверждения на тест?


  • У вас есть различные наборы тестов, связанные с одним и тем же проектом?


  • Вы используете различные подходы тестирования для различных частей приложения?


  • Используете ли вы какой-либо monkeyrunner?


  • Следуете ли вы какой-либо TDD или BDD методологии?


  • Используете ли вы Java, чтобы написать тестовые варианты (test cases)?





На основании этого списка, связанного с различными техническими областями, мы можем оценить качество приложения. Есть и другие моменты, которые мы также рассматриваем, но этот список содержит наиболее важные из них. Вы можете дать корректные ответы на все эти вопросы о вашем приложении?



Автор: Pedro Vicente G'omez S'anchez.

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

Спасибо за помощь в переводе и вдумчивую вычитку Кочкиной Яне, Заостровскому Роману (@firsto), Полежаеву Максиму (@itsme_42).

Отдельное спасибо за обе КДПВ, которых не было в оригинальной статье, Кочкиной Яне.



Альтернативная КДПВ
В память, о некогда очень популярной библиотеке от JakeWharton.





Кстати, если ActionBarSherlock живет в вашем проекте и по ныне, то рекомендую подумать об освежении проекта.


Original source: habrahabr.ru.

https://habrahabr.ru/post/304208/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Почему за GraphQL будущее

Понедельник, 27 Июня 2016 г. 12:48 (ссылка)

И что это значит лично для вас



Вы наверняка уже слышали про GraphQL, среду выполнения и язык запросов данных с открытым кодом. Про него много говорят в последнее время – в частности, на конференции React Europe, недавно проходившей в Париже, было сделано три выступления про GraphQL. И прочитав этот пост, вы узнаете, почему.



1. Вы уже его используете



Даже если вы впервые слышите о GraphQL, вам интересно будет узнать, что вы пользуетесь им ежедневно последние несколько лет. У Facebook есть миллиард ежедневных активных пользователей, и GraphQL лежит в основе работы соцсети. Если вы используете Facebook, вы используете и GraphQL.



Facebook используют GraphQL с 2012 года – задолго до того, как его код был открыт в прошлом июле. С тех пор наблюдается шквал активности по его поводу, а экосистема вокруг его открытого кода быстро растёт.



2. GraphQL решает реальные задачи, и это заметно



Существование GraphQL радует не только разработчиков на React. Работающие с Angular, iOS и Android также интересуются тем, что GraphQL может им предложить. Причина роста популярности GraphQL в том, что он решает некоторые вполне реальные задачи, с которыми разработчики борются каждый день. Именно поэтому его уже адаптируют такие компании, как Twitter, Intuit и Drupal.



Платформа мобильной разработки Fabric от Twitter уже сделала анонс переходна на GraphQL:

How we productionized GraphQL.js while protecting customer data & site uptime https://t.co/TaTuKVlWAO @GraphQL pic.twitter.com/Goj42tT2ct

— Fabric (@fabric) 7 июня 2016 г.





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



Это совершенно разные компании, и объединяет их один или несколько из следующих пунктов:


  • у них более одного программного клиента (например, веб и iOS);

  • у них есть мобильный клиент, и они заботятся о скорости отклика и потреблении трафика;

  • они переходят на архитектуру микросервисов;

  • их REST API стал таким сложным, что это замедляет разработку;

  • они хотят рассоединить фронтенды и бэкенды для ускорения разработки.





Компании выбирают GraphQL, потому что начинают понимать, что он сможет помочь им в решении задач, в отличие от REST. О чём и следующий пункт:



3. REST вам не поможет



Вот вкратце отличие REST от GraphQL:





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



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



Если не верите мне, спросите этих людей:





Можно найти гораздо больше примеров, если поискать. Twitter, Intuit и Drupal – это только начало (а в случае с Drupal, их модуль для GraphQL – это только начало). Я мог бы назвать имена десятка известных компаний, которые просто ещё не объявили публично о переходе на GraphQL. Сомнений нет, за GraphQL будущее.



Вы, наверно, думаете: «Ну классно, а мне-то что с этого?»



4. GraphQL порадует разработчиков



GraphQL привносит порядок в хаос:


  • это чёткий и ясный API между бэкендом и фронтендом;

  • уменьшая затраты на коммуникации, меньше соединений;

  • не надо писать документацию для API;

  • не надо придумывать API;

  • это отличный инструмент для вашего API.





При помощи GraphQL новый программист за пять минут поймёт, как работать с вашим API. Это включая время, необходимое для того, чтобы разобраться, как писать простые запросы на GraphQL.



Так что, будь вы разработчиком на React, Angular, Ember, iOS или Android, потратьте немного времени для изучения GraphQL, используйте его в своём новом проекте и попробуйте склонить к его использованию в компании коллег или босса. Вы не пожалеете.



И вы не одиноки! Множество разработчиков только сейчас узнают о GraphQL, и находят вдобавок очень дружественное сообщество, готовое оказать поддержку новичкам. Некоторые сидят в канале Slack, другие присоединяются к активной группе пользователей в Apollo и GraphQL GitHub.



Если же вы наткнётесь на группу поддержки REST или профессионального ворчуна, помните:

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

— Макс Планк

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304182/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Дайджест интересных материалов для мобильного разработчика #159 (20-26 июня)

Воскресенье, 26 Июня 2016 г. 15:13 (ссылка)

Мы продолжаем разбираться с «последствиями» WWDC, разбираем новые примеры кроссплатформенной разработки, выясняем какие ролики самые эффективные для продвижения приложений в разных категориях и поднимаем грабли hardware-стартапа. Добро пожаловать в новый дайджест!












Уведомления в iOS 10

Говорят, что на этом WWDC не было ничего интересного, кроме интерактивных уведомлений. Действительно, новые уведомления одна из самых интересных новых фич. Не только для разработчиков, но и для простых пользователей. В iOS 10 попытались унифицировать работу с локальными и пуш-уведомлениями и добавили для этого новый фреймворк UserNotifications.framework.




Создаем приложение на JavaScript с помощью React Native

В этом уроке мы будем изучать React Native – фреймворк от компании Facebook для создания нативных приложений под iOS и Android. У него много общего с другим очень популярным фреймворком от Facebook – React Javascript, который предназначен для построения декларативных пользовательских интерфейсов.




Грязные трюки мобильной разработки от J2ME до Android

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



iOS



Android



Разработка



Аналитика, маркетинг и монетизация





Устройства и IoT





<- Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку — пришлите, пожалуйста, в почту.
Original source: habrahabr.ru.

https://habrahabr.ru/post/304136/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

3DO и Android NDK и как бы во что не вляпаться…

Среда, 22 Июня 2016 г. 23:35 (ссылка)

image



Найдется наверное не мало приложений, которые почти невозможно сделать на Java, в силу большой исходной кодовой базы C++ или требований к производительности. И так вышло, что я разрабатывал одно из таких приложений, а именно эмулятор игровой консоли 3DO – Real3DOPlayer. В моем случае роль играла как кодовая база, так и требования к производительности. Код базировался на моем десктопном проекте «Феникс», и он тормозил даже на средних десктопах, не то, что на встраиваемых процессорах. Сколько проклятий вырывалось в адрес корпорации Gooogle я уже и не помню, но опыт я получил бесценный, которым и хочу здесь поделиться.





Новичок, бьющийся лбом об стену...



Gex



Несмотря на то, что я опытный программист (больше 15 лет), я почувствовал себя в шкуре новичка сразу же, как только взялся за NDK.



Шишка первая. Установив Android Studio под Windows я решил набросать простейший «Hello, world!» с вызовом JNI. Все очень просто:



JNIEXPORT jstring JNICALL Java_ru_arts_union_real3doplayer_NativeCore_stringFromJNI(JNIEnv* env, jclass clazz)
{
return env->NewStringUTF("Hello, World!");
}




Ошибка компиляции. Просто ошибка компиляции. Понимаете, код не компилируется и точка. День я пытался скомпилировать код, активно гугля проблему, но по истечению дня код так и не удалось собрать. На следующий день взял ноутбук с Linux и решил продолжить мучать эти две строчки, к моему удивлению все сразу же собралось. Начал читать форумы, почему под Windows нельзя собрать код? Оказалось — одного файла C/CPP мало для для сборки проекта, требуется как минимум 2!



Шишка вторая. Запускаю приложение, а оно падает, сообщая, что метод stringFromJNI не найден. Как так не найден?! Вот же он, прямо тут и в дизассемблере виден! Не паниковать, смотрю весь код от и до, слава богу, его не так уж много. Смотрю на префикс в названии функции ru_arts_union_real3doplayer и что-то мне подсказывает, что что-то здесь не так… Ведь имя моего пакета выглядело, так: ru.arts-union.real3doplayer, а имя метода кодирует точку и тире одинаково, это не хорошо, и странно, что сама среда допустила такое имя для пакета. Меняем имя пакета и метода, убрав тире. Ура! Метод видится, и спустя два дня работает «Hello, world!».



Шишка третья. Не беда, файлов будет много, название поправили, едем дальше, думая что самое страшное позади. Добавляем свои исходники, которые проверялись под Linux/Windows для различных процессоров (в том числе ARM). Все отлично скомпилировалось, без единой ошибки. Приложение падает при старте без каких-либо предупреждений. Продолжая мидитировать над кодом, наблюдаю проплывающую строчку с long double, вспоминаю, что NEON максимум держит double, но этот код даже не вызывается, он просто есть, а в заголовке типов я удалил real80. И потом, код ведь скомпилировался без ошибок! Хм.., чем стучать в бубен, лучше выпилю этот код… Запуск, и бинго! Код работает, игры заускаются, хоть и с дикими тормозами!



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



Чем меньше у вас опыта, тем больше у вас будет шишек — будьте морально готовы, наверняка я не все припомнил…



В погоне за производительностью или вляпался раз...



BC Racers



Как увеличить производительность эмулятора, который местами напрягал даже i7? Очень просто, нужно ограничить себя вычислительным ресурсом, что и произошло с попыткой портировать его на Андроид.



В такой непростой ситуации пришлось реализовать кеширование текстур с предварительно частично или полностью обработанными пикселями графическим процессором приставки, триангуляцию квадратных полигонов (у 3DO нелинейное наложение текстур), статическую рекомпиляцию кода часто используемых библиотек ОС консоли, распараллеливание эмуляции подсистем консоли. Все это позволило снизить аппаратные требования более чем в три раза. Где еще, можно сэкономить такты, не считая классических техник, оптимизации на ассемблере и длительного просиживания в профайлере? Очевидно, на том, в чем большинство пользователей разницы не заметит. Так например я хорошо сэкономил на 16-битном растре, вместо 24-битного, при заполнении кадра.



Сам процесс оптимизации очень занятный и тянет на отдельную статью, но все вышесказанное не относится к Андроиду как к таковому. А что же может дать нам сама платформа и ее особенности? Очевидно прямую запись в текстурную память поскольку CPU и GPU на мобильных платформах в подавляющем большинстве устройств ее разделяют. Но увы, данный механизм известный как GraphicBuffer не предназначен для общего пользования! Ничего, его можно достать через dlopen. Но делать это надо опционально, поскольку этот хак может работать не везде. Реализацию можно глянуть здесь (довольно непросто найти через поиск): android.googlesource.com/platform/external/deqp/+/deqp-dev/framework/platform/android/tcuAndroidInternals.cpp.



А что нам очень не хочет давать Андроид, но очень надо? Конечно контроль над циклом приложения. Но, если ооочень надо, то поможет NativeActivity или вот этот вот примерчик, который подкупает своей простотой и удобством: github.com/tsaarni/android-native-egl-example. В отличии от NativeActivity, с которым непонятно как работать из обычного Activity, данный подход позволяет захватить контекст окна и рисовать в отдельном потоке, тогда, когда надо нам, а не когда решит Java. И вот тут-то я вляпался, сам того не зная.



Дело в том, что данный механизм работает не на всех версиях Андроида (по крайней мере по моим тестам версии 4.1-4.3 не поддерживают), а это порядка 40% целевых устройств для моего приложения судя по статистике Гугла, т. е. 40% прибыли долой. И узнать вы об этом можете очень поздно, ведь обычно пользователь поставив приложение и увидев, что оно не работает, часто сносит его и не пишет отзыва, оно и понятно, ведь надо быстрей вернуть деньги. Исправлять же неправильный цикл приложения, дело не из приятных, ведь гарантированно определить на каком устройстве он работает, а на каком нет — нельзя, ставить по умолчанию более медленное решение, но более совместимое можно, но карму вы себе попортите, ведь не каждый полезет в настройки проверять, а нельзя ли что-то подкрутить, чтобы стало как раньше и не тормозило. Лучше сразу сделать более дубовый вариант, а потом уже добавить опцию, но в моем случае уже поздно.



Сокращая сущности или вляпался два...



Bust-a-Move



Довольно часто в SDK уже есть функционал, который не хочется дублировать в нативном коде, например для работы со шрифтами или изображениями, да много чего, ведь у Java огромная библиотека. И возникает закономерное желание сделать вызов Java-метода из C++. У меня как раз такое желание возникло и я сделал классную вещь — рендер шрифтов в текстуру по запросу из нативного кода, все протестировал на своих устройствах и куче виртуальных устройств. Все отлично работало и в очередной раз вляпался — сделал релиз… У примерно 1% пользователей (уже купивших приложение) программа начала крашиться. Это было мягко говоря — очень плохо, негативные отзывы, да и сама ситуация — человек заплатил и тут бац — у него не работает. В чем причина, сказать трудно, подозреваю некоторые производители используют модифицированную ось, или что-то еще. Ошибку у себя я конечно не исключаю, но глядя на такой вот рапорт, я сильно в этом сомневаюсь (разумеется метод такой был, черным по белому):



java.lang.NoSuchMethodError: no method with name='loadConfig' signature='(Ljava/lang/String;)Ljava/lang/String;' in class Lru/vastness/altmer/real3doplayer/MainActivity;
at dalvik.system.NativeStart.run(Native Method)




Пришлось очень быстро выпиливать это решение и заменять другим. Обошлось малой кровью. Само по себе решение очень хорошее (1% несовместимости можно стерпеть, просто пройдут мимо и не купят), но только до запуска приложения, потом, когда продано уже много копий — я бы настоятельно не советовал.



Обновляя арсенал или вляпался три...



Poed



Переставив систему, я поставил SDK поневее и соответственно targetSdkVersion тоже поменял. Тут же случилась неприятность, перестали видеться SD-накопители, что вызвано странными махинациями Гугла с правами доступа. При этом попытка загрузить APK с более старой версией SDK стало не возможным! Нельзя! Но я отделался легким испугом, проблема решилась запросом разрешений. А если пробла не решилась бы так легко? Что делать тогда? Вопрос очень интересный…



Самая же неприятная вещь пришедшая с обновлениями, от которой не могу избавиться по сей день — это нежелание среды обновлять APK при изменениях в нативной библиотеке, проблему наблюдаю и под Linux и под Windows. Это вызывает раздражение, теперь чтобы на устройстве в процессе отладки появился актуальный свежесобранный APK надо проделать следующее (Android Studio 2.1.1):



1. Пересобрать проект.

2. Запустить проект (при этом он пересоберется еще раз, если первый шаг пропустить — не пересоберется).

3. Остановить приложение.

4. Собрать APK.

5. Запустить приложение.



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



Тем у кого аналагичные проблемы, в качестве компенсации времени, если этого еще не сделали, советую указать jobs N для параллельной сборки нативного кода.



В сухом остатке...



Robinsons Requiem



Я вообще в осадке от средств разработки на эту платформу, такой кривизны уже лет десять не видел, а мне есть с чем сравнивать. Я конечно понимаю — Java в приоритете, но все же… С этим всем может потягаться разве что найденный мной много лет назад баг в интеловском компиляторе при сдвиге на ноль в переменной, с тех пор нет, нет, да напишу:



	if(shift)return x>>shift;
return x;




Тем не менее стоит отдать должное Гуглу, они сделали все, чтобы зарплаты у нативных разработчиков под Андроид были высокими!



Для меня как С++ разработчика ситуация с приложениями под Андроид выглядит парадоксальным образом, с одной стороны механизмы нужные есть, но совокупный объем проблем в платформе такой, что при попытке сделать какие-либо улучшения я должен выбирать между потерей репутации и развитием приложения. Ни одна платформа не ставила меня перед таким выбором.



Невольно ловишь себя на мысли, что может лучше ничего не улучшать под эту платформу, а то как бы чего не случилось…



ПС. Не подумайте — эмулятор будет развиваться и дальше, просто накипело.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303888/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<android - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda