谈谈跨平台APP开发难点在哪里？

在做客户端开发的公司都会面临一个巨大的问题，跨平台app开发对于目前上市面上的移动设备来说。Android、iOS、WindowsPhone、BlackBattery等等移动设备系统，让我们在开发适配上都很头痛。那么我们平时工作开发中为什么不选择一些跨平台的开发手段呢？

这里，我说一下我的总结和思考，基于WebView的跨平台解决方案相信大家已经很熟悉了，而使用Web开发对于一个Web开发工程师也是一个轻而一举的事情。HTML5方案的主要不足则在于功能和性能方面，这主要是因为html5应用的能力严重依赖于系统自带的Web引擎：iOS的UIWebview、Android的Webview等，此类组件的Html5能力相比Safari for iOS、Chrome for Android都要差一截。而且，对于原生系统的新能优化，如垃圾回收机制、ListView的复用机制等等，系统级别的优化，对于使用WebView来实现的逻辑，往往很难做到。另外在Android平台上，由于系统碎片化比较严重，不同Android版本的Webview的HTML5能力也有较大差异，导致相应的HTML5应用一致性难以保证。在Web开发中，我们总需要将变化的数据实时反应到UI上，这时就需要对DOM进行操作。而复杂或频繁的DOM操作通常是性能瓶颈产生的原因（如何进行高性能的复杂DOM操作通常是衡量一个前端开发人员技能的重要指标）。跨平台app开发难题在于，功能基本实现不是完美实现。同一套代码要兼顾不同平台，很多实现就变成折中实现了，原本一些很优秀的平台特性为了兼顾另一个平台用不了。Facebook之前还打算用html5来进行移动开发，开发了半年发现坑太多了，还是转成ios的native开发。Fackbook准备退出的React Native框架号称是能够良好的解决移动端跨平台app开发的难题，现在还没有开源，我们可以拭目以待。

Hybrid开发混合App

就是混合开发的App。Andorid+Html5 or IOS + Html5。理论上来说，混合开发的App算不上跨平台开发(我们可以简单的认为，就是使用原生的开发)。那么问题是，既然两者都有好处，那么我们就将一些体验、操作、权限要求不高的页面，使用Web来开发。其他的地方，我们还是使用原生的SDK进行研发。（转了一个大圈，完全没有跨平台，发现然并卵）

成本分析

当然，是否使用一些开源的跨平台框架，制作跨平台app开发程序，还取决于我们的公司业务范围和自己公司的技术人才积累。下面，笔者简单的总结了一下又如下几点原因，让大家在选择方向与平台的时候做一个良好的抉择。

Hybrid 技术

这类技术，使用 HTML/CSS/JavaScript 等前端技术来构建 App。利用 JSBridge 获取部分访问原生 API 的能力。更有代表性的是 PhoneGap，它是 Adobe 收购一家开源创业公司后推出的平台。这个链接有 PhoneGap 的一些历史信息。

这类平台的目标是保持大部分代码跨平台共用，涉及到平台不共用的 API （比如 GPS 接口，iOS 和 Android 肯定是不一样的），则由 PhoneGap 平台通过 JSBridge 提供。除此之外，还有一些明显的优点：

•       开发效率较高：使用 HTML/CSS/JavaScript 构建界面的效率要比原生 App 速度快很多。而且前端开发有一堆现成的框架和开源库可以直接使用。

•       即时更新：有 Bug 可以快速更新，不需要发布新 App，只需要更新服务器上更新相关的 HTML/CSS/JavaScript 即可。可以绕过 AppStore 的上架认证时间。

•       开发门槛低：对于前端开发工程师，可以快速转岗，开发出可用的 App，不需要对 iOS 平台和 Android 平台有太深入的了解。

这类平台的硬伤是：

•       单线程：JavaScript 在 WebView 里执行时是单线程的。对系统并发能力有较大的影响。

•       性能低：大概只能达到原生 App 70% 的流畅度。

这篇文章对几个热门的 Hybrid 平台进行了对比和介绍。

为了克服 Hybrid 的缺点，目前工程应用上典型的做法是，以原生 App 为主，把易变的逻辑，以及界面，不涉及性能瓶颈的部分使用基于 WebView 的 Hybrid 技术来开发。

准原生平台

为了解决 Hybrid 的问题，一些其他的方案逐步流行起来，更火的要算 React-Native，它是 Facebook 基于其前端框架 React 之上构建的跨平台 App 开发构架。

这类平台的特点是，只使用 JavaScript 来构建界面，但实际上构建出来的所有界面都是系统原生控件。这是和 Hybrid 平台更大的区别。在 Hybrid 平台，一个按钮就是 HTML 构建出来的，但在 React-Native 平台，一个按钮是在各自的平台 (Android/iOS) 上以原生控件的形式渲染出来的。

这类平台更大的优势是：

•       跨平台app开发界面及业务逻辑：以前端工程师熟悉的构架和技术，以一致的方式构建界面和业务逻辑。

•       即时更新：可以把业务逻辑放在 JavaScript 里，这样就可以直接在线更新功能。

•       性能较高：比 Hybrid 性能高，大概能达到原生 App 90% 的流畅度。

•       开发效率较高：可以使用前端技术快速构建界面。比如，熟悉 React 框架的人，可以无障碍地在 React-Native 下构建界面和业务逻辑。

这类平台和 Hybrid 相比，跟原生平台靠得更近一些，更多地依赖原生平台的一些知识。比如，很多机制，其实还是要分 iOS 平台和 Android 平台的。即无法做到真正的跨平台开发，在利用 React-Native 这类构架时，还是需要对目标平台有较深入的理解。除了 React-Native 之外，比较著名的还有 Weex 这是 alibaba 出品的一个构架，它是基于更近火热的前端构架 Vue.js 的。另外一个是 NativeScript，这是基于老牌的前端构架 Angular之上构建的。

大家注意到，这些热门平台都是基于一个热门的前端构架来构建的。从这一点也可以看到这种类型的构架的目标，就是让前端开发人员可以在其原有知识体系里，快速开发 App ，并且使用自己熟悉的语言 JavaScript 来处理业务逻辑。至于核心的代码以及性能相关的代码，还是需要使用原生编程语言 (OC for iOS, Java for Android) 来编写，不同的平台更终向上层提供一致接口。这样，上面界面部分代码，甚至一些逻辑代码就可以跨平台共用了。

原理上，JavaScript 怎么样和原生平台交互呢？

JavaScript 是脚本语言，可以在运行时解释并执行。这类平台上写出来的 JavaScript 代码更终是由原生平台里面的 JavaScript 引擎来负责执行的。那么 JavaScript 如何调用原生代码呢？答案是利用语言的元编程能力，OC 和 Java 都具备一定的元编程能力，这样 JavaScript 只要知道原生平台的类名称，函数名称，就可以调用到原生平台的这个函数了。

Hybrid 技术的愿景是真正达到一次开发，跨平台运行，但其性能是其更大的瓶颈。准原生平台的目标是让前端开发人员，基于其熟悉的前端框架，快速开发 App 的界面和业务逻辑，且其性能和原生 App 很接近。当使用准原生平台开发 App 时，除非你是全栈工程师，或者大体了解 iOS/Android 平台的一些开发知识，否则很大概率需要 iOS/Android 原生平台的开发人员配合。

以下几个场景可以考虑使用 React-Native 之类的准原生架构来开发：

•       熟悉前端技术构架：比如熟悉 React ，则可以考虑使用 React-Native 来进行开发。如果熟悉 Vue.js ，可以考虑选择 Weex 来进行开发。

•       对开发效率有较高的要求：特别是那些互联网创业公司，如果刚好又是个全栈工程师，可以考虑用这种技术来来提高整体开发效率，有可能一个人把 iOS/Android App 全包圆了。

•       应用非常频繁地更新：不管是修复严重 Bug 的 HotFix ，还是业务场景快速变化，我们在等待 AppStore 审核的时候，感觉是度日如年。如果这个痛点让你痛不欲生，不仿考虑一下准原生平台方案。

结束语：反过来，如果你对前端开发和构架不熟，切换到任何类型的跨平台技术方案上来，成本都将是巨大的。从头学习和适应全新的开发模式，虽然更后可能提高了效率，但学习时间成本可能会是不可承受这重。至少短期来看，性价比不高。

以上属于个人观点，仅供参考！