这篇文章主要想谈谈最近又刮起的App移动开发跨平台之风，并着重介绍和对比一下像是Xamarin，NativeScript 、React Native和 DeviceOne 之类的东西。不会有特别深入的技术讨论，大家可以当作一篇科普类的文章来看。
故事的开始
“一次编码，处处运行” 永远是程序员们的理想乡。二十年前 Java 正是举着这面大旗登场，击败了众多竞争对手。但是时至今日，事实已经证明了 Java 笨重的体型和缓慢的发展显然已经很难再抓住这个时代快速跃动的脚步。
在新时代的移动大潮下，一个应用想要取胜，完美的使用体验可以说必不可少。使用 native 的方式固然对提升用户体验很有帮助，但是移动的现状是必须针对不同平台 (至少是 iOS 和 Android) 进行开发。这对于开发来说妥妥的是隐患和额外的负担：
我们不仅需要在不同的项目间努力用不同的语言实现同样代码的同步，还要承担由此带来的后续维护任务。如果仅只限制在 iOS 和 Android 的话还行，但是如果还要继续向 Windows Phone 等平台拓展的话，所需要付出的代价和工数将几何级增长，这显然是难以接受的。
于是，一个其实一直断断续续被提及但是从没有占据过统治地位的概念又一次走进了移动开发者们的视野，那就是跨平台开发。
本地 HTML 和 JavaScript
因为每个平台都有浏览器，也都有 WebView 控件，所以我们可以使用 HTML，CSS 和 JavaScript 来将 web 的内容和体验搬到本地。通过这样做我们可以将逻辑和 UI 渲染部分都统一，以减少开发和维护成本。
这种方式开发的 app 一般被称为 Hybrid app，像 PhoneGap 或者 Cordova 这样的解决方案就是典型的应用。除了使用前端开发的一套技巧来构建页面和交互以外，一般这类框架还会提供一些访问设备的接口，比如相机和 GPS 等。
虽然使用全网页的开发策略和环境可以带来代码维护的便利，但是这种方式是有致命弱点的，那就是缓慢的渲染速度和难以驾驭的动画效果。这两者对于用户体验是致命而且难以接受的。
随着三年前 Facebook 使用 native 代码重新构建 Facebook 的手机 app 这一标志性事件的发生，曾经一度占领半壁江山的网页套壳的 app 的发展也日渐式微。
特别在现在对于用户体验的追求几近苛刻的现在，呆板的动画效果和生硬的交互体验已经完全无法满足人民群众对高质量 app 的心理预期了。
跨平台之心不死的我们该怎么办
想要解决用户体验的问题，基本还是需要回到 native 来进行开发，但是这种行为必然会与平台绑定。世界上总是有聪明人的，并且他们总会利用看起来更加聪明但是实际上却很笨的电脑来做那些很笨的事情 (恰得其所)。其中一件事情就是自动将某个平台的代码转换到另外的平台上去。
有一家英国的小公司正在做这样的事情，MyAppConverter 想做的事情就是把 iOS 的代码自动转成 Java 的。但是很可惜，如果你尝试过的话，就知道他们的产品暂时还处于无法实用的状态。
在这条路的另一个分叉上有一家公司走得更远，它叫做 Apportable。他们在游戏的转换上已经取得了很大的成果，像是 Kingdom Rush 或者 Mega Run 这样的大作都使用了这家的服务将游戏从 iOS 转换到 Android，并且非常成功。
可以毫不夸张地说，Apportable 是除开直接使用像 Unity 或者 Cocos2d-x 以外的另一套诱人的游戏跨平台解决方案。基本上你可以使用 Objective-C 或者 Swift 来在熟悉的平台上开发，而不必去触碰像是 C++ 这样的怪兽 (虽然其实在游戏开发中也不会碰到很难的 C++)。
但是好消息终结于游戏开发了，因为游戏在不同平台上体验不会差别很大，也很少用到不同平台的不同特性，所以处理起来相对容易。当我们想开发一个非游戏的 app 时，事情就要复杂得多。虽然 Apportable有一个计划让 app 转换也能可行，但是估计还需要一段时间我们才能看到它的推出。
新的希望---Xamarin
其实跨平台开发最大的问题还是针对不同的平台 UI 和体验的不同。如果忽视掉这个最困难的问题，只是共用逻辑部分的代码的话，问题一下子就简单不少。
十多年前，当 .NET 刚刚被公布，大家对新时代的开发充满期待的同时，一群喜欢捣鼓的 Hacker 就在盘算要如何将 .NET 和 C# 搬到 Linux 上去。而这就是 Mono的起源。
Mono 通过在其他平台上实现和 Windows 平台下功能相同的 Common Language Runtime 来运行 .NET 中间代码。现在 Mono 社区已经足够强大，并且不仅仅支持 Linux 平台，对移动设备也同样支持。Mono 背后的支撑企业 Xamarin 也顺理成章并适时地推出了一整套的移动跨平台解决方案。
Xamarin 的思路相对简单，那就是使用 C# 来完成所有平台共用的，和平台无关的 app 逻辑部分；然后由于各个平台的 UI 和交互不同，使用预先由 Xamarin 封装好的 C# API 来访问和操控 native 的控件，进行分别针对不同平台的 UI 开发。
虽然只有逻辑部分实现了真正的跨平台，而表现层已然需要分别开发，但这确实也是一种在完整照顾用户体验的基础上的好方式 -- 至少开发语言得到了统一。因为 Xamarin 解决方案中的纯 C# 环境和有深厚的 .NET 技术背景做支撑，这个项目现在也受到了微软的支持和重视。
不过存在的致命问题是针对某个特定平台你所能使用的 API 是由 Xamarin 所决定的。也就是说一旦 iOS 或者 Android 平台推出了新的 SDK，加入了新的功能，你必须要等 Xamarin 的工程师先进行封装，然后才能在自己的项目中使用。
这种延迟往往可能是致命的，因为现在 AppStore 对于新功能的首页推荐往往只会有新系统上线后的一两周，错过这段时间的话，可能你的 app 就再无翻身之日。
而且如果你想使用一些第三方框架的话，将不得不自己动手将它们打包成二进制，并且写 binding 为它们提供 C# 的封装，除非已经有别人帮你做过这件事情了。
另外，因为 UI 部分还是各自为战，所以不同的代码库依然存在于项目之中，这对工作量的减少的帮助有限，并且之后的维护中还是存在无法同步和版本差异的隐患。但是总体来说，Xamarin 是一个很不错的解决跨平台开发的思路了。(如果抛开价格因素的话)
React Native
Facebook 几个月前公布了 React Native，而今天这个项目终于在万众期待下发布了。
React Native 在一定程度上和 NativeScript 的概念类似：都是使用 JavaScript 和 native UI 来实现 app (所以说 JavaScript 真是有一桶浆糊的趋势..如果你现在还不会写几句 JavaScript 的话，建议尽早学一学)。但是它们的出发点略有不同，React Native 在首页上就写明了，使用这个库可以：
learn once, write anywhere
而并不是 "run anywhere"。所以说 React Native 想要达成的目标其实并不是一个跨平台 app 开发方案，而是让你能够使用相似的方法和同样的语言来在不同平台进行开发的工具。
另外，React Native 的主要工作是构建响应式的 View，其长处在于根据应用所处的状态来决定 View 的表现状态。而对于其他一些系统平台的 API 来说，就显得比较无力。而正是由于这些要素，使得 React Native 确实不是一个跨平台的好选择。
那为什么我们还要在这篇以 “跨平台” 为主题的文章里谈及 React Native 呢？
因为虽然 Facebook 不是以跨平台为出发点，但是却不可能阻止工程师想要这么来使用它。从原理上来说，React Native 继承了 React.js 的虚拟 DOM 的思想，只不过这次变成了虚拟 View。事实上这个框架提供了一组 native 实现的 view (在 iOS 平台上是 RCT 开头的一系列类)。
我们在写 JavaScript (更准确地说，对于 React Native，我们写的是带有 XML 的 JavaScript：JSX) 时，通过将虚拟 View 添加并绑定到注册的模块中，在 native 侧用 JavaScript 运行环境 (对于 iOS 来说也就是 JavaScriptCore) 执行编译并注入好的 JavaScript 代码，获取其对 UI 的调用，将其截取并桥接到 native 代码中进行对应部件的渲染。而在布局方面，依然是通过 CSS 来实现的。
这里整个过程和思路与 NativeScript 有相似之处，但是在与 native 桥接的时候采取的策略完全相反。React Native 是将 native 侧作为渲染的后端，去提供统一的 JavaScript 侧所需要的 View 的实体。NativeScript 基本算反其道行之，是在 JavaScript 里写分开的中间层来分别对应不同平台。
对于非 View 的处理，对于 iOS，React Native 提供了 RCTBridgeModule 协议，我们可以通过在 native 侧实现这个协议来提供 JavaScript 中的访问可能。另外，回调和事件发送等也可以通过相应的 native 代码来完成。
总结来说，如果想要把 React Native 作为一个跨平台方案来看的话 (实际上也并不应当如此)，那么单靠 JavaScript 一侧是难以完成的，因为一款有意义的 app 不太可能完全不借助平台 API 的力量。
但是毕竟这个项目背后是 Facebook，如果 Facebook 想要通过自己的影响力自立一派的话，必定会通过不断改进和工具链的完善，将 app 开发的风向引导至自己旗下。
对于原来就使用 React.js 的开发者来说，这个框架降低了他们进入 app 开发的门槛。但是对于已经在做 native app 开发的人来说，是否值得和需要投入精力进行学习，还需要观察 Facebook 接下来动作。
不过现在 React Native 的正式发布才过去了不到 24 小时，我想我们有的是时间来思考和检阅这样一个框架。
APICloud在官网上宣传轻松6个步骤就可以完成App制作和开发。
第一步：选择App开发模式
APICloud平台为不同需求的人提供了不同的产品，如果你要从零开始制作App，那么选用Deep Engine产品，用HTML5等标准Web语言去开发和制作App，iOS和Android两个系统是同时生成的。
如果你已经有现成的App，希望加速开发和制作的周期，或是降低升级的难度和时间，那么选用SuperWebview产品。在已有的App中嵌入SuperWebview，就可以使用Web语言去继续开发和制作了，这样降低成本，缩短周期。
第二步：编写App界面
Sublime Text、Eclipse和Webstorm，耳熟能详的App开发工具都在APICloud上集成，你也可以选择使用APICloud Studio开发工具。使用你熟悉的HTML工具，再加上APICloud的插件，以2-3倍的效率进行App制作。
第三步：App功能实现
APICloud聚合了几乎所有国内主流的云服务模块，如支付、社交分享、视频直播、IM、语音会议等。这些模块都在聚合API中，你可以一站式选用App制作中所需的所有功能模块，一键就可以集成，快速高效。
第四步：App的服务端开发
你可以选择自己的本地服务器进行相连，也可以试用由APICloud的服务器端产品——数据云。数据云能够帮助你减少70%服务器端编码工作量，支持基于Docker技术的私有云环境。并且提供数据存储服务，支持在线设计NoSQL数据表，动态生成RESTFul API。
第五步：在线生成App安装包
做完以上四步骤后，其实App制作的过程已经结束了。下面就是将这一套代码编译生成iOS和Android两套安装包，在这里，APICloud不仅提供真机调试功能，可以使你看到App最终的效果，还针对12个常用的Android市场，还提供一键生成渠道包服务，帮助你轻松上线到Android应用市场。
第六步：App上线运营管理
APICloud不光为你App制作提供服务，更帮助你在App上线后进行运营和管理。APICloud运营云产品涵盖推送、云修复、大数据统计分析等App运营必备功能。版本更新更能实现应用内增量更新，无需重新提交App。
在这里要单独讲解一下云修复和大数据统计分析两个功能，通过云修复可实现App内快速回滚，让App拥有自我修复能力在App内部快速回滚的过程中，支持断点续传，全面保障App自我修复的完整性。
而大数据统计分析的功能使得App的新增及活跃用户数据，几分钟即可摆在你的眼前，让你成为App的运营专家。同时还支持对App进行自定义事件统计,帮助你去了解用户在App中的特定行为数据、支持版本、终端分布及错误报告。
总结
当然还有一些其他方案，比如 Titanium 等。现在使用跨平台方案开发 app 的案例并不算很多，但是无论在项目管理还是维护上，跨平台始终是一种诱惑。它们都解决了一些 Hybrid app 的遗留问题，但是它们又都有一些非 native app 的普遍面临的阴影。
谁能找到一个好的方式来解决像是自定义 UI，API 扩展性以及 app 尺寸这样的问题，谁就将能在这个市场中取得领先或者胜利，从而引导之后的开发潮流。
但是谁又知道最后谁能取胜呢？也有可能大家在跨平台的道路上再一次全体失败。伺机而动也许是现在开发者们很好的选择，不过我的建议是提前学点儿 JavaScript 总是不会出错的。
更多app资讯，请关注www.apicloud.com
提交app定制需求，了解报价和周期：