Как разрабатываются мультиплатформенные приложения?

Question

Мне было интересно, как разрабатываются мультиплатформенные приложения.Такие приложения, как Microsoft Office для MAC / Windows, FireFox для MAC / Windows / Linux и т. Д.

Если им приходится кодировать для разных платформ, им трудно управлять, и возникает множество других сложностей.

В: Как команды разработчиков управляют сложностью разработки для нескольких платформ?

Answer 1

Microsoft office не является мультиплатформенным приложением. Если бы вы когда-либо использовали версию для Mac, вы бы знали. Последней мультиплатформенной версией Office была печально известная версия Office 6.0 в 1998 году. В результате пользователи стонали по поводу внешнего вида и осуждали менталитет «портирования».

Версия Office для Mac написана не только другой командой, но и совершенно другим отделом: подразделением Mac, также известным как MacBU. Разные начальники департаментов, разные менеджеры и, я думаю, разные люди, занимающиеся продажами и маркетингом.

Это один из способов сделать это. Также известен как «правильный путь» среди пользователей Mac.

Конечно, не все имеют размер Microsoft и могут позволить себе создать совершенно другую дочернюю компанию только для поддержки пользователей Mac (а тем более пользователей Linux). Немного более разумный способ сделать это - использовать кроссплатформенную библиотеку для графического интерфейса, такого как wxWidgets или QT или GTK. В конце концов, большая часть вашего кода на C не будет сильно меняться на разных платформах, а только на проприетарных вещах, таких как GUI и управление файлами. Черт возьми, вы можете даже использовать вызов функции POSIX для управления файлами и работы в сети для кросс-платформенности. Но будьте осторожны, есть большая вероятность того, что пользователи Mac будут ненавидеть конечный результат (например, что случилось с MS Office 6.0).

Третий путь - это средний путь. Держите общий основной код приложения отдельно от проприетарного графического интерфейса (что в любом случае является хорошей идеей с точки зрения удобства обслуживания). Шаблон проектирования MVC - хороший способ сделать это. Иметь способ (используя #define или другой сценарий сборки / make-файлы) для переключения компонентов View и Controller вашей инфраструктуры MVC. Это то, что Google делает с Chrome. Версия Mac использует встроенную графику Mac, а версия Windows / Linux использует графический движок Skia . Ядром Chrome являются WebKit и V8, которые являются кроссплатформенными.

Answer 2

Существует, вероятно, почти столько же подходов к этому, сколько и многоплатформенных приложений. В общем, они сводятся к нескольким различным стратегиям:

1. Используйте язык с переносимой средой выполнения - например, Java, в меньшей степени .NET или любой из множества различных интерпретируемых языков сценариев.

2. Используйте кроссплатформенный инструментарий (например, QT), чтобы скрыть различия платформ.

3. Используйте условную компиляцию на таких языках, как C или C ++, чтобы изменить кодовую базу для разных платформ. Это похоже на # 2, за исключением того, что вы по сути создаете свой собственный кроссплатформенный инструментарий внутри своего приложения.

Answer 3

Один из подходов состоит в том, чтобы иметь отдельный класс для каждой конкретной функциональности платформы и иметь все классы, необходимые для конкретной платформы, скомпилированные вместе.Таким образом, код становится чище, а также избегает ненужной абстракции.Вот пример «Загрузка данных XML в MySQL или NoSQL» Синий цвет для NoSQL и розовый для SQL, цвет хаки для общего кода и серый для поддержки языка.

Answer 4

В: Как команды разработчиков управляют сложностью разработки для нескольких платформ?

A: хорошие регрессионные тесты.

Answer 5

Один из способов - создать слой абстракции «Оборудование / Операционная система». Вы создаете свое приложение на C или C ++ с использованием стандартной библиотеки C или эквивалентного кода, который не зависит от платформы, на которую вы нацелены.

Для ОС или аппаратных интерфейсов (таких как диалог загрузки / сохранения, печать, панели инструментов, уведомления и т. Д.) Вы создаете обобщенный API для вашего приложения, а затем кодируете две отдельные реализации - по одной для каждой целевых платформ.

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

Answer 6

Основной подход для многоплатформенного кода, это многоплатформенная база.Например, код C ++, который свободно использует библиотеку boost (для доступа к файлам, примитивам синхронизации потоков и т. Д.), Будет работать в многоплатформенном режиме.Аналогично, если вы создаете .net (управляемый) код, тогда ваши кроссплатформенные возможности достигаются с помощью среды выполнения .net (если в Windows) или Mono (в системах Linux).вопросы, чем эти, но это самое большое.Другие вопросы могут включать, в случае C ++, как обрабатывается GUI.Преднамеренный выбор использования кросс-платформенного кода снова играет свою роль - например, использование WxWidgets или Qt.

Также полезно иметь процесс кросс-платформенной сборки .

Answer 7

Если вы говорите скомпилированный C ++, вы получите несколько условных определений, таких как #IFDEF WIN32 в нескольких местах кода. Когда вы пишете кросс-платформенный код, вы должны тестировать кросс-платформенный. Помогает система сборки, такая как Hudson, которая может создавать ваш код на всех платформах при регистрации.

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

Надеюсь, это поможет!