h5页面,Hybrid App中原生页面 VS H5页面
目前主流的APP有3种,分别是:Web App、Hybrid App(混合模式的移动应用,Hybrid的意思是“混合”)、Native App(native app,后面称为“native app”)。 Web App 和原生 App 有很多大牛对优缺点做了比较详细的对比分析。主要是对Hybrid App进行简单的分析,说说Hybrid App中原生页面和H5页面的对比分析。
Hybrid APP是指半原生半Web的混合App。它需要下载并安装。看起来和Native App很像,但是只有几个UI Web View,访问的内容是Web。
现在很多APP都用H5页面代替原生页面(即Hybrid APP),两种方式用户体验不同。最近刚遇到一家公司想用H5页面代替原生页面。了解了一下,记录了所有的问题和知识点。
原生页面和H5页面的优缺点分析
有很多前辈总结了各自的优缺点。我将它们记录下来并稍微总结一下(本文中的相对/比较是针对这两种方法的)。
本机页面
优点:
(1)跑得更快
(2)可以使用设备底层功能,如摄像头、方位传感器、重力传感器、表盘、GPS、语音、短信、蓝牙等。
(3)相比web,在界面设计、功能模块、操作逻辑等方面更容易实现App的便捷舒适,功能更强大
(4)保存数据
缺点:
(1)不同的操作系统(如Android和iOS)需要独立开发,使用各自的开发包、开发工具和控件
(2)每次有更新都需要重新打包发布到应用平台,提交到各个应用商店审核。之后用户需要手动点击更新安装(安装成本高)
(3)开发成本比较高,尤其是需要适配各种机型的时候(比如安卓应用,需要适配各种安卓手机)
H5页面
优点:
(1)因为运行在浏览器上,所以只需要开发一次,就可以在不同的操作系统上显示
(2)迭代版无需打包即可发布(实时更新,快速迭代),与云端实时数据交互
(3)开发成本比较低,对浏览器的适配比较简单,发布门槛比较低
缺点:
(1)每次打开页面都要重新加载并获取数据…
(2)过于依赖网络,速度无法保证。尤其是在网络较弱的环境下,不仅消耗流量而且加载变慢,即使是WiFi,也不乐观
(3)只能使用设备有限的底层功能(不能使用相机、方向传感器、重力传感器、拨号、GPS、语音、短信、蓝牙等)
(4)仍处于开发阶段,部分功能无法在基于现有技术的浏览器基础上实现h5页面,无法充分展现最完美的用户体验,只能利用现有技术摸索最佳解决方案
Hybrid APP中如何区分原生页面和H5页面
我一直在思考一个问题,原生页面和H5页面有什么区别?我看到网上很多大牛都是从页面的设计上区分的。例如:(1)网页链接显示在顶部;(2)有加载进度条;(3)没有底部标签导航栏;(4)顶部显示两个导航栏;(5)有悬浮的圆圈/logo;等可以区分H5页面的几种方式。但是越来越多的应用开始弱化这些外观。[在Hybrid中App,一般(1),(2),(4)点都被削弱了,除了微信等..),加载进度条还是用的(的加载进度条微信快把我的节奏给逼疯了,尤其是网速很慢的情况下,就看他还没走到尽头)]
附上微信进度条….(醉)
下面,以淘宝为例,看看……我真的认不出来了! !
从上图可以看出,是否有浮圈/logo无法区分H5页面
从上图可以看出,是否有底部标签导航栏是无法区分H5页面的。
我问了公司的程序员,结果还是一头雾水。我只是去找度娘帮忙,找到了。
设置 – 开发者选项 – 显示布局边界
H5中使用了webview控件。作为一个控件,它只有一个bounding box,所以通过这个,更容易区分一个界面是webview实现的还是原生布局控件实现的。当然也不排除用一堆webview的实现方法来组成一个界面。
下图是native和webview的混合界面。红色线框是每个控件的绘制边界。中间布局丰富的大界面,没有显示很多红色边界,是H5实现的。
原生页面还是H5页面?
比较两种开发模式,分别得到几个适用场景
选择原生页面的几个理由:
1.使用定位功能
如果需要使用GPS定位功能,过去只能使用原生API查看用户的位置信息,但现在大部分主流浏览器都嵌入了W3C Geolocation API。安装了 WebKit 的设备或配置了 Opera 或 Mozilla 浏览器的设备可以获取用户的位置信息。这在技术上并不太难,但受到隐私保护法规的限制。添加定位功能意味着向网站引入一些敏感信息,可能会导致严重后果。原生应用的位置信息必须经过用户授权,杜绝隐患。
2.使用相机
如果需要使用拍照功能,原生开发者可以简化拍照过程,直接在客户端做一些处理,只在需要的时候上传到服务器。 W3C 正在开发访问相机的 API,但尚未正式集成到浏览器中。
3.使用传感器(方向传感器、重力传感器等)
4.访问文件系统
访问文件系统通常涉及安全和用户隐私保护问题。恶意应用程序可能会修改或删除您的数据。移动设备越来越私密,大量用户的个人信息、好友信息和业务信息都存储在移动设备上。本地存储的数据更安全,可以为用户提供更有针对性的服务。这就要求开发者在获得用户授权之前不能访问用户的隐私数据。原生应用更容易做到这一点
访问文件系统时,在未经用户授权的情况下不要访问任何用户的私人数据,这一点至关重要。大多数应用程序经常忽略这一点。 W3C 正在为移动开发者开发相关的标准 API,但工作尚未完成。
5.提供离线服务
使用原生页面,可以本地保存和读取数据,实现离线服务。在无网或弱网的情况下,更受用户欢迎。
选择H5页面的几个理由:
1.功能开发不完善,试运行阶段(试错成本低),快速收集用户反馈并及时更新
2.应用程序必须适应多个操作系统并且有资源/预算限制
3.技术强大,能够解决网速导致的页面不流畅问题
4.不满足native app的条件之一,可以实现第三点改进,而且随着越来越多的功能接口可供开发者调用,web app比原生应用
4.
5.非核心需求,功能调整或内容操作灵活
6.分期营销活动,希望分享
总结
我觉得混合搭配这两种开发模式最符合现在的web技术开发和app开发背景。比如淘宝将原生页面和H5页面无缝融合,尽可能用技术解决H5页面的问题。弱点问题。当然,每个企业都需要根据自己的条件和战略,选择适合自己的发展模式,合理配置资源。
对于Hybrid APP,H5页面有几点需要注意
H5页面的几个动态设计优化点:
1.尽量用更简单的动画,不酷,但好用
2.顶部标题栏尽量原生(这样如果网速渣,内容不刷,不流量也能快速返回)
3.不要使用浏览器进度条加载方式,使用下拉刷新方式(与原生一致,不要让用户感觉喜欢浏览网页,而是使用app)
4.谨慎使用手势以防止与浏览器手势冲突
H5页面的几个技术优化点:
1.框架先显示,内容可以慢慢加载显示
2.模块化您的 H5 页面/应用并引入模块加载器(可选)
SeaJS、requireJS、kissy loader等模块加载器。使用模块化的方式开发你的应用,不仅有利于后期的代码维护,还能提升Hrbrid架构的性能。
问题:模块开发越细化,加载时请求的JS、CSS等静态资源越多,页面性能不会变差?
Answer:如果只使用模块加载器,异步加载各个模块,加载性能肯定很差,因为请求数很高。当然,发布前你肯定会想到捆绑合并静态资源,所以我只能给这样的解决方案50分,因为捆绑合并文件中只要有一个子文件发生变化,整个文件(JS或CSS) 都得重新下载,对移动带宽还是有负担的。
如何破解?见第 3 点——
3.启用AppCache并引入增量更新机制
做过WebApp的同学应该都知道Html5提供的mainfest文件和应用缓存功能。开发者只需要在这个列表中列出需要缓存的静态资源文件名,保证第二次访问时不需要重新加载。看起来很棒!这样,至少在第二次访问时,上述模块化开发导致的请求数过多的问题就不会再发生了。好吧,这样的计划可以给70分。其实Html5提供的mainfest缓存机制有一个很大的问题(不说兼容性):如果mainfest列表中的某个资源文件需要更新,整个mainfest中的其他文件也需要重新下载。也就是说二次访问没有问题,但是在Html5应用更新的时候还是会出现完全下载的问题。
别忘了,我们是Hybrid App,可以充分利用native层的强大能力,所以放弃mainfest,让native帮助Html5应用缓存静态资源文件。总体思路是:
(1)h5页面,Hybrid App中原生页面 VS H5页面,Html5应用第一次启动时,调用原生提供的专门加载资源文件的Device API请求所需的资源文件,native层发送真正的资源请求,请求结果缓存在手机的SD卡上。当然这个可以优化为zip包请求,因为原生可以提供强大的解压能力。
(2),当H5应用再次启动时,通过Device API从本地缓存中读取所有静态资源,无需去网络。
(3),H5应用在发生静态资源更新时,先在应用启动时通过Device API加载需要更新的文件,并更新本地缓存,其他不变的文件继续往缓存。
这个过程看起来很顺利,但有几个关键问题需要解决:
(1), 如何通过Device API加载资源文件?
这里体现了使用模块加载器的好处。只需在loader中稍作修改即可,无需直接通过Http请求,直接调用原生提供的文件加载DeviceAPI即可。如果您没有模块加载器,则需要编写一个统一的函数来加载资源。
其实原生也提供了拦截机制,可以拦截H5应用发送的所有Http请求,进行自定义处理。不幸的是,Andorid 4.0 以下的版本不支持这么好的功能。所以这个阶段主动调用Device API比较靠谱。
(2), 什么时候需要更新静态资源?
每个静态资源发布都会生成一个唯一的发布时间戳(或所有资源内容的 MD5 编码)。 H5应用启动后,可以保存当前时间戳,下次启动应用时h5页面,Hybrid App中原生页面 VS H5页面,可以请求最新的时间戳。将发布的时间戳与本地时间戳进行比较。如果不同,则先进行静态资源的增量更新。
(3),如何判断哪些静态资源文件需要增量更新替换?
这个问题的答案会比较复杂。核心思想是比较前后两个资源文件(js、css、image等)发布的内容:
这样,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的域名服务,后台服务器可以支持spdy协议。相信大部分静态服务器还是http服务h5页面,浏览器无法直接支持。
也就是说,因为我们是一个混合应用程序,我们可以利用原生! Native层可以完全实现基于spdy协议请求H5应用(JS)调用的设备API。这消除了 https 域名服务器使用 spdy 的需要。
如果你的Hybrid应用已经支持spdy协议,那么可以考虑不再需要将增量更新的资源文件打包成zip下载,直接并行下载spdy协议即可!
评论前必须登录!
注册