将H5网站转换成原生体验的App

H5网站转换成App需求说明

如果我们只有H5网站，没有App，想要生成App的可选方案有哪些？目前的技术，大概有三个路线：

利用Android/Object-c原生语言，分平台重新开发；这样会导致H5、安卓、iOS三端并行，成本最高，效率最低；
利用React Native/weex/MUI/Cordova等跨平台技术，一套代码覆盖Android、iOS两个平台；这样需要维护H5、跨平台App两套代码，成本、效率都居中；
复用H5网站，直接将H5网站转换成App，这样只需要维护H5一套代码，成本最低，效率最高。

虽然第三种方案成本最低，但要做好，难度最大；如果只是使用webview简单套壳打个包，功能体验和原生App相比，差距甚远，最终用户不买账。

H5网站转换成App，关键是实现原生版的功能和体验，这是存在业界很久的一个转换难题，甚至很多人已经放弃希望。

web App和原生App的体验差距

web App和原生App的体验差距主要体现在：

窗口动画：H5网页在手机浏览器上是通过href在当前页面跳转的，没有动画；但原生App是通过原生View动画进行切换的，体验更好；
滚动条通顶：H5网页的标题栏一般是div方式fix在顶部，页面滚动条会通顶，把标题栏右侧盖住。这个效果很不原生。虽然使用div滚动也可以解决滚动条通顶，但div滚动在安卓上效率无法商用。
下拉刷新：H5网页通过DIV模拟的下拉刷新不流畅，甚至很多M站干脆就不做下拉刷新。但App里这是一个常见而重要的交互操作。
选项卡切换：原生App切换选项卡时，选项卡区域不变，仅内容区view变化；但web app切换选项卡时，会将整个页面重新加载，经常出现白屏现象
返回按键处理：若用户之前操作触发了弹出层显示（比如地址选择），则在用户按下back键时，原生App会先关闭弹出层，并不会直接关闭当前页面；但web app会直接执行history.back()逻辑，导致整个页面的后退。
渲染速度：H5网站属于B/S结构，需要先下载再渲染；而原生App大多为C/S结构，资源从本地加载，可以无需等待立即渲染部分元素，避免白屏现象；
系统能力：HTML5因API限制，很多终端能力无法调用，导致很多功能缺失或不如原生，比如推送、扫码、分享、支付等；

系统梳理，这样的体验差异点还有很多，我们基于多年HTML5开发经验和大量项目实践，逐一解决如上的体验差异点，终于打磨出了wap2app产品。

wap2app框架简介

wap2app是一个将现有HTML5网站快速发布成App的开发框架，通过wap2app框架，进行简单的配置和必要的编程，即可完成M站的体验强化，可打包成iOS平台的ipa、Android平台的apk，可上线各大应用市场，转换后的App可媲美原生App。

不信媲美原生？看视频：https://v.qq.com/x/page/x05025vurui.html

视频说明：

环境：相同的手机设备（小米6，同样的MIUI版本）、相同的网络，使用前均清理了内存，原生应用使用最新版。
结论：wap2app新页面渲染速度和原生不相上下，在300毫秒的动画期间即可渲染，而且动画平顺。

wap2app框架具有如下特点：

提供了原生渲染能力，让界面渲染速度和动画效果，达到原生体验
提供丰富的系统原生能力（定位、分享、支付、推送等），达到原生功能
通过json配置页面规则和强化规则，工作量低，学习成本低
M站仅需稍作修改，改造成本低
强化部分和之前的M站解耦合，M站后续升级业务逻辑，生成的App自动含有更新后的业务逻辑

wap2app实现方案

wap2app的底层实现很复杂，涉及大量的原生、HTML5优化，针对每个体验差异问题，我们都有对应的优化方案，例如：

窗口动画：wap2app底层拦截页面跳转，新页面使用新的webview加载，然后使用view的原生动画（如slide-in-right或pop-in）切换；

滚动条通顶：使用原生标题栏代替HTML5的标题栏，随着webview一起创建；支持自动读取页面标题，即解决了滚动条通顶，也避免了页面全白问题。

选项卡切换：将选项卡区域和内容区拆分成两个单独的webview，切换选项卡时，选项卡区webview仅切换高亮状态，然后通知内容区webview加载新的页面，这样就可以避免整体白屏现象。

接下来，我们重点讲解能力扩展和渲染加速两个方面。

能力扩展

HTML5可用API比原生App少很多，很多和系统设备相关的功能无法实现；wap2app底层基于HTML5 PLUS引擎，可以调用几十万原生API，实现更强的推送、分享、支付、定位等系统能力，可实现和原生App一样的功能要求。

wap2app中可调用的HTML5 PLUS API分两个部分。

常用的API – HTML5plus

包括二维码、摇一摇、语音输入、地图、支付、分享、文件系统、通讯录等常用API，封装成跨平台的HTML5plus规范，并将规范公开于www.HTML5plus.org，不做厂商私有API。HTML5中国产业联盟目前已经成为工信部的下属单位，而HTML5Plus规范也已经成为行标，并进行了国标立项。

其他原生API – Native.js

原生API在iOS和Android上各自有40多万，有些API并不常用，而且不具有跨平台特性，比如ios的game center api。太多的API封装到HTML5plus里，会过多增加runtime的体积，但若有需求要使用这些api又很麻烦。
我们有一项突破性的技术来解决上述烦恼—Native.js，一种把40w原生API映射为JS API的技术。

wap2app支持native.js，可以在js代码中直接调用原生代码。

原生扩展示例 - 分享

因HTML5能力限制，H5网站仅支持wap方式的分享，分享体验很糟糕，如下是一种典型实现（参考下方截图）：

点击微信分享后，显示一个二维码，用户需要启动微信扫描二维码，先在微信中打开这篇文章，然后再通过微信右上角的菜单分享出去；分享路径太长，操作麻烦；
点击微博分享，需要登录微博wap站，完成授权后才能分享

wap2app运行在HTML5 PLUS 引擎下，是可以通过HTML5 PLUS的share模块直接调起系统原生分享的，同样场景，稍作改造，在wap2app环境下调用原生分享，则体验会大大改观，如下为调用原生分享后的截图：

wap2app还可以调起系统支持的更多分享，比如微博、QQ、短信、邮件等，如下为点击“更多分享”后的示例：

很明显，wap2app调起原生分享后，分享路径更短、体验更好，更有利于内容的分享传播。

渲染加速

web页面加载渲染速度相比原生App，有较大的体验差距，以至于在移动设备上严重影响业务体验。造成这些体验差距的原因大致有如下几个：

渲染时机：web app需要等待服务端Document下载完成后才开始启动渲染工作，无法提前分区域渲染；而原生App作为C/S结构的应用，仅向服务端请求业务数据，其它布局、样式大多在本地，故可以在用户触发打开新窗口时，立即渲染新窗口部分区域布局，服务端响应数据后，再更新对应区域的内容；
图片资源请求时机：web app需要先下载Document，然后再根据Document中的标签的src属性去异步加载图片资源，故在web app中总是先看到文字，然后再逐渐看到图片；而原生App则无需任务等待，可以直接加载图片资源，故原生App的图片显示会早于web app中的图片显示；
业务数据请求时机：web app的实现若是前后端分离，则需要先下载封装业务逻辑的js文件，下载完毕后，再由js发起ajax请求；而原生App，则大多将业务逻辑封装在本地，无需等待下载js文件，可以更早的发起HTTP业务请求

如何提升web页面的渲染速度，很多公司都在尝试，比如Google主导的AMP技术，以及国内百度延伸的MIP技术，这类技术以阅读类网页加速为主，不适合JS交互复杂的场景，适用范围有限。

DCloud在webview的基础上，提出了subNView技术，这是一种更为通用、可增强任意web页面渲染体验的方案。

subNView介绍

subNView，字面拆开理解就是sub native view，有两个核心点：

native：subNView是一种原生绘制的View，和HTML5的DOM无关
sub：subNView属于webview的一部分，并不替代完整Webview。和所属webview保持同样的生命周期，跟随webview的close、hide、zindex变化而变化。

subNView作为webview的子控件，一个webview可以包含多个subNView，一个subNView上可以绘制多个图片（包括图片轮播）、文字、区域、按钮等。

subNView在保留HTML5优势的基础上，利用原生View发挥原生渲染优势；当用户触发窗口切换时，webview按照原有逻辑继续加载Document，渲染页面；但无需等待Document加载完成，可同时在原生View上提前完成如下工作：

绘制固定内容区域，或可从前页获取数据的区域，例如固定地址图片、购物车按钮等，而无需等待Document下载完毕后再去请求加载图片
直接发起业务数据ajax请求，ajax响应后直接在原生View上绘制数据，无需等待业务封装的JS下载

如下为一个使用subNView增强后的商品详情页示例：

从上图可看出：

webview按照原有逻辑，加载Document，渲染页面，刚开始内容未加载时还是白屏（中间空白区域）
webview同时创建了2个subNView作为webview的子控件
subNView 1展示商品详情轮播图及商品价格，是通过ajax动态获取的；轮播图片支持滑动、点击放大预览，用户可提前查看商品详情
subNView 2展示购物车相关功能，属于固定显示内容，可直接渲染
购物车按钮点击后事件透传给Webview里的购物车按钮，HTML页面的所有逻辑，仍然复用。subNView只是简单的侵入动画渲染过程，不引发业务逻辑的重新编写。

如下是使用subNView加速后，页面切换过程对比：

如何使用subNView

开发者可以通过webview的subNViews属性创建或修改subNview控件，这里需要传入复杂的json对象；为简化开发，DCloud提供了NView模板技术。

NView模板类似于vue的single-file components(单文件组件)，HBuilder中新建NView模板文件，默认代码如下：

<template><nviews cachemaxage="86400"></nviews>
</template>
<script>module.exports = {data: {//默认数据},init: function(url) {//动态初始化数据},methods: {//方法}};
</script>

NView模板涉及模板标签、属性、样式定义、数据绑定等概念，详细移步wap2app官网查看。

wap2app开发方式

wap2app开发简单，主要基于json文件快速配置，规则简单，学习成本低，工作量少；一个中等规模的M站，一个前端工程师4天左右就可以转换完成。wap2app同时支持Javascript高级编程，可实现更为复杂的需求开发。

在具体开发过程中，wap2app涉及

wap2app本地端的工作：通过框架提供的sitemap文件，描述页面关系和动画强化方案，以达到原生的窗体切换效果。当sitemap.json配置无法满足复杂需求时，可使用app.js编程进行增强处理。
H5网站的改造工作：针对App运行环境（UA不同），进行适当的改造，包括去掉一些App里不应该出现的页面元素（如底部的电脑版链接，启用原生导航条后需隐藏原来HTML5的DIV导航条）。
如果需要调用DCloud的HTML5+扩展能力，比如M站之前无法实现的微信分享、推送、原生支付，进行必要的编程开发，这部分工作可以在本地端实现，也可以在H5网站实现（需要区分是wap2app运行环境）。

one more thing，wap2app 完全免费！

体验方式：从http://liuyingyong.cn下载“流管理器”，其中唯品会、大众点评等都是基于wap2app实现的。

更多信息，请移步wap2app官网：http://dcloud.io/wap2app.html