10 самых распространенных ошибок, которые допускают разработчики Android: учебник по программированию

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

С последним обновлением Lollipop программирование Android продолжает улучшаться. Платформа немного повзрослела с момента первоначального выпуска AOSP и установила довольно высокую планку ожиданий пользователей. Посмотрите, как хорошо выглядит новый паттерн Material Design!

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

Несмотря на такую ​​огромную сегментацию, большинство ошибок на самом деле вносятся из-за логических ошибок. Эти ошибки легко предотвратить, если мы правильно разбираемся в основах!

Вот руководство по программированию для Android, посвященное 10 наиболее распространенным ошибкам, которые допускают разработчики Android.

Распространенная ошибка №1: разработка для iOS

К моему большому удовольствию, эта ошибка Android встречается гораздо реже в наши дни (отчасти потому, что клиенты начинают понимать, что времена, когда Apple устанавливала все стандарты дизайна, давно прошли). Но тем не менее время от времени мы видим приложение, являющееся клоном iOS.

Не поймите меня неправильно, я не проповедник программирования для Android! Я уважаю каждую платформу, которая продвигает мобильный мир на шаг вперед. Но сейчас 2014 год, и пользователи уже давно используют Android и привыкли к платформе. Навязывать им стандарты дизайна iOS — ужасная стратегия!

Если нет очень веской причины для нарушения рекомендаций, не делайте этого. (Google делает это все время, но никогда путем копирования и вставки.)

Вот некоторые из наиболее распространенных примеров этой ошибки Android:

1. Вы не должны делать статические вкладки, и им не место внизу (я указываю на ваш Instagram).
2. Значки системных уведомлений не должны иметь цвета.
3. Иконки приложений не должны помещаться внутри прямоугольника со скругленными углами (если только это не ваш настоящий логотип, например, facebook).
4. Экраны-заставки избыточны, если не считать начальной настройки/введения. Не используйте их в других сценариях.
5. В списках не должно быть кареток.

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

Распространенная ошибка № 2: разработка для Android-устройства

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

• Пиксели, не зависящие от плотности (dp), отличаются от обычных пикселей (px).
• Ресурсы включены несколько раз для учета различной плотности и ориентации.
• 9-патч-рисунки растягиваются по размеру экрана.

Есть буквально тысячи возможных сценариев, но через какое-то время у вас появляется чувство охвата их всех несколькими случаями.

У вас нет тысяч устройств? Не проблема. Эмулятор Android очень хорошо воспроизводит физические устройства. Еще лучше, попробуйте Genymotion, это молниеносно и поставляется с множеством различных популярных предустановленных устройств.

Кроме того, вы пробовали вращать свое устройство? Весь ад может развернуться…

Распространенная ошибка № 3: не использовать намерения

Намерения — один из ключевых компонентов Android. Это способ передачи данных между разными частями приложения или, что еще лучше, между разными приложениями в системе.

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

Опция 1:

• Запросить разрешение SEND_SMS.

   <uses-permission android:name="android.permission.SEND_SMS" />

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

Вариант 2:

• Запустите SMS-намерение и позвольте приложению, предназначенному для SMS, сделать всю работу

   Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

Если у вас есть какие-либо сомнения, лучшим решением будет вариант 2!

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

Если нет веской причины для создания пользовательской реализации (например, камеры, которая применяет фильтры), всегда используйте намерения для этих сценариев. Это сэкономит вам много времени на программирование и AndroidManifest.xml ненужных разрешений.

Распространенная ошибка № 4: не использовать фрагменты

Некоторое время назад в Honeycomb Android представила концепцию фрагментов . Думайте о них как об отдельных строительных блоках со своими (довольно сложными) жизненными циклами, существующими внутри Activity. Они очень помогают с оптимизацией под различные экраны, легко управляются своей родительской активностью, могут быть повторно использованы, объединены и расположены по желанию.

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

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

Распространенная ошибка № 5: Блокирование основного потока

Основной поток имеет единственную цель: поддерживать отзывчивость пользовательского интерфейса.

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

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

Еще хуже, если основной поток заблокирован на некоторое время (5 секунд для действий, 10 для широковещательных приемников), произойдет ANR.

Это было настолько распространено в Android 2.x, что в более новых версиях система не позволяла вам совершать сетевые вызовы в основном потоке.

Чтобы избежать блокировки основного потока, всегда используйте рабочие/фоновые потоки для: 1. сетевых вызовов 2. загрузки растровых изображений 3. обработки изображений 4. запросов к базе данных 5. чтения/записи SD

Распространенная ошибка № 6: заново изобретать колесо

«Хорошо, я не буду использовать основной поток. Я напишу свой собственный код, который взаимодействует с моим сервером в фоновом потоке».

Нет! Пожалуйста, не делайте этого! Сетевые вызовы, загрузка изображений, доступ к базе данных, синтаксический анализ JSON и вход в социальные сети — это наиболее распространенные действия, которые вы выполняете в своем приложении. Не только ваше, каждое приложение там. Существует лучший способ. Помните, как развивалась и развивалась Android как платформа? Вот краткий список примеров:

1. Используйте gradle в качестве системы сборки.
2. Используйте Retrofit/Volley для сетевых вызовов.
3. Используйте Picasso для загрузки изображений.
4. Используйте Gson/Jackson для разбора JSON.
5. Используйте общие реализации для входа через социальные сети.

Если вам нужно что-то реализовать, скорее всего, это уже написано, протестировано и широко используется. Проведите базовое исследование и прочитайте несколько руководств по программированию для Android, прежде чем писать собственный код!

Распространенная ошибка № 7: Не предполагать успеха

Здорово. Мы узнали, что есть лучший способ обработки длительных задач, и мы используем для этой цели хорошо документированные библиотеки. Но пользователю все равно придется подождать. Это неизбежно. Посылки не отправляются, обрабатываются и принимаются моментально. Есть задержки в пути туда и обратно, сбои в сети, пакеты теряются, а мечты разрушаются.

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

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

Распространенная ошибка № 8: непонимание растровых изображений

Пользователи любят контент! Особенно, когда контент хорошо отформатирован и выглядит красиво. Изображения, например, являются чрезвычайно приятным контентом, в основном из-за их свойства передавать тысячу слов на изображение. Они также потребляют много памяти. Много памяти!

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

Допустим, вы хотите отобразить на экране изображение, которое вы только что сняли своей камерой. Общий объем необходимой для этого памяти рассчитывается по следующей формуле: memory_needed_in_bytes = 4 * image_width * image_height;

Почему 4? Что ж, наиболее распространенная/рекомендуемая конфигурация растрового изображения — ARGB_8888 . Это означает, что для каждого рисуемого пикселя нам нужно хранить в памяти 8 бит (1 байт) для альфа-, красного, жадного и синего каналов, чтобы правильно отобразить его. Существуют альтернативы, такие как конфигурация RGB_565 , которая требует вдвое меньше памяти, чем ARGB_8888 , но теряет прозрачность и точность цвета (возможно, добавляя зеленый оттенок).

Предположим, у вас есть совершенно новое устройство с экраном Full HD и 12-мегапиксельной камерой. Фотография, которую вы только что сделали, имеет размер 4000x3000 пикселей, а общая память, необходимая для ее отображения, составляет: 4 bytes * 4000 * 3000 = 48 MB .

48 мегабайт оперативной памяти только для одного изображения!? Это много!

Теперь возьмем во внимание разрешение экрана. Вы пытаетесь отобразить изображение 4000x3000 на экране с разрешением 1920x1080 пикселей, в худшем случае (отображение изображения на весь экран) вам не следует выделять более 4 * 1920 * 1080 = 8.3 MB памяти.

Всегда следуйте советам по программированию Android для эффективного отображения растровых изображений:

1. Измерьте представление, в котором вы показываете свои изображения.
2. Масштабируйте / обрезайте большое изображение соответствующим образом.
3. Показывать только то, что можно отобразить.

Распространенная ошибка № 9: использование иерархии глубокого просмотра

Макеты имеют представление XML в Android. Чтобы отрисовать контент, необходимо проанализировать XML, измерить экран и соответствующим образом разместить все элементы. Это ресурсоемкий и трудоемкий процесс, который необходимо оптимизировать.

Вот как работает ListView (а в последнее время и RecyclerView).

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

Допустим, вы хотите создать сетку 3x3 с изображениями. Один из способов сделать это — вертикальный LinearLayout , содержащий 3 LinearLayout с одинаковым весом, каждый из которых содержит 3 ImageViews с одинаковым весом.

Что мы получаем при таком подходе? Предупреждение о том, что «вложенные веса плохо влияют на производительность».

В мире программирования Android есть поговорка, которую я только что придумал: «Небольшими усилиями можно сгладить любую иерархию» .

В этом случае RelativeLayout или GridLayout эффективно заменят вложенные LinearLayouts .

Распространенная ошибка № 10: не установить для minSdkVersion значение 14

Что ж, это не ошибка, а плохая практика.

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

Цифры понятны, пользователи ушли, разработчики не должны оставаться в стороне.

Я знаю, что это не относится к некоторым крупным рынкам со старыми устройствами (например, в Индии), и установка minSdkVersion на 14 в приложении Facebook означает, что пара миллионов пользователей останется без своей любимой социальной сети. Но если вы начинаете с чистого листа и пытаетесь создать приятный опыт для своих пользователей, рассмотрите возможность избавиться от прошлого. У пользователей, у которых нет ресурсов или которые чувствуют потребность в обновлении своего устройства/ОС, не будет стимула попробовать улучшенную версию вашего приложения для Android и, в конечном итоге, потратить на это деньги.

Заворачивать

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

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