分享 Hybrid 技术调研

victor · 2014年03月18日 · 最后由 billy 回复于 2014年03月19日 · 6124 次阅读

此文是我们团队内部选型时候我的一点笔记,主要是给同事看的,也许对大家有点帮助,没什么新东西,主要是整理人家的文章和内容为主。

移动 App 开发技术分类

Web App

介绍

  • 成本低,快速开发
  • 响应式设计
  • 浏览器运行很多手机特性无法访问。例如联系人,推送等
  • single page app
  • 销售渠道限制于浏览器

Native App

介绍

  • 学习成本高,开发成本高,开发效率低
  • 不同平台一道坎

Hybrid App

介绍

Hybrid App 优点

  • 兼具 Native App 良好用户体验的优势和 Web App 跨平台开发的优势
  • 开发成本和难度比 Native App 小
  • 使得开发和日常维护过程变得集中式、更简短、更经济高效
  • 既可以通过 Native 分发渠道推广产品,也可同时在微信,百度轻,UC 等移动平台推广

现状

  • 国外的 Facebook,App Store
  • 国内的百度搜索,淘宝客户端 Android 版。其中百度封装的不是 WebView 而是自己的浏览内核,体验更像原生客户端,更高效。

Hybrid 含义

  • mobile application: 就是一个移动应用
  • both browser-supported language and computer language: 同时使用网页语言和程序语言编写
  • avaiable through application distribution platforms: 通过应用商店进行分发
  • a target device: 区分目标平台
  • install to run: 用户需要安装使用

Hybrid 类型

  • 多 View 混合型
  • 单 View 混合型
  • Web 主体型

多 View 混合型 (中)

即 Native View 和 Web View 独立展示,交替出现。例如我们第一版本的安卓 App。

单 View 混合型 (好)

即在同一个 View 内,同时包括 Native View 和 Web View。互相之间是覆盖(层叠)的关系。

这种 Hybrid App 的开发成本较高,开发难度较大,但是体验较好。

例如百度搜索为代表的单 View 混合型移动应用,既可以实现充分的灵活性,又能实现较好的用户体验。

Web 主体型 (差)

即移动应用的主体是 Web View,主要以网页语言编写,穿插 Native 功能的 Hybrid App 开发类型。

这种类型开发的移动应用体验相对而言存在缺陷,但整体开发难度大幅降低,并且基本可以实现跨平台。

Web 主体型的移动应用用户体验的好坏,主要取决于底层中间件的交互与跨平台的能力。

国外的 appMobi、PhoneGap 国内的 AppCan 和 Rexsee 都属于 Web 主体型移动应用中间件。其中 Rexsee 不支持跨平台开发。appMobi 和 PhoneGap 除基础的底层能力更多是通过插件(Plugins)扩展的机制实现 Hybrid。而 AppCan 除了插件机制,还提供了大量的单 View 混合型的接口来完善和弥补 Web 主体型 Hybrid App 体验差的问题,接近 Native App 的体验。

中间件

App 的 Native 代码部分使用操作系统的 API 来创建嵌入式 HTML 渲染引擎,该引擎在浏览器和设备的 API 之间充当了桥梁。这座桥梁让 Hybrid App 得以充分利用现代设备所提供的全部特性。

App 开发者可以选择编写自己的桥梁,或者充分利用现成的解决方案,比如 PhoneGap。

App 的 Web 部分可能是驻留在服务器上的网页,也可能是一组 HTML、JavaScript、CSS 和媒体文件,封装到 App 代码中,存储在设备本地。

  • 放置在服务器上的 HTML 代码让开发者不必经历提交和批准过程——有些 App 商店要求这个过程,就可以对 App 进行小幅更新。遗憾的是,这个方法摈弃了任何离线可用性,因为设备与网络没有连接时,无法访问设备。
  • 把 Web 代码封装到 App 里面可以提高性能和可访问性,但是不允许远程更新。
  • 推荐的方案是:结合使用两者。这种系统采用的架构可以把 HTML 资源放置在 Web 服务器上,以获得灵活性,但是又把它们本地缓存在移动设备上,以获得高性能。

根据我们目前的技术实力和业务需求,内部时间人力资源预算,不建议使用中间件,以下是市面主流中间件的对比。

最后选择的架构

  • Ember 用于双向绑定,网络请求,视图管理等工作
  • Require.js JavaScript 模块化工具,能够帮助你把整体的代码管理的井井有条(这块还没决定好)
  • 开发阶段使用 Haml + Sass + Coffee
  • API server 使用 Ruby Rack + Grape + Puma

题外话

为毛不用 Angular,为毛不用 jade,为毛不用 BackBone,不用 jQuery Mobile,不用 PhoneGap。。。。

我也不知道为啥不用。可能都是命吧。另外朋友们提到的一些技术,例如 jade ,我是确实不了解。可能在具体的开发中,如果发现特别合适的话,就会果断使用的。另外一些,比如 jQuery Mobile,PhoneGap 和 BackBone 确实是各有缺点,不适合我们目前的需求。并不是它们不好,我相信它们都有自己适用的地方。

后记

在用 Ember 开发了 2 周之后,发现确实可以满足我们目前阶段的需求。还在疑虑的同学,可以小范围的开始上了。

参考资源

延伸阅读

以前做了 3 年多手机跨平台的平台,编写方式类似于 android, 跨平台层由 mini java 来驱动,界面描述用 xml, 在 symbian,mobile 时代用着还挺不错。

不过现在手机平台做两个就差不多了,不管从体验,还是性能,都是原生的爽。说 Native App 开发效率低,在 oc,java 来说不会有多差呀。

这张图是 AppCan 的广告么?全是优。

楼主好人,楼主一生平安 😄

祝楼主 Ember 使用顺利。

Titanium 现在平台比较全,主要缺点还是生成的 app 文件过大,内存泄漏

#2 楼 @xieyu33333 这张图是盗的,可能真是广告。。。但是我仍然不会选,因为只要他们主机一死,用它开发的 App 就打不开了。

#1 楼 @hhuai 主要是为了解决跨平台的兼容性问题。希望一次开发,可以很快的同步移植到 iOS,和各种移动浏览器端。

Hybird app 不见得开发成本低。只是更适合 web 开发者罢了。而 web 开发者远比 iOS / Android 开发者多,所以你懂的……但这不代表随便找个懂点 jQuery 的就能干活。举个栗子,做一套 UI 能够适应 iPhone / iPad 和各种主流分辨率的 Android 机型就不是件容易的事情。

而且浏览器有浏览器的坑,不下于以前前端工程师考虑桌面浏览器兼容的情况。一些对 native app 开发者完全不是问题的东西到 hybird app 中就需要各种 hack……

  1. 比如 Mobile Safari 键盘一弹出所有 "position: fixed" 的元素就全变 absolute 了,目前来看官方也没有修复的迹象,但 Android 的 webkit 内核没问题。
  2. 比如 Android 4.0 键盘弹出会遮挡 UI ,而且最下面被挡住的部分死活滚动不上去。但 Mobile Safari 无此问题。而且 Andorid 2.x 貌似也没这个问题。
  3. 比如两者都对 div/span 上的 click 和 touch 事件无任何响应,还好可以加 "cursor: pointer" 解决。

#8 楼 @darkbaby123 你可能搞混了 Hybird app 和 Web app 的区别。所谓的混用,就是原生和 Web 技术混在一起搞。这样在跨平台的部分可以很容易。我们目前的实际使用情况是,只在小部分地方使用嵌入 HTML,JS,CSS 的办法。把这些文件当做一个资源包,比如 App 内部的社区部分,我们就改用 Ember 来做了。不过 Hybird 真的不是那么简单的一个 WebView 显示 file://XXXX 就完事了。首先找到靠谱的浏览内核,然后一个 UI 中哪里是 HTML5 哪里是原生,都要规划好。

想搞的特别好的确是任重而道远,但是对于小团队还想吃多平台的情况,这是一条 合适我们团队 的道路。

只会 jQuery 的确不行,JavaScript 功底不能差,CSS3 不能不熟。至于响应式布局的 UI。。。我们还是花钱买吧,自己搞耽误不起时间。

#8 楼 @darkbaby123 你遇到的这几个坑我都遇到过。1 太严重了,3 的话,如果用 jQuery,往不是 document 或 body 的父元素上可以绑,如:

$('.father-element').on('click', 'selector', function() {});

另外一些坑:

  • webview 里加载图片太多曝内存。想象很多 app 会有一个可以无限加载更多的大图列表...
  • 滚动时无事件,动画会暂停。
  • 样式各 “浏览器” 不兼容就不骂了。

@Victor 我的意思是不管 Web app 还是 Hybird app,只要有用到浏览器,都会碰到浏览器相关的问题,而往往那些问题对 Native app 来说不需要考虑的。所以不是简单写一套代码放在里面就高枕无忧了。

我是用的 PhoneGap + Ember.js 来做的,PhoneGap 除了打包,也就是负责一些浏览器无法做到的事情(跟设备进行交互)。所以我碰到的问题大多都是浏览器相关的。虽然一些组件也可以考虑用原生代码实现,然后做成 PhoneGap plugin,但那样而言就失去了 “Write once, run everywhere” 的便利性了。当然 web 和 native 的比重这个涉及到很多方面的权衡,各人有各人的选择。

@ashchan 曝内存的问题我还没遇到,不过确实很多人抱怨过。不过我碰到过一个很长的 list 会导致 app 变慢,暂时解决方法是把滚动到区域外的 item 取消掉,用相同高度的空白 div 代替。滚动时无事件是什么问题?可以说说么?

可以考虑百度轻应用,看他们的样子,近期是要有大动作的。

楼主做了好多研究。不过 Facebook 扎哥都承认 html5 是失败的选择了,楼主还拿他举例?

#11 楼 @darkbaby123 长列表的问题,一般也采取把 off screen 的图片去掉的方法(如把 src 设成一张小图片)。但好像已经不管用了。

滚动的问题,native 的 scrollbar 在滚动时会不断发事件。在 iOS webview 里,只有在完全停止后才会发事件。另外,滚动时页面上的 gif 动画或 css animation 多会暂停。

#11 楼 @darkbaby123 Native app 当然好。但是我们开发人员有限,又想快速吃掉 iOS,移动 Web(百度轻和 UE,以及其他某某移动浏览器)。使用 Native app 我们每次迭代的周期太长了。往往是主力版本都更新好几次了,其他版本都跟不上速度。

所以部分地方使用 HTML5 来搞,可以直接把这部分移植到其他版本尤其是百度轻,UC 那些地方。

#13 楼 @billy 我在开篇就说了,此文的内容是整理和收集。

各种移动浏览器坑也是挺多的

#13 楼 @billy 这个事情不能简单的说就说 html5 是失败的选择,或者也许是用法不成熟呢?微信也在逐渐的开放 Hybrid 框架出来,让更多的内容接入。我的看法:html5 不是问题,看如何用,以及用在哪里,或者说用的程度。

移动设备上的现有应用都没办法直接被搜索引擎索引,所以推广成本就非常高,需要自己开发,然后找各个 store,以及到处贴二维码,下载链接来推广 app。

这个本身是有问题: app 只是一种业务承载的方式,不能因为 apple 或者 google 的利益驱动,就让大家都去往这个上面靠。最后金钱,精力都消耗进去了,收获甚微,可是不做又不行,因为对手在做。在恐惧和贪婪的驱动下,我们不断去做 app。

如果 Hybrid 的 Native 部分是 google 或者百度来做,然后其中的 Html5 是开发商来做,这样用户通过搜索就可以发现商家的产品,并进行消费了。这个成本就会迅速降低下来,而搜索也收获了有价值的流量。

现阶段,搜索达不到产业要求,那么独立 Hybrid 做的产品,是不是 Html5 的部分本身就应该能被访问或者搜索,用户在搜索引擎里面检索到 Html5 页面,其中关键功能使用的时候引导下载 app 呢?这就是百度轻应用目前在做的事情

#18 楼 @mobiwolf 这诚意满满的广告语,您是百度轻内部的吗?求加好友

@Victor 我只是说那个事情而已。其实文章整理得非常好,很有帮助,谢谢你。

@mobiwolf 不是我说的:)是扎哥一两年前说的,他说他拍板用 HTML5 导致 Facebook 前期在移动平台上很被动。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号