在过去的几年中，我们周围的世界经历了一次强大的范式转换，其中，我们日常生活的几乎每个方面都围绕以应用程序为中心的生态系统旋转或与之相关。早上报警?有一个应用程序可以通过量身定制的机制唤醒您。早餐?火起来的食谱书，鞭打东西。出租车上班吗?几下水龙头，几分钟之内就会出现在路边。这种转变所产生的回旋效应使人们期望应用程序能够完成每项任务(无论多么艰辛)，每天都被初创企业和开发人员迅速填补。随着市场以惊人的速度发展，开发人员被迫在两种方法之间进行选择，每种方法都有自己的优缺点。
什么是本机和混合应用程序?
应用程序开发的两种流行方法是本机应用程序和混合应用程序。您问这些术语是什么意思?让我们快速看一下这两种范例。
本机应用程序是使用平台的既有方法专门为其创建的。他们尊重平台的设计模式，使用平台的主流编程语言(例如，Android的Java)，可以完全访问可用的API，并提供比混合应用程序更好的性能。
混合应用是使用HTML和Javascript等网络技术创建的，然后打包在一起并包装在本机浏览器中。设想此模型的一种简单方法是，设想一个网站，该网站在应用程序的WebView中本地运行。混合应用程序不具有完整的API访问权限，提供的设计体验不尽人意，并且使用Web包装程序会对性能产生重大影响。
代码可重用性
众多应用程序是混合的主要原因是该模型在代码可重用性方面拥有巨大的优势。混合应用程序产生了“一次构建，多次部署”的理念，该理念允许开发人员使用Web语言对应用程序进行一次编码，然后将其包装在浏览器中即可在各种平台上进行部署。据说这可以节省大量的初始版本和更新麻烦，但是这种方法的分散性常常被忽略–并非所有开箱即用的浏览器都支持较新的Web标准，并且开发人员经常最终编写一个大量的兼容性代码和替代CSS规则，针对每个平台的浏览器并满足其要求，从而降低了混合应用程序携带的“ 100%可移植”标签的重要性。
用户界面
社会的
近年来，设计已起着举足轻重的作用，每个平台都可以创建和完善自己已经适应用户的视觉样式，并且期望该平台上的所有应用程序都能使用它，原生应用程序可以轻松地使用平台的设计SDK所提供的组件，而混合应用需要花费大量精力才能实现用户熟悉的界面。尽管如此，混合应用程序只能在“一次构建，多次部署”的理念下一次满足一个平台的熟悉程度，而更占主导地位的平台的可视语言通常在应用程序中占据中心位置，从而使其他平台的用户陷入混乱混乱，因为他们迎接了许多外星人的布局。
设备访问
Android-4.55.0-L-Lollipop
每个平台都提供自己的API集，开发人员可以使用这些API，从布局设计和动画集到电池优化和安全访问。本机应用程序通常可以通过简单的方法调用来无缝利用这些API，但是混合应用程序在此方面的差距很大。尽管诸如Cordova和Ionic之类的某些框架提供了访问基本API(如蓝牙，WiFi等)的插件，但覆盖范围还远远不够完整，并导致缺乏优化，众多折衷和功能受限的问题。
性能
htc-one-m9基准
在过去的几年中，硬件功能已经走了很长一段路，与软件行业的需求保持同步，并确保用户获得优化和流畅的设备体验。尽管当今大多数旗舰店采用的CPU，GPU和RAM配置令人印象深刻，但应用程序并没有在这种架构级别上运行，而是封装在众多软件层中以提供高级开发体验。应用程序和硬件之间的每个包装器都会显着影响设备的性能和效率，而本机应用程序在层次结构中的特定级别运行，而混合应用程序则需要围绕HTML代码的另一个包装器。因此，性能影响虽然并不总是很明显，但肯定会存在，并且在执行更多苛刻的操作时可能会成为明显的缺点。
成本
代码可重用性的必然结果是，如果不是在本地应用程序上选择混合应用程序，则成本降低是主要原因，即使不是主要原因。在一个平台上构建然后在多个平台上部署的能力可以降低成本，因为每个平台都可以聘请独立的团队，由一个多产的HTML团队创建该应用，然后执行将其包装在每个平台的浏览器包装中的简单任务，甚至使用诸如Phonegap Build之类的自动化工具来进行最后一英里的平台分配。即便如此，浏览器碎片化仍然是一个不容易解决的严重问题，其修复程序更多地是不需要JavaScript中的try-catch块和大量替代CSS规则。要顺利实现这一目标非常困难，并且需要一支技术娴熟的Web开发团队，
用户体验
关注用户，其他所有操作都将随之而来。这个口号是由Google设计团队提出并提出的，在这个时代，用户的期望，参与度和满意度可以证明是应用与其替代品或竞争对手之间的关键区别，这一说法是正确的。正确完成后，本机应用程序可以提供最完美的用户体验，在设计时会考虑该平台的用户群，并随后无缝使用用户习惯的模式，样式和组件来制作。另一方面，混合应用程序提供的用户体验却远远不能令人满意，仅满足特定平台的需求，无法在触摸反馈，布局响应等方面满足用户期望。尽管许多开发人员继续忽略UX的重要性，
我该选择哪一个?
在这两种方法之间进行探索的目的不是要找到并确定两者中的更好方法，而是要突出选择一个或另一个缺点的各种优势。每种方法在某些方面都有优势，而在其他方面则有所欠缺，最终由开发人员做出选择。问自己一些简单的问题即可简化此选择，例如：
我需要立即为多个平台发布我的应用程序，还是可以从一个平台开始然后扩展?
牺牲成本和缩短上市时间值得牺牲用户界面和应用程序的用户体验吗?
我是否需要访问某些无法通过混合方法获得的特定API?
我的应用程序在性能方面是否繁重，混合方法是否可以满足这种需求?
不要忘记看一些大型企业并从他们的错误中学习。例如，Facebook和LinkedIn在过去都使用混合应用程序，这导致用户极度不满，导致两家公司走本机路线并分别为每个平台构建。只有您知道什么是最适合您的解决方案!
