<font id="zqva1"></font>
<rt id="zqva1"></rt>
  • <tt id="zqva1"></tt>
    <cite id="zqva1"></cite>

    <cite id="zqva1"><noscript id="zqva1"></noscript></cite>
      <rp id="zqva1"><meter id="zqva1"></meter></rp>

        <cite id="zqva1"></cite>
          <b id="zqva1"></b>
          <rp id="zqva1"></rp>
          <cite id="zqva1"></cite>

          <rt id="zqva1"></rt>

        1. <rp id="zqva1"></rp>

          H5和原生的職責劃分

          時間:?2017-12-26閱讀:?1415標簽:?h5

          前言

          在JSBridge實現后,前端網頁與原生的交互已經通了,接下來就要開始規劃API,明確需要提供哪一些功能來供前端調用。

          但是在這之前,還有一點重要工作需要做:

          明確H5與Native的職責劃分,確定哪一些功能可以由H5實現,哪一些功能只能由原生實現


          Native與H5職責劃分

          使用Hybrid模式,用H5開發頁面的本質是:

          減少工作量(一套代碼,多個平臺),以及快速的更新迭代(譬如線上更新),而且還需要考慮Native端的高性能以及系統API調用能力(否則直接用純H5就可以了)

          因此在進行職責劃分時,就得充分的考慮前端渲染,JS語言以及原生渲染,Java/OC等語言的特性,基本總結如下:

          • 混合頁面導航欄組件由原生實現

          • 一些重要的業務頁面、帶有復雜動畫或交互的頁面以及一些固定頁面由原生實現

          • 系統級UI由原生統一實現

          • 頁面切換的轉場由原生實現

          • CPU密集型任務、底層的優化要由原生完成

          • 其它功能能用H5實現(并且效果不錯)的就盡量不要用原生


          導航欄組件由Native實現

          嘗試過,也對比過很多的混合開發框架,譬如Dcloud的HTML5+,釘釘里的DD API,自己也嘗試過不同的方式, 最終發現導航欄的最好做法還是由原生提供,核心原因如下:

          • H5頁面加載過程會有白屏問題(也別是弱網絡情況),如果整個頁面都是H5實現,那么白屏了就體驗非常差,而且連基本的交互與操作都沒了

          僅基于這一點,就已經拍板了由Native導航欄組件+webview(加載H5)來組成頁面,而原生提供一些API來供網頁操控導航欄(譬如標題,按鈕等)

          整體頁面布局如下:


          而H5端可以通過原生提供的API來操控導航欄,以下舉例為quick中規劃的API:

          // 僅提供一部分示例
          quick.navigator.setTitle({
              title: '標題',
              subTitle: '子標題',
              success: function(result) {},
              error: function(error) {}
          });
          
          quick.navigator.setRightBtn({
              isShow: 1,
              text: '按鈕右1',
              // 設置圖片的優先級會較高
              //imageUrl: 'http://xxx/test.png',
              // 從右數起第幾個
              which: 0,
              success: function(result) {
                  /**
                   * 按鈕點擊后回調
                   */
              },
              error: function(error) {}
          });
          


          多tab頁面也由原生提供

          實際開發中Native導航欄組件+webview也就滿足絕大部分的頁面需求了,但是還有一些特殊頁面是這種實現達不到的,譬如多Tab頁面


          上述這種內含多tab的頁面,每一個tab里都是單獨的頁面,而且可以通過滑動等手勢來切換,甚至tab還會有一些漸變動畫,導航欄也配合改變等(常見于APP首頁)

          為了統一實現,這類頁面的導航欄與底部tab均是由原生實現,由H5通過API打開這類原生頁面,并將需要加載的網頁地址傳入,如下

          quick.page.openLocal({
              className: '那種原生頁面的標識,可以唯一查詢到相應的界面',
              data: {
                  // 需要加載的n個url
                  url1: 'http://...',
                  urln: 'http://...',
              },
              success: function(result) {},
              error: function(error) {}
          });
          

          然后,在每一個前端頁面(webview里加載的內容),可以分別在對于頁面的腳本里進行自己的交互控制


          重要的業務頁面由原生實現

          對于一些重要的業務頁面,如登陸,注冊,支付等,處于安全性以及交互性的考慮(就是一個APP的門面),會采用完全由Native實現 (當然了,一般這些頁面的變動頻率也不大)



          一些默認提示頁面采用原生實現

          webview加載網頁時,一般情況原生都是會對加載情況進行監聽的,比如是否網絡異常。服務器響應異常,頁面加載崩潰等, 為了防止APP假死,原生會提高一些默認提示頁面


          上述只是一個原型示例,實際上,很多情況都可以由原生提供統一提示頁面, 如404,頁面崩潰,網絡錯誤等


          交互性強、動畫復雜的頁面采用原生實現

          除了關鍵性頁面,還有一類,就是H5不好實現的(或者說達不到要求的、實現代價過大的),也應該由原生實現

          譬如以某圖像處理軟件某個界面截圖為例


          這種頁面涉及到了明顯不太適合H5實現的圖像處理,因此原生才是更佳的選擇(當然了,實際上H5的canvas是由圖像處理能力的)


          系統級UI由原生統一實現

          前面提到了頁面的選擇,但頁面內的內容也是需要抉擇的,比如一些UI顯示控件(alert,toast等)

          雖然H5完成可以實現這些UI控件,并且可以和原生模擬的一樣,但是基于以下考慮,所有系統級的UI全部由原生實現并提供API:(原生和H5需統一風格)

          • 每一個合格的原生應用本身就會有一套自己風格的UI,因此不存在重復開發問題

          • H5本身可以實現這些組件,但是如果要模擬的和原生一摸一樣的話代價并不小,而且體驗并不能完全接近原生(比如遮罩無法覆蓋導航欄)

          • 如果是原生提供的,更改風格時原生改掉就行了,其它無效變動,如果H5單獨維護一套,那么就被迫一起同步,平白新增很多的工作量

          • 而且H5還會存在一些坐標、尺寸計算偏差問題

          一般情況下H5通過如下API即可調用

          quick.ui.toast('xxxx');
          quick.ui.alert('xxxx');
          
          quick.ui.alert({
              title: "標題",
              message: "信息",
              buttonName: "確定",
              success: function(result) {
                  // 點擊 alert的按鈕后回調
              },
              error: function(err) {}
          });
          



          頁面切換的轉場由原生實現

          一般PC瀏覽器中,頁面之間的調整直接通過a標簽完成(或者改變href跳轉), 但是這種跳轉有一個缺點:

          無法使用轉場動畫,每次都是干巴巴的等瀏覽器加載進度條,體驗很差

          因此針對這種情況,原生需要提供特點的API來供頁面調用,可以有原生轉場動畫,在新的webview中打開這個頁面

          quick.page.open({
              pageUrl: "./xxx.html",
              data: {
                  // 額外傳遞的數據
                  key1: 'value1'
              },
              success: function(result) {},
              error: function(error) {}
          });
          

          采用這種方式打開的頁面不再是在本webview中跳轉,而是直接用新的webview打開,有過渡動畫,而且以前的頁面仍然存在內存中,接近原生體驗

          譬如

          頁面A -> 頁面B -> 頁面C
          


          可以看到,如果是直接調整,頁面A和B是不存存在的,而是會被替換,但是采用原生webview打開后,三個頁面同時存在


          仍然支持第三方頁面的href跳轉

          雖然說可以有API打開的增強方式,但是仍然需要支持href跳轉,這在集成第三方頁面時十分重要(將已經寫好的第三方純網頁集成到容器中,作為某個子模塊)

          這里有一點需要注意:

          這類頁面一般由a標簽或href跳轉直接打開,沒有轉場動畫,但是需要webview容器保存訪問歷史記錄,
          以避免多次跳轉后一個后退就直接退出了整個模塊
          


          CPU密集型任務、底層的優化要由原生完成

          當涉及到一些大量計算時,盡量避免直接在網頁端完成,而是應該由原生提供API完成。

          譬如對一張圖片進行圖像處理(曝光、水印、壓縮等等),如果直接由網頁完成的話會發現非常卡,發熱也嚴重,而原生則沒有這么多的問題

          關于底層優化,其實整套混合開發框架中,底層容器的實現是核心部分

          容器是否健壯,優化的如何,直接影響整個應用的體驗

          關于原生容器應該如何進行優化,后續會有專門的文章,這里不贅述,只是稍微提及一下:

          • 支持H5頁面的離線訪問(有線上版本和離線版本,通過本地路由表映射)

          • 離線資源動態更新(結合離線訪問一起,比較復雜)

          • 資源緩存(如圖片的緩存,腳本樣式的緩存等)

          • 統一數據埋點采樣等(手機應用使用數據)

          • ajax請求等等(還有很多,不一一列舉)


          能用H5實現的就盡量不要用原生

          接下來就是在實際開發過程遵循的準則:

          • 能用H5實現的就盡量不要用原生

          乍看之下可能和上述的有矛盾,但其實又是合理的,在排除了一些不適合H5實現的頁面,剩余的絕大部分都是普通的業務頁面, 這類頁面基本可以毫無壓力的采用H5。

          所以,這時候,第一想法都是采用H5完成(因為一套代碼可以在至少三個平臺運行-瀏覽器,Android,iOS), 遇到一些比較困難的頁面再去考慮原生實現(從開發效率上,維護代價上,更新方便上都比較麻煩)

          那些H5開發中遇到最多的頁面

          最后,看下實際開發過程中遇到的最多的頁面吧(以實際遇到的N個項目的總結)

          • 列表頁面(下拉刷新,加載更多)

          • 純詳情展示頁面(標題,關鍵字,內容)

          • 九宮格首頁

          • 圖片輪播(時常結合列表和九宮格)

          • 標準的表單提交頁面

          沒錯,80%都是上述這種可以算非常簡單的頁面。

          譬如封裝過一個下拉刷新組件,基本別人基于這個組件來開發,列表的代碼幾乎是千篇一律。(當然了,剝離了業務邏輯而言)


          結束語

          時至今日,Hybrid模式已經過了它最火的時候,市面上也出現如weex,react-native等直接寫原生組件的框架 但是,現在使用最多,應用最廣的仍然要屬這種傳統的Hybrid模式,它已經進入了穩定期(可以說,傳統H5開發(泛概念)不被APP淘汰,這種模式很難被擠下舞臺)

          來源:http://www.dailichun.com  

          站長推薦

          1.阿里云: 本站目前使用的是阿里云主機,安全/可靠/穩定。點擊領取2000元代金券、了解最新阿里云產品的各種優惠活動點擊進入

          2.騰訊云: 提供云服務器、云數據庫、云存儲、視頻與CDN、域名等服務。騰訊云各類產品的最新活動,優惠券領取點擊進入

          3.廣告聯盟: 整理了目前主流的廣告聯盟平臺,如果你有流量,可以作為參考選擇適合你的平臺點擊進入

          鏈接: http://www.modern-decoration.com.cn/article/detial/281

          H5嵌入APP后,通過window.WebViewJavascriptBridge原生APP與H5之間交互

          原生APP跳轉到H5頁面時,往往需要攜帶一些用戶信息,之前做法是在跳轉的地址中拼接H5頁面需要的參數,現在通過window.WebViewJavascriptBridge悄悄的進行數據交互

          h5頁面的viewpoint

          只要寫手機端的h5頁面,viewpoint是繞不過的坎,不處理好這個東西,h5頁面就無法正常顯示。那它到底是怎么回事呢?網上曾看到一個據說很有名的外國人,寫過一篇\\\"三個viewpoint\\\"的概念,但是看了,覺得似懂非懂,后來做了不少h5頁面

          h5開發在ios瀏覽器遇到的坑

          click事件;在ios上,最后一個元素加margin-bottom無效;時間轉化問題;position: fixed中的input框聚焦軟鍵盤彈出,IOS下會有光標錯位問題;滾動穿透問題

          Android H5秒開方案調研—今日頭條H5秒開方案詳解

          文件下載耗時:包括html、css、js、圖片等;頁面渲染耗時:頁面渲染,解析js、css文件等;WebView創建耗時:首次創建WebView耗時大約需要500ms左右,第二次創建耗時大約需要20ms左右

          H5喚醒App之scheme方案

          在寫移動端頁面會遇到喚醒App的需求, 一般都是通過scheme協議喚起的,這里記錄一下,以新浪微博為例: 其協議為 sinaweibo://splash; 這些協議需要自己去收集

          H5活動頁面2小時快速開發

          這是一套我自己經常用的H5活動頁面開發腳手架,針對目前一般的H5頁面,基本上2小時就能完成相關的開發內容。俗話說:工欲善其事必先利其器,有了這么一套H5頁面腳手架,我相信80%的H5頁面,都能夠在2小時當中開發完成。

          H5頁面中喚起APP的方法

          需要在從APP分享出去的H5頁面中,帶有一個立即打開的按鈕,如果本地安裝了app,那么就直接喚起本地的app,如果沒有安裝,則跳轉到下載。這是一個很正常的推廣和導流量的策略。

          H5與企業微信jssdk集成

          注冊企業微信,在應用與小程序欄目中,設置可信域名,配置公眾號菜單。可信域名不得不說下,在最初開發時,認為設置并驗證后,微信認證接口會實現跨域請求,其實并沒有。所以全在H5端還得配合服務端完成票據獲取等操作。

          h5通過css實現禁止ios端長按復制選中文字的方法

          在ios端默認的長按選擇,可以對文字進行復制粘貼。但是在實際開發中,針對一些按鈕一般要避免長按時彈出選中文字,或者一些罩層要避免彈出。 這篇文章通過css3實現禁止ios端長按復制選中文字的方法

          如何在h5中調用支付寶支付功能

          如何在自己的H5頁面如何集成支付寶支付呢?目前采用前后端分離的開發模式,數據都是通過服務器那邊獲取的,現在需要集成支付寶支付,下面就簡單介紹下。

          內容以共享、參考、研究為目的,不存在任何商業目的。其版權屬原作者所有,如有侵權或違規,請與小編聯系!情況屬實本人將予以刪除!

          文章投稿關于web前端網站點搜索站長推薦網站地圖站長QQ:522607023

          小程序專欄: 土味情話心理測試腦筋急轉彎幽默笑話段子句子語錄成語大全運營推廣

          国产精品高清视频免费 - 视频 - 在线观看 - 影视资讯 - 唯爱网