混合开发中的h5页面与原生界面

原创 minsong 随笔 移动开发 1299阅读 2017-05-16 19:07:37 举报

最近的在做混合开发的项目,再此记录一下查找到的资料以及遇到问题的解决。
现有3类主流APP,分别为:Web App、Hybrid App(混合模式移动应用,Hybrid有“混合的”意思)、 Native App(原生app,后面都用“原生app”来描述)。Web App和原生app有很多大牛们都做过比较详细的比较以及优劣势分析,我主要对Hybrid App来简要分析下,谈谈Hybrid App里原生页面和H5页面的比较和分析。
Hybrid APP指的是半原生半Web的混合类App。需要下载安装,看上去类似Native App,但只有很少的UI Web View,访问的内容是 Web 。
现在不少app已经使用H5页面来代替原生页面(即Hybrid APP),两种方式具有不同的用户体验。

1.原生页面和H5页面的优劣势分析

其各自的优劣势也有很多前辈都已经总结过了,我稍微记录并归纳下(本文中的相对/相比较都是针对这两种方式而言的)。
原生页面
优势:
(1)运行速度比较快
(2)能使用设备的底层功能,如摄像头、方向传感器、重力传感器、拨号、GPS、语音、短信、蓝牙等
(3)在界面设计、功能模块、操作逻辑等层面相较web更易做到App的便捷性和舒适性,功能更加强大
(4)节省流量
劣势:
(1)不同的操作系统(如Android和iOS)需要独立的进行开发,使用其各自的开发包、开发工具和控件
(2)每次有更新,都需要重新打包一次发布到应用平台上,且每次要向各个应用商店进行提交审核。之后用户需要手动进行点击更新安装(安装成本较高)
(3)开发成本比较高,尤其需要适配各种机型时(如Android应用,需要适配各种Android手机)

H5页面
优势:
(1)由于是运行在浏览器上,所以只需要开发一次便可以在不同的操作系统上显示
(2)迭代版本时,不需要打包便可以发布(实时更新、快速迭代),与云端实现实时数据交互
(3)开发成本相对较低,对浏览器的适配较简单,且发布门槛相对较低
劣势:
(1)每次打开页面,都得重新加载,获取数据...
(2)过于依赖网络,速度无法保证。特别在弱网环境下,不仅耗费流量而且加载缓慢,就算是WiFi情况下也不容乐观
(3)只能使用有限的设备底层功能(无法使用摄像头、方向传感器、重力传感器、拨号、GPS、语音、短信、蓝牙等功能)
(4)仍处于发展阶段,部分功能无法在基于现有技术的浏览器基础上实现,且无法全面的显示最完美的用户体验,只能用现有技术去弥去找最佳解决方案

2.如何区分Hybrid APP中的原生页面和H5页面

一直在想一个问题,原生页面和H5页面到底是凭啥区分的?看了网上很多大牛是从页面的设计上来区分的。如:
(1)顶部显示网页链接;
(2)有加载的进度条;
(3)没有底部tab导航栏;
(4)顶部显示两个导航条;
(5)有悬浮圆圈/标识;
等可以区别出H5页面的几种方式。然而现在越来越多的应用开始弱化这些表象。【Hybrid App里面一般(1)、(2)、(4)点已经被弱化,除了微信(等..),用的还是加载进度条(微信的加载进度条简直要逼疯我的节奏,特别是网速特别慢的情况下,就眼睁睁看着他到不了尽头)】,如图所示:

混合开发中的h5页面与原生界面
下面,以淘宝为例,给大家看看...真的是怎么都识别不出来啊!!
淘宝:原生 vs H5

混合开发中的h5页面与原生界面
淘宝-聚划算:双入口

混合开发中的h5页面与原生界面
由上图得知,是否有悬浮圆圈/标识无法区别出H5页面

底部H5tab导航栏

混合开发中的h5页面与原生界面
由上图得知,是否有底部tab导航栏也无法区别出H5页面。

问了公司的程序员,结果还是一头雾水,只有灰溜溜的去寻求度娘的帮助,果然找到了。
设置-开发者选项-显示布局边界
H5中使用了webview控件,其作为一个控件,只有一个边界框,所以通过这一点,就比较容易区分出一个界面是webview实现的还是原生布局控件实现的,当然也不排除用一堆webview来拼成一个界面的实现方法。
如下图是一个原生与webview混排的界面,红色线框是各控件的绘制边界,中间那一大块布局丰富的界面没有显示出很多边界红色,就是H5实现的。

混合开发中的h5页面与原生界面

3. 原生页面还是H5页面?

对这两种开发模式分别进行比较,分别得出几种各自适用的场景
选择原生页面的几点理由:
1.使用定位功能
如果需要用到GPS定位功能,以前只能使用原生的API来查看用户的位置信息,但现在大多数的主流浏览器上都嵌入了W3C Geolocation API。安装了WebKit的设备或是配置了Opera或Mozilla浏览器的设备,均可以获取用户的位置信息。这在技术上已经没有太大的困难,然而却受到隐私保护条例的限制。加入定位功能,意味着给网站引入了一些敏感信息,可能会导致严重的后果。而原生app的位置信息必须经过用户授权,排除了隐患。

2.使用摄像头
如果需要用到摄像头功能,原生开发者能够简化拍照的过程,直接在客户端对照片做一些处理,只有需要的时候才上传服务器。W3C正在开发一个访问摄像头的API,但现在还没有将这部分工作正式整合到浏览器中。

3.使用感应器(方向传感器、重力传感器等)

4.访问文件系统
访问文件系统常会涉及到安全和用户隐私保护的问题。恶意应用程序可能会修改或删除你的数据。移动设备越来越私人化,在移动设备上保存了大量用户的个人信息、朋友信息及商业信息,保存在本地的数据更加安全且可以为用户提供更加有针对性的服务,这要求开发者须获得用户的授权后才能访问用户的私人数据。则原生app更容易做到这点
访问文件系统时至关重要的一点就是在没有获得用户授权的情况下,不要访问任何用户的私人数据。而这一点,往往被大多数应用忽略了。W3C正在为移动开发商开发相关的标准API,但目前该工作尚未完成。

5.提供离线服务
使用原生页面可以将数据保存在本地并进行读取,可以实现离线服务,在无网或弱网情况下,更深得用户喜爱。

选择H5页面的几点理由:
1.功能开发不完善,试运营阶段(试错成本低),快速收集用户反馈信息及时更新
2.应用须适应多个操作系统,且资源/预算有限制
3.技术强,能够极力解决由网速引起的页面不顺畅问题
4.不满足原生app条件之一,且能做到第三点的完善,并随着越来越丰富的功能接口可供开发者调用,web app比原生app更合适
5.非核心需求,在功能调整或内容的运营上很灵活
6.阶段性的营销活动,希望被分享出去

4. h5和原生页面之间的交互一(判断web页面是否在App中打开)

自定义useragent的方式交互
web页面通过脚本能够很容易的拿到浏览器的ua属性,那么在app启动的时候,自定义添加一个ua属性,那么web页面就能够根据这个自定义的ua属性,轻而易举的判断出是否在app内了。比如jdapp。
要自定义ua属性,iOS可以参考学步园上的这片文章 或者参考stackoverflow上的文章。安卓可以参考包子博客里的安卓开发之设置webview的浏览器标识(User-Agent)

使用js调用的方式交互
webview和js之间可以通过脚本互相调用。
安卓实现可以参见denniswang的Android中webview和js之间的交互。iOS可以参见UIWebView与JS之间的数据交互

5.总结

我觉得混搭使用这两种开发模式是最符合当下web技术发展以及app的发展背景的,像淘宝就把原生页面和H5页面融合的天衣无缝,也尽可能的用技术解决了H5页面的劣势问题。当然,各企业需要根据自身的条件以及战略来选择适合自己的开发模式,合理配置资源。
对于Hybrid APP,对H5页面有几个注意点:
H5页面的几个动效设计优化点:
1.尽量使用比较简单的动效,不要求做到酷炫,但求做到好用就行
2.顶部标题栏尽量使用原生的(这样在网速渣,内容没刷出来的情况下,也可以快速返回,不流量)
3.不要使用浏览器进度条加载方式,用下拉刷新的方式(和原生保持一致,不让用户有浏览网页的感觉,而是在使用app)
4.少用手势,以防与浏览器手势冲突
H5页面的几个技术优化点:
1.优先显示框架,内容可以缓慢加载显示出来
2.模块化你的 H5 页面/应用,引入模块加载器(可选)
模块加载器如SeaJS、requireJS、kissy loader 等。使用模块化的方式来开发你的应用,不仅仅将有利于后期的代码维护,在 Hrbrid 的架构中,还将会有利于性能的提升。
疑问:模块开发粒度越细化,加载时请求的JS、CSS等静态资源的数量越多,页面的性能不会越差吗?
答:如果你仅仅是使用了模块加载器并异步加载各个模块,那么加载的性能一定很差,因为请求的数量太多。当然你肯定会想到在发布前打包合并静态资源,那么对这样的解决方案我只能给到 50 分,因为被打包合并的文件中只要有一个子文件发生变化,那么整个文件(JS或CSS)都要被重新下载,对移动带宽而言还是个负担。
3.启用 AppCache ,并引入增量更新机制
做过 WebApp 的同学应该会了解mainfest文件,Html5提供的应用缓存功能,开发者只要把需被缓存的静态资源文件名罗列在这个列表中即可保证二次访问时无需重新加载。看起来不错!这样前面说的模块化开发造成的请求数量过多的问题,至少在二次访问时不会再发生了。嗯,这样的方案可以给到 70 分吧。其实,Html5 提供的 mainfest 缓存机制有个比较大的问题(兼容性就先不提了):如果 mainfest 列表中的一个资源文件需要更新,那么整个 mainfest 中的其它文件也都需要被重新下载一遍。 也即是说二次访问没有问题了,但是 Html5 应用更新时还是会出现全量下载的问题。
别忘了,我们是 Hybrid App,还可以充分利用 原生层的强大能力,所以抛弃mainfest吧,让原生来帮助 Html5 应用缓存静态资源文件。总体思路是:
(1)、Html5 应用首次启动时,调用 原生提供的加载资源文件专用的 Device API 来请求所需的资源文件,由原生层发出真正的资源请求,并将请求结果缓存在手机的SD卡上。当然,这里完全可以优化为一次 zip 包请求,因为原生能够提供强大的解压能力。
(2)、H5 应用再次启动时,所有的静态资源都是通过 Device API 读取本地缓存,无需再走网络。
(3)、H5 应用出现静态资源更新时,在应用启动时首先通过 Device API 加载需要更新的文件,并更新本地缓存,其它未变更文件继续走缓存。
流程看起来挺顺,其中有几个关键问题需要解决:
(1)、如何通过 Device API 加载资源文件?
这里使用模块加载器的优势就体现出来了,只需要在加载器中做点小修改,不直接走Http请求了,而直接调用原生提供的文件加载 DeviceAPI 即可。 如果你没有模块加载器,就需要写统一的函数来做加载资源的功能了。
其实原生也提供了拦截机制,能够拦截到 H5 应用发出的所有 Http 请求并进行自定义处理,可惜这样好的功能在 Andorid 4.0 以下版本不支持。 故现阶段还是主动调用 Device API 更靠谱。
(2)、何时需要进行静态资源的更新?
每次静态资源发布都会产生一个唯一的发布时间戳(或是所有资源内容的MD5编码),H5应用启动后,可将当前时间戳保存下来,等应用下次启动时,请求最新的发布时间戳并与本地时间戳进行对比,若不同,则首先进行静态资源的增量更新。
(3)、如何判断哪些是需要被增量更新替代的静态资源文件?
这个问题的回答会比较复杂些,核心思路是通过对前后两次资源文件(js、css、image等)发布的内容对比完成:

混合开发中的h5页面与原生界面
如此,H5 应用借助原生应用的能力完成了资源的缓存与增量更新,可以保证 H5 应用在启动与更新时的加载速度。当然也有方案借助 HTML5 的 localstorage 来替代 Native 的缓存更新策略,但是可能会受到两处限制:
1)、若 Hybrid App 比较复杂,涉及多个子域甚至主域间的静态资源共享,则 localstorage 的方案首先要解决跨域访问的问题,并且在每个子域存储空间上存在上限,是 5M。
2)、原生能够支持更新包的 zip 打包下载,一次请求,然后解压并更新本地缓存。而 localstorage 无法实现。
若应用中以上两点不是问题,则使用 localstorage 缓存的策略完全 OK。
4.启用 spdy 协议
spdy协议在移动开发上大有可为,它是HTTP协议的增强版本,能够通过一次TCP链接同时请求到多个资源文件,请求速度上的提升那是自然的了,非常强大!chrome 等 webkit 内核浏览器都已经支持。 可惜若是借助浏览器自身使用 spdy 协议则要求静态资源服务(js、css、image)必须是 https 的域名服务,且后台server能支持spdy协议。相信大多数静态服务器都还是http 服务,是无法通过浏览器来直接支持的。
还是那句话,因为我们是 hybrid 应用,可以发挥native的优势! native 层完全可以实现基于 spdy 协议请求的 device API,供 H5 应用(JS)来调用。这样就不需要 https 域名服务器也能使用 spdy了。
如果你的 Hybrid 应用已经支持了 spdy 协议,那么你可以考虑不再需要把增量更新的资源文件打包成 zip 下载了,直接 spdy 协议并行下载即可!
SPDY 与 HTTP 协议速度对比:

混合开发中的h5页面与原生界面

参考:Hybrid 架构下的 H5 应用加速方案

其他

写过一些纯H5的APP,虽然开发起来的确很快很舒服,但和原生比起来纯H5APP还是有很多问题,主要聚集在以下几个方面:
1、动画
动画有很多种,比如侧边栏菜单的滑入滑出、元素的响应动画、页面切换之间的过场等等,在H5之下的众多实现方法都没有办法达到纯原生的性能。一般这些的话有几种不同的选择:css3动画,javascript动画,原生动画。
css3动画非常的消耗性能,如果某一个元素用到css3动画可能还看不出来,但大面积或过场使用css3动画会让app低端手机体验非常差。最好的选择一般是通过框架调用底层的动画,但不管怎么样等于在原来的代码上包上了一层,性能还是不可避免的受到影响。
比如在一个新页面的载入上,如果调用底层动画要考虑的问题有两个,一个是本身资源页面的渲染问题,另一个是远程数据的获取。即便是这些动画能够很快的响应,但大量的css页面会导致渲染卡顿,滑入时可能会有白屏/机器卡顿的现象。为了解决这些性能问题又必须要用到预加载或模拟动画。即便是这样,滑入滑出的动画在低端的安卓机器上还是有很多问题,如果获取服务端数据处理的方式不合适,卡顿白屏的现象会更严重。具体看下面的数据获取方式。

2、获取服务端数据
首先要接受的是,这里的数据获取都是在资源页面上异步完成的,因为只有这样才能让这些资源页面完成预加载或者渲染。但是异步拿到的数据在填入页面中时可能会涉及DOM操作,众所周知,DOM操作非常消耗性能,如果页面小还好,页面稍大数据稍微复杂一点,频繁的DOM操作会导致明显的闪白。
而且最重要的一点是,如果页面加载进来之后数据更新的速度太慢,也会让页面模板等待很长时间,对用户体验又不友好,总不能每次打开都像浏览器一样等待刷新是吧。
这个问题如果没有得到解决,H5APP是很难承担大规模数据的页面,在它们之中频繁切换更是难上加难,那么肯定有人也会想到用MVVM的方式,其实我也写过一些基于MVVM的H5APP,相对来说它们获取数据和更新数据的方式更敏捷更科学,但写的过程中又要注意很多H5独有的问题,这些问题在下面的页面切换里来讲。

3、页面切换
上面我们看到了几种不错的实现方式,比如预加载和模拟动画,甚至有批量的预加载,批量的截图模拟动画等等,虽然看起来很友好解决了不少问题,但事实上如果页面足够多就会引发另一个问题:页面的生存周期。
试想一下,如果引导页或者主页面缓存了5个子页面的资源,在跳转到响应的子页面时又会缓存这些子页面的下级页面资源,如此反复肯定会占据大量内存使APP的体验下降。那么怎么知道那些页面是需要的,最多缓存多少页面,什么时候结束哪些页面的生存周期呢?在我用过的很多H5APP的框架里都没有对这些问题有一个完美的解答,因此在页面较多内容较多的APP中可能会因这些资源分配的问题降低性能。
这时候我们回过头来再看看MVVM的数据加载问题,实际上不管哪个MVVM框架,写过的人都知道管理这种新型的前端代码最重要的问题是内存的问题,你既要保证代码写的足够优雅没有任何内存泄露问题,也要考虑到在页面生存周期结束时它们的控制器/页面资源是否得到释放,这对全局有没有什么影响,在多个请求时也要合理的分配资源,甚至是复用这些父级页面传过来的缓存资源等等。较小的APP可能并不会有这些问题,如果你想用纯H5来开发大型APP,这很可能会浪费你很多时间——而且结果还不会让你满意。

4、Android/iOS的区别
很多人都说纯H5APP一次编写就能编译Android/iOS两种不同的APP,大大降低了成本。实际上这个观点本身就是值得怀疑的,如果你写过这类APP就能明白我在说什么,它们既不省事,又存在很多BUG,调试时尤其繁琐。
举一个很简单的例子,Android和iOS在返回上一页的处理方式上就有明显的区别,iOS的顶部bar在全屏下怎样处理,Android机器出现smart bar怎样处理页面的布局,调用底层硬件时怎样区分不同的场景等等,你需要写一个又一个机型和系统的判断,然后分别在Android和iOS下调试,最后你却发现这并没有卵用,累的要死却什么没学到,只有一堆不知道什么时候会过时的经验。

现在做H5混合APP开发的人很多,但是纯H5却很年轻,很多问题都没有很好的解决,这几个是我在做这些APP时考虑最多的问题。当然大家也不必担心,随着ES6的推行,硬件发展越来越快,纯H5APP未必没有一席之地。最后说一个很少人注意到的H5优势,大家大谈H5APP时都是快速开发、低成本、多平台等等,但我却觉得它和很多APP开发方式相比有一个不同之处——图文混合的排版。
正是这些复杂多变的CSS样式消耗了性能,但是它带来了排版的多样性,能够细致到每一个字宽行高和风格的像素级处理,才是H5的优异之处。
评论 ( 0 )
最新评论
暂无评论

赶紧努力消灭 0 回复