- Сегодня мы поговорим о том почему Android сначала тормозил, а потом перестал.
- Помянем Dalvik кэш и припомним ART.
- Узнаем во сколько внутри Android просыпается демон.
- А также слегка затронем тему, почему Android никогда не обгонит iOS по производительность, но при этом всегда будет менее требовательным к железу.
Проблема Android
У системы Android есть одна очень важная особенность, которая является как огромным преимуществом, так и огромной проблемой.
Система Android должна быть универсальной. Это значит:
- Система должна работать на всём и вся: разные архитектуры, типы устройств и прочее.
- При этом под неё должно быть просто писать код. Чтобы один раз и везде.
- И, плюс ко всему, система не должна быть прожорливой и должна быстро работать хоть на ноунейме за 3 копейки, хоть на флагмане за 3 зарплаты.
Требования к Android:
- Поддержка разных архитектур и типов устройств
- Простота программирования
- Минимальные системные требования
- Высокая скорость работы
Итого, целых четыре требования. Но соблюсти все эти требования одновременно практически нереально.
Поэтому вся история развития системы Android — это история борьбы, компромиссов и поиска баланса.
Условно историю Android можно поделить на 4 этапа: когда Android тормозил, много жрал, оптимизировался и, наконец, находился в балансе.
Этап 1. Dalvik: Android тормозит
Этап 2. ART: Android потребляет
Этап 3. Profiling: Android оптимизируется
Этап 4. AAB: Android балансирует
И сегодня мы поговорим про все четыре этапа. Но начнём с небольшой ремарки.
Java
Чтобы соблюсти первые два базовых требования к системе, а именно: поддержка разных архитектур и простота программирования. В качестве основного языка программирования в системе 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… Просто счастье.
Но вы же понимаете, что на этом развитие Android не остановилось. Ведь у чистой AOT-компиляции есть недостатки, а именно:
- Сильно увеличился вес приложений, ведь машинный несжатый код весит много.
- Увеличилось время установки приложений, ведь компиляция происходила именно в момент установки.
- При каждом обновлении системы приходилось перекомпилировать все приложения.
Помните вот эту бесконечную оптимизацию приложений после установки ежемесячного обновления безопасности системы? Вот это оно — AOT-компиляция во всей красе.
ЭТАП 3. Profiling: Android оптимизируется
Поэтому в Google подумали: компилируя приложение целиком, не делаем ли мы лишнюю работу? А вот и делаем!
Как выяснилось, по статистике пользователи очень редко используют более 10-20% кода приложения. Иными словами, в большинстве случаев заранее будет достаточно скомпилировать только малую часть, которая будет действительно использоваться часто, а для редких уголков приложения, в которые мы не заходим, можно будет и JIT-компиляцию использовать.
Но вот только, какую часть кода нужно скомпилировать заранее, ведь даже разработчики приложений не знают, как именно пользователи будут юзать их программу.
Поэтому в Android 7.0 Nougat Google представили технологию PGC — Profile guided compilation. То есть это компиляция, основанная на профилях использования приложения. Думаю вы уже примерно догадываетесь как эта штука работает.
Естественно от AOT-компиляции на этапе установки отказались. Поэтому во время первого запуска приложения стали снова использовать старую добрую JIT-компиляцию, результат которой, естественно, сохранится в кэш. Тоже самое повторится и во время второго запуска, и третьего. Но когда вы поставите телефон на зарядку и крепко заснете, тогда проснется так называемый «Демон» (это, если что, официальное название специальной службы), который проанализирует кеши всех приложений, которые вы использовали в течение дня. После этого он создаст профили с оптимизированным кодом. И так каждую ночь…
Такой подход нивелировал недостатки чистой AOT-компиляции:
- Сильно ускорилось время установки приложений
- Ускорилось время обновления системы
- Скомпилированный код стал занимать на 80% меньше места на диске
В итоге сплошные плюсы за исключением одного очевидного жирного минуса: первое время приходилось терпеть тормоза.
Но и эту проблему 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?)
А что касается второй и моей, уж чего греха таить, любимой системы, которая также прекрасно работает на разных устройствах. О ней поговорим в другой раз.
Комментарии (50)
Aelliari
06.09.2021 14:20+4Хм, aab, это те самые, которые для работы требуют отдать Гуглу свой приватный ключ для подписи приложения? А оно точно надо? Так самые, которые создают геморрой при попытке поставить в приложении язык отличный от телефона?
Те кто испугался, что APK больше не будет, это не так. Вы, по-прежнему, сможете скачивать и устанавливать APK-файлы с других источников, тут нет никаких ограничений.
А так где гарантии что это долго продлится?
... тут нет никаких ограничений, на данный момент.
AquariusStar
06.09.2021 16:32Согласен. Особенно на фоне движений самого Гугла в сторону закрытия экосистемы в полный аналог iOS, чтобы потом не смогли устанавливать из других источников, даже альтернативных плей-маркетов.
deinlandel
13.09.2021 09:20Да, все эти «мы заботимся об оптимизации» — это прекрасно, но тот факт, что Гугл теперь по сути *требует* передавать ему инструмент, позволяющий произвольно модифицировать APK и распространять от моего имени, крайне огорчает. Раньше я мог быть уверен, что к пользователю попал ровно тот код, который я подписал и залил в магазин. Сейчас такой уверенности нет
Dim0v
23.09.2021 23:52Раньше я мог быть уверен, что к пользователю попал ровно тот код, который я подписал и залил в магазин
И что вам придавало такую уверенность?
Все публичные ключи и сертификаты для проверки подлинности апк конечный юзер получает (и получал) в самом апк, загруженном со стора. Т.е. от гугла, а не от разработчика.
В теории гугл запросто мог и раньше перед отдачей на девайс модифицировать апк и, например, банально переподписывать его своим ключом. Левый апдейт конечно так не подсунешь, но если с первой установки отдавать переподписанные апк, то вообще никто ничего не заметит (ну ок, разве что автор кинется сверять подписи, но тут как бы уже история с Боржоми и почками). Ну или если совсем по беспределу, то пойти дальше и выпустить OTA апдейт ОС, отключающий верификацию подписей вообще.
Единственное, на чем строится вся уверенность - это доверие к гуглу и тому, что он не будет беспределить. Что тогда, что сейчас. Не вижу, что здесь принципиально поменялось.
qw1
24.09.2021 09:33В теории гугл запросто мог и раньше перед отдачей на девайс модифицировать апк и, например, банально переподписывать его своим ключом
При этом немалый процент приложений ломался бы, проверяющих собственную целостность, или использующих ключ подписи как ключ внешнего APIесли совсем по беспределу, то пойти дальше и выпустить OTA апдейт ОС
Эх, если бы Гугл мог выпускать OTA на любые телефоны, а не только на пиксели, у нас не было бы проблем с тем, что вендор забросил какую-то модель телефона…
Nomad1
06.09.2021 15:05+5"Понятным языком" не должно быть в ущерб логике и реальности.
Сравнение размеров на разных ОС это вообще бред какой-то, вы уж тогда размер запакованного и подготовленного маркетом .ipa модуля с .apk сравнивайте, а не распакованный vs архив. От значений "разница -4.3x" мне просто страшно. Это что и в каких единицах измерения? "отрицательных дробных минус х"?
К первой части претензии, конечно, тоже есть, но они скорее к оригиналу, который вы перевели без указания авторства.
picul
06.09.2021 15:21+6машинный несжатый код весит много
Пруфы есть?
vics001
07.09.2021 01:34-11-е, С++ std lib все линкуют в Android статически, в Java stdlib (JDK) всегда линкуется "динамически". Причем, в эту JDK сверху входят и работа с XML, Calendar, SQL.
2-е, без вызовов JNI / Java в Android не обойтись (Android API / UI), а все эти обертки жрут просто тонну кода.
CrashLogger
15.09.2021 10:43После компиляции DEX кода ARTом в машинный код он продолжает использовать Java библиотеки, установленные в системе. Статическая stdlib там внезапно ниоткуда не появится )
vics001
15.09.2021 12:13Статические увеличивают как раз размер C++ библиотек, а не Java Runtime. Про что и аргумент, что на практике С++ код весит больше.
lohmatij
06.09.2021 15:48"затронем тему, почему Android никогда не обгонит iOS по производительность, но при этом всегда будет менее требовательным к железу." — и почему так получается?
picul
06.09.2021 16:05Не обгонит по производительности, очевидно, из-за джавы и аппаратного разнообразия. А менее требовательным к железу он не является.
lassana
06.09.2021 15:54Вплоть до Android версии 4.4 KitKat приложения запускались через виртуальную машину Dalvik, которая работала по принципу Just In time компиляции или JIT-компиляции
JIT появился только в 2.2. Вспоминаю китайские планшеты на 2.1, вот уж где действительно было медленно.
PaulZi
06.09.2021 21:49Да, помню, на nexus one когда вышло обновление с 2.2 angry birds стал прям летать)
kolu4iy
06.09.2021 22:28+2Ну они, конечно, правы. Наверное. Но вот AOT compilation я действительно ценил - наверное, самый маложрущий андроид был как раз пятый. И быстрый. А поскольку обновлялось всё пока телефон был на зарядке - плевать я хотел на время компиляции. Ну и при обновлении софта телефона - вполне можно было подождать.
Вот версионность ресурсов (особенно от разрешения экрана) - наверное, действительно правильный ход.
А с "магией профилирования"... Я помню, как на телефон работающий полтора дня от зарядки до зарядки поставил яндекс навигатор, и он за полчаса его разогрел и посадил батарею в 20% от 80 на том самом JIT. Нет, на следующий день (после компиляции) снова всё стало хорошо, но больно уж неожиданно было.
kirich1409
07.09.2021 13:27+2Жалко что не рассмотрели как с помощью AAB Google будет иметь жесткий контроль над разработчиками и усиливать безопасноcть Google Play, а возможно и бороться со сторонними магазинами
qw1
07.09.2021 13:35Так формат AAB открыт, кто мешает стороннему магазину перепаковывать приложения в AAB?
kirich1409
07.09.2021 13:38+1Вопрос не в ограничении использования, а в том что Google лешит разработчиков иметь доступ к ключу подписи. Также при упаковке сборке APK из AAB добавляется специальная метадата для валидации откуда сборка. Так что даже залив одинаковые AAB в разные магазины, сделать одинаковую подпись, то сборки будут отличаться.
qw1
07.09.2021 15:09Пока не догоняю, какие от этого будут последствия.
AAB из разных магазинов будут разные, это плохо?
Платформа Android в какой-то момент начнёт устанавливать AAB только из магазина гугла?
Neikist
07.09.2021 22:21+1Ну, часть сервисов гугла того же, вроде пушей, карт, логина через учетку гугл, работают только если приложение подписано ключем разработчика зарегистрированным в firebase/гугл консоли. Некоторые сторонние SDK и библиотеки тоже на проверку подписи завязываются. Это можно попробовать обойти, но для этого придется рута получать и много ковыряться с системой, либо по жесткому ковырять декомпилированное приложение и пересобирать заново, и то с тем же гуглом не прокатит просто приложение взломать.
Еще у крупных разработчиков у которых много приложений и они связаны между собой есть возможность защиты этого самого взаимодействия подписью (инфу можно найти по запросу в гугл: protection level signature android). И если подписывать разными подписями потеряется возможность такого взаимодействия, если сервис будет вообще все одной подписью подписывать наоборот уязвимости создаст когда приложения разных разработчиков между собой такие взаимодействия осуществлять смогут.
Если разработчик выложит где нибудь отдельно apk подписанный тем же ключом — хорошо. Но мало кто это делает. А для сторонних сервисов которые из гугл плея приложения позволяют устанавливать на девайсы без оного — это плохо, так как они будут вынуждены пересобирать и подписывать какой то своей подписью с которой будут вышеописанные проблемы.qw1
08.09.2021 10:00Документация google говорит, что разработчик просто передаёт свои ключи гуглу. То есть AAB подписан в итоге ключом разработчика и не должно быть проблем с несовместимостью подписей.
Neikist
08.09.2021 10:03Да, и гугл использует ключ чтобы собрать и поставить приложение с этой подписью. Но больше этого ключа ни у кого нет, и остальным для той же операции (сборка apk из бандла) придется свои ключи использовать, а не ключ разработчика.
qw1
08.09.2021 10:06Да, теперь вижу. Ключ можно создать на аккаунте «в облаке», но забрать его себе нельзя.
Neikist
08.09.2021 10:08Да нет, ключ таки у разработчика есть, но только у гугла и разработчика. У остальных нету.
qw1
08.09.2021 11:25Как я понял, ключ разработчика не тот ключ, которым финально подписывается приложение. А upload key — просто на время передачи apk от разработчика в магазин, а дальше переподписывается ключом, не покидающим гугл.
Иначе какие сложности? Разработчик отдаст этот ключ в другой магазин, и всё.Neikist
08.09.2021 11:29+2В файрбейс и прочие сервисы загружается оттиск ключа именно которым приложение подписывается в итоге, а не ключ загрузки.
Ну и как бы если разработчик выкладывает свое приложение на сайте своем или в альтернативных сторах сам — проблем не будет естественно. Проблемы будут у тех кто по каким то причинам не может/хочет ставить из гугл плея. Ибо выкладывают куда то еще свои приложения даже не проценты разработчиков, а ничтожные доли процентов.
qw1
08.09.2021 17:39То есть, проблемы будут у пиратов, которые перевыкладывают из сторов без ведома автора?
Neikist
08.09.2021 17:41+1Ээээ, а в чем пиратство бесплатное приложение скачать из другого источника?
Например у меня в читалке на электронных чернилах гугл сервисы есть, а стора нет. И приложения для читалки качаю с таких источников.
qw1
08.09.2021 18:35Я только «за» то, чтобы источников было больше.
К сожалению, «бесплатность» приложения по умолчанию не означает, что можно без ведома автора публиковать его в любом сторе.
Neikist
08.09.2021 18:46+1Ну, автор может и рад бы сам публиковать, но выкладывать каждый раз обновления на эти сотни сервисов и сайтов сторонних — задолбаешься. Еще и пользователи будут жаловаться если что то не работает на их девайсе с обрезком гугл сервисов.
З.Ы. наше приложение например только в гугл плее есть, но мы только за если его качают из других источников, если нет возможности из стора поставить по каким то причинам. Изредка по просьбе пользователей даже старые версии для андроида ниже 5 скидываем, благо они пока еще работают, просто фич меньше, багов больше, и немного устарели.
Javian
Такое чувство что надо вернуть обратно Dalwik: "То есть приложения транслировались в нативный код прямо во время исполнения, то есть “на лету”".
Процессоры и флешпамять стали быстрее, батареи увеличили ёмкость в раза 4. Причин тормозить и экономить энергию нет.
doctorw
Имхо, до тех пор, пока Ваш смартфон не живёт на одном заряде хотя бы неделю, при обычном для Вас использовании, про "Причин экономить энергию нет" даже не заикайтесь.
Javian
Доля процессора в энергопотреблении намного меньше экрана. Отключите экран и потребление процессора не сильно окажет влияние на время работы. Производитель моего первого смартфона на Samsung S5PC111 и PowerVR SGX540 (экран Super AMOLED 800х480 ) с Android 2.3 заявлял, что аккумулятор 1500мАч способен продержаться до 768 минут в режиме разговора и до 750 часов в режиме ожидания, более 24 часов при воспроизведении музыки. При воспроизведении видео аккумулятор разряжался примерно за 7 часов.
doctorw
А я и не утверждал обратного, я писал в целом о смартфоне. Да над энергопотреблением за годы неплохо поработали, да ёмкость батареи значительно увеличилась. Однако, смартфон в среднем дольше 2-х суток редко живёт, если не отключать всё и вся, и это когда батарея свежая.
Поэтому, причин экономить энергию вполне себе достаточно, как минимум не расходовать её там, где можно обойтись.
Javian
И во времена Android.2.3 телефон 2-х суток работы не достигал. Очевидно, что цели увеличивать длительность автономной работы нет. Пользователя приучили заряжать телефон минимум раз в сутки. И всё "сэкономленное" скармливается на поддержание работы каналов связи и программ, работающих непрозрачно для пользователя. А с точки зрения пользователя я не вижу тормозов ни на 2-й версии, ни на 10-й. Базовый функционал тот же - браузер, email, мессенджер, фото/видео.
Чего-то "нового", что мне бы понравилось я не видел с 5-й версии. Что появилось "нового" в телефонах, кроме фотокамер и их алгоритмов? Чем занимается процессор? Зачем надо "еще больше" и "быстрее"?
По-моему дальше его кроят как удобно и необходимо Google, а не пользователю. Я потерял к этой системе интерес - для меня она выглядит попавшей в тупик развития. Для пользователя уже нет ничего, что можно еще любить в этой ОС.
Собственно по этим мотивам есть две публикации на тему "Android окукливается и сообщество потворствует этому" от @IMnEpaTOP и @Roman_Cherkasov и я согласен с авторами, что "Андроид растратил всё, что мы в нём любили".
И возвращаясь к первоначальному комментарию о Dalwik, возможно, я бы сейчас бы с удовольствием купил бы телефон на Android 2 на современном железе: Браузер, почта, мессенджер и фотовидеокамера.
masai
Не уверен, что тот браузер откроет все современные сайты, а та камера будет снимать в качестве, к которому все привыкли.
Javian
Всё субъективно. Для меня браузер на A2 - это утерянный рай. Facebook обычно посещаю на старом телефоне. Habr там тоже работает. Современные мобильные браузеры познаются в сравнении - они не удобны для тех действий что мне нужны. А некоторые вещи в современных не работают - не дают скопировать текст на некоторых сайтах, сохранить фото.
Фото тоже субъективная тема. У старого другое фокусное расстояние, нет сильной широкоугольности как у современных. Вполне хватает 5 Мп для фотофиксации события. Например эти фото с него.
Если серьезно, то единственная причина долгожительства этого телефона - размер. Комфортный для меня размер. Попытки купить другой телефон много лет останавливаются дискомфортом от габаритов. Из последнего понравился iPhone 12 mini - по размерам мне идеален. Возможно решусь перейти на эту платформу.
qw1
Dimezis
По какой физике вся потраченная энергия уходит в тепло? Как тогда вообще полезная работа происходит?
qw1
Смартфон не делает «полезную работу» (в физическом смысле этого термина, как произведение силы на перемещение)
Dimezis
Да? А как тогда переносится заряд от батареи к компонентам?
Это механическая работа.
Но речь даже не об этом. Заставить светиться экран - это тоже затраты энергии. Энергия аккумулятора переходит в кинетическую энергию фотонов, и частично в нагрев компонентов.
qw1
Так и есть. Но это немного. Достаточно закрыть экран бумажкой, и весь свет перейдёт в тепло. И такого тепла будет заметно меньше, чем нагрев от работы процессора.
Dimezis
Конечно же нет. Такое произойдет только если бумажка не пропускает и не отражает свет, то есть является абсолютно черным телом, чего в принципе не бывает.
Но я как бы не пытаюсь спорить кто больше жрет - проц или экран, я понятия не имею. Просто пытаюсь донести, что нельзя все сравнивать по тепловыделению. Энергия может преобразовываться в очень разные виды
qw1
Для практических оценок достаточно бумажки, т.к. очень большой процент света она поглотит. Энергии много видов, но для смартфона учитывать можно только тепло, всё остальное несущественно.
qw1
Можно не заниматься гаданиями, а посмотреть замеры.
Я нашёл тесты (хотя очень старые, но порядок величин верный)
www.cas.mcmaster.ca/~rzheng/course/CAS765fa13/CH10.pdf
LCD-экран от 33 до 74 mW в зависимости от картинка, подсветка под ним от 194 до 1313 mW в зависимости от яркости.
Пиковое потребление разных моделей Snapdragon от 3 до 11 W
https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_processors#Snapdragon_888/888+_5G_(2021)
То есть в 5-10 раз выше экрана.
Javian
Практическая эксплуатация, которая отличается от максимальных нагрузок. Хотя бы посмотреть как загружен телефон в Energy Profiler, где видно, что обычно CPU на 100% не работает.
T_Cirkla
Если смартфоны сейчас перестанут экономить энергию хотя бы так, как они это делают сейчас, то заряда будет хватать едва ли на полдня, а то и меньше.