Apple Silicon M1: взгляд разработчика
Обсуждение нового чипа Apple Silicon M1 повсюду. Я купил MacBook Air 16 ГБ M1, чтобы понять, насколько он жизнеспособен в качестве основной машины для разработки — вот предварительный отчет после недели тестирования.
Обсуждение нового чипа Apple Silicon M1 повсюду. Я купил MacBook Air 16 ГБ M1, чтобы понять, насколько он жизнеспособен в качестве основной машины для разработки — вот предварительный отчет после недели тестирования.
Xcode на Apple Silicon M1
Xcode на M1 работает БЫСТРО. Компиляция PSPDFKit PDF SDK (debug, arm64) может конкурировать с самыми быстрыми MacBook Pro на базе Intel, которые предлагает Apple на сегодняшний день — 8:49 мин против 7:31 мин. Для сравнения, мой Hackintosh билдит то же самое менее чем за 5 минут.
Трудно переоценить, насколько это впечатляет для машины без кулера. Последним экспериментом Apple с MacBook без него была 12-дюймовая версия 2017 года, в которой тот же проект собирался 41 минуту.
My M1 MacBook Pro arrived today. Chances are you have various questions, but I think a whole lot is summed up in this 50-second video. (Alt text, because Twitter still doesn’t make this easy: Xcode 12.3 beta unzips in 5 minutes on an M1, vs 13 minutes 22 seconds on an Intel i9) pic.twitter.com/STiivUXXnH
Наши тесты в основном прошли нормально, хотя я обнаружил ошибку, специфичную для arm64, которую мы пропустили раньше, так как мы не запускаем наши тесты на реальном оборудовании в ходе CI. Перенос симулятора на ту же архитектуру, что и у продающихся устройств, будет полезным и поможет найти больше ошибок.
Тестировать iOS ниже 14 проблематично. Похоже, WebKit дает сбой в распределении памяти, выдавая EXC_BAD_INSTRUCTION (code = EXC_I386_INVOP, subcode = 0x0) (FB8920323). Производительность также кажется очень плохой: Xcode периодически зависает, и вся система становится настолько медленной, что курсор мыши дергается. Некоторые симуляторы создают проблемы даже с iOS 14, например iPad Air (4-го поколения), который все еще эмулирует Intel, поэтому постарайтесь избегать этого.
Мы были очень взволнованы переносом нашего CI на Mac Mini с чипом M1 и ожидаем, что MacStadium получит эти устройства, однако, похоже, нам придется ограничить тесты только iOS 14, чтобы это работало. В соответствии с нашим текущим графиком мы планируем отказаться от iOS 12 в третьем квартале 2021 года и от iOS 13 в третьем квартале 2022 года, так что пройдет некоторое время, пока мы сможем полностью перейти на Apple Silicon.
Есть шанс, что Apple исправит эти проблемы, однако на это не стоит рассчитывать — учитывая, что это затрагивает только старые версии iOS, проблема в какой-то момент просто «исчезнет».
Сейчас мы работаем над сбоями в WebKit отслеживая трансляцию Rosetta2 во время выполнения и просто пропуская тесты, в которых используется WebKit. Это не очень хорошо, но, к счастью, мы не часто используем WebKit в нашем текущем проекте. Производительность кажется приемлемой, если вы ограничиваете параллельное тестирование не более чем двумя инстансами — в противном случае системе просто не хватает оперативной памяти, и свап происходит очень медленно.
Docker
Мы используем Docker для автоматизации нашего веб-сайта и загрузочных сред для наших веб и серверных PDF SDK. Docker опубликовал в блоге сообщение о текущем состоянии дел, признав, что в настоящее время система не работает, но они пытаются исправить это. Есть хитрые способы использовать Гипервизор Apple для запуска контейнера Docker вручную, однако для этого нужны контейнеры на основе ARM.
Я ожидаю решения в первом квартале 2021 года, в котором будут работать контейнеры на базе ARM. Нам нужно будет немного поработать, чтобы добавить поддержку arm (что-то уже есть в дорожной карте), так что это только проблема перехода.
Виртуализация и Windows
Чтобы тестировать наш Windows PDF SDK, большинство наших разработчиков использует виртуальную машину VMware с Windows 10 и Visual Studio. В настоящее время ни одно из решений виртуализации Mac не поддерживает Apple Silicon, однако и VMware, и Parallels работают над этим. Я не ожидаю, что Virtualbox будет обновлен в ближайшее время.
Я ожидаю, что в конечном итоге мы сможем запускать Windows с набором коммерческих инструментов на базе ARM. Уже существуют различные proof-of-concepts, и производительность кажется многообещающей. Microsoft в настоящее время не продает Windows на базе ARM, поэтому будет интересно получить лицензию.
ARM-Windows может эмулировать приложения x86, а Microsoft работает над эмуляцией x64, которая уже внедряется в сборках Insider. Через несколько месяцев появится возможность разработать и протестировать наш Windows SDK с Visual Studio на M1 с приемлемой производительностью.
Запуск более старых версий macOS может быть более проблематичным. В настоящее время мы поддерживаем macOS 10.14 с нашим AppKit PDF SDK и macOS 10.15 с Catalyst PDF SDK, обе версии ОС требуют тестирования. Еще неизвестно, включат ли VMWare или Parallels полный уровень эмуляции x64. Скорее всего, это будет очень медленно, поэтому я бы не стал на это рассчитывать.
Кроме того, 16 ГБ ОЗУ — это мало. При запуске параллельных тестов машина начинает сильно свапить, и производительность действительно падает. Это будет еще более проблематично при запущенных виртуальных машинах. В будущем у Mac-ов будет вариант с 32 ГБ, что поможет решить эту проблему.
Android Studio на Apple Silicon M1
IntelliJ работает над портированием JetBrains Runtime на Apple Silicon. В настоящее время приложения работают через Rosetta 2, однако сборка через Gradle происходит очень медленно. Gradle создает код в рантайме, что кажется особенно плохим сочетанием с логикой опережающей трансляции Rosetta 2.
Я ожидаю, что большинство проблем будет решено к первому кварталу 2021 года, однако, вероятно, пройдет еще больше времени, пока все версии Java не заработают на ARM. Много усилий было вложено в развертывание циклов и векторизацию, и пока еще не все доступно на ARM.
Homebrew
Homebrew в настоящее время работает через Rosetta 2. Просто добавьте перед всем префикс arch -x86_64, и все будет работать. Можно установить дополнительную (основанную на arm) версию Homebrew в /opt/homebrew и смешать установки, поскольку все больше и больше программного обеспечения добавляет поддержку ARM.
В настоящее время это не проблема (производительность хорошая), и со временем это будет просто работать нативно.
Приложения
Большинство приложений просто работают, Rosetta еле заметна. Более крупные приложения в начале заметно снижают производительность (например, Microsoft Word нужно около 20 секунд на трансляцию), но затем двоичные файлы кэшируются и последующие запуски выполняются быстро.
Иногда бывает, что приложение не может быть транслировано и падает при запуске (например, Beamer или клиент Google Drive), но это случается редко. Некоторые приложения не понимают своего места на диске и просят переместить их в каталог Applications, хотя на самом деле это просто переведенный двоичный файл, который выполняется где-то еще. Большинство этих запросов можно игнорировать. Некоторые приложения (например, Visual Studio Code) блокируют автоматическое обновление, поскольку местоположение транслируемого приложения доступно только для чтения. Однако в случае VS Code сборка Insider уже обновлена для ARM и нормально работает.
Приложения на основе Electron работают медленно, если работают на Rosetta. Похоже, что оптимизированный компилятор JavaScript V8 блокирует ahead-of-time трансляцию. Последняя стабильная версия Electron (версия 11) уже полностью поддерживает Apple Silicon, и такие компании, как Slack, уже обновили свои бета-версии для работы в нативном режиме.
Google только что выпустил Chrome, который работает на ARM, однако между ним и Apple Safari, который просто летает на Apple Silicon, все еще существует значительный разрыв в производительности.
Вывод
Новые MacBook M1 быстрые, красивые, тихие, и хайп полностью оправдан. В области программного обеспечения еще многое предстоит сделать, чтобы наверстать упущенное, и ошибки, связанные с более старыми симуляторами iOS, доставляют больше всего проблем.
Все это можно исправить в самом ПО, и вся отрасль в настоящее время работает над улучшением этого опыта, поэтому к следующему году, когда Apple обновит 16-дюймовый MacBook Pro и выпустит следующее поколение своей линейки чипов M, можно будет использовать Mac M в качестве основной машины разработчика.
В настоящее время Apple Silicon M1 будет моим вторым ноутбуком в путешествиях, и я продолжу работать с 16-дюймовым MacBook Pro с частотой 2.4 ГГц и 32 ГБ оперативной памяти, который сейчас является более быстрой машиной. Мне будет намного труднее принять шум постоянно работающих кулеров теперь, когда я знаю, какая тишина скоро станет возможной.
Источник
О том, как я написал простое приложение для Android/iOS
Хочу сразу отметить, что это не статья от профессионала, скорее взгляд любителя на мобильную разработку, скажем так, «с нуля». Мое основное занятие — это создание сайтов. В данное время я работаю у провайдера интернета и занимаюсь поддержкой внутреннего биллинга/сайта и так далее (PHP и немного Perl), довольно скучное занятие, скажу я вам. В общем, я обычный провинциальный «программист».
В один прекрасный момент у руководства компании возникла идея сделать мобильное приложение для iPhone, которое могло бы показать баланс пользователю, его статус, возможность взять «обещанный платеж», фактически, дублирование личного кабинета, но чтобы приложение. Не зная про мобильную разработку совсем ничего, идею воспринял с большим энтузиазмом, потому что всегда приятно делать/узнавать что-то новое, думаю, это у всех так.
Придя на работу в один из серых скучных дней, я решился и написал в поиске Google «как сделать мобильное приложение». Это было очень наивно. Кажется, я даже попробовал задать вопрос на Toster, «с чего начать разработку под мобильные приложения», тогда я еще не понимал насколько глупым воспринимается этот вопрос профессионалами.
Довольно быстро я разделил для себя разработку на две части, это был Android и iOS, потому что они совсем разные (поиск подсказал.
Как-то я наткнулся на Phonegap, насколько я понял, пишем на Javascript+html+css, а потом получаем готовое приложение для Android/iOS, но почему-то мне не хотелось пользоваться подобными решениями, во-первых: были непонятные отзывы, кто-то хвалил, кто-то ругал, а во-вторых: мне хотелось попробовать как это изнутри, каково это сделать «нативное» приложение.
План и подготовка
Собственно, идея довольно проста:
- Логин экран с логином/паролем
- Основной экран с информацией об абоненте (ФИО, № договора, баланс, статус (Активен, Отключен), есть ли авария на доме, кнопка Активировать обещанный платеж
- Экран с платежами (зачисления на счет)
- Экран со списаниями по счету
Для функционирования приложения я написал простейшее API на PHP, скрипт который по определенному запросу отвечал строкой в JSON-формате. Сделать это оказалось элементарно.
Начать решил с Android.
Android
Начал я с установки Android Studio, первоначально смутило количество кнопочек/иконок, но за пару дней я уже был как рыба в воде. Для начала надо было понять как вообще делаются приложения, очень помогает изначальное «Hello world!» которое создается по-умолчанию. Выглядело все достаточно просто и понятно. Погуглив «Как начать разработку в Android Studio», я понял, что надо скачать SDK. Открыв SDK-manager я не понял вообще ничего, ну, точнее, не понял что именно надо делать, поэтому поставил все галочки и ждал пока все скачается. Для чего оно мне нужно я совсем не понимал, общее представление конечно было «чтобы работала поддержка такой-то версии», но почему надо все отдельно качать и выбирать среди сотен галочек — бррр.
Вторым достаточно сложным этапом было запустить приложение на симуляторе. Погуглив, пришлось повозиться с AVD, конечно, потыкашись как слепой котенок я сделал несколько виртуальных устройств. На одном даже запустилось приложение. Честно сказать, симулятор у Android Studio совсем не User-friendly, очень долго я с ним воевал, пытался запускать по-разному, хотел чтобы кнопки управления были на экране и работали, но почему-то не работали. Видимо, сказывалось отсутствие опыта.
Как оказалось, для Android пишут на Java. Про Java я знал только то, что это язык программирования и это не Javascript.
Решил разбить большую задачу на более мелкие.
Теперь возникла ситуация когда у меня, в принципе, все готово, но я не знал как вообще делается приложение, поэтому, погуглив, я понял что никакой нормальной информации на русском языке мне не найти (либо я плохо искал). Информация либо устаревшая, либо не то что мне требуется. Спас меня youtube и знание английского языка. Сделав несколько запросов в ютюбе можно найти массу информации, да еще и с самим процессом — это очень помогло, если бы не обучающие видео, думаю, приложение я бы делал несколько месяцев.
Выбирая минимальную версию Android я остановился на 4 что-то там 🙂 (Охват аудитории 90%+ если верить Google).
Опять же разбив свои задачи на более мелкие я искал туториалы в youtube, например: «how to get json in android» или «menu in android studio». Конечно, пришлось пересмотреть штук 30 разных видео и все они были на английском (одно на немецком и одно на китайском — когда показывают не так сложно самому дойти что же говорят :)).
Разработка под Android заняла примерно неделю с момента установки Android Studio. После чего отобрав планшет у сына я смог протестировать свое приложение на реальном устройстве — просто подсоединив его к компьютеру.
Публикация в Google Play
Сначала я думал что будет очень сложно и даже переживал, но как оказалось всего 25$ и фактически без каких-либо серьезных проверок приложение попало в Google Play и через несколько часов было доступно в поиске, публикация заняла около одного дня.
Отдохнув пару дней и поразмыслив, решил что пора реализовать тоже самое приложение под iOS. Но, оказалось, что бесплатная среда разработки xCode может быть запущена исключительно в среде Mac. Пришлось скачать образ виртуальной машины MAC OS Yosemite и запустить ее через VMWare. Сделать это было очень просто и фактически не требовало от меня никаких телодвижений кроме как «ждать».
После чего я скачал xCode и начал разбираться, дело пошло быстрее, так как разработка под мобильные устройства что для Android, что для iOS примерно схожа в своих идеях.
Язык программирования выбрал Swift. Версию iOS минимум 7.1+
В принципе разработка под iOS была более простой, хотя баги симулятора присутствовали, но весь процесс оказался более удобным, нежели под Android. Опять же я открыл youtube и смотрел видео/читал руководства о том, как сделать какую-то вещь. Например, нагуглил прекрасный скрипт который делает slide menu, которого у меня не было в Android. В общем, еще один марафон и за неделю было готово улучшенное приложение, добавил возможность пополнить счет с помощью карты предоплаты и совместил платежи/списания в одно окно.
Использовал тоже самое API (тот же скрипт, что и для Android).
Публикация в iOS
Тут все оказалось не так радужно и просто как в Android. Во-первых, оказалось, что мне требуется реальное устройство для тестирования приложения, а без него никак не опубликоваться. Пришлось искать iPhone и привязать его к профилю тестирования.
Опять же, при создании аккаунта был выбор между «компания» и «индивидуальный разработчик», но начитавшись страшилок про 4+ месяца проверки компаний я решил регистрироваться как индивидуальный разработчик. Сделать это было не сложно, главное оплатить 99$ за аккаунт разработчика iOS со своей кредитной карты чтобы имя совпадало (подсказал поиск). Платеж проходил 2 дня.
После чего пришлось искать целое видео «how to publish in app store» и следовать инструкции, настолько там все непонятно. Какие-то сертификаты, туда — сюда. В общем, не очень удобно, хотя и сделать надо лишь один раз :).
Приложение ушло на проверку и ждало очереди около полутора недель. После чего было принято. Кстати, как показали логи, проверка была примерно такая: Логин -> Баланс -> Платежи -> Баланс. И все, хотя была еще страница «Пополнить баланс», но ее не проверяли (а зря, я там накосячил и пришлось выкладывать новую версию программы 1.1 которую тоже проверяли больше недели).
Выводы
1. Как оказалось это не сложно даже для человека который никогда не использовал Java/Swift/Mac OS.
2. Много новой информации заставляло мой мозг просто переполняться в первые дни и зависать. Помогал только сон, после него я более четко понимал что делать дальше. Не надо бояться таких этапов. Иногда мне казалось что «я вообще ничего не понимаю», были ощущения что я бьюсь головой в бетонную стену. Но на следующий день я решал проблему. Например, в Android, в самом начале у меня возникла ситуация «ничего не работает», когда я подключался к серверу и должен был получать информацию, оказалось, надо было это делать в асинхронном потоке. Потратил целый день.
3. Очень быстрое устаревание руководств/видео уроков. Платформы настолько быстро развиваются, что надо сразу проверять актуальность информации. На русском языке ее очень мало, после нескольких попыток я даже бросил искать и сразу начал штудировать stackoverflow и англоязычный интернет. Youtube со своими видео-уроками просто спас меня! Я открывал видео на одном мониторе и работал на втором. Без базового английского — никуда.
4. Сервисы вопрос-ответ реально помогают! Иногда, впадая в ступор я задавал вопросы и почти сразу получал ответы — очень удобно если находишься в тупике.
5. Apple более чутко относится к публикации приложений, но особых проблем кроме длительного времени я не заметил. Android же делают все очень быстро (зато пускают всех подряд, как я понял).
6. В общей сложности я потратил почти месяц (на разработку около двух недель с перерывами). Стоило ли оно того — думаю да, было очень интересно. Если у вас есть желание — попробуйте, все оказалось не так сложно. У меня нет смартфона Android/iPhone, но и без них все оказалось просто. Симуляторы работают достоверно.
Приложение называется dagotel, но оно создано для клиентов, поэтому дальше логина не пустит. Разве что посмотреть скриншоты.
Понятия не имею, зачем я написал эту статью и какие цели преследовал, но раз написал, решил опубликовать.
Источник
