Разработка системы контроля и управления энергопотреблением элементов графического интерфейса на мобильных устройствах

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ «ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

МОСКОВСКИЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ

им. А Н. ТИХОНОВА

Выпускная квалификационная работа по направлению подготовки

Информатика и вычислительная техника студента образовательной программы «Информатика и вычислительная техника»

РАЗРАБОТКА СИСТЕМЫ КОНТРОЛЯ И УПРАВЛЕНИЯ ЭНЕРГОПОТРЕБЛЕНИЕМ ЭЛЕМЕНТОВ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА НА МОБИЛЬНЫХ УСТРОЙСТВАХ

Юндин Владислав Андреевич

Руководитель

Старший преподаватель ДКИ, А.Ю. Ролич

Москва, 2020



ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ «ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

МОСКОВСКИЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ им. А.Н. ТИХОНОВА

ЗАДАНИЕ

на выпускную квалификационную работу бакалавра
студенту группы БИВ 161 Юндину Владиславу Андреевичу

Тема работы

Разработка системы контроля и управления энергопотреблением элементов графического интерфейса на мобильных устройствах

Development of a system for monitoring and energy management of graphical interface elements on mobile devices

Требования к работе

Общие требования к объекту разработки

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

Требования к функциональности

• система должна находить иерархию элементов графического интерфейса для каждого экрана

• система должна анализировать иерархию элементов графического интерфейса для каждого экрана

• система должна формировать список рекомендаций по оптимизации энергопотребления для каждого экрана

Требования к информационной и программной совместимости

• операционная система Android версии 5.0 и выше

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

• возможность подключения к проекту сторонней библиотеки из файла Android Archive (AAR)

Содержание работы

Обзор существующих исследований по проблеме оптимизации энергопотребления

Обзор инструментов для измерения энергопотребления устройства

Исследование энергопотребления различных элементов графического интерфейса

Проектирование подключаемой библиотеки для контроля и управления энергопотреблением элементов графического интерфейса

Разработка подключаемой библиотеки для контроля и управления энергопотреблением элементов графического интерфейса

Тестирование системы



Аннотация

В настоящее время мобильные устройства пользуются большей популярностью, чем когда-либо прежде. Для улучшения опыта взаимодействия с устройствами необходимо более эффективно использовать их ресурсы, особенно важен вопрос разрядки аккумулятора. Целью данной работы является разработка системы контроля и управления энергопотреблением элементов графического интерфейса на мобильных устройствах c операционной системой Android. В работе представлен способ измерения энергопотребления виджетов с помощью анализа отчётов службы batterystats. Процесс измерения управлялся zsh-скриптом через подключение к устройству по USB. Результатом работы стала подключаемая библиотека, способная предложить рекомендации по оптимизации 23 виджетов.



Annotation

Nowadays mobile devices are more popular than ever before. To improve the experience of interaction with devices it is necessary to use their resources more effectively, especially the battery draining issue is important. The purpose of this paper is to develop a system for monitoring and energy management of graphical interface elements on Android devices. This study presents a method for measuring the power consumption of the widget by analyzing the output of batterystats service. The measurement process was controlled by a script written for zsh while the device is connected via USB. The result is a plug-in library that can offer recommendations for optimizing 23 widgets.



Оглавление

Введение

1. Актуальность работы

2. Обзор литературы

2.1 Проблемы пользователей и разработчиков мобильных приложений

2.2 Измерение энергопотребления устройств

2.3 Оптимизации на уровне исходного кода

2.4 Общие методы оптимизации потребления ресурсов для портативных устройств

2.5 Энергопотребление в операционной системе Android

2.6 Оптимизация энергопотребления экранов мобильных устройств

2.7 Выводы

3. Инструменты измерения энергопотребления

3.1 Способы измерения

3.2 Обоснование выбранного инструмента

3.3 Анализ системных отчётов

3.3.1 Анализ архива отчёта

3.3.2 Инструмент dumpsys

3.4 Фильтрация данных

3.4.1 Служба batterystats

3.4.2 Служба cpuinfo

4. Процесс сбора данных

4.1 Оптимизация сбора данных

4.2 Проблемы при сборе данных

4.2.1 Сброс статистики

4.2.2 Связь с компьютером

4.3 Автоматизация процесса

5. Составление списка элементов

6. Измерение одного виджета

6.1 Проектирование автоматических тестов

6.1.1 Процесс запуска Activity

6.1.2 Передача данных при запуске теста

6.1.3 Обработка объекта виджета

6.2 Выбор фреймворка автоматического тестирования

7. Сравнение результатов измерений в разных условиях

7.1 Влияние подключённого USB-кабеля

7.2 Влияние запуска через автотест

8. Постобработка результатов измерений

9. Результаты измерений

10. Подключаемая библиотека

10.1 Проектирование библиотеки

10.2 Язык программирования и инструментальные средства

10.3 База данных

10.4 Разработка

10.4.1 Структура проекта

10.4.2 Написание кода библиотеки

11. Итоги работы

Заключение

Глоссарий

Перечень сокращений, условных обозначений, символов и терминов

Список использованных источников

Список сущностей пакета android.widget в Android 10 SDK Platform



Введение

мобильный приложение энергопотребление экран

Современная жизнь немыслима без смартфонов и разных мобильных приложений, которые могут неэффективно потреблять ресурсы устройства. Значительные проблемы в оптимизации пользовательского опыта возникают в вопросах разряда батареи. Энергоэффективность приложений -- одна из важнейших проблем, с которой сталкиваются как разработчики, так и пользователи [1; 2]. Низкая энергоэффективность приложения ускоряет разрядку смартфона и может даже стать основанием для удаления приложения [3]. Данная проблема имеет популярность среди исследователей, и является предметом большого количества работ. Предложено множество способов снижения энергопотребления, но мне хотелось бы проверить эффективность метода, который основан на замене менее эффективных виджетов на экране более эффективными.

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

• Проанализировать существующие исследования по оптимизации энергопотребления;

• Определить инструменты для измерения энергопотребления Android-смартфонов;

• Измерить энергопотребление различных элементов пользовательского интерфейса;

• Создать библиотеку для мониторинга и управления энергопотреблением графических элементов пользовательского интерфейса

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

Программные средства Для разработки системы будет использован язык программирования Kotlin и фреймворк автоматического тестирования пользовательского интерфейса Kaspresso. Для измерения энергопотребления использованы отчёты службы batterystats. Для обработки отчётов использованы языки Python и Z shell.



1. Актуальность работы

Смартфон -- неотъемлемая часть жизни современного человека. Человек может использовать телефон до 200 раз каждый день [4]. Тем не менее, смартфоны всё ещё не достигли потолка своего развития и многие аспекты нуждаются в улучшении. Одним из таких является энергопотребление устройства.

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

Рис. 1 Среднее время работоспособности аккумуляторной батарей

Раньше мобильные телефоны могли работать более недели от одного заряда аккумулятора, но с их развитием такая возможность была потеряна. Как видно на диаграмме (рис. 1), процесс увеличения числа возможностей портативных устройств сопряжён с уменьшением времени работы прибора. Если в 1996 году портативное устройство было способно работать 8-10 недель до разрядки аккумулятора, то уже в 2004 году наличие камеры, диктофона, Bluetooth, цветного дисплея и другой функциональности сократили время работы до недели и меньше [6].

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

Имеют место множество подходов к уменьшению потребления экрана, которые основываются на самых разных идеях. Некоторые считают, что изменение цветовой схемы интерфейса на AMOLED экранах поможет снизить затраты [10], другие понижают кадровую частоту и частоту обновления экрана [11; 12].

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

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



2. Обзор литературы

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

2.1 Проблемы пользователей и разработчиков мобильных приложений

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

Одна из проблем, освещённая в статье Мана, Гао и др., связана с пользовательским восприятием приложений [1]. Авторами был создан новый фреймворк под названием CrossMiner для автоматического анализа проблем приложений из отзывов пользователей с помощью метода, основанного на ключевых словах. Основываясь на пяти миллионах отзывов пользователей, платформа автоматически фиксирует распределение семи проблем приложения, а именно: “батарея”, “сбой”, “память”, “сеть”, “конфиденциальность”, “спам” и “пользовательский интерфейс”. По итогу было выявлено, что проблемы, связанные со “сбоем” и “сетью”, больше беспокоят пользователей, чем другие проблемы на трех рассматриваемых платформах (Google Play, App Store и Windows Store).



Рис. 3 Причины удаления приложений пользователями

В другой работе задача состояла в том, чтобы определить причины, по которым пользователи выбирают и устанавливают мобильные приложения из магазинов приложений [3]. А также причины, по которым пользователи их удаляют. Было проведено анкетирование с участием 121 респондента из 26 различных стран. Как видно на диаграмме (рис. 2), самыми частыми причинами установки приложения являются его описание, оценки пользователей и скриншоты приложения. Согласно другим данным (рис. 3) в топе причин удаления -- бесполезность, сбои, высокое использование оперативной памяти.

С точки зрения инженеров [2] наиболее остро стоят следующий вопросы:

* Улучшение пользовательского опыта;

• Нефункциональные требования (производительность, энергоэффективность, надёжность, качество, безопасность);

• Процессы, инструменты и архитектура;

• Переносимость на другие платформы.

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

2.2 Измерение энергопотребления устройств

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

В зарубежных исследованиях нередко предлагаются собственные инструменты измерения. Так, в департаменте компьютерных наук университета Ёнсе в Южной Корее, был разработан AppScope -- приложение для автоматического измерения энергопотребления приложений Android с помощью мониторинга активности ядра [13]. Оно отслеживает системные вызовы, а также анализирует данные механизма IPC операционной системы.

В статье Сео, Малека и Медвидовика представлена структура для оценки энергопотребления программных систем на основе Java [14]. Её инфраструктура использует компонентную перспективу, что делает ее подходящей для большого класса современных распределенных, встроенных и распространяющихся приложений. В большом количестве сценариев распределенных приложений платформа показала очень хорошую точность в целом, давая результаты, которые были в пределах 5% от фактического потребления энергии, затраченного при работе приложения.

Проектная группа из университета Джорджа Мейсона и Национального института стандартов и технологий США представила систему, которая эффективно учитывает энергопотребление всех основных аппаратных подсистем телефона: процессора, дисплея, графики, GPS, аудио, микрофона и Wi-Fi [15]. Для этого они использовали доли времени для каждой подсистемы, сообщаемые модулем управления питанием операционной системы. Предложенное решение позволяет работать в режиме реального времени без значительного влияния на энергопотребление подконтрольного устройства, что может помочь разработчикам и исследователям принимать более оптимальные решения для повышения энергоэффективности.

2.3 Оптимизации на уровне исходного кода

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

Одно из исследований показало, что JavaScript экономит больше энергии и работает медленнее, чем другие подходы, и что гибридизация приложений может быть решением для оптимизации приложений как с точки зрения производительности, так и энергопотребления [16]. Среди двух вариантов гибридизации использование NDK является наиболее безопасным вариантом для повышения производительности, но использование веб-подхода может дать ощутимый результат при небольшом количестве кросс-языковых вызовов.

Ещё одно исследование относительно Java сфокусировано вокруг одного из механизмов для снижения требований к памяти, а именно сжатия [17]. В статье рассматривается влияние сжатия на объём использованных системных ресурсов виртуальной машиной Java (JVM). Также обращается внимание на алгоритмы, применимые для этих целей. Опыты показали, что экономия энергии составляет в среднем 21%. В тех приложениях, где декомпрессия играет большую роль, результаты заметно хуже.

2.4 Общие методы оптимизации потребления ресурсов для портативных устройств

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

В статье Маурицио предлагается значительно пересмотреть подход к производству устройств с учётом интересов конечного пользователя [18]. А именно: изменить подбор архитектуры и уделять внимание экономии энергии всех стадиях разработки продукта. При выборе архитектуры автор предлагает учитывать критерий энергопотребления, например, энергозатратные архитектуры, использующие ТПЛ и дифференциальные сигнальные методы со скоростью передачи данных более 10 Гбит/с, необходимо сопоставлять с менее энергоёмкими методиками, например, КМОП или использование несимметричных архитектур. В дополнение к данному подходу делается акцент на необходимости дальнейшей оптимизации уже существующих архитектур, дополняя их новыми характеристиками.

Анализ энергопотребления и средней задержки для режима энергосбережения с несколькими циклами ожидания показывает, что можно оптимизировать параметры режимов ожидания с учётом ограничения средней начальной задержки [19]. Предложенная автором методика базируется на математической модели для входного потока, которая применима и для сложных систем с большим числом состояний. Однако методика может быть использована лишь для систем, функционирование которых может быть разбито на циклы регенерации.

Также можно рассмотреть более частные случаи. Например, способы по оптимизации потребления энергии устройствами, функционирование которых управляется микроконтроллером. Они нашли себе применение в том числе и в смартфонах. Обзор охватывает программные, архитектурные и схемотехнические способы снижения потребления [20]:

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

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

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

2.5 Энергопотребление в операционной системе Android

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

В статье Ли и Халфонда была проведена эмпирическая оценка общепринятых методов энергосбережения и повышения производительности [8]. Она позволила определить, в какой степени эти методы смогли сэкономить энергию по сравнению с неоптимизированными аналогами кода. В частности, было обнаружено, что объединение сетевых пакетов до определённого размера и использование определённых методов кодирования для считывания информации о длине массива, доступа к полям классов и выполнения вызовов приводят к снижению энергопотребления. Однако другие методы, такие как ограничение использования памяти, оказали минимальное влияние на количество затраченной энергии. Эти результаты позволят разработчикам избежать использования неэффективных подходов.

Работа Ли, Хао и др. по сбору информации о поведении приложений в контексте энергопотребления выявила, что в среднем приложения тратят 60% своей энергии в неактивных состояниях. При этом самым энергоёмким составляющим является взаимодействие устройства с сетью [21]. Также они проанализировали три распространённых метода, используемых в исследованиях, связанных с измерением энергопотребления: использование времени работы для расчёта приближенного значения; использование измерения на уровне миллисекунд; и пренебрежение затратами энергией в состоянии покоя. Существенный недостаток этих методов заключается в большой погрешности измерения, что может исказить результаты исследований.

2.6 Оптимизация энергопотребления экранов мобильных устройств

Целевым компонентом результата данной работы -- системы для оптимизации энергопотребления элементов графического интерфейса -- является экран мобильного устройства. В связи с чем стоит рассмотреть ранее изученные подходы к энергооптимизации данного компонента.

Исследования показывают, что потребление может быть уменьшено за счет снижения частоты кадров [11], оптимизации сети [7], использования памяти [8], использования тёмного фона жидкокристаллических экранах [22] и так далее. Эмпирическое исследование показывает, что смартфон потребляет большое количество энергии при отображении интерфейса для пользователя [21].

Ван и Джин [10] описали методику обнаружения энергоёмких интерфейсов и их преобразования для экономии энергии. Их результаты оказали значительное влияние на оценку энергопотребления экрана и, кроме того, их идея была разработана в исследовании Линареса-Васкеса и др. [23]. Суть данного подхода основана на оптимизации цветовой палитры при сохранении допустимого уровня контрастности. Частота обновления дисплея также была изучена научным сообществом. Хуан и др. [12] и Ким и Юнг [24] предполагают, что частота обновления является ключевым фактором, за счёт снижения которого достигается экономия энергии.

Ключевой особенностью исследования Вана и Джина [10] является инструмент, который может анализировать содержимое скриншота. Это модель потребляемой дисплеем мощности, которая предсказывает количество энергии, потребляемой каждым пикселем экрана, принимая во внимание тип экрана и цвет определённого пикселя. Позже оригинальный скриншот трансформируется, чтобы достичь более энергоэффективного пользовательского интерфейса. Преобразованное изображение аналогично анализируется перед сравнением результатов с исходными данными. Результаты работы учёных показывают, что предполагаемая экономия энергии достигает 50% от первоначального значения. Это указывает на то, что их идеи служат хорошей основой для дальнейшего изучения. В данной работе оценка погрешности модели была измерена только на 4 различных устройствах, которые могут не отражать полноту всей картины.

В работе Линарес-Васкес и др. [23] основой подхода является многоцелевое рассмотрение контента. Это позволяет разработчикам достичь компромисса между тремя выделенными целями: снижение энергопотребления на OLED-дисплеях, увеличение контраста между соседними элементами пользовательского интерфейса и сохранение согласованности в использовании цветов по сравнению с оригинальным дизайном. Для достижения такого поведения необходимо найти состояние оптимальности по Парето, в котором улучшение одной из целевых функций не может быть достигнуто без ухудшения других целей. С помощью указанных методов учёным удалось в некоторых случаях снизить энергопотребление на 79%. Этот результат представлен с множеством графически выраженных данных, которые иллюстрируют весь процесс. Вопрос, который остаётся нераскрытым -- это сопоставимость опыта пользователя до и после оптимизации питания.

Хуан и др. [12], в свою очередь, демонстрируют взаимосвязь между энергопотреблением и частотой обновления дисплея. В настоящее время частота обновления ЖК-экранов постоянна, что приводит к тому, что экрану приходится рисовать те же кадры без особой на то необходимости. Учёные представили механизм, сокращающий избыточные обновления кадров и доступ к памяти на основании информации о кадровых буферов. Тем не менее, из исследования невозможно сделать вывод об устройствах с типом экрана, отличным от LCD.

В дополнение к вышеупомянутым исследованиям Ким и Юнг [24] придерживались идеи интеллектуальной частоты обновления дисплея. Ключевой особенностью статьи является показатель скорости контента и его отношение к частоте обновления экрана. Предлагаемая метрика скорости контента начинается с определения частоты обновления контента для каждого приложения и затем управления частотой обновления, чтобы оптимизировать энергопотребление без ущерба для пользовательского восприятия. Измерение частоты обновления контента основано на частоте кадров и сравнении кадровых буферов разных кадров для вычитания избыточной частоты кадров. Кроме того, была применена технология ускорения касанием: частота обновления резко возрастает, когда происходит событие касания. Это исследование все ещё имеет некоторые ограничения: только одна модель устройства была протестирована, а типы дисплеев, для которых исследование является действительным, не описаны.

2.7 Выводы

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



3. Инструменты измерения энергопотребления

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

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

3.1 Способы измерения

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

• анализ напряжения на аккумуляторе, получаемого через компонент приложения BroadcastReceiver;

• получение данных по энергопотреблению с помощью инструмента Android Profiler;

• анализ данных по конкретному приложению, собираемых операционной системой, с помощью инструмента Battery Historian;

• анализ напряжения на аккумуляторе, собираемого операционной системой, с помощью Battery Historian;

• измерение энергопотребления всего устройства с помощью стороннего оборудования.

Анализ напряжения, получаемого через BroadcastReceiver страдает от несовершенности API. Разные устройства могут иметь различное поведение относительно частоты обновления данных, но в среднем новое значение рассылается при уменьшении заряда аккумулятора на один процент. То есть данный подход позволяет получить лишь около 100 значений за время полного разряда устройства, чего недостаточно для анализа.

Android Profiler и Battery Historian позволяют фильтровать потребление по отдельному приложению, что несомненно является преимуществом. Но Android Profiler не учитывает потребляемую экраном энергию и показывает лишь потребление по четырёхзначной шкале (None, Low, Meduim, High) следующих потребителей: процессор, сеть, геолокация. Этого также не хватит для полноценного анализа.

Battery Historian отображает более точную информацию о потреблении конкретным приложением. Доступна информация по проценту израсходованной батареи, а также процессорное время, использованное приложением. Но доступны только суммарные данные за всё время с последней полной зарядки устройства. То есть нельзя сказать, сколько потребляло приложение в конкретный момент времени. Так как тесты проводятся в рамках одного приложения, использовать Battery Historian без модификаций не получится.

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



Рис. 4. Напряжение на аккумуляторе устройства

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

3.2 Обоснование выбранного инструмента

Самым надёжным способом в настоящий момент остаётся измерение потребления всего устройства с помощью стороннего оборудования. Данный подход используется практически всеми современными исследованиями, требующими измерения энергопотребления приложения. Устройство для измерения подключается к тестируемому устройству вместо аккумуляторной батареи и записывает показатели потребляемой устройством мощности с некоторым интервалом. Устройства для измерения варьируются от платы Arduino с небольшой программой до оборудования, специально созданного для таких целей. Самым популярным решением является использование Monsoon Power Monitor, именно его я собирался использовать при проведении собственных измерений.

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

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

3.3 Анализ системных отчётов

В Battery Historian загружается zip-архив, получаемый через Android Debug Bridge командой adb bugreport. Его следует проанализировать в первую очередь.

3.3.1 Анализ архива отчёта

При распаковке архива мы получаем директорию c файлами, описанными в документации [25]:

• bugreport-OnePlus3-PKQ1.181203.001-2020-05-13-12-21-11.txt -- самый большой по занимаемому дисковому пространству файл, содержащий всю основную информацию;

• FS -- директория с некоторыми данными из файловой системы устройства;

• dumpstate_log.txt -- файл, содержащий информацию о том, как прошёл сбор данных;

• lshal-debug -- директория с информацией о слоях аппаратных абстракций операционной системы;

• main_entry.txt -- файл, содержащий имя файла с основными данными, в данном случае, первого в списке файла;

• proto -- информация от вспомогательных служб в proto-формате;

• version.txt -- файл с версией формата отчёта, данном случае используется версия 2.0.

После изучения директории становится понятно, что единственный файл, представляющий интерес -- первый в списке. При открытии файла мы видим шапку с информацией о модели устройства, версии ядра операционной системы и так далее (рис. 5). После этого упоминается вызов инструмента dumpsys и представлены разделённые на блоки отчёты различных служб.

Рис. 5 Шапка отчёта устройства

3.3.2 Инструмент dumpsys

Из найденной документации к dumpsys [26] становится понятно, что отчёты служб можно получать по отдельности, что удобно, так как файл отчёта, полученный из архива, содержит более 500 тысяч строк и понадобится далеко не вся информация, которую он содержит. В документации можно найти команду adb shell dumpsys batterystats, которая возвращает статистику по расходу заряда батареи устройства. Возвращаемый файл достаточно объёмный, наибольший интерес представляет раздел Statistics since last charge, так как он содержит информацию по конкретным приложениям.

В подразделе Estimated power use (mAh) отображаются затраты, разделённые на Uid (рис. 6). Uid -- это пользовательский идентификатор в Unix-подобных операционных системах, он уникален для каждого приложения и по нему можно отслеживать энергопотребление и затраченное процессорное время.

Рис. 6 Подраздел с затратами на каждый Uid

Также в разделе есть подраздел с общей статистикой для каждого иЫ в системе, там не указана израсходованная энергия, но есть информация о процессорном времени, потраченным на это приложение (рис. 7).

Также была использована служба cpuinfo, предоставляющая дополнительную информацию о затраченном процессорном времени. Обычно сервис предоставляет незначительную информацию, но в отчётах устройства, используемого для тестирования (ОпеР1ш А3000), имелись дополнительные данные, разделённые по времени и иЫ, что предоставляет возможности для дополнительного анализа (рис. 8).



Рис. 7 Подраздел со статистикой по Uid u0a662

Рис. 8 Дополнительная информация сервиса cpuinfo на устройстве OnePlus A3000

Получаемые с помощью служб batterystats и сршпй данные уже не содержат нерелевантную информацию от других служб операционной системы, но всё ещё имеют объём 3-5 тысяч строк. Понадобится инструмент фильтрации нужной информации.

На первом этапе фильтрации нужно оставить только информацию, которая относится к тестируемому приложению.

3.4.1 Служба batterystats

Для службы batterystats это строка с нужным Uid из подраздела Estimated power use (mAh), а также подраздел с общей статистикой по Uid. Для фильтрации этой информации на языке Python был написан скрипт filter_bat.py. Скрипт принимает в качестве аргументов командной строки имена файлов, которые ему требуется отфильтровать. Отфильтрованные версии файлов помещаются в директорию batt_results_filtered/, которую создаёт скрипт.

3.4.2 Служба cpuinfo

Из службы cpuinfo понадобятся такие строки, которые отражают данные для промежутка времени, в которое производилось тестирование, и содержат информацию по Uid тестируемого приложения. Также понадобятся сами строки с датами, так как временные промежутке в файле не равные. Для фильтрации данных на языке Python был написан скрипт filter_cpu.py. Он так же принимает в качестве аргументов командной строки имена файлов, которые ему требуется отфильтровать, а результат помещает в созданную директорию cpu_results_filtered/.

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



4.1 Оптимизация сбора данных

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

• проводить тестирование на устройстве без сторонних приложений;

• проводить тестирование на устройстве с операционной системой без сервисов Google Play Services, которые выполняют фоновые задачи операционной системы;

• проводить тестирование всех элементов интерфейса на одном и том же устройстве;

• проводить тестирование при активированном на устройстве режиме полёта;

• проводить тестирование с максимальной яркостью экрана.

К сожалению, доступа к устройству без сторонних приложений и с операционной системой без сервисов Google Play Services, не имеется. Тестирование будет проводится на устройстве OnePlus A3000 с операционной системой Android 9 и версией ядра 3.18.120-perf+. На устройстве будет активирован режим полёта и установлена максимальная яркость экрана. Также будут закрыты все сторонние приложения.

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

4.2 Проблемы при сборе данных

Используемый метод получения данных от операционной системы не лишён недостатков. Стоит их рассмотреть.



4.2.1 Сброс статистики

Как уже упоминалось, служба Battery Historian предоставляет только суммарные данные за время с последней полной зарядки устройства, что мешает получать данные по конкретному виджету. Такое поведение обусловлено тем, что именно в таком формате предоставляет данные служба batteryststs, анализ которой будет производится и в этой работе.

Для решения данной проблемы была использована команда adb shell dumpsys batterystats --reset, которая помогает вручную сбросить все имеющиеся данные и начать запись статистики сначала.

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

4.2.2 Связь с компьютером

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

Подключение может быть осуществлено через USB-кабель, либо через локальную сеть, когда устройства подключены к одной точке доступа Wi-Fi.

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

В случае подключения по кабелю устройство находится в состоянии зарядки. Однако когда устройство заряжается, сбор статистики службой batteryststs приостанавливается. Для решения этой проблемы была использована возможность искусственно выключать режим зарядки на устройстве командой adb shell dumpsys battery set usb 0. После команды устройство продолжает заряжаться, но операционная система ведёт себя так, будто устройство не заряжается. Очевидно, что в этом случае результаты также могут быть неточными, поэтому искажения данного способа будут дополнительно рассмотрены в подразделе 7.1.

4.3 Автоматизация процесса

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

В теории, это может быть сделано двумя способами: обращением к командной оболочке из самого приложения, либо обращением к оболочке через средства Android Debug Bridge с компьютера. При проверке оказалось, что первый вариант невозможен, так как требует особого разрешения операционной системы, которое не выдаётся сторонним приложениям [27]. Поэтому сбор и сброс статистики необходимо осуществлять через Android Debug Bridge.

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

Был написан zsh-скрипт estimation.sh (рис. 9), который в цикле для каждого виджета сбрасывает статистику батареи и запоминает время начала теста. Так как способ запуска измерений пока неизвестен, в коде оставлены пустые строки. После запуска измерений, скрипт ожидает до окончания теста плюс одну секунду, после чего записывает время окончания теста, а также собранную статистику. После выполнения измерений для каждого виджета, записывается статистика процессора.

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

Рис. 9 Листинг части скрипта для проведения измерений



5. Составление списка элементов

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

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

Для составления списка элементов был взят список всех сущностей пакета android.widget в Android 10 SDK Platform (Приложение). После этого из списка были исключены следующие сущности:

• deprecated классы, так как они не рекомендуются к использованию разработчиками ОС и в будущих версиях могут быть удалены;

• интерфейсы и классы-адаптеры, так как они не являются виджетами;

• абстрактные классы, так как невозможно создать объект такого класса;

• вспомогательные классы, так как они не являются виджетами;

• виджеты, требующие наличие адаптера или презентера для отображения;

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

После этого остался список самостоятельных элементов, которые можно независимо тестировать:

• AutoCompleteTextView

• Button

• CalendarView

• Checkbox

• CheckedTextView

• Chronometer

DatePicker

EditText

ImageButton

ImageSwitcher

ImageView

MultiAutoCompleteTextView

NumberPicker

ProgressBar

RadioButton

RatingBar

SearchView

SeekBar

Space

Switch

TextClock

TextSwitcher

TextView

TimePicker

ToggleButton

VideoView

View



6. Измерение одного виджета

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

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

6.1 Проектирование автоматических тестов

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

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

6.1.1 Процесс запуска Activity

Появляется необходимость запускать тестирование не только через автоматические тесты, но и с запуском Activity. Запуск Activity может быть произведён как с компьютера, так и без взаимодействия с ним. Также появляется необходимость сравнения результатов измерений при отображении виджета через запуск автотеста и запуск Activity. Результат такого сравнения представлен в подразделе 7.2.

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

Для достижения такого поведения, именно Activity на стадии своей инициализации должна иметь информацию о номере виджета, и устанавливать его на экран. После чего Activity должна ждать столько, сколько нужно для тестирования виджета, и завершаться.

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

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

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

6.1.2 Передача данных при запуске теста

Ещё одна проблема появляется при передаче номера тестируемого виджета автотесту. По умолчанию возможности передавать дополнительные данные из команды запуска теста в код теста нет, но её можно добавить, расширив класс Instrumentation. По умолчанию, в приложении используется класс AndroidJUnitRunner в качестве Instrumentation, поэтому мой класс MyTestRunner будет наследовать и расширять возможности AndroidJUnitRunner (рис. 10).

Было решено передавать в приложение 2 параметра: индекс виджета и время его тестирования. Время будет удобнее определять в единственном месте, этим местом будет zsh-скрипт. После этого остаётся в файле build.gradle сменить testInstrumentationRunner на написанный com.yundin.estimation.MyTestRunner.

Рис. 10 Листинг класса MyTestRunner



6.1.3 Обработка объекта виджета

Некоторые элементы, например TextView или ImageView, требуют наполнения каким-нибудь содержимым, чтобы отображаться на экране. Некоторые элементы требуют менее тривиальных манипуляций перед отображением. Чтобы унифицировать процесс обработки элемента перед и после добавления на экран, было принято решение создать класс ViewWrapper, который будет содержать класс требуемого представления, а также методы beforeAdd и afterAdd, которые будут вызваны до добавления на экран и после добавления на экран соответственно.

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

1. Создаётся объект класса представления, содержащегося в объекте ViewWrapper;

2. Вызывается метод beforeAdd для созданного объекта;

3. Объект устанавливается в качестве наполнения Activity;

4. Вызывается метод afterAdd для добавленного объекта.

Были написаны наследники класса ViewWrapper, которые будут наполнять виджеты минимальным содержимым (рис. 11). В Activity будет формироваться массив, содержащий объект ViewWrapper для каждого тестируемого виджета.



Рис. 11 Листинг класса ViewWrapper и части его наследников

6.2 Выбор фреймворка автоматического тестирования

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

• appium;

• espresso;

• kakao;

Appium не является подходящим, так как он не всегда стабильно работает, а также не поддерживает старые версии Android.

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

Kakao и Kaspresso в свою очередь основываются на Espresso, но каждый по-своему исправляет избыточность синтаксиса с помощью возможностей языка Kotlin, но Kaspresso имеет расширенную функциональность, поэтому был выбран данный фреймворк.