Архитектура Android-приложений. Часть I — истоки
В этой статье мы рассмотрим архитектуру Android-приложений.
Откровенно говоря, официальную статью Google по этой теме я считаю не очень полезной. Детально отвечая на вопрос «как», она совсем не объясняет «что» и «почему». Итак, вот моя версия, и, я надеюсь, она внесёт некоторую ясность. Да, кстати, я полностью одобряю чтение статей Google, поскольку они содержат полезную информацию, повторять которую я не собираюсь.
Архитектура ОС Android — немного истории
Как это часто бывает в IT, многие вещи не могут быть объяснены в отрыве от истории возникновения конкретного программного обеспечения. Вот почему мы должны обратиться к истокам ОС Android.
Разработка ОС Android была начата в 2003 молодой компанией Android Inc. В 2005 году эта компания была куплена Google. Я считаю, что главные особенности архитектуры Android были определены именно в этот период. Это заслуга не только Android Inc; архитектурные концепции и финансовые ресурсы Google оказали решающее влияние на архитектуру Android. Далее я приведу несколько примеров.
Если вы помните, 2003-2005 года были ознаменованы повышенным вниманием к AJAX приложениям. Я думаю, это оказало основополагающее влияние на архитектуру Android: во многих аспектах она ближе к архитектуре типичного AJAX приложения, нежели к десктопному GUI приложению, написанному на Java, C#, C++, VB и тп.
Не знаю, почему так произошло. Моя догадка — это придумал кто-то из Google в тот период, когда насыщенные интернет-приложения (Rich Internet Applications, RIA) в духе Google Docs или Gmail считались решением всех проблем. По-моему, эту идею нельзя назвать ни плохой, ни хорошей. Просто помните, что Android-приложения очень сильно отличаются от десктопных.
Влияние архитектурной философии Eclipse заметно в выборе принципа реализации GUI, который больше похоже на SWT, нежели на Swing.
В стандартах оформления кода Android присутствует «венгерская нотация», рождённая в стенах MS. Можно предположить, что тот, кто писал эти стандарты, ранее занимался разработкой под Windows.
Архитектурные уровни Android
Операционная система Android имеет три весьма различных и сильно отделённых друг от друга уровня:
Уровень Linux
Представьте себе, что вы — архитектор в молодой компании. Вы должны разработать ОС для нового типа устройств. Что вы будете делать?
Грубо говоря, у вас два пути: реализовывать собственные идеи, начав с нуля или же использовать существующую ОС и адаптировать её под свои устройства.
Реализация с нуля всегда звучит захватывающе для программистов. В эти моменты мы все верим в то, что в этот раз мы всё сделаем лучше, чем делают другие, и даже лучше, чем мы сами делали ранее.
Тем не менее, это не всегда практично. Например, использование ядра Linux заметно уменьшило стоимость разработки (возможно где-то и без того чрезмерно большую). Согласитесь, если кто-то решит создать нечто, напоминающее ядро Linux в его сегодняшнем состоянии, ему потребуется несколько миллионов долларов.
Если вы руководите Android Inc, то у вас по определению не может быть столько денег. Если вы руководите Google, то у вас такие деньги найдутся, но вы, скорее всего, подумаете дважды, прежде чем потратить их на создание собственной ОС. Так же вы потратите несколько лет, прежде чем достигните сегодняшнего состояния Linux; несколько лет задержки могут стать слишком большим опозданием при выходе на рынок.
В подобной ситуации компания Apple решила построить Mac OS на основе Free BSD. Android Inc приняла решение использовать Linux как основу для Android. Исходники как Free BSD, так и Linux, находятся в свободном доступе и предоставляют собой хорошую основу для любых разработок, будь то Apple или Google.
Но в то время запустить стандартный Linux на мобильном устройстве было невозможно (сейчас это уже не так). Устройства имели слишком мало оперативной и энергонезависимой памяти. Процессоры были значительно медленнее по сравнению с процессорами компьютеров, где обычно используется Linux. Как результат, разработчики Android решили минимизировать системные требования Linux.
Если рассматривать Linux на высоком уровне, то это комбинация ядра (без которого нельзя обойтись) и множества других, необязательных частей. Можно даже запустить одно ядро, без чего бы то ни было ещё. Так, Google вынуждена в любом случае использовать ядро Linux как часть ОС Android. Кроме того, были рассмотрены необязательные части и из них выбрано самое необходимое. Например, были добавлены сетевой фаервол IPTables и оболочка Ash. Любопытно, что добавили именно Ash, а не Bash, не смотря на то, что последний на порядок мощнее; вероятно, это решение было основано на том, что Ash менее требователен к ресурсам.
Разработчики Android модифицировали ядро Linux, добавив поддержку железа, используемого в мобильных устройствах и, чаще всего, недоступного на компьютерах.
Выбор Linux в качестве основы оказал огромное влияние на все аспекты ОС Android. Сборка Android, по сути, есть вариация процесса сборки Linux. Код Android находится под управлением git (инструмент, разработанный для управления кодом Linux). И так далее.
Пускай это всё и интересно, но вы, скорее всего, никогда не коснётесь всех этих специфических моментов до тех пор, пока ваша цель просто разработать приложения под Android. Исключение может составить разве что обзор файловой системы с помощью команд ash. Главное, что вы должны знать, разрабатывая приложения под Android — это уровень инфраструктуры приложения.
Вы можете спросить, как же быть, если необходимо разработать нативное приложение для Android? Google настоятельно не рекомендует делать этого. Технически, конечно, это возможно, но в дальнейшем у вас не будет возможности распространять это приложение нормальным способом. Так что подумайте дважды, прежде чем начать нативную разработку под Android, если конечно, вы не работает над Android Open Source Project (AOSP), т.е. собственно ОС Android.
Уровень инфраструктуры приложения
Несмотря на некоторое сходство Apple iOS и Android ОС, существуют значительные отличия между архитектурными решениями на инфраструктурном уровне обоих ОС.
Apple решила использовать Objective-C как язык программирования и среду выполнения приложения iOS. Objective-C выглядит более или менее естественным выбором для ОС, в основе которой лежит Free BSD. Можно рассматривать Objective-C как обычный C++ с кастомным препроцессором, который добавляет некоторые специфические лингвистические конструкции. Почему же нельзя использовать стандартный C++, на котором написана Free BSD? Мне кажется причина в том, что Apple старается всё делать в своём, «эппловском» стиле.
Основная идея в том, что приложения iOS написаны более или менее на том же языке, что и стоящая за ними ОС.
Android-приложения сильно отличаются в этом смысле. Они написаны на Java, а это совсем другая технология, нежели C++ (хотя синтаксис и унаследован от C++).
Почему это так? Почему, например, Android-приложения не написаны на C++? Со стороны Google я не нашёл никаких объяснений, поэтому могу поделиться лишь собственными соображениями.
Я думаю, основная причина состоит в необходимости одному и тому же приложению работать на различном аппаратном обеспечении. Эта проблема имеет место лишь для ОС Android; у ребят из Apple такой проблемы нет. iOS работает только на оборудовании собственного производства, и Apple полностью контролирует весь процесс. Для Android же всё наоборот: Google не контролирует производителей аппаратных средств. Например, ОС Android работает на процессорах с архитектурой x86, ARM и Atom (в комментах подсказывают, что x86 включает в себя Atom, и Android работает на x86, ARM, PPC и MIPS — примечание переводчика). На бинарном уровне эти архитектуры несовместимы.
Если бы архитекторы ОС Android выбрали тот же путь, что и архитекторы из Apple, разработчики приложений под Android были бы вынуждены распространять несколько версий одного и того же приложения одновременно. Это стало бы серьёзной проблемой, которая могла бы привести к краху всего проекта Android.
Для того, чтобы одно и то же приложение могло работать на разном аппаратном обеспечении, компания Google использовала контейнер-ориентированную архитектуру (container-based architecture). В такой архитектуре двоичный код выполняется программным контейнером и изолируется от деталей конкретного аппаратного обеспечения. Примеры всем знакомы — Java и C#. В обоих языках двоичный код не зависит от специфики аппаратного обеспечения и выполняется виртуальной машиной.
Конечно, есть и другой способ достигнуть независимости от аппаратного обеспечения на уровне двоичного кода. Как один из вариантов, можно использовать эмулятор аппаратного обеспечения, так же известный как QEMU. Он позволяет эмулировать, например, устройство с процессором ARM на платформе x86 и так далее. Google могла бы использовать C++ как язык для разработки приложений внутри эмуляторов. Действительно, Google использует такой подход в своих эмуляторах Android, которые построены на основе QEMU.
Очень хорошо, что они не пошли по такому пути, поскольку тогда кому-то пришлось бы запускать ОС на эмуляторе, требующем намного больше ресурсов, и, как итог, скорость работы снизилась бы. Для достижения наилучшего быстродействия эмуляция была оставлена только там, где этого нельзя было избежать, в нашем случае — в Android-приложениях.
Как бы то ни было, компания Google пришла к решению использовать Java как основной язык разработки приложений и среды их выполнения.
Я думаю, это было критически важное архитектурное решение, которое поставило Android в стороне от остальных мобильных ОС на основе Linux, представленных в настоящее время. Насколько мне известно, ни у одной из них нет совместимости двоичного кода на уровне приложений. Возьмём для примера MeeGo. Она использует C++ и фреймворк Qt; не смотря на то, что Qt кроссплатформенный, необходимость делать разные сборки для разных платформ не исчезает.
Выбрав Java, нужно было решить, какую виртуальную машину (JVM) использовать. Ввиду ограниченности ресурсов использование стандартной JVM было затруднено. Единственным возможным выбором было использование Java ME JVM, разработанной для мобильных устройств. Однако счастье Google было бы неполным без разработки собственной виртуальной машины, и появилась Dalvik VM.
Dalvik VM отличается от других виртуальных Java-машин следующим:
Также они добавили несколько пакетов с открытым кодом, не являющихся частью стандартного JDK: Bouncy Castle crypto API, HTTPClient с поддержкой разделения HTTP/HTTPS на стороне клиента.
Также Google добавила веб-браузер в уровень инфраструктуры приложения. Это не полноценный Google Chrome для мобильных устройств, но очень близок к нему, поскольку основан на том же движке WebKit и использует движок JavaScript V8 из Chrome. В конце концов, это крайне современный и высокотехнологичный браузер. Он может быть интегрирован в любые Android-приложения.
На сегодня это всё. В следующей статье мы сосредоточим внимание на архитектуре Android-приложений.
Апдейт от переводчика. В оригинале использовалась не совсем верная терминология. Спасибо всем тем, кто указал на эти ошибки.
Как Android пришел к AAB? Что будет с APK? Разбор
Не так давно прогремела новость о том, что Android отказывается от APK-файлов и переходит на AAB. Вы наверняка уже эту новость прочитали, во всём разобрались и успокоились, так как новость проходная. Тем не менее, мы считаем, что переход к новой системе публикации приложений App Bundle — это часть большого пути, которую проделала система Android, чтобы стать по-настоящему быстрой, эффективной и супероптимизированной платформой. Поэтому мы подготовили большой и очень интересный материал. И сегодня мы раскроем вам массу страшных тайн Android.
Проблема Android
У системы Android есть одна очень важная особенность, которая является как огромным преимуществом, так и огромной проблемой.
Поэтому вся история развития системы Android — это история борьбы, компромиссов и поиска баланса.
Условно историю Android можно поделить на 4 этапа: когда Android тормозил, много жрал, оптимизировался и, наконец, находился в балансе.
Этап 1. Dalvik: Android тормозит
Этап 2. ART: Android потребляет
Этап 3. Profiling: Android оптимизируется
Этап 4. AAB: Android балансирует
И сегодня мы поговорим про все четыре этапа. Но начнём с небольшой ремарки.
Чтобы соблюсти первые два базовых требования к системе, а именно: поддержка разных архитектур и простота программирования. В качестве основного языка программирования в системе Android была выбрана Java. Почему так?
У Java есть несколько классных свойств: он изначально был создан как мультиплатформенный: пишешь один раз — работает везде.
Но, есть и недостаток. Достигается это всё очень грязными методами, а именно при помощи виртуальной Java-машины. Тут стоит пояснить.
Дело в том, что люди пишут код на понятных для человека языках программирования, но машины не понимают такой код, они понимают машинный код, то есть бинарный код. А значит, в процессе финальной сборки приложения, человеческий код нужно перевести в машинный код. Такой процесс называется компиляцией. А приложение скомпилированное под требуемую архитектуру называется нативным.
Нативные приложения — самые быстрые, потому они записаны на языке понятном железу. А теперь смотрите внимательно: приложения написанные на Java компилируется не в нативный код, а в промежуточный код, который называется байт-кодом.
А вот уже из этого байт-кода можно достаточно быстро перевести приложение под любую архитектуру при помощи виртуальной Java-машины.
Иными словами, приложения написанные на Java — это всегда не нативные приложения, которые требуют дополнительной пост-компиляции., а значит дополнительных издержек.
И Android-приложения — не исключение.
Единственное что, в Android вместо виртуальной машины Java используется собственная, куда более эффективная, виртуальная машина Dalvik или ART. А также вместо байт-кода Java используется собственный, куда более эффективный, байт-код, который внутри APK-шек записыватся в файлах с расширением DEX (анимация).
Тем не менее, это не меняет сути, т.к. Android-приложения содержат много Java-кода и это проблема, которую как-то нужно решать. Так вот на протяжении своей истории эта проблема решалась по-разному.
ЭТАП 1. Dalvik: Android тормозит
Вплоть до Android версии 4.4 KitKat приложения запускались через виртуальную машину Dalvik, которая работала по принципу Just In time компиляции или JIT-компиляции. То есть приложения транслировались в нативный код прямо во время исполнения, то есть “на лету”.
Мы уже рассказывали про JIT-компиляцию в ролике про Android на Windows 11, если не видели — посмотрите. Е
Ответ простой: такой подход позволял экономить много памяти — в первую очередь, оперативной. Тогда устройства были не такие мощные как сейчас, у многих на борту было не больше 200 Мб ОЗУ. А JIT-компиляция позволяла, так сказать, загружать в оперативку только ту часть приложения, которая используется.
Плюс ко всему, сам по себе байт-код компактный, поэтому и на диске приложения занимали очень мало места.
Да и были возможности оптимизации: скомпилированный код можно записать в кэш и дальше уже из кэша брать как бы нативный код. В общем, можно жить…
Помните же Dalvik-кэш? Вот это как раз он…
ЭТАП 2. ART: Android потребляет
Тем не менее пользователи и приложения становились всё более требовательными к отзывчивости. И в Android 4.4 KitKat была представленная новая виртуальная машина ART или Android Runtime. А в Android 5.0 Lollipop ART полностью заменила Dalvik.
Вместе с новой средой выполнения, Android поменял стратегию на 180 градусов. Вместо компиляции во время исполнения приложения ART стала использовать компиляцию перед исполнением. То есть компиляция теперь делается во время установки приложения. Такой вид компиляции называет Ahead Of Time компиляция или сокращенно AOT-компиляция.
И естественно, Android залетал! Приложения стали быстрее запускаться и работать без каких либо дополнительных задержек. Фактически все приложения внезапно стали “нативными” для железа!
Вообще согласитесь, Android 5-й версии был хорош. Система летала, представили Material Design… Просто счастье.
ЭТАП 3. Profiling: Android оптимизируется
Поэтому в Google подумали: компилируя приложение целиком, не делаем ли мы лишнюю работу? А вот и делаем!
Как выяснилось, по статистике пользователи очень редко используют более 10-20% кода приложения. Иными словами, в большинстве случаев заранее будет достаточно скомпилировать только малую часть, которая будет действительно использоваться часто, а для редких уголков приложения, в которые мы не заходим, можно будет и JIT-компиляцию использовать.
Но вот только, какую часть кода нужно скомпилировать заранее, ведь даже разработчики приложений не знают, как именно пользователи будут юзать их программу.
Поэтому в Android 7.0 Nougat Google представили технологию PGC — Profile guided compilation. То есть это компиляция, основанная на профилях использования приложения. Думаю вы уже примерно догадываетесь как эта штука работает.
Естественно от AOT-компиляции на этапе установки отказались. Поэтому во время первого запуска приложения стали снова использовать старую добрую JIT-компиляцию, результат которой, естественно, сохранится в кэш. Тоже самое повторится и во время второго запуска, и третьего. Но когда вы поставите телефон на зарядку и крепко заснете, тогда проснется так называемый «Демон» (это, если что, официальное название специальной службы), который проанализирует кеши всех приложений, которые вы использовали в течение дня. После этого он создаст профили с оптимизированным кодом. И так каждую ночь…
Но и эту проблему Google решили. В Android 9.0 Pie они представили Облачные профили.
Они просто собрали профили приложений со всех пользователей, проанализировали их и создали усредненный профиль для каждого приложения, который теперь стал автоматически скачиваться во время установки приложения из Google Play Store.
Всё это позволило значительно повысить скорость первого запуска приложения, да и в целом, первые дни использования девайса. А, как известно, первое впечатление, второй раз произвести не получится.
И вот мы с вами видим какой огромный путь проделала система Android.
Система стала в десятки раз отзывчивее, оптимизированее и дружелюбнее к пользователям.
Но несмотря на огромное количество изменений под капотом самой системы оставалось одна очень важная проблема: огромное разнообразие устройств. Поэтому переходим к заключительному этапу становления Android.
ЭТАП 4. AAB: Android балансирует
На последнем этапе Google решил уменьшить не только размер скомпилированного кода, но и размер самих приложений.
И в 2018 году они представили новый формат публикаций приложений, который называется Android App Bundle, или просто AAB.
Это не новая технология. Всё это уже давно работает, но просто только сейчас она станет единственным правильным способом публикации приложений. В чём прикол?
Система Android поддерживает 4 архитектуры, 6 разрешений графики и более 150 языков.
Поэтому если собрать универсальный APK, который будет включать в себя вообще все необходимые файлы для всех девайсов (всю графику, все библиотеки, все языки) — такой файл будет просто неподъемно весить. А если собрать по идеальной APK-шке под каждое устройство, то придется генерировать тысячи таких APK.
Поэтому, чтобы разработчики не парились, Google придумал умную систему публикации.
Во время финальной сборки приложения они просто формируют бандл, то есть архив вообще со всеми необходимыми файлами под все девайсы. Делается это автоматически через Android Studio. И загружают этот архив в Google Play.
А дальше, когда вы заходите в Google Play и скачиваете приложение, то Google Play сам собирает для вас идеальную APK-шку только с необходимым набором данных: подгружается только графика необходимого разрешения, библиотеки только под вашу архитектуру и только тот языковой пакет, который выбран у вас в системе.
Кстати, да, если в системе у вас выбрано несколько языков, то подгрузится больше языковых пакетов. Вот так всё просто и умно.
Тем не менее, последствия от этого нововведения воистину колоссальные. Для Google это позволяет экономить ежедневно 10 ПБ трафика, который тратится на скачку и приложений и обновлений.
А для пользователей это позволят сэкономить просто кучу места на устройстве. Ведь многие приложения похудели более чем на 30 процентов.
Иными словами, от нововведения сплошные блага.
Те кто испугался, что APK больше не будет, это не так. Вы, по-прежнему, сможете скачивать и устанавливать APK-файлы с других источников, тут нет никаких ограничений. Точно также нет ограничений и на сторонние магазины приложений, они также смогут использовать App Bundle или по старинке заставлять разработчиков самим собрать APK. Полная свобода и анархия.
И в качестве финального аккорда. Если вам кажется, что все эти оптимизации, связанные с компиляцией, скоростью загрузки приложений, размером APK и вещи, которые проделал Google с Android, это всё фигня. В качестве аргумента что это не так, мы решили по приколу сравнить размер приложений на Android и iOS и вот, что обнаружили.
Размер приложения Facebook на iOS 246 МБ, на Android — 57. Разница в 4,3 раза!
Instagram. iOS 150 МБ, Android — 39, разница 3.8 раза!
Snapchat 234 против 63 МБ.
TikTok 230 против 67 МБ… и так далее.
В итоге только на выбранном небольшом списке приложений мы получили экономию, более чем в 1 ГБ! Мы считаем — это достойно, именно поэтому Android настоящая народная ОС.
Выводы
Что в итоге. За время своего существования система Android прошла просто огромный путь оптимизации и стала по-настоящему универсальной, быстрой и эффективной системой, которая отлично работает на массе разных устройств. Вот бы все ОС так развивались. (Да, Microsoft?)
А что касается второй и моей, уж чего греха таить, любимой системы, которая также прекрасно работает на разных устройствах. О ней поговорим в другой раз.
Виджеты, лаунчеры и минимализм: 20 способов организовать приложения на экране телефона
Коллекция скриншотов читателей Т—Ж
Мы попросили читателей поделиться скриншотами экранов телефонов и рассказать, как они организуют и выбирают приложения.
Собрали снимки самых структурированных и необычных экранов, которые помогают не теряться среди десятков и сотен программ.
Это комментарии читателей из Сообщества Т—Ж. Собраны в один материал, бережно отредактированы и оформлены по стандартам редакции.
На главном экране только то, чем пользуюсь ежедневно. Это лаунчер для Андроида в стиле «Виндоус 10». Он классный.
У меня шесть экранов. Каждый условно разделен по темам: мусор, мессенджеры, магазины, банки, «Яндекс», игры.
В какой-то момент надоело искать среди кучи одинаковых иконок нужную, написал свой лаунчер. Все приложения отображаются одним списком, неиспользуемые скрываю либо удаляю, поэтому вижу только то, чем пользуюсь регулярно. Ориентируюсь в основном по положению на экране, а текст и цвет помогают не теряться. На соседней странице пара виджетов: погода и календарь — без календаря жить не могу.
Как-то так. Удалось себя приучить сортировать приложения по папкам, чтобы не создавать 15 разных экранов. Но пока не могу привыкнуть к библиотеке приложений на Ай-ос 14.
У меня всего два экрана с приложениями, остальное — через поиск. На главном экране стопка виджетов: календарь, погода и Streaks, который помогает мне отслеживать цели по активности на день и более глобально — привычки. Недавно убрал из закрепа внизу стандартную камеру Айфона и поставил Halide, но пока непривычно.
Одного экрана достаточно, остальное в библиотеке.
На экране пусто, все приложения в меню.
За минимализм. Очень понравился Niagara Launcher.
Все остальные — через меню приложений. Люблю минимализм.
Остальные приложения через поиск, как и контакты.
Вот основной. Второй — экран потребления: «Твич», «Тикток», заказ еды. Третий — экран сервисов: госуслуги, VPN, налоги.
Самый часто используемый экран.
Один экран — много эмодзи.
Я тут доверился Сири. Чаще всего она подставляет нужные приложения. Если вдруг его нет, а такое бывает редко, свайп вниз — и через поиск достаю нужное. Начинал с одного виджета, сейчас их три.
Всю личную инфу свернул в одну строку на виджет, обычно развернуто на длинную ленту.
Какие у всех скучные экраны. Это второй из двух моих: тут каршеринги, карты и банки.
Технологии. Что происходит в мире технологий, какие устройства стоит купить и как выжать максимум из вашего телефона и компьютера
>виджеты, лаунчеры
>на обложке айфон
Не спрашивайте зачем
Эдуард, супер! Один из немногих, на какие приятно смотреть
Эдуард, что зачем? глупый вопрос, чтобы использывать
Андрей, как называется сей чудо лаунчер?
Сильный,
Nova launcher prime
Виджеты KWGT
Иконки Aline Yellow icon pack
Fluid NG для тонкой настройки жестов (вместо нижней панели и вместо стандартных в телефоне)
Сильный, нова лаунчер
Оч люблю разглядывать чужие рабочие столы, всегда было интересно, как люди их организовывают
У меня вот этот экран основной (аполло = реддит, только гораздо удобнее и быстрее оригинального приложения + большое количество виджетов на любой вкус)
А у меня котик. Просто котик.
Самые нужные приложения в баре снизу, а все остальные: провожу по экрану, что открылся поисковик, ввожу первые три буквы названия приложения, запускаю из поисковой выдачи
Ответ на вопрос: приложение с ДМС, вообще не пользуюсь, но спокойнее когда оно под рукой.
Боже, храни Samsung за edge panel — ТОП-10 приложений на каждый день тут. На главном экране только лаконичный виджет погоды + внизу 5 стандартных иконок (звонки, смс, камера, галерея, Chrome). Всё остальное разбито по тематическим папкам в меню приложений.
мой билайн. заглядываю туда раз в месяц, когда надо оплачивать сотовую связь или отследить куда у меня ушло 40 смс после бурной ночи и попытки позвонить бывшему
Интересно узнать что за лаунчер/виджет на телефоне
Денис Лифанов
Тиндер)) но это шутка
Самые важные приложения, плюс два дополнительных часовых пояса для мамы и папы
Вот как организовано у меня. На первом экране чаще всего используемые приложения, на втором реже используемые. В папке «Контент» фитнес-приложения, онлайн-кинотеатры, приложения для обработки фото и видео, игры и реже используемые социальные сети. В папке «Разное» системные приложения типа почты, которые не добавлены в стандартный почтовик, приложения для получения кодов доступа, приложение для Apple Watch, приложения умного дома и т.п. В папке «Сервисы» приложения онлайн-магазинов, бонусных программ и госуслуг. На третьем экране один виджет, этот экран нужен для того, чтобы если я случайно на него попаду, то не увижу экран с библиотекой приложений, которая меня очень раздражает. Расстраивает, что её нельзя скрыть через настройки.
Не крепится скрин. Говорит что фото должно быть до 5 мб
А вообще, у меня сортируются по степени срочности: чем ближе к левому большому пальцу, тем чаще я его запускаю где то в неудобных для долгого поиска условиях. Так в углу у меня сканер перекрестка, раньше был каршеринг, набор скидочных карт, vk.
Так же как и многие приучил себя сортировать по папкам основное. А верхняя часть экрана занята большим виждетов-стопкой с погодой, расписанием и… все.
Второй экран занимает второстепенный хлам, чем иногда пользуюсь. Остальное скрыто в библиотеку. И тоже пользуюсь поиском по свайпу вниз, если нужно найти приложение, посчитать или валюту конвертнуть. К библиотеке не приучусь наверное никогда.