Ответ 1

Я только что провел последний день или пытаюсь отследить эту точную проблему. Я создал небольшую игру под названием BlockIT для Android, и теперь у меня есть работающая версия для iOS. Чрезвычайно странно, что версия Android составляет 8,2 МБ, а версия iOS - 14,1 МБ.

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

Итак, почему код так сильно отличается! Моя сборка кода iOS была около 7 МБ, а Android - менее 3 МБ. Сам код был написан для работы идентично, и все, кроме небольших частей кода, одинаковы на каждой платформе. Я обнаружил, что настройки сборки (iOS gcc) имели огромное влияние на размер выпускаемой вами информации. Если вы установите только для ARM6 или ARM7, размер моего двоичного кода кода упал с 7 МБ до 5 МБ. Это указывает на почти полное дублирование функций и библиотек для каждой цели в одном бинарном! Кроме того, встроенные отладочные символы не выглядят полностью лишенными. Наконец, шифрование кода также требует больших затрат. Это, наверное, самое озадачивающее, так как Android подписывает свой apk аналогичным образом. Кажется, что подписание iOS выполняется очень странно.

Итак, я надеюсь, что это поможет. Повторить:
- Изображения/Данные, похоже, не являются проблемой
- Создание кода на iOS генерирует несколько выходных данных платформы в одном бинарнике == много дополнительного кода (кстати, я не понимаю, почему Apple делает это - кажется странным).
- Шифрование кода не очень удобно для iOS.

Нет реального способа исправить реальную проблему (опять же, странно и неутешительно).

Ответ 2

Двоичный исполняемый файл в приложении iOS зашифрован и, таким образом, сжимается очень плохо или вообще не работает. Бинарный исполняемый файл в приложении iOS скомпилирован с некоторым статическим кодом библиотеки, который часто может сделать его более значительным, чем интерпретированный байт-код Dalvik для аналогичного материала. Приложения iPhone, как правило, содержат более качественный графический контент и иллюстрации для множества разрешений экрана, включая относительно большой дисплей iPad.

Ответ 3

Для универсального приложения в iPhone нам нужно разместить три размера изображений -

один для 320x480 px
второй для 640x940 px (сетчатка)
третий для 768x1024 (iPad)

где, разрабатывая приложение для Android, нужно поместить три вида изображений -

hdpi (высокий)
mdpi (средний)
ldpi (низкий)

еще одна вещь здесь, в андроиде, нет обязательного правила ставить все три вида изображений. В основном это зависит от того, для какой цели вы создаете приложение, только для тех резолюций, которые нам нужны для размещения изображений.

Ответ 4

По моему мнению, Apple Developers используют больше полноэкранного размера Изображения (в low def и Retina) и намного больше изображений, чем Android, а файлы определений UI для iPhone (.XIB) намного больше, чем файлы XML, используемые в Android. Там также должна быть разница сжатия в упаковке (.APK) настолько сильно сжата! И, наконец, может быть, разница в том, что включает фреймворки, но по этому вопросу у меня нет подсказки:)