Как скопировать код между Android и iOS
Я отхожу от строгой разработки Android и хочу создавать приложения для iPhone. Я понимаю, что я могу кодировать серверные приложения iOS на C/С++, а также использовать NDK для включения кода C/С++ в приложениях Android. Мой вопрос, однако, как? Я немного искал Google, и я не могу найти четких и сжатых ответов.
При взгляде на пример кода для NDK кажется, что все имена функций и т.д. - это Android (или, по крайней мере, Java), и поэтому я не смогу использовать этот C/С++-сервер для разработки интерфейса iPhone?
Я был бы признателен за некоторые разъяснения по этому вопросу, и если бы у меня был какой-то код, который бы мне помог? (даже просто простой Hello World, который читает строку из файла C/С++ и отображает ее в приложении для iOS и Android).
Спасибо, ребята!
Крис
Ответы
Ответ 1
Пока настроение звучит (вы следуете политике "Не повторяйте себя" ), это только прагматично, если вы можете эффективно использовать этот код. В этом случае не возможно иметь подход "один раз" к кросс-платформенной разработке, где код для двух платформ должен быть написан на разных языках (C/С++/Obj-C на iPhone, Java для Android).
В этом случае вам лучше написать два разных кодовых файла (на двух разных языках). Совет: не пишите свой Java-код, как на С++, или на ваш код на С++, как на Java. Несколько лет назад я работал в компании, у которой был продукт, который они "портировали" с Java на С++, и они не записывали код на С++, как это было на С++, и это вызывало всевозможные проблемы, не говоря уже о том, читать.
Ответ 2
Обратите внимание, что я почти исключительно работаю над приложениями "бизнес/полезность/производительность"; вещи, которые в значительной степени зависят от довольно стандартных элементов пользовательского интерфейса и ожидают полной интеграции с их платформой. Этот ответ отражает это. См. Комментарий Митча Линдгрена к Shaggy Frog ответьте за хорошие комментарии для разработчиков игр, у которых совершенно другая ситуация.
Я считаю, что @Shaggy Frog здесь некорректна. Если у вас есть эффективный, проверенный код на С++, нет причин не делиться им между Android и iPhone, и я работал над проектами, которые делают именно это, и это может быть очень успешным. Однако есть опасности, которых следует избегать.
Наиболее критично, будьте осторожны с "самым низким общим знаменателем". Самодостаточный, алгоритмический код, очень хорошо делится. Сложные структуры, которые управляют потоками, разговаривают в сети или иным образом взаимодействуют с ОС, более сложны в том, чтобы сделать это не заставляя вас нарушать парадигмы платформы и снимать для ЖК-дисплея, который одинаково плохо работает на всех платформах, В частности, я рекомендую написать свой сетевой код, используя платформы платформы. Для этого часто требуется подход "сэндвич", где верхний слой является специфичным для платформы, а самый нижний слой является специфичным для платформы, а средний - переносимым. Это очень хорошая вещь, если она тщательно разработана.
Управление потоками и таймеры также должны выполняться с использованием платформ платформы. В частности, Java сильно использует потоки, в то время как iOS обычно полагается на свою runloop, чтобы избежать потоков. Когда iOS использует потоки, GCD настоятельно рекомендуется. Опять же, решение здесь заключается в том, чтобы изолировать по-настоящему портативные алгоритмы и позволить платформенному коду управлять тем, как он вызван.
Если у вас есть сложная существующая инфраструктура, которая сильно переполнена и имеет большое количество сетевого или UI-кода, распространяемого по всему миру, то ее совместное использование может быть затруднено, но моя рекомендация по-прежнему заключается в поиске способов рефакторинга, а не переписывайте его.
Как разработчик iOS и Mac, который широко работает с кросс-платформенным кодом, разделенным на Linux, Windows и Android, могу сказать, что Android на сегодняшний день является самым раздражающим для платформ, которыми можно поделиться (Windows используется для проведения этого различия, но Android сдул его). У Android было больше всего случаев, когда нецелесообразно делиться кодом. Но есть много возможностей повторного использования кода, и их следует продолжать.
Ответ 3
Написание общей базы кода действительно практично в этой ситуации. Есть некоторые накладные расходы на настройку и поддержание ее организованности, но основными преимуществами являются: 1) уменьшение количества кода путем совместного использования общей функциональности; 2) исправление ошибок исправления для общей базы кода. В настоящее время я знаю о двух маршрутах, которые я рассматриваю для проекта, - используйте собственный c/С++ (выигрыш в скорости за счет потери сбора мусора и установки целей на процессор) или используйте monodroid/monotouch, которые обеспечивают привязки С# для каждой функциональности платформы os (я не уверен, насколько это зрелое.)
Если бы я писал игру с использованием 3d, я бы определенно использовал подход № 1.
Ответ 4
Я отправил этот же ответ на аналогичный вопрос, но считаю, что это так важно...
Я использую BatteryTech для моей платформы-абстракции, а моя структура проекта выглядит следующим образом:
На моем ПК:
-
gamename
- содержит только общий код
-
gamename-android
- содержит в основном код Android android для Android и Android, разработчики указывают на проект игрового имени для общего кода
-
gamename-win32
- Просто для построения Windows, использует код из проекта gameame
На моем Mac:
-
gamename
- содержит только общий код
-
gamename-ios
- сборка iPhone/iPad, импорт общего кода
-
gamename-osx
- Собственная сборка OSX. импортирует общий код.
И я использую SVN для совместного использования между моим ПК и Mac. Мои единственные реальные проблемы - когда я добавляю классы в общую базу кода в Windows, а затем обновляю mac, чтобы вытащить их из SVN. XCode не имеет возможности автоматически добавлять их в проект без скриптов, поэтому мне приходится каждый раз вытаскивать их вручную, что является болью, но это не конец света.
Все это происходит с BatteryTech, поэтому легко понять, как только вы его получите.
Ответ 5
Помимо использования C/С++ общего доступа , поэтому lib.
Если для разработки кросс-платформенных приложений, таких как игра, предлагайте использовать моно-основанную структуру, например Unity3D.
Если вы разрабатываете бизнес-приложения, для которых требуется собственный пользовательский интерфейс, и вы хотите использовать перекрестные мобильные платформы бизнес-логики, я предлагаю использовать встроенный движок Lua как бизнес-логический центр клиента.
Пользовательский интерфейс клиента по-прежнему является родным и обладает лучшими характеристиками пользовательского интерфейса. i.e Java на Android и ObjectC на iOS и т.д.
Логика разделяется с теми же сценариями Lua для всей платформы.
Таким образом, уровень Lua похож на клиентские службы (по сравнению со службами на стороне сервера).
- Андерсон Мао, 2013-03-28
Ответ 6
Хотя я не использую их сам, поскольку большая часть материала, который я пишу, не будет хорошо переноситься, я бы рекомендовал использовать что-то вроде Appcelerator или Red Foundry для создания базовых приложений, которые затем могут быть созданы изначально на обеих платформах. В этих случаях вы не пишете objective-c или java, вы используете какой-то посредник. Обратите внимание: если вы перейдете за пределы коробки, к которой они привязаны, вам нужно будет написать свой собственный код ближе к металу.