Комментарии 39
Лечение всегда легче, чем профилактика, вот и придумывают костыли при обновлении, когда можно спроектировать ОС так, чтобы приложения на выходе получались с изначально небольшим размером. Почему нельзя разработать приложение весом в 3 МБ вместо 300 МБ? Ответ: сама ОС такая.
Например, на Windows 10 приложения — это тупо набор скриптов, причём без преувеличения говорю. Даже обратная совместимость определяется двумя строчками в манифесте, все ресурсы хранит система, знай себе юзай ссылки на ресурсы, вызывай системные API и не пиши хуки, всё сделано за тебя, разрабатывай как хочешь. Итог: приложение на Android/iOS занимает 150 МБ, а на Windows — 1 МБ, и то это округление в большую сторону от 150 КБ.
Вывод: 400 000 000+ юзеров на Windows 10 экономят трафика столько, сколько Android и не снилось!
Например, на Windows 10 приложения — это тупо набор скриптов, причём без преувеличения говорю. Даже обратная совместимость определяется двумя строчками в манифесте, все ресурсы хранит система, знай себе юзай ссылки на ресурсы, вызывай системные API и не пиши хуки, всё сделано за тебя, разрабатывай как хочешь. Итог: приложение на Android/iOS занимает 150 МБ, а на Windows — 1 МБ, и то это округление в большую сторону от 150 КБ.
Вывод: 400 000 000+ юзеров на Windows 10 экономят трафика столько, сколько Android и не снилось!
Вывод: 400 000 000+ юзеров на Windows 10 экономят трафика столько, сколько Android и не снилось!
Положим, что каждый юзер WinPhone получает 1 обновление в день (в среднем) и чистая экономия — 1 МБ. 4*10^8 юзеров * 10^6 Байт = 4*10^14 Байт = 400 ТБ.
В то же время
эффективный подход позволяет сократить трафик обновлений на 6 петабайт ежедневно.
6 ПБ / 400 ТБ = 15 раз. Так что нет. Самая непопулярная платформа если даже и экономит трафик, то в 15 раз меньше, чем самая популярная. Так себе достижение, если честно.
Может мобильная Windows всё-таки «взлетит» когда-нибудь? Просто народ пока не просёк (причём и программисты и пользователи).
Пишу под мобильную Windows и под Android. Пока что вся экосистема UWP просто враждебна разработчику. Если интересно — могу написать об этом целый отдельный пост боли и страданий.
Конечно пишите, надо ведь поделиться опытом с теми, кто думает начать писать под эту платформу.
Ну, боль и страдания есть на всех платформах. Причём чаще всего боль и страдания возникают тогда, когда принципы одной платформы пытаются перенести на другую.
Конечно интересно! Напишите, пожалуйста. И если так, то тогда понятно, почему так не популярна платформа. Жаль, конечно… Потому, что мне — как пользователю — почему-то очень нравится и интерфейс и то, что на 1 Гб ОЗУ всё бегает не хуже (а то и лучше), чем на двух-трёх на Андроиде.
Сильно сомневаюсь, что разработчики мобильной ОС думали о размере обновлений меньше, чем разработчики настольной ОС.
В iOS и Android тоже используется принцип, когда все ресурсы и весь код совместимости старых приложений с новой системой есть в самой системе. Другой вопрос, когда новое приложение хотят запустить на старой системе, где нет нужного кода. Тогда приходится этот код встраивать в само приложение, и на Windows абсолютно такая же ситуация.
Откуда тогда такой размер в приложениях? Это потому, что разработчики не хотят пользоваться стандартными ресурсами, и рисуют свои. Опять же, на Windows абсолютно такая же ситуация.
В iOS и Android тоже используется принцип, когда все ресурсы и весь код совместимости старых приложений с новой системой есть в самой системе. Другой вопрос, когда новое приложение хотят запустить на старой системе, где нет нужного кода. Тогда приходится этот код встраивать в само приложение, и на Windows абсолютно такая же ситуация.
Откуда тогда такой размер в приложениях? Это потому, что разработчики не хотят пользоваться стандартными ресурсами, и рисуют свои. Опять же, на Windows абсолютно такая же ситуация.
Почему нельзя разработать приложение весом в 3 МБ вместо 300 МБ? Ответ: сама ОС такая.
Можно. На андроиде код занимает очень малую часть от приложения. Если повыкидывать из приложения звуки, кастомные кнопочки, сплеш-скрин и прочие красивости, оно будет весить очень мало. Только пользователи будут недовольны, потому что им красивостей хочется, а размер +- 10 мб не важен.
Например, когда я писал небольшую игру на libgdx+scala, apk файл весил 3мб.
Внутри лежит classes.dex на 1.7 мб (большая часть — scala library), ещё 4.6 мб занимают библиотечки от libgdx, всё это с остальными ресурсами ужимается в апк размером в 3мб. (единственный косяк — библиотечки лежат сразу для пяти платформ, "x86", "x86_64", "armeabi", "armeabi-v7a", "arm64-v8a")
Итог: приложение на Android/iOS занимает 150 МБ, а на Windows — 1 МБ, и то это округление в большую сторону от 150 КБ.
Вывод: 400 000 000+ юзеров на Windows 10 экономят трафика столько, сколько Android и не снилось!
Ага, попробуйте поставить Windows Visual Studio. Даже если отключить все опции, она займёт 5 гб на диске. Для сравнения, образ линукса занимает около одного гигабайта. А в линуксе уже установлены gcc и прочие штуки для разработки.
(единственный косяк — библиотечки лежат сразу для пяти платформ, "x86", "x86_64", "armeabi", "armeabi-v7a", "arm64-v8a")
Это можно пофиксить настойками в gradle, будут генерироваться отдельные apk для каждой платформы — плей маркет такое поддерживает — и сам разрулит какому пользователю что отдавать.
Можно. На андроиде код занимает очень малую часть от приложения.
Плюсую. Моё самое успешное приложение (более миллиона скачиваний в Google Play) весит всего 200 Кб.
После этого APK опять пересобирается уже на стороне устройства.
и кто, интересно, его (APK) подписывает? ))
а в чем проблема, что будет собранный на самом девайсе APK подписан самим же девайсом?
в целом, наверное, это не проблема
непонятно только будет от кого апдейт прилетел (если эта информация вообще кому-нибудь нужна)
непонятно только будет от кого апдейт прилетел (если эта информация вообще кому-нибудь нужна)
Апдейт будет прилетать от гугла и, как я понимаю, будет на лету подписываться гуглом же. Пришел апк — проверили что подписан гуглом — все ок.
неее
я понял почему
в оригинале есть примечание:
Схема подписи APK v2 — введена в Android 7.0. Встраивается в саму APK (ZIP-архив), в отличие от APK для Android 6.0 и ниже, где используется JAR-подпись (подробности по вышеприведённой ссылке)
я понял почему
конечный APK должен полностью совпадать с исходным, байт в байт
в оригинале есть примечание:
(see APK Signature Schema v2 for why).
Схема подписи APK v2 — введена в Android 7.0. Встраивается в саму APK (ZIP-архив), в отличие от APK для Android 6.0 и ниже, где используется JAR-подпись (подробности по вышеприведённой ссылке)
Магазин будет присылать дельту и подпись (для полного файла).
Дельта обновит распакованные ресурсы, их соберут в архив и проверят подпись.
Точно так же в обычном случае присылают архив и подпись, проверяют подпись и ставят архив.
Заморочки с сертификацией и доверием к открытому ключу разработчика в этом случае этой схемы не касаются, но там и так все решено.
Дельта обновит распакованные ресурсы, их соберут в архив и проверят подпись.
Точно так же в обычном случае присылают архив и подпись, проверяют подпись и ставят архив.
Заморочки с сертификацией и доверием к открытому ключу разработчика в этом случае этой схемы не касаются, но там и так все решено.
а нельзя просто прикрепить новую подпись (ведь файлы то идентичны)?
да новую-то можно
только тут вопрос, который я озвучил: «кто подписал?», и соответственно, степени доверия к подписавшему )
тут ведь вопрос в чём:
подпись — это зашифрованный закрытым ключом подписавшего (в оригинале — разработчика) хэш содержимого
если содержимое — изменилось хоть на байт — всё, подпись невалидна
если подписал кто-то другой, то это «кто-то другой». нельзя удостоверить, что содержимое финального APK то же, что подписывал оригинальный разработчик
c JAR-подписью такое могло бы сработать, т.к. там подписывается СОДЕРЖИМОЕ APK (который есть ZIP-архив)
тут же речь о подписывании самого бинарного APK (APK Signature Schema v2). вот поэтому
только тут вопрос, который я озвучил: «кто подписал?», и соответственно, степени доверия к подписавшему )
тут ведь вопрос в чём:
подпись — это зашифрованный закрытым ключом подписавшего (в оригинале — разработчика) хэш содержимого
если содержимое — изменилось хоть на байт — всё, подпись невалидна
если подписал кто-то другой, то это «кто-то другой». нельзя удостоверить, что содержимое финального APK то же, что подписывал оригинальный разработчик
c JAR-подписью такое могло бы сработать, т.к. там подписывается СОДЕРЖИМОЕ APK (который есть ZIP-архив)
тут же речь о подписывании самого бинарного APK (APK Signature Schema v2). вот поэтому
конечный APK должен полностью совпадать с исходным, байт в байт
а не, не выйдет
в Android нельзя поставить обновления, подписанные другим ключом, нежели обновляемое приложение. Можно только снести предыдущую версию и ставить «обновление» с нуля.
в Android нельзя поставить обновления, подписанные другим ключом, нежели обновляемое приложение. Можно только снести предыдущую версию и ставить «обновление» с нуля.
Лично мне кажется, что появится новый вирус на Android, который заразит утилиту, занимающуюся сборкой APK файла на устройстве. Этот вирус будет просто потом инжектить вредоносный код в каждый собранный APK.
Тогда будет несовпадение по размерам, если так со старта и на глаз.
Если всё так просто, то ничего не изменилось. Просто ваш мифический вирус уже сейчас заражает утилиту, занимающуюся установкой апк на устройстве.
Какой смысл заражать APK, собранные под конкретное устройство, если они с этого устройства никуда не уходят?
Если хочется закрепиться в системе и, раз уж доступ на запись получен (обычно /system монтируется как read only при инициализации ядра), проще дописаться куда-нибудь к системным бинарникам.
Например, во framework.jar, чтобы инжектиться автоматически в каждое приложение.
Если хочется закрепиться в системе и, раз уж доступ на запись получен (обычно /system монтируется как read only при инициализации ядра), проще дописаться куда-нибудь к системным бинарникам.
Например, во framework.jar, чтобы инжектиться автоматически в каждое приложение.
Такое ощущение что все комментаторы выше не хабравчане, а какие то левые
Люди, ау! если каждое приложение будет таскать с собой полную копию используемого фреймворка, вместо того чтобы добавить его в зависимость, как это сделано в нормальных linux-системах, то тогда каждый фонарик будет весить 5-35мб вместо 10кб.
Ради интереса, посмотрите, сколько приложений таскают с собой код webkit для просмотра html.
впору уже аппаратную дедупликацию запускать, а во время установки, принудительно распаковывать все сжатые файлы, которые могут в принципе хранить дублируемый код, так как сделать все правильно никому уже не придет в голову…
p.s. оперативная память например засирается именно этим.
Люди, ау! если каждое приложение будет таскать с собой полную копию используемого фреймворка, вместо того чтобы добавить его в зависимость, как это сделано в нормальных linux-системах, то тогда каждый фонарик будет весить 5-35мб вместо 10кб.
Ради интереса, посмотрите, сколько приложений таскают с собой код webkit для просмотра html.
впору уже аппаратную дедупликацию запускать, а во время установки, принудительно распаковывать все сжатые файлы, которые могут в принципе хранить дублируемый код, так как сделать все правильно никому уже не придет в голову…
p.s. оперативная память например засирается именно этим.
НЛО прилетело и опубликовало эту надпись здесь
Что я вижу в apk, так это всякие SDK, как гугловские
которые нужны для in-app purchase,
так и sdk от десятка социальных кнопок и рекламных сетей
Ещё частый гость — библиотеки поддержки определённых визуальных стилей (разного рода action-bar-ы и контролы), которые с определённых версий есть в Android. Но нам же надо запуститься на как можно большем количестве платформ, и чтобы вёрстка не поплыла, поэтому системными не пользуемся.
HTC-шные приложения содержат контролы типа com.htc.lib1.cc.view.viewpager, которые есть во framework, но для удобства, чтобы под каждое устройство не собирать свой пакет почтового клиента или календаря/будильника, их включают в обновления, скачиваемые из маркета. Поэтому будильник весит 5.5MB.
com.google.ads
com.google.android.gms
com.google.market,которые нужны для in-app purchase,
так и sdk от десятка социальных кнопок и рекламных сетей
com.facebook.*
com.flurry.*
com.twitter.*
com.yandex.metrica
com.yandex.mobile.adsЕщё частый гость — библиотеки поддержки определённых визуальных стилей (разного рода action-bar-ы и контролы), которые с определённых версий есть в Android. Но нам же надо запуститься на как можно большем количестве платформ, и чтобы вёрстка не поплыла, поэтому системными не пользуемся.
HTC-шные приложения содержат контролы типа com.htc.lib1.cc.view.viewpager, которые есть во framework, но для удобства, чтобы под каждое устройство не собирать свой пакет почтового клиента или календаря/будильника, их включают в обновления, скачиваемые из маркета. Поэтому будильник весит 5.5MB.
НЛО прилетело и опубликовало эту надпись здесь
Товарищи из статьи отвечают за ядро андроида. Ваша претензия ни о чем, ибо обновления на ваш конкретный телефон зависят только от производителя этого вашего телефона.
НЛО прилетело и опубликовало эту надпись здесь
Проще сказать себе «У меня нет на это времени».
А так, при желании, можно себе любую версию залепить на любой девайс. А если не будет хватать памяти или ещё чего (например, нет поддержки определённых команд видеоускорения) — повод помозгоштурмить и сделать компромисное решение )))
На HTC HD2, который выходил в 2009 на Windows Mobile 6.5, до сих пор то Windown Phone, то Android 7 выпустят. Даже отсутствие каких-то исходников этих людей не останавливает.
А так, при желании, можно себе любую версию залепить на любой девайс. А если не будет хватать памяти или ещё чего (например, нет поддержки определённых команд видеоускорения) — повод помозгоштурмить и сделать компромисное решение )))
На HTC HD2, который выходил в 2009 на Windows Mobile 6.5, до сих пор то Windown Phone, то Android 7 выпустят. Даже отсутствие каких-то исходников этих людей не останавливает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработчики Android добились уменьшения размера обновлений в среднем на 65%