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

发布于 2024-09-18 08:37:36 字数 349 浏览 5 评论 0原文

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

谢谢大家 克里斯

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).

Thanks guys
Chris

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

娜些时光,永不杰束 2024-09-25 08:37:36

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

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

最重要的是,要小心“最小公分母”。独立的算法代码,共享性很好。管理线程、在网络上通信或以其他方式与操作系统交互的复杂框架更具挑战性,并且不会迫使您打破平台的范例并争取在所有平台上都表现同样糟糕的 LCD 。特别是,我建议使用该平台的框架编写网络代码。这通常需要“三明治”方法,其中顶层是特定于平台的,最底层是特定于平台的,中间是可移植的。如果精心设计的话,这是一件非常好的事情。

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

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

作为一名广泛使用在 Linux、Windows 和 Android 上共享的跨平台代码的 iOS 和 Mac 开发人员,我可以说 Android 是迄今为止最令人讨厌的共享平台(Windows 曾经保持着这种区别,但 Android 却失败了)把它带走)。 Android 在大多数情况下共享代码是不明智的。但代码重用的机会仍然很多,应该加以利用。

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.

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.

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.

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.

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.

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.

初雪 2024-09-25 08:37:36

虽然这种情绪是合理的(您遵循“不要重复自己”的政策),但只有当您能够以有效的方式共享该代码时,这才是务实的。在这种情况下,实际上不可能采用“一次编写”的跨平台开发方法,因为两个平台的代码需要用不同的语言编写(iPhone 上的 C/C++/Obj-C,Android 上的 Java)。

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

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).

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.

春花秋月 2024-09-25 08:37:36

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

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

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/monotouch which provide c# bindings for each os's platform functionality (I'm uncertain of how mature this is.)

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

一腔孤↑勇 2024-09-25 08:37:36

我对类似的问题发布了相同的答案,但我认为它是相关的,所以...

我使用 BatteryTech 作为我的平台抽象内容和我的项目结构如下所示:

在我的电脑上

  • 游戏名称 - 仅包含通用代码

  • gamename-android - 主要包含 BatteryTech 的 android 特定代码和 Android 配置,构建者指向通用代码的 gamename 项目

  • gamename-win32 - 仅用于构建到 Windows,使用 gamename 中的代码项目

在我的 Mac 上:

  • gamename - 仅包含通用代码

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

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

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

所有这些东西都随 BatteryTech 一起提供,因此一旦您获得它就很容易弄清楚。

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

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

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

On my 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.

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.

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

俯瞰星空 2024-09-25 08:37:36

除了使用C/C++共享so库。

如果要开发游戏等跨平台应用程序,建议使用基于单一的框架,如Unity3D

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

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

-- 毛泽东,2013-03-28

Besides using C/C++ share so lib.

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

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

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).

-- Anderson Mao, 2013-03-28

带上头具痛哭 2024-09-25 08:37:36

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

Though I don't use these myself as most of the stuff I write won't port well, I would recommend using something like Appcelerator or Red Foundry to 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文