Hybrid App中原生页面 VS H5页面

Hybrid App中原生页面 VS H5页面

 

      现有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），两种方式具备不一样的用户体验。恰好最近遇到公司想用H5页面来代替原生页面，了解了下，并把全部的问题以及知识点都记录下来。

 

原生页面和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）仍处于发展阶段，部分功能没法在基于现有技术的浏览器基础上实现，且没法全面的显示最完美的用户体验，只能用现有技术去弥去找最佳解决方案

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

---

一直在想一个问题，原生页面和H5页面究竟是凭啥区分的？看了网上不少大牛是从页面的设计上来区分的。如：（1）顶部显示网页连接；（2）有加载的进度条；（3）没有底部tab导航栏；（4）顶部显示两个导航条；（5）有悬浮圆圈/标识；等能够区别出H5页面的几种方式。然而如今愈来愈多的应用开始弱化这些表象。【Hybrid App里面通常（1）、（2）、（4）点已经被弱化，除了微信（等..），用的仍是加载进度条（微信的加载进度条简直要逼疯个人节奏，特别是网速特别慢的状况下，就眼睁睁看着他到不了尽头）】

附上微信的进度条....（已醉）

微信：加载进度条

下面，以淘宝为例，给你们看看...真的是怎么都识别不出来啊！！

淘宝：原生 vs H5

淘宝-聚划算：双入口

由上图得知，是否有悬浮圆圈/标识没法区别出H5页面

底部H5tab导航栏

由上图得知，是否有底部tab导航栏也没法区别出H5页面。

问了公司的程序员，结果仍是一头雾水，只有灰溜溜的去寻求度娘的帮助，果真找到了。

设置-开发者选项-显示布局边界

H5中使用了webview控件，其做为一个控件，只有一个边界框，因此经过这一点，就比较容易区分出一个界面是webview实现的仍是原生布局控件实现的，固然也不排除用一堆webview来拼成一个界面的实现方法。

以下图是一个原生与webview混排的界面，红色线框是各控件的绘制边界，中间那一大块布局丰富的界面没有显示出不少边界红色，就是H5实现的。

显示布局边界

搞定！

原生页面仍是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.阶段性的营销活动，但愿被分享出去

总结

---

我以为混搭使用这两种开发模式是最符合当下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点---

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 应用在启动与更新时的加载速度。固然也有方案借助 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 协议速度对比：