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页面

优点：

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