背景

在移動端頁面中，由于屏幕空間有限，導航條扮演著非常重要的角色，提供了快速導航到不同頁面或功能的方式。用戶也通常會在導航條中尋找他們感興趣的內(nèi)容，因此導航條的曝光率較高。在這樣的背景下，提供一個動態(tài)靈活的導航條，為產(chǎn)品賦能，變得尤其重要。

使用原生導航欄現(xiàn)狀

拿iOS原生導航條為例，導航條作為頁面進出棧的根視圖連接器，以及生命周期的管理器。尤其是在作為webView Controller的父容器的時候，面對webview中h5頁面靈活的的路由屬性，以及一些難料的異常情況，原生很難也不便于頻繁操作根試圖容器，因此也產(chǎn)生了一些性能差、體驗差、開發(fā)成本高、測試場景難覆蓋等問題。安卓也有類似情況。

1、性能問題

?ssr預渲染時，無法對原生導航條進行預加載。對于百億，便宜包郵等使用ssr預渲染的頻道，因為原生導航欄無法進行預加載，導致上屏較慢等問題。

2、開發(fā)/測試成本高

?原生導航條生命周期耦合。原生導航條作為webviewController的根容器，一旦操作時機不當，很可能影響到線上頁面，而且最大的問題在于這種場景測試很難覆蓋。比如：window.href.url使用這種方式更新當前頁面時，由于不同頻道操作同一根導航條，會引發(fā)不可預知的問題；

?場景有限。站外場景無法使用原生導航條，一些業(yè)務方往往需要單獨處理站內(nèi)外，造成開發(fā)資源浪費。

3、體驗差

?webview初始化時會預置一個默認的導航條，然后根據(jù)前端配置，再去設置導航條的不同樣式，無法避免的存在一個過渡期，體驗較差。

?window.location.reload()刷新當前頁面的時候，即便是在js中隱藏了導航條，webview為了兼容一個線上問題，執(zhí)行reload時此時會先展示原生導航條，直到執(zhí)行了js的隱藏邏輯，才會被隱藏，體驗較差。

4、難擴展造成營銷資源浪費

?無法擴展交互動效。得益于移動端頁面中，導航條得天獨厚的位置，產(chǎn)品往往希望有更生動的交互性，來提高曝光、粘性、活動觸達率等。比如導航欄上掛載搜索框、以及吸頂、延伸動畫、沉浸式、炫酷的營銷icon等等。遺憾的是原生系統(tǒng)導航條不能全部支持，其實無論從視圖層級上來說，還是從導航條職責上來說，apple并不希望過多操作導航欄上的元素。也就造成了高曝光位置的資源浪費。

5、依賴性強

?因為要依賴原生JS橋，就一定會存在版本限制問題。造成需求迭代慢，甚至隨著時間的推移，版本卡口原因無跡可尋，代碼調(diào)整戰(zhàn)戰(zhàn)兢兢，版本審核慢、周期長等問題。

解決方案

基于原生導航條現(xiàn)狀，百億補貼頻道沉淀出了通用H5導航條組件@pango/navigation-bar，具有以下優(yōu)勢：

1、性能好

?支持ssr預渲染，上屏較快。

2、開發(fā)/測試成本低

?人力節(jié)省百分之90%以上，以plus 95折為例，對接只需0.5/人日。

?無場景限制?？捎糜谡緝?nèi)外，ssr以及csr場景，無需站內(nèi)外多次開發(fā)。

?可配置。 @pango/navigation-bar使用config的形式配置item，這么做的好處是一旦業(yè)務需求改動，只需調(diào)整配置，無需調(diào)整組件邏輯，極大降低開發(fā)和測試成本。另外如果你使用主站的webview并且配置了config，那么只需要簡單的改動config，代碼遷移成本低。

?導航條在頻道內(nèi)和其他普通樓層無異，生命周期隔離清晰，不會影響別的頁面，測試成本低。

?單向數(shù)據(jù)流設計，外部數(shù)據(jù)變化，組件UI及時響應，不存在原生的操作窗口問題，開發(fā)體驗佳；

3、用戶體驗好

?生命周期和其他樓層保持同步，規(guī)避了原生容器和H5頁面天然的生命周期無法同步的問題，也就不存在兩者之間的過渡問題，體驗佳。

4、靈活定制

?采用左、中、右、狀態(tài)欄、導航欄分層設計的模式，支持傳入React.ReactElement，比原生定制性更強，可靈活定制目前站內(nèi)絕大部分導航條樣式以及交互動畫，合理高效利用導航條資源；

5、機型、系統(tǒng)兼容性好

?參考原生導航欄異形屏適配方案，參考原生絕對布局思路，完美適配折疊屏、異形屏。

?iOS9 - 最新 、Android5 - 最新均兼容性良好，未發(fā)現(xiàn)線上兼容異常。

6、不對外依賴

純手工打造，未使用第三方庫，不會對宿主造成依賴沖突，隨時改動隨時發(fā)布不存在版本控制，最大程度的降低和隔斷對原生容器的版本依賴。

異常處理

原生導航條作為根試圖容器，容器內(nèi)子視圖異常不會影響根試圖的展示，所以不用特殊處理html下載失敗，js執(zhí)行異常，服務掛掉等異常情況。但是H5導航條遇到這些異常情況，也要保證用戶可以點擊返回按鈕返回上一頁。

百補方案

目前方案已和通天塔以及hybrid團隊打通，方案如下：

異常場景1：業(yè)務js執(zhí)行異常。

? @pango/navigation-bar組件使用a標簽渲染返回按鈕，保證js執(zhí)行異常時依然展示返回按鈕，并且能正常響應返回事件。

?業(yè)務展示兜底錯誤頁時，會使用導航條兜底數(shù)據(jù)渲染導航條確?？煞祷厣弦患?。

異常場景2：webview加載html失敗。

為了消除上面提到的過渡問題，業(yè)務鏈接中新增了qurey參數(shù)hideNavi=1 ，原生webview會通過該字段在webview出現(xiàn)之前隱藏導航條。但是因此也引發(fā)了一個風險：html加載失敗時，會造成無頭的問題。因此需要webview配合改造，一旦監(jiān)測到html加載失敗，原生webview要展示原生導航條。

異常場景3：通天塔服務異常。

同樣是場景2中的問題，需要通天塔配合改造通天塔服務異常的場景：依據(jù)鏈接中hideNavi字段添加返回按鈕或者通知webview展示默認導航條。

競品和兄弟頻道對比

觀察多個競品以及兄弟頻道，發(fā)現(xiàn)在上述的異常場景2、3下，均未做特別處理，展示無頭錯誤頁。如果此時原生禁用了右滑返回手勢，頁面將無法返回上一級，這無異是一個非常嚴重的缺陷（事實上有些競品頁面以及我們某些頻道確實無法返回上一級）。

線上項目

目前使用該組件的項目：百億補貼、月黑風高、PLUS95折。

線上成果展示

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ce5wngUS-1693195344487)(https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-08-24-10-11qEAz6FH44uxSFloN.gif)]

設計思路

參考原生navigationBar的設計思路，把整個導航欄分為左、右、中三個區(qū)域，左、右區(qū)域根據(jù)內(nèi)容自適應寬度，剩余空間為中間區(qū)域。左右區(qū)域接受items數(shù)組，可根據(jù)item接口協(xié)議設置左右的items，協(xié)議可自定義圖片、尺寸、事件、間距、下拉菜單、是否動畫響應等，已默認包含了關注、返回、更多、頻道logo等常用元素，當然如有需要也可以自定義一個React.ReactElement。中間區(qū)域只接受React.ReactElement，你可以自由定制元素，傳入navigation-bar即可，一張圖片一段文字，或者是一個搜索框……不管是伸縮或者是上滑吸頂，都可自定義。

@pango/navigation-bar

該組件使用react + ts開發(fā)，大小只有4.1K。

文件結構：

使用方式

安裝

npm i @pango/navigation-bar --registry=http://registry.m.jd.com

配置

你可以自由配置items除了"follow", "more","back","logo"，這些已知的元素外還可以設置type:"common"，是一個通用類型的item;

scrollCallBack會回調(diào)上滑比例，可根據(jù)該比例做交互動畫；

import {
  BACK_ICON,
  FEEDBACK_ICON,
  FEEDBACK_URL,
  INavigationParams,
  MORE_ICON,
  RULE_ICON,
  SHARE_ICON,
} from  "@pango/navigation-bar";

setH5NavigationButton = (headerData) => {
    const extend = headerData?.navigationBar?.extend;
    const followInfo = headerData?.navigationBar?.followInfo;

    const follow = {
      type: "follow",
      collectionId: String(followInfo?.themeId),
      gapWidth: 12,
      width: 55,
      height: 22,
    };

    const moreItem = {
      type: "more",
      menuBackgroundColor: "white",
      img: MORE_ICON,
      title: "更多",
      menuList: [],
      
    };

    moreItem.menuList.push({
      icon: RULE_ICON,
      title: "規(guī)則頁",
      menuEventData: extend?.guideUrl,
    });
    moreItem.menuList.push({
      icon: SHARE_ICON,
      title: "分享",
      type: "share",
      menuEventData: extend?.share,
    });

    const backItem = {
      type: "back",
      img: BACK_ICON,
      canClick: !margicWindow,
      title: "返回",
    };

    const backLogo = {
      type: "logo",
      img: DEFAULT_LOGO,
      isAnimation: true,
      gapWidth: 5,
      width: 176,
      height: 34
    };

    const navBarParams: INavigationParams = {
      leftItems: [],
      rightItems: [],
      backgroundColor: "#FD4D00",
      navHeight: this.status.navHeight,
    };
    navBarParams.leftItems.push(backItem， backLogo);    
    navBarParams.rightItems.push(moreItem, follow);
    navBarParams.titleImgItem = TitleSearch({});
    navBarParams.scrollCallBack = (scale) => {
      this.setStatus({
        navigationBarParams: Object.assign(this.status.navigationBarParams, {
          titleImgItem: TitleSearch({ isCollapse: scale === 1 })
        })
      });
    }
    return navBarParams;
  };

titleImgItem

特別注意titleImgItem，這個屬性是導航條中間區(qū)域的展示內(nèi)容，TitleSearch是百億補貼的搜索框，你可以參考該元素自定義中間區(qū)域。

掛載

import { INavigationParams, NavigationBar } from "@pango/navigation-bar";
import "@pango/navigation-bar/lib/navigation-bar.scss";
css
.nav-bar {
   width: 750px;
   z-index: 1;
   top: 0px;
 }

 <NavigationBar
    className="nav-bar"
    params={data.navParams}
    barHeight={200} //自定義導航欄高度
    event={do somethings}
  />

遇到了哪些問題

Q:若原生導航條隱藏，此時異常怎么辦？

異常分為以下3類：

異常場景1：業(yè)務js執(zhí)行異常。

? @pango/navigation-bar組件使用a標簽渲染返回按鈕，保證js執(zhí)行異常時依然展示該標簽，并且能正常相應出棧事件。

?業(yè)務展示兜底錯誤頁時，會使用導航條兜底數(shù)據(jù)渲染導航條。

異常場景2：webview加載html失敗。

為了消除上面提到的過渡問題，業(yè)務鏈接中新增了qurey參數(shù)hideNavi=1 ，原生webview會通過該字段在webview出現(xiàn)之前隱藏導航條。但是因此也引發(fā)了一個風險：html加載失敗時，會造成無頭的問題。因此需要webview配合改造，一旦監(jiān)測到html加載失敗，原生webview要展示原生導航條。

異常場景3：通天塔服務異常。

同樣是場景2中的問題，需要通天塔配合改造通天塔服務異常的場景：依據(jù)鏈接中hideNavi字段添加返回按鈕或者通知webview展示默認導航條。

若發(fā)現(xiàn)其他異常，麻煩提醒我。

Q:折疊屏怎么適配？

折疊屏適配一直是前端適配的噩夢，噩夢的根本原因在于：寬度于高度的比例非常值，前端布局是往往會把px轉(zhuǎn)換成vw，因此造成了異形屏適配難的問題。

?參考原生系統(tǒng)導航欄的絕對布局方案：@pango/navigation-bar把導航條拆分為狀態(tài)欄和導航欄上下兩部分， 導航條寬度屏幕自適應，導航條高度跟隨設備變化，并采用大寫的PX單位來固定元素尺寸。根據(jù)協(xié)議item寬高、間距仍可自定義，但是大寫的PX保證了item不會隨著屏幕寬度而異常變化。

navigation-bar {
        width: 750px; // 會轉(zhuǎn)換成vw
        height: 44PX; // 不會轉(zhuǎn)換成vw
        display: flex;
        position: absolute;
        .left-items-bg {
            margin-left: 16PX; // 不會轉(zhuǎn)換成vw
            height: 22PX;
            margin-top: 11PX;
            width: fit-content;
            display: flex;
            align-items: center;
            justify-content: center;
        }
}

Q:原生導航條優(yōu)化？

現(xiàn)狀中的幾個異常場景，仍需要webview配合一起整改，所以目前整改方案為：

業(yè)務鏈接中新增qurey參數(shù)hideNavi=1，此時 webview通過該字段在webview 出現(xiàn)之前隱藏導航條。由webview負責整改，跟版12.1.4。

開源計劃

經(jīng)安全部門審核之后，會向外開源。

迭代計劃

?導航條在移動端頁面中的重要性無需多言，我們最終的目的是面向全集團，和通天塔以及hybrid團隊，一起打造一根規(guī)范通用的H5導航欄，如果你在使用過程中發(fā)現(xiàn)一些我們沒有考慮到的異常場景或者設計規(guī)范，請與我聯(lián)系，我們共同完善。

?目前該組件下拉刷新還是要依賴原生的下拉刷新事件，后期會定制H5自己的下拉刷新。

?一個規(guī)范的UI組件應該是一個有嚴格UI設計規(guī)范的，比如間距，字體大小、圖片規(guī)范等。但是一期的設計中我們?yōu)榱遂`活，通過協(xié)議把UI把控留給了用戶，也希望后面的迭代開發(fā)中融入更多規(guī)范的設計語言。

作者：京東零售 張松超

來源：京東云開發(fā)者社區(qū) 轉(zhuǎn)載請注明來源文章來源地址http://www.zghlxwxcb.cn/news/detail-677233.html

到了這里，關于百億補貼通用H5導航欄方案 | 京東云技術團隊的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！