Comments 6
UFO just landed and posted this here
Ну не знаю, а в чем идея? У всего есть границы применимости. Если автор признает, что даже в 2013 году, когда еще по сути не существовало инструментов для кроссплатформенной мобильной разработки, и приходилось на все педалить свой велосипед,
то сейчас, когда есть Qt, Flutter, React Native, для разработки продукта на начальном этапе силами небольшой команды использовать что-нибудь из этого — самое то. Потом, когда продукт и его команда вырастут и начнут приносить деньги, тогда можно будет уже перейти на нативные технологии (если будет смысл в этом к тому времени, конечно).
Такое решение позволило выдавать большой объём кода как на Android, так и на iOS силами маленькой команды
то сейчас, когда есть Qt, Flutter, React Native, для разработки продукта на начальном этапе силами небольшой команды использовать что-нибудь из этого — самое то. Потом, когда продукт и его команда вырастут и начнут приносить деньги, тогда можно будет уже перейти на нативные технологии (если будет смысл в этом к тому времени, конечно).
Расскажу свою историю: Мы делаем фреймворки для офлайн карт, навигации, поиска на iOS и Android. Код максимально шарится между платфомами. Приведу пример: Для того чтобы показать вьюху с картой на стороне ОС мы обрабатываем касания, реализуем API для взаимодействия с компонентом и создаем surface для рендера. Весь остальной код пишется на C++. И там его очень много. Парсинг данных, парсинг стиля, применение стиля к данным, подготовка данных для OpenGL/Metal, весь сетевой стек, очереди фоновых задач, обработка данных пользователя. API, которое видит разработчик — это просто верхушка айсберга. Это с одной стороны. Много сложного кода, его лучше писать один раз. И ошибки ловить один раз.
При этом мы делаем приложения Guru Maps на своих же фреймворках. И тут ситуация обратная весь интерфейс и большинство кода этих приложений пишутся так, как это принято на конкретной архитектуре. Общий код на C++ тоже есть, но его мало. Это работа с данными и конверсия между бинарным форматом,GPX,KML в любую сторону.
Категоричный вывод о том что общий код на C++ вреден — я бы не делал. Он сильно облегчает жизнь. Но это должно быть что-то такое, в чем нужна скорость и нет зависимости от специфичных для платформы плюшек.
При этом мы делаем приложения Guru Maps на своих же фреймворках. И тут ситуация обратная весь интерфейс и большинство кода этих приложений пишутся так, как это принято на конкретной архитектуре. Общий код на C++ тоже есть, но его мало. Это работа с данными и конверсия между бинарным форматом,GPX,KML в любую сторону.
Категоричный вывод о том что общий код на C++ вреден — я бы не делал. Он сильно облегчает жизнь. Но это должно быть что-то такое, в чем нужна скорость и нет зависимости от специфичных для платформы плюшек.
Самое главное, требовалась кастомная система сборки для создания библиотек, которые содержат код C++, а также оболочки Java и Objective-C.Gradle отлично переваривает CMake-проекты.
Зависит от объема приложения и сложности бизнес-логики. Начиная с какого-то момента общая плюсамя часть кода начинает окупаться и приносить доход.
Представьте себе, например, проект масштабов Microsoft Office.
Ясное дело, что на хеловорлдах такой подоход не выстрелит.
Представьте себе, например, проект масштабов Microsoft Office.
Ясное дело, что на хеловорлдах такой подоход не выстрелит.
Поддерживаю автора статьи. В компании, в которой я работал была похожая проблема. Хочу также дополнить, что у нас была поддержка Windows Mobile. Т.е. ядро написанное на C++ должно было поддерживать 3 платформы в идеале. На практике под Windows Mobile было практически своё ядро, что поражало ещё больше проблем.
Также была проблема, если вы распространяете приложение не через Google Play (Bundle), а через платформы, которые этого не поддерживают или обычной apk, то размер apk увеличивается из-за необходимости поддержки всех типов процессоров. У нас кода на C++ было большинство, поэтому размер apk увеличивался кратно количеству процессоров. Можно было конечно apk разбивать, но этот вариант не всегда подходил
Также была проблема, если вы распространяете приложение не через Google Play (Bundle), а через платформы, которые этого не поддерживают или обычной apk, то размер apk увеличивается из-за необходимости поддержки всех типов процессоров. У нас кода на C++ было большинство, поэтому размер apk увеличивался кратно количеству процессоров. Можно было конечно apk разбивать, но этот вариант не всегда подходил
Sign up to leave a comment.
(Не очень) скрытые издержки общей кодовой базы iOS и Android