Комментарии 31
Кат, Карл, кат!
Об этом принято писать в личку
ох, извиняюсь :-( исправлено
del.
Выражаю благодарность DmitryO за ссылку на эту интересную статью :-)
Все неточности перевода, непонятности и пожелания прошу писать в личку, ошибки будут оперативно исправлены.
Вообще, было сложно понять, какие термины нужно перевести, а какие оставить на английском. Я старался делать примерно так, как это принято в предыдущих статьях Хабра по Android, чтобы читателям было понятнее (мне самому не очень понятно, почему «фрагменты» обычно пишут на русском, а «activity» оставляют на английском). Заранее приношу свои извинения любителям русского языка за выражения типа «релизная сборка» и «обфускировать» — увы, это специализированный технический текст и альтернативы, как правило, были не лучше. А если оставлять все эти термины на английском, как мы обычно делаем в профессиональным диалогах с коллегами, тут пол-текста будет латиницей :-)
Все неточности перевода, непонятности и пожелания прошу писать в личку, ошибки будут оперативно исправлены.
Вообще, было сложно понять, какие термины нужно перевести, а какие оставить на английском. Я старался делать примерно так, как это принято в предыдущих статьях Хабра по Android, чтобы читателям было понятнее (мне самому не очень понятно, почему «фрагменты» обычно пишут на русском, а «activity» оставляют на английском). Заранее приношу свои извинения любителям русского языка за выражения типа «релизная сборка» и «обфускировать» — увы, это специализированный технический текст и альтернативы, как правило, были не лучше. А если оставлять все эти термины на английском, как мы обычно делаем в профессиональным диалогах с коллегами, тут пол-текста будет латиницей :-)
Используйте систему сборки Gradle и стандартную структуру проектаПочему, например, не Maven?
Не пишите свой собственный HTTP-клиент, лучше используйте библиотеки Volley или OkHttpА Aquery можно?
Используйте библиотеку Jackson для парсинга данных в формате JSONНе GSON?
Не делайте слишком глубокую иерархию элементов ViewGroupСлишком много это сколько? Стоило бы пруфы привести. Например этот от автора хорошей книги по Android.
Есть два распространённых варианта: старая Ant & Eclipse ADT структура проекта — либо новая Gradle & Android Studio.Maven & Eclipse?
Всегда используйте ProGuard или DexGuardЗачем? Ужимать код? Это мелочи по сравнению с ресурсами. Обфускации? Не всегда требуется. Я не говорю, что не надо использовать ProGuard, но не понимаю, почему автор так категорично навязывает его использование.
не могу быть уверен, почему так написали авторы статьи, могу лишь озвучить своё мнение :-)
1. По нашим ощущениям, Gradle действительно функциональнее Maven и позволяет писать более компактный код. Я без проблем приведу примеры вещей, которые может Gradle и не может Maven, но не наоборот. Впрочем, статьи по этому поводу пишутся уже минимум лет 5
2. Aquery, конечно, можно :-)
3. По мнению авторов, Jackson более функционален, это явным образом написано в статье. Не могу уточнить, не использовали
4. Оценка глубины иерархии — вопрос хороший, и на Хабре обсуждался, насколько помню, но явно за рамками статьи для новичков. Это же относительно короткий набор советов, а не полноценная книга по Android-разработке :-)
5. Пусть меня поправят знатоки Eclipse, давненько не открывал, вроде под Maven там надо было ставить плагин. Android Studio же дружит с Gradle «из коробки», так что выражение автора имеет некоторый смысл
6. выражение «Always use ProGuard or DexGuard» мне тоже кажется чересчур сильным
1. По нашим ощущениям, Gradle действительно функциональнее Maven и позволяет писать более компактный код. Я без проблем приведу примеры вещей, которые может Gradle и не может Maven, но не наоборот. Впрочем, статьи по этому поводу пишутся уже минимум лет 5
2. Aquery, конечно, можно :-)
3. По мнению авторов, Jackson более функционален, это явным образом написано в статье. Не могу уточнить, не использовали
4. Оценка глубины иерархии — вопрос хороший, и на Хабре обсуждался, насколько помню, но явно за рамками статьи для новичков. Это же относительно короткий набор советов, а не полноценная книга по Android-разработке :-)
5. Пусть меня поправят знатоки Eclipse, давненько не открывал, вроде под Maven там надо было ставить плагин. Android Studio же дружит с Gradle «из коробки», так что выражение автора имеет некоторый смысл
6. выражение «Always use ProGuard or DexGuard» мне тоже кажется чересчур сильным
Если принять во внимание, что ваш проект в дальнейшем будут поддерживать другие Android разработчики, то Gradle предпочтительнее, чем что либо еще, т.к. в последнее время является чуть ли не стандартом для сборки Android приложений. Даже если вы лучше разбираетесь с Maven, заставлять это других делать не вижу смысла.
Возможно я не прав, но приложение, после обфускации с помощью ProGuard должно работать быстрее: названия методов становятся короче -> поиск по ним становится быстрее. Использовать DexGuard во всех подрят приложениях не вижу смысла.
А вообще, вы можете сделать Pull Request в оригинальную статью на github со своими комментариями;)
Возможно я не прав, но приложение, после обфускации с помощью ProGuard должно работать быстрее: названия методов становятся короче -> поиск по ним становится быстрее. Использовать DexGuard во всех подрят приложениях не вижу смысла.
А вообще, вы можете сделать Pull Request в оригинальную статью на github со своими комментариями;)
1. Потому что Gradle единственная официально поддерживаемая гуглом система сборки под андроид. Ну и с эстетической точки зрения gradle красивее.
2. Неа, Aquery нельзя. Он во всю поддерживает reflection что при включении proguard добавит неимоверное количество головной боли. Ну и сломать код гораздо проще, т.к. ошибки компиляции превращаются в ошибки исполнения. В статье неточность, там должно быть написано Volley И okhttp. OkHttp гарантирует что используется последняя реализация http движка, а volley оборачивает это и добавляет кеширование, мультиплексирование запросов и загрузку картинок в придачу. Правда volley гугл тоже забросил, так что можно посмотреть на альтернативы.
3. С глубокой иерархией две проблемы — во-первых, это приводит к StackOverflowExceptions на старых девайсах и во-вторых если используются RelativeRayout или любые другие двухпроходные layouts то это будет жутко тормозить.
4. Эклипс больше не поддерживается. Ну и по сравнению с AndroidStudio он убог.
5. Потому что рано или поздно но вы придете к проблеме 65k methods, а если решать ее Multidex-ом то получится тормозящее чудовище типа клиента фейсбука. Прогуард кроме выкидывания кода который вы не используете еще дает существенную оптимизацию потребления памяти и скорости выполнения.
2. Неа, Aquery нельзя. Он во всю поддерживает reflection что при включении proguard добавит неимоверное количество головной боли. Ну и сломать код гораздо проще, т.к. ошибки компиляции превращаются в ошибки исполнения. В статье неточность, там должно быть написано Volley И okhttp. OkHttp гарантирует что используется последняя реализация http движка, а volley оборачивает это и добавляет кеширование, мультиплексирование запросов и загрузку картинок в придачу. Правда volley гугл тоже забросил, так что можно посмотреть на альтернативы.
3. С глубокой иерархией две проблемы — во-первых, это приводит к StackOverflowExceptions на старых девайсах и во-вторых если используются RelativeRayout или любые другие двухпроходные layouts то это будет жутко тормозить.
4. Эклипс больше не поддерживается. Ну и по сравнению с AndroidStudio он убог.
5. Потому что рано или поздно но вы придете к проблеме 65k methods, а если решать ее Multidex-ом то получится тормозящее чудовище типа клиента фейсбука. Прогуард кроме выкидывания кода который вы не используете еще дает существенную оптимизацию потребления памяти и скорости выполнения.
Не пишите свой собственный HTTP-клиент, лучше используйте библиотеки Volley или OkHttp
а чем плох Android Asynchronous Http Client loopj.com/android-async-http ?
вполне хорош, доводилось использовать
но вряд ли автор мог перечислить все хорошие библиотеки для http-запросов, тут скорее акцент на том, чтобы начинающие разработчики не писали свои велосипеды, а посмотрели по сторонам
Volley и OkHttp — вполне себе решения, тоже живут у нас в production
но вряд ли автор мог перечислить все хорошие библиотеки для http-запросов, тут скорее акцент на том, чтобы начинающие разработчики не писали свои велосипеды, а посмотрели по сторонам
Volley и OkHttp — вполне себе решения, тоже живут у нас в production
Почему тогда акцентирование именно на сетевом стеке? Ведь таким образом можно вообще всё обобщить: «Не пишите свои велосипеды, если есть уже готовые решения».
это были конкретные примеры велосипедов, на мой взгляд, вполне удачные
по крайней мере не раз доводилось видеть (как правило, именно у начинающих разработчиков) объёмные реализации сетевых взаимодействий, по функциональности легко покрываемые тем же OkHttp, или, если брать шире, Retrofit
по крайней мере не раз доводилось видеть (как правило, именно у начинающих разработчиков) объёмные реализации сетевых взаимодействий, по функциональности легко покрываемые тем же OkHttp, или, если брать шире, Retrofit
Потому что эта статья — перевод списка советов, полученных исходя из опыта работы вполне конкретной команды.
Вполне очевидно, что кто-то более чем успешно пользуется другими инструментами и библиотеками.
Вполне очевидно, что кто-то более чем успешно пользуется другими инструментами и библиотеками.
Не стоит злоупотреблять API уровня Android, например, слепо полагаясь на механизм Intent для внутренней работы приложения. Вы можете повлиять на операционную систему Android или другие приложения, вызвав ошибки или зависания. Например, известно, что если ваше приложение использует механизм Intent для внутренней коммуникации между пакетами приложения, вы можете вызвать зависание в несколько секунд, если приложение было открыто сразу после загрузки операционной системы.Не понял, что это значит. Объясните подробнее, плз.
Возможно речь идет о некоторых ограничениях метода. Например, если вы положите в Intent список из миллиона строк, то вероятнее всего, принимающая сторона «не заведется». Если это будет Activity, то вы не увидите даже запуска метода onCreate(), как и хоть какого-нибудь сообщения в лог – такую ошибку становится непросто поймать.
Или, если вы напишете свой Parcelable, который будет не просто раскладываться в POJO, а лезть, например, в кеш, то десериализация такого объекта в неродном процессе также, скорее всего, ни к чему хорошему не приведет.
Или, если вы напишете свой Parcelable, который будет не просто раскладываться в POJO, а лезть, например, в кеш, то десериализация такого объекта в неродном процессе также, скорее всего, ни к чему хорошему не приведет.
кода пользователь поймает баг и пришлёт вам обфускированный лог ошибок.
В части наших проектов мы используем Crashlytics, а для ещё одного писали своё собственное решение для автоматического сбора крэшей. Статистика по проблемам, возникающим у пользователей, собирается гораздо быстрее, если не доверять им возможность выбора — слать отчёт об ошибке, или не слать, а отсылать сразу же в фоновом режиме.
Подводные камни: Genymotion не позволяет использовать в приложении такие сервисы Google, как Google Play Store или Maps.
Это только если не научить его их использовать. :)
Я бы еще добавил, что нужно смотреть на правильную организацию потоков и передачу данных между ними. Для этого можно взять широкоизвестный Robospice, или недавно представленный нами Chronos. Очень часто ведь люди пишут все на AsyncTask'ах, когда 2015 год на дворе, а потом приложение неадекватно себя ведет, стоит только несколько раз повернуть экран.
Помните о ограничении dex-файла на количество методов, и избегайте использования большого количества библиотек. Приложения Android, при упаковке в dex-файл, имеют жёсткое ограничение в 65536 ссылочных методов
Ну если не получается уложиться, то можно использовать multidex.
developer.android.com/tools/building/multidex.html
меня в этой статье больше всего смутил раздел «Фреймворки для тестирования»
чем ребят из Futurice не устраивает Espresso, входящий в официальный com.android.support, поддерживающий API начиная с Froyo, совместимый с Junit4 — мне совершенно непонятно :-|
живёт у нас в production уже пол-года и никаких проблем с тестированием UI не наблюдаем
чем ребят из Futurice не устраивает Espresso, входящий в официальный com.android.support, поддерживающий API начиная с Froyo, совместимый с Junit4 — мне совершенно непонятно :-|
живёт у нас в production уже пол-года и никаких проблем с тестированием UI не наблюдаем
Так ребята ж делятся своим опытом. Есть дисклеймер. Вот если бы вы поделились опытом своей команды, там бы стоял Espresso.
В смысле, pull request им прислать? (issue по мотивам этой статьи им уже вкатили) :-D или написать «Best Practices» от MyCompany? :-)
На самом деле, вопрос был в некоторой степени риторический, конечно. Имелось в виду донести информацию, что есть не только Robotium.
А не устраивает их в Espresso с большой вероятностью то, что переходить на другой фреймворк тестирования — это убиться можно сколько работы, разве что в новых проектах начинать потихоньку.
Правда чтоли pull request отправить? :-) Один вон уже прислал перевод "to French" :-D
На самом деле, вопрос был в некоторой степени риторический, конечно. Имелось в виду донести информацию, что есть не только Robotium.
А не устраивает их в Espresso с большой вероятностью то, что переходить на другой фреймворк тестирования — это убиться можно сколько работы, разве что в новых проектах начинать потихоньку.
Правда чтоли pull request отправить? :-) Один вон уже прислал перевод "to French" :-D
В Genymotion можно поставить ARM Translation и GApps, будет и Play Store и Play Services.
...[DexGuard] Он может легко разделить Dex-файл на несколько для обхода ограничения в 65k методов...
MultiDexApplication отлично справляется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Передовой опыт Android-разработки