聊聊移动端跨平台开发的各种技术

除了有 Java 转成 Objective-C，还有 Objective-C 转成 Java 的方案，那就是 MyAppConverter，比起前面的 j2objc，这个工具更有野心，它还打算将 UI 部分也包含进来，从它已转换的列表中可以看到还有 UIKit、CoreGraphics 等组件，使得有些应用可以不改代码就能转成功，不过这点我并不看好，对于大部分应用来说并不现实。

由于目前是收费项目，我没有尝试过，对技术细节也不了解，所以这里不做评价。

将 Java 转成 C#

Mono 提供了一个将 Java 代码转成 C# 的工具 Sharpen，不过似乎用的人不多，Star 才 118，所以看起来不靠谱。

还有 JUniversal 这个工具可以将 Java 转成 C#，但目前它并没有发布公开版本，所以具体情况还待了解，它的一个特色是自带了简单的跨平台库，里面包括文件处理、JSON、HTTP、OAuth 组件，可以基于它来开发可复用的业务逻辑。

比起转成 Objective-C 和 Java 的工具，转成 C# 的这两个工具看起来都非常不成熟，估计是用 Windows Phone 的人少。

将 Haxe 转成其它语言

说到源码转换就不得不提 Haxe 这个奇特的语言，它没有自己的虚拟机或可执行文件编译器，所以只能通过转成其它语言来运行，目前支持转成 Neko（字节码）、Javascript、Actionscript 3、PHP、C++、Java、C# 和 Python，尽管有人实现了转成 Swift 的支持，但还是非官方的，所以要想支持 iOS 开发目前只能通过 Adobe AIR 来运行。

在游戏开发方面做得不错，有个跨平台的游戏引擎 OpenFL 的，最终可以使用 HTML5 Canvas、OpenGL 或 Flash 来进行绘制，OpenFL 的开发体验做得相当不错，同一行代码不需要修改就能编译出不同平台下的可执行文件，因为是通过转成 C++ 方式进行编译的，所以在性能和反编译方面都有优势，可惜目前似乎并不够稳定，不然可以成为 Cocos2d-x 的有利竞品。

在 OpenFL 基础上还有个跨平台的 UI 组件 HaxeUI，但界面风格我觉得特别丑，也就只能在游戏中用了。

所以目前来看 Haxe 做跨平台游戏开发或许可行，但 APP 开发就别指望了，而基于它来共用代码实在就更不靠谱了，因为熟悉它的开发者极少，反而增加成本。

XMLVM

除了前面提到的源码到源码的转换，还有 XMLVM 这种与众不同的方式，它首先将字节码转成一种基于 XML 的中间格式，然后再通过 XSL 来生成不同语言，目前支持生成 C、Objective-C、JavaScript、C#、Python 和 Java。

虽然基于一个中间字节码可以方便支持多语言，然而它也导致生成代码不可读，因为很多语言中的语法糖会在字节码中被抹掉，这是不可逆的，以下是一个简单示例生成的 Objective-C 代码，看起来就像汇编：

XMLVM_ENTER_METHOD("org.xmlvm.tutorial.ios.helloworld.portrait.HelloWorld", "didFinishLaunchingWithOptions", "?")XMLVMElem _r0;XMLVMElem _r1;XMLVMElem _r2;XMLVMElem _r3;XMLVMElem _r4;XMLVMElem _r5;XMLVMElem _r6;XMLVMElem _r7;_r5.o = me;_r6.o = n1;_r7.o = n2;_r4.i = 0;_r0.o = org_xmlvm_iphone_UIScreen_mainScreen__();XMLVM_CHECK_NPE(0)_r0.o = org_xmlvm_iphone_UIScreen_getApplicationFrame__(_r0.o);_r1.o = __NEW_org_xmlvm_iphone_UIWindow();XMLVM_CHECK_NPE(1)...

在我看来这个方案相当不靠谱，万一生成的代码有问题基本没法修改，也没法调试代码，所以不推荐。

小结

虽然代码转换这种方式风险小，但我觉得对于很多小 APP 来说共享不了多少代码，因为这类应用大多数围绕 UI 来开发的，大部分代码都和 UI 耦合，所以公共部分不多。

在目前的所有具体方案中，只有 j2objc 可以尝试，其它都不成熟。

编译流

编译流比前面的代码转换更进一步，它直接将某个语言编译为普通平台下的二进制文件，这种做法有明显的优缺点：

• 优点
  • 可以重用一些实现很复杂的代码，比如之前用 C++ 实现的游戏引擎，重写一遍成本太高
  • 编译后的代码反编译困难
  • 或许性能会好些（具体要看实现）
• 缺点
  • 如果这个工具本身有 Bug 或性能问题，定位和修改成本会很高
  • 编译后体积不小，尤其是如果要支持 ARMv8 和 x86 的话

接下来我们通过区分不同语言来介绍这个流派下的各种方案。

C++ 类

C++ 是最常见的选择，因为目前 Android、iOS 和 Windows Phone 都提供了 C++ 开发的支持，它通常有三种做法：

• 只用 C++ 实现非界面部分，这是官方比较推崇的方案，目前有很多应用是这么做的，比如 Mailbox 和 Microsoft Office。
• 使用 2D 图形库来自己绘制界面，这种做法在桌面比较常见，因为很多界面都有个性化需求，但在移动端用得还不多。
• 使用 OpenGL 来绘制界面，常见于游戏中。

使用 C++ 实现非界面部分比较常见，所以这里就不重复介绍了，除了能提升性能和共用代码，还有人使用这种方式来隐藏一些关键代码（比如密钥），如果你不知道如何构建这样的跨平台项目，可以参考 Dropbox 开源的 libmx3 项目，它还内嵌了 json 和 sqlite 库，并通过调用系统库来实现对简单 HTTP、EventLoop 及创建线程的支持。

而如果要用 C++ 实现界面部分，在 iOS 和 Windows Phone 下可以分别使用 C++ 的超集 Objective-C++ 和 C++/CX，所以还比较容易，但在 Android 下问题就比较麻烦了，主要原因是 Android 的界面绝大部分是 Java 实现的，所以用 C++ 开发界面最大的挑战是如何支持 Android，这有两种做法：通过 JNI 调用系统提供的 Java 方法或者自己画 UI。

第一种做法虽然可行，但代码太冗余了比如一个简单的函数调用需要写那么多代码：

JNIEnv* env;jclass testClass = (*env)->FindClass(env, "com/your/package/name/Test"); 
// get ClassjmethodID constructor = (*env)->GetMethodID(env, cls, "", "()V");jobject testObject = (*env)->NewObject(env, testClass, constructor);methodID callFromCpp = (*env)->GetMethodID(env, testClass, "callFromCpp", "()V");
 //get methodid(*env)->CallVoidMethod(env, testObject, callFromCpp);

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!