Если вы разрабатываете мобильные приложения, то почти наверняка сталкивались с Flutter — мегапопулярным открытым фреймворком от Google. Наша команда Mobile SDK and Applications Development, конечно, тоже захотела использовать Flutter при создании приложений для KasperskyOS — собственной микроядерной операционной системы «Лаборатории Касперского» — но был нюанс…



Особенности архитектуры KasperskyOS задают условия, при которых мы не можем пойти проторенными дорожками и свободно интегрировать фреймворк на своей платформе. Подсмотреть решения где-то вовне мы не можем тоже — таких кейсов в индустрии просто не было. А сам Google практически не раскрывает внутреннюю архитектуру Flutter. Так что интеграцию требовалось выстраивать с нуля.

И мы залезли под капот Flutter и нашли решения, которые, с одной стороны, были бы удобны разработчикам, а с другой — устраивали бы нас с точки зрения безопасности и производительности.

Если вы тоже разрабатываете приложения, где требуется разбираться во внутренней архитектуре Flutter, статья точно будет вам полезна — ныряйте под кат!

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

Демонстрация идеи будет проходить на живых примерах кода на современном C++. Большинство описанных решений я применял сначала на собственных проектах, а теперь часть этих подходов уже используется в нашей собственной микроядерной операционной системе «Лаборатории Касперского» (KasperskyOS).

Сразу хочу оговориться, что тема многопоточности — очень большая и серьезная. И эта статья — не полноценный анализ проблем многопоточки, а только частНЫе (но довольно частЫе) кейсы, когда мы вынуждены использовать мьютексы.

Этот небольшой пост может оказаться полезен тем, кто хотел бы быстро начать работать с LLVM, не заморачиваясь с закачкой исходников и построением фреймворка. Кто не хотел бы ковыряться в малопонятных скриптах CMake-а, чтобы добиться ожидаемого результата, ну и наконец, просто для ленивых :)

Я расскажу, как сделать это изящно, буквально парой строк в билд-скрипте Gradle-а.

Задавшись этим вопросом я, в первую очередь, сформулировал требования: жесткие и опциональные (но желательные) для системы сборки и графической среды разработки.
Сразу хочу отметить что речь идет о написании C++ кода не под какую-то специфичную платформу типа Android или фреймворка, например Qt, — где все уже готово, как с построением так и с редактированием кода, а об generic коде не привязанному к конкретной платформе или фреймворку.

Закончив очередной проект на Java, я попытался разобраться в причинах накопившегося раздражения. Да я люблю Яву и все такое, но… Есть несколько «но», которые досаждают. Приходится писать довольно много шаблонного кода, с генерацией которого вполне может справиться сам компилятор, IDE, конечно, выручает, но это не решение проблемы, а скорее костыль: если что-то изменилось, нужно перегенерить и вычистить и т.д. Проверки на null! Это зубная боль, по-хорошему, нужно делать их всегда дабы не нарваться на «нежданчик» в виде NullPointerException в самый неподходящий момент. Короче говоря, появилось желание посмотреть, что еще появилось в природе и сможет ли это нечто заменить мне Java. Дальше имеет смысл описать участников данного сравнения. Сразу скажу, что не претендую на полноту анализа, к сожалению, у меня было слишком мало времени, чтобы как следует познакомиться с каждым языком.

Обязательные требования к претендентам, которые у меня были:

• Язык общего назначения
• Кроссплатформенность (хотя бы Windows/Linux)
• Стабильность
• Статическая типизация
• Автоматическая уборка памяти
• Поддержка полноценной объектно-ориентированной парадигмы
• Хорошая поддержка в IDE (Eclipse, IDEA или на худой конец NetBeans)
• Безгемморойный доступ к существующим фреймворкам/библиотекам
• Производительность на уровне Java