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

В подразделах 4.2.2 и 6.1.1 обосновывается необходимость сравнения результатов измерений, проведённых в разных условиях.



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

В этом подразделе будут протестированы сценарии измерений при подключённом USB-кабеле с искусственно отключённым режимом зарядки и при питании только от батареи.

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

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

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

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



Рис. 12 Результаты сравнения сценариев измерения. Красные столбцы -- 3 измерения с подключённым кабелем. Синие столбцы -- к устройству ничего не подключено

Сравнение показало, что результаты измерения по разным сценариям достаточно сильно отличаются (рис. 12), но разница между измерениями без подключения к компьютеру также довольно большая и такому способу доверять сложно. В то же время при подключённом кабеле результаты относительно стабильные.

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

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

Тестирование так же будет производится на виджете AutoCompleteTextView.

Автотест будет запущен командой adb shell am instrument. Activity, как и ранее, запускается командой adb shell am start.

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

Рис. 13 Результаты сравнения сценариев измерения. Красные столбцы -- измерения, запущенные через Activity. Синие столбцы -- измерения, запущенные через автотест

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

Сравнение сценариев измерения показало, что стабильней всего себя показывает вызов Activity напрямую при подключённом USB-кабеле. Для реализации данного сценария для всех виджетов скрипт estimation.sh был модифицирован до скрипта activity_estimation.sh (рис. 14).

Рис. 14 Листинг части скрипта activity_estimation.sh

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

После работы скрипта filter_bat.py файлы содержат только информацию по тестируемому приложению, но она понадобится не в полном объёме. Для сравнения достаточно получить затраченное процессорное время, а также количество mAh.

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

Скрипт sum_cpu.py помогает просуммировать процессорное время, потраченное на исполнение системного и пользовательского кода во время работы приложения. Изначально данные представлены в формате, понятном человеку (например, u=240ms s=50ms), но компьютер сравнивать такие строки не сможет. Скрипт переводит данную строку в количество миллисекунд и записывает следующей строкой.

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

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

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

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



Рис. 15 Результаты измерений. Синие столбцы -- процессорное время в мс

Красные столбцы -- количество затраченных mAh.

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

Из результатов можно сделать и более неожиданные выводы. Например, виджет Space, заявленный как легковесное View, на деле потребляет больше ресурсов устройства, чем оригинальное View. Также MultiAutoCompleteTextView потребляет ощутимо меньше энергии, чем подобные ему AutoCompleteTextView, и даже EditText.



Рис. 16 Результаты измерений. Синие столбцы -- процессорное время в мс. Красные столбцы -- количество затраченных mAh

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

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



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

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

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

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

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

• прослушивание событий открытия нового экрана;

• прослушивание событий добавления новых элементов на текущий экран;

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

• вывод результата.

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

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

• HierarchyAnalyzer -- абстракция с методом analyzeDynamicHierarchy и полями типа Adviser и RecommendationOutputter. Этот класс будет слушать изменения в существующих иерархиях элементов, обращаясь к Adviser, чтобы сравнить элемент с имеющимися в базе данных и к RecommendationOutputter, чтобы вывести полученный результат.

• Adviser -- абстракция с методом, который ищет оптимальный элемент, подобный заданному. Может возникнуть необходимость делать это асинхронно, так как поиск будет связан с работой с базой данных, поэтому метод findAlternativeAsync помимо имени класса элемента принимает callback, через который будет возвращён результат.

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

Отношения между описанными частями представлены на рис. 17.

Рис. 17 Структурная диаграмма библиотеки

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

Теперь нужно определиться, какими инструментами предстоит пользоваться при написании кода библиотеки. Самое основное -- язык написания программы. Для разработки встраиваемой библиотеки необходимо использовать язык программирования Java и/или Kotlin. Дополнительно могут быть использованы модули, скомпилированные в.so файл, и написанные на любом языке, поддерживающим такую компиляцию.

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

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

В библиотеке предстоит отслеживать смену экранов и динамическое изменение иерархий элементов, в Android SDK для этого имеются такие средства как Application.ActivityLifecydeCallbacks, FragmentManager.FragmentLifecycleCallbacks и ViewGroup.OnHierarchyChangeListener. ActivityLifecycleCallbacks используются для отслеживания изменений состояния жизненного цикла Activity. Его удобно использовать, чтобы определять, что создалась новая сущность Activity (для этой сущности будет вызван метод жизненного цикла onCreate). FragmentLifecycleCallbacks может использоваться для отслеживания жизненного цикла Fragment (компонент, который может представлять собой отдельный экран или его часть). OnHierarchyChangeListener в свою очередь позволяет отслеживать динамические изменения иерархии элементов графического интерфейса.

Так как ViewGroup.OnHierarchyChangeListener полностью покрывает все текущие сценарии использования FragmentManager.FragmentLifecycleCallbacks, было решено использовать Application.ActivityLifecycleCallbacks для определения появления новых Activity вместе с ViewGroup.OnHierarchyChangeListener, чтобы находить новые сущности Fragment и вручную добавляемые программистом представления.

10.3 База данных

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

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

База данных содержит рекомендации по замене следующих виджетов:

• ProgressBar -- Switch

• DatePicker -- CalendarView

• TimePicker -- AutoCompleteTextView

• AutoCompleteTextView - EditText

• CalendarView -- EditText

• RadioButton -- Switch with custom logic

• Switch -- Checkbox

• Checkbox -- TextSwitcher

• SearchView -- EditText

• NumberPicker -- Seekbar

• Imagebutton -- ImageSwitcher

• Seekbar -- EditText

• TextSwitcher -- ImageSwitcher

• RatingBar -- EditText

• EditText -- MultiAutoCompleteTextView

• ImageSwitcher -- ToggleButton

• Space -- View

• Button -- TextView

• TextView -- ImageView

• MultiAutoCompleteTextView -- ToggleButton

• ImageView -- CheckedTextView

• ToggleButton -- CheckedTextView

• CheckedTextView -- View with background

Созданная база данных помещена в директорию assets модуля hierarchy- checker, чтобы иметь доступ к бинарному файлу базы из библиотеки.

10.4 Разработка

Перед началом написания кода библиотеки встаёт вопрос организации кода.

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

Сам проект будет удобно разделить на несколько модулей, чтобы хранить весь код в одном проекте. Модуль estimation содержит весь код, необходимый для проведения измерений. Модуль hierarchy-checker содержит код встраиваемой библиотеки. Модуль example подключает модуль hierarchy- checker и демонстрирует работу библиотеки.

Модуль estimation в корневой директории содержит все используемые скрипты, а также результаты измерений. В директории src/androidTest содержится класс MyTestRunner, а также код автотестов. В директории src/main находятся наследники ViewWrapper, а также класс MainActivity.

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

При написании кода было решено начать с описания спроектированной архитектуры в синтаксисе языка программирования Kotlin. UIManager -- singleton-объект, содержащий методы init и getActivityRoot. Первый метод -- точка входа в приложение, он принимает объект приложения и ничего не возвращает. getActivityRoot принимает на вход объект Activity и возвращает корневое представление иерархии, привязанное к этому Activity.

Adviser -- интерфейс с методом findAlternativeAsync, который принимает имя класса представления, которое необходимо проанализировать, а также callback, через который будет возвращён результат. RecommendationOutputter тоже интерфейс с методом output, принимающим объект View, для которого сформирована рекомендация, и сама рекомендация в виде строки.

HierarchyAnalyzer -- абстрактный класс, у которого имеется конструктор, принимающий реализации Adviser и RecommendationOutputter и сохраняющий их в поля на уровне абстрактного класса. Также он содержит абстрактный метод analyzeDynamicHierarchy, который принимает корень иерархии элементов, которую необходимо проанализировать.

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

В качестве реализации интерфейса RecommendationOutputter используется LogOutputter, выводящий информацию в логи устройства. При вызове метода output реализация проходит по всем родительским элементам, чтобы составить полный адрес текущего элемента в иерархии. Для смены порядка родительских элементов (идём снизу вверх по иерархии, выводим её сверху вниз) используется стек. После этого формируется сообщение, содержащее класс объекта, его расположение в иерархии и совет по оптимизации. Сообщение выводится в логи устройства.

Класс DatabaseAdviser реализует интерфейс Adviser и содержит в поле класса объект AdviceHelper, который абстрагирует взаимодействие с базой данных, а также ThreadPoolExecutor, который сохраняет несколько потоков исполнения, которые могут быть многоразово использованы или завершены, если дополнительных задач не поступает в течение 30 секунд. Предполагается, что его использование сократит издержки на создание новых потоков за счёт переиспользования уже существующих.

При вызове метода findAlternativeAsync на потоке, который предоставляет объект ThreadPoolExecutor, вызывается метод getAdvice у AdviceHelper, который возвращает более эффективный аналог Но чтобы сформировать наиболее полный список аналогов, метод getAdvice вызывается ещё раз для результата предыдущего вызова. Так происходит до тех пор, пока программа не достигнет самого оптимального виджета. Все виджеты будут описаны в результате, который уже на главном потоке передаётся в переданный методу callback. В иерархии реального приложения некоторые названия виджетов могут отличаться от того, что есть в базе данных. Например, вместо TextView можно встретить AppCompatTextView. Такая замена совершается операционной системой и предусматривается алгоритмами поиска в базе данных.

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

В методе init класса UIManager создаются конкретные реализации Adviser и RecommendationOutputter, они передаются в конструктор ConcreteHierarchyAnalyzer. Затем на объекте приложения вызывается registerActivityLifecycleCallbacks, а в реализации Application.ActivityLifecycleCallbacks при приобретении какой-либо Activity состояния Started, с помощью метода getActivityRoot находится корень его иерархии и передаётся в метод analyzeDynamicHierarchy созданного ранее HierarchyAnalyzer. Итоговая библиотека имеет структуру, представленную на рис 18.



Рис. 18 Диаграмма классов библиотеки



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

Весь исходный код проекта, а также необработанные результаты всех проведённых измерений были опубликованы на GitHub [28].

Для демонстрации работы библиотеки в проект был добавлен модуль example. Модуль содержит приложение, способное динамически добавлять на экран объект класса android.app.Fragment с наполнением, объект класса androidx.fragment.app.Fragment с наполнением, объекты класса TextView, а также открывать новое Activity (рис. 19). К проекту подключена библиотека из модуля hierarchy-checker и в методе onCreate наследника класса Application у объекта UIManager был вызван метод init, в который был передан контекст приложения.



Рис. 19 Интерфейс приложения из модуля example

Так как главный экран приложения уже содержит кнопки и текстовые поля, сразу после открытия приложения в логах устройства появляются советы по оптимизации открывшегося экрана (рис. 20).

Рис. 20 Логи устройства после открытия приложения из модуля example

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



Заключение

Для разработки системы контроля и управления энергопотреблением элементов графического интерфейса на устройствах под управлением операционной системы Android были проведены измерения 27 виджетов в пакете android.widget в Android 10 SDK Platform. Результаты измерений показали соотношения энергопотребления между всеми измеренными элементами.

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

Существенными ограничениями данной работы являются следующие факторы:

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

• Отсутствие доступа к устройству без сторонних приложений и без служб Google Play Services;

• Наличие лишь одного устройства для тестирования.

Изначально для измерения энергопотребления устройства планировалось использовать специализированное оборудования Monsoon Power Monitor. Использование данного оборудования позволило бы более точно измерить энергопотребление устройства, причём не за всё время тестирования виджета, а за более малые промежутки. Инструмент Battery Historian также имеет возможность обработки результатов работы Monsoon Power Monitor. В дальнейших исследованиях можно повторить измерения с использованием более точного стороннего оборудования.

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

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

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



Глоссарий

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

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

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

Фреймворк автоматического тестирования -- программное обеспечение, позволяющее создавать тесты для автоматизированного тестирования приложения. Частные случаи: appium, espresso, kakao, kaspresso.

Activity -- компонент приложения, имеющий графический интерфейс, и позволяющий пользователю с ним взаимодействовать.

Android -- мобильная операционная система с открытым исходным кодом.

Android Debug Bridge -- инструмент командной строки, позволяющий взаимодействовать с устройством.

Android Profiler -- инструмент, предоставляющий данные о потребляемых приложением ресурсах устройства в реальном времени.

Battery Historian -- инструмент анализа и визуализации расхода батареи устройства на основании отчётов операционной системы.

BroadcastReceiver -- компонент приложения, позволяющий принимать и обрабатывать системные события.

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



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

Автотест -- тест для автоматизированного тестирования приложения.

ОС -- операционная система. adb -- Android Debug Bridge.

API -- application program interface. mAh -- миллиампер-час. zsh -- Z shell.



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

1. Experience report: Understanding cross-platform app issues from user reviews / Y. Man [и др.] // 2016 IEEE 27th International Symposium on Software Reliability Engineering (ISSRE). IEEE. 2016. С. 138--149.

2. Wasserman A. I. Software engineering issues for mobile application development // Proceedings of the FSE/SDP workshop on Future of software engineering research. 2010. С. 397--400.

3. Ickin S., Petersen K., Gonzalez-Huerta J. Why do users install and delete Apps? A survey study // International Conference of Software Business. Springer. 2017. С. 186--191.

4. Diversity in smartphone usage / H. Falaki [и др.] // Proceedings of the 8th international conference on Mobile systems, applications, and services. 2010. С. 179--194.

5. Pentikousis K. In search of energy-efficient mobile networking // IEEE Communications Magazine. 2010. Т 48, № 1. С. 95--103.

6. Василенко Д., Бирюков Е. Методы снижения потребления энергии современными портативными устройствами // Компоненты и Технологии. 2005. № 50.

7. Tuysuz M. F., Ucan M., Trestian R. A real-time power monitoring and energy-efficient network/interface selection tool for android smartphones // Journal of Network and Computer Applications. 2019. Т 127. С. 107--121.

8. Li D., Halfond W. G. J. An investigation into energy-saving programming practices for android smartphone app development // Proceedings of the 3rd International Workshop on Green and Sustainable Software. 2014. С. 46--53.

9. Android power management and analyses of power consumption in an Android smartphone / G. Bai [и др.] // 2013 IEEE 10th International Conference on High Performance Computing and Communications & 2013 IEEE International Conference on Embedded and Ubiquitous Computing. IEEE. 2013. С. 2347-- 2353.

10. Detecting display energy hotspots in Android apps / M. Wan [и др.] // 2015 IEEE 8th International Conference on Software Testing, Verification and Validation (ICST). IEEE. 2015. С. 1--10.

11. Improving Energy Efficiency of Android Devices by Preventing Redundant Frame Generation / G. Lee [и др.] // IEEE Transactions on Mobile Computing. 2018. Т 18, № 4. С. 871--884.

12. Intelligent frame refresh for energy-aware display subsystems in mobile devices / Y. Huang [и др.] // Proceedings of the 2014 international symposium on Low power electronics and design. 2014. С. 369--374.

13. Appscope: Application energy metering framework for android smartphone using kernel activity monitoring / C. Yoon [и др.] // Presented as part of the 2012 {USENIX} Annual Technical Conference ({USENIX}{ATC} 12). 2012. С. 387--400.

14. Seo C., Malek S., Medvidovic N. An energy consumption framework for distributed java-based systems // Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering. 2007. С. 421--424.

15. Mobile application and device power usage measurements / R. Murmuria [и др.] // 2012 IEEE Sixth International Conference on Software Security and Reliability. IEEE. 2012. С. 147--156.

16. Oliveira W., Oliveira RCastor F. A study on the energy consumption of android app development approaches //2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR). IEEE. 2017. С. 42--52.

17. Экономия энергии посредством компрессии во встроенной среде Java / Ч. Гуанджиу [и др.] // Компоненты и Технологии. 2004. № 39.

18. Маурицио С. Переоценка подхода к снижению потребления энергии // Компоненты и Технологии. 2008. № 82.

19. Пустовалов Е. В., Тюрликов А. М. Анализ режимов энергосбережения мобильного пользовательского устройства // Известия высших учебных заведений. Приборостроение. 2013. Т. 56, № 8.

20. Кафтанников И. Л., Руднев В. А. Оптимизация энергопотребления микроконтроллерных систем // Вестник Южно-Уральского государственного университета. Серия: Компьютерные технологии, управление, радиоэлектроника. 2013. Т. 13, № 2.

21. An empirical study of the energy consumption of android applications / D. Li [и др.] // 2014 IEEE International Conference on Software Maintenance and Evolution. IEEE. 2014. С. 121--130.

22. Адаптивное управление приложениями мобильных телефонов для увеличения продолжительности их автономной работы / Л. Л. Утин [и др.] // Доклады Белорусского государственного университета информатики и радиоэлектроники. 2018. 2 (112).

23. Multi-objective optimization of energy consumption of GUIs in Android apps / M. Linares-Vasquez [и др.] // ACM Transactions on Software Engineering and Methodology (TOSEM). 2018. Т 27, № 3. С. 1--47.

24. Kim D., Jung N., Cha H. Content-centric display energy management for mobile devices // 2014 51st ACM/EDAC/IEEE Design Automation Conference (DAC). IEEE. 2014.С. 1--6.

25. Bugreport file format. URL: https: / / android. googlesource. com / platform/ frameworks/ native/ + / master/ cmds/ dumpstate/bugreport- format.md (дата обр. 10.05.2020).

26. dumpsys. URL: https: / / developer. android. com/ studio/ command - line/dumpsys (дата обр. 10.05.2020).

27. Manifest.permission.DUMP. URL: https: / / developer. android. com/ reference/android/Manifest.permission#DUMP (дата обр. 10.05.2020).

28. Yundin V UIEnergyManagement. URL: https: / / github. com / Yundin / UIEnergyManagement (дата обр. 15.05.2020).



Приложение

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

• AbsListView

• AbsoluteLayout

• AbsSeekBar

• AbsSpinner

• ActionMenuView

• Adapter

• AdapterView

• AdapterViewAnimator

• AdapterViewFlipper

• Advanceable

• AlphabetIndexer

• AnalogClock

• ArrayAdapter

• AutoCompleteTextView

• BaseAdapter

• BaseExpandableListAdapter

• Button

• CalendarView

• Checkable

• CheckBox

• CheckedTextView

Chronometer

CompoundButton

CursorAdapter

CursorTreeAdapter

DatePicker

DialerFilter

DigitalClock

EdgeEffect

EditText

ExpandableListAdapter

ExpandableListView

Filter

Filterable

FilterQueryProvider

FrameLayout

Gallery

GridLayout

GridView

HeaderViewListAdapter

HeterogeneousExpandableList

HorizontalScrollView

ImageButton

• ImageSwitcher

• ImageView

• LinearLayout

• ListAdapter

• ListPopupWindow

• ListView

• Magnifier

• MediaController

• MultiAutoCompleteTextView

• NumberPicker

• OverScroller

• PopupMenu

• PopupWindow

• ProgressBar

• QuickContactBadge

• RadioButton

• RadioGroup

• RatingBar

• RelativeLayout

• RemoteViews

• RemoteViewsService

• ResourceCursorAdapter

• ResourceCursorTreeAdapter

• Scroller

• ScrollView

• SearchView

• SectionIndexer

• SeekBar

• ShareActionProvider

• SimpleAdapter

• SimpleCursorAdapter

• SimpleCursorTreeAdapter

• SimpleExpandableListAdapter

• SlidingDrawer

• Space

• Spinner

• SpinnerAdapter

• StackView

• Switch

• TabHost

• TableLayout

• TableRow

• TabWidget

• TextClock

TextSwitcher

TextView

ThemedSpinnerAdapter

TimePicker

Toast

ToggleButton

Toolbar

TwoLineListItem

VideoView

ViewAnimator

ViewFlipper

ViewSwitcher

WrapperListAdapter

ZoomButton

ZoomButtonsController

ZoomControls

Размещено на Allbest.ru