移动端跨平台开发技术
2016-05-18 16:26:58 0 举报AI智能生成
移动端跨平台开发技术
作者其他创作
大纲/内容
Web流
也被称为 Hybrid 技术，它基于 Web 相关技术来实现界面及功能
PhoneGap/Cordova+ionic/DCloud+html5+mui
问题：性能慢
1. 早期浏览器实现比较差，没有进行优化
IOS很流畅；安卓4.4后用Chrome来渲染
2. CSS 过于复杂，计算起来更耗时
简化CSS(famo.us)
3. DOM 提供的接口太有限，使得难以进行优化
不用HTML/CSS，自己画界面，谨慎使用！如：React Canvas, WebGL
不是“DOM慢”
Web最大优势：显示丰富的图文排版，在很多 Native 应用中是不可避免要嵌 Web 的
代码转换流
将某个语言转成 Objective-C、Java 或 C#，然后使用不同平台下的官方工具来开发
j2objc: Java转换为Objective-C
MyAppConverter: Objective-C转成Java，收费
Mono: Sharpen: Java转成C#， JUniversal，开发者少
Haxe: OpenFl+HaxeUI, 跨平台游戏开发，不稳定
XMLVM: 字节码->XML中间格式，通过 XSL -> C、Objective-C、JavaScript、C#、Python 和 Java，生成的代码可能不可读！
小结：虽然代码转换这种方式风险小，但我觉得对于很多小 APP 来说共享不了多少代码，因为这类应用大多数围绕 UI 来开发的，大部分代码都和 UI 耦合，所以公共部分不多。
在目前的所有具体方案中，只有 j2objc 可以尝试，其它都不成熟。
编译流
将某个语言编译为二进制文件，生成动态库或打包成 apk/ipa/xap 文件
优点
可以重用一些实现很复杂的代码，比如之前用 C++ 实现的游戏引擎，重写一遍成本太高
编译后的代码反编译困难
或许性能会好些（具体要看实现）
缺点
如果这个工具本身有 Bug 或性能问题，定位和修改成本会很高
编译后体积不小，尤其是如果要支持 ARMv8 和 x86 的话
C++类
1. 只用 C++ 实现非界面部分，这是官方比较推崇的方案，目前有很多应用是这么做的，比如 Mailbox 和 Microsoft Office。
2. 使用 2D 图形库来自己绘制界面，这种做法在桌面比较常见，因为很多界面都有个性化需求，但在移动端用得还不多。
3. 使用 OpenGL 来绘制界面，常见于游戏中。
可参考： Dropbox 开源的 libmx3 项目，它还内嵌了 json 和 sqlite 库，并通过调用系统库来实现对简单 HTTP、EventLoop 及创建线程的支持。
用C++实现界面
iOS 和 Windows Phone：可以分别使用 C++ 的超集 Objective-C++ 和 C++/CX
安卓
1) 通过 JNI 调用系统提供的 Java 方法， 代码冗余
2) 自己画 UI: JUCE/QT，安卓5下很悲剧
3) 使用 OpenGL 来绘制界面，工作量极大
Xamarin
使用 C# 来开发 Android 及 iOS 应用，UI: Xamarin.Forms
优点
开发 app 所需的基本功能全部都有
有商业支持，而且这个项目对 Windows Phone 很有利，微软会大力支持
缺点
如果深入后会发现功能缺失，尤其是定制 UI，因为未开源使得遇到问题时不知道如何修复
Xamarin 本身有些 Bug
相关资源太少，没有原生平台那么多第三方库
Xamarin studio 比起 Xcode 和 Android Studio 在功能上还有很大差距
将Objective-C编译为Windows phone
RoboVM
将 Java 字节码编译为可在 iOS 下运行的机器码
RoboVM 和 Xamarin 很像，但 RoboVM 风险会小些，因为它只需要把 iOS 支持好就行了，对优先开发 Android 版本的团队挺适用，但目前官方文档太少了，而且不清楚 RoboVM 在 iOS 上的性能和稳定性怎样。
Swift - Apportable/Silver
成功案例均为游戏
相关工具不成熟
Go
最近几年很火的后端服务开发语言，它语法简单且高性能，目前在国内有不少用户
Xojo
使用VisualBasic
小结：从目前分析的情况看，C++ 是比较稳妥的选择，但它对团队成员有要求，如果大家都没写过 C++，可以试试 Xamrin 或 RoboVM。
虚拟机流
通过将某个语言的虚拟机移植到不同平台上来运行
问题
性能损耗
虚拟机本身也会占不小的体积
java系
J2ME
Titanium/Hyperloop
Titanium: 和 PhoneGap 最大的区别是：它的界面没有使用 HTML/CSS，而是自己设计了一套基于 XML 的 UI 框架 Alloy
学习成本，资料少
Titanium: 配套跨平台API
1. API 有限，因为这是由 Titanium 提供的，它肯定会比官方 API 少且有延迟，Titanium 是肯定跟不过来的
2. 相关资料及社区有限，比起 Android/iOS 差远了，遇到问题都不知道去哪找答案
3. 缺乏第三方库，第三方库肯定不会专门为 Titanium 提供一个版本，所以不管用什么都得自己封装
Hyperloop: Titanium的下一代解决方案
可以将 JavaScript 编译为原生代码，这样的好处是调用原生 API 会比较方便
这个方案和之前的说的 Xamarin 很相似，基本上等于将 Objective-C 翻译为 JavaScript 后的样子，意味着你可以对着 Apple 的官方文档开发，不过如果发现某些 Objective-C 语法发现不知道对应的 JavaScript 怎么写时就悲剧了，只有自己摸索。
但从 Github 上的提交历史看，这项目都快开发两年了，但至今仍然是试验阶段，从更新频率来看，最近一年只提交了 8 次，所以恐怕是要弃坑了，非常不靠谱。
因此我认为 Titanium/Hyperloop 都非常不靠谱，不推荐使用。
NativeScript
用工具来自动生成 wrapper API，和系统 API 保持一致
从底层实现上看，NativeScript 在 Android 下内嵌了 V8，而在 iOS 下内嵌了自己编译的 JavaScriptCore
能调用更底层的 API，也避免了不同操作系统版本下 JS 引擎不一致带来的问题
后果是生成文件的体积变大和在 iOS 下性能不如 WKWebView。
使用体验很不错，做到了一键编译运行，而且还有 MVVM 的支持，能进行数据双向绑定
NativeScript 和 Titanium 都有个很大的缺点，那就是排它性太强，如果你要用这两个方案，就得完整基于它们进行开发，不能在某些 View 下进行尝试，也不支持直接嵌入第三方 View，有没有方案能很好地解决这两个问题？有，那就是 React Native。
React Native
在不同平台下使用平台自带的 UI 组件
主要是借鉴了 CSS 中的 Flexbox 写法，还有 navigator、XMLHttpRequest 等几个简单的 API，React Native 和 HTML 5 完全不是一回事
用到了 Flow，它支持定义函数参数的类型，极大提升了代码可读性，另外还能使用 ES6 的语法，比如 class 关键字等
用XML+CSS写界面
语言：Javascript
已有组件仓库，gitHub上有500+仓库，不需要写原生代码
游戏引擎中的脚本
Ejecta
它实现了 Canvas 及 Audio 的 API，可以开发简单的游戏，但目前还不支持 Android
CocoonJS
实现了 WebGL 的 API，可以运行 Three.js 写的游戏
Unreal Engine 3
可以使用 UnrealScript 来开发，这个语言的语法很像 Java
Cocos2d-js
Cocos2d-x 的 JavaScript binding，它内部使用的 JS 引擎是 SpiderMonkey
Unity 3D
可以使用 C# 或 JavaScript 开发游戏逻辑
Corona
使用 Lua 来开发
Adobe AIR
Dart
职业：暂无
0 条评论
下一页
为你推荐
查看更多
