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