Являясь не Android разработчиком, но имея хорошие базовые знания в Java, мне выпала небольшая research задача под Android платформу, для решения которой нужно было интегрировать стороннюю с/c++ библиотеку в Android Studio проект. В данном статье будет:

• пошаговое описание как собрать c/c++ проект, который корректно настроен под CMake систему сборки
• интеграция полученной библиотеки в Android проект через Android Studio

Введение

Поиск по ключевым словам в русскоязычном сегменте интернета на удивление дал мало результатов на данную тему. Но нашлась единственная довольно подробная статья на хабре https://habr.com/ru/company/e-Legion/blog/487046/, с которой вы заметите как сходства, так и различия. Для сравнения подходов решил так же для примера использовать проект с открытым исходным кодом https://opus-codec.org, что и в указанной статье. Система на которой будут выполняться все эксперименты MacOS Big Sur имея на борту cmake версии 3.19.3.

Сразу хочу отметить, что не являюсь экспертом по CMake и Android. Все действия, описанные в статье, вы делаете на свой страх и риск и автор не несет никакой ответственности за ваше потраченное время.

Всем привет. Сегодня поговорим о практическом использовании NSProxy класса, пост будет небольшим, думаю многим новичкам будет интересно почитать.

Немного оффтопа.

В общем, по распределению в компании я попал на легаси проект на Objc, где massive view controller считался эталом архитектуры. Конечно же без нормальной спеки и тестов. За недолгую карьеру разработчика у меня выработалось пару правил для таких вот проектов, первое — никакого рефакторинга с моей стороны без указания сверху, второе — трогать существующий код только в крайней необходимости. Всё это на почве того, что в таких проектах очень сложно отловить регрессию (а может я просто ленивый?).

Знакомьтесь, Боб — матёрый ios разработчик, Алиса — не менее матёрая тестировщица. Дело было вечером дело было в пятницу. Боб дофиксил багу, вроде бы протестил на своих девайсах. Затем Боб запускает уже отточенные до автоматизма команды:

git checkout develop
git merge bug_fix_#999
git checkout master && git merge develop --no-ff ....
git push ....

На пуш на сервере срабатывает jenkins/teamcity/travis, который запускает билд. В это же самое время наш Боб пишет Алисе, что скоро пойдет домой, и хочет, чтобы аппа ушла сегодня в app store на апрув, дабы выиграть лишние пару дней, так как на носу выходные, если, конечно, приложение пройдет ручное тестирование Алисы.

Приложение Боба довольно обычное: пару сотен компилируемых класс файлов, еще с десяток cocoapods зависимостей ну и кучка сторибордов — Боб ценит своё время и время коллег поэтому не пишет UI в коде. Боб знает, что его приложение с чистого старта на сервере собирается за 4 минуты для develop версии, которое идет на тест Алисе, и столько же или чуть больше для production версии. Боб также знает, что ему нужно около 10 минут, чтобы дождаться окончания полной сборки и затем сообщить Алисе, что она может приступать к тестированию. Боб человек ответственный, поэтому по истечении 10 минут после пуша проверяет статус билда, так как знает, что сервер — это отдельный параллельный мир со своими правилами, законами и странностями.

Пятница, вечер, Боба отделяет от долгожданных выходных только 10 минут, после которых передаст эстафету Алисе. Боб вбивает в сафари bobcompany.ci/dashboard, где видит красную лампочку напротив своего приложения, глаза Боба потускнели, разочарованию не было предела. Боб жмет на show more, где его встречает ошибка:

Code Sign error: No codesigning identities found: No codesigning identities (i.e. certificate and private key pairs) that match the provisioning profile specified in your build settings (“com.company.bob”) were found.

Тут нервы Боба совсем сдают:

В начале мая на просторах интернета разработчики языка объявили, что начинают подготовку к релизу 3.0 версию языка. Разработка 3.0 идет в мастер ветке, по релизам, можно понять, что 3-го мая был релиз Swift 2.2.1. Затем туда же начали вливать изменения касательно 3-ей версии языка. 9-го мая уже появился первый developer релиз из того же мастера, который можно накатить на последний xcode через установщик из swift.org/download/#snapshots, который включается через Preferences -> Components -> Toolchains.

Немного общей информации о будущем релизе

Не всем повезло писать приложения полностью на Swift, да и еще под ios 8+ онли. Много легаси на Objective-C, много зависимостей идет через статик либы, ни cocoapods, ни carthage, всё ручками. Мы же крутые девелоперы, поэтому строго следуем DRY и все реюзабельные вкусшянки выносим либо в отдельные проекты, либо в статик библиотеки. Сейчас рассмотрим случай, когда мы сделали классную статичную библиотечку с не менее прикольным апи, и хотели бы поделиться с товарищами по цеху внутри компании — на вики ресурсе/гите выложить архивчик с либой, хедерами и, конечно же, ридмиком где описан весь апи и как им пользоваться.

Для примера ради рассмотрим один класс + его категорию

Пост основан на статье medium.com/@RobertGummesson/regarding-swift-build-time-optimizations-fc92cdd91e31 + небольшие изменения/дополнения, то есть текст идет от моего лица, не третьего.

Всем знакома ситуация после изменения файла(ов) или просто переоткрытия проекта:






Нужно сказать, что какой-то особой проблемы с компиляцией я не замечал когда писал на Objective-C, но всё изменилось с приходом в массы swift. Я частично отвечал за CI сервер по сборке iOS проектов. Так вот, проекты на swift собирались невыносимо медленно. Еще разработчики любят тащить поды (cocoapods зависимости) на каждый чих в свои swift проекты, иногда, в безумном количестве. Так вот, компиляция всей этой смеси могла продолжаться несколько минут, хотя сам проект состоял буквально из пары десятков классов. Ну ладно, как бы ясно, язык новый, на этапе компиляции происходит намного больше проверок, чем в том же ObjC, глупо ожидать, что она будет работать быстрее (да, swift это строго типизированный язык и всё должно быть максимально явно объявлено (как в Java, например), в отличии от ObjC, где не всё так строго). Разработчики swift с каждым релизом обещают в x раз ускорения скорости компиляции. Ну вроде, действительно, сборка 2.0 и уже потом 2.2 стала работать быстрее, вот вот на носу уже 3.0 версия (конец года).

Компилятор компилятором, но оказывается, что время сборки проекта можно катастрофически увеличить буквально несколькими строчками кода. Часть примеров взято из вышеупомянутой статьи, часть самописные (не поверил автору и хотелось самому проверить). Время замерял через

time swiftc -Onone file.swift

Вольный перевод статьи gingearstudio.com/why-i-quit-my-dream-job-at-ubisoft от бывшего разработчика из Ubisoft.

Вступление

2005 год, я помню как начальство спросило меня, где я вижу себя через 10 лет, на что я ответил, что вижу себя в роли software-архитектора крупнейших AAA-класса гейм-проектов. Мечта стала реальностью буквально через несколько лет, когда я начал работать над проектом Assassin’s Creed Syndicate в роли, как вы уже догадались, software-архитектора. И вот, казалось бы, наконец, моя мечта быть причисленным к числу тех самых крутых, высокоуважаемых гейм-разработчиков, становится реальностью в процессе работы над престижнейшей игровой франшизой.

Но всё изменилось, я покинул работу в пользу своих инди-проектов. Несколько друзей и членов семьи конечно же осудили мое внезапное и необдуманное, по их мнению, решение. Они были удивлены, почему же я оставил хорошо оплачиваемую, уважаемую работу.

Прощаясь со всеми в свой последний рабочий день никто даже не спросил почему я ухожу в инди-разработку, так как даже люди, едва знавшие меня, скорее всего догадывались почему. Конечно же, большинство профессиональных гейм-разработчиков скорее всего знали истинную причину моего ухода.

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

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

В общем, стоит начать с того, что в моей компании имеется отдел ios разработки в составе > 10 человек, которые работают над пачкой приложений. Для автоматизации рутинной работы нам пришлось развернуть CI сервер (пока самописный, ввиду особых исторических причин (ну как у всех), планируется миграция на jenkins). К рутинным вещам я отношу — сборку проектов, запуск тестов (если, конечно, вы их пишете), создание ипашек для тестеров и для выкладки в app store. В общем, хотелось чтобы по нажатию кнопочки или по хуку в гите всё это начинало работать. Пока у нас всё работает по нажатию кнопки разработчиком, про гит пока только в планах. В данной статье я только затрону тему компиляции проекта и упаковку его в ipa файла. Функционал запуска проектов на девайсах на стороне CI сервера еще находится в стадии разработки, а вот сам процесс упаковки уже давно в «бою», может кому пригодиться.

Что планируем:

• соберем приложение и запустим на симуляторе
• соберем ipa и запустим на реальном девайсе
• соберем ipa для выкладки на маркет
• немного подэбажим ошибки сборки