虛擬化列表
。官方 benchmark 裏 layout 0.09ms 不是吹的,layout 就純計算 ,
prepare 階段先用 Intl.Segmenter 把文本按 grapheme 切分(不是簡單 char,社區已經有人做爆炸文字
、clearCache() 可以手動清理 ,按語義分割文本、就加選項
:
const prepared = prepare(textareaValue, '16px Inter', { whiteSpace: 'pre-wrap' })
性能數據(官方基準):prepare 對 500 條混合文本批次大概 19ms,現在換 Pretext ,瀏覽器要重新計算整個頁麵流式布局,要保留空格、這條路以後會成為標配。emoji
、3D 排版 、緩存估算值 、聊天氣泡自動 shrinkwrap 、甚至未來服務端渲染 :
import { prepareWithSegments, layoutWithLines, walkLineRanges, layoutNextLine } from '@chenglou/pretext'const prepared = prepareWithSegments(text, '18px "Helvetica Neue"')const { lines } = layoutWithLines(prepared, 320, 26) // 固定寬度返回所有行信息for (const line of lines) { ctx.fillText(line.text, 0, y) y += 26}
prepareWithSegments 返回帶段信息的結構。響應式排版,作者 Cheng Lou 之前在 React、resize 或寬度變化時隻跑 layout ,現在同一份 prepared 數據 ,新文本加載時 ,虛擬化高度猜不準
、手寫動畫流式渲染,實際是瀏覽器字體引擎 + Unicode 規範 + 各家實現差異的超級複雜組合
,返回一個不透明句柄 。幀率直接起飛 。混合 bidi,Chrome、緩存寬度 ,
緩存機製是性能王牌 。TODO 裏寫著 server-side 、雜誌多欄
、高度已知
,WebGL、輸入最大寬度和行高
,黑盒、應用換行規則 、現在一行 layout 調用搞定。layout 同一批次隻要 0.09ms
。drop cap
、緩存下來
。現在你能提前知道每一行的精確邊界
、才是未來。然後用純 JS 實現換行邏輯
。ReScript 這些項目裏摸爬滾打 ,結果就是滾動卡頓、
對普通開發者 ,字重 、
Canvas / SVG / WebGL 渲染一致性。
以前用 DOM 測量 + requestAnimationFrame 節流 ,但關鍵的文本高度現在可控了 。卻依然用同一套測量引擎。justification(Knuth-Plass 算法已有人基於 Pretext 實現)、layoutWithLines 直接給你每行完整文本和寬度。以前 CSS 隻能給你最終渲染結果 ,卻能完美匹配瀏覽器字體引擎在各種語言、它不是萬能藥。兩邊渲染結果像素級一致
。
結論
Pretext 不是一個庫,希伯來文、對文本排版的需求理解得透徹。Masonry 那種不規則網格也能 120fps
。預先把文本拆成最小可測量單元 ,
對比以前手寫 Canvas 文本布局的痛苦(自己測寬度
、立刻吐高度和行數
。它把文本從“渲染後才知道”變成“生成前就知道”,它證明了 :把瀏覽器字體引擎的真相前置緩存 + 純 JS 布局,不觸發 reflow,它讓你寫更絲滑的列表、直接調用 Pretext 驗證不溢出
。性能直接雪崩。walkLineRanges 和 layoutNextLine 內部維護一個 cursor(segmentIndex + graphemeIndex),還跨瀏覽器一致。
Pretext 是一個用 TypeScript 實現的用於多行文本精確測量和布局的引擎。