【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

别闯进 Hybrid App 的误区

  • 2014-03-20
  • 本文字数:3570 字

    阅读完需:约 12 分钟

【引言】Hybrid App,一种开发模式,兼顾 Web 和 Native 的一种开发模式。有人说它把 Web App 扼杀在摇篮里,有人说它把 Native App 引向一个新阶段。我说,它是一把双刃剑,千万别闯进它的误区。本文是笔者在实践 Hybrid App 开发模式过程中总结出的一些经验教训,供读者参考。Hybrid App 虽好,可万万不能仓促选择,盲目运用。

智能手机日益普及,移动互联网乱战日趋白热化,开发一个应用早就不是技术圈热议的话题,iOS 和 Android 上的 App 已经成了每个互联网产品的标配。“唯快不破”也是中被移动互联网人尊为铁律,快速迭代,高效开发,低成本上线是每一个 App 开发团队追求的目标。同时,随着 HTML 5 的不断升温和智能手机硬件性能的提高,Hybrid App 的概念应运而生。这种“Native 搭台,HTML 5 唱戏”的 Hybrid App 开发模式一时间受到各个开发团队追捧,快速进入了大量开发团队,成为主流开发模式。

Hybrid App 优点众多,Web 前端工程师 0 成本介入,不依赖版本的实时更新,快速实现跨平台需求,等等。而另一个方面,2012 年 Hybrid App 的践行者 Facebook 决定大量弃用 App 中的 HTML 页面,转向更加 Native 化的方案。Facebook 的这一举措也给 Hybrid App 方案的敲响了警钟,这似乎并不是一个完美的方案。

本文主要跟大家分享一下我团队和个人在 Hybrid App 的实践中遇到的问题,提醒大家不要闯进 Hybrid App 的误区。

误区一:为了HTML 5Hybrid App

HTML 5 在 Hybrid App 模式中是一个最常被提起的概念。HTML 5 作为一个 HTML 4.0.1 和 XHTML 1.0 的升级版,基于旧版本有更强大的表现功能,并加入了 Local Storage 等技术,确实为 Web 页面提供了更大的想象空间和更多的可能性。但 HTML 5 处在目前的发展阶段,受到浏览器兼容性和手机硬件性能水平的影响,它所能提供的功能与 Native 仍然有很大差距。

所以,我认为作为工程师要明确一款 App 采用 Hybrid App 模式的根本原因是什么。作为一款 App 其最根本的功能是满足使用者的需求,而并不是服务某项新技术。因此当决定采用 Hybrid App 去构建一款应用时,应该从应用本身功能特点和整个团队的开发资源配比统一考虑,是否有必要同时又有能力去驾驭一款“Native 搭台,HTML 唱戏”的 Hybrid App。类似“HTML 5 的时代已经到来,如果我们不这么做就变土鳖了,错过这场技术革新的大潮,终将被这个时代所淘汰”的话真不是一个有责任心的工程师应该发出的声音。

误区二:忽略关键因素

在谈到 Hybrid App 的场合我们更多提及的是它有诸多优点,如何架构一个 Hybrid App,怎么让 Web 和 Native 和谐共处,然而 Web 开发中会被忽略的一些因素少被提起,这些因素又恰恰经常是一个 Web 页面能否正常运行在 App 中的决定性因素。

Web 开发是基于 PC 的一种开发模式,开发者使用 PC 浏览器模拟 App 中的 Web View 进行调试。PC 浏览器与手机 Web View 的区别是巨大的,能支配的 CPU 资源,最大占有的内存,运行的网络环境,鼠标操作与触控操作的区别,浏览器对 CSS/JS 的解析和对事件处理,等等。

App 工程师,无论是 iOS 还是 Android,最敏感的一个问题莫过于内存管理,而在 Web 开发则对这个问题没有过多注意。这就经常导致同一个功能界面 Native 实现中会通过一些技术手段,把内存容量控制在操作系统允许的范围内保证 App 正常运行。如果以 Web 方式接入 App 的页面没有一个明确的标准和严格的验收机制,相应的 Web 实现则不会过多考虑这方面的问题,而且浏览器也没有给前端工程师提供足够的 Api 支持处理内存问题,导致在某些条件下造成 App 无法正常运行,甚至 Crash。

同样的问题会出现在网络环境方面,虽然现在 wifi 覆盖越来越广,3G 网络也日益普及,但 App 运行的网络环境与 PC 相比仍然有着巨大差距,wifi 和蜂窝网络的切换,基站变化等诸多因素都会导致网络间歇性断开。Web 开发总是默认有一个稳定的网络环境,因此在对于不稳定网络环境问题的处理上也有所欠缺。没有明确的对于低速网络或不稳定网络访问的处理,在很多情况下这些页面也会非常不给面子。

误区三:富交互导致体验差

这里所谓的体验问题一分为二:一是与手机平台默认交互习惯不一致的体验,二是与同样功能 Native 界面存在的体验差距。

无论在 Android 还是 iOS 平台上,都有各自的一套交互习惯,包括视觉风格,界面切换,操作习惯等,与 Web 习惯完全不同。如果使用 Web 方式开发富交互的页面,或多页面功能就会出现这样的问题。

以 iOS 界面切换为例,系统风格是新界面自右向左推入,后退时界面自左向右推出,而旧界面保持状态。Web 开发的默认习惯则是刷新页面,无论新载入页面或是后退,都会对页面进行刷新。因此使用 Web 模式开发多界面功能就面临这样的交互习惯差异,造成体验上的损失。当然 Web 方式也可模拟 Native 的交互方式,但这样的模拟首先提高了开发成本,有悖于最初的高效原则,从效果上看,也很难达到 Native 的流畅性。

另一个方面,也是上述提到的与 Native 相比,同样的功能在性能上存在巨大差距。Web 界面上 JS 对 HTML Node 的操作需要消耗大量的 CPU 资源,手机 CPU 的性能还不能与 PC 相提并论,就算在智能手机之间,硬件水准也参差不齐,一个可以在 iPhone 5 上流畅运行的界面,跑到三星 S III 上很可能就卡住不动了。所以我们经常可以发现一些富交互页面上的操作无法达到令人满意的流畅度,而流畅度也正是用户评价一款 App 优劣的最直观因素。

误区四:跨平台

一次开发,跨平台运行是 Web 的优势,这也是很多 App 采用 Hybrid 模式的重要原因之一。兼容性问题在 Web 开发过程中往往不被关注,但当下智能手机的软硬件版本众多,兼容性绝对是一个不容忽视的问题。

以 Android 手机为例,诸多主流品牌都有各自定制过的操作系统,浏览器内核对 JS 和 CSS 的解析,事件处理等方面都存在区别。以 HTC One 为例重叠在一起的层在某些情况下会对点击事件透传,而其他多数平台则不存在这个问题。并且目前移动平台的开发框架还没有完全成熟,可以很好的解决兼容性问题。所以就要求开发者在开发过程中要对兼容性做充分测试,对于某些特殊版本进行特殊处理。

即使在相对统一的 iOS 平台,不同版本之间也存在较大差异。例如:在 iOS 4.x 版本中 CSS 甚至不支持 position fix 的属性,4 英寸屏幕的设备无法很好的支持 apple-mobile-web-app-capable 属性,等等。

误区五:交互一致性。

交互一致性是一个非常容易被误读的概念,“一致性”经常被理解为同一个应用在各种平台和场景下要有一致性的体验。我认为在移动平台开发过程中,“一致性”应该是 App 视觉和交互习惯与其运行平台的习惯保持一致。而 Web 开发“一次开发,跨平台运行”的特性与此存在一定程度上的冲突。

以“返回上一页面”的操作为例,在 iOS 平台上在页面顶部始终存在一个 44 像素高的导航栏,左侧有一个返回按钮用于返回操作,而 Android 平台则习惯使用设备提供的返回键操作。这个返回按钮在 iOS 平台可以通过绝对地址的方式连接到任何其他页面,而在 Android 平台返回按钮和设备的返回键则可能指向不同的位置。

例如这样的一个流程:首页 -> 列表 -> 筛选 -> 刷新过的列表,此时的返回操作被期望是导向首页,则页面上的返回按钮可以通过绝对链接的方式实现,而 Android 设备的返回键则只能返回上一个筛选页面,再次返回是筛选前的列表页。

Hybrid App 方案是一把双刃剑,一方面它平衡了 Native App 和 Web 页面的优缺点,一定程度上解决了 Native App 开发过程中迭代慢,版本依赖,Native 开发资源不足的问题,但另一个方面过度依赖 Hybrid 方案会造成 Web 前端开发成本快速上升,甚至造成 App 整体体验下降,甚至造成功能缺失。

不要为了 Hybrid 而 Hybrid,控制好方案中 Native 与 Web 的边界。

扩展阅读

较早 Mobtest 针对 Facebook 的 iOS App 专门做的一片评测文章,阐述了使用大量 HTML 页面的 App 出现的问题: http://blog.mobtest.com/2012/05/heres-why-the-Facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/

资深开发者 @李秉骏 在 InfoQ 发表的《Hybrid App 实战》,阐述了 Hybrid 模式的优势与劣势,并简单介绍了开发 Hybrid App 所需的技术储备,供读者参考。: http://www.infoq.com/cn/articles/hybrid-app-development-combat

资深开发者 @唐巧 较早对 Hybrid App 主流框架 PhoneGap 的分析文章,笔者非常同意对 PhoneGap 框架的态度,PhoneGap 虽好,可不要贪杯哟: http://blog.devtang.com/blog/2012/03/24/talk-about-uiwebview-and-phonegap/


感谢李永伦对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

关注 IT 趋势,承载前沿、深入、有温度的内容。感兴趣的读者可以搜索 ID:laocuixiabian,或者扫描下方二维码加关注。

2014-03-20 16:5815634

评论

发布
暂无评论
发现更多内容

明道云在工程项目行业中的应用场景

明道云

「TEG+系列」破局者 - 腾讯金融级数据库TDSQL

腾讯云数据库

数据库 tdsql

Tensorflow保存神经网络参数有妙招:Saver和Restore

华为云开发者联盟

神经网络 tensorflow 变量 Saver Restore

云资源生命周期管理怎么做?用什么软件好?

行云管家

云计算 云服务 云资源 生命周期管理

马某兵VIP资料惨遭泄露,Java大厂面试手册,21年高频题版

Java架构师迁哥

TDSQL金融级特性之:数据强一致性保障

腾讯云数据库

数据库 tdsql

华为云GaussDB:发挥生态优势,培养应用型DBA

华为云开发者联盟

数据库 开源 GaussDB 云数据库 dba

酷家乐 UI 自动化测试平台实践

CPPAlien

测试框架 selenium BDD UI测试 活文档

简化IT运维工作,就要学会使用自动化运维工具!

行云管家

运维 云服务 IT运维

TDSQL inside之路

腾讯云数据库

数据库 tdsql

统信软件张磊:国产操作系统如何获得大众市场的认可?

Jessie

开源 最佳实践 新基建 企业动态 文化 & 方法

开放原子全球开发者峰会「开源治理」论坛预告(更新中)

开放原子开源基金会

小游戏如何应对大流量?Shopee Shake 的大促实践

Shopee技术团队

后端 高并发 游戏 电商大促 Shopee

GraphQL 快速入门【2】环境设置

码语者

Rest graphql

TDSQL 全时态数据库系统 -- 典型案例

腾讯云数据库

数据库 tdsql

张宏江出席HICOOL 2021全球创业者峰会,阐述AI研究与创业新机遇

硬科技星球

人工智能 大模型时代 悟道2.0

代理服务器转发消息时的相关头部(qbit)

qbit

正向代理与反向代理 Proxy

SpringBoot 如何进行对象复制,老鸟们都这么玩的

Java 架构 后端 计算机 框架

常见的安全应用识别技术有哪些?

郑州埃文科技

鲲鹏展翅|SphereEx 获华为鲲鹏技术认证

SphereEx

TDSQL核心架构

腾讯云数据库

数据库 tdsql

TDSQL数据同步和备份

腾讯云数据库

数据库 tdsql

Android正确的保活方案,不要掉进保活需求死循环陷进

Halifax

android 大前端 kotlin 移动开发 语言 & 开发

数字化转型的终局:赛博朋克?社会主义?

龙归科技

数字化 软件系统 软件经济 赛博朋克

MYSQL离线迁移至分布式TDSQL

腾讯云数据库

数据库 tdsql

分布式TDSQL的实践

腾讯云数据库

数据库 tdsql

淘宝网 Java 千亿级并发系统架构设计笔记(全彩版小册开源)

Java 架构 面试 后端 高并发

快速提升Golang编程能力:那就一起用Go做项目吧

博文视点Broadview

华为云与北大BIOPIC联合发布蛋白质多序列比对开源数据集

华为云开发者联盟

AI 华为云 蛋白质 多序列 开源数据集

TDSQL是什么:腾讯如何打造一款金融级分布式数据库

腾讯云数据库

数据库 tdsql

TDSQL核心特性:极具挑战的“四高”服务与安全可运维

腾讯云数据库

数据库 tdsql

别闯进Hybrid App的误区_语言 & 开发_高嘉峻_InfoQ精选文章