Практическая работа №11. Работа в ос android


Download 192.51 Kb.
bet1/4
Sana09.09.2022
Hajmi192.51 Kb.
#803400
TuriПрактическая работа
  1   2   3   4
Bog'liq
Практическая работа12
Pedagogik jarayonlarda AKT vositalari hamda innovatsion yondashuv, 4 классы, tuzuklar uz, 1-mavzu, 1- topshiriq 2021-2022 KTE, 2-dedline 632-20, deadline 1, A Ismoilov Tezis mono organishim kk— копия, Elektronika va sxemalar fanidan yakuniy nazorat test, Цели и задачи и методы научного иследования, p.r.3, МСС сам раб 2, p.r. 1, мустакил таълим 1 lotincha, Mustaqil talim 2-25

Практическая работа № 11. Работа в ОС Android


Теоретическая часть:
Android всегда работал иначе. Здесь можно запустить множество различных приложений и все они будут оставаться в памяти и даже смогут работать в фоне. Вы открываете браузер, вводите адрес и, пока загружается страница, запускаете почтовый клиент и читаете письма. Все как на десктопе, с тем исключением, что вам не нужно заботиться о закрытии приложений, система сделает это сама, когда оперативная память подойдет к концу или ее не хватит для размещения запускаемого приложения (само собой, в первую очередь в расход пойдут редко используемые приложения). Этот механизм называется lowmemorykiller.

Имея права root, настройки lowmemorykiller можно регулировать напрямую или с помощью специальных приложений
Важным элементом системы многозадачности были службы (service). Это особые компоненты приложений, которые могли работать в фоне абсолютно в любых условиях: включен экран или выключен, свернуто приложение или развернуто, службам плевать даже на то, запущено ли родительское приложение вообще. Оно просто говорило: «Эй, Android, мне нужны ресурсы процессора, я хочу сделать некоторые расчеты» — и получало эти ресурсы. В терминологии Android такой запрос к системе называется wakelock (а если точнее — процессорный wakelock).
Однако поддержка такого мощного и полезного инструмента сыграла с Google злую шутку. Появилось огромное количество приложений, которые плодили службы на каждый чих, постоянно выполняли какую-то работу и не давали смартфону спать. Установив на смартфон сотню приложений, пользователь получал несколько десятков служб, каждая из которых периодически что-то делала (обновить ленту твиттера, пока телефон спит, — это же так важно).
Дела обстояли настолько плачевно, что китайские производители, не обремененные задачей сохранить совместимость с оригинальным Android (это требуется, если хотите устанавливать на свои смартфоны Play Store), просто отключили в своих смартфонах механизмы поддержания жизненного цикла служб для несистемных приложений.
Продвинутые юзеры шли другим путем: они получали права root и устанавливали приложение Greenify, которое позволяло заморозить службы выбранных приложений так, чтобы их уже никто не смог разбудить. Существовали и более радикальные варианты, например снести весь софт, которым пользуешься реже одного раза в сутки.
Сама Google также предпринимала определенные действия для борьбы с «ядовитыми» службами. Большой шаг в этом направлении был сделан в Android 4.4, где появился интеллектуальный механизм, который определял, не работает ли служба слишком много времени и не сильно ли она грузит процессор, и, если это оказывалось так, прибивал ее на месте и не давал запуститься. Даже на поверхностный взгляд эта версия системы жила на батарейке заметно дольше предыдущих.
В Android 6.0 Google пошла еще дальше и оснастила ее механизмом Doze, который после определенного времени неактивности смартфона (около одного часа) переводил его в специальный энергосберегающий режим. Одна из особенностей этого режима — запрет на wakelock, то есть ни приложения, ни службы просто не могут разбудить смартфон, чтобы выполнить какую-либо работу. На глаз Android 6.0 не стал жить дольше, так что неизвестно, сработал ли этот механизм вообще.
Шкала работы Doze
И наконец, в Android 8.0 Google пошла на радикальный шаг — запретила работу фоновых служб. Но с двумя исключениями:
Приложение в некоторых случаях, например когда оно находится на экране, может запускать службы, но Android прибьет их после ухода приложения в сон.
Видимые пользователю службы до сих пор разрешены. Это так называемый foreground service, служба, которая видна в панели уведомлений и имеет иконку в статусбаре.
Казалось бы, да, службы — это зло, но как теперь быть таким приложениям, как противоугонное, которое должно работать незаметно в фоне? Или тот же почтовый клиент? Из-за необходимости периодически проверять почту он должен висеть в панели уведомлений?
На самом деле нет. Google шла к запрету служб еще с версии 5.0, где появился так называемый JobScheduler. Это специальная подсистема, которая позволяет приложениям попросить Android выполнить ту или иную работу в такое-то время или при возникновении такого-то события (подключение к интернету, например). И да, JobScheduler сильно напоминает аналогичную функцию из iOS.
Binder
Вопреки расхожему мнению, Android с самых первых версий использовал песочницы для изоляции приложений. И реализованы они были весьма интересным образом. Каждое приложение запускалось от имени отдельного пользователя Linux и, таким образом, имело доступ только к своему каталогу внутри /data/data.
Друг с другом и с операционной системой приложения могли общаться только через IPC-механизм Binder, который требовал авторизации на выполнение того или иного действия. Этот же механизм использовался и для несколько других целей: с его помощью система оповещала приложения о системных событиях, таких как входящий вызов, пришедшее СМС, втыкание зарядки и так далее. Приложения получали сообщения и могли на них отреагировать.

Работу Binder обеспечивают драйвер в ядре Linux и Service Manager
Эта особенность дала Android очень широкие возможности автоматизации, о которых мы знаем благодаря таким приложениям, как Tasker, Automate или Locale. Все эти приложения доступны и для Android 8, разве что некоторые опасные возможности, такие как включение/выключение режима полета, теперь запрещены для использования обычными приложениями.
Система оповещения базируется на интентах (intent), специальном механизме, реализованном поверх Binder и предназначенном для обмена информацией между приложениями (или ОС и приложениями), а также запуска компонентов приложений. С помощью интентов можно оповещать приложения о событиях, попросить систему открыть приложение для обработки определенных типов данных (например, чтобы открыть определенную страницу в браузере, достаточно послать широковещательный интент со ссылкой на страницу, и на него откликнутся все приложения, способные отображать веб-страницы, либо только дефолтовый браузер) или просто запустить компонент того или иного приложения. Например, приложения в Android запускаются не напрямую, а с помощью интентов.
К сожалению, как и службы, интенты стали проблемой для Google и пользователей Android. Дело в том, что широковещательные интенты, используемые для уведомления приложений о событиях, приходят сразу ко всем приложениям, которые заявили, что способны на них реагировать. А чтобы приложение смогло среагировать на интент, его надо запустить. Картина получается такая: на смартфоне есть двадцать приложений, которые могут реагировать на интент android.net.conn.CONNECTIVITY_CHANGE, и при каждом подключении к сети и отключении от нее система запускает эти приложения, чтобы они смогли среагировать на интент. Как это сказывается на энергопотреблении — представьте сами.
Google исправила это недоразумение опять же в Android 8.0. Теперь приложения могут регистрировать обработчики широковещательных интентов только во время своей работы (за небольшими исключениями).

Download 192.51 Kb.

Do'stlaringiz bilan baham:
  1   2   3   4




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2022
ma'muriyatiga murojaat qiling