整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
讀一開始我們的H5頁面秒開率只有30%左右，現在我們的H5頁面秒開率達到了 75%。這中間巨大的差異究竟有哪些黑科技在里面？我們為什么要做H5頁面的秒開優化？我們的秒開指標是如何統計的？客戶端和H5是怎么配合做到 1+1>2的？監控是如何發現H5頁面可優化項的？我們又通過監控發現了哪些可優化的問題呢？
H5秒開優化是一個老生常談的問題，本文將逐步介紹如何通過客戶端 + H5 的優化手段（1+1>2）把秒開從 30% 提升到 75% ？后續接口預請求、客戶端預渲染以及預加載2.0上線后還會再次助力指標提升。
為什么要做優化？
Global Web Performance Matters for ecommerce 的報告中指出：
整體系統架構圖：
首先講一下得物用來衡量秒開的指標 FMP，那為什么不選擇 FCP 或者 LCP 呢？FCP 只有要渲染就會觸發，LCP 兼容性不佳，得物希望站在用戶的角度來衡量秒開這件事情，用戶從點擊打開一個WebView到首屏內容完整的呈現出來的時間點就是得物定義的FMP觸發時機。
指標清楚了之后，再來看一下完整的 FMP 包含哪些耗時。
接下來將分為兩大部分進行介紹，客戶端優化部分和H5 優化部分。
通過 HTML 預加載、HTML 預請求、離線包、接口預請求、鏈接保活、預渲染等手段提升頁面首屏打開速度，其中預加載、預請求、離線包分別可提升10%左右的秒開。
通過配置由客戶端提前下載好HTML主文檔，當用戶訪問時直接使用已經下載好的HTML文檔，以此減少HTML網絡請求時間，從而提升網頁打開速度。
前人栽樹后人乘涼，得物App有很多的資源位，banner、金剛位、中通位等，這些位置顯示什么內容，早就已經是智能推薦算法產出的了，那么就可以直接指定這些資源位進行預加載。
頁面被預加載之后，總不能一直不更新吧？那么什么時候更新頁面的緩存呢？
被現實打臉：
但是在后面的灰度過程中被現實狠狠的教育了一頓，發現有些SSR的頁面會涉及到狀態的變更，比如說：領劵場景。這些狀態都是經過SSR服務渲染好的，用戶在進入頁面時還沒有領劵，這個時候去更新HTML文檔，實屬更新了個寂寞，在用戶領劵之后關閉頁面再次進入，發現頁面中的狀態仍是讓用戶領劵，點擊領劵又告訴人家你已經領過了。
改進措施
至此問題也解決了，工程師的任務結束了嗎？如果你認為功能做上去就算結束，那么此時此刻請你一定要轉變思維，想一想我們的目標是什么？我們的目標是「提升秒開」，預加載只是一種提升秒開的手段，但是在功能做上去之后并不知道這個功能帶來了多少秒開的收益，因此在把功能開發完成上線之后，就要開始關注上線之后的結果，來看看預加載的性能表現如何。從下圖可以看到，預加載開啟狀態下可提升10%以上的秒開率。
（1）SSR服務擴容
要解決服務器壓力問題，很自然就會想到增加機器，于是我們對SSR機器數量做了一次擴容，將機器數量提升了一倍，這個時候繼續嘗試擴大預加載的用戶數量，但是仍然無法抗住這么大的QPS，而且此時還引發了第二個問題，算法部門的服務器發出了告警，于是放量計劃又一次遇到了阻礙。
（2）破局者 CDN
利用CDN 服務器的緩存能力既可以減輕 SSR 服務器的壓力又可以減少后端服務鏈路的壓力，這么好的東西為什么不用呢？這里留個懸念，后面將H5優化部分會詳細介紹。
（3）客戶端配合改造
支持針對CDN域名進行全部開放預加載能力，針對非CDN域名保持原有放量比例。
在這個過程中還分析了頁面的流量占比，發現開屏廣告來源的頁面流量占比也很高，那么是不是可以把開屏廣告的HTML文檔內容也給預加載下來呢？
開屏頁面預加載策略
既然可以提前下載好HTML，那是不是可以更進一步，提前把頁面內的資源加載好，這樣在打開一個頁面的時候可以減少大部分的網絡請求從而更快速的把內容呈現給用戶。這里還需要考慮如何跟下面講到的離線包進行協作。
在WebView初始化同時，去請求HTML主文檔，等待HTML文檔下載完成 且 WebView初始成功后渲染，減少用戶等待時間，客戶端請求成功后，WebView加載本地 HTML，并保存以供下次使用。預請求HTML開啟狀態下可提升8%左右的秒開。
預請求 VS 預加載
本質上HTML預加載和HTML預請求的區別就是下載HTML文檔的時機不同， 預加載是在App啟動后用戶無任何操作的情況下就會去下載，但是預請求只會在用戶單擊打開H5頁面的時候才會去下載。如果用戶是第二次打開某個H5頁面，此時發現本地有已經下載好的HTML且尚未過期就會直接使用，這個時候的行為表現就跟預加載的功能是一致的了。
上線之后發現預請求只提升了2%左右的秒開，經過分析發現問題：
在本地用低端機對整個秒開耗時鏈路進行了分析，為什么要用低端機分析呢？低端機有個好處，天然的加上了慢放功能，可以最大程度發現問題。
從圖中可以看出h5 頁面加載之前 耗時 分布在 activityStart() 函數，該函數 包含了 onCreateView ，其中耗時最長是 布局填充 inflate()，因為 WebView 對象是提前創建好的，直接從對象池中取出的，所以耗時主要在 初始化過程，WebView 自身的初始化 WebViewChromiumFactoryProvider. startYourEngines （耗時 87 us，不到 1 ms），耗時還有 WebView 的一些其他初始化，jockey 的初始化 等等。
而秒開的計算是包含了 View 初始化到 WebVIew url 加載 的耗時，從而發現了優化點，可以將Webview loadUrl 前置，h5 頁面加載 與 原生布局填充并行執行。在 onCreateView 時，創建 FrameLayout 進行返回，執行 WebView loadUrl 之后，主線程開始 對布局進行 inflate，布局加載成功后，將其 addView 到 FrameLayout 中，減少了 loadUrl 的阻塞時長。中高端機型有 15ms 左右優化，低端機型有 30 ~ 50 ms 優化 效果。
預請求HTML時機是在進入到 native 頁面中，這個時間點距離用戶單擊事件已經過去100ms，那么是否可以將下載HTML的時機提前呢？經過一番探索，最終選擇在路由階段進行攔截，既可以統一收口而且距離用戶點擊的時間間隔可以忽略不計。通過這種方式將下載HTML時機提前了平均80ms+。
此時的流程變成了下面這樣。
可能有的同學會問了，為什么不在用戶點擊的時候去下載呢？從用戶點擊到路由肯定還是有耗時的。
在上述問題解決后，將緩存時間修改為1天，發現預請求HTML開啟狀態下可提升8%左右的秒開，已經和預加載的效果相差不大了。
通過提前將H5頁面內所需的css、js等資源聚合在一個壓縮包內，由客戶端在App啟動后進行下載解壓縮，在后續訪問H5頁面時，匹配是否有本地離線資源，從而加速頁面訪問速度。
資源攔截這塊安卓這邊實現比較簡單，WebView支持 shouldInterceptRequest, 可以在該方法內檢測是否需要進行資源攔截，需要的話返回 WebResourceResponse 對象，不需要直接返回 null。
但是在iOS 這邊遇到了一些困難，調研了以下方案：
NSURLProtocol 攔截方式，使用WKBrowsingContextController和registerSchemeForCustomProtocol。通過反射的方式拿到了私有的 class/selector。通過把注冊把 http 和 https 請求交給 NSURLProtocol 處理。通過這種方式確實可以攔截請求，但是發現post請求的body會出現丟失的問題。而且NSURLProtocol一經注冊就是全局開啟。我們希望他只會攔截接入了離線包的頁面，但是沒有辦法控制他，他會攔截所有頁面的請求，包括第三方合作頁面，顯然這是無法接受的。
在iOS 11及以上系統中, 擁有了加載自定義資源的API：WKURLSchemeHandler。
可以修改當前頁面url為自定義 scheme 協議，比如：https://fast.dewu.com 修改為 duapp://fast.dewu.com 然后在客戶端內注冊該 scheme，前端配合修改頁面內所有的資源請求未自適應協議，如：src="//fast.dewu.com/xxx" 就可以實現攔截。但是在測試過程中發現，接口為了安全起見只允許白名單內的域名發起跨域請求，且無法配置多個域名，導致該方案無法繼續進行。
仍然是使用 WKURLSchemeHandler 然后通過 hook WKWebview 的 handlesURLScheme 方法來支持 http 和 https 請求的代理。通過這種方式雖然可以攔截請求了，但是遇到了以下問題：
（1）body丟失問題
不過在 iOS 11.3 之后對這種情況做了修復處理，只有 blob 類型的數據會丟失。需要由JS來代理 fetch 和 XMLHttpRequest 的行為，在請求發起時將 body 內容通過 JSBridge 告知 native，并將請求交給客戶端進行發起，客戶端在請求完成后 callback js 方法。
（2）Cookie 丟失、無法使用問題
通過代理 document.cookie 賦值和取值動作，交由客戶端來進行管理，但是這里需要額外注意一點，需要做好跨域校驗，防止惡意頁面對cookie進行修改。
至此功能開發完成上線，先來一組線上收益數據，安卓開啟離線情況有有10%左右的收益，但是iOS開啟離線的反而秒開率更低。經過修復處理后iOS也可提升10%以上的秒開。
安卓和iOS實現差異
經過分析對比發現，安卓的攔截動作比較輕，可以判斷是否需要攔截，不需要攔截可以交給WebView自己去請求。
但是iOS這邊一旦頁面開啟攔截后，頁面中所有的http和https請求都會被攔截掉，由客戶端發起請求進行響應，無法將請求交還給WebView自己去發起。
iOS 緩存問題修復
頁面中的資源經過客戶端請求代理后原本第二次打開WebView本身會使用緩存的內存，現在緩存也失效了，于是只能在客戶端內實現了一套緩存機制。
從下圖可以看到離線包的下載錯誤率在 6% 左右浮動，這么高的下載錯誤率肯定是無法接受的， 經過一系列優化手段，把離線包下載錯誤率從6%左右浮動下降至 0.3%左右浮動。
先來看下優化前的流程圖和問題點。
通過埋點發現大量 unknown host 、網絡請求失敗、網絡連接斷開的情況。分析代碼發現下載未做隊列控制，會同時并發下載多個離線包，從而導致多個下載任務爭搶資源的情況。針對發現的問題點做出了以下優化：
下面是優化之后的流程圖：
針對離線資源是直接存儲在磁盤上的，每次訪問都會有磁盤IO耗時，經過在低端機器上做測試發現這個耗時會在 0 - 10ms 之間進行波動，后面會把內存合理的利用起來，通過設置內存上限，文件數量上限，甚至是文件類型，并通過 LRU 策略進行內存文件的淘汰更新。
通過客戶端發起H5頁面首屏接口請求，遠比等待客戶端頁面初始化、下載HTML、JS下載執行的時機更提前，從而節省用戶的首屏等待時間。在本地測試過程中發現接口預請求可提前100+ms，用戶也就可以更快的看到內容。
客戶端會在App啟動后獲取配置，保存支持預請求的頁面地址及對應的接口信息，在用戶打開WebView時，會并行發起對應預請求的接口，并保存結果。當JS執行開始獲取首屏數據時，會先詢問客戶端是否已經存有對應的響應數據，如果此時已經拿到數據則無需發起請求，否則 js 也會發起接口請求并開啟競速模式。以下是整體流程圖：
那么客戶端怎么知道這個頁面需要請求什么接口呢？以及接口的參數是什么呢？那自然少不了配置平臺，它支持以下功能：
首先即使是在 SSR 的情況下，首屏內容中仍然可能有部分組件是骨架直出的，需要等待頁面渲染執行時才會去請求數據，另外還有一部分頁面是SPA的。針對這兩種情況都能做到很好的補充。
開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。
通過上圖可以看到一個網絡請求在經過DNS解析耗時、TCP建連耗時、SSL建連耗時階段之后才能把請求發出去，那么是否可以節省這段時間的耗時呢？
客戶端常用的網絡請求框架如OkHttp等，都能完整支持http1.1與HTTP2的功能，也就支持連接復用。了解了這個連接復用機制優勢，那就可以利用起來，比如在APP開屏等待的時候，就預先建立關鍵域名的連接，這樣進入相應頁面后可以更快的獲取到網絡請求結果，給予用戶更好體驗。在網絡環境偏差的情況下，這種預連接理論上會有更好的效果。
可以通過對域名鏈接提前發起一個HEAD請求從而建立鏈接，網絡框架會自動將連接放入連接池。并在默認無操作5分鐘后進行釋放，在五分鐘內重復執行上述動作即可一直保持鏈接。
另外這里需要注意下連接池的數量問題，如果連接池的數據太小，但是域名比較多的話，通過預建連保持的鏈接很容易就會被釋放掉，這就需要通過域名收斂或者調大連接池的數量來進行優化。
那預建連會不會增加服務器的壓力呢？這個肯定是會的，首先會針對預建連功能本身就行灰度策略，在HTML頁面通過CDN托管后，直接針對 cdn 域名進行全量開啟，從而不用擔心 cdn 域名扛不住壓力。
來看一下線上效果，通過下圖可以看到在開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。
客戶端提前通過WebView將頁面渲染好，等待用戶訪問時，可直接展示。從而達到瞬開效果。但是這種功能肯定不能對所有的頁面進行開放，而且存在一定的弊端。
下圖【開學季】是業務上已經進行預渲染的H5頁面，可以看到在打開【開學季】頁面時，頁面已經渲染完畢，絲毫沒有等待過程。
后面計劃把這種能力放大到通用的webview上，針對大促以及PV量高的頁面進行開放。
SSR服務端渲染（英語：server side render）一般情況下，一個H5頁面的數據渲染完全由客戶端來完成，先通過AJAX請求到頁面數據并把相應的數據填充到模板，形成完整的頁面來呈現給用戶。而服務端渲染把數據的請求和模板的填充放在了服務端，并把渲染的完整的頁面返回給客戶端。
SSR對于秒開有平均15%的提升，既然是服務端渲染，就會對服務器造成壓力，尤其是在預加載HTML功能開啟后，那得物是如何解決的呢？
通過這么多優化手段仍然無法滿足預加載的需求，并且通過分析發現網絡階段耗時較長，最終還是搬出了CDN這個大殺器，一直沒上CDN的原因有很多，主要有以下幾方面：
（1）得物的頁面是千人千面的每個人看到的內容都不同
通過上述優化4即可解決，將原本SSR渲染的內容修改CSR，由于已經上了CDN了，后續計劃將這部分內容再次修改回SSR，這樣用戶可以更快的看到商品而不是骨架，然后通過 CSR 的方式來更新內容。
（2）頁面狀態變更，無法及時更新緩存
這個問題在上述客戶端預加載優化部分已經有解決方案了，可以通過在頁面打開后針對有需要的組件再次請求接口刷新數據以確保數據的準確性，但是這部分工作量也是比較大的，梳理出來的需要刷新狀態的組件就有30+，而且之后開發的組件都需要考慮狀態更新的事情。
（3）HTML模板內容變更無法及時更新
引起模板內容變更的地方有兩處，第一個場景就是在搭建器場景下，運營可以動態修改模板內容導致頁面結構變更（低頻次），第二個場景是項目發版后模板內容需要更新（高頻）。
這個問題可以通過在感知到內容變更時自動調用CDN服務商的刷新緩存接口來更新CDN緩存內容。
通過puppeteer將SPA頁面渲染出來并將HTML文檔進行保存，配合上述頁面刷新策略，并將HTML通過CDN進行托管，讓你的 SPA 頁面 像 SSR 一樣絲滑。
主要實現方案是通過基于webpack的插件prerender-spa-plugin，并配置需要預渲染的路由，這樣經過打包之后就會產出對應路由的頁面。方案本身是通用的，但是每接入一個頁面都需要人工check。
眾所周知 css 加載會阻塞HTML渲染，最終將首屏公共css從118kb縮減至38kb，下圖通過 chrome 模擬弱網環境下的SSR頁面加載時序圖。從圖中可以看出 styles.fb201fce.chunk.css 下載耗時 18s，阻塞了頁面的渲染，HTML 主文檔耗時 2.38s 就已經下載完成了，但是實際渲染時間卻是在 20s 之后。
優化思路也比較單間，將首屏所需要的css 文件通過內聯方式內嵌到HTML中，由SSR服務一并返回，并對css文件進行拆分，按需加載。
思路有了，接下來就看怎么去實現了，最初嘗試了MiniCssExtractPlugin 插件他可以把css分成單獨的文件，并且每一個js會對應生成一個css文件，但是他需要建立在webpack5之上，然而項目中使用的next版本是9.5，于是就想著升級到最新版next12，升級后發現，在構建中其他包各種報錯，發現有些包并不支持最新的next12，在嘗試一天的修復之后，仍未解決，且升級到最新版不確定是否會引發其他穩定性問題，暫且擱置尋找其他方法。
經過不懈的努力，通過閱讀 next 源碼發現了端倪，發現在打包時將所有的公共css通過 splitChunks 進行分組，由于項目中組件都是動態引入的，這里直接在 next.config.js 中修改webpack打包參數，將 splitChunks.cacheGroups.styles 配置刪除，使用默認的 chunks: async 配置，即可實現按需引入。
（1）避免圖片src為空
雖然src屬性為空字符串，但瀏覽器仍然會向服務器發起一個HTTP請求，尤其是在SSR服務器壓力扛不住的情況下，因此這里需要特別注意一下。
（2）圖片壓縮以及格式選擇
WebP 的優勢體現在它具有更優的圖像數據壓縮算法，能帶來更小的圖片體積，而且擁有肉眼識別無差異的圖像質量；同時具備了無損和有損的壓縮模式、Alpha 透明以及動畫的特性，在 JPEG 和 PNG 上的轉化效果都相當優秀、穩定和統一。
通過向圖片服務器傳遞參數選擇合適的分辨率。
（1）打包優化
（2）非關鍵js、css延遲加載
（3）媒體資源加載優化
（4）其他資源優化
（5）頁面渲染優化
（6）代碼層面優化
為了幫助開發者更好地衡量和改進前端頁面性能，W3C性能小組引入了 Performance API ，其中Navigation Timing API 實現了自動、精準的頁面性能打點。得物前端性能監控指標也都是從 Performance API 中獲取數據進行上報統計分析的。
SDK 數據采集完畢后，會上報到 阿里云 sls 日志平臺，隨后通過 flink 實時消費清洗數據后落庫至 clickhouse 中，平臺后端通過讀取 clickhouse 數據并做各種聚合處理后使用。
做優化之前首先要建立監控指標，互聯網稱之為抓手，沒有監控指標的情況下，任你怎么優化，都不知道優化的效果怎么樣，更不知道下一步該做什么？以及還有哪些問題沒解決。因此優化之前指標先行，當然一定要指標的準確性。
指標大盤主要包含以下功能：
在正常情況下，完成上述的優化措施后用戶基本是可以秒開 H5 頁面的了。但異常情況總是會有的，用戶的網絡環境和系統環境千差萬別，甚至 WebView 也可能發生內部崩潰。當發生問題時，用戶看到的可能就直接只是一個白屏頁面了，所以進一步的優化手段就是需要去檢測是否發生白屏以及相應的應對措施。
檢測白屏最直觀的方案就是對 WebView 進行截圖，遍歷截圖的像素點的顏色值，如果非純色的顏色點超過一定的閾值，就可以認為不是白屏。首先獲取包含 WebView 視圖的 Bitmap 對象，然后把截圖縮小到指定的分辨率大小如:100*auto，遍歷檢測圖片的像素點，當非純色的像素點大于 5% 的時候就可以認為是非白屏的情況，但是還有很多列外的情況，我們通過圖片識別技術對截圖進行分析，可以很好的感知當前是否白屏、是不是在loading、是不是特殊頁面等。
白屏是一個重要的指標，我們針對整體白屏率快速拉升、新增白屏頁面發出告警通知，便于開發人員及時介入開始排查問題。
主要通過 CDN 未覆蓋監控、http請求監控、網絡監控（加載失敗、耗時異常、傳輸大小異常）、圖片監控（未壓縮、分辨率異常）等監控手段發現頁面中的潛在問題，同時還提供了問題分析能力，在問題分析頁面輸入頁面url地址即可幫助您發現問題并給出修改建議。
CDN的重要性不言而喻，它可以加速資源訪問速度，從而提升用戶體驗，我們通過對線上埋點數據分析，找出CDN未覆蓋的資源列表，從而推動各業務同學優化。
為什么要監控HTTP請求呢？我們先來看一下HTTPS相對于HTTP新增的特點：
那么HTTP就容易被中間人查看到內容，甚至被篡改，既然如此為了我們服務的安全性就需要對現有的http協議統一進行升級改造，那就需要監控去發現。
某些頁面秒開率低，那就要分析一下原因，是不是這個頁面的接口響應比較慢呢，還是說頁面本身有請求比較大的資源？如果發生網絡請求失敗的情況也要第一時間感知，不能被動等待用戶反饋。
包含圖片未壓縮、圖片分辨率異常、圖片傳輸大小大于 300kb 異常、動圖資源傳輸大小大于 1M 異常功能。
上面列出來一堆功能，對于業務的同學可能比較煩惱，我一個頁面具體有哪些問題呢？你不能讓我去上面的功能里面一個個看，哪個異常是我負責的頁面的吧？這個功能本身就行將現有的功能利用起來，通過一個頁面path進行聚合分析。
H5異常一直是使用 sentry 進行監控的，但是sentry系統因缺乏同PV、DAU數據的關聯性，因此無法衡量產品異常發生后所帶來的嚴重程度。在業務域關聯上的缺失導致異常問題無法根據業務域進行劃分。用戶行為日志也尚未與Native 端側打通，在問題分析時容易遇到上下文不全的瓶頸。還有一個問題是sentry會有限流措施，當qps較高時會丟棄一部分異常數據。
由于sentry已經可以幫助我們進行一定的問題排查分析能力，我們不打算做sentry同樣的功能，而是做sentry不支持的部分，針對上述問題我們設計了以下功能：
雖然目前秒開率已經做到了75%以上，但是同時我們還有一個重要的指標，90分位耗時，致力于提升末尾用戶H5頁面使用體驗，在90分位優化完成后，可能會考慮繼續深入優化95分位耗時。
至此我們系統的講解了背景以及從指標建立到秒開優化上線的全過程，全文分成了三個部分，客戶端、H5、以及監控。如果閱讀本文對您有所收獲，麻煩您動一動發財的小手點個贊吧！如果閱讀完還意猶未盡或者有什么問題和想法歡迎留言區評論交流。
最后奉上整體優化腦圖：
*文/徐銘
歡迎關注「得物技術」微信公眾號，每周一三五晚18:30更新技術干貨
要是覺得文章對你有幫助的話，歡迎評論轉發點贊～
SS的4種引入方式是：行內樣式、內嵌樣式、鏈接樣式、導入樣式
1.行內樣式
最直接最簡單的一種，直接對HTML標簽使用style=""，例如：
<p style="color:#F00; "></p>
缺點：HTML頁面不純凈，文件體積大，不利于蜘蛛爬行，后期維護不方便。
2.內嵌樣式
內嵌樣式就是將CSS代碼寫在<head></head>之間，并且用<style></style>進行聲明，例如：
<style type="text/css">
body,div,a,img,p{margin:0; padding:0;}
</style>
優缺點：頁面使用公共CSS代碼，也是每個頁面都要定義的，如果一個網站有很多頁面，每個文件都會變大，后期維護難度也大，如果文件很少，CSS代碼也不多，這種樣式還是很不錯的。
3.鏈接樣式
鏈接樣式是使用頻率最高，最實用的樣式，只需要在<head></head>之間加上<link…/>就可以了，如下：
<link type="text/css" rel="stylesheet" href="style.css" />
優缺點：實現了頁面框架代碼與表現CSS代碼的完全分離，使得前期制作和后期維護都十分方便
4.導入樣式（不建議使用）
導入樣式和鏈接樣式比較相似，采用@import樣式導入CSS樣式表，在HTML初始化時，會被導入到HTML或者CSS文件中，成為文件的一部分，類似第二種內嵌樣式。
@import在html中使用，如下：
<style type="text/css">
@import url(style.css);
</style>
@import在CSS中使用，如下：
@import url(style.css);
四種CSS引入方式的優先級
1.就近原則
2.理論上：行內>內嵌>鏈接>導入
3.實際上：內嵌、鏈接、導入在同一個文件頭部，誰離相應的代碼近，誰的優先級高
文章地址：peixun.qietu.com
文/丁向明
做一個有博客的web前端自媒體人，專注web前端開發，關注用戶體驗，加我qq/微信交流：6135833
基于vue2.x+vuex+vue-cli+vue-router+element-ui+swiper等技術開發仿微信pc端界面聊天應用，實現了發送消息+表情(動圖gif)、圖片/視頻預覽、右鍵長按菜單、紅包/朋友圈、截圖發送等功能。
<script src="https://lf3-cdn-tos.bytescm.com/obj/cdn-static-resource/tt_player/tt.player.js?v=20160723"></script>
github地址
Element | 是一套為開發者、設計師和產品經理準備的基于 Vue 2.0 的桌面端組件庫
https://element.eleme.cn/https://github.com/ElemeFE/elementnpm install element-ui -Simport Vue from 'vue'
import Element from 'element-ui'
Vue.use(Element)
// 按需引入
import {
Select,
Button
// ...
} from 'element-ui'
Vue.component(Select.name, Select)
Vue.component(Button.name, Button)/*
引入公共及全局組件配置
*/
// 引入側邊欄及聯系人
import winBar from './components/winbar'
import sideBar from './components/sidebar'
import recordList from './components/recordList'
import contactList from './components/contact'
// 引入jquery
import $ from 'jquery'
// 引入wcPop彈窗插件
import wcPop from './assets/js/wcPop/wcPop'
import './assets/js/wcPop/skin/wcPop.css'
// 引入餓了么pc端UI庫
import elementUI from 'element-ui'
import 'element-ui/lib/theme-chalk/index.css'
// 引入圖片預覽插件
import photoPreview from 'vue-photo-preview'
import 'vue-photo-preview/dist/skin.css'
// 引入自定義滾動條插件
import geminiScrollbar from 'vue-gemini-scrollbar'
// 引入加載更多插件
import infiniteLoading from 'vue-infinite-scroll'
// 引入高德地圖
import vueAMap from 'vue-amap'
const install = Vue => {
// 注冊組件
Vue.component('win-bar', winBar)
Vue.component('side-bar', sideBar)
Vue.component('record-list', recordList)
Vue.component('contact-list', contactList)
// 應用實例
Vue.use(elementUI)
Vue.use(photoPreview, {
loop: false,
fullscreenEl: true, //是否全屏
arrowEl: true, //左右按鈕
});
Vue.use(geminiScrollbar)
Vue.use(infiniteLoading)
Vue.use(vueAMap)
vueAMap.initAMapApiLoader({
key: "e1dedc6bdd765d46693986ff7ff969f4",
plugin: [
"AMap.Autocomplete", //輸入提示插件
"AMap.PlaceSearch", //POI搜索插件
"AMap.Scale", //右下角縮略圖插件 比例尺
"AMap.OverView", //地圖鷹眼插件
"AMap.ToolBar", //地圖工具條
"AMap.MapType", //類別切換控件，實現默認圖層與衛星圖、實施交通圖層之間切換的控制
"AMap.PolyEditor", //編輯 折線多，邊形
"AMap.CircleEditor", //圓形編輯器插件
"AMap.Geolocation" //定位控件，用來獲取和展示用戶主機所在的經緯度位置
],
uiVersion: "1.0"
});
}
export default install/*
* 主頁面js
*/
import Vue from 'vue'
import App from './App.vue'
import router from './router'
import store from './vuex'
// 引入公共Js
import './common.js'
// 引入全局組件
// 方式一：
// Vue.component('headerBar', resolve => require(['./common/header'], resolve))
// Vue.component('tab-bar', resolve => require(['./common/footer'], resolve))
// 方式二：
import _g_component from './components.js'
Vue.use(_g_component)
new Vue({
el: '#app',
router,
store,
render: h => h(App)
})<template>
<div id="app">
<div class="vChat-wrapper flexbox flex-alignc">
<div class="vChat-panel" style="background-image: url(src/assets/img/placeholder/vchat__panel-bg01.jpg);">
<div class="vChat-inner flexbox">
<!-- //頂部按鈕(最大、最小、關閉) -->
<win-bar></win-bar>
<!-- //側邊欄 -->
<side-bar v-if="!$route.meta.hideSideBar"></side-bar>
<keep-alive>
<router-view class="flex1 flexbox"></router-view>
</keep-alive>
</div>
</div>
</div>
</div>
</template><style>
/* 引入公共樣式 */
@import './assets/fonts/iconfont.css';
@import './assets/css/reset.css';
@import './assets/css/layout.css';
</style>/*
* 頁面地址路由js
*/
import Vue from 'vue'
import Router from 'vue-router'
import store from '../vuex'
// 通過改寫router.go方法，當new Router 實例就包含back方法
Router.prototype.back = function(){
window.history.go(-1)
}
Vue.use(Router)
const router = new Router({
routes: [
// 登錄、注冊
{
path: '/login',
component: resolve => require(['../views/auth/login'], resolve),
meta: { hideSideBar: true },
},
{
path: '/register',
component: resolve => require(['../views/auth/register'], resolve),
meta: { hideSideBar: true },
},
//...
// 聊天頁面
{
path: '/chat',
component: resolve => require(['../views/chat/group-chat'], resolve),
meta: { requireAuth: true }
},
//...
]
});
export default routerrouter.beforeEach和next實現路由攔截驗證
// 注冊全局鉤子（攔截登錄狀態）
router.beforeEach((to, from, next) => {
const token = store.state.token
// 判斷該路由地址是否需要登錄權限
if(to.meta.requireAuth){
// 判斷token是否存在
if(token){
next()
}else{
next()
// 未登錄授權
wcPop({
content: '還未登錄授權！', anim: 'shake', style: 'background:#e03b30;color:#fff;', time: 2,
end: function(){
next({ path: '/login' })
}
});
}
}else{
next()
}
})?? 最后
如果你覺得這篇文章對你有幫助，麻煩點個「關注/轉發」，讓更多的人也能看到你的分享！
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
