一、H5網站轉換成App需求說明

如果我們只有H5網站，沒有App，想要生成App的可選方案有哪些？目前的技術，大概有三個路線：

  1. 利用Android/Object-c原生語言，分平台重新開發；這樣會導致H5、安卓、iOS三端並行，成本最高，效率最低；
  2. 利用React Native/weex/MUI/Cordova等跨平台技術，一套代碼覆蓋Android、iOS兩個平台；這樣需要維護H5、跨平台App兩套代碼，成本、效率都居中；
  3. 復用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。

不信媲美原生？看視頻：wap2app應用和原生應用的對比視頻

視頻說明：

  • 環境：相同的手機設備（小米6，同樣的MIUI版本）、相同的網路，使用前均清理了內存，原生應用使用最新版。
  • 結論：wap2app新頁面渲染速度和原生不相上下，在300毫秒的動畫期間即可渲染，而且動畫平順。

wap2app框架具有如下特點：

  1. 提供了原生渲染能力，讓界面渲染速度和動畫效果，達到原生體驗
  2. 提供豐富的系統原生能力（定位、分享、支付、推送等），達到原生功能
  3. 通過json配置頁面規則和強化規則，工作量低，學習成本低
  4. M站僅需稍作修改，改造成本低
  5. 強化部分和之前的M站解耦合，M站後續升級業務邏輯，生成的App自動含有更新後的業務邏輯

四、wap2app實現方案

wap2app的底層實現很複雜，涉及大量的原生、HTML5優化，針對每個體驗差異問題，我們都有對應的優化方案，例如：

窗口動畫：wap2app底層攔截頁面跳轉，新頁面使用新的webview載入，然後使用view的原生動畫（如slide-in-right或pop-in）切換；

滾動條通頂：使用原生標題欄代替HTML5的標題欄，隨著webview一起創建；支持自動讀取頁面標題，即解決了滾動條通頂，也避免了頁面全白問題。

選項卡切換：將選項卡區域和內容區拆分成兩個單獨的webview，切換選項卡時，選項卡區webview僅切換高亮狀態，然後通知內容區webview載入新的頁面，這樣就可以避免整體白屏現象。

接下來，我們重點講解能力擴展和渲染加速兩個方面。

1、能力擴展

HTML5可用API比原生App少很多，很多和系統設備相關的功能無法實現；wap2app底層基於HTML5 PLUS引擎，可以調用幾十萬原生API，實現更強的推送、分享、支付、定位等系統能力，可實現和原生App一樣的功能要求。

wap2app中可調用的HTML5 PLUS API分兩個部分。

1.1、常用的API – HTML5plus

包括二維碼、搖一搖、語音輸入、地圖、支付、分享、文件系統、通訊錄等常用API，封裝成跨平台的HTML5plus規範，並公開到 www.HTML5plus.org，不做廠商私有API。HTML5中國產業聯盟目前已經成為工信部的下屬單位，而HTML5Plus規範也已經成為行標，並進行了國標立項。

1.2、其他原生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代碼中直接調用原生代碼。

1.3、 原生擴展示例 - 分享

因HTML5能力限制，H5網站僅支持wap方式的分享，分享體驗很糟糕，如下是一種典型實現（參考下方截圖）：

  • 點擊微信分享後，顯示一個二維碼，用戶需要啟動微信掃描二維碼，先在微信中打開這篇文章，然後再通過微信右上角的菜單分享出去；分享路徑太長，操作麻煩；
  • 點擊微博分享，需要登錄微博wap站，完成授權後才能分享

wap2app運行在HTML5 PLUS 引擎下，是可以通過HTML5 PLUS的[share模塊](HTML5+ API Reference)直接調起系統原生分享的，同樣場景，稍作改造，在wap2app環境下調用原生分享，則體驗會大大改觀，如下為調用原生分享後的截圖：

wap2app還可以調起系統支持的更多分享，比如微博、QQ、簡訊、郵件等，如下為點擊「更多分享」後的示例：

很明顯，wap2app調起原生分享後，分享路徑更短、體驗更好，更有利於內容的分享傳播。

2、 渲染加速

web頁面載入渲染速度相比原生App，有較大的體驗差距，以至於在移動設備上嚴重影響業務體驗。造成這些體驗差距的原因大致有如下幾個：

  • 渲染時機：web app需要等待服務端Document下載完成後才開始啟動渲染工作，無法提前分區域渲染；而原生App作為C/S結構的應用，僅向服務端請求業務數據，其它布局、樣式大多在本地，故可以在用戶觸發打開新窗口時，立即渲染新窗口部分區域布局，服務端響應數據後，再更新對應區域的內容；
  • 圖片資源請求時機：web app需要先下載Document，然後再根據Document中的<img>標籤的src屬性去非同步載入圖片資源，故在web app中總是先看到文字，然後再逐漸看到圖片；而原生App則無需任務等待，可以直接載入圖片資源，故原生App的圖片顯示會早於web app中的圖片顯示；
  • 業務數據請求時機：web app的實現若是前後端分離，則需要先下載封裝業務邏輯的js文件，下載完畢後，再由js發起ajax請求；而原生App，則大多將業務邏輯封裝在本地，無需等待下載js文件，可以更早的發起HTTP業務請求

如何提升web頁面的渲染速度，很多公司都在嘗試，比如Google主導的AMP技術(Accelerated Mobile Pages Project)，以及國內百度延伸的MIP技術，這類技術以閱讀類網頁加速為主，不適合JS交互複雜的場景，適用範圍有限。

DCloud在webview的基礎上，提出了subNView技術，這是一種更為通用、可增強任意web頁面渲染體驗的方案。

2.1、 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加速後，頁面切換過程對比：

2.2、如何使用subNView

開發者可以通過webview的[subNViews屬性](HTML5+ API Reference)創建或修改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涉及

  1. wap2app本地端的工作：通過框架提供的sitemap文件，描述頁面關係和動畫強化方案，以達到原生的窗體切換效果。當sitemap.json配置無法滿足複雜需求時，可使用app.js編程進行增強處理。
  2. H5網站的改造工作：針對App運行環境（UA不同），進行適當的改造，包括去掉一些App里不應該出現的頁面元素（如底部的電腦版鏈接，啟用原生導航條後需隱藏原來HTML5的DIV導航條）。
  3. 如果需要調用DCloud的HTML5+擴展能力，比如M站之前無法實現的微信分享、推送、原生支付，進行必要的編程開發，這部分工作可以在本地端實現，也可以在H5網站實現（需要區分是wap2app運行環境）。

one more thing，wap2app 完全免費！

體驗方式：從http://liuyingyong.cn下載「流管理器」，其中唯品會、大眾點評等都是基於wap2app實現的。

更多信息，請移步：wap2app官網


推薦閱讀：
相关文章