Отладка графического процессора что это значит

Эффективное использование GPU

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

Настроить параметры GPU визуализации

Если ваше приложение тормозит, значит часть или все кадры обновления экрана обновляются больше чем 16 миллисекунд. Чтобы визуально увидеть обновления кадров на экране, можно на устройстве включить специальную опцию Настроить параметры GPU визуализации (Profile GPU Rendering).

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

Опция доступна на устройствах, начиная с Android 4.1. На устройстве следует активировать режим разработчика. На устройствах с версией 4.2 и выше режим по умолчанию скрыт. Для активации идёт в Настройки | О телефоне и семь раз щёлкаем по строке Номер сборки.

После активации заходим в Опции разработчика и находим пункт Настроить параметры GPU визуализации (Profile GPU rendering), который следует включить. В всплывающим окне выберите опцию На экране в виде столбиков (On screen as bars). В этом случае график будет выводиться поверх запущенного приложения.

Вы можете протестировать не только своё приложение, но и другие. Запустите любое приложение и начинайте работать с ним. Во время работы в нижней части экрана вы увидите обновляемый график. Горизонтальная ось отвечает за прошедшее время. Вертикальная ось показывает время для каждого кадра в миллисекундах. При взаимодействии с приложением, вертикальные полосы рисуются на экране, появляясь слева направо, показывая производительность кадров в течение какого-то времени. Каждый такой столбец представляет собой один кадр для отрисовки экрана. Чем выше высота столбика, тем больше времени уходит на отрисовку. Тонкая зелёная линия является ориентиром и соответствует 16 миллисекундам за кадр. Таким образом, вам нужно стремиться к тому, чтобы при изучении вашего приложения график не выбивался за эту линию.

Рассмотрим увеличенную версию графика.

Зелёная линия отвечает за 16 миллисекунд. Чтобы уложиться в 60 кадров в секунду, каждый столбец графика должен рисоваться ниже этой линии. В каких-то моментах столбец окажется слишком большим и будет гораздо выше зелёной линии. Это означает торможение программы. Каждый столбец имеет голубой, фиолетовый (Lollipop и выше), красный и оранжевый цвета.

Голубой цвет отвечает за время, используемое на создание и обновление View.

Фиолетовая часть представляет собой время, затраченное на передачу ресурсов рендеринга потока.

Красный цвет представляет собой время для отрисовки.

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

Существуют специальные методики для уменьшения нагрузки на графический процессор.

Отладить показатель GPU overdraw

Другая настройка позволяет узнать, как часто перерисовывается один и тот же участок экрана (т.е. выполняется лишняя работа). Опять идём в Опции разработчика и находим пункт Отладить показатель GPU overdraw (Debug GPU Overdraw), который следует включить. В всплывающим окне выберите опцию Показывать зоны наложения (Show overdraw areas). Не пугайтесь! Нкоторые элементы на экране изменят свой цвет.

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

Если цвет в приложении не изменился, значит всё отлично. Нет наложения одного цвета поверх другого.

Голубой цвет показывает, что один слой рисуется поверх нижнего слоя. Хорошо.

Зелёный цвет — перерисовывается дважды. Нужно задуматься об оптимизации.

Розовый цвет — перерисовывается трижды. Всё очень плохо.

Красный цвет — перерисовывается много раз. Что-то пошло не так.

Вы можете самостоятельно проверить своё приложение для поиска проблемных мест. Создайте активность и поместите на неё компонент TextView. Присвойте корневому элементу и текстовой метке какой-нибудь фон в атрибуте android:background. У вас получится следующее: сначала вы закрасили одним цветом самый нижний слой активности. Затем поверх неё рисуется новый слой от TextView. Кстати, на самом TextView рисуется ещё и текст.

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

Маленький совет. Поместите после метода setContentView() вызов метода, который уберёт перирисовку экрана цветом темы. Это поможет убрать одно лишнее наложение цвета:

Источник

Все о функциях разработчика в вашем телефоне

Константин Иванов

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

«Разблокируем» функции разработчика в телефоне

Как говорилось выше, эти функции изначально скрыты. Это имеет смысл, поскольку найти их просто, а большинству людей они попросту не нужны. Для того, чтобы добраться до них, идем в раздел «Об устройстве» и ищем там пункт «Номер сборки». После пяти быстрых тапов появляется диалоговое окно – теперь устройство считает вас разработчиком. Только попробуйте ничего не испортить, ладно? Ну, или делайте что хотите – тоже вариант. Так или иначе, возможность заставить ваш телефон перестать работать всегда имеется.

А теперь посмотрим на предложенные функции повнимательнее.

Настройки

• Создать отчет об ошибках. Тапаете здесь, чтобы отправить соответствующее сообщение туда, куда вы хотите. Устройство готовит нужные файлы для отправки, что занимает пару минут, после чего вы видите уведомление. Если смахнуть его, процесс остановится, а если тапнуть, сообщение отправится.
• Пароль резервного копирования. Позволяет использовать ADB для создания бэкапа и восстановления приложений и связанных с ними данных на вашем компьютере. Резервное копирование данных требует введения пароля, и без него данные не могут быть восстановлены.
• Активный режим. Выбор этого пункта позволяет вам держать экран работающим постоянно при подключении телефона кабелем к зарядному устройству или к компьютеру по USB. Не стоит использовать этот пункт без надобности, поскольку это верный способ выжечь экран.
• Выбор рабочего модуля. Именно здесь вы можете выбрать между Dalvik и ART. Последний по-прежнему находится в тестовом режиме – это явно не то, что мы увидим в Android L. С некоторыми телефонами у него настоящий антагонизм, поэтому стоит уточнить на соответствующем форуме насчет вашей модели устройства.
• Включить журнал трансляции операций HCI Bluetooth. Иногда разработчику или специалисту по безопасности требуется перехватить и проанализировать пакеты Bluetooth HCI. Включение этого пункта помещает их в файл, который находится во встроенной памяти устройства (/sdcard/btsnoop_hci.log) для восстановления. После этого их можно проанализировать программой типа Wireshark.
• Статистика процессов. Все, что вам может понадобиться узнать о запущенных на вашем устройстве процессах. Тапаете здесь, а потом на одном из пунктов. Для обычного пользователя это просто набор цифр, но для разработчика может быть весьма полезным.
• Отладка USB. То, что позволяет вашему телефону связываться с компьютером, используя Android Debug Bridge (ADB). Это требуется для использования DDMS или команд ADB.
• Отозвать авторизацию отладки USB. Когда отладка при помощи компьютера происходит в первый раз, вам нужно авторизовать его и установить пару ключей. Эта настройка отменяет данное действие и предлагает повторить его снова.
• Отчеты об ошибках. Включает опцию, которая становится видимой, когда вы зажимаете кнопку питания для сбора и отправки отчета об ошибках. Очень удобно, если вы что-то тестируете.
• Фиктивные местоположения. Эта настройка позволяет вам вручную задавать информацию о местоположении, заставляя ваш телефон думать, что он там, где его в действительности нет. Кроме читов для Forsquare, это полезно для приложений, которые используют информацию о местоположении.
• Приложение для отладки. Эта настройка позволяет вам выбрать приложение для отладки. Вам не требуется действительно подключаться к отладчику, но если вы включите его, то не будете получать сообщений об ошибках, когда останавливаетесь на точке останова. Если вы не понимаете, что это значит, тогда эта настройка вам никогда не требовалась и не понадобится. Она создана для работы со средствами разработчика, позволяющими убедиться в том, что приложение работает корректно.
• Подождите, пока отладчик. Этот пункт остается неактивным, пока вы не выберет приложение для отладки. Когда оно установлено и выбрано, то настройка просто не позволяет выбранному приложению запуститься до тех пор, пока не включится отладчик. Еще один пункт, который нужен разработчикам, но бесполезен для большинства пользователей.
• Проверять для USB. Позволяет Google сканировать приложения, которые вы поставили через ADB, на предмет вредоносного поведения. Хорошая вещь.
• Показывать касания. Выбирая этот пункт, вы будете видеть визуальный эффект, подтверждающий регистрацию касания экрана.
• Местоположение указателя. Эта настройка размещает в верхней части экрана строку, в которой выводятся координаты точки экрана, которой коснулись последней.
• Показать обновления экрана. Заставляет край «окна» вспыхивать, когда происходит обновление контекста. Раздражает безумно.
• Показывать границы макета. Отмечает края элементов в окне диалога для того, чтобы вы знали, куда нужно нажать, чтобы активировать его. Попробуйте – и немедленно выключайте.
• Написание справа налево. Изменяет ориентацию экрана для поддержки языков с правосторонним написанием
• Анимация окна: масштаб. Устанавливает скорость воспроизведения анимации окна. Чем меньше число, тем быстрее.
• Анимация перехода: масштаб. Устанавливает скорость воспроизведения анимации при переходе. Опять же, чем меньше, тем быстрее.
• Эмуляция дополнительных дисплеев. Эта настройка позволяет разработчикам имитировать различные размеры экрана. Не самая надежная вещь.
• Рендеринг принудительно. Заставляет приложения использовать аппаратный двухмерный рендеринг, если они были написаны так, чтобы не использовать его по умолчанию. Иногда творит чудеса. Иногда отправляет все к чертям. Будьте бдительны.
• Показать обновления окна. С этой настройкой любая отрисовка, производимая графической подсистемой, получает красную подсветку.
• Показывать аппаратные обновления. Выделяет аппаратные уровни зеленым при обновлении. Зачем это нужно — можете почитать здесь http://www.curious-creature.org/2013/09/13/optimizing-hardware-layers/ (на английском).
• Отладка наложения. Наложение происходит каждый раз, когда приложение запрашивает систему на отрисовку чего-либо поверх чего-то иного. Эта настройка позволяет вам видеть, когда и где это происходит, чтобы видеть, в чем проблема.
• Включить 4х MSAA. Эта настройка принудительно включает множественную выборку сглаживания (MSAA). Как и с любым другим графическим ускорителем, чем больше сглаживания, тем лучше все смотрится. Но скорость работы при этом падает.
• Строгий режим. Эта настройка заставляет экран мигать, когда приложение использует главный поток для выполнения длительной и интенсивной операции.
• Выводить использование ЦП. Размещает в правом верхнем углу небольшое окно с информацией о центральном процессоре и его использовании. Забавная игрушка.
• Профиль обработки GPU. Эта настройка может либо рисовать график на экране, либо писать его в файл. График — визуальное отображение загрузки работы графического адаптера. Еще одна вещь, на которую интересно посмотреть.
• Включить трассеровку OpenGL. Настройка, позволяющая следить за ошибками OpenGL и помещающая их в специальный файл лога по вашему выбору. Ничего такого, что стоило бы трогать большинству пользователей.
• Не сохранять операции. Эта настройка уничтожает любое приложение, как только вы закрываете его окно. Ничего хорошего из этого не выйдет, что бы там на форумах ни писали.
• Фоновые процессы. Позволяет задавать в настройках количество процессов, которые могут одновременно работать в фоне. Еще одна вещь, которую большинству из нас не стоит трогать слишком часто. Если вообще стоит.
• Показать все ANR. Эта настройка заставляет все процессы показать сообщение «Приложение не отвечает», если приложение зависло, включает фоновые процессы, которые не запускаются пользователем. Полезно, если одно приложение мешает нормально работать другому.

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

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

Источник

Русские Блоги

Инструменты оптимизации производительности приложения — отладка графического процессора Overdraw

Сегодня я представляю два относительно простых инструмента оптимизации производительности:

Отладка перезапуска графического процессора
Анализ режима рендеринга в GPU

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

Во-вторых, отладка перезапуска графического процессора

Этот инструмент в основном используется для проверки, есть ли проблема слишком глубокого макета в макете.

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

Аналогичным образом, если вы тратите энергию, пытаясь нарисовать что-то в своем приложении, это также вызовет проблемы с производительностью. Термин overdraw используется для описания того, сколько раз пиксель на экране был перерисован в одном кадре.

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

Перейдите в Настройки-Параметры разработчика-Включите опцию Отладка графического процессора и выберите второй элемент во всплывающем окне:

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

Конкретная картина выглядит следующим образом

1. Синяя перекраска один раз (указывает на то, что эта область пикселей была нарисована дважды)
2. Зеленый перерисован дважды
3. Розовый перерисован три раза
4. Красный перерисован четыре раза

• Цели и легкий путь

Ваша цель состоит в том, чтобы максимально уменьшить излишнее рисование, чтобы на экране вы видели больше синего, чем темно-красного.

Резюме и рекомендации

Слишком много перекрывающихся фонов
Перекрывающиеся фоны иногда необходимы, а иногда и не нужны. Это зависит от вашего проекта.

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

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

1. Избегайте «OverDesign»

Перерисовка принесет в приложение плохой опыт. Причины перерисовки — не что иное, как сложные уровни компоновки, перекрывающиеся виды и перекрывающиеся фоны. Неограниченная укладка View для разработчиков — не что иное, как дизайн безудержных требований к продукту. Существует поговорка «от бережливости к роскоши, от роскоши до бережливости». Многие приложения носят роскошные пальто с чрезмерным дизайном, но забывают, что простота и удобство использования — это сущность дороги. Сложные и сложные конструкции не приносят пользователям Хороший опыт на самом деле заставит пользователей чувствовать себя угнетенными, а сам продукт может застрять. Конечно, все, кроме деловых дискуссий, — это оптимизация в воздухе, которая требует компромисса между дизайном продукта и балансом между сложной бизнес-логикой и простым в использовании отображением интерфейса, а не вслепую OverDesign.

2. Слишком много пересекающихся взглядов

Первое предложение: используйте ViewStub для загрузки некоторых необычных макетов. Это легкий и невидимый вид по умолчанию. Вы можете динамически загружать макет. Загружайте его только при использовании этого перекрывающегося представления. Задержка времени загрузки. Второе предложение: если вы используете комбинацию, такую ​​как viewpager + Fragment или имеете несколько фрагментов на одном интерфейсе, вам нужно управлять отображением и скрытием фрагментов, пытаться использовать динамическое представление Inflation, его производительность лучше, чем SetVisiblity.

3. Разумно выберите контрольный контейнер

Здесь есть и другие предложения. Прежде всего, рекомендуется использовать инструмент верстки Hierarchy Viewer, предоставляемый Android, для проверки и оптимизации макета. Первое предложение: если вложенный линейный макет углубляет уровень макета, вы можете вместо этого использовать относительный макет. Второе предложение — использовать метки для объединения макета, что может уменьшить иерархию макета. Третье предложение — повторно использовать макет с тегами. Извлечение общего макета может сделать логику макета более понятной. Помните, конечная цель этих предложений — сделать ваш макет широким и поверхностным, а не узким и глубоким в средстве просмотра иерархии.

4. Удалите другой ненужный фон

Иногда для удобства сначала задайте общий фон для макета, а затем задайте фон для дочернего представления, это также приведет к перекрытию. Если ширина дочернего представления равна mach_parent, вы можете увидеть, что он полностью покрывает часть макета, и вы можете установить фон отдельно Чтобы уменьшить перерисовку. В другом примере, если используется фон селектора, установка цвета нормального состояния на «@android: color / transparent» также может решить проблему. Вот только два примера: некоторые из наших привычных формул мышления в процессе разработки приведут к непреднамеренному перерасходу, поэтому, когда мы устанавливаем фон для определенного View или ViewGroup во время разработки, сначала подумайте, действительно ли это необходимо. Или подумайте, можно ли установить этот фон в дочернем представлении в разделах вместо карты непосредственно в корневом представлении.

5.ClipRect & QuickReject
Для решения проблемы Overdraw система Android минимизирует потребление, избегая рисования полностью невидимых компонентов. Но, к сожалению, для этих слишком сложных пользовательских представлений (обычно переопределяющих метод onDraw) система Android не может определить, какие операции будут выполняться в onDraw, система не может отслеживать и оптимизировать автоматически, и избежать перерисовки невозможно. Но мы можем использовать canvas.clipRect (), чтобы помочь системе идентифицировать эти видимые области. Этот метод может указать прямоугольную область, которая будет отображаться только в этой области, а другие области будут игнорироваться. Этот API может помочь тем пользовательским представлениям с несколькими наборами перекрывающихся компонентов управлять областью отображения. В то же время метод clipRect также помогает экономить ресурсы ЦП и ГП: инструкции рисования вне области clipRect не будут выполняться, а те компоненты, содержимое которых находится в прямоугольной области, будут по-прежнему отображаться. В дополнение к методу clipRect мы также можем использовать canvas.quickreject (), чтобы определить, не пересекается ли он с прямоугольником, тем самым пропуская операции рисования в непрямоугольных областях.
Детальный метод клипа

6. Используйте заполнители ViewStub

Что такое ViewStub? В предложении:Эффективный заполнитель.Мы часто сталкиваемся с ситуациями, когда среда выполнения динамически определяет, какой вид или макет отображать в зависимости от условий. Обычной практикой является написание Views для них, сначала установите их видимость для View.GONE, а затем динамически измените ее видимость в коде. Преимущества этого подхода — простая логика и гибкое управление. Но его недостаток в том, что он потребляет ресурсы. Несмотря на то, что исходным представлением View является View.GONE, при разметке Inflate представление все равно будет Inflate, что означает, что объекты все равно будут созданы, созданы и свойства будут установлены. Другими словами, он потребляет ресурсы, такие как память. Рекомендуемый метод — использовать android.view.ViewStub. ViewStub — это облегченный вид, невидимый элемент управления, который не занимает позицию макета и потребляет очень мало ресурсов. Вы можете указать макет для ViewStub. В макете Inflate будет инициализирован только ViewStub. Затем, когда ViewStub настроен как видимый или когда вызывается ViewStub.inflate (), макет, к которому направлен ViewStub, будет Inflate. И создать экземпляр, тогда свойство макета ViewStub будет передано макету, на который он указывает. Таким образом, вы можете использовать ViewStub, чтобы удобно или не отображать определенный макет во время выполнения.

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

7. Уменьшите глубину макета с помощью Merge.
Какой смысл в теге Merge? Простой и грубый ответ:Убить уровень просмотра.Роль Merge очевидна, но есть некоторые ограничения на условия использования. В двух случаях мы можем использовать тег Merge в качестве элемента управления контейнером. В первом начальном представлении не требуется указывать какие-либо свойства макета для родительского представления, то есть родительский контейнер является просто контейнером, и дочернее представление необходимо только непосредственно добавить в родительское представление для отображения. Другое заключается в том, что если вам необходимо встроить макет (или представление) в LinearLayout, а корневым узлом этого макета (или представления) также является LinearLayout, это добавит слой бесполезного вложения, что, несомненно, замедлит работу программы. скорость. В настоящее время, если мы используем корневой тег слияния, мы можем избежать этой проблемы. Кроме того, Merge можно использовать только в качестве корневого тега макета XML.Если Inflate — это файл макета, начинающийся с , необходимо указать родительский ViewGroup, а для attachToRoot должно быть установлено значение true.
Используйте HierarchyViewer для проверки уровней макета

7. Хорошо используйте draw9patch
Добавьте границу в ImageView. Вы, должно быть, столкнулись с этой необходимостью. Обычно фоновое изображение устанавливается за ImageView. Открытая граница решит проблему отлично. В настоящее время ImageView имеет две настройки. Слой можно рисовать, а нижний слой служит только для границы рисунка. Но область перекрытия двух слоев выдвижных элементов была нарисована дважды, что привело к перерасходу. План оптимизации: сделайте фон для рисования в draw9patch и установите прозрачную часть, перекрывающую передний план. Поскольку 2D-рендеринг Android оптимизирует прозрачную область в draw9patch, это переопределение оптимизировано. Но фоновое изображение должно быть превращено в draw9patch, потому что в Android 2D рендерере есть только эта оптимизация для draw9patch, в противном случае обычный Png, даже если вы установите среднюю часть на прозрачный, не уменьшит это перерисовывание.

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

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

Источник