雀恰营销
专注中国网络营销推广

h5页面,Hybrid App中原生页面 VS H5页面

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页面,Hybrid App中原生页面 VS H5页面

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)点都被削弱了,除了微信等..),加载进度条还是用的(的加载进度条微信快把我的节奏给逼疯了,尤其是网速很慢的情况下,就看他还没走到尽头)]

附上微信进度条….(醉)

下面,以淘宝为例,看看……我真的认不出来了! !

h5页面,Hybrid App中原生页面 VS H5页面

从上图可以看出,是否有浮圈/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.尽量用更简单的动画,不酷,但好用

h5页面,Hybrid App中原生页面 VS H5页面

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协议即可!

赞(0) 打赏
未经允许不得转载:雀恰营销 » h5页面,Hybrid App中原生页面 VS H5页面
分享到: 更多 (0)

评论 抢沙发

评论前必须登录!

 

文章对你有帮助就赞助我一下吧

支付宝扫一扫打赏

微信扫一扫打赏