維修簽字頁最容易被低估的地方是把它理解成“在畫布上畫幾條線”。實際接入時畫面上同時存在幾類不同性質(zhì)的數(shù)據(jù)手指或觸控筆剛落下時的當(dāng)前筆畫、已經(jīng)完成的筆畫、歷史記錄中的只讀筆跡以及頁面提示的本地確認(rèn)狀態(tài)。它們看起來都會落在同一塊 Canvas 上卻不能用同一條寫入路徑處理。我在這個場景里遇到的表象很簡單點了撤銷、清空、歷史預(yù)覽、退出預(yù)覽或抗鋸齒開關(guān)后頁面文字已經(jīng)變了簽名板卻可能仍然保留舊筆跡。繼續(xù)書寫時用戶會不確定自己是在補寫當(dāng)前簽名還是意外改動一條歷史記錄點“確認(rèn)并歸檔”后又容易把本地頁面記錄誤認(rèn)為真實工單已經(jīng)回寫。所以我沒有把“重新繪制”當(dāng)成一個補丁而是把它放到每次狀態(tài)變更之后。這里的重繪只做一件事用當(dāng)前允許展示的筆跡重新生成 Canvas 像素。它能證明頁面已按本地狀態(tài)更新不能證明簽名已提交到外部系統(tǒng)、真實工單已經(jīng)歸檔或任意設(shè)備上的筆跡效果完全一致。先把問題拆成四層在維修簽名場景里先分清數(shù)據(jù)所在的層比直接追某個按鈕更重要。層次頁面中的數(shù)據(jù)可以確認(rèn)不能據(jù)此確認(rèn)觸摸輸入activeStroke、觸點坐標(biāo)當(dāng)前觸摸正在被頁面采集簽名已有效、已確認(rèn)或已保存新建簽名strokes已采集的本地筆畫可參與繪制已回寫真實工單或已持久化歷史預(yù)覽signatureHistory、selectedHistoryId指定歷史記錄可被選中并只讀展示歷史記錄來自真實服務(wù)端頁面狀態(tài)signatureStatus、viewMode、antialiasEnabled當(dāng)前頁面給出的本地提示和展示模式后端、設(shè)備或業(yè)務(wù)流程已經(jīng)完成這四層都可能觸發(fā)視覺變化但不能互相替代。例如signatureStatus寫著“本地確認(rèn)已記錄”只能說明當(dāng)前組件更新了狀態(tài)文案signatureHistory多了一條記錄才能說明頁面內(nèi)存中新增了一條本地歷史項兩者都不能推出真實工單已收到簽名。把證據(jù)層拆開后面的每一次重繪才不會被寫成虛假的業(yè)務(wù)成功。場景解說此圖應(yīng)記錄新建簽名模式、簽名板和歷史列表的頁面基線只能證明頁面已展示不能證明已有有效簽名或工單回寫。先定重繪的唯一輸入當(dāng)前應(yīng)當(dāng)可見的筆跡這個頁面有“新建”和“預(yù)覽”兩種模式。新建模式下Canvas 應(yīng)顯示當(dāng)前用戶寫入的strokes預(yù)覽模式下Canvas 必須改為顯示被選中歷史記錄的strokes。如果繪制函數(shù)直接引用this.strokes那么進入歷史預(yù)覽后仍會畫出新建簽名頁面的“歷史預(yù)覽”標(biāo)簽就成了一個只有文字變化的假狀態(tài)。源碼把這個選擇收斂到visibleStrokes()private visibleStrokes(): Stroke[] { const record this.selectedHistory(); return this.viewMode preview record ? record.strokes : this.strokes; }這段代碼能夠證明渲染前會根據(jù)viewMode和已選歷史記錄在歷史筆跡與當(dāng)前筆跡之間作出本地選擇。它不能證明record.strokes一定來自服務(wù)端也不能說明這些坐標(biāo)已經(jīng)被持久化頁面里預(yù)置的歷史項和本地確認(rèn)新增的歷史項都只是當(dāng)前組件可展示的數(shù)據(jù)。我把它看作繪制層的“唯一入口”。觸摸、撤銷、清空和預(yù)覽切換可以分別修改不同狀態(tài)但redraw()不再判斷業(yè)務(wù)動作本身只取visibleStrokes()。這樣做的好處是排查時可以把問題分開若模式標(biāo)簽已變而畫面沒變先檢查是否觸發(fā)redraw()若已觸發(fā)重繪卻仍是錯誤筆跡再檢查visibleStrokes()的選擇條件而不是把所有懷疑堆到觸摸事件上。一筆簽名不是一次賦值而是一段觸摸生命周期簽名采集從handleSignatureTouch()進入。它先拒絕預(yù)覽狀態(tài)下的寫入再按Down、Move、Up與Cancel處理同一條筆畫private handleSignatureTouch(event: TouchEvent): void { if (this.viewMode preview) { this.signatureStatus 歷史簽名只讀請先退出預(yù)覽后新建簽名; return; } const point this.pointFromTouch(event); if (event.type TouchType.Down point) { const stroke: Stroke { points: [point] }; this.activeStroke stroke; this.strokes [...this.strokes, stroke]; this.signatureStatus 正在采集現(xiàn)場簽名…; this.redraw(); return; } if (event.type TouchType.Move point this.activeStroke) { this.activeStroke.points.push(point); this.strokes [...this.strokes]; this.redraw(); return; } if (event.type TouchType.Up || event.type TouchType.Cancel) { if (point this.activeStroke) { this.activeStroke.points.push(point); } this.activeStroke undefined; this.signatureStatus this.validStrokeCount() 0 ? 筆跡已采集可確認(rèn)本地歸檔 : 筆跡過短請重新簽字; this.redraw(); } }這段代碼能確認(rèn)三件事。第一按下時會創(chuàng)建一條包含起點的Stroke并將它同時設(shè)置為活動筆畫和當(dāng)前筆畫列表的一員。第二移動事件把后續(xù)坐標(biāo)追加到這條活動筆畫中再通過this.strokes [...this.strokes]讓頁面狀態(tài)重新參與渲染。第三抬起或取消時都會結(jié)束活動筆畫并根據(jù)當(dāng)前有效筆畫數(shù)更新本地提示。它同樣劃出了兩個邊界。觸摸事件被收到不等于筆跡已經(jīng)有效Cancel發(fā)生時頁面只是在本地結(jié)束本次采集不能把它解釋為用戶完成簽字。另一個邊界是坐標(biāo)來源pointFromTouch()只取當(dāng)前觸點的x、y代碼沒有做壓感、筆鋒或身份認(rèn)證因此不能把這塊畫布描述為具有電子簽名法律效力的簽署鏈路。為什么移動一次就要重繪一次Canvas 不是聲明式文本組件。strokes數(shù)組更新后之前執(zhí)行過的moveTo、lineTo和stroke不會自動根據(jù)新數(shù)組改寫已經(jīng)存在的像素。因此移動事件只追加坐標(biāo)而沒有redraw()時數(shù)據(jù)層的筆畫會越來越長畫布上卻仍停在舊輪廓等到抬筆時才一次性繪制用戶看到的是斷續(xù)或滯后的反饋。頁面的redraw()處理順序是固定的先判斷畫布是否已經(jīng)準(zhǔn)備好再應(yīng)用當(dāng)前抗鋸齒設(shè)置清除舊像素、鋪設(shè)白底與簽名基線最后按模式繪制visibleStrokes()。private redraw(): void { if (!this.canvasReady || this.canvasWidth 0 || this.canvasHeight 0) { return; } this.applyAntialias(); this.context.clearRect(0, 0, this.canvasWidth, this.canvasHeight); this.context.fillStyle #FFFFFF; this.context.fillRect(0, 0, this.canvasWidth, this.canvasHeight); this.context.strokeStyle #D5E0EA; this.context.lineWidth 1; this.context.beginPath(); this.context.moveTo(34, this.canvasHeight - 64); this.context.lineTo(this.canvasWidth - 34, this.canvasHeight - 64); this.context.stroke(); if (this.viewMode preview) { this.drawStrokes(this.context, this.visibleStrokes(), this.canvasWidth / 240, this.canvasHeight / 130, #172D40, 5); } else { this.drawStrokes(this.context, this.visibleStrokes(), 1, 1, #172D40, 5); } }這里“清除后完整重畫”不是多余操作。撤銷、清空和模式切換都可能使舊筆畫不再屬于當(dāng)前可見集合。若只在新增筆畫時繼續(xù)lineTo就沒有可靠方式擦掉最后一筆、整頁筆跡或新建模式下殘留的歷史預(yù)覽先清空再從visibleStrokes()重建才能讓畫布與當(dāng)前狀態(tài)一致。這段代碼能夠確認(rèn)當(dāng)前組件使用“狀態(tài)是來源、Canvas 是投影”的方式工作。它不能確認(rèn)渲染幀率、觸控延遲或不同屏幕密度下的肉眼效果因為源碼沒有提供性能采樣、真機記錄或設(shè)備對照數(shù)據(jù)。頁面運行后出現(xiàn)筆跡也只能證明本地 Canvas 已繪制這些點。筆跡如何真正落到 Canvas 上drawStrokes()并不保存業(yè)務(wù)數(shù)據(jù)它只把已經(jīng)存在的坐標(biāo)按給定比例轉(zhuǎn)為線段。每一條少于兩個點的筆畫會被跳過以免“剛按下一個點”被錯誤畫成一條線private drawStrokes(context: CanvasRenderingContext2D, strokes: Stroke[], scaleX: number, scaleY: number, color: string, lineWidth: number): void { context.strokeStyle color; context.lineWidth lineWidth; context.lineCap round; context.lineJoin round; strokes.forEach((stroke: Stroke) { if (stroke.points.length 2) { return; } context.beginPath(); context.moveTo(stroke.points[0].x * scaleX, stroke.points[0].y * scaleY); for (let index 1; index stroke.points.length; index 1) { context.lineTo(stroke.points[index].x * scaleX, stroke.points[index].y * scaleY); } context.stroke(); }); }lineCap round與lineJoin round說明頁面選擇圓形端點和圓形連接來呈現(xiàn)筆跡它們描述的是當(dāng)前本地繪制樣式不是對簽名真實性或圖像質(zhì)量的認(rèn)證。scaleX、scaleY則解釋了預(yù)覽與新建模式為何不能完全沿用同一坐標(biāo)比例歷史記錄按 240×130 的基準(zhǔn)坐標(biāo)保存在主簽名板預(yù)覽時需要放大到當(dāng)前畫布尺寸新建筆跡還處于當(dāng)前畫布坐標(biāo)中可以按 1:1 繪制。若忽略這一點歷史預(yù)覽通常會出現(xiàn)兩種問題要么筆跡被擠在左上角要么通過錯誤比例拉伸到超出邊界。這里的比例換算能證明坐標(biāo)映射存在不能證明它已適配所有窗口尺寸需要在具體運行環(huán)境中觀察onAreaChange后的實際寬高才能評價視覺效果。場景解說此圖應(yīng)記錄選中歷史記錄后的只讀預(yù)覽、簽名板筆跡及“歷史預(yù)覽”狀態(tài)只能證明本地選中記錄被重繪不能證明歷史記錄已從外部系統(tǒng)查詢成功。歷史預(yù)覽必須禁止寫入而不只是把按鈕藏起來簽名歷史面板通過selectHistoryRecord()切換到預(yù)覽模式private selectHistoryRecord(id: string): void { this.selectedHistoryId id; this.viewMode preview; this.activeStroke undefined; this.signatureStatus 正在預(yù)覽歷史簽名筆跡已鎖定; this.redraw(); }表面上它只做了四次賦值實際上缺一項都會留下歧義。selectedHistoryId指定預(yù)覽對象viewMode preview讓visibleStrokes()改取歷史筆跡清空activeStroke避免上一次正在寫的筆畫繼續(xù)保留為活動狀態(tài)最后強制redraw()把舊畫面替換為所選記錄。僅改變列表高亮或標(biāo)題文字不足以完成“切換預(yù)覽”。真正的保護并不在按鈕樣式而在寫入路徑的第一行。觸摸、撤銷、清空和確認(rèn)都先判斷viewModeif (this.viewMode preview) { this.signatureStatus 歷史簽名只讀請先退出預(yù)覽后新建簽名; return; }這段判斷能夠證明當(dāng)前頁面不會在預(yù)覽模式繼續(xù)修改strokes或新增本地歷史記錄。它不能證明用戶在其他頁面、其他進程或真實工單系統(tǒng)中也沒有修改歷史數(shù)據(jù)這個組件沒有跨頁面鎖定和服務(wù)端權(quán)限校驗的證據(jù)。把邊界寫清楚比把“筆跡鎖定”夸大成全面的業(yè)務(wù)鎖定更可靠。退出預(yù)覽和重新開始的語義也不相同。exitPreview()只清除選中歷史項、回到新建模式讓用戶繼續(xù)處理已有的strokesstartNewSignature()在此基礎(chǔ)上還清空strokes創(chuàng)建一張新的本地簽名畫布。兩者都要重繪否則狀態(tài)文案雖然已變Canvas 仍可能保留歷史筆跡形成“可寫模式卻看著像歷史記錄”的誤導(dǎo)。撤銷與清空先改變來源數(shù)據(jù)再讓畫布跟隨維修簽名常見的兩個操作是撤銷最后一筆和清空整張簽名板。它們不是對 Canvas 像素做局部覆蓋而是先更新strokes再調(diào)用redraw()private undoStroke(): void { if (this.strokes.length 0) { this.signatureStatus 沒有可撤銷的筆畫; return; } this.strokes this.strokes.slice(0, this.strokes.length - 1); this.activeStroke undefined; this.signatureStatus this.strokes.length 0 ? 已撤銷全部筆畫 : 已撤銷最后一筆; this.redraw(); } private clearSignature(): void { this.strokes []; this.activeStroke undefined; this.signatureStatus 簽名畫布已清空; this.redraw(); }這條順序有明確的因果關(guān)系。slice()返回去掉最后一項后的新數(shù)組下一次重繪就不會再把最后一筆畫出來清空數(shù)組后重繪仍會保留背景和基線但不會有任何drawStrokes()的筆跡輸入。若反過來先擦畫布、后更新數(shù)組下一次觸摸、尺寸變化或抗鋸齒切換觸發(fā)重繪時被“擦掉”的舊筆跡還會從數(shù)組中重新出現(xiàn)。同樣需要避免把狀態(tài)文案當(dāng)結(jié)果證據(jù)?！耙殉蜂N最后一筆”只能說明當(dāng)前組件完成了本地數(shù)組更新“簽名畫布已清空”不等于本地歷史記錄被刪除更不等于真實工單中的任何簽名被撤回。頁面沒有實現(xiàn)遠(yuǎn)程刪除或歷史項刪除邏輯所以正文不能把這兩個按鈕說成工單操作。有筆跡不一定能確認(rèn)頁面如何識別過短輸入僅憑strokes.length 0判定簽名完成會把一次誤觸也計為簽字。當(dāng)前頁面用isValidStroke()過濾過短筆畫少于三個點直接無效滿足點數(shù)后再累加相鄰點之間的二維距離只有總長度不少于 12 才算有效。private isValidStroke(stroke: Stroke): boolean { if (stroke.points.length 3) { return false; } let length 0; for (let index 1; index stroke.points.length; index 1) { const horizontal stroke.points[index].x - stroke.points[index - 1].x; const vertical stroke.points[index].y - stroke.points[index - 1].y; length Math.sqrt(horizontal * horizontal vertical * vertical); } return length 12; }這段實現(xiàn)能確認(rèn)的是一個很具體的頁面準(zhǔn)入條件當(dāng)前坐標(biāo)樣本至少包含三個點且累計軌跡長度達到 12。它不能驗證簽字人的身份、簽名字形是否符合公司制度、筆跡是否可作為法律憑據(jù)也沒有給出任何防偽、時間戳簽名或服務(wù)端驗簽邏輯。它的作用是讓“請先完成有效簽字”不只是空提示而是有一個能從當(dāng)前源代碼核對的本地閾值。對讀者而言最值得復(fù)核的是操作路徑而不是猜一個簽名看起來是否像真的先只短按或短劃一次確認(rèn)狀態(tài)仍提示“筆跡過短”再完成一條多點且足夠長的筆畫確認(rèn)狀態(tài)變?yōu)椤肮P跡已采集可確認(rèn)本地歸檔”。這能驗證當(dāng)前頁面的本地閾值分支沒有業(yè)務(wù)系統(tǒng)回執(zhí)時不能把它稱為驗收通過或工單完結(jié)。點擊確認(rèn)后為什么我仍只寫“本地確認(rèn)”confirmSignature()先禁止預(yù)覽態(tài)確認(rèn)再檢查有效筆畫數(shù)。滿足條件時它將當(dāng)前筆跡坐標(biāo)歸一化然后追加一條歷史記錄private confirmSignature(): void { if (this.viewMode preview) { this.signatureStatus 歷史簽名只讀請先退出預(yù)覽后新建簽名; return; } const count this.validStrokeCount(); if (count 0) { this.signatureStatus 請先完成有效簽字; return; } const record: SignatureHistoryRecord { id: local-${this.signatureHistory.length 1}, action: 完工確認(rèn), signer: 維修人員, signedAt: 剛剛, strokes: this.normalizedStrokes() }; this.signatureHistory [record, ...this.signatureHistory]; this.signatureStatus 本地確認(rèn)已記錄共 ${count} 筆有效筆畫未回寫真實工單; this.redraw(); }關(guān)鍵事實就在狀態(tài)文案最后七個字未回寫真實工單。這里的確認(rèn)結(jié)果是頁面內(nèi)存中的signatureHistory新增一項方便在左側(cè)歷史列表中預(yù)覽源代碼沒有網(wǎng)絡(luò)請求、數(shù)據(jù)庫寫入、工單接口回執(zhí)或失敗重試邏輯。因此無論按鈕寫著“確認(rèn)并歸檔”還是歷史列表數(shù)量增加都只能描述為本地演示記錄。normalizedStrokes()的存在也有實際原因。新建簽名使用當(dāng)前 Canvas 的像素坐標(biāo)存入歷史項前頁面按當(dāng)前寬高換算為 240×130 基準(zhǔn)坐標(biāo)。后續(xù)歷史預(yù)覽再按照當(dāng)前畫布尺寸放大能夠減少“在一個尺寸寫入、換一個尺寸預(yù)覽時位置完全失真”的問題。它能證明頁面進行了本地坐標(biāo)歸一化不能證明記錄離開當(dāng)前頁面后仍然完整可用因為沒有持久化和跨設(shè)備同步的實現(xiàn)。場景解說此圖應(yīng)顯示有效筆跡后的確認(rèn)操作、歷史列表新增記錄和“未回寫真實工單”提示只能證明本地歷史狀態(tài)變化不能代替外部工單系統(tǒng)的回執(zhí)證據(jù)?？逛忼X是重繪條件不是另一篇文章的主線簽名頁提供antialiasEnabled和toggleAntialias()但這里它服務(wù)于手寫筆跡的顯示狀態(tài)而不是把整篇寫成文字邊緣對比。切換時先嘗試寫入當(dāng)前繪制上下文再無論成功或回退都調(diào)用redraw()private toggleAntialias(): void { const previous this.antialiasEnabled; this.antialiasEnabled !previous; if (this.applyAntialias()) { this.antialiasStatus this.antialiasEnabled ? 抗鋸齒已開啟 : 抗鋸齒已關(guān)閉; } else { this.antialiasEnabled previous; this.applyAntialias(); } this.redraw(); }這條鏈路能確認(rèn)頁面將本地開關(guān)嘗試應(yīng)用到CanvasRenderingContext2D若當(dāng)前運行環(huán)境拋出異常就恢復(fù)之前的開關(guān)值隨后再重畫簽名板。它解決的是“按鈕文本變了但畫布仍保留舊像素”的一致性問題。我不會把它描述成“關(guān)閉后簽名一定更鋸齒”或“開啟后每臺設(shè)備都更平滑”。源碼只處理設(shè)置與重繪沒有提供真機截圖、像素測量或設(shè)備對照。正確的觀察順序是記錄切換前狀態(tài)點擊開關(guān)確認(rèn)狀態(tài)文案與按鈕一致再觀察簽名字跡是否隨完整重繪更新若需要評價視覺差異必須補充相同畫布尺寸、相同筆跡和目標(biāo)設(shè)備上的實際取證。我按這條操作鏈做人工復(fù)核為了把“頁面顯示了簽名”與“業(yè)務(wù)完成”分開我會按以下順序核對當(dāng)前工程頁面進入FullScreenSignaturePage確認(rèn)新建模式提示為“請在簽名板內(nèi)書寫”簽名板為空且?guī)в谢€。在簽名板內(nèi)完成一條連續(xù)筆跡觀察狀態(tài)從“正在采集現(xiàn)場簽名…”變?yōu)橛行ЧP跡提示短劃或短按時應(yīng)保留“筆跡過短”分支。點擊“撤銷”確認(rèn)最后一筆從 Canvas 消失點擊“清空畫布”確認(rèn)當(dāng)前新建筆跡清除但頁面基線仍保留。選中一條歷史記錄確認(rèn)頁面進入歷史預(yù)覽并拒絕繼續(xù)書寫、撤銷、清空和確認(rèn)退出預(yù)覽后確認(rèn)可重新進入新建簽名流程。寫入有效筆跡后點擊“確認(rèn)并歸檔”確認(rèn)本地歷史列表增加記錄并且狀態(tài)明確顯示“未回寫真實工單”。切換抗鋸齒確認(rèn)按鈕和狀態(tài)文案同步僅在補充同尺寸目標(biāo)設(shè)備取證后才對邊緣差異做視覺結(jié)論。這六步覆蓋當(dāng)前頁面可觀察的本地狀態(tài)變化。它們不包含賬號、服務(wù)端工單、數(shù)據(jù)庫或真實簽字人驗證因為工程文件里沒有對應(yīng)調(diào)用鏈。人工審核時若需要發(fā)布“工單已更新”“記錄已歸檔到后臺”之類的結(jié)論應(yīng)先補充外部系統(tǒng)回執(zhí)、接口路徑和失敗處理證據(jù)不能從這張 Canvas 的頁面狀態(tài)推導(dǎo)。結(jié)論重繪負(fù)責(zé)對齊本地狀態(tài)不負(fù)責(zé)替業(yè)務(wù)背書維修簽名頁的難點不在于畫出一條線而在于讓每一次本地狀態(tài)變化都有唯一、可追溯的畫面結(jié)果。觸摸采集更新的是當(dāng)前筆畫預(yù)覽切換更換的是可見筆跡來源撤銷和清空先改變數(shù)組再重畫確認(rèn)新增的是本地歷史記錄抗鋸齒切換改變的是繪制配置。它們都需要通過redraw()回到同一條繪制路徑才能避免舊像素留在畫布上誤導(dǎo)操作人。與此同時重繪的責(zé)任到 Canvas 為止。它能讓讀者觀察到本地狀態(tài)與簽名板一致不能讓頁面憑空擁有真實工單回寫、服務(wù)端持久化、身份認(rèn)證或跨設(shè)備同步能力。把這一層邊界說清楚才是我在維修簽名頁中堅持每次狀態(tài)變化后重新繪制的原因。必要條件運行條件矩陣必要條件工程位置運行前動作未滿足時現(xiàn)象SDK/API與構(gòu)建工具build-profile.json5、Hvigor確認(rèn) compile/compatible/target 均為 API 24類型檢查或構(gòu)建失敗Kit引入當(dāng)前文章對應(yīng)頁面 import檢查 Kit 名稱和 API 是否與 API 24 匹配編譯期找不到類型或方法模塊與頁面配置module.json5、main_pages.json確認(rèn)頁面已注冊、模塊為 Stage頁面無法啟動或路由失敗設(shè)備權(quán)限與動態(tài)授權(quán)requestPermissions、abilityAccessCtrl先查詢并申請權(quán)限能力初始化被拒絕或跳過系統(tǒng)能力與硬件設(shè)備能力、Camera、MapKit、VisionKit等在目標(biāo)設(shè)備檢查能力進入不支持、等待或人工降級狀態(tài)矩陣中的 SDK/API 行核對完成后插入構(gòu)建證據(jù)需同時看到 API 24 和構(gòu)建工具信息設(shè)備權(quán)限行核對完成后插入授權(quán)證據(jù)系統(tǒng)能力與硬件行核對完成后插入版本/能力證據(jù)MapKit文章在系統(tǒng)能力行后增加AppGallery Connect 項目已創(chuàng)建或選定應(yīng)用包名和簽名證書與工程一致MapKit 服務(wù)已開通并按控制臺要求完成應(yīng)用服務(wù)憑據(jù)/授權(quán)配置。截圖不得帶出密鑰或證書私鑰。