Comments 39
Например, на 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 и под Android. Пока что вся экосистема UWP просто враждебна разработчику. Если интересно — могу написать об этом целый отдельный пост боли и страданий.
В 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 должен полностью совпадать с исходным, байт в байт
в оригинале есть примечание:
(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 должен полностью совпадать с исходным, байт в байт
в Android нельзя поставить обновления, подписанные другим ключом, нежели обновляемое приложение. Можно только снести предыдущую версию и ставить «обновление» с нуля.
Если всё так просто, то ничего не изменилось. Просто ваш мифический вирус уже сейчас заражает утилиту, занимающуюся установкой апк на устройстве.
Если хочется закрепиться в системе и, раз уж доступ на запись получен (обычно /system монтируется как read only при инициализации ядра), проще дописаться куда-нибудь к системным бинарникам.
Например, во framework.jar, чтобы инжектиться автоматически в каждое приложение.
Люди, ау! если каждое приложение будет таскать с собой полную копию используемого фреймворка, вместо того чтобы добавить его в зависимость, как это сделано в нормальных linux-системах, то тогда каждый фонарик будет весить 5-35мб вместо 10кб.
Ради интереса, посмотрите, сколько приложений таскают с собой код webkit для просмотра html.
впору уже аппаратную дедупликацию запускать, а во время установки, принудительно распаковывать все сжатые файлы, которые могут в принципе хранить дублируемый код, так как сделать все правильно никому уже не придет в голову…
p.s. оперативная память например засирается именно этим.
Они, правда, еще и ворох JS библиотек тащат, но по сравнению с webkit'ом — капля в море. 200 килобайт против 20 мегабайт.
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 выпустят. Даже отсутствие каких-то исходников этих людей не останавливает.
Разработчики Android добились уменьшения размера обновлений в среднем на 65%