速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

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

评论

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

构建Web3社交平台:DeBox式DApp开发全攻略

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 NFT开发 代币开发

探索最佳多人协作软件,优化团队流程

爱吃小舅的鱼

协同办公软件 团队协作工具 协作工具

大奖收割机!望繁信科技荣获年度技术创新和应用品牌奖

望繁信科技

数字化转型 流程挖掘 流程资产 流程智能

收藏!打造高质量技术文章的8个技巧

京东零售技术

写作 企业号9月PK榜

精准电商营销:基于京东商品详情API返回值的数据分析

技术冰糖葫芦

api 网关 API Gateway API 测试 API 策略 pinduoduo API

海外云手机有哪些推荐?

Ogcloud

云手机 海外云手机 云手机推荐 手机群控 ogphone云手机

加密货币市场持有与价格波动:CFI调查揭示的趋势与未来展望

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 NFT开发 代币开发

ICE 8月各项板块盈利报告,人工智能与高频交易驱动稳定收益

科技热闻

如何使用 StarRocks 管理和优化数据湖中的数据?

镜舟科技

数据湖 数据处理 分布式架构 StarRocks

C++创建与调用dll动态链接库(MinGW64 Dev-C++)

快乐非自愿限量之名

华为应用市场:用户为首,技术领先,筑牢应用安全“第一道防线”

最新动态

区块链趣步模式DAPP系统开发部署搭建

V\TG【ch3nguang】

趣步模式DAPP系统开发

百年码头遇见数智化:华为和天津港解锁新质生产力

Alter

一文读懂企业治理转型助力数字经济和低代码发展

快乐非自愿限量之名

低代码

把低代码拿在手里,快速推动工业数智化创新发展

EquatorCoco

低代码 数智化

游戏直播平台开发如何避免安全漏洞?这里有一份解决方案!

软件开发-梦幻运营部

数据库上云有多轻松?华为云技术专家带你玩转云数据库API

华为云开发者联盟

从管控角度谈慢SQL治理

不思jo

等待风起——京东.Vision项目参与实录分享

京东零售技术

Vision pro 京东.vision

Hugging Face 的应用

霍格沃兹测试开发学社

纯CSS实现海浪文字效果

南城FE

CSS 前端 动画

Reflection 70B 遭质疑基模为 Llama 3;Replit Agent:编程 0 基础适用丨 RTE 开发者日报

声网

精准学:用一根垂直大模型支柱,撑起教育普惠的未来

脑极体

AI

由点到面,英特尔与腾讯持续深耕云、网络、存储等领域

E科讯

《代码整洁之道》-大师眼中的整洁代码是什么样

京东零售技术

后端 代码

开发者必备的 4 大类 AI 工具盘点,错过你就亏大了!

伤感汤姆布利柏

三分钟带你看懂,低代码开发赋能办公方式转变

不在线第一只蜗牛

低代码

阿里巴巴中国站商品搜索API返回值解析与实战

技术冰糖葫芦

api 网关 API Gateway API 测试 API 策略 pinduoduo API

Java 内部类的使用场合介绍

秃头小帅oi

AI+医疗:营销机遇洞察2024

易观分析

医疗 人工智能’

京东鸿蒙上线前瞻——使用 Taro 打造高性能原生应用

京东零售技术

鸿蒙

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