整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
讀一開始我們的H5頁面秒開率只有30%左右，現(xiàn)在我們的H5頁面秒開率達(dá)到了 75%。這中間巨大的差異究竟有哪些黑科技在里面？我們?yōu)槭裁匆鯤5頁面的秒開優(yōu)化？我們的秒開指標(biāo)是如何統(tǒng)計(jì)的？客戶端和H5是怎么配合做到 1+1>2的？監(jiān)控是如何發(fā)現(xiàn)H5頁面可優(yōu)化項(xiàng)的？我們又通過監(jiān)控發(fā)現(xiàn)了哪些可優(yōu)化的問題呢？
H5秒開優(yōu)化是一個(gè)老生常談的問題，本文將逐步介紹如何通過客戶端 + H5 的優(yōu)化手段（1+1>2）把秒開從 30% 提升到 75% ？后續(xù)接口預(yù)請(qǐng)求、客戶端預(yù)渲染以及預(yù)加載2.0上線后還會(huì)再次助力指標(biāo)提升。
為什么要做優(yōu)化？
Global Web Performance Matters for ecommerce 的報(bào)告中指出：
整體系統(tǒng)架構(gòu)圖：
首先講一下得物用來衡量秒開的指標(biāo) FMP，那為什么不選擇 FCP 或者 LCP 呢？FCP 只有要渲染就會(huì)觸發(fā)，LCP 兼容性不佳，得物希望站在用戶的角度來衡量秒開這件事情，用戶從點(diǎn)擊打開一個(gè)WebView到首屏內(nèi)容完整的呈現(xiàn)出來的時(shí)間點(diǎn)就是得物定義的FMP觸發(fā)時(shí)機(jī)。
指標(biāo)清楚了之后，再來看一下完整的 FMP 包含哪些耗時(shí)。
接下來將分為兩大部分進(jìn)行介紹，客戶端優(yōu)化部分和H5 優(yōu)化部分。
通過 HTML 預(yù)加載、HTML 預(yù)請(qǐng)求、離線包、接口預(yù)請(qǐng)求、鏈接?；睢㈩A(yù)渲染等手段提升頁面首屏打開速度，其中預(yù)加載、預(yù)請(qǐng)求、離線包分別可提升10%左右的秒開。
通過配置由客戶端提前下載好HTML主文檔，當(dāng)用戶訪問時(shí)直接使用已經(jīng)下載好的HTML文檔，以此減少HTML網(wǎng)絡(luò)請(qǐng)求時(shí)間，從而提升網(wǎng)頁打開速度。
前人栽樹后人乘涼，得物App有很多的資源位，banner、金剛位、中通位等，這些位置顯示什么內(nèi)容，早就已經(jīng)是智能推薦算法產(chǎn)出的了，那么就可以直接指定這些資源位進(jìn)行預(yù)加載。
頁面被預(yù)加載之后，總不能一直不更新吧？那么什么時(shí)候更新頁面的緩存呢？
被現(xiàn)實(shí)打臉：
但是在后面的灰度過程中被現(xiàn)實(shí)狠狠的教育了一頓，發(fā)現(xiàn)有些SSR的頁面會(huì)涉及到狀態(tài)的變更，比如說：領(lǐng)劵場景。這些狀態(tài)都是經(jīng)過SSR服務(wù)渲染好的，用戶在進(jìn)入頁面時(shí)還沒有領(lǐng)劵，這個(gè)時(shí)候去更新HTML文檔，實(shí)屬更新了個(gè)寂寞，在用戶領(lǐng)劵之后關(guān)閉頁面再次進(jìn)入，發(fā)現(xiàn)頁面中的狀態(tài)仍是讓用戶領(lǐng)劵，點(diǎn)擊領(lǐng)劵又告訴人家你已經(jīng)領(lǐng)過了。
改進(jìn)措施
至此問題也解決了，工程師的任務(wù)結(jié)束了嗎？如果你認(rèn)為功能做上去就算結(jié)束，那么此時(shí)此刻請(qǐng)你一定要轉(zhuǎn)變思維，想一想我們的目標(biāo)是什么？我們的目標(biāo)是「提升秒開」，預(yù)加載只是一種提升秒開的手段，但是在功能做上去之后并不知道這個(gè)功能帶來了多少秒開的收益，因此在把功能開發(fā)完成上線之后，就要開始關(guān)注上線之后的結(jié)果，來看看預(yù)加載的性能表現(xiàn)如何。從下圖可以看到，預(yù)加載開啟狀態(tài)下可提升10%以上的秒開率。
（1）SSR服務(wù)擴(kuò)容
要解決服務(wù)器壓力問題，很自然就會(huì)想到增加機(jī)器，于是我們對(duì)SSR機(jī)器數(shù)量做了一次擴(kuò)容，將機(jī)器數(shù)量提升了一倍，這個(gè)時(shí)候繼續(xù)嘗試擴(kuò)大預(yù)加載的用戶數(shù)量，但是仍然無法抗住這么大的QPS，而且此時(shí)還引發(fā)了第二個(gè)問題，算法部門的服務(wù)器發(fā)出了告警，于是放量計(jì)劃又一次遇到了阻礙。
（2）破局者 CDN
利用CDN 服務(wù)器的緩存能力既可以減輕 SSR 服務(wù)器的壓力又可以減少后端服務(wù)鏈路的壓力，這么好的東西為什么不用呢？這里留個(gè)懸念，后面將H5優(yōu)化部分會(huì)詳細(xì)介紹。
（3）客戶端配合改造
支持針對(duì)CDN域名進(jìn)行全部開放預(yù)加載能力，針對(duì)非CDN域名保持原有放量比例。
在這個(gè)過程中還分析了頁面的流量占比，發(fā)現(xiàn)開屏廣告來源的頁面流量占比也很高，那么是不是可以把開屏廣告的HTML文檔內(nèi)容也給預(yù)加載下來呢？
開屏頁面預(yù)加載策略
既然可以提前下載好HTML，那是不是可以更進(jìn)一步，提前把頁面內(nèi)的資源加載好，這樣在打開一個(gè)頁面的時(shí)候可以減少大部分的網(wǎng)絡(luò)請(qǐng)求從而更快速的把內(nèi)容呈現(xiàn)給用戶。這里還需要考慮如何跟下面講到的離線包進(jìn)行協(xié)作。
在WebView初始化同時(shí)，去請(qǐng)求HTML主文檔，等待HTML文檔下載完成 且 WebView初始成功后渲染，減少用戶等待時(shí)間，客戶端請(qǐng)求成功后，WebView加載本地 HTML，并保存以供下次使用。預(yù)請(qǐng)求HTML開啟狀態(tài)下可提升8%左右的秒開。
預(yù)請(qǐng)求 VS 預(yù)加載
本質(zhì)上HTML預(yù)加載和HTML預(yù)請(qǐng)求的區(qū)別就是下載HTML文檔的時(shí)機(jī)不同， 預(yù)加載是在App啟動(dòng)后用戶無任何操作的情況下就會(huì)去下載，但是預(yù)請(qǐng)求只會(huì)在用戶單擊打開H5頁面的時(shí)候才會(huì)去下載。如果用戶是第二次打開某個(gè)H5頁面，此時(shí)發(fā)現(xiàn)本地有已經(jīng)下載好的HTML且尚未過期就會(huì)直接使用，這個(gè)時(shí)候的行為表現(xiàn)就跟預(yù)加載的功能是一致的了。
上線之后發(fā)現(xiàn)預(yù)請(qǐng)求只提升了2%左右的秒開，經(jīng)過分析發(fā)現(xiàn)問題：
在本地用低端機(jī)對(duì)整個(gè)秒開耗時(shí)鏈路進(jìn)行了分析，為什么要用低端機(jī)分析呢？低端機(jī)有個(gè)好處，天然的加上了慢放功能，可以最大程度發(fā)現(xiàn)問題。
從圖中可以看出h5 頁面加載之前 耗時(shí) 分布在 activityStart() 函數(shù)，該函數(shù) 包含了 onCreateView ，其中耗時(shí)最長是 布局填充 inflate()，因?yàn)?WebView 對(duì)象是提前創(chuàng)建好的，直接從對(duì)象池中取出的，所以耗時(shí)主要在 初始化過程，WebView 自身的初始化 WebViewChromiumFactoryProvider. startYourEngines （耗時(shí) 87 us，不到 1 ms），耗時(shí)還有 WebView 的一些其他初始化，jockey 的初始化 等等。
而秒開的計(jì)算是包含了 View 初始化到 WebVIew url 加載 的耗時(shí)，從而發(fā)現(xiàn)了優(yōu)化點(diǎn)，可以將Webview loadUrl 前置，h5 頁面加載 與 原生布局填充并行執(zhí)行。在 onCreateView 時(shí)，創(chuàng)建 FrameLayout 進(jìn)行返回，執(zhí)行 WebView loadUrl 之后，主線程開始 對(duì)布局進(jìn)行 inflate，布局加載成功后，將其 addView 到 FrameLayout 中，減少了 loadUrl 的阻塞時(shí)長。中高端機(jī)型有 15ms 左右優(yōu)化，低端機(jī)型有 30 ~ 50 ms 優(yōu)化 效果。
預(yù)請(qǐng)求HTML時(shí)機(jī)是在進(jìn)入到 native 頁面中，這個(gè)時(shí)間點(diǎn)距離用戶單擊事件已經(jīng)過去100ms，那么是否可以將下載HTML的時(shí)機(jī)提前呢？經(jīng)過一番探索，最終選擇在路由階段進(jìn)行攔截，既可以統(tǒng)一收口而且距離用戶點(diǎn)擊的時(shí)間間隔可以忽略不計(jì)。通過這種方式將下載HTML時(shí)機(jī)提前了平均80ms+。
此時(shí)的流程變成了下面這樣。
可能有的同學(xué)會(huì)問了，為什么不在用戶點(diǎn)擊的時(shí)候去下載呢？從用戶點(diǎn)擊到路由肯定還是有耗時(shí)的。
在上述問題解決后，將緩存時(shí)間修改為1天，發(fā)現(xiàn)預(yù)請(qǐng)求HTML開啟狀態(tài)下可提升8%左右的秒開，已經(jīng)和預(yù)加載的效果相差不大了。
通過提前將H5頁面內(nèi)所需的css、js等資源聚合在一個(gè)壓縮包內(nèi)，由客戶端在App啟動(dòng)后進(jìn)行下載解壓縮，在后續(xù)訪問H5頁面時(shí)，匹配是否有本地離線資源，從而加速頁面訪問速度。
資源攔截這塊安卓這邊實(shí)現(xiàn)比較簡單，WebView支持 shouldInterceptRequest, 可以在該方法內(nèi)檢測是否需要進(jìn)行資源攔截，需要的話返回 WebResourceResponse 對(duì)象，不需要直接返回 null。
但是在iOS 這邊遇到了一些困難，調(diào)研了以下方案：
NSURLProtocol 攔截方式，使用WKBrowsingContextController和registerSchemeForCustomProtocol。通過反射的方式拿到了私有的 class/selector。通過把注冊(cè)把 http 和 https 請(qǐng)求交給 NSURLProtocol 處理。通過這種方式確實(shí)可以攔截請(qǐng)求，但是發(fā)現(xiàn)post請(qǐng)求的body會(huì)出現(xiàn)丟失的問題。而且NSURLProtocol一經(jīng)注冊(cè)就是全局開啟。我們希望他只會(huì)攔截接入了離線包的頁面，但是沒有辦法控制他，他會(huì)攔截所有頁面的請(qǐng)求，包括第三方合作頁面，顯然這是無法接受的。
在iOS 11及以上系統(tǒng)中, 擁有了加載自定義資源的API：WKURLSchemeHandler。
可以修改當(dāng)前頁面url為自定義 scheme 協(xié)議，比如：https://fast.dewu.com 修改為 duapp://fast.dewu.com 然后在客戶端內(nèi)注冊(cè)該 scheme，前端配合修改頁面內(nèi)所有的資源請(qǐng)求未自適應(yīng)協(xié)議，如：src="//fast.dewu.com/xxx" 就可以實(shí)現(xiàn)攔截。但是在測試過程中發(fā)現(xiàn)，接口為了安全起見只允許白名單內(nèi)的域名發(fā)起跨域請(qǐng)求，且無法配置多個(gè)域名，導(dǎo)致該方案無法繼續(xù)進(jìn)行。
仍然是使用 WKURLSchemeHandler 然后通過 hook WKWebview 的 handlesURLScheme 方法來支持 http 和 https 請(qǐng)求的代理。通過這種方式雖然可以攔截請(qǐng)求了，但是遇到了以下問題：
（1）body丟失問題
不過在 iOS 11.3 之后對(duì)這種情況做了修復(fù)處理，只有 blob 類型的數(shù)據(jù)會(huì)丟失。需要由JS來代理 fetch 和 XMLHttpRequest 的行為，在請(qǐng)求發(fā)起時(shí)將 body 內(nèi)容通過 JSBridge 告知 native，并將請(qǐng)求交給客戶端進(jìn)行發(fā)起，客戶端在請(qǐng)求完成后 callback js 方法。
（2）Cookie 丟失、無法使用問題
通過代理 document.cookie 賦值和取值動(dòng)作，交由客戶端來進(jìn)行管理，但是這里需要額外注意一點(diǎn)，需要做好跨域校驗(yàn)，防止惡意頁面對(duì)cookie進(jìn)行修改。
至此功能開發(fā)完成上線，先來一組線上收益數(shù)據(jù)，安卓開啟離線情況有有10%左右的收益，但是iOS開啟離線的反而秒開率更低。經(jīng)過修復(fù)處理后iOS也可提升10%以上的秒開。
安卓和iOS實(shí)現(xiàn)差異
經(jīng)過分析對(duì)比發(fā)現(xiàn)，安卓的攔截動(dòng)作比較輕，可以判斷是否需要攔截，不需要攔截可以交給WebView自己去請(qǐng)求。
但是iOS這邊一旦頁面開啟攔截后，頁面中所有的http和https請(qǐng)求都會(huì)被攔截掉，由客戶端發(fā)起請(qǐng)求進(jìn)行響應(yīng)，無法將請(qǐng)求交還給WebView自己去發(fā)起。
iOS 緩存問題修復(fù)
頁面中的資源經(jīng)過客戶端請(qǐng)求代理后原本第二次打開WebView本身會(huì)使用緩存的內(nèi)存，現(xiàn)在緩存也失效了，于是只能在客戶端內(nèi)實(shí)現(xiàn)了一套緩存機(jī)制。
從下圖可以看到離線包的下載錯(cuò)誤率在 6% 左右浮動(dòng)，這么高的下載錯(cuò)誤率肯定是無法接受的， 經(jīng)過一系列優(yōu)化手段，把離線包下載錯(cuò)誤率從6%左右浮動(dòng)下降至 0.3%左右浮動(dòng)。
先來看下優(yōu)化前的流程圖和問題點(diǎn)。
通過埋點(diǎn)發(fā)現(xiàn)大量 unknown host 、網(wǎng)絡(luò)請(qǐng)求失敗、網(wǎng)絡(luò)連接斷開的情況。分析代碼發(fā)現(xiàn)下載未做隊(duì)列控制，會(huì)同時(shí)并發(fā)下載多個(gè)離線包，從而導(dǎo)致多個(gè)下載任務(wù)爭搶資源的情況。針對(duì)發(fā)現(xiàn)的問題點(diǎn)做出了以下優(yōu)化：
下面是優(yōu)化之后的流程圖：
針對(duì)離線資源是直接存儲(chǔ)在磁盤上的，每次訪問都會(huì)有磁盤IO耗時(shí)，經(jīng)過在低端機(jī)器上做測試發(fā)現(xiàn)這個(gè)耗時(shí)會(huì)在 0 - 10ms 之間進(jìn)行波動(dòng)，后面會(huì)把內(nèi)存合理的利用起來，通過設(shè)置內(nèi)存上限，文件數(shù)量上限，甚至是文件類型，并通過 LRU 策略進(jìn)行內(nèi)存文件的淘汰更新。
通過客戶端發(fā)起H5頁面首屏接口請(qǐng)求，遠(yuǎn)比等待客戶端頁面初始化、下載HTML、JS下載執(zhí)行的時(shí)機(jī)更提前，從而節(jié)省用戶的首屏等待時(shí)間。在本地測試過程中發(fā)現(xiàn)接口預(yù)請(qǐng)求可提前100+ms，用戶也就可以更快的看到內(nèi)容。
客戶端會(huì)在App啟動(dòng)后獲取配置，保存支持預(yù)請(qǐng)求的頁面地址及對(duì)應(yīng)的接口信息，在用戶打開WebView時(shí)，會(huì)并行發(fā)起對(duì)應(yīng)預(yù)請(qǐng)求的接口，并保存結(jié)果。當(dāng)JS執(zhí)行開始獲取首屏數(shù)據(jù)時(shí)，會(huì)先詢問客戶端是否已經(jīng)存有對(duì)應(yīng)的響應(yīng)數(shù)據(jù)，如果此時(shí)已經(jīng)拿到數(shù)據(jù)則無需發(fā)起請(qǐng)求，否則 js 也會(huì)發(fā)起接口請(qǐng)求并開啟競速模式。以下是整體流程圖：
那么客戶端怎么知道這個(gè)頁面需要請(qǐng)求什么接口呢？以及接口的參數(shù)是什么呢？那自然少不了配置平臺(tái)，它支持以下功能：
首先即使是在 SSR 的情況下，首屏內(nèi)容中仍然可能有部分組件是骨架直出的，需要等待頁面渲染執(zhí)行時(shí)才會(huì)去請(qǐng)求數(shù)據(jù)，另外還有一部分頁面是SPA的。針對(duì)這兩種情況都能做到很好的補(bǔ)充。
開啟后DNS 90分位耗時(shí)從80ms降至0ms，TCP建連90分位耗時(shí)從65ms分位耗時(shí)降為0，DNS平均耗時(shí)從55ms降為4.3ms，TCP建連平均耗時(shí)從30ms降為2.5ms。
通過上圖可以看到一個(gè)網(wǎng)絡(luò)請(qǐng)求在經(jīng)過DNS解析耗時(shí)、TCP建連耗時(shí)、SSL建連耗時(shí)階段之后才能把請(qǐng)求發(fā)出去，那么是否可以節(jié)省這段時(shí)間的耗時(shí)呢？
客戶端常用的網(wǎng)絡(luò)請(qǐng)求框架如OkHttp等，都能完整支持http1.1與HTTP2的功能，也就支持連接復(fù)用。了解了這個(gè)連接復(fù)用機(jī)制優(yōu)勢(shì)，那就可以利用起來，比如在APP開屏等待的時(shí)候，就預(yù)先建立關(guān)鍵域名的連接，這樣進(jìn)入相應(yīng)頁面后可以更快的獲取到網(wǎng)絡(luò)請(qǐng)求結(jié)果，給予用戶更好體驗(yàn)。在網(wǎng)絡(luò)環(huán)境偏差的情況下，這種預(yù)連接理論上會(huì)有更好的效果。
可以通過對(duì)域名鏈接提前發(fā)起一個(gè)HEAD請(qǐng)求從而建立鏈接，網(wǎng)絡(luò)框架會(huì)自動(dòng)將連接放入連接池。并在默認(rèn)無操作5分鐘后進(jìn)行釋放，在五分鐘內(nèi)重復(fù)執(zhí)行上述動(dòng)作即可一直保持鏈接。
另外這里需要注意下連接池的數(shù)量問題，如果連接池的數(shù)據(jù)太小，但是域名比較多的話，通過預(yù)建連保持的鏈接很容易就會(huì)被釋放掉，這就需要通過域名收斂或者調(diào)大連接池的數(shù)量來進(jìn)行優(yōu)化。
那預(yù)建連會(huì)不會(huì)增加服務(wù)器的壓力呢？這個(gè)肯定是會(huì)的，首先會(huì)針對(duì)預(yù)建連功能本身就行灰度策略，在HTML頁面通過CDN托管后，直接針對(duì) cdn 域名進(jìn)行全量開啟，從而不用擔(dān)心 cdn 域名扛不住壓力。
來看一下線上效果，通過下圖可以看到在開啟后DNS 90分位耗時(shí)從80ms降至0ms，TCP建連90分位耗時(shí)從65ms分位耗時(shí)降為0，DNS平均耗時(shí)從55ms降為4.3ms，TCP建連平均耗時(shí)從30ms降為2.5ms。
客戶端提前通過WebView將頁面渲染好，等待用戶訪問時(shí)，可直接展示。從而達(dá)到瞬開效果。但是這種功能肯定不能對(duì)所有的頁面進(jìn)行開放，而且存在一定的弊端。
下圖【開學(xué)季】是業(yè)務(wù)上已經(jīng)進(jìn)行預(yù)渲染的H5頁面，可以看到在打開【開學(xué)季】頁面時(shí)，頁面已經(jīng)渲染完畢，絲毫沒有等待過程。
后面計(jì)劃把這種能力放大到通用的webview上，針對(duì)大促以及PV量高的頁面進(jìn)行開放。
SSR服務(wù)端渲染（英語：server side render）一般情況下，一個(gè)H5頁面的數(shù)據(jù)渲染完全由客戶端來完成，先通過AJAX請(qǐng)求到頁面數(shù)據(jù)并把相應(yīng)的數(shù)據(jù)填充到模板，形成完整的頁面來呈現(xiàn)給用戶。而服務(wù)端渲染把數(shù)據(jù)的請(qǐng)求和模板的填充放在了服務(wù)端，并把渲染的完整的頁面返回給客戶端。
SSR對(duì)于秒開有平均15%的提升，既然是服務(wù)端渲染，就會(huì)對(duì)服務(wù)器造成壓力，尤其是在預(yù)加載HTML功能開啟后，那得物是如何解決的呢？
通過這么多優(yōu)化手段仍然無法滿足預(yù)加載的需求，并且通過分析發(fā)現(xiàn)網(wǎng)絡(luò)階段耗時(shí)較長，最終還是搬出了CDN這個(gè)大殺器，一直沒上CDN的原因有很多，主要有以下幾方面：
（1）得物的頁面是千人千面的每個(gè)人看到的內(nèi)容都不同
通過上述優(yōu)化4即可解決，將原本SSR渲染的內(nèi)容修改CSR，由于已經(jīng)上了CDN了，后續(xù)計(jì)劃將這部分內(nèi)容再次修改回SSR，這樣用戶可以更快的看到商品而不是骨架，然后通過 CSR 的方式來更新內(nèi)容。
（2）頁面狀態(tài)變更，無法及時(shí)更新緩存
這個(gè)問題在上述客戶端預(yù)加載優(yōu)化部分已經(jīng)有解決方案了，可以通過在頁面打開后針對(duì)有需要的組件再次請(qǐng)求接口刷新數(shù)據(jù)以確保數(shù)據(jù)的準(zhǔn)確性，但是這部分工作量也是比較大的，梳理出來的需要刷新狀態(tài)的組件就有30+，而且之后開發(fā)的組件都需要考慮狀態(tài)更新的事情。
（3）HTML模板內(nèi)容變更無法及時(shí)更新
引起模板內(nèi)容變更的地方有兩處，第一個(gè)場景就是在搭建器場景下，運(yùn)營可以動(dòng)態(tài)修改模板內(nèi)容導(dǎo)致頁面結(jié)構(gòu)變更（低頻次），第二個(gè)場景是項(xiàng)目發(fā)版后模板內(nèi)容需要更新（高頻）。
這個(gè)問題可以通過在感知到內(nèi)容變更時(shí)自動(dòng)調(diào)用CDN服務(wù)商的刷新緩存接口來更新CDN緩存內(nèi)容。
通過puppeteer將SPA頁面渲染出來并將HTML文檔進(jìn)行保存，配合上述頁面刷新策略，并將HTML通過CDN進(jìn)行托管，讓你的 SPA 頁面 像 SSR 一樣絲滑。
主要實(shí)現(xiàn)方案是通過基于webpack的插件prerender-spa-plugin，并配置需要預(yù)渲染的路由，這樣經(jīng)過打包之后就會(huì)產(chǎn)出對(duì)應(yīng)路由的頁面。方案本身是通用的，但是每接入一個(gè)頁面都需要人工check。
眾所周知 css 加載會(huì)阻塞HTML渲染，最終將首屏公共css從118kb縮減至38kb，下圖通過 chrome 模擬弱網(wǎng)環(huán)境下的SSR頁面加載時(shí)序圖。從圖中可以看出 styles.fb201fce.chunk.css 下載耗時(shí) 18s，阻塞了頁面的渲染，HTML 主文檔耗時(shí) 2.38s 就已經(jīng)下載完成了，但是實(shí)際渲染時(shí)間卻是在 20s 之后。
優(yōu)化思路也比較單間，將首屏所需要的css 文件通過內(nèi)聯(lián)方式內(nèi)嵌到HTML中，由SSR服務(wù)一并返回，并對(duì)css文件進(jìn)行拆分，按需加載。
思路有了，接下來就看怎么去實(shí)現(xiàn)了，最初嘗試了MiniCssExtractPlugin 插件他可以把css分成單獨(dú)的文件，并且每一個(gè)js會(huì)對(duì)應(yīng)生成一個(gè)css文件，但是他需要建立在webpack5之上，然而項(xiàng)目中使用的next版本是9.5，于是就想著升級(jí)到最新版next12，升級(jí)后發(fā)現(xiàn)，在構(gòu)建中其他包各種報(bào)錯(cuò)，發(fā)現(xiàn)有些包并不支持最新的next12，在嘗試一天的修復(fù)之后，仍未解決，且升級(jí)到最新版不確定是否會(huì)引發(fā)其他穩(wěn)定性問題，暫且擱置尋找其他方法。
經(jīng)過不懈的努力，通過閱讀 next 源碼發(fā)現(xiàn)了端倪，發(fā)現(xiàn)在打包時(shí)將所有的公共css通過 splitChunks 進(jìn)行分組，由于項(xiàng)目中組件都是動(dòng)態(tài)引入的，這里直接在 next.config.js 中修改webpack打包參數(shù)，將 splitChunks.cacheGroups.styles 配置刪除，使用默認(rèn)的 chunks: async 配置，即可實(shí)現(xiàn)按需引入。
（1）避免圖片src為空
雖然src屬性為空字符串，但瀏覽器仍然會(huì)向服務(wù)器發(fā)起一個(gè)HTTP請(qǐng)求，尤其是在SSR服務(wù)器壓力扛不住的情況下，因此這里需要特別注意一下。
（2）圖片壓縮以及格式選擇
WebP 的優(yōu)勢(shì)體現(xiàn)在它具有更優(yōu)的圖像數(shù)據(jù)壓縮算法，能帶來更小的圖片體積，而且擁有肉眼識(shí)別無差異的圖像質(zhì)量；同時(shí)具備了無損和有損的壓縮模式、Alpha 透明以及動(dòng)畫的特性，在 JPEG 和 PNG 上的轉(zhuǎn)化效果都相當(dāng)優(yōu)秀、穩(wěn)定和統(tǒng)一。
通過向圖片服務(wù)器傳遞參數(shù)選擇合適的分辨率。
（1）打包優(yōu)化
（2）非關(guān)鍵js、css延遲加載
（3）媒體資源加載優(yōu)化
（4）其他資源優(yōu)化
（5）頁面渲染優(yōu)化
（6）代碼層面優(yōu)化
為了幫助開發(fā)者更好地衡量和改進(jìn)前端頁面性能，W3C性能小組引入了 Performance API ，其中Navigation Timing API 實(shí)現(xiàn)了自動(dòng)、精準(zhǔn)的頁面性能打點(diǎn)。得物前端性能監(jiān)控指標(biāo)也都是從 Performance API 中獲取數(shù)據(jù)進(jìn)行上報(bào)統(tǒng)計(jì)分析的。
SDK 數(shù)據(jù)采集完畢后，會(huì)上報(bào)到 阿里云 sls 日志平臺(tái)，隨后通過 flink 實(shí)時(shí)消費(fèi)清洗數(shù)據(jù)后落庫至 clickhouse 中，平臺(tái)后端通過讀取 clickhouse 數(shù)據(jù)并做各種聚合處理后使用。
做優(yōu)化之前首先要建立監(jiān)控指標(biāo)，互聯(lián)網(wǎng)稱之為抓手，沒有監(jiān)控指標(biāo)的情況下，任你怎么優(yōu)化，都不知道優(yōu)化的效果怎么樣，更不知道下一步該做什么？以及還有哪些問題沒解決。因此優(yōu)化之前指標(biāo)先行，當(dāng)然一定要指標(biāo)的準(zhǔn)確性。
指標(biāo)大盤主要包含以下功能：
在正常情況下，完成上述的優(yōu)化措施后用戶基本是可以秒開 H5 頁面的了。但異常情況總是會(huì)有的，用戶的網(wǎng)絡(luò)環(huán)境和系統(tǒng)環(huán)境千差萬別，甚至 WebView 也可能發(fā)生內(nèi)部崩潰。當(dāng)發(fā)生問題時(shí)，用戶看到的可能就直接只是一個(gè)白屏頁面了，所以進(jìn)一步的優(yōu)化手段就是需要去檢測是否發(fā)生白屏以及相應(yīng)的應(yīng)對(duì)措施。
檢測白屏最直觀的方案就是對(duì) WebView 進(jìn)行截圖，遍歷截圖的像素點(diǎn)的顏色值，如果非純色的顏色點(diǎn)超過一定的閾值，就可以認(rèn)為不是白屏。首先獲取包含 WebView 視圖的 Bitmap 對(duì)象，然后把截圖縮小到指定的分辨率大小如:100*auto，遍歷檢測圖片的像素點(diǎn)，當(dāng)非純色的像素點(diǎn)大于 5% 的時(shí)候就可以認(rèn)為是非白屏的情況，但是還有很多列外的情況，我們通過圖片識(shí)別技術(shù)對(duì)截圖進(jìn)行分析，可以很好的感知當(dāng)前是否白屏、是不是在loading、是不是特殊頁面等。
白屏是一個(gè)重要的指標(biāo)，我們針對(duì)整體白屏率快速拉升、新增白屏頁面發(fā)出告警通知，便于開發(fā)人員及時(shí)介入開始排查問題。
主要通過 CDN 未覆蓋監(jiān)控、http請(qǐng)求監(jiān)控、網(wǎng)絡(luò)監(jiān)控（加載失敗、耗時(shí)異常、傳輸大小異常）、圖片監(jiān)控（未壓縮、分辨率異常）等監(jiān)控手段發(fā)現(xiàn)頁面中的潛在問題，同時(shí)還提供了問題分析能力，在問題分析頁面輸入頁面url地址即可幫助您發(fā)現(xiàn)問題并給出修改建議。
CDN的重要性不言而喻，它可以加速資源訪問速度，從而提升用戶體驗(yàn)，我們通過對(duì)線上埋點(diǎn)數(shù)據(jù)分析，找出CDN未覆蓋的資源列表，從而推動(dòng)各業(yè)務(wù)同學(xué)優(yōu)化。
為什么要監(jiān)控HTTP請(qǐng)求呢？我們先來看一下HTTPS相對(duì)于HTTP新增的特點(diǎn)：
那么HTTP就容易被中間人查看到內(nèi)容，甚至被篡改，既然如此為了我們服務(wù)的安全性就需要對(duì)現(xiàn)有的http協(xié)議統(tǒng)一進(jìn)行升級(jí)改造，那就需要監(jiān)控去發(fā)現(xiàn)。
某些頁面秒開率低，那就要分析一下原因，是不是這個(gè)頁面的接口響應(yīng)比較慢呢，還是說頁面本身有請(qǐng)求比較大的資源？如果發(fā)生網(wǎng)絡(luò)請(qǐng)求失敗的情況也要第一時(shí)間感知，不能被動(dòng)等待用戶反饋。
包含圖片未壓縮、圖片分辨率異常、圖片傳輸大小大于 300kb 異常、動(dòng)圖資源傳輸大小大于 1M 異常功能。
上面列出來一堆功能，對(duì)于業(yè)務(wù)的同學(xué)可能比較煩惱，我一個(gè)頁面具體有哪些問題呢？你不能讓我去上面的功能里面一個(gè)個(gè)看，哪個(gè)異常是我負(fù)責(zé)的頁面的吧？這個(gè)功能本身就行將現(xiàn)有的功能利用起來，通過一個(gè)頁面path進(jìn)行聚合分析。
H5異常一直是使用 sentry 進(jìn)行監(jiān)控的，但是sentry系統(tǒng)因缺乏同PV、DAU數(shù)據(jù)的關(guān)聯(lián)性，因此無法衡量產(chǎn)品異常發(fā)生后所帶來的嚴(yán)重程度。在業(yè)務(wù)域關(guān)聯(lián)上的缺失導(dǎo)致異常問題無法根據(jù)業(yè)務(wù)域進(jìn)行劃分。用戶行為日志也尚未與Native 端側(cè)打通，在問題分析時(shí)容易遇到上下文不全的瓶頸。還有一個(gè)問題是sentry會(huì)有限流措施，當(dāng)qps較高時(shí)會(huì)丟棄一部分異常數(shù)據(jù)。
由于sentry已經(jīng)可以幫助我們進(jìn)行一定的問題排查分析能力，我們不打算做sentry同樣的功能，而是做sentry不支持的部分，針對(duì)上述問題我們?cè)O(shè)計(jì)了以下功能：
雖然目前秒開率已經(jīng)做到了75%以上，但是同時(shí)我們還有一個(gè)重要的指標(biāo)，90分位耗時(shí)，致力于提升末尾用戶H5頁面使用體驗(yàn)，在90分位優(yōu)化完成后，可能會(huì)考慮繼續(xù)深入優(yōu)化95分位耗時(shí)。
至此我們系統(tǒng)的講解了背景以及從指標(biāo)建立到秒開優(yōu)化上線的全過程，全文分成了三個(gè)部分，客戶端、H5、以及監(jiān)控。如果閱讀本文對(duì)您有所收獲，麻煩您動(dòng)一動(dòng)發(fā)財(cái)?shù)男∈贮c(diǎn)個(gè)贊吧！如果閱讀完還意猶未盡或者有什么問題和想法歡迎留言區(qū)評(píng)論交流。
最后奉上整體優(yōu)化腦圖：
*文/徐銘
歡迎關(guān)注「得物技術(shù)」微信公眾號(hào)，每周一三五晚18:30更新技術(shù)干貨
要是覺得文章對(duì)你有幫助的話，歡迎評(píng)論轉(zhuǎn)發(fā)點(diǎn)贊～
于OZON的產(chǎn)品詳情頁來說，有兩種形式來表達(dá)，分別是：純文本和富文本形式。這兩種形式可以共存，關(guān)于富文本Json的內(nèi)容可以查看歷史文章：https://kuajing365.cn/document/4516.html
那么這篇文章主要給大家介紹一下純文本部分的內(nèi)容應(yīng)該寫哪些？
如下圖所示：純文本填寫的內(nèi)容在特征頁面填寫。
審批通過的產(chǎn)品的詳情頁的描述會(huì)出現(xiàn)在產(chǎn)品頁面如下圖所示位置：
那么關(guān)于產(chǎn)品詳情頁這里，我們主要應(yīng)該放哪些信息呢：
1、產(chǎn)品的核心關(guān)鍵詞：這里也要出現(xiàn)產(chǎn)品的關(guān)鍵詞，要將產(chǎn)品詞以及核心修飾詞、屬性詞放進(jìn)去。通常會(huì)以句子的形式完成，比如說：這是一雙非常輕便的女士跑步鞋。
2、產(chǎn)品的優(yōu)點(diǎn)或者特點(diǎn)：在這里要將產(chǎn)品的優(yōu)勢(shì)羅列出來，起到打動(dòng)買家的作用。
3、產(chǎn)品的尺寸、顏色、容量等特征：一般來說，在描述的下方會(huì)有特征模塊。不過在這里可以適當(dāng)將產(chǎn)品的重要屬性列出來。
4、品牌故事或者產(chǎn)品故事：如果你的產(chǎn)品是有品牌的，那么完全可以在這里講一個(gè)故事，或者圍繞產(chǎn)品設(shè)計(jì)一段話。如上圖所示的例子，就是專門針對(duì)這個(gè)拖鞋設(shè)計(jì)了一段文案，這個(gè)文案可以成為通用文案！那么對(duì)于俄羅斯用戶來說，這種方式會(huì)起到情感共鳴的作用，有效提升轉(zhuǎn)化率！
當(dāng)然，描述信息這里與標(biāo)題一樣，同樣有一些注意事項(xiàng)：不能描述臟話，不能包含以下非必要的推廣營銷信息，比如：“促銷”、“銷售”、“新奇”、“折扣”、“僅限今天”等詞；產(chǎn)品價(jià)格；短語“最佳產(chǎn)品”、“獨(dú)特產(chǎn)品”、“驚人產(chǎn)品”等；配送信息；不需要堆砌關(guān)鍵詞！
綜上所述，差不多從這四個(gè)方面來寫描述即可，也不用寫的太多，無論是哪個(gè)國家用戶，對(duì)于大段文字其實(shí)都是缺乏耐心的！所有更多還是需要配合jason富內(nèi)容來優(yōu)化詳情頁，提升整體支付轉(zhuǎn)化率！
文介紹了制定產(chǎn)品設(shè)計(jì)規(guī)范標(biāo)準(zhǔn)的重要性，也包括行業(yè)對(duì)于高級(jí)產(chǎn)品經(jīng)理的要求，并以幾點(diǎn)詳細(xì)介紹，包括了制定標(biāo)準(zhǔn)的共同目標(biāo)、基礎(chǔ)要素、設(shè)計(jì)原則、規(guī)范制定的流程以及如何推動(dòng)規(guī)范的執(zhí)行等。適合產(chǎn)品崗位的你閱讀。
每一款產(chǎn)品，都會(huì)有它的產(chǎn)品設(shè)計(jì)規(guī)范。例如支付寶小程序，微信小程序，有它的設(shè)計(jì)風(fēng)格和交互的審核要求。
而適用于移動(dòng)應(yīng)用以及Web設(shè)計(jì)，可以參考Material Design（Google），強(qiáng)調(diào)直觀性、一致性和有意義的動(dòng)效設(shè)計(jì)。
如果你是ios產(chǎn)品，那首先就得去了解Human Interface Guidelines（Apple），再基于這個(gè)設(shè)計(jì)規(guī)范制定符合平臺(tái)的標(biāo)準(zhǔn)，最通用，最基礎(chǔ)的，就當(dāng)屬M(fèi)icrosoft Design Guidelines，適用于Windows平臺(tái)的設(shè)計(jì)規(guī)范，強(qiáng)調(diào)平面化、簡潔和直觀的設(shè)計(jì)風(fēng)格。
為什么要制定產(chǎn)品的規(guī)范標(biāo)準(zhǔn)？
制定產(chǎn)品的規(guī)范標(biāo)準(zhǔn)可以提高產(chǎn)品的一致性、可用性和用戶體驗(yàn)，幫助建立品牌形象、提升用戶滿意度，并為團(tuán)隊(duì)提供明確的指導(dǎo)，提高工作效率和協(xié)作效果。
行業(yè)對(duì)于高級(jí)產(chǎn)品經(jīng)理的要求:
在講這篇內(nèi)容之前，先容許我把之前的幾篇文章給大家同步一下，感興趣的小伙伴或者遇到瓶頸的小伙伴一定要看，我相信會(huì)對(duì)你們的提升帶來很大的幫助，內(nèi)容很長，建議先收藏。
我們先來簡單的對(duì)規(guī)范標(biāo)準(zhǔn)有個(gè)概念，有很多小伙伴都總是會(huì)在這兩個(gè)詞進(jìn)行拉扯，但其實(shí)這兩個(gè)詞加起來就代表了準(zhǔn)則。而規(guī)范則是基于標(biāo)準(zhǔn)之下，如支付寶小程序，它的設(shè)計(jì)規(guī)范，對(duì)于我們來講，就是平臺(tái)的設(shè)計(jì)標(biāo)準(zhǔn)，我們基于這個(gè)標(biāo)準(zhǔn)下再去制定屬于自己產(chǎn)品的設(shè)計(jì)規(guī)范。
那我們現(xiàn)在來看看，標(biāo)準(zhǔn)和規(guī)范在文學(xué)上的區(qū)別為：意思不同、出處不同。
① 意思不同
② 出處不同
規(guī)范要求和標(biāo)準(zhǔn)的區(qū)別：
③ 成因不同
接下來，我們開始今天的主要內(nèi)容。小編會(huì)通過三個(gè)篇章，七個(gè)章節(jié)，給大家提供落地的方法。
倘若你目前剛好處在對(duì)于制定產(chǎn)品的規(guī)范標(biāo)準(zhǔn)無從下手的階段，以下內(nèi)容絕對(duì)能夠讓你按部就班的完成；假如你已經(jīng)為多個(gè)平臺(tái)制定過標(biāo)準(zhǔn)，也可以參考本篇內(nèi)容，思考下有沒有進(jìn)步的空間；假如你從來沒接觸也沒有機(jī)會(huì)制定，那么，這篇文章就是你的敲門磚。
小編總結(jié)了十點(diǎn)，先給大家介紹一下，我們?yōu)槭裁匆プ鲞@個(gè)事情，這個(gè)事情給我們帶來什么價(jià)值。
作為產(chǎn)品，我們必須要清楚一個(gè)原則在于：我們做的任何事情，都得有它的價(jià)值，要清楚它的目的再去做，拒絕為了做而做的行為，切勿讓自己變成了傳聲筒。
綜上所述，制定產(chǎn)品的設(shè)計(jì)規(guī)范標(biāo)準(zhǔn)可以帶來許多益處，包括提升用戶體驗(yàn)、降低開發(fā)成本、增強(qiáng)品牌形象和改善團(tuán)隊(duì)協(xié)作。
規(guī)范的制定和執(zhí)行有助于打造出一致、優(yōu)質(zhì)的產(chǎn)品，提高用戶滿意度和市場競爭力。
產(chǎn)品設(shè)計(jì)的常識(shí)（Common Sense），很多時(shí)候都會(huì)被忽略，特別一些小型項(xiàng)目。研發(fā)人員會(huì)在初期嫌麻煩不對(duì)一些常識(shí)的問題進(jìn)行處理，最終導(dǎo)致的影響，往往是影響到產(chǎn)品的本身。
產(chǎn)品一定要把控好這個(gè)關(guān)卡，誰都可以不懂，產(chǎn)品一定要最清楚最基本的就是系統(tǒng)異常處理設(shè)計(jì)規(guī)范能夠有效解決且避免以下七點(diǎn)：
產(chǎn)品設(shè)計(jì)是否保持一致很容易反映出一個(gè)產(chǎn)品經(jīng)理做事情的嚴(yán)謹(jǐn)性。有不少產(chǎn)品經(jīng)理設(shè)計(jì)產(chǎn)品很隨意，抱著“能用就行”的態(tài)度做設(shè)計(jì)，結(jié)果就會(huì)出現(xiàn)整個(gè)產(chǎn)品的一致性非常差。
比如，列表的添加按鈕一會(huì)在頁面的右上角，一會(huì)在頁面的左上角，搞得用戶使用不同的頁面像是在玩“躲貓貓”游戲一般，學(xué)習(xí)成本非常高。
再比如移動(dòng)端，有些頁面使用長按刪除，有的使用向左滑動(dòng)刪除，還有的需要點(diǎn)擊“…”在彈層中點(diǎn)擊刪除……同一個(gè)產(chǎn)品，多種交互形式也會(huì)讓用戶困惑。
至此，產(chǎn)品的規(guī)范標(biāo)準(zhǔn)入門篇已經(jīng)跟大家介紹完了。大家在做任何一個(gè)項(xiàng)目的時(shí)候，都應(yīng)該注意入門篇的兩個(gè)章節(jié)，究竟有沒有做到位，有沒有制定規(guī)范標(biāo)準(zhǔn)同步到設(shè)計(jì)，研發(fā)。
入門篇基本滿足大部門從0-1的項(xiàng)目，或者是初中級(jí)的產(chǎn)品經(jīng)理所需要掌握的技能，建議大家收藏起來。如果遇到這類任務(wù)的時(shí)候，就可以以這篇文章，作為你們的任務(wù)List，一項(xiàng)一項(xiàng)對(duì)應(yīng)的去檢查是否有做到位。那么我相信你們吹來的作品，一定是具備一定的專業(yè)度，一致性以及可延展性的。
在入門篇開始之前，先給大家交個(gè)底。我們?cè)谥贫óa(chǎn)品入門篇的規(guī)范標(biāo)準(zhǔn)時(shí)，有一個(gè)部門必須拉他們參與進(jìn)來，那就UI部。UI部門在入門篇的環(huán)節(jié)，起到了決定性的作用，由他們?yōu)橹鲗?dǎo)，我們?yōu)檩o助的方式，達(dá)成一致性的決定。
這一個(gè)環(huán)節(jié)，最重要的目的是讓產(chǎn)品與UI保持同頻，大家都在統(tǒng)一規(guī)范標(biāo)準(zhǔn)下進(jìn)行設(shè)計(jì)，為產(chǎn)品添磚加瓦。而且通常我們都會(huì)把這個(gè)環(huán)節(jié)以一個(gè)功能模塊級(jí)別的需求去做，也有這個(gè)需求的版本，持續(xù)優(yōu)化迭代。
當(dāng)然，需要優(yōu)化迭代的時(shí)候，那就應(yīng)該是由產(chǎn)品為主導(dǎo)，在原有的標(biāo)準(zhǔn)下，再去優(yōu)化規(guī)范，最終形成新一版的規(guī)范標(biāo)準(zhǔn)。
這個(gè)環(huán)節(jié)也是能夠讓產(chǎn)品在與UI溝通上的成本減少，在同頻基礎(chǔ)下工作也有利于減少兩個(gè)部門之間的摩擦。
相信大家應(yīng)該也聽說過交互設(shè)計(jì)師這個(gè)崗位，大多數(shù)在中小型企業(yè)很難有資源去匹配這個(gè)崗位，一般都是在成熟的互聯(lián)網(wǎng)公司會(huì)有這個(gè)崗位的需求。
通過這么個(gè)規(guī)律我們也可以發(fā)現(xiàn)：需要注重交互設(shè)計(jì)，往往到了產(chǎn)品已經(jīng)扎根土地，茁壯成長的階段。
相對(duì)比較穩(wěn)定的時(shí)候就會(huì)開始考慮這個(gè)問題，但并不代表說，交互設(shè)計(jì)不重要。交互設(shè)計(jì)對(duì)于產(chǎn)品來言，在做需求時(shí)，靠的是經(jīng)驗(yàn)，靠的是競品分析，靠的是借鑒。
看到這里的小伙伴們，自動(dòng)自覺對(duì)號(hào)入座，往往一味的靠經(jīng)驗(yàn)，靠競品，靠借鑒，只會(huì)讓產(chǎn)品的交互五花八門，沒有一個(gè)體系。單個(gè)功能抽出來可能是合理的，方便的；但全部湊在一起的時(shí)候，倘若需要用戶去適應(yīng)，那么就適得其反。
因此，我們產(chǎn)品就需要UI同學(xué)幫忙一起制定出產(chǎn)品交互設(shè)計(jì)規(guī)范，而產(chǎn)品本身，也應(yīng)該有一套自己的標(biāo)準(zhǔn)，把控好產(chǎn)品的交互，這樣才有利于產(chǎn)品的發(fā)展。
接下來，我會(huì)通過收集一些常見的交互問題，給大家用實(shí)例去介紹產(chǎn)品交互設(shè)計(jì)規(guī)范如何制定。
1）做一個(gè)頁面交互設(shè)計(jì)的時(shí)候要注意什么？
2）如何理解模態(tài)框？
何時(shí)應(yīng)該使用模態(tài)框？模態(tài)框和阻斷框有什么區(qū)別？
模態(tài)對(duì)話框(Modal DialogueBox) ，阻斷(Blocking），可以用兩個(gè)比喻給大家解釋：
3）在具體設(shè)計(jì)一個(gè)產(chǎn)品的過程中，把握住哪些關(guān)鍵點(diǎn)才能讓整個(gè)產(chǎn)品有著一致的交互體驗(yàn)，或者交互模式？比如iOS端和android端，比如web端和移動(dòng)端？
一致性，在交互設(shè)計(jì)中非常重要！保持交互一致性，有兩個(gè)武器：原則和規(guī)范。
規(guī)范又有兩個(gè)層面：指南Guidelines和規(guī)格
原則
一些指導(dǎo)性的東西，在設(shè)計(jì)當(dāng)中要遵從。在整個(gè)產(chǎn)品（無論多少端，多少子產(chǎn)品）都要遵守的。
舉例：一個(gè)界面完成一個(gè)任務(wù)；表單超過10項(xiàng)必須分步驟；用戶必須隨時(shí)能回到主界面……這些原則可以由不同的形式來實(shí)現(xiàn)，但必須遵從這些原則。
規(guī)范
文章開頭也有提及到，忘記了請(qǐng)翻上去復(fù)習(xí)一下。
指南：圈定具體的交互模式、色彩搭配和設(shè)計(jì)禁忌。
在這個(gè)層面，一個(gè)[構(gòu)]可以有多個(gè)[形]，但某個(gè)形只能有一個(gè)[構(gòu)]，達(dá)到相同位置、相同外觀、相同操作。通過指南能夠讓各個(gè)端（IOS和安卓）看起來似曾相識(shí)，便于用戶學(xué)習(xí)和養(yǎng)成習(xí)慣。
舉例：在沒有左側(cè)導(dǎo)航的詳情界面，必須包含面包屑；面包屑只能出現(xiàn)在PC瀏覽器端，不允許出現(xiàn)在響應(yīng)式web界面中。
IOS和安卓的官方Guidelines就是這樣的東西，但也可視情況制定私有的指南，也就是各個(gè)公司自己的設(shè)計(jì)指南。
規(guī)格：規(guī)格非常具體的描述了每一個(gè)模式的每一個(gè)形態(tài)的具體尺寸、色彩、響應(yīng)，精確到數(shù)值。
舉例：一級(jí)標(biāo)題，字號(hào)為宋體 18pt；行高30pt；行上下外距為5pt；色值為#CC9300。
3）表單布局有什么規(guī)范要注意的？
這個(gè)問題是初級(jí)產(chǎn)品經(jīng)理最容易犯的問題，設(shè)計(jì)太隨意，看到別人的就想復(fù)制粘貼過來。這個(gè)問題正是可以解決很多初級(jí)產(chǎn)品常見錯(cuò)誤的問題，以及給大家提供一個(gè)思路。
這里分享四個(gè)常見的表達(dá)布局對(duì)齊：
首先，我們要清楚，人的視覺是上下，左右的。所以我們會(huì)把要填寫的標(biāo)題，放在左邊，輸入的內(nèi)容放在右邊。這個(gè)原因也在于大部分都是右撇子，所以放在右面方便輸入，而在左邊提到的四點(diǎn)，各有千秋。
關(guān)鍵在于考慮的出發(fā)點(diǎn)是用戶的視覺，還是表單的體驗(yàn)，抑或者是信息是否足夠直觀。再者就是是否夠簡潔，都是可供選擇，關(guān)鍵在于選定一個(gè)就保持一致。
綜上所述我們可以知道，交互設(shè)計(jì)可以通過交互的顯性和交互的隱性去考慮。
交互顯性
交互顯性指的是用戶在頁面所有的點(diǎn)擊，滑動(dòng)，跳轉(zhuǎn)的操作，比如刷新方式有下拉、上滑、按壓點(diǎn)擊等方式。
這就是所謂的交互顯性的操作。要保持產(chǎn)品顯性操作的統(tǒng)一性，同類別的交互不可有不同的操作感受。同時(shí)交互顯性要符合大眾的認(rèn)知習(xí)慣，可創(chuàng)新但不可違背潛意識(shí)，比如說PC端的交互顯性是以點(diǎn)擊事件作為核心操作的，移動(dòng)端的交互顯性是以滑動(dòng)作為核心操作的。
交互隱性
交互隱性指的是用戶信息發(fā)生改變時(shí)的顯示。比如說訂單狀態(tài)的顯示，確認(rèn)收貨后，綠色的標(biāo)簽顯示訂單已完成，申請(qǐng)售后則有售后的標(biāo)簽，一些平臺(tái)還會(huì)以訂單的顏色區(qū)分去給用戶隱喻。
再舉個(gè)例子，消息有個(gè)小紅點(diǎn)，用戶就會(huì)知道去點(diǎn)，上文也有提到隱喻，很多時(shí)候，我們就是通過交互隱性的方式，來引導(dǎo)用戶，提示用戶，這樣的方式有利于讓用戶自發(fā)性去體驗(yàn)，感受平臺(tái)的功能，帶來舒適感。
歸根結(jié)底，產(chǎn)品的交互離不開創(chuàng)新，一致，符合規(guī)范。
本章節(jié)我們以Web端為例，我們?cè)谠O(shè)計(jì)過程中，需要考慮我們基于什么樣的尺寸進(jìn)行基礎(chǔ)設(shè)計(jì)。劃分哪些區(qū)域需要固定尺寸、哪些需要做適配等。
據(jù)統(tǒng)計(jì)，使用中系統(tǒng)的用戶的主流分辨率主要為 1920、1440 和 1366。
設(shè)計(jì)思考，有如下幾點(diǎn)：
web頁面是按照Html的設(shè)計(jì)規(guī)范標(biāo)準(zhǔn)進(jìn)行布局設(shè)計(jì)的，由以下三部分構(gòu)成:
1）Margin（邊距）
為避免頁面元素緊貼邊沿的情況發(fā)生，WEB 頁面和其中的表格，應(yīng)設(shè)定邊距，最小邊距值為 “3px”。
一般粗細(xì)直角以1px，圓角為2px。
2）Button（按鈕）
按鈕一般有三種樣式：小、中、大。
按鈕是交互設(shè)計(jì)中必備的元素，它在用戶和系統(tǒng)的交互中承擔(dān)著非常重要的作用。
后臺(tái)中常見的按鈕類型分為線性按鈕、文字按鈕、圖標(biāo)按鈕等。
按鈕并列間距為：小間距8px，中間距16px，大間距24px
其中小中大的寬度分別為：58px，74px，96px
3）Table（表單）
常見表單是由多個(gè)列表項(xiàng)構(gòu)成的。而每一個(gè)列表項(xiàng)都是由最基本的標(biāo)簽和輸入框組成，常規(guī)的表單包括單選、多選、下拉選、輸入框、時(shí)間選擇、開關(guān)選擇等控件。
頂部標(biāo)簽是標(biāo)簽在控件的上方，標(biāo)簽可以和控件左對(duì)齊，對(duì)于橫向空間不足的情況是一種很好的方案。
豎列標(biāo)簽的使用場景思考：
表格的設(shè)計(jì)思考：
表格的設(shè)計(jì)規(guī)范的設(shè)計(jì)思考點(diǎn)如下：
表頭的文案，可遵循信息降噪的原則思考：
4）Progress bar（進(jìn)度條）
進(jìn)度條的設(shè)計(jì)思考：
加載中進(jìn)度條，存在加載中、成功、失敗三種狀態(tài)通過顏色去區(qū)分，進(jìn)度條長度支持自定義。
5）Dialog（彈窗）
彈框主要分為兩個(gè)大類模態(tài)彈框和非模態(tài)彈框，他們最大的區(qū)別就是是否強(qiáng)制用戶交互。
常規(guī)狀態(tài)通常出現(xiàn)在頁面的上方，有普通信息、成功信息、失敗信息、警示信息四種icon。
6）Default（缺省狀態(tài)）：
缺省頁面是當(dāng)頁面沒有數(shù)據(jù)、用戶沒有建立資料或網(wǎng)絡(luò)連接不通暢的情況下所展現(xiàn)的頁面。
為了緩解用戶面對(duì)這類情況產(chǎn)生焦慮情緒，設(shè)計(jì)師可以用一些插畫和文字的結(jié)合來引導(dǎo)用戶進(jìn)行下一步的操作。
產(chǎn)品風(fēng)格設(shè)計(jì)的形成一般通過以下幾點(diǎn)：顏色，字體，圖標(biāo)，尺寸決定的。
1）Color（顏色）
色彩內(nèi)容主要包含基礎(chǔ)色（如品牌色、黑色、白色）和功能色（如鏈接色、提醒色等），圖表配色為單獨(dú)的配色體系。
在前期制定顏色規(guī)范的時(shí)候，精益求精的設(shè)定顏色，切忌顏色過多。
顏色的狀態(tài)色盡量用原色進(jìn)行轉(zhuǎn)換，設(shè)置一個(gè)合理的變色公式，讓所有顏色的狀態(tài)色都根據(jù)這個(gè)公式進(jìn)行轉(zhuǎn)換。
例：
在設(shè)計(jì)規(guī)范中，盡量把顏色的色值和 rgba 值都寫出來（這里是強(qiáng)迫癥患者要標(biāo)的，因?yàn)橛袝r(shí)候色值完全一樣，但 rgba 數(shù)值略有不同，雖然效果一樣，但是對(duì)于強(qiáng)迫癥的你來說，舒服嗎？）。
狀態(tài)色有 4 狀態(tài)色：Normal、Hover、Click、Disable。
在設(shè)定圖表顏色的時(shí)候，要考慮不同的使用樣式（柱狀圖、環(huán)形圖、餅圖等…），同時(shí)也要考慮他的延展性。比如你設(shè)定 12 個(gè) chart 色值，在使用的時(shí)候按著順序來使用，當(dāng)超過 12 個(gè)后可以為同一個(gè)顏色。
2）Font（文字）
設(shè)定統(tǒng)一的字體規(guī)范，使用非襯線字體在各個(gè)操作系統(tǒng)下都有最佳展示效果。
首先，要設(shè)置一個(gè)字體家族，保證產(chǎn)品界面的最優(yōu)展示。
例如（僅作為展示，不是建議）：font-family: “Chinese Quote”, -apple-system, BlinkMacSystemFont, “Segoe UI”, “PingFang SC”, “Hiragino Sans GB”, “Microsoft YaHei”, “Helvetica Neue”, Helvetica, Arial, sans-serif, “Apple Color Emoji”, “Segoe UI Emoji”, “Segoe UI Symbol”;
字號(hào)
現(xiàn)在主流的產(chǎn)品中，主體字為 12px / 14px的居多，可根據(jù)自身的產(chǎn)品定位以及用戶的習(xí)慣進(jìn)行設(shè)定。
字號(hào)不要出現(xiàn)奇數(shù)，否則在一些顯示器上會(huì)有對(duì)不齊像素的狀況發(fā)生。
字體顏色
字體顏色數(shù)量建議在 3~4 個(gè)，不宜過多，但是每個(gè)層級(jí)之間區(qū)分要大一些。
文本應(yīng)該保持至少 4.5:1 （基于亮度值計(jì)算）的對(duì)比度以保持文本清晰；最佳對(duì)比度為 7:1。
測試對(duì)比度的網(wǎng)站：https://contrast-ratio.com
WCAG 2.0 中將顏色對(duì)比等級(jí)分為 3 種，A級(jí)，AA級(jí)，AAA級(jí)，等級(jí)越高意味著顏色的對(duì)比度越高，呈現(xiàn)出來的視覺壓力越大。
3）icon（圖標(biāo)）
設(shè)定統(tǒng)一的圖標(biāo)使用規(guī)范，讓視覺效果更和諧。
icon大小
icon 的常用尺寸有很多，需要注意的是 icon 的大小中，相鄰的兩個(gè)尺寸至少相差 4px，否則你會(huì)在后期用的時(shí)候會(huì)有選擇困難癥。同時(shí)功能 icon 盡量貼邊或盡量貼邊繪制，保證展現(xiàn)的視覺統(tǒng)一性（操作 icon 除外）。
單獨(dú) icon 使用的時(shí)候，盡量不要太小，最小值建議為 12px。
icon 熱區(qū)
icon 的熱區(qū)經(jīng)常被設(shè)計(jì)師和開發(fā)所忽略，本身 icon 的尺寸一般就很小，再加上如果沒有設(shè)置熱區(qū)的話，操作體驗(yàn)極差。
所以一定一定要設(shè)置 icon 的熱區(qū)，設(shè)置的值我建議為 icon 大小的 2倍。例：icon 大小為 14 * 14px，則熱區(qū)大小為 28 * 28px。
4）size（尺寸）
頁面內(nèi)布局間、模塊間、模塊內(nèi)的各部件距離。
尺寸大部分規(guī)范中都用的是 8 的倍數(shù)，不用糾結(jié)，直接用就行。我這里有個(gè)公式：Sn=8px * n，n為正整數(shù)。特殊：最小支持4px。
進(jìn)入進(jìn)階篇階段，我們不只是按照行業(yè)標(biāo)準(zhǔn)制定規(guī)范，也不是按照一些平臺(tái)標(biāo)準(zhǔn)以及常識(shí)問題，去為自己的產(chǎn)品制定規(guī)范標(biāo)準(zhǔn)。而是需要投入更多的精力，站在更高的角度去思考要為產(chǎn)品帶來什么價(jià)值。而價(jià)值的體現(xiàn)就在于轉(zhuǎn)化，管理，引導(dǎo)，復(fù)用，創(chuàng)新，切忌盲目動(dòng)手。
在進(jìn)階篇沒有唯一的標(biāo)準(zhǔn)，都需要各位結(jié)合自身產(chǎn)品的業(yè)務(wù)，產(chǎn)品定位，用戶畫像去制定。
接下來的內(nèi)容，也只是小編分享一下比較通用的方法，希望能夠幫助有緣人在迷茫的時(shí)候有個(gè)新思路。
在開始之前，再給大家補(bǔ)充三點(diǎn)，作為進(jìn)階篇學(xué)習(xí)之前，所需要結(jié)合著來學(xué)習(xí)的3個(gè)方面：
引導(dǎo)分為 5 種：Newbie guide（新手引導(dǎo)）、Steps guide（步驟引導(dǎo)）、Help / Operation guide（幫助/操作引導(dǎo)）、New function guide（新功能引導(dǎo)）、Blank guide（空白頁引導(dǎo)）。
1）Newbie guide（新手引導(dǎo)）
新手引導(dǎo)是針對(duì)新用戶的，首次進(jìn)入產(chǎn)品的時(shí)候，我們要著重的把自己產(chǎn)品的亮點(diǎn)以及操作快速的介紹給新用戶，讓他用最短的時(shí)間上手我們的產(chǎn)品。
新手引導(dǎo)要言簡意賅，并且如果非必要的話，盡量給用戶一個(gè)可以直接關(guān)閉的按鈕，讓用戶有選擇權(quán)。我就非常討厭有一些產(chǎn)品的新手引導(dǎo)，必須走完全部流程后才能關(guān)閉，惡心的不行。
2）Steps guide（步驟引導(dǎo)）
步驟引導(dǎo)一般用在有固定操作步驟的場景下，指引用戶一步一步的完成想要的結(jié)果。常規(guī)的步驟引導(dǎo)建議在 3~5 步之間為合理。
3）Help/Operation guide（幫助/操作引導(dǎo)）
幫助/操作引導(dǎo)的展現(xiàn)方式是比較豐富多彩的，可以是提示語、輔助性文本、tooltips 等等，他的作用就是輔助用戶去了解并且知道如何操作這個(gè)功能。
這個(gè)也是在產(chǎn)品中使用頻率最高的，運(yùn)用好他，可以讓你的產(chǎn)品事半功倍。
4）New function guide（新功能引導(dǎo)）
他就是常用在新功能上線后，用戶第一次登陸相關(guān)頁面后做的一些引導(dǎo)，目的是為了告訴用戶我們做了新東西，你快來試試吧。
5）Blank guide（空白頁引導(dǎo)）
空白頁引導(dǎo)一般用在在缺省頁，對(duì)用戶進(jìn)行一些操作指引，讓無信息的頁面變得更有價(jià)值。比如百度在一些缺省頁上就放了一些關(guān)于失蹤兒童的信息，就因?yàn)樽隽诉@個(gè)引導(dǎo)，幫助了千萬個(gè)家庭找到了失散的孩子。
這一章節(jié)在很多平臺(tái)里面，都會(huì)給忽略掉它的一個(gè)重要性，一個(gè)產(chǎn)品的延展性，通用性，易用性和親密性都離不開一個(gè)好的角色設(shè)計(jì)規(guī)范，角色設(shè)計(jì)的底層邏輯就是產(chǎn)品權(quán)限的制定。
目前的主流產(chǎn)品對(duì)于權(quán)限的制定都有一套規(guī)范標(biāo)準(zhǔn)，小編負(fù)責(zé)的產(chǎn)品也是通過借鑒主流產(chǎn)品權(quán)限的制定方式來設(shè)計(jì)，本章節(jié)主要是給大家分享下小編的方法。
我在做權(quán)限制定的對(duì)象是角色，而不是用戶，所以也點(diǎn)一下題，我們?cè)谧龅氖菍?duì)產(chǎn)品角色設(shè)計(jì)的規(guī)范，并不是對(duì)用戶權(quán)限去做控制，接下來我們先來梳理下在做權(quán)限制定的時(shí)候常見的問題。
1）權(quán)限制定的過程中常遇到的問題有。
我們可管理的權(quán)限（系統(tǒng)資源）分為功能權(quán)限、數(shù)據(jù)權(quán)限：
這些問題主要都是基于用戶作為權(quán)限主體的時(shí)候會(huì)出現(xiàn)的問題。傳統(tǒng)的方式就是A -> B -> C 這類型的用戶權(quán)限去對(duì)用戶進(jìn)行管理，對(duì)于業(yè)務(wù)的調(diào)整以及對(duì)功能模塊的拓展是不友好的。
因此，我對(duì)于權(quán)限管理的理解為權(quán)限是主體對(duì)客體遵循特定機(jī)制做出的行為，而本章節(jié)主要是給各位分享RBAC模型。
2）對(duì)RBAC模型中的關(guān)系描述 – 基于角色的訪問控制
RBAC（Role-Based Access Control）是一種訪問控制模型，用于管理系統(tǒng)中的用戶訪問權(quán)限。RBAC模型基于角色來定義和分配權(quán)限，通過將權(quán)限與角色關(guān)聯(lián)，然后將角色分配給用戶，實(shí)現(xiàn)對(duì)系統(tǒng)資源的訪問控制。
1. 角色與權(quán)限之間的關(guān)系：
2. 角色與用戶之間的關(guān)系：
這些關(guān)系形成了RBAC模型的基本結(jié)構(gòu)，通過這些關(guān)系的建立和管理，可以實(shí)現(xiàn)對(duì)用戶訪問權(quán)限的控制和管理。
3）對(duì)RBAC模型的分析
RBAC模型的優(yōu)點(diǎn)包括：
然而，RBAC模型也存在一些挑戰(zhàn)，如角色爆炸問題（角色數(shù)量過多）、權(quán)限維護(hù)復(fù)雜、權(quán)限繼承問題等。在實(shí)施RBAC模型時(shí)，需要仔細(xì)設(shè)計(jì)角色和權(quán)限的結(jié)構(gòu)，平衡權(quán)限的粒度和靈活性，以及確保合理的權(quán)限繼承和分配策略。
4）分享一個(gè)使用RBAC模型的實(shí)例
假設(shè)有一個(gè)在線學(xué)習(xí)平臺(tái)，涉及學(xué)生、教師和管理員三個(gè)角色，以及對(duì)應(yīng)的權(quán)限：
1. 角色與權(quán)限之間的關(guān)系：
2. 角色與用戶之間的關(guān)系：
3. 在該實(shí)例中，RBAC模型的使用如下：
通過RBAC模型，該在線學(xué)習(xí)平臺(tái)實(shí)現(xiàn)了對(duì)不同角色的權(quán)限控制，確保每個(gè)用戶只能執(zhí)行其角色所允許的操作，從而提供了安全和可控的訪問控制機(jī)制。
5）最后，對(duì)本章節(jié)進(jìn)行一個(gè)總結(jié)
在權(quán)限模型里面有兩個(gè)核心概念，第一個(gè)是靜態(tài)指責(zé)分離，第二個(gè)是動(dòng)態(tài)指責(zé)分離
靜態(tài)職責(zé)分離
互斥角色限制：有些特殊的崗位，同一個(gè)用戶在兩個(gè)互斥的角色中只能選擇一個(gè)。
比如財(cái)務(wù)和審計(jì)，不能既是運(yùn)動(dòng)員又做裁判。
基數(shù)限制：考慮容量、并發(fā)等的問題，一個(gè)用戶擁有的角色是有限的，一個(gè)角色擁有的權(quán)限也是有限的，一個(gè)角色下的用戶也是有限的。
比如微信公眾平臺(tái)做的限制：一個(gè)微信號(hào)可綁定并管理5個(gè)公眾號(hào)。
先決條件限制：用戶想要獲得高級(jí)別的角色，必須先獲得低級(jí)別的角色。
比如一個(gè)PMer需要先從專員做起，再升為產(chǎn)品經(jīng)理，再到產(chǎn)品總監(jiān)。
這種條件限制在人員規(guī)模比較大的團(tuán)隊(duì)就很常見了，人越多越需要嚴(yán)格且清晰的制度，避免個(gè)別的take a shortcut影響大局的穩(wěn)定。
動(dòng)態(tài)職責(zé)分離
動(dòng)態(tài)的限制用戶及其擁有的角色。
一個(gè)用戶可以擁有多個(gè)角色，但是運(yùn)行時(shí)只能激活一個(gè)角色。
常見就像招聘網(wǎng)站這種，用戶既可以招人也可以找工作，角色不同看到的信息完全不一樣，所以就只能激活其中一個(gè)角色。
最后給大家總結(jié)一下今天分享出來的內(nèi)容，產(chǎn)品設(shè)計(jì)的規(guī)范標(biāo)準(zhǔn)，具體的規(guī)范還會(huì)根據(jù)產(chǎn)品的特點(diǎn)、行業(yè)要求和用戶需求而有所不同。
在制定產(chǎn)品設(shè)計(jì)規(guī)范時(shí)，需要綜合考慮用戶體驗(yàn)、技術(shù)可行性、業(yè)務(wù)目標(biāo)和品牌形象等因素，以確保產(chǎn)品能夠提供優(yōu)質(zhì)的用戶體驗(yàn)并達(dá)到預(yù)期的目標(biāo)。
歸納為以下8點(diǎn)：
本文由@樂少有話說 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自 Unsplash，基于 CC0 協(xié)議
該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
