據(jù)庫(kù)調(diào)試三板斧：拉庫(kù)、Debug面板與dataChange訂閱)
說(shuō)個(gè)真實(shí)場(chǎng)景你在鴻蒙NEXT應(yīng)用里寫(xiě)了一個(gè)關(guān)系型數(shù)據(jù)庫(kù)模塊增刪改查全通了代碼也不報(bào)錯(cuò)但就是想確認(rèn)表里到底存了什么數(shù)據(jù)。最笨的辦法是翻日志一行一行打印字段數(shù)據(jù)量一多直接崩潰于是絕大多數(shù)開(kāi)發(fā)者都會(huì)想到同一件事——把數(shù)據(jù)庫(kù)文件拖出來(lái)看一眼。這個(gè)方法本身沒(méi)毛病但鴻蒙的沙箱機(jī)制和SQLite的WAL模式會(huì)讓這條老路踩不少暗坑。這篇文章就圍繞“如何實(shí)時(shí)查看數(shù)據(jù)庫(kù)”這件事把設(shè)備側(cè)拉庫(kù)、應(yīng)用內(nèi)Debug面板、dataChange自動(dòng)刷新三條路全部捋一遍給出可以直接抄的命令和代碼并且把每種方案的適用邊界說(shuō)清楚。適合正在做鴻蒙NEXT應(yīng)用、被本地?cái)?shù)據(jù)調(diào)試折磨的開(kāi)發(fā)者參考。1. 先分清“實(shí)時(shí)查看”的兩種場(chǎng)景別做重復(fù)功很多人一提“實(shí)時(shí)查看數(shù)據(jù)庫(kù)”開(kāi)口就問(wèn)“有沒(méi)有現(xiàn)成工具”。其實(shí)這個(gè)問(wèn)題拆開(kāi)看大多數(shù)時(shí)候包含兩種完全不同的訴求混在一起找方案容易兩頭不討好。1.1 調(diào)試期的“看一眼”與運(yùn)行期的“盯著看”場(chǎng)景A是開(kāi)發(fā)調(diào)試期的靜態(tài)快照式查看。應(yīng)用跑完某個(gè)功能后你想知道剛才那條記錄到底有沒(méi)有寫(xiě)進(jìn)去字段值是否符合預(yù)期。這個(gè)場(chǎng)景的核心訴求是“數(shù)據(jù)可見(jiàn)、字段可查”操作對(duì)象通常是已經(jīng)落盤(pán)的數(shù)據(jù)庫(kù)文件不需要應(yīng)用代碼參與把文件拉到電腦上用SQLite工具打開(kāi)就行。場(chǎng)景B是運(yùn)行過(guò)程中的動(dòng)態(tài)觀察式查看。應(yīng)用不停止數(shù)據(jù)持續(xù)寫(xiě)入你希望界面上的數(shù)據(jù)列表能跟著數(shù)據(jù)庫(kù)變化自動(dòng)刷新用于自測(cè)、聯(lián)調(diào)或者向測(cè)試同學(xué)演示某功能的前后數(shù)據(jù)差異。這個(gè)場(chǎng)景的核心訴求是“變化即所見(jiàn)”單純拉文件解決不了必須借助鴻蒙RDB的變更訂閱能力。這兩個(gè)場(chǎng)景的難度和實(shí)現(xiàn)路徑差異很大。場(chǎng)景A適合“快速驗(yàn)證一下”場(chǎng)景B適合“長(zhǎng)時(shí)間觀察狀態(tài)”。如果一開(kāi)始就把目標(biāo)定成“做一套自動(dòng)刷新面板”可能花了半天時(shí)間卻發(fā)現(xiàn)最初只是想看一眼字段名反過(guò)來(lái)如果只想“拉庫(kù)看一眼”又不滿足聯(lián)調(diào)時(shí)持續(xù)觀察的需求。1.2 兩種場(chǎng)景的選型判斷我做選型時(shí)習(xí)慣列一張表把使用階段、是否需要改應(yīng)用代碼、刷新方式、適合誰(shuí)來(lái)用幾個(gè)維度擺出來(lái)對(duì)比之后答案就很清楚。維度設(shè)備側(cè)拉庫(kù)查看應(yīng)用內(nèi)Debug面板dataChange自動(dòng)刷新使用階段開(kāi)發(fā)調(diào)試早期功能自測(cè)階段聯(lián)調(diào)、回歸階段是否改應(yīng)用代碼不需要純PC操作需要新增Debug頁(yè)面在Debug頁(yè)面基礎(chǔ)上加訂閱邏輯刷新方式手動(dòng)拉取離線打開(kāi)手動(dòng)點(diǎn)擊刷新數(shù)據(jù)庫(kù)變更后自動(dòng)刷新數(shù)據(jù)完整性依賴WAL文件是否合入實(shí)時(shí)查詢始終最新實(shí)時(shí)查詢始終最新硬件依賴需要連接電腦真機(jī)或模擬器均可真機(jī)或模擬器均可上手成本低命令復(fù)制即用中需要寫(xiě)UI頁(yè)面中高需要理解訂閱機(jī)制對(duì)照這張表你會(huì)發(fā)現(xiàn)三者不是替代關(guān)系而是互補(bǔ)關(guān)系。我現(xiàn)在的習(xí)慣是早期用方案一快速確認(rèn)表結(jié)構(gòu)和字段名做功能自測(cè)時(shí)打開(kāi)方案二進(jìn)入聯(lián)調(diào)階段再開(kāi)啟方案三。下面逐個(gè)展開(kāi)。2. 設(shè)備側(cè)拉庫(kù)查看最快出結(jié)果但別踩沙箱權(quán)限的坑2.1 搞清楚RDB文件到底落在哪個(gè)目錄鴻蒙NEXT的關(guān)系型數(shù)據(jù)庫(kù)relationalStore底層是SQLite數(shù)據(jù)庫(kù)文件存放在應(yīng)用沙箱的database目錄下。以默認(rèn)配置為例如果創(chuàng)建數(shù)據(jù)庫(kù)時(shí)傳的name是demo.dbbundleName是com.example.demoapp那么文件路徑通常是/data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db但這里有個(gè)很容易踩的坑不同API版本、不同構(gòu)建方式下文件落盤(pán)位置有差異。有的版本會(huì)把db文件直接放在database目錄下不經(jīng)過(guò)entry/rdb這一層有的版本還可能出現(xiàn)以bundleName命名的子目錄。所以最穩(wěn)妥的做法是先用hdc探一下真實(shí)路徑不要憑經(jīng)驗(yàn)硬寫(xiě)。在你已經(jīng)連接設(shè)備并開(kāi)啟USB調(diào)試的前提下執(zhí)行hdc shell ls -l /data/app/el2/100/database/com.example.demoapp/entry/rdb/如果輸出里能看到demo.db、demo.db-wal、demo.db-shm三個(gè)文件那說(shuō)明路徑是對(duì)的如果報(bào)錯(cuò)或者目錄不存在就換不帶entry/rdb的路徑再試hdc shell ls -l /data/app/el2/100/database/com.example.demoapp/另外數(shù)據(jù)庫(kù)文件名不一定和代碼里config.name完全一致取決于你是否傳了擴(kuò)展名。建議直接ls看實(shí)際生成的文件名而不是想當(dāng)然。2.2 拉庫(kù)的完整命令與SQLite工具打開(kāi)確認(rèn)路徑后一條命令把數(shù)據(jù)庫(kù)拉到電腦本地hdc file recv /data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db ./demo.db如果你在同一個(gè)目錄下看到了-wal和-shm文件建議一起拉下來(lái)hdc file recv /data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db-wal ./demo.db-wal hdc file recv /data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db-shm ./demo.db-shm原因很簡(jiǎn)單SQLite默認(rèn)開(kāi)啟了WAL模式最新的寫(xiě)入可能還在demo.db-wal文件里單獨(dú)拿db文件離線打開(kāi)時(shí)數(shù)據(jù)是不完整的。把三個(gè)文件放在同一目錄再打開(kāi)才能看到完整的最新?tīng)顟B(tài)。拿到文件后PC端用通用SQLite工具打開(kāi)即可比如DB Browser for SQLite這類(lèi)免費(fèi)工具能看表結(jié)構(gòu)、執(zhí)行SQL、導(dǎo)出CSV已經(jīng)覆蓋絕大多數(shù)需求。打開(kāi)時(shí)注意確認(rèn)三個(gè)文件放在同一目錄工具會(huì)自動(dòng)合并WAL內(nèi)容。2.3 權(quán)限不足時(shí)的補(bǔ)救路線先從應(yīng)用內(nèi)把庫(kù)“搬”出來(lái)如果hdc直接訪問(wèn)沙箱目錄時(shí)收到Permission denied不要急著懷疑人生。這通常是因?yàn)楫?dāng)前設(shè)備的調(diào)試模式受限或者h(yuǎn)dc連接的權(quán)限等級(jí)不夠。我有一次換了臺(tái)測(cè)試機(jī)hdc版本沒(méi)同步更新拉庫(kù)時(shí)一直報(bào)權(quán)限問(wèn)題折騰半天發(fā)現(xiàn)是設(shè)備端和PC端的hdc版本不匹配導(dǎo)致連接狀態(tài)異常升級(jí)hdc后問(wèn)題直接消失。但更多時(shí)候權(quán)限限制是真實(shí)存在的。這時(shí)候最省事的補(bǔ)救方案是在應(yīng)用內(nèi)加一段“導(dǎo)出數(shù)據(jù)庫(kù)”的臨時(shí)代碼把database目錄下的db文件復(fù)制到應(yīng)用自身的files目錄下。應(yīng)用操作自己的沙箱文件不存在權(quán)限問(wèn)題而files目錄通常位于hdc可訪問(wèn)的base路徑下之后就能正常拉取了。import { fileIo } from kit.CoreFileKit; import { common } from kit.AbilityKit; function exportDbToFiles(context: common.UIAbilityContext, dbName: string): string { const srcPath ${context.databaseDir}/${dbName}; const destDir ${context.filesDir}/export_db; fileIo.mkdirSync(destDir); const destPath ${destDir}/${dbName}; fileIo.copyFileSync(srcPath, destPath); return destPath; }注意context.databaseDir返回的是當(dāng)前應(yīng)用數(shù)據(jù)庫(kù)沙箱目錄這段代碼在應(yīng)用自己進(jìn)程內(nèi)執(zhí)行是合法的?？截愅瓿珊笤偻ㄟ^(guò)hdc拉取files目錄下的文件即可hdc shell ls /data/app/el2/100/base/com.example.demoapp/files/export_db/ hdc file recv /data/app/el2/100/base/com.example.demoapp/files/export_db/demo.db ./demo.db真實(shí)文件路徑可能因設(shè)備版本略有差異以ls實(shí)際結(jié)果為準(zhǔn)。把這個(gè)導(dǎo)出函數(shù)放在一個(gè)Debug按鈕后面只在開(kāi)發(fā)期調(diào)用交付時(shí)移除。3. 應(yīng)用內(nèi)Debug面板在屏幕上直接看數(shù)據(jù)庫(kù)內(nèi)容3.1 為什么Debug面板比頻繁插線更值得投入拉庫(kù)這條路雖然直接但每次都要連電腦、敲命令、打開(kāi)PC工具做一次數(shù)據(jù)確認(rèn)至少一分鐘起步。如果你正在做列表頁(yè)聯(lián)調(diào)改一次數(shù)據(jù)就要確認(rèn)一次數(shù)據(jù)庫(kù)狀態(tài)來(lái)回插拔數(shù)據(jù)線能把人逼瘋。應(yīng)用內(nèi)Debug面板的思路就簡(jiǎn)單了在App里加一個(gè)隱藏頁(yè)面用RDB查詢能力讀取表結(jié)構(gòu)和數(shù)據(jù)在手機(jī)上直接展示。功能自測(cè)或者給同事演示時(shí)打開(kāi)面板就能看到數(shù)據(jù)不需要任何PC操作。更重要的是這個(gè)面板是所有后續(xù)自動(dòng)刷新功能的載體——不先把數(shù)據(jù)展示做好談?dòng)嗛喫⑿露际强照?。我做這個(gè)面板時(shí)目標(biāo)非?？酥颇芰谐鏊斜?、能看每張表的行數(shù)、能點(diǎn)進(jìn)表看數(shù)據(jù)明細(xì)、能手動(dòng)刷新。這四個(gè)能力已經(jīng)覆蓋90%的調(diào)試需求再多的功能都屬于錦上添花后面可以按需擴(kuò)展。3.2 讀取表結(jié)構(gòu)拿sqlite_master當(dāng)入口RDB提供了querySql接口可以直接執(zhí)行任意SQL。要拿到數(shù)據(jù)庫(kù)里的全部表名最直接的方式是查詢SQLite自帶的元數(shù)據(jù)表sqlite_masterimport { relationalStore } from kit.ArkData; async function queryAllTables(store: relationalStore.RdbStore): Promisestring[] { const resultSet await store.querySql(SELECT name FROM sqlite_master WHERE type table ORDER BY name); const tables: string[] []; while (resultSet.goToNextRow()) { tables.push(resultSet.getString(resultSet.getColumnIndex(name))); } resultSet.close(); return tables; }拿到表名列表后逐表查詢行數(shù)。行數(shù)查詢用RdbPredicates的count接口async function getTableCount(store: relationalStore.RdbStore, tableName: string): Promisenumber { const predicates new relationalStore.RdbPredicates(tableName); return await store.count(predicates); }面板首頁(yè)的核心邏輯就是這兩段。頁(yè)面用一個(gè)List組件把表名和行數(shù)渲染成列表項(xiàng)點(diǎn)擊某項(xiàng)跳轉(zhuǎn)到表數(shù)據(jù)詳情頁(yè)。這里有個(gè)小細(xì)節(jié)查詢sqlite_master時(shí)最好把以sqlite_開(kāi)頭的內(nèi)部表過(guò)濾掉否則面板上會(huì)混入一些你從來(lái)沒(méi)見(jiàn)過(guò)也無(wú)權(quán)操作的系統(tǒng)表看著礙眼。3.3 表數(shù)據(jù)頁(yè)的展示與翻頁(yè)實(shí)現(xiàn)點(diǎn)擊某張表進(jìn)入詳情頁(yè)后需要分頁(yè)讀取數(shù)據(jù)。鴻蒙RDB的RdbPredicates提供了limitAs方法可以指定偏移量和每頁(yè)大小async function queryPage( store: relationalStore.RdbStore, tableName: string, page: number, pageSize: number, ): Promise{ columns: string[]; rows: ArrayRecordstring, string | number | null } { const predicates new relationalStore.RdbPredicates(tableName); predicates.limitAs(page * pageSize, pageSize); const resultSet await store.query(predicates); const columns resultSet.columnNames; const rows: ArrayRecordstring, string | number | null []; while (resultSet.goToNextRow()) { const row: Recordstring, string | number | null {}; for (const col of columns) { const index resultSet.getColumnIndex(col); const value resultSet.getValue(index); row[col] value; } rows.push(row); } resultSet.close(); return { columns, rows }; }這段代碼把ResultSet里的數(shù)據(jù)一次性轉(zhuǎn)成了普通對(duì)象數(shù)組方便交給UI層渲染。這里必須強(qiáng)調(diào)的是不要在UI線程里直接遍歷ResultSet——如果表數(shù)據(jù)量大一次goToNextRow循環(huán)會(huì)卡住頁(yè)面。先轉(zhuǎn)成數(shù)組再setState是一個(gè)基本但重要的習(xí)慣。UI層用List組件配合ForEach即可。每一行數(shù)據(jù)按“字段名: 值”的形式橫向排布字段太多時(shí)允許橫向滾動(dòng)。頁(yè)面底部放兩個(gè)按鈕上一頁(yè)、下一頁(yè)分別修改當(dāng)前頁(yè)碼后重新查詢。頁(yè)大小建議固定20行避免一次查詢過(guò)大導(dǎo)致渲染卡頓。3.4 給面板加一個(gè)“僅Debug環(huán)境可見(jiàn)”的入口Debug面板做得再好也不能讓它出現(xiàn)在正式包里。鴻蒙工程里常見(jiàn)做法是讀取構(gòu)建標(biāo)記只有DEBUG為true時(shí)才顯示入口。以Stage模型為例在首頁(yè)的aboutToAppear里判斷import { BuildProfile } from ohos.buildProfile; const isDebug BuildProfile.DEBUG true;在首頁(yè)某個(gè)不太顯眼的位置比如設(shè)置項(xiàng)里連點(diǎn)版本號(hào)五次或者界面上用一個(gè)僅Debug構(gòu)建才渲染的浮動(dòng)按鈕進(jìn)入Debug面板。正式包構(gòu)建時(shí)這段代碼因?yàn)闂l件判斷不成立根本不會(huì)渲染入口也就不用擔(dān)心誤觸或者被安全掃描盯上。入口設(shè)計(jì)還有一個(gè)細(xì)節(jié)開(kāi)發(fā)者模式開(kāi)關(guān)的提示狀態(tài)別寫(xiě)死。不同版本的真機(jī)對(duì)開(kāi)發(fā)者選項(xiàng)的開(kāi)放程度不同Debug入口最好同時(shí)支持“雙擊頁(yè)面空白處”這類(lèi)手勢(shì)觸發(fā)避免狀態(tài)欄遮擋或者按鈕被系統(tǒng)控件蓋住的情況。4. 訂閱dataChange讓數(shù)據(jù)庫(kù)變更自動(dòng)推送到界面4.1 dataChange的觸發(fā)時(shí)機(jī)與ChangeInfo含義手動(dòng)點(diǎn)刷新解決了“看一眼”的問(wèn)題但離“實(shí)時(shí)查看”還差一步。鴻蒙relationalStore提供了on(dataChange)訂閱能力當(dāng)事務(wù)提交后注冊(cè)了訂閱的回調(diào)會(huì)被觸發(fā)。這里有個(gè)關(guān)鍵點(diǎn)訂閱類(lèi)型是SubscribeType.COMMIT意味著不是每一條SQL執(zhí)行完立刻回調(diào)而是整個(gè)事務(wù)提交后才通知保證回調(diào)里能讀到已提交的數(shù)據(jù)?；卣{(diào)參數(shù)ChangeInfo里主要包含變更涉及的表名列表、變更類(lèi)型和變更數(shù)據(jù)明細(xì)。我經(jīng)常在實(shí)測(cè)中發(fā)現(xiàn)有人在這里犯迷糊自己在代碼里明明執(zhí)行了update訂閱卻沒(méi)反應(yīng)。排查到最后幾乎都是因?yàn)槌钟?訂閱的RdbStore實(shí)例和真正執(zhí)行寫(xiě)操作的實(shí)例不是同一個(gè)。鴻蒙的store對(duì)象需要通過(guò)getRdbStore獲取如果你在多個(gè)頁(yè)面里分別調(diào)用了getRdbStore拿到的可能是不同實(shí)例注冊(cè)在一個(gè)實(shí)例上的訂閱自然收不到另一個(gè)實(shí)例的寫(xiě)入事件。所以正確的做法是在應(yīng)用初始化階段創(chuàng)建一個(gè)全局單例RdbStore所有業(yè)務(wù)模塊和Debug面板都從同一個(gè)單例拿store。這既是避免訂閱失效的保障也是后續(xù)做緩存、做事務(wù)管理的基礎(chǔ)。4.2 自動(dòng)刷新開(kāi)關(guān)的實(shí)現(xiàn)骨架在Debug面板的表數(shù)據(jù)頁(yè)上加一個(gè)“自動(dòng)刷新”開(kāi)關(guān)開(kāi)啟時(shí)訂閱dataChange關(guān)閉時(shí)取消訂閱。訂閱回調(diào)收到變更后判斷變更表是否包含當(dāng)前正在查看的表如果包含就重新查詢當(dāng)前頁(yè)數(shù)據(jù)// 偽代碼字段名以當(dāng)前SDK提示為準(zhǔn) private onChange (changeInfo: relationalStore.ChangeInfo) { const tables changeInfo.tables as string[]; if (!tables.includes(this.currentTableName)) { return; } this.reloadCurrentPage(); }; private autoRefresh(enabled: boolean) { if (enabled) { this.store.on(dataChange, relationalStore.SubscribeType.COMMIT, this.onChange); } else { this.store.off(dataChange, relationalStore.SubscribeType.COMMIT, this.onChange); } }reloadCurrentPage的內(nèi)部實(shí)現(xiàn)就是重新調(diào)用queryPage函數(shù)然后把查詢結(jié)果通過(guò)狀態(tài)管理刷新UI。具體到ArkTS頁(yè)面可以用State管理rows數(shù)組也可以使用AppStorage做跨頁(yè)面共享看你的工程結(jié)構(gòu)習(xí)慣。4.3 多表變更時(shí)的合并刷新與性能取舍真實(shí)業(yè)務(wù)里數(shù)據(jù)變更不會(huì)只發(fā)生在你正在看的這張表上。比如一份訂單從創(chuàng)建到支付可能更新了訂單表、流水表、用戶表三處。如果訂閱回調(diào)每次觸發(fā)都立刻查一遍當(dāng)前表數(shù)據(jù)那這一瞬間可能會(huì)有多次重復(fù)查詢。我在實(shí)測(cè)里遇到過(guò)更夸張的情況某個(gè)批量導(dǎo)入功能在一個(gè)事務(wù)里寫(xiě)了幾千條數(shù)據(jù)訂閱回調(diào)連續(xù)觸發(fā)了十幾次Debug頁(yè)面每次都在重新分頁(yè)查詢屏幕瘋狂刷新完全沒(méi)法看。解決辦法是給刷新動(dòng)作加一個(gè)短防抖比如收到變更后啟動(dòng)一個(gè)200毫秒的定時(shí)器多次變更只執(zhí)行最后一次查詢private timer: number -1; private throttledReload() { if (this.timer 0) { clearTimeout(this.timer); } this.timer setTimeout(() { this.reloadCurrentPage(); this.timer -1; }, 200); }200毫秒看著不長(zhǎng)但能大幅減少查詢次數(shù)頁(yè)面刷新也不再有閃爍感。這個(gè)思路不僅適用于Debug面板業(yè)務(wù)列表頁(yè)做“寫(xiě)后刷新”同樣可以用算是RDB訂閱場(chǎng)景里的一個(gè)通用優(yōu)化。4.4 生命周期綁定必須成對(duì)出現(xiàn)的on/off訂閱容易取消訂閱容易忘。Debug頁(yè)面如果在Page銷(xiāo)毀時(shí)沒(méi)有調(diào)用off回調(diào)仍然會(huì)在每次事務(wù)提交時(shí)執(zhí)行而且會(huì)捕獲已經(jīng)銷(xiāo)毀的頁(yè)面實(shí)例輕則日志刷屏重則變量訪問(wèn)異常。雖然不一定會(huì)崩潰但這種“看不見(jiàn)的泄漏”在長(zhǎng)駐應(yīng)用里積累多了能明顯感覺(jué)到設(shè)備變卡。我習(xí)慣在aboutToDisappear里統(tǒng)一清理aboutToDisappear() { if (this.autoRefreshEnabled) { this.store.off(dataChange, relationalStore.SubscribeType.COMMIT, this.onChange); } }同時(shí)頁(yè)面退出前最好把防抖定時(shí)器也清掉避免定時(shí)器回調(diào)去操作一個(gè)不存在的頁(yè)面狀態(tài)。這個(gè)習(xí)慣一旦養(yǎng)成很多莫名其妙的偶發(fā)問(wèn)題都能從源頭上避免。5. 一套完整的日常調(diào)庫(kù)流程以及我踩過(guò)的那些坑5.1 我現(xiàn)在的三個(gè)調(diào)試階段怎么分工有了設(shè)備側(cè)拉庫(kù)、Debug面板、dataChange自動(dòng)刷新三條路我的日常調(diào)庫(kù)流程就固定下來(lái)了。寫(xiě)代碼的時(shí)候主要用hdc拉庫(kù)快速確認(rèn)字段名、表名、類(lèi)型是否符合預(yù)期。這個(gè)時(shí)候Debug面板往往還沒(méi)建好拉庫(kù)是最低成本的手段。功能自測(cè)階段打開(kāi)Debug面板每次操作完點(diǎn)刷新看數(shù)據(jù)變化不用再連電腦。聯(lián)調(diào)和回歸階段打開(kāi)自動(dòng)刷新開(kāi)關(guān)讓數(shù)據(jù)自己動(dòng)起來(lái)配合業(yè)務(wù)操作觀察列表變化任何一個(gè)寫(xiě)入異常都能第一時(shí)間暴露在屏幕上。這個(gè)流程真正跑順之后你會(huì)發(fā)現(xiàn)自己在數(shù)據(jù)庫(kù)調(diào)試上花的時(shí)間明顯變少。以前可能為了確認(rèn)一個(gè)update是否生效要寫(xiě)日志、拉文件、翻工具三步下來(lái)三五分鐘沒(méi)了現(xiàn)在打開(kāi)面板盯著就行省下來(lái)的時(shí)間還能多做幾輪自測(cè)。5.2 高頻問(wèn)題與處理方案一路踩下來(lái)我把自己經(jīng)常遇到的坑整理成了一張小表遇到同類(lèi)問(wèn)題直接照著排查?，F(xiàn)象可能原因處理方案hdc訪問(wèn)沙箱目錄報(bào)Permission denied設(shè)備調(diào)試模式受限、hdc版本不匹配升級(jí)hdc改用應(yīng)用內(nèi)導(dǎo)出文件后再拉取拉下來(lái)的db文件里看不到最新數(shù)據(jù)最新數(shù)據(jù)還在WAL文件中連同-wal、-shm文件一起拉取放同一目錄打開(kāi)dataChange回調(diào)一直不觸發(fā)注冊(cè)訂閱的store實(shí)例和執(zhí)行寫(xiě)入的store實(shí)例不同改成全局單例RdbStore自動(dòng)刷新時(shí)列表頻繁閃爍、卡頓回調(diào)里直接執(zhí)行查詢且沒(méi)有防抖查詢改為異步并加200ms合并刷新Debug入口在正式包被誤觸入口按鈕沒(méi)有做構(gòu)建條件限制用BuildProfile.DEBUG或等價(jià)標(biāo)記控制渲染這些問(wèn)題的共性是它們都不是代碼寫(xiě)不出來(lái)而是對(duì)鴻蒙沙箱和RDB機(jī)制理解不透導(dǎo)致的。我把它們寫(xiě)出來(lái)是希望后來(lái)者能夠直接繞開(kāi)。5.3 后續(xù)可以擴(kuò)展的方向Debug面板做到能看數(shù)據(jù)、能自動(dòng)刷新之后如果還有余力可以再往前走兩步。第一個(gè)是自定義SQL執(zhí)行器在面板里放一個(gè)輸入框直接執(zhí)行任意SQL并展示結(jié)果排查復(fù)雜問(wèn)題時(shí)就像在手機(jī)端裝了一個(gè)精簡(jiǎn)版數(shù)據(jù)庫(kù)管理工具。第二個(gè)是數(shù)據(jù)導(dǎo)出功能把當(dāng)前表內(nèi)容一鍵導(dǎo)出成JSON或者CSV文件寫(xiě)自動(dòng)化測(cè)試腳本或者做性能分析時(shí)非常有用。第三個(gè)方向是慢查詢?nèi)罩?。RDB執(zhí)行耗時(shí)可以通過(guò)日志跟蹤但那是系統(tǒng)層面的事在Debug面板里記錄每次querySql的耗時(shí)超過(guò)某個(gè)閾值就標(biāo)紅顯示對(duì)優(yōu)化列表頁(yè)性能很有幫助。這幾個(gè)方向我已經(jīng)陸續(xù)在做了實(shí)時(shí)查看數(shù)據(jù)庫(kù)這個(gè)需求的價(jià)值也會(huì)隨著這些功能逐步擴(kuò)大。以我個(gè)人這幾輪實(shí)測(cè)的感受來(lái)說(shuō)調(diào)試數(shù)據(jù)庫(kù)這件事工具鏈和方法論同樣重要。拉庫(kù)解決找證據(jù)面板解決看狀態(tài)訂閱解決跟變化三者結(jié)合基本覆蓋了日常開(kāi)發(fā)中所有的數(shù)據(jù)核對(duì)需求。如果你也正在鴻蒙NEXT應(yīng)用里做數(shù)據(jù)庫(kù)相關(guān)的開(kāi)發(fā)建議先花半天時(shí)間把這三條路搭起來(lái)后面調(diào)試效率的提升會(huì)非常明顯。 鴻蒙NEXT數(shù)據(jù)庫(kù)調(diào)試三板斧：拉庫(kù)、Debug面板與dataChange訂閱
說(shuō)個(gè)真實(shí)場(chǎng)景你在鴻蒙NEXT應(yīng)用里寫(xiě)了一個(gè)關(guān)系型數(shù)據(jù)庫(kù)模塊增刪改查全通了代碼也不報(bào)錯(cuò)但就是想確認(rèn)表里到底存了什么數(shù)據(jù)。最笨的辦法是翻日志一行一行打印字段數(shù)據(jù)量一多直接崩潰于是絕大多數(shù)開(kāi)發(fā)者都會(huì)想到同一件事——把數(shù)據(jù)庫(kù)文件拖出來(lái)看一眼。這個(gè)方法本身沒(méi)毛病但鴻蒙的沙箱機(jī)制和SQLite的WAL模式會(huì)讓這條老路踩不少暗坑。這篇文章就圍繞“如何實(shí)時(shí)查看數(shù)據(jù)庫(kù)”這件事把設(shè)備側(cè)拉庫(kù)、應(yīng)用內(nèi)Debug面板、dataChange自動(dòng)刷新三條路全部捋一遍給出可以直接抄的命令和代碼并且把每種方案的適用邊界說(shuō)清楚。適合正在做鴻蒙NEXT應(yīng)用、被本地?cái)?shù)據(jù)調(diào)試折磨的開(kāi)發(fā)者參考。1. 先分清“實(shí)時(shí)查看”的兩種場(chǎng)景別做重復(fù)功很多人一提“實(shí)時(shí)查看數(shù)據(jù)庫(kù)”開(kāi)口就問(wèn)“有沒(méi)有現(xiàn)成工具”。其實(shí)這個(gè)問(wèn)題拆開(kāi)看大多數(shù)時(shí)候包含兩種完全不同的訴求混在一起找方案容易兩頭不討好。1.1 調(diào)試期的“看一眼”與運(yùn)行期的“盯著看”場(chǎng)景A是開(kāi)發(fā)調(diào)試期的靜態(tài)快照式查看。應(yīng)用跑完某個(gè)功能后你想知道剛才那條記錄到底有沒(méi)有寫(xiě)進(jìn)去字段值是否符合預(yù)期。這個(gè)場(chǎng)景的核心訴求是“數(shù)據(jù)可見(jiàn)、字段可查”操作對(duì)象通常是已經(jīng)落盤(pán)的數(shù)據(jù)庫(kù)文件不需要應(yīng)用代碼參與把文件拉到電腦上用SQLite工具打開(kāi)就行。場(chǎng)景B是運(yùn)行過(guò)程中的動(dòng)態(tài)觀察式查看。應(yīng)用不停止數(shù)據(jù)持續(xù)寫(xiě)入你希望界面上的數(shù)據(jù)列表能跟著數(shù)據(jù)庫(kù)變化自動(dòng)刷新用于自測(cè)、聯(lián)調(diào)或者向測(cè)試同學(xué)演示某功能的前后數(shù)據(jù)差異。這個(gè)場(chǎng)景的核心訴求是“變化即所見(jiàn)”單純拉文件解決不了必須借助鴻蒙RDB的變更訂閱能力。這兩個(gè)場(chǎng)景的難度和實(shí)現(xiàn)路徑差異很大。場(chǎng)景A適合“快速驗(yàn)證一下”場(chǎng)景B適合“長(zhǎng)時(shí)間觀察狀態(tài)”。如果一開(kāi)始就把目標(biāo)定成“做一套自動(dòng)刷新面板”可能花了半天時(shí)間卻發(fā)現(xiàn)最初只是想看一眼字段名反過(guò)來(lái)如果只想“拉庫(kù)看一眼”又不滿足聯(lián)調(diào)時(shí)持續(xù)觀察的需求。1.2 兩種場(chǎng)景的選型判斷我做選型時(shí)習(xí)慣列一張表把使用階段、是否需要改應(yīng)用代碼、刷新方式、適合誰(shuí)來(lái)用幾個(gè)維度擺出來(lái)對(duì)比之后答案就很清楚。維度設(shè)備側(cè)拉庫(kù)查看應(yīng)用內(nèi)Debug面板dataChange自動(dòng)刷新使用階段開(kāi)發(fā)調(diào)試早期功能自測(cè)階段聯(lián)調(diào)、回歸階段是否改應(yīng)用代碼不需要純PC操作需要新增Debug頁(yè)面在Debug頁(yè)面基礎(chǔ)上加訂閱邏輯刷新方式手動(dòng)拉取離線打開(kāi)手動(dòng)點(diǎn)擊刷新數(shù)據(jù)庫(kù)變更后自動(dòng)刷新數(shù)據(jù)完整性依賴WAL文件是否合入實(shí)時(shí)查詢始終最新實(shí)時(shí)查詢始終最新硬件依賴需要連接電腦真機(jī)或模擬器均可真機(jī)或模擬器均可上手成本低命令復(fù)制即用中需要寫(xiě)UI頁(yè)面中高需要理解訂閱機(jī)制對(duì)照這張表你會(huì)發(fā)現(xiàn)三者不是替代關(guān)系而是互補(bǔ)關(guān)系。我現(xiàn)在的習(xí)慣是早期用方案一快速確認(rèn)表結(jié)構(gòu)和字段名做功能自測(cè)時(shí)打開(kāi)方案二進(jìn)入聯(lián)調(diào)階段再開(kāi)啟方案三。下面逐個(gè)展開(kāi)。2. 設(shè)備側(cè)拉庫(kù)查看最快出結(jié)果但別踩沙箱權(quán)限的坑2.1 搞清楚RDB文件到底落在哪個(gè)目錄鴻蒙NEXT的關(guān)系型數(shù)據(jù)庫(kù)relationalStore底層是SQLite數(shù)據(jù)庫(kù)文件存放在應(yīng)用沙箱的database目錄下。以默認(rèn)配置為例如果創(chuàng)建數(shù)據(jù)庫(kù)時(shí)傳的name是demo.dbbundleName是com.example.demoapp那么文件路徑通常是/data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db但這里有個(gè)很容易踩的坑不同API版本、不同構(gòu)建方式下文件落盤(pán)位置有差異。有的版本會(huì)把db文件直接放在database目錄下不經(jīng)過(guò)entry/rdb這一層有的版本還可能出現(xiàn)以bundleName命名的子目錄。所以最穩(wěn)妥的做法是先用hdc探一下真實(shí)路徑不要憑經(jīng)驗(yàn)硬寫(xiě)。在你已經(jīng)連接設(shè)備并開(kāi)啟USB調(diào)試的前提下執(zhí)行hdc shell ls -l /data/app/el2/100/database/com.example.demoapp/entry/rdb/如果輸出里能看到demo.db、demo.db-wal、demo.db-shm三個(gè)文件那說(shuō)明路徑是對(duì)的如果報(bào)錯(cuò)或者目錄不存在就換不帶entry/rdb的路徑再試hdc shell ls -l /data/app/el2/100/database/com.example.demoapp/另外數(shù)據(jù)庫(kù)文件名不一定和代碼里config.name完全一致取決于你是否傳了擴(kuò)展名。建議直接ls看實(shí)際生成的文件名而不是想當(dāng)然。2.2 拉庫(kù)的完整命令與SQLite工具打開(kāi)確認(rèn)路徑后一條命令把數(shù)據(jù)庫(kù)拉到電腦本地hdc file recv /data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db ./demo.db如果你在同一個(gè)目錄下看到了-wal和-shm文件建議一起拉下來(lái)hdc file recv /data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db-wal ./demo.db-wal hdc file recv /data/app/el2/100/database/com.example.demoapp/entry/rdb/demo.db-shm ./demo.db-shm原因很簡(jiǎn)單SQLite默認(rèn)開(kāi)啟了WAL模式最新的寫(xiě)入可能還在demo.db-wal文件里單獨(dú)拿db文件離線打開(kāi)時(shí)數(shù)據(jù)是不完整的。把三個(gè)文件放在同一目錄再打開(kāi)才能看到完整的最新?tīng)顟B(tài)。拿到文件后PC端用通用SQLite工具打開(kāi)即可比如DB Browser for SQLite這類(lèi)免費(fèi)工具能看表結(jié)構(gòu)、執(zhí)行SQL、導(dǎo)出CSV已經(jīng)覆蓋絕大多數(shù)需求。打開(kāi)時(shí)注意確認(rèn)三個(gè)文件放在同一目錄工具會(huì)自動(dòng)合并WAL內(nèi)容。2.3 權(quán)限不足時(shí)的補(bǔ)救路線先從應(yīng)用內(nèi)把庫(kù)“搬”出來(lái)如果hdc直接訪問(wèn)沙箱目錄時(shí)收到Permission denied不要急著懷疑人生。這通常是因?yàn)楫?dāng)前設(shè)備的調(diào)試模式受限或者h(yuǎn)dc連接的權(quán)限等級(jí)不夠。我有一次換了臺(tái)測(cè)試機(jī)hdc版本沒(méi)同步更新拉庫(kù)時(shí)一直報(bào)權(quán)限問(wèn)題折騰半天發(fā)現(xiàn)是設(shè)備端和PC端的hdc版本不匹配導(dǎo)致連接狀態(tài)異常升級(jí)hdc后問(wèn)題直接消失。但更多時(shí)候權(quán)限限制是真實(shí)存在的。這時(shí)候最省事的補(bǔ)救方案是在應(yīng)用內(nèi)加一段“導(dǎo)出數(shù)據(jù)庫(kù)”的臨時(shí)代碼把database目錄下的db文件復(fù)制到應(yīng)用自身的files目錄下。應(yīng)用操作自己的沙箱文件不存在權(quán)限問(wèn)題而files目錄通常位于hdc可訪問(wèn)的base路徑下之后就能正常拉取了。import { fileIo } from kit.CoreFileKit; import { common } from kit.AbilityKit; function exportDbToFiles(context: common.UIAbilityContext, dbName: string): string { const srcPath ${context.databaseDir}/${dbName}; const destDir ${context.filesDir}/export_db; fileIo.mkdirSync(destDir); const destPath ${destDir}/${dbName}; fileIo.copyFileSync(srcPath, destPath); return destPath; }注意context.databaseDir返回的是當(dāng)前應(yīng)用數(shù)據(jù)庫(kù)沙箱目錄這段代碼在應(yīng)用自己進(jìn)程內(nèi)執(zhí)行是合法的?？截愅瓿珊笤偻ㄟ^(guò)hdc拉取files目錄下的文件即可hdc shell ls /data/app/el2/100/base/com.example.demoapp/files/export_db/ hdc file recv /data/app/el2/100/base/com.example.demoapp/files/export_db/demo.db ./demo.db真實(shí)文件路徑可能因設(shè)備版本略有差異以ls實(shí)際結(jié)果為準(zhǔn)。把這個(gè)導(dǎo)出函數(shù)放在一個(gè)Debug按鈕后面只在開(kāi)發(fā)期調(diào)用交付時(shí)移除。3. 應(yīng)用內(nèi)Debug面板在屏幕上直接看數(shù)據(jù)庫(kù)內(nèi)容3.1 為什么Debug面板比頻繁插線更值得投入拉庫(kù)這條路雖然直接但每次都要連電腦、敲命令、打開(kāi)PC工具做一次數(shù)據(jù)確認(rèn)至少一分鐘起步。如果你正在做列表頁(yè)聯(lián)調(diào)改一次數(shù)據(jù)就要確認(rèn)一次數(shù)據(jù)庫(kù)狀態(tài)來(lái)回插拔數(shù)據(jù)線能把人逼瘋。應(yīng)用內(nèi)Debug面板的思路就簡(jiǎn)單了在App里加一個(gè)隱藏頁(yè)面用RDB查詢能力讀取表結(jié)構(gòu)和數(shù)據(jù)在手機(jī)上直接展示。功能自測(cè)或者給同事演示時(shí)打開(kāi)面板就能看到數(shù)據(jù)不需要任何PC操作。更重要的是這個(gè)面板是所有后續(xù)自動(dòng)刷新功能的載體——不先把數(shù)據(jù)展示做好談?dòng)嗛喫⑿露际强照?。我做這個(gè)面板時(shí)目標(biāo)非?？酥颇芰谐鏊斜?、能看每張表的行數(shù)、能點(diǎn)進(jìn)表看數(shù)據(jù)明細(xì)、能手動(dòng)刷新。這四個(gè)能力已經(jīng)覆蓋90%的調(diào)試需求再多的功能都屬于錦上添花后面可以按需擴(kuò)展。3.2 讀取表結(jié)構(gòu)拿sqlite_master當(dāng)入口RDB提供了querySql接口可以直接執(zhí)行任意SQL。要拿到數(shù)據(jù)庫(kù)里的全部表名最直接的方式是查詢SQLite自帶的元數(shù)據(jù)表sqlite_masterimport { relationalStore } from kit.ArkData; async function queryAllTables(store: relationalStore.RdbStore): Promisestring[] { const resultSet await store.querySql(SELECT name FROM sqlite_master WHERE type table ORDER BY name); const tables: string[] []; while (resultSet.goToNextRow()) { tables.push(resultSet.getString(resultSet.getColumnIndex(name))); } resultSet.close(); return tables; }拿到表名列表后逐表查詢行數(shù)。行數(shù)查詢用RdbPredicates的count接口async function getTableCount(store: relationalStore.RdbStore, tableName: string): Promisenumber { const predicates new relationalStore.RdbPredicates(tableName); return await store.count(predicates); }面板首頁(yè)的核心邏輯就是這兩段。頁(yè)面用一個(gè)List組件把表名和行數(shù)渲染成列表項(xiàng)點(diǎn)擊某項(xiàng)跳轉(zhuǎn)到表數(shù)據(jù)詳情頁(yè)。這里有個(gè)小細(xì)節(jié)查詢sqlite_master時(shí)最好把以sqlite_開(kāi)頭的內(nèi)部表過(guò)濾掉否則面板上會(huì)混入一些你從來(lái)沒(méi)見(jiàn)過(guò)也無(wú)權(quán)操作的系統(tǒng)表看著礙眼。3.3 表數(shù)據(jù)頁(yè)的展示與翻頁(yè)實(shí)現(xiàn)點(diǎn)擊某張表進(jìn)入詳情頁(yè)后需要分頁(yè)讀取數(shù)據(jù)。鴻蒙RDB的RdbPredicates提供了limitAs方法可以指定偏移量和每頁(yè)大小async function queryPage( store: relationalStore.RdbStore, tableName: string, page: number, pageSize: number, ): Promise{ columns: string[]; rows: ArrayRecordstring, string | number | null } { const predicates new relationalStore.RdbPredicates(tableName); predicates.limitAs(page * pageSize, pageSize); const resultSet await store.query(predicates); const columns resultSet.columnNames; const rows: ArrayRecordstring, string | number | null []; while (resultSet.goToNextRow()) { const row: Recordstring, string | number | null {}; for (const col of columns) { const index resultSet.getColumnIndex(col); const value resultSet.getValue(index); row[col] value; } rows.push(row); } resultSet.close(); return { columns, rows }; }這段代碼把ResultSet里的數(shù)據(jù)一次性轉(zhuǎn)成了普通對(duì)象數(shù)組方便交給UI層渲染。這里必須強(qiáng)調(diào)的是不要在UI線程里直接遍歷ResultSet——如果表數(shù)據(jù)量大一次goToNextRow循環(huán)會(huì)卡住頁(yè)面。先轉(zhuǎn)成數(shù)組再setState是一個(gè)基本但重要的習(xí)慣。UI層用List組件配合ForEach即可。每一行數(shù)據(jù)按“字段名: 值”的形式橫向排布字段太多時(shí)允許橫向滾動(dòng)。頁(yè)面底部放兩個(gè)按鈕上一頁(yè)、下一頁(yè)分別修改當(dāng)前頁(yè)碼后重新查詢。頁(yè)大小建議固定20行避免一次查詢過(guò)大導(dǎo)致渲染卡頓。3.4 給面板加一個(gè)“僅Debug環(huán)境可見(jiàn)”的入口Debug面板做得再好也不能讓它出現(xiàn)在正式包里。鴻蒙工程里常見(jiàn)做法是讀取構(gòu)建標(biāo)記只有DEBUG為true時(shí)才顯示入口。以Stage模型為例在首頁(yè)的aboutToAppear里判斷import { BuildProfile } from ohos.buildProfile; const isDebug BuildProfile.DEBUG true;在首頁(yè)某個(gè)不太顯眼的位置比如設(shè)置項(xiàng)里連點(diǎn)版本號(hào)五次或者界面上用一個(gè)僅Debug構(gòu)建才渲染的浮動(dòng)按鈕進(jìn)入Debug面板。正式包構(gòu)建時(shí)這段代碼因?yàn)闂l件判斷不成立根本不會(huì)渲染入口也就不用擔(dān)心誤觸或者被安全掃描盯上。入口設(shè)計(jì)還有一個(gè)細(xì)節(jié)開(kāi)發(fā)者模式開(kāi)關(guān)的提示狀態(tài)別寫(xiě)死。不同版本的真機(jī)對(duì)開(kāi)發(fā)者選項(xiàng)的開(kāi)放程度不同Debug入口最好同時(shí)支持“雙擊頁(yè)面空白處”這類(lèi)手勢(shì)觸發(fā)避免狀態(tài)欄遮擋或者按鈕被系統(tǒng)控件蓋住的情況。4. 訂閱dataChange讓數(shù)據(jù)庫(kù)變更自動(dòng)推送到界面4.1 dataChange的觸發(fā)時(shí)機(jī)與ChangeInfo含義手動(dòng)點(diǎn)刷新解決了“看一眼”的問(wèn)題但離“實(shí)時(shí)查看”還差一步。鴻蒙relationalStore提供了on(dataChange)訂閱能力當(dāng)事務(wù)提交后注冊(cè)了訂閱的回調(diào)會(huì)被觸發(fā)。這里有個(gè)關(guān)鍵點(diǎn)訂閱類(lèi)型是SubscribeType.COMMIT意味著不是每一條SQL執(zhí)行完立刻回調(diào)而是整個(gè)事務(wù)提交后才通知保證回調(diào)里能讀到已提交的數(shù)據(jù)?；卣{(diào)參數(shù)ChangeInfo里主要包含變更涉及的表名列表、變更類(lèi)型和變更數(shù)據(jù)明細(xì)。我經(jīng)常在實(shí)測(cè)中發(fā)現(xiàn)有人在這里犯迷糊自己在代碼里明明執(zhí)行了update訂閱卻沒(méi)反應(yīng)。排查到最后幾乎都是因?yàn)槌钟?訂閱的RdbStore實(shí)例和真正執(zhí)行寫(xiě)操作的實(shí)例不是同一個(gè)。鴻蒙的store對(duì)象需要通過(guò)getRdbStore獲取如果你在多個(gè)頁(yè)面里分別調(diào)用了getRdbStore拿到的可能是不同實(shí)例注冊(cè)在一個(gè)實(shí)例上的訂閱自然收不到另一個(gè)實(shí)例的寫(xiě)入事件。所以正確的做法是在應(yīng)用初始化階段創(chuàng)建一個(gè)全局單例RdbStore所有業(yè)務(wù)模塊和Debug面板都從同一個(gè)單例拿store。這既是避免訂閱失效的保障也是后續(xù)做緩存、做事務(wù)管理的基礎(chǔ)。4.2 自動(dòng)刷新開(kāi)關(guān)的實(shí)現(xiàn)骨架在Debug面板的表數(shù)據(jù)頁(yè)上加一個(gè)“自動(dòng)刷新”開(kāi)關(guān)開(kāi)啟時(shí)訂閱dataChange關(guān)閉時(shí)取消訂閱。訂閱回調(diào)收到變更后判斷變更表是否包含當(dāng)前正在查看的表如果包含就重新查詢當(dāng)前頁(yè)數(shù)據(jù)// 偽代碼字段名以當(dāng)前SDK提示為準(zhǔn) private onChange (changeInfo: relationalStore.ChangeInfo) { const tables changeInfo.tables as string[]; if (!tables.includes(this.currentTableName)) { return; } this.reloadCurrentPage(); }; private autoRefresh(enabled: boolean) { if (enabled) { this.store.on(dataChange, relationalStore.SubscribeType.COMMIT, this.onChange); } else { this.store.off(dataChange, relationalStore.SubscribeType.COMMIT, this.onChange); } }reloadCurrentPage的內(nèi)部實(shí)現(xiàn)就是重新調(diào)用queryPage函數(shù)然后把查詢結(jié)果通過(guò)狀態(tài)管理刷新UI。具體到ArkTS頁(yè)面可以用State管理rows數(shù)組也可以使用AppStorage做跨頁(yè)面共享看你的工程結(jié)構(gòu)習(xí)慣。4.3 多表變更時(shí)的合并刷新與性能取舍真實(shí)業(yè)務(wù)里數(shù)據(jù)變更不會(huì)只發(fā)生在你正在看的這張表上。比如一份訂單從創(chuàng)建到支付可能更新了訂單表、流水表、用戶表三處。如果訂閱回調(diào)每次觸發(fā)都立刻查一遍當(dāng)前表數(shù)據(jù)那這一瞬間可能會(huì)有多次重復(fù)查詢。我在實(shí)測(cè)里遇到過(guò)更夸張的情況某個(gè)批量導(dǎo)入功能在一個(gè)事務(wù)里寫(xiě)了幾千條數(shù)據(jù)訂閱回調(diào)連續(xù)觸發(fā)了十幾次Debug頁(yè)面每次都在重新分頁(yè)查詢屏幕瘋狂刷新完全沒(méi)法看。解決辦法是給刷新動(dòng)作加一個(gè)短防抖比如收到變更后啟動(dòng)一個(gè)200毫秒的定時(shí)器多次變更只執(zhí)行最后一次查詢private timer: number -1; private throttledReload() { if (this.timer 0) { clearTimeout(this.timer); } this.timer setTimeout(() { this.reloadCurrentPage(); this.timer -1; }, 200); }200毫秒看著不長(zhǎng)但能大幅減少查詢次數(shù)頁(yè)面刷新也不再有閃爍感。這個(gè)思路不僅適用于Debug面板業(yè)務(wù)列表頁(yè)做“寫(xiě)后刷新”同樣可以用算是RDB訂閱場(chǎng)景里的一個(gè)通用優(yōu)化。4.4 生命周期綁定必須成對(duì)出現(xiàn)的on/off訂閱容易取消訂閱容易忘。Debug頁(yè)面如果在Page銷(xiāo)毀時(shí)沒(méi)有調(diào)用off回調(diào)仍然會(huì)在每次事務(wù)提交時(shí)執(zhí)行而且會(huì)捕獲已經(jīng)銷(xiāo)毀的頁(yè)面實(shí)例輕則日志刷屏重則變量訪問(wèn)異常。雖然不一定會(huì)崩潰但這種“看不見(jiàn)的泄漏”在長(zhǎng)駐應(yīng)用里積累多了能明顯感覺(jué)到設(shè)備變卡。我習(xí)慣在aboutToDisappear里統(tǒng)一清理aboutToDisappear() { if (this.autoRefreshEnabled) { this.store.off(dataChange, relationalStore.SubscribeType.COMMIT, this.onChange); } }同時(shí)頁(yè)面退出前最好把防抖定時(shí)器也清掉避免定時(shí)器回調(diào)去操作一個(gè)不存在的頁(yè)面狀態(tài)。這個(gè)習(xí)慣一旦養(yǎng)成很多莫名其妙的偶發(fā)問(wèn)題都能從源頭上避免。5. 一套完整的日常調(diào)庫(kù)流程以及我踩過(guò)的那些坑5.1 我現(xiàn)在的三個(gè)調(diào)試階段怎么分工有了設(shè)備側(cè)拉庫(kù)、Debug面板、dataChange自動(dòng)刷新三條路我的日常調(diào)庫(kù)流程就固定下來(lái)了。寫(xiě)代碼的時(shí)候主要用hdc拉庫(kù)快速確認(rèn)字段名、表名、類(lèi)型是否符合預(yù)期。這個(gè)時(shí)候Debug面板往往還沒(méi)建好拉庫(kù)是最低成本的手段。功能自測(cè)階段打開(kāi)Debug面板每次操作完點(diǎn)刷新看數(shù)據(jù)變化不用再連電腦。聯(lián)調(diào)和回歸階段打開(kāi)自動(dòng)刷新開(kāi)關(guān)讓數(shù)據(jù)自己動(dòng)起來(lái)配合業(yè)務(wù)操作觀察列表變化任何一個(gè)寫(xiě)入異常都能第一時(shí)間暴露在屏幕上。這個(gè)流程真正跑順之后你會(huì)發(fā)現(xiàn)自己在數(shù)據(jù)庫(kù)調(diào)試上花的時(shí)間明顯變少。以前可能為了確認(rèn)一個(gè)update是否生效要寫(xiě)日志、拉文件、翻工具三步下來(lái)三五分鐘沒(méi)了現(xiàn)在打開(kāi)面板盯著就行省下來(lái)的時(shí)間還能多做幾輪自測(cè)。5.2 高頻問(wèn)題與處理方案一路踩下來(lái)我把自己經(jīng)常遇到的坑整理成了一張小表遇到同類(lèi)問(wèn)題直接照著排查?，F(xiàn)象可能原因處理方案hdc訪問(wèn)沙箱目錄報(bào)Permission denied設(shè)備調(diào)試模式受限、hdc版本不匹配升級(jí)hdc改用應(yīng)用內(nèi)導(dǎo)出文件后再拉取拉下來(lái)的db文件里看不到最新數(shù)據(jù)最新數(shù)據(jù)還在WAL文件中連同-wal、-shm文件一起拉取放同一目錄打開(kāi)dataChange回調(diào)一直不觸發(fā)注冊(cè)訂閱的store實(shí)例和執(zhí)行寫(xiě)入的store實(shí)例不同改成全局單例RdbStore自動(dòng)刷新時(shí)列表頻繁閃爍、卡頓回調(diào)里直接執(zhí)行查詢且沒(méi)有防抖查詢改為異步并加200ms合并刷新Debug入口在正式包被誤觸入口按鈕沒(méi)有做構(gòu)建條件限制用BuildProfile.DEBUG或等價(jià)標(biāo)記控制渲染這些問(wèn)題的共性是它們都不是代碼寫(xiě)不出來(lái)而是對(duì)鴻蒙沙箱和RDB機(jī)制理解不透導(dǎo)致的。我把它們寫(xiě)出來(lái)是希望后來(lái)者能夠直接繞開(kāi)。5.3 后續(xù)可以擴(kuò)展的方向Debug面板做到能看數(shù)據(jù)、能自動(dòng)刷新之后如果還有余力可以再往前走兩步。第一個(gè)是自定義SQL執(zhí)行器在面板里放一個(gè)輸入框直接執(zhí)行任意SQL并展示結(jié)果排查復(fù)雜問(wèn)題時(shí)就像在手機(jī)端裝了一個(gè)精簡(jiǎn)版數(shù)據(jù)庫(kù)管理工具。第二個(gè)是數(shù)據(jù)導(dǎo)出功能把當(dāng)前表內(nèi)容一鍵導(dǎo)出成JSON或者CSV文件寫(xiě)自動(dòng)化測(cè)試腳本或者做性能分析時(shí)非常有用。第三個(gè)方向是慢查詢?nèi)罩?。RDB執(zhí)行耗時(shí)可以通過(guò)日志跟蹤但那是系統(tǒng)層面的事在Debug面板里記錄每次querySql的耗時(shí)超過(guò)某個(gè)閾值就標(biāo)紅顯示對(duì)優(yōu)化列表頁(yè)性能很有幫助。這幾個(gè)方向我已經(jīng)陸續(xù)在做了實(shí)時(shí)查看數(shù)據(jù)庫(kù)這個(gè)需求的價(jià)值也會(huì)隨著這些功能逐步擴(kuò)大。以我個(gè)人這幾輪實(shí)測(cè)的感受來(lái)說(shuō)調(diào)試數(shù)據(jù)庫(kù)這件事工具鏈和方法論同樣重要。拉庫(kù)解決找證據(jù)面板解決看狀態(tài)訂閱解決跟變化三者結(jié)合基本覆蓋了日常開(kāi)發(fā)中所有的數(shù)據(jù)核對(duì)需求。如果你也正在鴻蒙NEXT應(yīng)用里做數(shù)據(jù)庫(kù)相關(guān)的開(kāi)發(fā)建議先花半天時(shí)間把這三條路搭起來(lái)后面調(diào)試效率的提升會(huì)非常明顯。