Web 頁面性能衡量指標-以用戶為中心的效果指標

Web 頁面性能衡量指標-以用戶為中心的性能指標

以用戶為中心的性能指標是理解和改進站點體驗的關鍵點

一、以用戶為中心的性能指標

1. 指標是用來干啥的?

指標是用來衡量性能和用戶體驗的

2. 指標類型

  • 感知加載速度:網頁可以多快地加載網頁中的所有視覺元素并將其渲染到屏幕上

  • 加載響應速度:頁面加載和執行組件快速響應用戶互動所需的 JavaScript 代碼的速度

  • 運行時響應速度:網頁在加載后對用戶互動的響應速度

  • 視覺穩定性:頁面上的元素是否會以用戶意想不到的方式發生偏移,是否可能會干擾用戶的互動?

  • 流暢性:過渡和動畫是否以一致的幀速率渲染,并在一種狀態之間流暢地流動?

3. 要衡量的指標

3.1. FCP(First Contentful Paint)

從網頁開始加載到網頁內容的任何部分呈現在屏幕上所用的時間

3.2. LCP(Largest Contentful Paint)

從網頁開始加載到屏幕上呈現最大的文本塊或圖片元素所用的時間

3.3. INP(Interaction to Next Paint)

與網頁進行的每次 tapclick 或鍵盤互動的延遲時間

并根據交互的數量選擇頁面中最差的交互延遲作為單個代表性值來描述頁面的總體響應性

3.4. TBT(Total Blocking Time)

FCP 到可交互時間 (TTI) 之間的總時長

3.5. CLS(Cumulative Layout Shift)

從頁面開始加載到其生命周期狀態更改為隱藏期間發生的所有意外布局偏移的累計分數

3.6. TTFB(Time to First Byte)

網絡使用資源的第一個字節響應用戶請求所花費的時間

3.7. FID(First Input Delay)

用戶首次與網頁互動(即,點擊鏈接、點按按鈕或使用由 JavaScript 提供支持的自定義控件)到瀏覽器實際能夠開始處理事件處理腳本以響應相應互動的時間

二、FCP(First Contentful Paint )

1. 什么是 FCP?

FCP:從網頁開始加載到網頁內容的任何部分呈現在屏幕上所用的時間。

首次內容繪制 (FCP) 是一項以用戶為中心的重要指標,用于衡量感知的加載速度。

它標記了網頁加載時間軸中用戶可以看到屏幕上任何內容的第一個點。

FCP 衡量的是從用戶首次導航到相應網頁到該網頁的任何部分呈現在屏幕上所用的時間。對于此指標,內容是指文本、圖片(包括背景圖片)、<svg> 元素或非白色 <canvas> 元素。

2. FCP

image

FCP 在第二幀發生,因為這是第一個文本元素渲染到屏幕上的時間

3. 良好的 FCP 是多少時間?

為了提供良好的用戶體驗,網站的 FCP 最好不超過 1.8 秒。

較好的 FCP 值為 1.8 秒或更短。較差超過 3.0 秒。

在這里插入圖片描述

4. 如何衡量 FCP?

  • PageSpeed Insights

  • Chrome 用戶體驗報告

  • web-vitals JavaScript

  • Lighthouse

  • Chrome DevTools

  • PerformanceObserver 方法

5. 衡量 JS 中的 FCP

如需在 JavaScript 中測量 FCP,需使用 Paint Timing API

5.1. 簡單示例:
new PerformanceObserver((entryList) => {for (const entry of entryList.getEntriesByName('first-contentful-paint')) {console.log('FCP candidate:', entry.startTime, entry);}
}).observe({type: 'paint', buffered: true});

image

5.2. 指標與 API 的區別
  • API 會為后臺標簽頁中加載的網頁分派 first-contentful-paint ,但在計算 FCP 時應忽略這些網頁。只有當網頁始終在前臺運行時,系統才會考慮首次渲染時間。

  • 從往返緩存中恢復網頁時,API 不會報告 first-contentful-paint ,但在這些情況下,應衡量 FCP,因為用戶將它們視為不同的網頁訪問。

  • API 可能不會報告跨源 iframe 的繪制時間,但為了正確衡量 FCP,必須考慮所有幀。子幀可以使用該 API 將其繪制時間報告給父幀以進行匯總。

  • API 從導航啟動時開始測量 FCP,但對于預渲染的網頁,應通過 activationStart 測量 FCP

5.3. 使用 web-vitals JavaScript 庫來衡量 FCP

使用 web-vitals JavaScript 庫來衡量 FCP,而無需記住所有這些細微差異,該庫會盡可能處理這些差異

import {onFCP} from 'web-vitals';onFCP(console.log);

onFCP 源碼

6. 如何提高 FCP?

6.1. 提高特定網站的 FCP

可以運行 Lighthouse 性能審核,并關注審核建議的任何特定 opportunities 或者 diagnostics

6.2. 總體提高 FCP
  • 移除阻塞渲染的資源

  • 縮減 CSS 大小

  • 移除未使用的 CSS

  • 移除未使用的 JavaScript

  • 預先連接到所需的源

  • 縮短服務器響應時間 (TTFB)

  • 避免多次網頁重定向

  • 預加載密鑰請求

  • 避免網絡負載龐大

  • 采用高效的緩存政策提供靜態資源

  • 避免 DOM 規模過大

  • 最大限度地縮短關鍵請求深度

  • 確保文本在網頁字體加載期間保持可見狀態

  • 盡量減少請求數量,減少傳輸大小

三、LCP(Largest Contentful Paint )

1. 什么是 LCP?

LCP:從網頁開始加載到屏幕上呈現最大的文本塊或圖片元素所用的時間

LCP 報告的是窗口中可見最大圖片或文本塊相對于用戶首次導航到網頁的呈現時間

LCP 包含從上一個網頁開始的所有卸載時間、連接設置時間、重定向時間和首字節時間 (TTFB)

2. 良好的 LCP 是多少時間?

為了提供良好的用戶體驗,網站應努力將 LCP 控制在 2.5 秒以內。

在這里插入圖片描述

2.5 s 或者更短

3. 需要考慮哪些元素?

Largest Contentful Paint 考慮的元素類型包括:

  • <img> 元素(第一幀呈現時間用于 GIF 或動畫 PNG 等動畫內容)

  • <svg> 元素內的 <image> 元素

  • <video> 元素(系統會使用視頻的海報圖片加載時間或第一幀顯示時間,以較早者為準)

  • 一個元素,帶有使用 url() 函數加載的背景圖片

  • 包含文本節點或其他內嵌級文本元素子元素的塊級元素。

后面可能會增加其他元素

4. 如何確定元素的大小?

LCP 報告的元素的大小通常是用戶在窗口中可見的大小,如果元素延伸到窗口之外,或者元素被剪切或有不可見的溢出,這些部分不計入元素的大小。

對于根據固有尺寸調整過大小的圖片元素,報告的尺寸為可見尺寸或固有尺寸(以較小者為準)。

對于文本元素,LCP 只會考慮能夠包含所有文本節點的最小矩形。

對于所有元素,LCP 都不會考慮使用 CSS 應用的外邊距、內邊距或邊框。

5. 什么時候報告 LCP?

網頁通常會分階段加載,因此,網頁上最大的元素可能會發生變化。

為了應對這種可能發生的變化,瀏覽器在繪制完第一幀后,會立即分派 largest-contentful-paint 類型的 PerformanceEntry,用于標識鏈接最大的內容元素,在渲染后續幀后,只要最大內容元素發生變化,它就會再分派一個 PerformanceEntry

元素只有在呈現并對用戶可見后,才能被視為最大的內容元素。尚未加載的圖片不會被視為已渲染。在字體屏蔽期間,文本節點也不會使用網頁字體。在這種情況下,系統可能會將較小的元素報告為最大的內容元素,但如果這個較大的元素呈現完畢,系統便會創建另一個 PerformanceEntry

除了延遲加載圖片和字體之外,網頁還可能會在新內容可用時向 DOM 添加新元素。如果這些新元素中的任何一個大于之前的最大內容元素,系統還會報告新的 PerformanceEntry

如果從窗口甚至 DOM 中移除了最大的內容元素,除非渲染了較大的元素,否則它仍然是最大的內容元素

一旦用戶與網頁互動(通過點按、滾動或按鍵),瀏覽器就會停止報告,因為用戶互動通常會改變向用戶顯示的內容(特別是滾動時)。

6. 如何衡量 LCP?

  • Chrome User Experience Report

  • PageSpeed Insights

  • web-vitalsJavaScript library

  • Chrome DevTools

  • Lighthouse

  • WebPageTest

  • PerformanceObserver 方法

7. 在 JS 中衡量 LCP

7.1. 簡單示例
new PerformanceObserver((entryList) => {for (const entry of entryList.getEntries()) {console.log('LCP candidate:', entry.startTime, entry);}
}).observe({type: 'largest-contentful-paint', buffered: true});

image

7.2. 指標與 API 的區別
  • API 將為后臺標簽頁中加載的頁面分派 largest-contentful-paint,但在計算 LCP 時應忽略這些頁面。

  • 在頁面進入后臺后,API 將繼續分派 largest-contentful-paint,但在計算 LCP 時應忽略這些(只有在頁面始終在前臺運行時才可以考慮元素)。

  • 從往返緩存中恢復網頁時,該 API 不會報告 largest-contentful-paint ,但應在在這些情況下衡量 LCP ,因為用戶對它們的訪問體驗是不同的。

  • API 不會考慮 iframe 中的元素,但該指標會考慮,因為它們是網頁用戶體驗的一部分。

  • API 從導航開始就測量 LCP,但對于預渲染的網頁,LCP 應從 activationStart 開始測量,因為 LCP 對應于用戶實際體驗到的 LCP 時間。

7.3. 使用 web-vitals JavaScript 庫衡量 LCP

可以使用 web-vitalsJavaScript 庫來衡量 LCP,而無需記住所有這些細微差異

import {onLCP} from 'web-vitals';onLCP(console.log);

onLCP 源碼

8. 如何提高 LCP?

  • 消除加載延遲
  • 消除元素渲染延遲
  • 縮短資源加載時長
  • 縮短第一個字節所用的時間

四、INP(Interaction to Next Paint )

1. 什么是 INP?

INP:與網頁進行的每次 tapclick 或鍵盤互動的延遲時間

良好的響應速度意味著網頁對互動的響應速度很快。

當網頁響應互動時,瀏覽器會在所繪制的下一幀中提供_視覺反饋。

有些互動自然會比其他互動花費更長的時間,但對于特別復雜的互動,必須快速提供一些初始視覺反饋,讓用戶知道正在發生的事情。

INP 的目的不是測量互動的所有最終效果,而是下一次繪制被阻止的時間。通過延遲視覺反饋,用戶可能會覺得頁面響應速度不夠快,而 INP 旨在幫助開發者衡量這部分用戶體驗。

2. INP

image

3. 良好的 INP 是多少時間?

一般 200 ms 以內

  • INP 低于或等于 200 毫秒表示網頁響應良好

  • INP 高于 200 毫秒且低于或等于 500 毫秒表示網頁的響應能力需要改進

  • INP 高于 500 毫秒表示網頁響應速度很差

在這里插入圖片描述

4. 什么是互動?

在這里插入圖片描述

互動的主要驅動因素通常是 JavaScript,但瀏覽器確實會通過并非由 JavaScript 提供支持的控件(例如復選框、單選按鈕和由 CSS 提供支持的控件)提供互動性。
INP 而言,只觀察以下互動類型

  • 使用鼠標點擊。
  • 點按帶有觸摸屏的設備。
  • 按實體鍵盤或屏幕鍵盤上的某個鍵。

互動發生在主文檔或文檔內嵌的 iframe 中。

系統會在用戶離開頁面時計算該頁面的 INP。結果會得到一個能夠代表網頁在其整個生命周期內的整體響應能力的值。INP 較低意味著網頁能夠可靠地響應用戶輸入。

5. INP 與 First Input Delay (FID) 有何不同?

INPFirst Input Delay (FID) 的繼任指標。雖然兩者都是響應速度指標,但 FID 僅衡量了網頁上首次互動的輸入延遲。INP 通過觀察網頁上的所有互動來改進 FID,即從輸入延遲開始,到運行事件處理腳本所需的時間,再到瀏覽器繪制下一幀。
這些差異意味著 INPFID 是不同類型的響應能力指標。FID 是用于評估網頁對用戶的首次展示的加載響應速度指標,而無論網頁互動在何時發生,INP 都是更可靠的整體響應能力指標。

6. 如果未報告 INP 值,該怎么辦?

網頁可能不會返回任何 INP 值。導致這種情況的原因可能有很多,其中包括以下原因:

  • 頁面已加載,但用戶從未點擊、點按或按鍵盤上的鍵。
  • 網頁已加載,但用戶使用不衡量的手勢與網頁互動。
  • 該網頁正被機器人訪問,但該機器人尚未編寫與該網頁交互的腳本。

7. 如何改進 INP?

  • 優化耗時較長的任務

  • 優化輸入延遲

  • 腳本評估和耗時較長的任務

  • 使用 Web Worker 在瀏覽器的主線程之外運行 JavaScript

  • 避免大型、復雜的布局和布局抖動

  • 縮小樣式計算的范圍并降低其復雜性

五、 TBT(Total Blocking Time)

1. 什么是 TBT?

TBT:總阻塞時間,從 FCP 到可交互時間 (TTI) 之間的總時長,其中主線程處于阻塞狀態的時間足夠長,足以阻止輸入響應能力。

每當存在長任務(一種在主線程上運行時間超過 50 毫秒 (ms) 的任務)時,主線程就會被視為阻塞。

我們說主線程處于阻塞狀態,因為瀏覽器無法中斷正在進行的任務。如果用戶嘗試在耗時較長的任務過程中與頁面互動,瀏覽器必須等待任務完成才能響應。

如果主線程處于阻塞狀態的時間超過 50 毫秒,用戶很可能會注意到延遲,并認為網頁運行緩慢或損壞。

2. 良好的 TBT 是多少時間?

網站的 TBT 應低于 200 毫秒。

TBT 時間(以毫秒為單位)顏色編碼
0 - 200綠色(快速)
200-600橙色(中等)
600 多個紅色(慢)

3. 如何提高 TBT

  • 將所有工作拆分為運行時間不超過 50 毫秒的代碼塊,并在合適的位置和時間運行這些代碼塊。

  • 降低第三方代碼的影響

  • 縮短 JavaScript 執行時間

  • 去除不必要的 JS 加載、解析、執行

  • 盡量減少主線程工作

  • 盡量減少請求數量,減少傳輸大小

六、 CLS(Cumulative Layout Shift)

1. 什么是 CLS

CLS:從頁面開始加載到其生命周期狀態更改為隱藏期間發生的所有意外布局偏移的累計得分。

每當可見元素的位置從渲染的幀更改為下一幀時,都會發生布局偏移。

1.1. 什么是布局偏移

布局偏移由 Layout Instability API 定義。

只要窗口內可見的元素在兩幀之間更改起始位置,該 API 就會報告 layout-shift 。此類元素被視為不穩定元素。

image

1.2. CLS

當資源以異步方式加載或 DOM 元素被動態添加到頁面的現有內容之前,頁面內容通常會發生意外移動。

布局偏移的原因可能包括尺寸未知的圖片或視頻、呈現的字體大于或小于其初始后備值,或者第三方廣告或微件會自行調整大小。

由于網站在開發過程中的運行情況與其用戶的體驗之間的差異,會使此問題變得更糟。例如:

  • 個性化內容或第三方內容在開發和生產環境中的行為通常有所不同。

  • 測試圖片通常已存在于開發者的瀏覽器緩存中,但為最終用戶加載所需時間更長。

  • 在本地運行的 API 調用速度通常非常快,以至于開發過程中出現明顯的延遲,在生產環境中可能就會出現嚴重的延遲。

2. 頁面生命周期

在這里插入圖片描述

3. 良好的 CLS 是多少?

為了提供良好的用戶體驗,網站應努力使 CLS 得分不超過 0.1

在這里插入圖片描述

4. 如何衡量 CLS

  • Chrome 用戶體驗報告

  • PageSpeed Insights

  • web-vitals JavaScript

  • Chrome DevTools

  • Lighthouse

  • WebPageTest

  • PerformanceObserver 方法

5. JS 中衡量 CLS

5.1. 簡單示例
new PerformanceObserver((entryList) => {for (const entry of entryList.getEntries()) {console.log('Layout shift:', entry);}
}).observe({type: 'layout-shift', buffered: true});
5.2. 指標與 API 的區別
  • 如果網頁是在后臺加載的,或者在瀏覽器繪制任何內容之前在后臺播放,則系統不應報告任何 CLS 值。

  • 如果某個網頁從往返緩存中恢復,其 CLS 值應重置為零,因為用戶此次體驗是一次不同的網頁訪問。

  • API 不會針對 iframe 中發生的偏移報告 layout-shift ,但該指標會報告這些變化,因為它們會影響網頁的用戶體驗。

5.3. 使用 web-vitalsJavaScript 庫衡量 CLS

可以使用 web-vitalsJavaScript 庫來衡量 CLS

import {onCLS} from 'web-vitals';onCLS(console.log);

onCLS 源碼

6. 如何改善 CLS?

  • 改善沒有尺寸的圖片

  • 給嵌入內容的延遲加載預留空間

  • 動畫:盡量使用 transform 平移動畫、縮放、旋轉/傾斜元素

  • 網絡字體優化

七、TTFB(Time to First Byte)

1. 什么是 TTFB?

TTFB:網絡使用資源的第一個字節響應用戶請求所需的時間。

TTFB 是以下請求階段的總和:

  • 重定向時間

  • Service Worker 啟動時間(如果適用)

  • DNS 查找

  • 連接和 TLS 協商

  • 請求,直到響應的第一個字節到達

縮短連接設置時間和后端的延遲時間有助于降低 TTFB

2. 良好的 TTFB 是多少時間?

大多數網站都應盡量將 TTFB 控制在 0.8 秒以內。

在這里插入圖片描述

3. 如何衡量 TTFB?

  • Chrome 用戶體驗報告
  • web-vitalsJavaScript
  • WebPageTest
  • PerformanceObserver 方法

4. JS 衡量 TTFB

4.1. 簡單示例
new PerformanceObserver((entryList) => {const [pageNav] = entryList.getEntriesByType('navigation');console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({type: 'navigation',buffered: true
});

image

4.2. 使用 web-vitalsJavaScript 庫衡量 TTFB

使用 web-vitalsJavaScript 庫也可以在瀏覽器中以較低的復雜性測量 TTFB

import {onTTFB} from 'web-vitals';onTTFB(console.log);

onTTFB 源碼

5. 如何優化 TTFB?

  • 具體的項目平臺

  • 托管服務商

  • CDN

  • 盡可能的使用緩存

  • 避免多次重定向

  • 使用 service worker

八、FID(First Input Delay)

1. 什么是 FID?

FID:從用戶首次與網頁互動到瀏覽器實際能夠開始處理事件處理腳本以響應相應互動的時間。

2. 良好的 FID 是多少時間?

為了提供良好的用戶體驗,網站應努力將 FID 控制在 100 毫秒以內

在這里插入圖片描述

3. 如何衡量 FID?

FID 指標只能在實際操作衡量,因為它需要真實用戶的網頁互動

  • Chrome 用戶體驗報告

  • PageSpeed Insights

  • web-vitals JavaScript

  • PerformanceObserver

4. 衡量 JS 中的 FID

4.1. 簡單示例
new PerformanceObserver((entryList) => {for (const entry of entryList.getEntries()) {const delay = entry.processingStart - entry.startTime;console.log('FID candidate:', delay, entry);}
}).observe({type: 'first-input', buffered: true});

image

4.2. 使用 web-vitals JavaScript 庫來衡量 FID
import {onFID} from 'web-vitals';onFID(console.log);

onFID 源碼

5. 如何優化 FID?

  • 拆分長任務

  • 使用 web worker

  • 縮短 JS 執行時間

  • 減少多余的 JS

  • 針對具體的情況優化頁面

九、總結

  • 本文整體的概括了以用戶為中心的性能衡量指標
  • 也對每個指標進行了具體的描述和提出優化方案
  • 希望對大家有幫助

參考

  • Web Vitals
  • Web Metrics

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/bicheng/22314.shtml
繁體地址,請注明出處:http://hk.pswp.cn/bicheng/22314.shtml
英文地址,請注明出處:http://en.pswp.cn/bicheng/22314.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

如何在vs code中安裝JavaFX

目錄 下載JavaFX 配置vs code工程 編寫測試代碼 下載JavaFX 網站鏈接:https://openjfx.io 選擇如下的版本

從1.0到4.0,看看你公司的費控模式是第幾代?

早在2021年9月&#xff0c;艾媒咨詢在《2021H1企業費控報銷服務專題研究報告》中&#xff0c;第一次對企業費用管控模式的進化歷程進行了清晰的劃代&#xff1a;1.0手工模式、2.0網報模式、3.0移動報銷模式、4.0智能費控模式。 2022年&#xff0c;在《中國企業費用管理發展白皮…

vr樣板房實景漫游展示制作解決了地產商難題

家具和軟裝銷售中&#xff0c;如何直觀展示產品優勢一直是老板們的難題。口頭描述往往難以讓客戶真正感受到產品的獨特之處&#xff0c;這不僅影響了銷售效果&#xff0c;也增加了溝通的難度。但現在&#xff0c;我們有了全新的解決方案——樣板房VR全景編輯軟件! 樣板房VR全景…

精打細算:可燃氣體報警器檢驗收費的合理規劃與管理

隨著工業化的快速發展&#xff0c;可燃氣體報警器已經成為各類工業場所不可或缺的安全設備。 它的主要功能是在可燃氣體濃度超標時發出警報&#xff0c;有效預防和減少火災、爆炸等安全事故的發生。 然而&#xff0c;為了確保報警器能夠持續、準確地發揮作用&#xff0c;定期…

科技盛事即將拉開帷幕,WWDC2024官宣定檔,亮點搶先看!

隨著全球科技愛好者們對蘋果年度開發者大會&#xff08;WWDC&#xff09;的期待日益高漲&#xff0c;今年的WWDC24&#xff08;蘋果全球開發者大會&#xff09;&#xff0c;正式宣告這一科技盛事將于北京時間6月11日凌晨1點拉開帷幕。距離WWDC 2024的召開只剩下一周時間&#x…

【電子取證篇】電子數據取證標準合集更新202405(附下載)

【電子取證篇】電子數據取證標準合集更新202405&#xff08;附下載&#xff09; 電子數據取證相關標準合集&#xff0c;按照司法鑒定職業分類目錄&#xff0c;對電子數據鑒定可能涉及的測試、測量方法進行標準歸類&#xff0c;更新于2024年05月14日—【蘇小沐】 &#xff08;…

前端localForage存儲數據使用教程

前言 前端本地化存儲算是一個老生常談的話題了&#xff0c;我們對于 cookies、Web Storage&#xff08;sessionStorage、localStorage&#xff09;的使用已經非常熟悉&#xff0c;在面試與實際操作之中也會經常遇到相關的問題&#xff0c;但這些本地化存儲的方式還存在一些缺陷…

「技能培訓」硬蛋學堂職業技能培訓,助你掌握未來技術!!!

硬蛋學堂職業技能培訓 &#x1f680; 火熱報名中&#xff01; &#x1f680; &#x1f31f; 2024年已過半&#xff0c;我們迎來了年中的轉折點。你是否還在為年初制定的宏偉計劃而奮斗&#xff1f;是否渴望在職場上更進一步&#xff0c;卻苦于缺乏機會和資源&#xff1f; &a…

systemctl系統控制器

systemctl系統控制器 作用&#xff1a;控制服務的開啟、關閉、開機自啟、禁止開機自啟 查看linux中所有的服務 systemctl --type service 檢查服務狀態 systemctl is-active 服務名 &#xff08;簡要&#xff09;systemctl status 服務名&#xff08;詳情&#xff09; 開…

期權懂題庫免費!期權開戶測試難嗎?多少分算合格通過?

今天帶你了解期權懂題庫免費&#xff01;期權開戶測試難嗎&#xff1f;多少分算合格通過&#xff1f;期權開戶測試通常要求投資者達到一定的合格分數&#xff0c;以確保他們具備足夠的理解和知識來參與期權交易。 期權開戶測試難嗎&#xff1f; 期權開戶測試的難度因人而異&am…

【設計模式深度剖析】【1】【行為型】【模板方法模式】| 以烹飪過程為例加深理解

&#x1f448;?上一篇:結構型設計模式對比 文章目錄 模板方法模式定義英文原話直譯如何理解呢&#xff1f; 2個角色類圖代碼示例 應用優點缺點使用場景 示例解析&#xff1a;以烹飪過程為例類圖代碼示例 模板方法模式 模板方法模式&#xff08;Template Method Pattern&…

C++linux下使用clog和重定向實現寫日志

Clinux下使用clog和重定向實現寫日志 實現文件基本功能測試編譯運行額外知識點 實現文件 LogUtil.hpp /** * 通用日志實現 * lsl * 2024-06-04 */#ifndef LOGUTIL_HPP #define LOGUTIL_HPP #include<iostream> #include <time.h> #include <cstring> #defi…

LED驅動IC:HC2161,升壓型LED恒流驅動ic,供應LED燈杯單節電池以上供電的LED燈串平板顯示LED背光大功率LED照明

LED驅動IC&#xff1a; HC2161:升壓型LED恒流驅動ic 概述&#xff1a;HC2161是一款高效率、高精度的升 壓型大功率LED恒流驅動控制芯片。 HC2161內置高精度誤差放大器&#xff0c;固 定關斷時間控制電路&#xff0c;恒流驅動電路等&#xff0c; 特別適合大功率、多個高亮…

七年

七年 我&#xff0c;回來了&#xff0c;七年后。回看之前的文章&#xff0c;當初的情意濃濃&#xff0c;患得患失&#xff0c;真的是恍如隔世。 經歷了重重波折&#xff0c;父母反對&#xff0c;奔赴廣州&#xff0c;云南危機&#xff0c;房名危機&#xff0c;都沒把我們拆散…

鴻蒙開發接口定制管理:【@ohos.configPolicy (配置策略)】

配置策略 配置策略提供按預先定義的定制配置層級獲取對應定制配置目錄和文件路徑的能力。 說明&#xff1a; 本模塊首批接口從API version 8開始支持。后續版本的新增接口&#xff0c;采用上角標單獨標記接口的起始版本。 本模塊接口均為系統接口&#xff0c;三方應用不支持調…

Kaggle平臺進行Python版本降級

前言 最近在復現語音合成模型VITS&#xff0c;由于目前沒有算力故去Kaggle白嫖運算資源。 VITS的運行環境要求如下 Cython0.29.21 librosa0.8.0 matplotlib3.3.1 numpy1.18.5 phonemizer2.2.1 scipy1.5.2 tensorboard2.3.0 torch1.6.0 torchvision0.7.0 Unidecode1.1.1截至2…

21.過擬合和欠擬合示例

1. 背景介紹 在機器學習和深度學習中&#xff0c;過擬合和欠擬合是兩個非常重要的概念。過擬合指的是模型在訓練數據上表現很好&#xff0c;但在新的測試數據上效果變差的情況。欠擬合則是指模型無法很好地擬合訓練數據的情況。這兩種情況都會導致模型無法很好地泛化&#xff…

視頻號小店,常見的違規條例!98%的商家必犯的違規細節!

哈嘍~我是電商月月 做電商&#xff0c;不管哪個平臺都有屬于自己的規則條例&#xff0c;這些違規細節&#xff0c;一定要提前了解 所以今天&#xff0c;月月就給大家分享一下&#xff0c;做視頻號小店的話&#xff0c;有哪些常見的違規細節 這里我們分三點講解 一&#xff…

【分享】兩種方法禁止修改Word文檔

對于比較重要的Word文件&#xff0c;不想被隨意編輯修改&#xff0c;可以試試以下兩個方法&#xff0c;不清楚的小伙伴&#xff0c;一起來看看吧&#xff01; 方法1&#xff1a;設置“只讀方式” 我們可以給Word文檔設置以“只讀方式”打開&#xff0c;這樣就算編輯修改了文檔…

如何通過SD-WAN提升企業溝通效率

在數字化飛速發展的今天&#xff0c;企業對大數據和實時商業數據傳輸的需求日益增長。傳統的專線連接技術已無法滿足企業對快速部署商業應用和高效網絡連接的需求。在這種背景下&#xff0c;SD-WAN成為提升企業網絡溝通效率的關鍵技術。 SD-WAN的靈活部署模式 SD-WAN提供了高度…