写点什么

别闯进 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:5816154

评论

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

你的数据是如何泄露的?企业和个人应该这样做……

火绒安全

安全漏洞 数据泄露 黑客攻击

开源一夏 | jQuery scroll() 滚动加载列表 获取腾讯云图片像素信息

六月的雨在InfoQ

开源 COS ​jQuery 8月月更

大数据开发课程靠谱吗?

小谷哥

Kubernetes Crossplane VCluster构建新集群

CTO技术共享

开源 签约计划第三季 8月月更

PHP 项目对接视频号原来如此简单,小白也能轻松完成【带附件】

CRMEB

当科学家决定搞点“花里胡哨”的东西

图灵教育

如何读取redis的手机号验证码数据,实现自动化登录测试

Liam

程序员 测试 自动化测试 测试开发 测试自动化

聊聊阻容降压原理 和 实际使用的电路

矜辰所致

电路设计 8月月更

开源一夏 | Java"实现"svn文件对比

六月的雨在InfoQ

svn 开源 文件对比 8月月更

兆骑科创海内外高层次人才大赛平台,双创赛事活动举办

兆骑科创凤阁

黄东旭,TiDB的灵魂骑手,和他的叛逆“问答”

B Impact

一步一图带你深入剖析 JDK NIO ByteBuffer 在不同字节序下的设计与实现

bin的技术小屋

网络编程 Netty nio Java Concurrency java nio

元宇宙|高阶音频处理能力,让声音「声临其境」

融云 RongCloud

音视频技术

Kubernetes监控 Harbor

CTO技术共享

开源 签约计划第三季 8月月更

程序员培训班哪家教的比较好

小谷哥

实时云渲染——让元宇宙从科幻走入现实

Finovy Cloud

云渲染 GPU渲染

Apache APISIX 在微软云 ARM 和 x86 服务器上的性能测试对比

API7.ai 技术团队

API网关 APISIX 微软云

武汉链(基于ETH)BSN官方DDC链上数据解析

BSN研习社

区块链

免费云管平台有吗?咨询电话多少?

行云管家

云计算 企业上云 云管平台

Kubernetes Ingress 控制器讲解

CTO技术共享

开源 签约计划第三季 8月月更

基于SpringBoot的OnlineMusicPlayer项目

bug郭

签约计划第三季 8月月更

IDC:阿里云位居2021年中国关系型数据库市场第一

Lily

招生报名小程序开发笔记二:功能需求设计

CC同学

StarRocks 在 58 集团全业务线的深度实践

StarRocks

数据库

java课程学习难度怎么样

小谷哥

在小程序中SVG的打开方式

Geek_99967b

小程序 SVG

2022-08微软漏洞通告

火绒安全

microsoft 终端安全 安全漏洞

直播短视频源码——直播与短视频之间的区别如何解决

开源直播系统源码

软件开发 短视频源码 直播系统源码 直播源码 一对一视频聊天系统

焱融科技入选“2022 中关村国际前沿科技创新大赛”大数据与云计算领域 TOP10

焱融科技

文件存储 分布式文件存储 获奖

大模型落地实践:同花顺大模型技术应用及优化

澜舟孟子开源社区

人工智能 自然语言处理 预训练模型

招生报名小程序开发笔记一:开发背景和技术方案的选型确定

CC同学

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