- Что значит отказ от поддержки 32-битной архитектуры в будущих процессорах ARM
- Константин Иванов
- А разве Android еще не 64-битный?
- Что известно о 64-битных процессорах ARM
- О совместимости Android-приложений на различных устройствах
- Обновляем проекты Unity Android для совместимости с архитектурой ARM64
- Google предложил разработчикам обновить приложения для совместимости с архитектурой ARM64 в срок до 1 августа 2019 года, если они не соответствуют этим требованиям
- Найдем и включим поддержку ARM64 в Unity
- Если в проекте используется Vuforia, ее также требуется обновить
- Перевод «Подготовьте ваши приложения к 64-бит требованиям»
- 64-бит требования: что это означает для разработчиков
- Подготовка к 64-бит требованиям
Что значит отказ от поддержки 32-битной архитектуры в будущих процессорах ARM
Константин Иванов
Во время выступления на конференции Arm DevSummit Пол Вильямсон, вице-президент и глава клиентского подразделения ARM, заявил, что новые процессоры Arm Cortex-A, то есть те самые, что служат основой платформы для чипсета вашего смартфона, к 2022 году будут поддерживать только 64-битную архитектуру. Это означает, что на аппаратном уровне поддержки 32-битных приложений в будущем не будет, а следовательно, это небольшой, но весьма значимый шаг для будущего смартфонов и ОС Android.
Если вы волновались насчет поддержки приложений, то напрасно. Компания Google с августа 2019 года требует, чтобы все приложения в магазине Google Play были 64-битными. Со стороны ARM также подчеркивают, что около 60% приложений уже совместимы с 64-битной архитектурой. Большая часть тех, что 64-бита не поддерживают, находятся за пределами западных экосистем, созданных Apple и Google. Так что большинство приложений или уже 64-битные, или у их создателей есть еще масса времени для обеспечения такой поддержки. Худший вариант – это старые приложения, у которых уже нет поддержки. Они просто перестанут работать.
А разве Android еще не 64-битный?
Технически ОС Android уже 64-битная. Поддержка 64-битных приложений была внедрена еще в 2014 году с обновлением до версии 5.0 Lollipop, но ОС Android и ядра ARM сохраняют поддержку 32-битных приложений. Так что называть ОС Android полностью 64-битной системой будет неверно. Это наследство в виде поддержки старой архитектуры просуществует до 2022 года с точки зрения аппаратной части, так что нет предпосылок к тому, чтобы из Android его исключили заранее. Так что для пользователей переход должен быть бесшовным.
Польза от перехода полностью на 64-битную архитектуру должна включать улучшение производительности для приложений, игр и операционной системы. В некоторых случаях оно может достигать 20%. Разработчикам больше не потребуется заботиться о поддержке двух архитектур, и они смогут сосредоточиться исключительно на 64-битной. Возможно, это даст некоторое ускорение в выпуске обновлений.
В большинстве случаев переход к 64-битной архитектуре будет заурядным событием. Смартфоны и приложения находятся в переходном периоде уже несколько лет. Так что и с точки зрения аппаратной и программной части переход давно пора завершить. В конце концов, в Apple еще в 2017 году уже сделали iOS 11 полностью 64-битной.
Что известно о 64-битных процессорах ARM
Важной новостью от Arm является то, что они наконец-то смогут избавиться от лишней части своих процессоров, которая требуется исключительно для поддержки 32-битной архитектуры. Это сэкономит полезную площадь при печати, что означает меньший физический размер ядра и его меньшую теплоотдачу, ну или большую производительность при тех же размерах.
Кодовые названия ядер Arm для 2021 и 2022 года – Matterhorn и Makalu. И вот у второго уже не будет поддержки 32 бит. Компания Arm обещает 30% прирост в производительности между ядрами 2020 года Cortex-A78 и Makalu, так что не заметить улучшение будет сложно. Переход к полностью 64-битной архитектуре начнется с больших ядер Cortex-A. При этом сам переход не будет непременно сопровождаться новой архитектурой самого ядра, такой как ArmV9. Другими словами, скорее всего, мы увидим дизайн кластера ядер, в котором будут присутствовать как полностью 64-битные Makalu, так и меньшие ядра с поддержкой 32/64-бит, такие как Cortex-A55. Хотя финальный продукт с точки зрения пользователя и разработчика будет исключительно 64-битным.
Так что до того, как появятся чипсеты, работающие исключительно с 64-битами, нам придется подождать, чтобы появились малые ядра в полностью 64-битном исполнении. Это оставляет пространство для менее производительных устройств, которые используют только меньшие ядра. Они смогут обеспечивать поддержку 32-битной архитектуры несколько дольше. И есть даже предпосылки к тому, что обновление данного типа ядер произойдет до этого момента. Это будет более новая модель в сравнении с Cortex-A55, но у нее все еще будет поддержка и 32, и 64-бит, так что тут переход будет еще более плавным.
Переход полностью на 64-бита – это важный шаг для ОС Android и компании Arm. Его значение – в упрощении в сравнении с современным состоянием, когда требуется поддержка наследия 32-битной эры. Однако не нужно воспринимать его как фундаментальное изменение экосистемы или радикальное обновление пользовательского опыта, поскольку вся сложность перехода ложится исключительно на плечи разработчиков. А простые пользователи устройств, скорее всего, вообще ничего не заметят.
Источник
О совместимости Android-приложений на различных устройствах
Не секрет, что число устройств на Android велико, они различаются по железу, размерам и качеству экрана, мощности процессора и др.. В отличии от iPhone- программистов, которые знают наверняка на каком устройстве будет запущено их приложение, Android-разработчикам необходимо уделять внимание совместимости приложений с различными устройствами.
В данной статье уделяется внимание вопросу совместимости приложений, в первую очередь отображения приложений на экранах с различными диагоналями и разрешением.
Для начала необходимо разобраться с возможностями, которые предоставляет Android для работы с экраном.
Основные сведения
Размер экрана(screen size) — физический размер экрана; предопределенные значения: small, normal, large, extra large*.
Геометрический коэффициент(aspect ratio)– отношение физических пропорций экрана (ширины к высоте); предопределенные значения: long (для экранов, чьи размеры превосходят по ширине или высоте стандартные размеры экрана), notlong(для экранов, чьи размеры соответствуют стандартным).
Плотность(density) – распределение пикселей относительно физических размеров экрана. Значение плотности распределения пикселей важно, поскольку один и тот же UI элемент, выраженный в пикселях для экранов с более низкой плотностью будет казаться больше, чем для экранов с высокой. Предопределенные значения для плотности: ldpi (low), mdpi (medium), hdpi (high), and xhdpi*.
Независимый(от плотности) пиксел(density-independent или dp) – “виртуальный” пиксел, который может быть использован приложением для прорисовки UI-элементов. Данный пиксел является эквивалентом физического пиксела на экране с плотностью 160 dpi. Во время выполнения OS Android прорисовывает элемент в соответствии с формулой pixel = dp * (density/160), где density – плотность экрана.
Стоит также отметить, что OS Android работает с разрешением экрана, через значения плотности экрана (никаких средств для работы с разрешением напрямую разработчик не имеет).
На рисунке ниже показано как соотносятся значения плотности и размера экрана устройств с предопределенными значениями этих величин.
*Еще один момент, который стоит отметить: значение плотности xdpi было добавлено в версии Android 2.2(API level 8), значение экрана xlarge – в версии Android 2.3(API level 9)
Работа с манифестом и загрузкой ресурсов
Начиная с версии Android 1.6, в манифест был добавлен тег , который используется для определения класса устройств, на которых может быть запущено приложение. Атрибуты тега smallScreens, normalScreens, largeScreens, xlargeScreens соответствуют определенным выше значениям экрана и могут принимать значения true или false. Дефолтные значения атрибутов варьируются в зависимости от используемой версии Android (более детальную информацию можно посмотреть тут. ). При определении значения атрибута как true, OS Android получает сигнал о том, что приложение совместимо с соответствующим типом экрана и не применяет дополнительные средства для совместимости ( что происходит при значении false). Стоит также отметить, что эти средства(функции) работают только на совместимость с большими размерами экранов (т.о. если значение normalScreen – true, остальные – false, приложение будет также совместимо с экранами large и с xlarge, но не совместимо со small). Данный тег также используется Android Market’ом для фильтрации приложений.
Для плотности также имеется атрибут – anyDensity, который также принимает значения true/false. Если значение атрибута – true, OS Android не использует функции для совместимости с различными плотностями экрана. В этом случае приложение должно использовать dp для прорисовки UI элементов, либо самостоятельно управлять вычислением размеров для различных плотностей. Если значение – false, OS Android включает функции для масштабирования элементов в соответствии с плотностью экрана.
Размещение ресурсов
OS Android также предоставляет средства для определения ресурсов, которые будут использованы для конкретных размеров экранов и плотностей. Ресурсы размещаются в соответствующих папках.
res/layout/my_layout.xml // layout for normal screen size
res/layout-small/my_layout.xml // layout for small screen size
res/layout-large/my_layout.xml // layout for large screen size
res/layout-large-land/my_layout.xml // layout for large screen size in landscape mode
res/layout-xlarge/my_layout.xml // layout for extra large screen size
res/drawable-ldpi/my_icon.png // image for low density
res/drawable-mdpi/my_icon.png // image for medium density
res/drawable-hdpi/my_icon.png // image for high density
res/drawable-nodpi/composite.xml // density independent resource
Поддержка совместимости экранов
Общие рекомендации для создания совместимого приложения
Послесловие
Статья не охватывает практических моментов, связанных с тестированием приложения на девайсах с различными характеристиками экранов, думаю выделить это в отдельный пост.
Источник
Обновляем проекты Unity Android для совместимости с архитектурой ARM64
Google предложил разработчикам обновить приложения для совместимости с архитектурой ARM64 в срок до 1 августа 2019 года, если они не соответствуют этим требованиям
Найдем и включим поддержку ARM64 в Unity
Для включения, откроем настройки File — Build Settings, далее — Player Settings для платформы Android. В открывшемся инспекторе, видим на вкладке Other settings раздел Configuration.
Обратите внимание! Опция Scripting Backend должна быть установлена в IL2CPP. И после включения этой опции потребуется иметь установленный NDK Android, если он не установлен!
Скачиваем последнюю стабильную версию, прописываем пути к ней — и «упс», самая новая версия NDK для Unity почему-то не подошла!
Не тратьте время, как это сделал я, на скачивание последней стабильной версии с номером 20. Размер этого пакета около 2Gb. Начинайте качать версию r16b (64-bit).
Скачать именно эту, требуемую версию NDK Android r16b (64-bit) для Windows
можно здесь.
После, естественно, распаковать, положить в надежное доступное место и при сборке билда указать путь к этому месту. Или же, сразу прописать этот путь в главных настройках Unity, там есть такое поле для прописывания пути к NDK, а меню называется внешние компоненты (External Tools).
В результате, в опции Target Architectures должен стать активным флажок ARM64. До этих манипуляций флажок был неактивным:
Если в проекте используется Vuforia, ее также требуется обновить
Проекты с использованием Vuforia — ранние версии 64x не поддерживали. Однако, начиная с версии 8.1 Vuforia поддерживает 64-х разрядность.
Лучше всего обновляться непосредственно из Unity. Для этого, идем в меню Window — Vuforia Configuration (Ctrl-Shift-V) — и в инспекторе смотрим на самый верх — если доступно обновление и версия Vuforia не самая новая, то будет доступна ссылка на скачивание — именно она позволяет загружать исполняемый файл обновления.
Второй способ для проверки обновления — можно открыть меню Help — Vuforia Engine — Check for Updates. И если есть обновление, то оно будет предложено к скачиванию.
После скачивания, распакуйте. Внутри должен быть исполняемый файл примерно с таким именем UnitySetup-Vuforia-AR-Support-for-Editor-2018.4-2019.1.exe. Отличаться может версия вашего редактора.
Далее, обратите внимание на правильность действий при запуске этого обновления:
- Принять лицензионное соглашение
- Если Unity редактор открыт, то будет предложено его закрыть
- Выбрать путь к редактору Unity и нажать Update
Причем, если у вас установлен Unity Hub, то путь возможно будет выглядеть как то так: «C:\Program Files\Unity\Hub\Editor\2018.4.3f1\».
Будьте повнимательней с путями и все получится. Когда я указывал путь до той папки, где непосредственно лежит Unity.exe то получал ошибку: «Не могу найти Unity.exe». Правильный путь указывается только до названия версии редактора!
Еще одни грабли могут быть тут. Возможно, вы сами найдете на сайте Вуфории ссылку на Vuforia SDK Engine 8.3: developer.vuforia.com/downloads. Но, здесь скачиваются zip архивы с исходниками SDK, и автоматически установить это в Unity не получится. Не используйте этот архив! Скачивайте файл обновления только по ссылке в редакторе.
Все рекомендации относятся к обновлению Vuforia если у вас установлена Windows. Если же у вас Mac, то отличий немного, разве что в написании путей к папке с редактором Unity. И конечно, выбирайте версии пакетов под свою платформу правильно.
На этом все, спасибо аудитории, надеюсь статья кому-то поможет.
Источник
Перевод «Подготовьте ваши приложения к 64-бит требованиям»
Перевод статьи Get your apps ready for the 64-bit requirement (от 15.01.2019) блога «Android Developers Blog».
Современные 64-бит процессоры увеличивают скорость и обогащают опыт ваших пользователей. Добавление 64-бит версии приложения даёт улучшение производительности, открывает пути для будущих инноваций и настраивает на устройства только с 64-бит «железом»
Мы хотим помочь вам быть готовыми, и знаем что вам нужно планировать время. Мы поддерживаем 64-бит CPU начиная с Android 5.0 Lolipop, и в 2017 году мы впервые анонсировали, что приложения использующие нативный код, должны иметь 64-бит версию (в дополнение к 32-бит версии). Сегодня мы представляем более детальную информацию и временной график, чтобы сделать этот переход как можно более лёгким в 2019 году
64-бит требования: что это означает для разработчиков
Начиная с 1 августа 2019
- все новые приложения и обновления приложений, которые содержат нативный код, должны иметь 64-бит версию в дополнение к 32-бит версиям при публикации в Google Play
- Дополнение: Google Play до августа 2021 продолжит принимать 32-бит версии только в части обновления существующих игр использующих Unity версии 5.6 или младше
Начиная с августа 2021
- Google Play остановит обслуживание приложений без 64-бит версий на 64-бит совместимых устройствах, т.е. они перестанут отображаться в Play Store на этих устройствах
- это будет касаться в том числе игр использующих Unity версии 5.6 или младше
Эти требования не применяются для:
- приложений предназначенных исключительно для Wear OS или Android TV, т.к. они имеют форм-фактор не поддеживающий в настоящее время 64-бит код
- приложений не предназначенных для распространения на устройствах работающих на Android 9 Pie или выше
Мы не меняем наши условия поддержки 32-бит. Play будет продолжать доставлять приложения на 32-бит устройства. Это требование лишь означает что приложения с 32-бит нативным кодом должны будут дополнительно иметь 64-бит версию
Подготовка к 64-бит требованиям
Мы ожидаем что для большинства разработчиков, переход на 64-бит будет простым. Многие приложения написаны полностью на не-нативном коде (например на Java или Kotlin) и не потребуют изменения кода.
ВСЕМ РАЗРАБОТЧИКАМ: вот обзор шагов который вам необходимо проделать для 64-бит совместимости. Для большей информации обратитесь к нашей подробной документации
- проверьте ваше приложение на наличие нативного кода. Вы можете проверить наличие .so файлов с помощью APK Analyzer. Определите состоят ли они из вашего собственного кода или импортированного из SDK или используемой вами библиотеки. Если у вас нет каких-либо .so файлов в вашем APK, то вы 64-бит совместимы
- включите 64-бит архитектуры и пересоберите нативный код (.so файлы) импортированный из вашего собственного кода. Для большей информации см. документацию
- обновите все SDK и библиотеки до 64-бит совместимых версий, если необходимо. Обратитесь к владельцу SDK или библиотеки если такие версии недоступны. Мы работаем с владельцами ведущих библиотек над их 64-бит совместимостью
- проверьте на наличие локальных проблем после пересборки вашего приложения
- разверните ваши тесты используя tasting track для тщательного тестирования
РАЗРАБОТЧИКАМ ИГР: все три наиболее используемых движка в настоящее время поддерживают 64-бит (Unreal и Cocos2d с 2015 года, Unity с 2018). Мы понимаем что миграция стороннего игрового движка это затратный процесс требующий много времени
- т.к. Unity только недавно начала предоставлять 64-бит поддержку в версиях 2017.4 и 2018.2, мы делаем исключение существующим играм использующим версию 5.6 или более раннюю до августа 2021 года. Unity подготовила руководство которое может помочь вам в обновлении для 64-бит совместимости
ВЛАДЕЛЬЦАМ SDK И БИБЛИОТЕК: обновитесь для 64-бит совместимости по возможности скорее чтобы дать разработчикам приложений время на адаптацию, и дайте знать об этом разработчикам. Зарегистрируйте ваш SDK для получения обновлений последних инструментов и информации которая может помочь обслуживать ваших пользователей
Источник