如何在Android和iOS之间共享代码

How to code sharing between Android and iOS

提问by Sonoman

I'm moving away from strict Android development and wanting to create iPhone applications. My understanding is that I can code the backend of iOS applications in C/C++ and also that I can use the NDK to include C/C++ code in Android apps. My question however is how? I've googled quite a bit and I can't find any clear and concise answers. When looking at sample code for the NDK, it seems that all the function names etc. are Android (or at least Java) specific and so I would not be able to use this C/C++ backend to develop an iPhone frontend? I'd appreciate some clarification on this issue and if at all available some code to help me out? (even just a simple Hello World that reads a string from a C/C++ file and displays it in an iOS and Android app).

我正在摆脱严格的 Android 开发，想要创建 iPhone 应用程序。我的理解是，我可以用 C/C++ 编写 iOS 应用程序的后端，也可以使用 NDK 在 Android 应用程序中包含 C/C++ 代码。然而，我的问题是如何？我在谷歌上搜索了很多，但找不到任何清晰简洁的答案。在查看 NDK 的示例代码时，似乎所有函数名称等都是 Android（或至少 Java）特定的，因此我无法使用此 C/C++ 后端来开发 iPhone 前端？我很感激关于这个问题的一些澄清，如果有一些可用的代码来帮助我？（甚至只是一个简单的 Hello World，它从 C/C++ 文件中读取字符串并将其显示在 iOS 和 Android 应用程序中）。

Thanks guys Chris

谢谢你们克里斯

采纳答案by Shaggy Frog

While the sentiment is sound (you are following the policy of Don't Repeat Yourself), it's only pragmatic if what you can share that code in an efficient manner. In this case, it's not really possible to have a "write once" approach to cross-platform development where the code for two platforms needs to be written in different languages (C/C++/Obj-C on iPhone, Java for Android).

虽然这种情绪是合理的（您遵循“不要重复自己”的政策），但只有您可以以有效的方式共享该代码的内容才是务实的。在这种情况下，真正不可能采用“一次编写”的跨平台开发方法，其中两个平台的代码需要用不同的语言编写（iPhone 上的 C/C++/Obj-C，Android 上的 Java）。

You'll be better off writing two different codebases in this case (in two different languages). Word of advice: don't write your Java code like it's C++, or your C++ code like it's Java. I worked at a company a number of years ago who had a product they "ported" from Java to C++, and they didn't write the C++ code like it was C++, and it caused all sorts of problems, not to mention being hard to read.

在这种情况下（用两种不同的语言）编写两个不同的代码库会更好。忠告：不要像 C++ 那样编写 Java 代码，也不要像 Java 那样编写 C++ 代码。几年前我在一家公司工作，他们有一个产品从 Java“移植”到 C++，他们没有像 C++ 那样编写 C++ 代码，这导致了各种各样的问题，更不用说很难了阅读。

回答by Rob Napier

Note that I almost exclusively work on "business/utility/productivity" applications; things that rely heavily on fairly standard UI elements and expect to integrate well with their platform. This answer reflects that. See Mitch Lindgren's comment to Shaggy Frog's answer for good comments for game developers, who have a completely different situation.

请注意，我几乎专门从事“业务/公用事业/生产力”应用程序；严重依赖相当标准的 UI 元素并期望与他们的平台很好地集成的东西。这个答案反映了这一点。请参阅 Mitch Lindgren 对 Shaggy Frog 的回答的评论，以获得对情况完全不同的游戏开发者的好评。

I believe @Shaggy Frog is incorrect here. If you have effective, tested code in C++, there is no reason not to share it between Android and iPhone, and I've worked on projects that do just that and it can be very successful. There are dangers that should be avoided, however.

我相信@Shaggy Frog 在这里是不正确的。如果你有有效的、经过测试的 C++ 代码，没有理由不在 Android 和 iPhone 之间共享它，而且我已经从事过这样的项目，它可以非常成功。然而，有一些危险是应该避免的。

Most critically, be careful of "lowest common denominator." Self-contained, algorithmic code, shares very well. Complex frameworks that manage threads, talk on the network, or otherwise interact with the OS are more challenging to do in a way that doesn't force you to break the paradigms of the platform and shoot for the LCD that works equally badly on all platforms. In particular, I recommend writing your networking code using the platform's frameworks. This often requires a "sandwich" approach where the top layer is platform-specific and the very bottom layer is platform-specific, and the middle is portable. This is a very good thing if designed carefully.

最重要的是，要小心“最小公分母”。自包含的算法代码，分享得很好。管理线程、在网络上交谈或以其他方式与操作系统交互的复杂框架在不强迫您打破平台范式并为在所有平台上都同样糟糕的 LCD 上进行拍摄的方式更具挑战性. 特别是，我建议您使用平台的框架编写网络代码。这通常需要一种“三明治”方法，其中顶层是特定于平台的，最底层是特定于平台的，中间是可移植的。如果精心设计，这是一件非常好的事情。

Thread management and timers should also be done using the platform's frameworks. In particular, Java uses threads heavily, while iOS typically relies on its runloop to avoid threads. When iOS does use threads, GCD is strongly preferred. Again, the solution here is to isolate the truly portable algorithms, and let platform-specific code manage how it gets called.

线程管理和计时器也应该使用平台的框架来完成。特别是，Java 大量使用线程，而 iOS 通常依赖其运行循环来避免线程。当 iOS 确实使用线程时，强烈推荐 GCD。同样，这里的解决方案是隔离真正可移植的算法，并让特定于平台的代码管理它的调用方式。

If you have a complex, existing framework that is heavily threaded and has a lot of network or UI code spread throughout it, then sharing it may be difficult, but my recommendation still would be to look for ways to refactor it rather than rewrite it.

如果您有一个复杂的现有框架，该框架具有大量线程并且散布着大量网络或 UI 代码，那么共享它可能会很困难，但我的建议仍然是寻找重构它的方法而不是重写它。

As an iOS and Mac developer who works extensively with cross-platform code shared on Linux, Windows and Android, I can say that Android is by far the most annoying of the platforms to share with (Windows used to hold this distinction, but Android blew it away). Android has had the most cases where it is not wise to share code. But there are still many opportunities for code reuse and they should be pursued.

作为一名 iOS 和 Mac 开发人员，他广泛使用在 Linux、Windows 和 Android 上共享的跨平台代码，我可以说 Android 是迄今为止最令人讨厌的共享平台（Windows 曾经保持这种区别，但 Android 吹了把它带走）。Android 有最多的案例共享代码是不明智的。但是仍然有很多代码重用的机会，应该去追求。

回答by jchristof

Writing a shared code base is really practical in this situation. There is some overhead to setting up and keeping it organized, but the major benefits are these 1) reduce the amount of code by sharing common functionality 2) Sharing bug fixes to the common code base. I'm currently aware of two routes that I'm considering for a project - use the native c/c++ (gains in speed at the expense of losing garbage collection and setting targets per processor) or use monodroid/monotouchwhich provide c# bindings for each os's platform functionality (I'm uncertain of how mature this is.)

在这种情况下，编写共享代码库非常实用。设置和保持组织有一些开销，但主要的好处是： 1) 通过共享公共功能减少代码量 2) 将错误修复共享到公共代码库。我目前知道我正在考虑用于项目的两条路线 - 使用本机 c/c++（以丢失垃圾收集和设置每个处理器的目标为代价提高速度）或使用monodroid/monotouch提供 c# 绑定每个操作系统的平台功能（我不确定这有多成熟。）

If I was writing a game using 3d I'd definitely use approach #1.

如果我使用 3d 编写游戏，我肯定会使用方法 #1。

回答by rbgrn

I posted this same answer to a similar question but I think it's relevant so...

我在一个类似的问题上发布了同样的答案，但我认为它是相关的，所以......

I use BatteryTechfor my platform-abstraction stuff and my project structure looks like this:

我将BatteryTech用于我的平台抽象内容，我的项目结构如下所示：

On my PC:

在我的电脑上：

• gamename- contains just the common code

• gamename-android- holds mostly BatteryTech's android-specific code and Android config, builders point to gamename project for common code

• gamename-win32- Just for building out to Windows, uses code from gamename project

• gamename- 只包含通用代码

• gamename-android- 主要包含 BatteryTech 的 android 特定代码和 Android 配置，构建者指向游戏名称项目以获得通用代码

• gamename-win32- 仅用于构建到 Windows，使用来自游戏名称项目的代码

On my Mac:

在我的 Mac 上：

• gamename- contains just the common code

• gamename-ios- The iPhone/iPad build, imports common code

• gamename-osx- The OSX native build. imports common code.

• gamename- 只包含通用代码

• gamename-ios- iPhone/iPad 构建，导入通用代码

• gamename-osx- OSX 本机构建。导入通用代码。

And I use SVN to share between my PC and Mac. My only real problems are when I add classes to the common codebase in Windows and then update on the mac to pull them down from SVN. XCode doesn't have a way to automatically add them to the project without scripts, so I have to pull them in manually each time, which is a pain but isn't the end of the world.

我使用 SVN 在我的 PC 和 Mac 之间共享。我唯一真正的问题是当我将类添加到 Windows 中的公共代码库，然后在 mac 上更新以将它们从 SVN 中拉下来时。XCode 没有办法在没有脚本的情况下自动将它们添加到项目中，所以我每次都必须手动拉入它们，这很痛苦，但并不是世界末日。

All of this stuff comes with BatteryTech so it's easy to figure out once you get it.

所有这些东西都随 BatteryTech 一起提供，所以一旦你得到它就很容易弄清楚。

回答by Anderson Mao

Besides using C/C++share solib.

除了使用C/C++共享所以lib。

If to develop cross-platform apps like game, suggest use mono-based framework like Unity3D.

如果要开发游戏等跨平台应用，建议使用基于单声道的框架，如Unity3D。

Else if to develop business apps which require native UI and want to share business logic code cross mobile platforms, I suggest use Luaembedded engine as client business logic center.

否则如果开发需要原生 UI 的业务应用，并希望跨移动平台共享业务逻辑代码，我建议使用Lua嵌入式引擎作为客户端业务逻辑中心。

The client UI is still native and get best UI performance. i.e Java on Android and ObjectC on iOS etc. The logic is shared with same Lua scripts for all platform. So the Lua layer is similar as client services (compare to server side services).

客户端 UI 仍然是原生的并获得最佳 UI 性能。即 Android 上的 Java 和 iOS 上的 ObjectC 等。该逻辑与所有平台的相同 Lua 脚本共享。所以 Lua 层类似于客户端服务（与服务器端服务相比）。

-- Anderson Mao, 2013-03-28

——毛安德，2013-03-28

回答by Scott

Though I don't use these myself as most of the stuff I write won't port well, I would recommend using something like Appceleratoror Red Foundryto build basic applications that can then be created natively on either platform. In these cases, you're not writing objective-c or java, you use some kind of intermediary. Note that if you move outside the box they've confined you to, you'll need to write your own code closer to the metal.

虽然我自己不使用这些，因为我编写的大多数东西都不能很好地移植，但我建议使用Appcelerator或Red Foundry 之类的东西来构建基本的应用程序，然后可以在任一平台上本地创建这些应用程序。在这些情况下，您不是在编写 Objective-c 或 java，而是使用某种中介。请注意，如果您走出他们限制您的框框，您将需要编写自己的代码，更接近金属。