做到第71個(gè)練手項(xiàng)目我特別想聊這個(gè)四則運(yùn)算演示器。HarmonyOS的應(yīng)用實(shí)例不難搜很多都套路化但這個(gè)題目的價(jià)值在于它并不只是寫一個(gè)計(jì)算器而是把小學(xué)數(shù)學(xué)里最容易搞混的“先乘除后加減有括號(hào)先算括號(hào)”規(guī)則在ArkTS里做成了可視化逐步演示。它解決了一個(gè)實(shí)際痛點(diǎn)光告訴結(jié)果還不夠必須把每一步運(yùn)算順序、每一步優(yōu)先級(jí)怎么變化都展示出來。如果你已經(jīng)會(huì)寫基礎(chǔ)ArkUI頁面想找一個(gè)既有界面又有算法邏輯的HarmonyOS項(xiàng)目來練手這個(gè)題目很對(duì)口味。1. 項(xiàng)目定位它和普通計(jì)算器到底有什么不一樣1.1 從“計(jì)算器”到“運(yùn)算順序演示器”的思維轉(zhuǎn)變?nèi)绻皇亲鲆粋€(gè)能算四則運(yùn)算的應(yīng)用HarmonyOS里有現(xiàn)成的組件和邏輯可以直接套輸入表達(dá)式、點(diǎn)擊、出結(jié)果三分鐘就搞定了。但“運(yùn)算順序演示器”這個(gè)定位不一樣它要求的不只是結(jié)果而是要把中間過程完整呈現(xiàn)出來。舉個(gè)例子表達(dá)式2 3 × 4 - 8 ÷ 2普通計(jì)算器直接給出10就完事了但演示器需要說明第一步先算3 × 4得到12第二步再算8 ÷ 2得到4第三步計(jì)算2 12第四步計(jì)算14 - 4最終結(jié)果是10這個(gè)差異決定了整個(gè)項(xiàng)目的設(shè)計(jì)核心計(jì)算引擎必須能夠把一次完整運(yùn)算拆解成多步并且每一步都要記錄“我算的是哪個(gè)子表達(dá)式”、“結(jié)果是什么”、“當(dāng)前整個(gè)表達(dá)式長(zhǎng)什么樣”。這是一個(gè)典型的“過程展示型”應(yīng)用計(jì)算能力反而是次要的重要的是順序邏輯。1.2 適合什么人、練什么能力這個(gè)實(shí)例適合兩類人剛學(xué)完HarmonyOS基礎(chǔ)組件、想深入理解狀態(tài)管理細(xì)節(jié)的開發(fā)者。項(xiàng)目里會(huì)頻繁用到State、Prop、ForEach以及數(shù)組替換不刷新視圖這類經(jīng)典坑。想給孩子做數(shù)學(xué)輔助工具、順帶練練手感的家長(zhǎng)開發(fā)者。把運(yùn)算規(guī)則做成演示器比單純刷題直觀得多孩子可以看到每一步高亮、每一步結(jié)果。從技術(shù)覆蓋面上看這個(gè)項(xiàng)目幾乎不依賴第三方庫核心代碼就是“表達(dá)式解析 步驟生成 UI綁定”。難點(diǎn)在于把解析算法講清楚然后配合ArkTS的響應(yīng)式狀態(tài)讓步驟逐條刷新出來。這比做幾十個(gè)靜態(tài)列表頁面要扎實(shí)得多。1.3 功能拆解我在開發(fā)前把功能拆成了四塊表達(dá)式輸入?yún)^(qū)支持?jǐn)?shù)字、加減乘除、括號(hào)輸入允許修改和清空。校驗(yàn)與容錯(cuò)表達(dá)式不完整、括號(hào)不配對(duì)、連續(xù)運(yùn)算符要能給出友好提示。逐步運(yùn)算引擎把表達(dá)式轉(zhuǎn)換成一系列帶步驟說明的計(jì)算過程。步驟展示區(qū)用列表展示每一步同時(shí)高亮正在計(jì)算的局部表達(dá)式。這四塊聽起來簡(jiǎn)單但每一步都有隱藏問題。比如“高亮當(dāng)前計(jì)算片段”就涉及原始表達(dá)式字符串和當(dāng)前步驟之間的位置映射處理不好就高亮錯(cuò)地方。2. 運(yùn)算順序規(guī)則與技術(shù)選型思路2.1 優(yōu)先級(jí)、結(jié)合性和括號(hào)的完整處理做這個(gè)項(xiàng)目之前必須先明確四則運(yùn)算的完整規(guī)則不是只記一句話就夠的括號(hào)優(yōu)先從最內(nèi)層括號(hào)開始計(jì)算乘號(hào)和除號(hào)優(yōu)先級(jí)相同同級(jí)從左到右依次計(jì)算加號(hào)和減號(hào)優(yōu)先級(jí)相同同級(jí)從左到右依次計(jì)算減號(hào)可以當(dāng)成負(fù)號(hào)處理但這個(gè)項(xiàng)目我先不做負(fù)號(hào)避免解析復(fù)雜化這里最容易出問題的就是“同級(jí)從左到右”。很多人實(shí)現(xiàn)計(jì)算器時(shí)只處理了優(yōu)先級(jí)沒有處理結(jié)合性結(jié)果8 ÷ 4 ÷ 2會(huì)算出錯(cuò)誤答案。正確結(jié)果是1因?yàn)橐劝? ÷ 4算成2再用2 ÷ 2得到1如果從右往左算就會(huì)得到4。我在設(shè)計(jì)引擎時(shí)把運(yùn)算符定義為一個(gè)枚舉每個(gè)運(yùn)算符帶兩個(gè)屬性優(yōu)先級(jí)和方向。優(yōu)先級(jí)用數(shù)字表示數(shù)字越大越先算方向表示同級(jí)時(shí)從左還是從右處理。加減乘除都是左結(jié)合不需要特殊處理。2.2 為什么選用“中綴轉(zhuǎn)后綴”而不是遞歸解析表達(dá)式3 4 × 2這種寫法叫中綴表達(dá)式人類看著舒服但程序處理順序很麻煩。常見方案有兩種遞歸下降解析直接處理中綴表達(dá)式通過遞歸函數(shù)識(shí)別優(yōu)先級(jí)代碼直觀但分支多。調(diào)度場(chǎng)算法先把中綴表達(dá)式轉(zhuǎn)換成后綴表達(dá)式后綴表達(dá)式也叫逆波蘭式然后依次壓棧計(jì)算順序天然和運(yùn)算法則一致。我最終選擇了調(diào)度場(chǎng)算法原因很實(shí)際它完美契合“逐步演示”的需求。調(diào)度場(chǎng)算法的輸出序列本身就體現(xiàn)了運(yùn)算順序比如3 4 × 2轉(zhuǎn)成后綴是3 4 2 × 一眼就能看出要先乘法后加法。后續(xù)步驟展示就是把后綴表達(dá)式的求值過程翻譯成文字。有人可能會(huì)問遞歸解析是不是更簡(jiǎn)單對(duì)于嵌套括號(hào)很深的表達(dá)式遞歸代碼確實(shí)不難寫但它不好記錄“每一步發(fā)生了什么”。而調(diào)度場(chǎng)算法天然帶著棧操作過程每一步都有跡可循。要把運(yùn)算過程展示給用戶選這種結(jié)構(gòu)化算法更省勁。2.3 步驟數(shù)據(jù)模型設(shè)計(jì)要讓步驟展示有條理數(shù)據(jù)模型必須先定清楚。我在項(xiàng)目里定義了一個(gè)StepRecord類class StepRecord { // 當(dāng)前步驟的說明文字 description: string; // 參與這一步運(yùn)算的兩個(gè)操作數(shù)的值 leftValue: number; rightValue: number; // 運(yùn)算符 op: string; // 這一步的結(jié)果 result: number; // 在當(dāng)前表達(dá)式文本中的起始位置 startIndex: number; // 在當(dāng)前表達(dá)式文本中的結(jié)束位置 endIndex: number; // 計(jì)算完這一步之后整個(gè)表達(dá)式的文本快照 snapshot: string; }這個(gè)模型里最關(guān)鍵的是startIndex和endIndex。它們用于在原始表達(dá)式里高亮當(dāng)前正在計(jì)算的片段。比如原始表達(dá)式2 3 × 4在算3 × 4這一步時(shí)高亮范圍應(yīng)該從字符串第4位到第8位。沒有這兩個(gè)字段高亮功能就只能靠猜。snapshot字段則用于展示“當(dāng)前表達(dá)式變?yōu)槭裁礃恿恕?。每算完一步我都把新的表達(dá)式字符串存下來這樣步驟列表里可以直接顯示中間化簡(jiǎn)結(jié)果不需要用戶自己腦補(bǔ)。3. HarmonyOS界面拆解與交互布局3.1 頁面整體結(jié)構(gòu)設(shè)計(jì)在ArkUI里做這個(gè)頁面我用的是Column嵌套滾動(dòng)布局整體分三層頂部表達(dá)式展示區(qū)用大號(hào)字體顯示當(dāng)前輸入的表達(dá)式和一個(gè)“演示”按鈕。中部步驟結(jié)果區(qū)用List或Scroll組件展示計(jì)算步驟。底部數(shù)字和運(yùn)算符按鈕區(qū)。之所以把輸入?yún)^(qū)放在頂部、按鈕放在底部是為了符合手機(jī)單手握持習(xí)慣。孩子用的時(shí)候拇指最容易夠到的是底部按鍵展示區(qū)在整個(gè)頁面中段視線也更集中。我用滾動(dòng)列表Scroll而不是List來做步驟區(qū)因?yàn)椴襟E數(shù)量通常不超過幾十條滾動(dòng)需求簡(jiǎn)單Scroll加ForEach就夠用性能開銷也小。3.2 按鍵布局與輸入限制按鍵區(qū)我用了四行7 8 9 ÷ 4 5 6 × 1 2 3 - 0 . C 還有一個(gè)單獨(dú)的全寬按鈕放“括號(hào)”和“演示”。這里要注意÷和×在字符串里直接保留原符號(hào)但在解析時(shí)要做映射把÷映射成除法運(yùn)算符把×映射成乘法運(yùn)算符不要真的用文本里的unicode參與計(jì)算。我還加了一層輸入限制邏輯運(yùn)算符后面不能直接跟另一個(gè)運(yùn)算符除非是負(fù)號(hào)場(chǎng)景小數(shù)點(diǎn)不能重復(fù)輸入左括號(hào)必須和右括號(hào)配對(duì)。這些限制用onClick或onChange事件攔截都行我用的是在按鈕點(diǎn)擊處理函數(shù)里統(tǒng)一判斷這樣所有入口都走同一套規(guī)則。3.3 高亮和步驟聯(lián)動(dòng)的實(shí)現(xiàn)思路步驟高亮是這個(gè)演示器的靈魂。我的實(shí)現(xiàn)方式是解析步驟數(shù)據(jù)時(shí)記錄每個(gè)步驟在原始表達(dá)式中的位置區(qū)間[startIndex, endIndex]。在表達(dá)式文本顯示組件中把普通文本和需要高亮的文本拆成多個(gè)Span子組件。根據(jù)當(dāng)前選中的步驟索引動(dòng)態(tài)計(jì)算哪些Span需要用不同顏色顯示。在ArkTS里可以使用Text組件的Span子組件實(shí)現(xiàn)單段混排顏色例如Text() { ForEach(this.textSegments, (segment: TextSegment) { Span(segment.text) .fontSize(24) .fontColor(segment.isHighlighted ? Color.Red : Color.Black) .fontWeight(segment.isHighlighted ? FontWeight.Bold : FontWeight.Normal) }) }這里有個(gè)地方要特別注意原始表達(dá)式里每個(gè)字符都要放進(jìn)對(duì)應(yīng)的TextSegment數(shù)組里哪怕一個(gè)連續(xù)的數(shù)字串也要按“是否落入高亮區(qū)間”拆成多個(gè)片段不能直接按空格切分否則高亮位置會(huì)對(duì)不上。4. 核心代碼實(shí)現(xiàn)詳解4.1 表達(dá)式合法性校驗(yàn)計(jì)算前先校驗(yàn)這一步不能省。我寫的校驗(yàn)函數(shù)做了三件事括號(hào)配對(duì)遇到左括號(hào)入棧右括號(hào)出棧最后棧必須是空的。運(yùn)算符位置表達(dá)式開頭不能是運(yùn)算符負(fù)號(hào)場(chǎng)景先跳過結(jié)尾不能是運(yùn)算符。連續(xù)運(yùn)算符出現(xiàn)× 這類連續(xù)運(yùn)算符要報(bào)錯(cuò)。以括號(hào)校驗(yàn)為例思路很簡(jiǎn)單function checkBrackets(expr: string): boolean { let stack: string[] []; for (let ch of expr) { if (ch () { stack.push(ch); } else if (ch )) { if (stack.length 0) { return false; } stack.pop(); } } return stack.length 0; }這里我把“括號(hào)配對(duì)”和“表達(dá)式位置”分開寫因?yàn)殄e(cuò)誤提示需要區(qū)分是“括號(hào)不配對(duì)”還是“輸入不完整”合并寫雖然省代碼但用戶看到的提示會(huì)很不友好。4.2 表達(dá)式拆分?jǐn)?shù)字、運(yùn)算符、括號(hào)字符串表達(dá)式不能直接逐字符丟給后續(xù)算法得先拆成Token列表。常見的坑是數(shù)字有多位比如123必須被識(shí)別成整體小數(shù)點(diǎn)也要跟數(shù)字一起歸入同一個(gè)Token。下面這段是我項(xiàng)目里的拆分邏輯核心function tokenize(expr: string): Token[] { let tokens: Token[] []; let i 0; while (i expr.length) { let ch expr[i]; if (isDigit(ch) || ch .) { let start i; while (i expr.length (isDigit(expr[i]) || expr[i] .)) { i; } let numStr expr.substring(start, i); tokens.push({ type: TokenType.NUMBER, value: parseFloat(numStr), rawText: numStr, startIndex: start, endIndex: i - 1 }); continue; } if (ch ) { tokens.push({ type: TokenType.PLUS, value: 0, rawText: ch, startIndex: i, endIndex: i }); i; continue; } // 減號(hào)、乘號(hào)、除號(hào)、左括號(hào)、右括號(hào)同理 } return tokens; }這里每個(gè)Token都保存了startIndex和endIndex這部分?jǐn)?shù)據(jù)是后面高亮功能能精確工作的基礎(chǔ)。如果只在Token里存數(shù)字和運(yùn)算符類型后續(xù)就追查不到原始位置了。我就是因?yàn)榈谝话鏇]記錄位置后來不得不重寫了一次。4.3 調(diào)度場(chǎng)算法中綴轉(zhuǎn)后綴調(diào)度場(chǎng)算法的核心是維護(hù)一個(gè)運(yùn)算符棧。遍歷Token時(shí)數(shù)字直接進(jìn)入輸出隊(duì)列運(yùn)算符則要跟棧頂運(yùn)算符比較優(yōu)先級(jí)如果棧頂優(yōu)先級(jí)更高或相同就先彈出棧頂進(jìn)輸出隊(duì)列再把當(dāng)前運(yùn)算符壓棧遇到左括號(hào)直接壓棧遇到右括號(hào)則一直彈棧直到碰到左括號(hào)。用2 3 × 4舉例讀到2直接輸出讀到?？諌簵Ｗx到3直接輸出讀到×比較棧頂是×優(yōu)先級(jí)更高所以×壓棧讀到4直接輸出結(jié)束后彈出棧中所有運(yùn)算符這樣就得到后綴表達(dá)式2 3 4 × 。ArkTS代碼里我就是按這個(gè)邏輯寫的注意數(shù)組的pop()和push()方法可以直接復(fù)現(xiàn)棧操作。不需要自己實(shí)現(xiàn)棧類直接用Arraystring就行。4.4 后綴表達(dá)式求值并生成演示步驟得到后綴表達(dá)式之后求值階段就是專門為“演示”服務(wù)的。每次從后綴表達(dá)式里取出一個(gè)數(shù)字時(shí)壓入數(shù)字棧取出運(yùn)算符時(shí)從數(shù)字棧彈出兩個(gè)數(shù)字按順序計(jì)算然后生成一條StepRecord。這里要處理一個(gè)最關(guān)鍵的細(xì)節(jié)表達(dá)式的原始展示文本和計(jì)算順序之間的對(duì)應(yīng)關(guān)系。后綴表達(dá)式里數(shù)字和運(yùn)算符都已經(jīng)丟失了原始順序所以我需要額外維護(hù)一個(gè)映射關(guān)系在解析每種Token時(shí)就把它們指向的原始位置保存下來。我的處理方式很簡(jiǎn)單把每個(gè)Token都拷貝一份到“求值隊(duì)列”里這個(gè)隊(duì)列元素除了類型和數(shù)值還帶著它在原始表達(dá)式里的開始和結(jié)束位置。每次執(zhí)行一個(gè)運(yùn)算符時(shí)讀到的就是這個(gè)運(yùn)算符Token以及它關(guān)聯(lián)的操作數(shù)Token的位置信息這樣生成的步驟說明可以精確指向原始表達(dá)式中的某一段。function evaluateToSteps(postfix: Token[]): StepRecord[] { let numStack: number[] []; let records: StepRecord[] []; for (let token of postfix) { if (token.type TokenType.NUMBER) { numStack.push(token.value); } else { let right numStack.pop()!; let left numStack.pop()!; let result applyOp(left, right, token.type); // 記錄這一步對(duì)應(yīng)的原始位置 records.push(buildStepRecord(left, right, token, result)); numStack.push(result); } } return records; }注意applyOp里除法要判斷除數(shù)為零的情況我在項(xiàng)目里專門彈了個(gè)提示“除數(shù)不能為0”。雖然在教育場(chǎng)景里這是個(gè)好教學(xué)點(diǎn)但應(yīng)用不能崩潰。4.5 演示過程的節(jié)奏控制步驟列表一次性生成之后怎么播放也有講究。我提供了兩種模式“一鍵出步驟”所有步驟同時(shí)生成點(diǎn)擊“演示”后全部顯示?！爸鸩讲シ拧卑磿r(shí)間間隔逐條顯示模擬老師在黑板上一步步寫。逐步播放我在實(shí)現(xiàn)時(shí)用了setInterval每500毫秒往步驟數(shù)組里追加一條記錄。但這里有個(gè)ArkTS狀態(tài)管理的大坑數(shù)組元素的添加不一定觸發(fā)視圖刷新。我踩了好幾次后面專門用了一個(gè)State currentStepCount: number來驅(qū)動(dòng)顯示State displayedStepCount: number 0; startPlay() { let timer setInterval(() { if (this.displayedStepCount this.steps.length) { clearInterval(timer); return; } this.displayedStepCount; }, 500); }UI里渲染步驟時(shí)只取前displayedStepCount條這樣狀態(tài)改變一定會(huì)觸發(fā)重新渲染方式笨但絕對(duì)穩(wěn)。如果你只把this.steps.push(record)寫在定時(shí)器里而不改變?nèi)魏纹渌鸖tate變量界面很可能一動(dòng)不動(dòng)。5. 實(shí)操踩坑記錄狀態(tài)、動(dòng)畫與輸入法的那些事5.1 ArkTS數(shù)組更新不刷新視圖這個(gè)問題可以說是HarmonyOS應(yīng)用開發(fā)里最高頻的坑之一。很多人寫了this.dataSource.push(item)之后發(fā)現(xiàn)列表不更新原因是State監(jiān)聽的是引用變化而不是原地修改。雖然某些場(chǎng)景下框架會(huì)深度觀察但依賴這種邊緣行為太危險(xiǎn)了。我的解決方案很簡(jiǎn)單每次修改數(shù)組后重新賦值一個(gè)新數(shù)組引用。例如let newList: StepRecord[] this.steps.slice(); newList.push(record); this.steps newList;這樣視圖刷新響應(yīng)非常穩(wěn)定。如果你用裝飾器Observed和ObjectLink去跟蹤復(fù)雜的類對(duì)象也能解決但對(duì)這種簡(jiǎn)單數(shù)據(jù)我更推薦直接替換整個(gè)數(shù)組代碼更直觀行為也更好預(yù)測(cè)。5.2 高亮位置偏移與文本拆分這個(gè)坑非常隱蔽。原始表達(dá)式經(jīng)過Token拆分后我記錄了每個(gè)Token的起止位置但用戶輸入的表達(dá)式里可能摻雜了空格。我在輸入層限制了用戶不能輸入空格不過從別處復(fù)制粘貼就可能帶進(jìn)來?？崭駮?huì)導(dǎo)致字符位置和下標(biāo)的計(jì)算差一位到兩位高亮就會(huì)偏。處理辦法是入庫前先做一次“凈化”把所有空格、不可見字符統(tǒng)一剔除expression expression.replace(/\s/g, );如果你不想剔除空格就要在計(jì)算高亮區(qū)間時(shí)做偏移映射。我權(quán)衡之后選擇了剔除因?yàn)樽鳛榻虒W(xué)演示器空格本來也不影響語義。5.3 軟鍵盤彈出遮擋按鍵區(qū)頁面底部是按鈕區(qū)在真機(jī)上點(diǎn)擊輸入框編輯表達(dá)式時(shí)軟鍵盤彈出會(huì)遮擋底座。原因很簡(jiǎn)單頁面高度沒有隨著鍵盤調(diào)整。HarmonyOS里比較直接的處理是用expandSafeArea或者設(shè)置頁面的鍵盤避讓模式。我在項(xiàng)目里用了window.setWindowInputMode調(diào)整默認(rèn)輸入模式設(shè)置為adjustResize讓頁面能自動(dòng)收縮高度按鍵區(qū)就能跟著上移。不過還要注意不要給底部按鈕列設(shè)置固定高度height盡量用layoutWeight或安全區(qū)適配否則鍵盤彈出來時(shí)按鈕區(qū)會(huì)和鍵盤疊在一起。5.4 逐步播放時(shí)高亮閃爍逐步播放時(shí)每一條新步驟出現(xiàn)用戶希望當(dāng)前步驟的表達(dá)式高亮能跟著變化。我的實(shí)現(xiàn)是在步驟列表當(dāng)前展示的索引變化時(shí)重新計(jì)算textSegments并把新數(shù)組狀態(tài)賦值回去。高亮閃爍的bug出在我沒設(shè)置過渡動(dòng)畫導(dǎo)致每次重新生成文本段數(shù)組時(shí)整個(gè)表達(dá)式都被強(qiáng)制刷新一次看起來就像閃了一下。解決方式很直接要么不加動(dòng)畫要么用animateTo做顏色變化的平滑過渡。我最終選擇不加動(dòng)畫只改變字體顏色和粗細(xì)這樣在教育場(chǎng)景里更利索不會(huì)因?yàn)閯?dòng)畫干擾視線。另外如果用戶點(diǎn)擊任意一條歷史步驟我希望高亮能跳轉(zhuǎn)到對(duì)應(yīng)位置。這個(gè)我用了一個(gè)State只存當(dāng)前選中步驟的索引點(diǎn)擊列表項(xiàng)時(shí)動(dòng)態(tài)更新因?yàn)樗旧砭万?qū)動(dòng)了文本段數(shù)組重建所以聯(lián)動(dòng)是自動(dòng)化完成的不需要額外刷一次UI。6. 表達(dá)式校驗(yàn)的幾個(gè)邊界情況6.1 括號(hào)嵌套與非法輸入我實(shí)際測(cè)試時(shí)發(fā)現(xiàn)用戶最容易輸入的非法表達(dá)式其實(shí)是())重復(fù)括號(hào)和2 (3 × 4這種漏右括號(hào)的情況。前者我在括號(hào)配對(duì)檢查里直接攔截后者在表達(dá)式結(jié)尾也會(huì)被判為非法。但有個(gè)邊界容易被漏掉2 (3 × 4))這種表達(dá)式括號(hào)總數(shù)是配對(duì)的但右括號(hào)數(shù)量在中間某個(gè)位置超過了左括號(hào)的累計(jì)數(shù)量。如果只是簡(jiǎn)單數(shù)左右括號(hào)數(shù)量會(huì)被當(dāng)成合法。所以括號(hào)校驗(yàn)必須用“遇到左括號(hào)計(jì)數(shù)加一遇到右括號(hào)計(jì)數(shù)減一中途出現(xiàn)負(fù)數(shù)就非法”的方式不能只看最終計(jì)數(shù)。6.2 除數(shù)為零和重復(fù)小數(shù)點(diǎn)除數(shù)為零在演示步驟里如何表現(xiàn)我做了個(gè)特殊設(shè)計(jì)不直接報(bào)錯(cuò)而是在步驟里用文字展示“這里不能除以0所以這個(gè)表達(dá)式不成立”并且終止后續(xù)計(jì)算。這個(gè)處理的邏輯是教育應(yīng)用應(yīng)該解釋為什么非法而不是只給一個(gè)NaN結(jié)果。重復(fù)小數(shù)點(diǎn)1.2.3在Token解析階段就會(huì)出問題我會(huì)在解析時(shí)判斷一個(gè)數(shù)字字符串內(nèi)的小數(shù)點(diǎn)數(shù)量是否大于1如果大于1就返回一個(gè)錯(cuò)誤碼提示用戶格式不正確。6.3 形如2 × ÷ 3的連續(xù)運(yùn)算符連續(xù)運(yùn)算符會(huì)在解析過程中被識(shí)別。我在輸入限制之外還給解析器加了一層容錯(cuò)如果剛解析了一個(gè)運(yùn)算符緊接著又出現(xiàn)另一個(gè)運(yùn)算符且中間沒有數(shù)字就判斷當(dāng)前Token類型不合法。這樣即使在極少數(shù)繞過輸入限制的情況下引擎也不會(huì)崩潰而是輸出友好的錯(cuò)誤提示。這個(gè)雙保險(xiǎn)很重要。輸入限制是針對(duì)人手點(diǎn)擊按鈕設(shè)計(jì)的如果用戶用輸入法從剪貼板粘貼表達(dá)式就能繞過按鈕點(diǎn)擊邏輯所以解析器本身必須可靠。7. 后續(xù)擴(kuò)展方向與個(gè)人經(jīng)驗(yàn)7.1 可以擴(kuò)展成“分步講解器”做完這個(gè)演示器之后我其實(shí)產(chǎn)生了更多想法。最直接的一個(gè)是把它擴(kuò)展成“步驟詳解器”不僅僅是演示運(yùn)算順序還可以在每一步下面追加講解文字比如“為什么這里要先算乘法因?yàn)槌朔▋?yōu)先級(jí)比加法高括號(hào)以外的乘除要先于加減計(jì)算”。這個(gè)擴(kuò)展需要增加一個(gè)“講解詞生成器”在生成步驟時(shí)根據(jù)運(yùn)算符類型附上對(duì)應(yīng)的規(guī)則說明。代碼層面改動(dòng)不大只是數(shù)據(jù)模型里加一個(gè)explanation字段。如果你想讓這個(gè)應(yīng)用更適合兒童教育我建議把顏色做得更大膽一些比如用高亮色塊圈住正在計(jì)算的部分點(diǎn)擊步驟條可以高亮到具體數(shù)字。孩子看到“原來先算的是這一段”比大人看到結(jié)果更有意義。7.2 從項(xiàng)目里得到的實(shí)際體會(huì)開發(fā)這個(gè)應(yīng)用時(shí)最大的收獲不是掌握了調(diào)度場(chǎng)算法而是理解了“狀態(tài)管理 計(jì)算過程”之間如何配合。一個(gè)計(jì)算器的功能可以靠一次性計(jì)算解決但一旦涉及過程展示就必須把日志記錄、變量狀態(tài)、UI刷新全部編排好。如果你準(zhǔn)備動(dòng)手復(fù)刻這個(gè)實(shí)例我建議從“不帶動(dòng)畫的單機(jī)版本”開始先把計(jì)算引擎和步驟生成跑通再美化界面。直接一開始就追求動(dòng)畫和視覺效果卡殼之后很難定位是解析問題還是渲染問題。還有一點(diǎn)經(jīng)驗(yàn)可以分享程序里的步驟記錄不要只為了人看而寫要給每一個(gè)步驟配上“機(jī)器可讀”的字段比如原始位置區(qū)間、參與運(yùn)算的左右值后續(xù)做高亮、做撤銷、做跳轉(zhuǎn)都有用。只輸出一句人話后面想重新計(jì)算就抓瞎了。這個(gè)項(xiàng)目現(xiàn)在還在我的練習(xí)列表里下一步我準(zhǔn)備把它移植成一個(gè)HarmonyOS的卡片服務(wù)讓用戶不用打開應(yīng)用就能看到上一條表達(dá)式運(yùn)算過程。做卡片時(shí)數(shù)據(jù)綁定又會(huì)有新的坑到時(shí)候再跟你們聊聊。