上周陪一個團隊排查HarmonyOS應(yīng)用的更新問題他們的應(yīng)用還沒上架測試在“檢查更新”上點了半天頁面紋絲不動。負責(zé)產(chǎn)品的同事問我更新功能是不是必須上架才能調(diào)試我說不是更新鏈路拆開看真正要驗證的東西和上不上架沒有必然關(guān)系。真正需要解決的是“未上架時沒有應(yīng)用市場幫你分發(fā)新版本”但你完全可以用一個本地服務(wù)模擬這個分發(fā)動作把整個流程測通。這篇就記錄一下我怎么在應(yīng)用未上架的情況下完整調(diào)試和檢測HarmonyOS應(yīng)用更新功能是否正常的。先說結(jié)論未上架不影響你驗證“檢查更新邏輯是否正確、下載流程是否通、安裝拉起是否順利”這三件事。應(yīng)用市場在上架后只是多了一個官方分發(fā)渠道而我們在調(diào)試階段需要的只是一個可控的“更新源”。1. 更新鏈路拆開看未上架時真正要驗證的是哪三件事很多團隊一聽到“未上架”就覺得更新功能沒法測其實是把“應(yīng)用市場能力”和“應(yīng)用自身邏輯”混在一起了。應(yīng)用更新功能在代碼層面只做三件事對比版本、取回新包、交給系統(tǒng)安裝。這三件事運行在應(yīng)用內(nèi)不依賴應(yīng)用市場。1.1 更新不是“點個按鈕”而是三段鏈路第一段是檢測更新。應(yīng)用啟動或者用戶點擊檢查更新時客戶端把當前版本號發(fā)給服務(wù)器服務(wù)器返回“有沒有新版本、新版本號、下載地址、包大小”等信息。這一段的核心是版本號讀取和網(wǎng)絡(luò)請求只要服務(wù)器接口可控沒上架也一樣能測。第二段是下載新包。確認有新版本后客戶端把hap包下載到應(yīng)用自己的沙箱目錄里。這段的核心是下載任務(wù)調(diào)度、進度回調(diào)和異常處理和上架不上架沒有半點關(guān)系。實際調(diào)試時你會發(fā)現(xiàn)下載階段最容易出問題的是路徑寫錯、權(quán)限沒配、防火墻攔截。第三段是拉起安裝。下載完成后應(yīng)用需要調(diào)用系統(tǒng)安裝能力把hap包路徑通過Intent傳給系統(tǒng)由系統(tǒng)彈窗讓用戶確認安裝。這一段的重點是“系統(tǒng)是否接受這個包”安裝成功與否取決于包簽名、版本號和系統(tǒng)安裝策略這些和上架狀態(tài)也無關(guān)。所以你看整個更新功能能不能跑通取決于你寫的代碼和測試服務(wù)器的配合而不是應(yīng)用市場。未上架唯一的影響是你拿不到AppGallery Connect那邊托管的“正式更新源”需要自己搭一個。1.2 未上架到底缺了什么應(yīng)用市場通道與本地自建通道的差異如果用了華為應(yīng)用市場提供的“應(yīng)用內(nèi)更新”SDK那確實要上架后在AGC后臺配置版本才能分發(fā)。SDK會去應(yīng)用市場后臺拉取升級包列表應(yīng)用沒上架時這個列表根本不存在自然返回不了任何更新信息。所以如果你走的是官方SDK路線未上架階段測不出來是正常的這是第一個必須認清的差異。但自建更新通道是完全繞開應(yīng)用市場的服務(wù)器地址、版本規(guī)則、包分發(fā)全由你自己控制。未上架階段你完全可以搭一個臨時的HTTP服務(wù)放一個測試hap包讓手機走局域網(wǎng)訪問這個服務(wù)來完成整個更新閉環(huán)。這個閉環(huán)一旦跑通等上架后再切到官方SDK邏輯驗證成本會低很多。另外還要提醒一點AppGallery的“應(yīng)用內(nèi)更新”SDK在應(yīng)用未上架時有時會返回特定的錯誤碼比如未配置或未授權(quán)。如果你在未上架階段看到這類錯誤不要慌不代表代碼寫錯了只是渠道還沒激活。1.3 先定驗收標準什么樣的狀態(tài)才算“更新功能正?！闭{(diào)試之前先明確“正?！钡暮x后面才不會測了個寂寞。我的驗收標準很簡單四個鉤子全打上就算通過老版本啟動后能正確觸發(fā)檢查更新服務(wù)器日志能看到請求返回數(shù)據(jù)能被解析。檢測到新版本后提示語、版本號、包大小展示正確用戶點擊確認后開始下載。下載過程有進度反饋下載完成后文件確實落在沙箱目錄里大小和服務(wù)器一致。系統(tǒng)安裝頁面能正常拉起用戶確認后安裝成功重新打開應(yīng)用顯示的是新版本號。這四條聽起來樸素但真跑起來你會發(fā)現(xiàn)卡在第二條和第四條的情況最多。后面我會按這個標準鋪開講怎么操作。2. 版本讀取、下載與安裝拉起HarmonyOS更新鏈路的核心API進入實操前先把更新鏈路涉及的HarmonyOS API過一遍。這部分我不打算貼一堆官方文檔只挑你寫代碼時真正會用到的東西講順便說說容易踩的坑。2.1 拿當前版本號versionCode 與 versionName 別混淆更新檢測的第一件事就是知道自己當前是什么版本。HarmonyOS應(yīng)用的版本信息有兩個字段versionCode是整數(shù)必須遞增機器比較用它versionName是字符串給用戶看的比如“1.0.2”。很多新手用versionName比較大小寫過一次就知道有多坑這個我放到第五章再說。讀取版本號的代碼框架大概是這樣的// 示意代碼不同SDK版本的導(dǎo)入路徑略有差異 import { bundleManager } from kit.AbilityKit; let bundleInfo bundleManager.getBundleInfoForSelfSync( bundleManager.BundleFlag.GET_BUNDLE_INFO_WITH_APPLICATION ); let currentVersionCode bundleInfo.versionCode; // 整數(shù)用于邏輯比較 let currentVersionName bundleInfo.versionName; // 字符串用于界面展示注意一點在API 12HarmonyOS NEXT的Kit化寫法里模塊導(dǎo)入路徑可能和API 9時代的ohos.bundle.bundleManager不同。你自己工程里按SDK文檔確認即可重點是拿到versionCode和versionName這兩個字段。我在實際項目里習(xí)慣把這兩個值在應(yīng)用啟動時打一條日志這樣后面用hdc看日志時第一件事就能確認當前裝的到底是哪個版本排查問題不必靠猜。2.2 檢查更新用 http 請求問服務(wù)器要版本信息檢查更新本質(zhì)就是一個GET請求。客戶端把當前versionCode帶給服務(wù)器服務(wù)器返回有沒有新版本。HarmonyOS上標準的做法是使用ohos.net.http模塊大致寫法如下import { http } from kit.NetworkKit; let httpRequest http.createHttp(); httpRequest.request( http://192.168.1.100:8080/api/update?versionCode currentVersionCode, { method: http.RequestMethod.GET, connectTimeout: 10000, readTimeout: 10000 } ).then((response) { if (response.responseCode 200) { // 解析JSON判斷 hasUpdate 和 serverVersionCode let result JSON.parse(response.result as string); // 先判斷網(wǎng)絡(luò)層再判斷業(yè)務(wù)層 } }).catch(() { // 斷網(wǎng)、超時、地址不可達都會走到這里 });這里我強烈建議把超時時間設(shè)置好不要依賴默認值。我在真機調(diào)試時遇到過一種情況電腦開了防火墻手機訪問不到本地服務(wù)結(jié)果客戶端一直轉(zhuǎn)圈不報錯后來才發(fā)現(xiàn)是超時時間設(shè)得太長體驗上像“卡死”。服務(wù)端返回的數(shù)據(jù)結(jié)構(gòu)建議固定一套至少要包含hasUpdate、versionCode、versionName、downloadUrl、size這幾個字段。后面章節(jié)我會給一個可以直接跑的本地服務(wù)示例字段就是按這套來的。2.3 下載新包官方下載任務(wù)與本地路徑選擇下載hap包推薦用ohos.request模塊的下載任務(wù)而不是自己拿HTTP流一段段寫文件。理由很簡單官方下載任務(wù)自帶進度回調(diào)和斷點續(xù)傳能力代碼量少穩(wěn)定性高。import { request } from kit.BasicServicesKit; let downloadTask await request.downloadFile(context, { url: http://192.168.1.100:8080/app-1.0.2.hap, filePath: ${context.cacheDir}/update/app-1.0.2.hap }); downloadTask.on(progress, (data) { console.info(UpdateManager progress: ${data.receivedSize}/${data.totalSize}); });文件路徑這塊是個隱性坑。我見過不少人把更新包直接寫到filesDir結(jié)果安裝時會遇到沙箱路徑傳參問題。我的建議是下載到cacheDir/update/下面原因有兩個一是更新包屬于臨時數(shù)據(jù)裝完就應(yīng)該清理二是cacheDir空間被系統(tǒng)清理不影響用戶業(yè)務(wù)數(shù)據(jù)即使更新包殘留也不會白白占用用戶手機空間。下載完成后什么算成功標準有兩層下載任務(wù)狀態(tài)正常返回且落盤文件大小與服務(wù)器返回的size一致。如果服務(wù)器能提供MD5建議再校驗一遍調(diào)試階段可以省掉但正式上線最好加上。2.4 拉起安裝把 hap 交給系統(tǒng)讓用戶確認下載完成后就是拉起系統(tǒng)安裝頁面。HarmonyOS里應(yīng)用自身不能靜默安裝必須通過系統(tǒng)安裝能力最終由用戶點擊確認。代碼結(jié)構(gòu)如下// 示意代碼具體action與參數(shù)名以當前SDK文檔為準 let want { action: ohos.intent.action.INSTALL_PACKAGE, parameters: { path: ${context.cacheDir}/update/app-1.0.2.hap } }; context.startAbility(want).then(() { console.info(UpdateManager: install page launched); }).catch((err) { console.error(UpdateManager: startAbility failed, ${JSON.stringify(err)}); });這一段在API 12HarmonyOS NEXT上行為會比舊版嚴格很多。系統(tǒng)會強制校驗hap包的簽名和來源如果簽名不一致安裝頁面會直接拒絕或者安裝到一半報“安裝失敗”。這也是我說未上架調(diào)試時最容易碰壁的點具體原因在第五章展開。另外安裝結(jié)果不在startAbility的返回值里因為拉起安裝頁后用戶可能確認、取消、也可能因為簽名問題直接失敗。你需要通過“安裝后重查版本號”來驗證是否真的裝上了這個檢測方法我放在第四章第4節(jié)。3. 把“遠端更新源”搬到本地搭建調(diào)試版本服務(wù)與測試包如果你已經(jīng)有一個測試服務(wù)器可以跳過本章直接看第四章的檢測清單。如果和我一樣平時主要用DevEco Studio本機調(diào)試那這一章就是為你準備的——十分鐘搭一個本地更新源讓手機和平板能訪問到。3.1 準備兩個版本的測試 hap更新鏈路要跑通至少需要兩個不同versionCode的包一個當當前安裝的老版本一個當服務(wù)器上的新版本。操作上很簡單在DevEco Studio里把app.json5的versionCode先設(shè)成1000001打一個包安裝到手機然后把versionCode改到1000002再把versionName改成1.0.2打出的這個包放到你的更新服務(wù)器目錄下。有一個細節(jié)要注意調(diào)試階段建議都用同一個簽名來打這兩個包。如果你用DevEco Studio的自動簽名Debug簽名裝老版本但塞到服務(wù)器上的新版本換了上傳簽名或Release簽名那安裝環(huán)節(jié)會報簽名不一致干擾你判斷“工期是不是真的通了”。還有一個技巧為了讓下載進度看得清楚你可以在新版本里隨便塞一個幾MB的素材讓hap包大一點這樣下載進度條變化明顯不會一兩秒就閃過去。3.2 一個十分鐘就能跑起來的本地更新服務(wù)我一直覺得調(diào)試階段沒必要上個完整后端Python的標準庫就能搞定更新接口和文件托管。下面這個腳本可以直接保存為update_server.py運行# update_server.py -- 本機調(diào)試用不建議直接上生產(chǎn) import json import os from http.server import BaseHTTPRequestHandler, HTTPServer from urllib.parse import urlparse, parse_qs HAP_FILE app-1.0.2.hap # 與腳本放同一個目錄 CURRENT_CODE 1000002 # 服務(wù)器認為的最新版本號 PORT 8080 class UpdateHandler(BaseHTTPRequestHandler): def log_message(self, fmt, *args): pass # 去掉默認的訪問日志噪音 def do_GET(self): url urlparse(self.path) if url.path /api/update: current int(parse_qs(url.query).get(versionCode, [0])[0]) if current CURRENT_CODE: data { code: 0, data: { hasUpdate: True, versionCode: CURRENT_CODE, versionName: 1.0.2, downloadUrl: http://電腦局域網(wǎng)IP:8080/app-1.0.2.hap } } else: data {code: 0, data: {hasUpdate: False}} body json.dumps(data).encode(utf-8) self.send_response(200) self.send_header(Content-Type, application/json; charsetutf-8) self.send_header(Content-Length, str(len(body))) self.end_headers() self.wfile.write(body) elif url.path f/{HAP_FILE}: if not os.path.exists(HAP_FILE): self.send_error(404) return self.send_response(200) self.send_header(Content-Type, application/octet-stream) self.send_header(Content-Length, str(os.path.getsize(HAP_FILE))) self.end_headers() with open(HAP_FILE, rb) as f: self.wfile.write(f.read()) else: self.send_error(404) if __name__ __main__: HTTPServer((0.0.0.0, PORT), UpdateHandler).serve_forever()啟動后先用電腦瀏覽器驗證一下訪問http://127.0.0.1:8080/api/update?versionCode1000001應(yīng)該能看到JSON返回hasUpdate: true。再把versionCode1000002傳一次應(yīng)該返回hasUpdate: false。接口通了這個服務(wù)就跑起來。這里那個電腦局域網(wǎng)IP需要你換成實際的IP不要照抄。真機訪問時不能填127.0.0.1那是手機自己。3.3 讓手機/平板找到開發(fā)電腦最省事的方案是讓手機和電腦連同一個WiFi然后給手機一個局域網(wǎng)IP下的下載地址。電腦IP怎么查Windows下在命令行敲ipconfig找“無線局域網(wǎng)適配器 WLAN”下面的IPv4地址Mac下在終端敲ipconfig getifaddr en0Linux桌面用ip addr。查到IP后先做兩件事驗證連通性手機瀏覽器直接訪問http://電腦IP:8080/app-1.0.2.hap能看到下載動作就是通的。如果打不開九成是電腦防火墻攔了8080端口。Windows在“允許應(yīng)用通過防火墻”里放行Python或者在入站規(guī)則里臨時放行8080然后重試。如果你用的是DevEco Studio的模擬器就不存在局域網(wǎng)IP的問題但模擬器訪問宿主機通常有專用的映射地址查一下當前模擬器的網(wǎng)絡(luò)說明就行不要照搬真機的IP方案。3.4 權(quán)限與明文HTTP調(diào)試期的小配置HarmonyOS應(yīng)用要訪問網(wǎng)絡(luò)必須先在module.json5里申請ohos.permission.INTERNET權(quán)限。忘了這一步請求會直接失敗而且有時候日志不直觀。{ module: { name: entry, type: entry, requestPermissions: [ { name: ohos.permission.INTERNET } ] } }還有一個隱形問題本地調(diào)試時服務(wù)器地址是http://明文而HarmonyOS從某個版本開始對明文流量有限制。如果請求發(fā)起后一直報錯提示不安全連接要么臨時在網(wǎng)絡(luò)配置里放行明文流量要么干脆把本地服務(wù)套一層HTTPS開發(fā)環(huán)境也可以用openssl生成自簽名證書但真機上還要處理證書信任比較麻煩。我的經(jīng)驗是調(diào)試期優(yōu)先處理明文HTTP的放行把鏈路跑通正式上線再統(tǒng)一換HTTPS不要一上來就糾結(jié)證書。4. 從觸發(fā)更新到安裝成功調(diào)試檢測的完整操作清單環(huán)境搭好了代碼也寫得差不多了接下來按步驟把整個更新功能從頭到尾測一遍。這一章我給出一套可復(fù)用的操作清單每一步都帶預(yù)期結(jié)果方便自測也方便團隊內(nèi)部轉(zhuǎn)交。4.1 確認當前版本先排除“裝的不是你以為的包”調(diào)試最怕的是你辛辛苦苦測了半小時最后發(fā)現(xiàn)手機上裝的包根本不是你以為的那個版本。所以第一步永遠是把當前版本確認清楚。手機上可以直接看應(yīng)用“關(guān)于”頁里的版本號但更可靠的方式是用hdc命令行工具hdc shell bm dump -n 你的包名 | grep -E versionCode|versionNamebm dump是鴻蒙設(shè)備側(cè)的包管理命令能直接看到已安裝應(yīng)用的版本信息。hdc工具在DevEco Studio的toolchains目錄下把它的路徑加到環(huán)境變量里或者直接在DevEco終端里執(zhí)行。這一條命令應(yīng)該出現(xiàn)在你的調(diào)試肌肉記憶里因為它能同時驗證兩件事應(yīng)用裝沒裝上、裝的是哪個版本。4.2 觸發(fā)更新并驗證請求與返回版本確認后進入應(yīng)用執(zhí)行檢查更新的動作點按鈕或等自動觸發(fā)。此時打開本地更新服務(wù)器的終端窗口應(yīng)該能看到客戶端發(fā)來的請求記錄。我腳本里屏蔽了默認日志如果你想觀察請求可以臨時在do_GET里加一行print(self.path)。這一步的驗證點有三個客戶端確實發(fā)出了帶versionCode參數(shù)的請求。服務(wù)器返回的JSON能被客戶端正確解析沒有類型轉(zhuǎn)換之類的崩潰。返回hasUpdate: true時界面彈出了更新提示框版本號、更新說明文案和服務(wù)器返回一致。如果提示框沒彈出來優(yōu)先看客戶端日志里解析是否異常再看服務(wù)器返回的JSON格式是否符合預(yù)期。我遇到過一種情況服務(wù)器返回的versionName是1.0.2但客戶端代碼用了parseInt去轉(zhuǎn)換直接導(dǎo)致提示框崩潰這種小問題在聯(lián)調(diào)階段特別容易發(fā)生。4.3 下載階段的進度與異常驗證提示框彈出后點擊“立即更新”進入下載階段。這時候你的本地服務(wù)器會開始傳輸hap文件。正常的現(xiàn)象是客戶端出現(xiàn)進度條或者通過日志能看到progress回調(diào)的receivedSize在增長。建議刻意做兩次異常測試測試一下載過程中把手機WiFi斷掉觀察客戶端有沒有走到失敗分支有沒有給出“下載失敗請重試”之類的提示。很多團隊只測順風(fēng)路斷網(wǎng)場景根本沒人看。測試二服務(wù)器返回的size字段故意寫成錯誤的比如比真實大小大很多看客戶端下載完成后會不會做大小校驗。如果代碼里直接跳過校驗這個問題會在用戶身上以“下載完成但安裝失敗”的形式暴露。下載完成的正常標準日志看到progress達到totalSize然后應(yīng)用跳轉(zhuǎn)到拉起安裝的邏輯。你還可以在下載完成后用hdc進文件目錄看一眼hdc shell ls -l /data/app/el2/100/base/你的包名/haps/entry/cache/update/注意不同SDK版本的沙箱路徑規(guī)則可能不一樣最簡單的是在代碼里把下載路徑打日志然后用日志里的路徑去查文件。4.4 安裝拉起、覆蓋安裝與結(jié)果確認下載完成后的動作是拉起系統(tǒng)安裝頁面。操作到這一步觀察點有三個是否彈出了系統(tǒng)安裝確認窗口。點擊確認后安裝是否報錯簽名不一致、包已損壞等都會在這里暴露。安裝完成后重新打開應(yīng)用顯示的版本號是不是新版本。重開應(yīng)用后不要急著點“檢查更新”先用前面提到的bm dump確認版本號確實切換到了新版本然后再點一次檢查更新此時服務(wù)器應(yīng)該返回hasUpdate: false界面提示“已是最新版本”。這一條閉環(huán)走完整個更新功能才算真正合格。這里再提醒一句安裝結(jié)果不要依賴startAbility返回的Promise因為用戶可能取消、也可能安裝失敗。一定要靠“安裝后重查版本號”來判定結(jié)果這是最穩(wěn)的檢測方式。4.5 全程日志觀測DevEco Log 和 hdc/hilog 雙管齊下調(diào)試全程建議開兩個日志通道DevEco Studio的Log面板優(yōu)點是可以直接看到console.info日志和崩潰堆棧適合在開發(fā)調(diào)試期看業(yè)務(wù)邏輯。命令行hdc shell hilog優(yōu)點是不受DevEco運行狀態(tài)影響即使應(yīng)用是手動安裝的也能看到系統(tǒng)側(cè)日志。常用命令大概是hdc shell hilog | grep UpdateManager我習(xí)慣在代碼里把每個階段的關(guān)鍵日志都加上UpdateManager前綴這樣排查問題時一行命令就能過濾出完整鏈路。日志一定要舍得打更新功能本身不復(fù)雜怕的是故障時靠猜。5. 未上架調(diào)試特有的大坑簽名、版本號、路徑與日志斷連這一章是干貨中的干貨全是我自己或團隊在未上架狀態(tài)下調(diào)試更新功能時真實踩過的坑。每一個都足以讓半天調(diào)試時間白費希望你提前繞開。5.1 簽名不一致調(diào)試包與發(fā)布包涇渭分明現(xiàn)象很典型下載進度100%系統(tǒng)安裝頁面也彈了點確認之后直接報“安裝失敗”?？慈罩径喟胧呛灻ｒ炇?。根因在于你用DevEco Studio的自動簽名打了一個Debug包安裝到手機但服務(wù)器上放的新版本hap用了上傳簽名或者別的證書簽名。兩個包簽名不一致系統(tǒng)拒絕覆蓋安裝。這類問題在未上架調(diào)試階段特別容易踩因為你根本不會去注意簽名。解決方案有兩個整個調(diào)試期統(tǒng)一簽名。Debug包和測試包都用DevEco的自動簽名保證覆蓋安裝能過。如果就是要驗證“簽名不一致”時的表現(xiàn)那就把這次當成一個獨立的測試用例明確預(yù)期結(jié)果就是安裝失敗而不是讓它混在正常鏈路測試里干擾判斷。另外要記住真機連DevEco調(diào)試時每次Run都相當于重新安裝。如果你在設(shè)備上手動裝了一個測試包再點DevEco的Run它會先卸載再安裝這是正常的不要當成更新功能的問題。5.2 版本號比較字符串排序坑了所有人檢查更新時最常見的低級bug就是用versionName做比較。字符串比較有一個人盡皆知的坑1.0.9 1.0.10因為按字典序比較時9比1大。所以再次強調(diào)邏輯判斷只認整數(shù)versionCodeversionName只做展示。服務(wù)器返回的字段要設(shè)計成同時給versionCode和versionName客戶端判斷用前者展示用后者兩不耽誤。還有一個細節(jié)versionCode在HarmonyOS里是整數(shù)不要用負數(shù)不要用超長數(shù)字。我曾見過一個團隊為了配合灰度策略把版本號寫成1000000321這種很長的大數(shù)雖然沒出事但完全沒有必要版本號只要保證單調(diào)遞增就行。5.3 文件路徑與 URI拉到安裝界面卻找不到文件下載是成功的文件也確實寫進去了但拉起安裝時系統(tǒng)提示“找不到文件”。這種情況多半是傳給startAbility的參數(shù)不對。HarmonyOS的沙箱機制下應(yīng)用能訪問的是自己的filesDir、cacheDir等目錄。如果你把更新包下載到了這些目錄之外或者構(gòu)建Intent時用了不正確的路徑格式系統(tǒng)側(cè)自然找不到。調(diào)試時我的做法是下載完成后立刻打一條日志打印完整路徑和文件大小。用hdc進沙箱目錄實際看一眼文件是否存在。確保傳給系統(tǒng)的路徑和日志里打印的完全一致。另外不同SDK版本對打開文件的協(xié)議支持可能不同有的版本要求傳file://協(xié)議有的直接傳絕對路徑就行。這個以你工程對應(yīng)的SDK文檔為準不要盲抄網(wǎng)上舊代碼。5.4 DevEco 重新 Run 打斷沙箱更新測到一半就清場這個坑尤其隱蔽。你正在真機上測更新下載完了準備點系統(tǒng)安裝頁面。這時候如果你不小心在DevEco Studio里點了Run或者手機上重新裝了應(yīng)用沙箱目錄會被系統(tǒng)清理剛才下載的hap包直接沒了。安裝頁面即使彈出來也找不到目標文件。解決辦法是測更新鏈路時不要中途重新Run工程。如果需要重裝用hdc install -r覆蓋安裝避免清空沙箱。我自己還養(yǎng)成了一個習(xí)慣——下載下來的更新包文件名帶版本號比如app-1.0.2.hap這樣就算文件真的被清了日志里也能明確看到是誰清掉了鏈路。5.5 “已是最新”測不出來等于號語義要提前定更新檢測邏輯里有一個產(chǎn)品層面容易忽略的點當客戶端版本號等于服務(wù)器版本號時到底顯示什么大多數(shù)實現(xiàn)是if (serverVersionCode currentVersionCode) 有更新 else 無更新所以等于時顯示“已是最新”。但在調(diào)試階段你為了驗證“已是最新”的展示必須把服務(wù)器版本號改成和你當前安裝版本一致。很多團隊只準備了“有更新”的包一測到“已是最新”就被卡住以為功能壞了。其實不是是測試數(shù)據(jù)沒設(shè)計好。我建議準備三組測試數(shù)據(jù)服務(wù)器版本號大于當前有更新、等于當前已是最新、小于當前異常場景驗證客戶端能兜住。三組都過才說明版本比較邏輯是真的穩(wěn)了。6. 調(diào)試環(huán)境回歸上線更新策略的取舍與收尾建議本地鏈路完全跑通只是第一步。真要上架你還需要面對“官方應(yīng)用市場通道”和“自建通道”的取舍。這里我給一點實際建議。6.1 上架前用官方更新通道回歸一遍如果正式產(chǎn)品打算走AppGallery的應(yīng)用內(nèi)更新SDK上架前必須用官方SDK完整回歸一遍更新流程。注意這時候你已經(jīng)上架或者在AGC后臺配置了灰度版本SDK才能拉到列表?；貧w時重點驗證三件事SDK的更新策略強制更新、非強制更新是否符合產(chǎn)品定義。權(quán)限彈窗和隱私說明是否合規(guī)應(yīng)用市場審核對這部分很敏感。從舊版本升到新版本后應(yīng)用數(shù)據(jù)是否保留。更新不同于卸載重裝用戶數(shù)據(jù)應(yīng)該原樣保留這一點在自建通道里可能靠覆蓋安裝天然成立但在官方SDK里也需要確認一次。不要以為本地自建鏈路測通了官方SDK就一定通API不同、鑒權(quán)方式不同、版本分發(fā)策略也不同花半天時間回歸是值得的。6.2 自更新通道要不要保留我的取舍建議很多團隊因為要做灰度、要繞開市場審核周期傾向于保留自建更新通道。我的看法是調(diào)試期用自建通道沒問題但正式環(huán)境優(yōu)先走官方應(yīng)用內(nèi)更新除非你能保證自建通道的簽名校驗、HTTPS傳輸、包源安全都做到位。自建通道最大的風(fēng)險不是技術(shù)上跑不通而是用戶從“應(yīng)用市場版”升級時道德信任和安全感知很微妙。萬一自建通道被中間人攻擊或者包源被污染影響的是整個應(yīng)用的口碑。應(yīng)用市場審核看到應(yīng)用有自更新邏輯也會重點檢查這是另一個不可控因素。如果你最終還是決定保留自更新至少做到三點下載URL一律HTTPS、安裝前校驗文件MD5或簽名、每次更新前彈明確說明。這三點能幫你規(guī)避九成風(fēng)險。6.3 最后小技巧把更新地址做成構(gòu)建期可配置調(diào)試期你用的服務(wù)器地址是http://192.168.1.100:8080上線時要改成正式域名。最怕的是開發(fā)人員上線時忘了改地址導(dǎo)致正式用戶全部連到內(nèi)網(wǎng)IP。我建議把更新接口地址做成按構(gòu)建類型配置Debug構(gòu)建讀本地環(huán)境里的配置指向本地或測試服務(wù)器。Release構(gòu)建只允許讀正式域名調(diào)試地址硬編碼不進Release邏輯。實現(xiàn)方式很簡單在工程里用一個常量文件區(qū)分buildMode或者在CI/CD環(huán)境變量里注入地址。這個改動成本不大但能徹底杜絕“上線忘改地址”這種低級事故。整個流程測下來你會發(fā)現(xiàn)HarmonyOS應(yīng)用更新功能的調(diào)試難點不在“上架”而在你對簽名、沙箱路徑、網(wǎng)絡(luò)策略這些基礎(chǔ)工作的熟悉程度。把這些基礎(chǔ)打牢未上架階段測出來的結(jié)果基本就能代表線上行為。以后不管產(chǎn)品怎么變只要版本號管理和簽名策略不亂更新功能這道關(guān)就守得住。