编写一次，随处部署(WODE) 在过去的十年中，许多开发框架的承诺是什么, 谁的目标是减轻编写多个本机应用程序的痛苦. 由于高昂的启动成本，决定走哪条路是项目经理必须做出的最关键的决定之一, 对开发团队的影响, 以及逆转的潜在不可行性.

混合解决方案，例如 离子 利用web技术跨平台呈现应用程序, 但往往, 最终产品没有达到用户的期望 本地的。 外观和感觉.

然而, 甚至“原生”这个词最近也被编译成原生代码的框架弄得模糊不清.g., 反应本地, Xamarin的等.).

本文将分析各种手机开发路径的利弊，并将其与团队构成进行对比, 成本, 以及用户体验，让产品经理能够做出更明智的决定.

一次编写，随处部署

的概念 一次编写，随处部署 指开发团队使用单个开发堆栈编写一次应用程序的能力, 将部署应用程序的平台的抽象，同时保持将应用程序部署到所有所需平台的能力, e.g.， Android, iOS, Windows等. 在理想的情况下, 这在不牺牲可维护性的情况下实现, 表演。, 或用户体验(UX).

移动应用程序开发的另一种方法(也是历史上的方法)涉及到为每个平台编写单独的应用程序的直接过程, 哪一个。, 当然, 随之而来的是潜在的高成本时间和资源.

一般来说，在选择发展道路时需要考虑的因素包括:

• 项目的年龄
• 开发团队的组成和规模
• 所需的分发平台
• 所需的上市时间
• 如果必须的话，可用带宽可以切换到另一条路径

不幸的是, 将这些因素应用于每个可用路径, 以及在无数关于这个主题的现有观点中跋涉, 会让人望而生畏. 此外, 为了满足应用程序的需求，哪条路径是最好的，这个过程常常使项目经理感到不确定.

在高水平上, 不同的手机开发路径可以分为两类:原生或WODE, i.e.无论是本地的还是其他的. 简单地说，要么编写本机应用程序，要么不编写. WODE类别进一步分为两组:

• 混合框架 -利用web技术在多个平台上呈现应用程序.
• 不同类型的框架 -那些使用本地UI组件的组件(例如.g., 按钮, 文本字段, 甚至是布局管理器)，而不是像混合框架那样在应用程序内部呈现web视图.

大多数WODE框架都是这样 混合动力; however, 以改善混合框架的性能和用户体验限制，同时仍然提供WODE框架的优点, 目前的趋势是 不同类型. 由于这种趋势，反应本地、Xamarin的和Appcelerator等框架越来越受欢迎.

这些路径都是原生的, 混合动力, 而非混合-有不同的优点和缺点, 结果就是, 每个都有最适合的不同用例. 本文的其余部分在考虑团队构成等竞争优先事项时，将分析每种移动开发路径的利弊, 项目成本, 和用户体验. 除了一些特殊的用例, 编写本机应用程序可以以稍高的成本最大化用户体验.

一般来说，“一分钱一分货“适用, 所以如果成本比顾客体验更重要, 本地可能不是正确的选择. 然而, 一旦用户体验变得至关重要, 本机应用程序成为了明确的选择, 以改善用户体验, 基于wode的应用程序会以时间或本地专业知识的形式产生相当大的成本, 哪一点违背了选择非本地开发路径的初衷.

此外, 即使付出了代价, 与原生产品相比，基于wode的最终产品总是提供较差的用户体验. 结果是, 对于大多数开发团队和大多数项目来说，原生语言几乎总是正确的选择.

本机应用程序

本机应用程序是用给定平台的核心语言编写的. 例如, Android应用程序是用Java编写的, 而iOS应用程序要么用Obj-C编写，要么用Swift编写. 它们要求开发工程师理解语言以及特定于平台的细微差别, 其中包括, 例如, 第三方包集成, 布局管理, 操作系统交互, 等等......。.

优点

高度可定制的. 因为每个应用程序都是利用本地组件编写的, 定制的唯一限制是底层框架的接口, 有时甚至没有. 正如大多数本地开发工程师所证明的那样, 尽管界面有限，但通常有一种方法可以完成给定的任务.

通过浏览特定平台的支持社区，可以找到这个想法的简单证明. 你会发现许多关于如何完成一项可能“不合时宜”的任务的例子,尽管底层框架存在局限性.

关于这种看似简单的任务，一个具体的iOS例子可能是显示全屏覆盖, 最重要的是外部UI元素, e.g., a 标签栏导航栏等. 如图所示 图1，这通常超出了当前呈现的普通UI层的范围. 像这样, 为了有一个全屏覆盖, 它必须添加到视图堆栈中TAB栏上方的隐藏层. 这种自定义通常只能在本机应用程序上实现.

最高的性能. 正如预期的那样，本机应用程序设置了性能基准. 因为大多数其他框架类型添加了一个或多个中间层, 它们天生就比本机应用程序运行得慢.

大多数可维护的. 操作系统不断变化. 期. 当他们这么做的时候, 取决于是否进行了破坏性更改, 应用程序必须及时更新，以免失去一部分升级到新操作系统的用户. 很明显, 从向用户提供更改到更新应用程序之间的时间越短, 更好的. 如果没有需要更新的依赖项来支持这个新的操作系统，那么这个时间就会最小化, 在开发本地应用程序时是哪种情况.

缺点

额外的资源. 在为多个平台编写应用程序时, 一个开发团队通常由一个或多个成员组成 移动软件工程师 对于每个支持的平台. 当然，这必然会增加开发团队的规模和成本. 它还要求工程师团队具备各种技能, 而不是拥有相同的技能基础. 这有可能在支持和协作方面分裂一个团队.

较慢的开发周期. 原生应用的开发周期可能较慢，因为必须针对每个平台编写单独的应用程序. 极端的情况是当团队中只有一名移动开发工程师时，因为每个应用程序基本上都是串联编写的.

低性能. 把表演看做是正反两面，这似乎有些奇怪. 一方面, 本地应用程序为开发人员提供了足够的空间来创建精细的调整, 高性能的应用程序. 但另一方面，它们也给了开发者足够的自讨苦吃的余地. 如果他们不知道自己在做什么, 最后, 他们最多只能得到一个不合格的应用程序.

注意: 一般来说，这适用于 所有 框架路径(原生、混合和非混合). 如果开发应用程序的工程师没有足够的技能来实现他们的目标, 最终的应用程序可能既不能满足设计要求，也不能被用户很好地接受.

混合应用程序

混合应用程序通常使用HTML/CSS/LESS来设计用户界面:MVC设计模式中的“V”. “C”或控制器通常是用JavaScript编写的——理想情况下，使用 JavaScript MVC框架，如AngularJS. 使用像AngularJS这样的框架，可以比只使用jQuery更好地分离类和职责.

这种类型的混合框架堆栈的一个例子是由AngularJS支持的离子视图层, 最终使用PhoneGap和Cordova在所需平台上转换并呈现在web视图中. 显然，这种WODE框架的代价是增加了复杂性.

此外, JavaScript的使用带来了它自己基于设计的限制和基于语言的问题. The goal of this article is not to debate the merits or flaws of any one language; however, 作为项目经理, 在移动技术栈中使用JavaScript的选择不应该轻易做出. 以下只是一些关于为什么JavaScript应该尽可能避免的好文章的例子:

• JavaScript问题
  
• 为什么我不是反应本地开发者

优点

最小开发团队. 混合框架使小型开发团队——特别是以web开发为主要知识基础的团队——能够跨多个平台快速生成简单的应用程序. 这使得项目经理可以保持团队规模较小，并且不需要团队为多个平台学习本地语言和框架.

更快的开发周期. 除了一个更小的团队, 当部署到多个平台时，混合框架提供了更快的开发周期，因为只需要使用web技术设计一个视图层.

缺点

潜在的糟糕用户体验. 只需要编写一个视图层的缺点是只剩下一个视图层. 这可能会导致糟糕的用户体验，因为一刀切的UI设计方法无法为所有平台上的用户提供舒适和熟悉的应用程序外观. 除了, 因为混合应用本质上是嵌入在UI中的webview, 它给用户的印象是，他们实际上是在浏览网页，而不是与本地应用程序交互. 这种体验几乎总是会对用户满意度和留存率产生负面影响.

定制成本高. 通过为每个平台设计定制的UI来改进用户体验，会产生复杂而独特的UI框架，这些框架的创建成本很高，并且随着时间的推移难以维护. 此外，为了创建有助于使应用程序脱颖而出的UI元素(例如.g.，动画，自定义视图等.), 必须创建定制的桥接组件，以将高级UI设计转换为低级框架所需的内容, 比如科尔多瓦, 就会明白. 在一般情况下, 对混合应用程序的用户体验定制和改进得越多, 它就会削弱快速和廉价设计周期的好处.

较低的性能. 因为混合应用程序在webview中呈现应用程序的视图, 在处理操作系统框架时，有很大的可能犯实现错误.g.，网络，蓝牙，设备上的联系人等.)，这会导致性能大大降低. 同样值得注意的是, 即使在性能方面非常小心，因为所有内容都是通过webview显示的, 混合应用程序的最大性能总是略低于原生应用程序.

非平凡插件管理. 记住那些设计团队花了数周时间打磨的定制功能, 接下来的几个星期，开发团队创建了必要的桥接组件，以便Cordova可以使用它们? 好吧, 他们不会工作，除非有一个支持Cordova插件的团队正在努力实现. 这意味着两件事中的一件:要么团队自己创建，要么需要找到一个合适的第三方插件来完成这项工作. 不幸的是，通常情况下，第二种选择并不存在. 结果是, 创建自定义插件需要额外的开发时间, 然后是构建支持工作，随着时间的推移，管理应用程序所需的不断增长的Cordova插件库. 当然, 当Cordova更新发生时, 这些插件也很有可能需要更新.

操作系统支持滞后. 当操作系统改变核心功能时，前面提到的级联桥组件/Cordova插件问题会进一步加剧. 一旦科尔多瓦, PhoneGap, 和离子已经更新以支持这些变化, 定制插件和桥接组件也可能需要更新. 不管这项工作需要的数量级是多少, 它会导致应用程序不支持已更新到新操作系统的最终用户的额外时间. 这, 当然, 最坏的情况是什么破, 非向后兼容的更改是由苹果或谷歌做出的, 这从来没有发生过，对吧? 在一般情况下, 任何不受开发人员控制且必须首先更新的中间框架只会延迟开发过程. 最后, 依赖于一个中间框架对于项目经理来说是一个令人头痛的计划，因为这些框架的时间是如此的未知.

不同类型的应用程序

非混合应用程序一开始就和它们的混合应用程序一样——一个用非本地平台语言设计的UI层:反应本地使用HTML/CSS支持JavaScript或Xamarin的, 它是基于c#的，因为它的 .净根.

然而，相似之处就到此为止了. 非混合应用程序编译成本地代码，并使用平台本地组件而不是通过webview来呈现应用程序. 这就产生了一个WODE框架，至少在表面上是两全其美的.

如前所述, 选择使用JavaScript不应该是一个轻率的决定, 对于不希望学习或对使用JavaScript没有兴趣的开发团队来说，这可能是一个交易破坏者.

优点

比混合动力车性能更高. 正如人们所预料的那样, 非混合应用程序天生就比混合应用程序具有更高的性能，因为它们能够使用本地UI组件(按钮)呈现应用程序, 的观点, 布局管理器等.)，而不是依赖于嵌入式webview. 当然, 开发人员仍然可以自由地编写执行出色或糟糕的应用程序. 非混合应用程序的好处是，与类似的混合应用程序相比，它们具有更高的性能基准.

最小开发团队. 类似于混合框架, 非混合模式使小型开发团队——特别是以web开发为主要知识基础的团队——能够跨多个平台快速生成简单的应用程序. 这使得项目经理可以保持他们的团队规模较小，并避免团队学习多种平台的本地语言和框架.

更快的开发周期. 除了一个更小的团队, 当部署到多个平台时，非混合框架提供了更快的开发周期, 因为只需要设计一个视图层.

更快的迭代(React). React框架提供了一个强大的功能，允许实时呈现应用程序的更改:无需重新编译, 重建等. 结果是, React模拟器是一个非常强大的开发工具，它极大地缩短了每个实现周期的持续时间.

缺点

定制成本高. 很像它的混合动力对手, 当非混合应用程序需要通过为每个平台设计定制的用户界面来改进用户体验时, 它会导致复杂而独特的UI组件，这些组件的创建成本很高，并且随着时间的推移难以维护. 这也意味着要编写定制的桥接组件来补充框架原生元素支持方面的不足. 喜欢混合动力车, 这种成本降低了快速和廉价设计周期的好处, 但与混合应用程序不同, 桥接组件是为每个所需的平台编写的 用他们的母语. 这意味着，对于主要由web开发人员组成的团队来说，非混合应用程序是一种灵活的选择, 选择非混合路径的团队不仅要学习框架的特定语言(例如.g.， JSX或c#)，但也可以是每个平台的本机语言(Java, Obj-C或Swift).

第三方依赖关系. 这种限制有两种不同的形式. 在反应本地的情况下，它采用的形式是 众多 依赖关系,我.e.大约650人. 结果是，在任何特定时间，这些依赖项中的一个或多个都很有可能过时. 这也意味着，如果发生较大的操作系统级更改, 很有可能需要更新大部分或全部依赖项. 潜在的可取之处是Facebook使用React, 所以一个人会有300磅的大猩猩站在他们这边.

以Xamarin的为例, 第三方依赖问题很简单，首先集成它们是极其困难的. Xamarin的意识到了这个问题，并提供了一个名为Sharpie的实用工具. 该工具的目的是帮助进行一些集成, 但不幸的是, Sharpie经常试图编译和链接不正确的资源, 为了成功地完成集成，是什么迫使开发人员承担手工修改低级编译参数的费时费力的任务.

操作系统支持滞后. 非混合型应用程序与混合型应用程序同样受到同样问题的困扰. 任何不受开发人员控制并且必须首先更新的中间框架只会延迟更新应用程序以支持尖端用户的过程. 此外, 如前所述, 依赖于一个中间框架对于项目经理来说是一个令人头痛的计划，因为这些框架的时间是如此的未知.

长期支持(反应本地). 这个问题是反应本地特有的，并且与一个奇怪的事实有关, 到目前为止, Facebook尚未承诺为其框架提供长期支持计划. 可以说，这是一个低风险，因为该公司使用自己的框架为其移动应用程序, 但任何项目经理都值得停下来思考一下，为什么Facebook拒绝就这个话题发表评论.

选择正确的方法

当成本不是首要考虑因素时， 图2 说明在利用开发团队的组成来满足应用程序的需求时，编写本机应用程序几乎总是最好的选择. 当开发工程师的数量少于所需平台的数量时, 它变得更有趣了. 在这种情况下, using React is the correct choice if the team is under a very tight release schedule; otherwise, 本地化仍然是最好的选择.

当团队主要是一个web开发团队时, 和定制的用户体验是必需的, 为了使应用程序本地化，最好让一些团队成员改变身份或增加一些团队成员. 真的没有可行的, 如果应用程序需要自定义元素，可维护的框架选项, 很多应用程序都是这样的.

然而, 如果不需要自定义UX, 然后, 取决于发布时间表, 使用离子或React可能会更好. 如果一个团队没有时间学习JSX，那么 离子是正确的选择. 否则, 最好选择React，因为它已经需要很多第三方依赖, 添加更多内容并不会影响开发者的开发周期.

一旦项目的成本是首要考虑的问题, 通常, 现有的团队组成变得不那么重要了，因为第一步是将适当的团队安排到位，以执行项目计划的预计成本. 如图所示 图3, 本机应用程序的启动成本比WODE应用程序高, 还有更高的潜在用户体验. 此外, WODE应用程序在用户体验方面总是受到限制, 不管项目投入了多少资金和资源.

我希望这篇文章能够说明各种移动开发路径的优缺点, 同时也有助于根据应用程序需求和项目成本来权衡团队组成. 它的信息并不是要传达WODE框架是次等的，永远不应该寻求, 而是说，即使存在不使用本机的有效用例, 人们应该充分理解这样做的后果.