在一个大学项目中,我的团队计划开发一款适用于 Android 的云消息应用程序。最初,我们通过研究和使用 Ionic Framework 和 Phonegap 创建混合应用程序来开始开发。
根据到目前为止我们所阅读和了解的内容,我们所理解的混合应用程序开发允许我们使用我们非常熟悉的网络技术(HTML、CSS Javascript)进行编码,而与构建本机应用程序相比,花费的时间要少得多。它还有一个优点是可以在多个平台上运行,只需进行很小的调整。
但随着我们的前进,我们从许多同事和该领域的人们那里得到了一些奇怪的反馈,这些反馈都指向一件事:
对混合应用程序普遍不信任和怀疑。
最终,由于这种反馈以及其他原因,我们决定采用原生应用程序,但它总是困扰我们为什么人们有这样的感觉。
是的,普遍的观点是混合应用程序不如本机应用程序。虽然这对于更熟悉 Web 技术的开发人员来说可能会令人沮丧,但它确实有充分的理由:
-
无法与原生组件交互: 虽然插件如
cordova-plugin-statusbar
存在,使用 Web 技术与本机组件交互和操作本机组件存在限制。我个人遇到的一个重大(且令人沮丧)的问题是,当键盘动画输入时,无法在键盘顶部进行输入。这听起来像是一个不问题,直到您看到一个应用程序,其中这是一个基本功能,例如在 Slack 等聊天应用程序中。
-
300毫秒延迟:虽然现代浏览器开始逐步淘汰这个 https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away,混合应用程序上存在的一小部分延迟使应用程序感觉缓慢且非原生。随着越来越多的用户采用诸如以下的解决方法,这个问题变得不再是一个因素FastClick.js https://github.com/ftlabs/fastclick以及一些框架,例如Ionic https://ionicframework.com/默认消除它。
-
仇恨者是对的(某种程度上):虽然混合应用程序开发已经取得了长足的进步,但仍然存在原生应用程序中不存在的小故障和滞后功能。屏幕转换、应用程序切换和电池寿命仍然是错误出现的常见领域,并且可能会持续一段时间,即使它们开始变得越来越不引人注目。
-
有一些很棒的本机解决方案:使用较新的语言,例如 Apple 的Swift https://swift.org/用本机语言编码变得越来越容易。话虽这么说,诸如此类的工具反应本机 https://facebook.github.io/react-native/由于允许开发人员使用 JavaScript 等友好技术进行编码,但编译为本机代码,因此陷入了 Native 和 Hybrid 之间的灰色地带。
这个故事的寓意是,这实际上取决于对您的特定用例来说重要的是什么。混合应用程序已成为一种可行的选择,不再是令人尴尬的副业。相反,与 Native UX 交互的一些小方面仍然是不可能的,除非使用 Native 应用程序。
总的来说,我建议规划您的项目并确定您的应用程序是否需要本机应用程序的任何优势。使用诸如离子视图 http://view.ionic.io/您可以轻松地将应用程序的基本模型放在一起,并在真实设备上测试混合应用程序是否适合您。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)