产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

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

评论

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

一个好的持续交付流水线是怎样的? | 研发效能提升36计

阿里云云效

云计算 阿里云 云原生 持续交付 持续部署

恒源云(Gpushare)_【活动专区】已上线,没有最优只有更优

恒源云

人工智能 算法 服务器

【等级保护】等级保护共分为几级?保护对象是指什么?

行云管家

网络安全 等保 等级保护 等保2.0

初识工业互联网

劼哥stone

工业互联网

presto实战读书笔记

聚变

从理想照进现实,浅谈“算力网络”

鲸品堂

东数西算

今儿直白的用盖房子为例,给你讲讲Java建造者模式

华为云开发者联盟

Java 设计模式 对象 建造者模式 对象构建模式

Mybatis的where标签,竟然还有这么多不知道的!

CRMEB

Linux之ping命令

入门小站

Linux

当TIME_WAIT状态的TCP正常挥手,收到SYN后…

华为云开发者联盟

TCP syn 报文 TIME_WAIT RST报文

selenium的实现原理

红毛丹

自动化测试 自动化测试框架 selenium 3月程序媛福利 3月月更

js几种网络请求方式梳理——摆脱回调地狱

有道技术团队

谁能在第四代算力革命中脱颖而出?CPU?GPU?算法?数据?

GPU算力

在线HTML转PUG工具

入门小站

工具

网易智企发布“易+”开源计划,网易会议组件正式开源

网易云信

音视频 开发

selenium相对定位器

红毛丹

3月程序媛福利 3月月更

当渲染遇上边缘计算,打造视频交互新模式

火山引擎边缘云

云原生 边缘计算 实时渲染

简单说明一下数据库审计能带来的价值

行云管家

数据库 数据安全 数据库审计

遵循Promises/A+规范,深入分析Promise实现细节(基础篇)

战场小包

JavaScript 前端 Promise 3月月更

解密数据仓库LLVM技术神奇之处

华为云开发者联盟

数据仓库 LLVM 算子 GaussDB(DWS) 底层虚拟机

详解用OpenCV绘制各类几何图形

华为云开发者联盟

OpenCV 图像处理 图像 几何图形

NFT商城游戏系统开发技术

薇電13242772558

NFT

读一篇博客,写一段代码,每天写写Python自然就会了,每日Python第1天

梦想橡皮擦

Python 3月月更

关于 CentOS 迁移龙蜥操作系统,这里有一份详细指南,请查收!

OpenAnolis小助手

centos 开源 操作系统 龙蜥

应对EAST 5.0新挑战!索信达推出灵矩全景式监管合规平台

索信达控股

数据治理 金融 监管平台 数智化 合规性

老牌软件厂商亚信科技加入,携手龙蜥社区共建开源生态

OpenAnolis小助手

开源 亚信科技 互联网社区

DevOps流水线CI 成倍提速方案

八戒技术团队

DevOps

Web 键盘输入法应用开发指南 (4) —— 组合键

天择

JavaScript 键盘 输入法 3月月更

ImageView变灰、倒影、圆角、加水印

逆锋起笔

android 图片处理 3月月更 imageView

大规模异构数据的线索列表进化之路

百度Geek说

后端

TiDB Online DDL 在 TiCDC 中的应用丨TiDB 工具分享

PingCAP

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