寫自動化腳本這件事最磨人的往往不是流程有多復(fù)雜而是同一批基礎(chǔ)方法在每次新腳本里都要重新寫一遍。AutoJs里click、text、findOne這些API雖然開箱即用可真跑起來你就會發(fā)現(xiàn)直接嗑原生API的腳本大多活不過三天控件還沒加載完就去點擊了、屏幕黑著就執(zhí)行了、日志刷了幾百行也看不出來卡在哪一步。我整理了幾個自己從實際腳本里拆出來的AutoJs工具方法都是從坑里爬出來之后留下的版本拿過去改改參數(shù)就能用。適合正在寫AutoJs腳本、想少走彎路的朋友也適合那些剛接觸自動化、還沒建立起自己工具庫的新手。1. 這些工具方法解決的是哪幾類老問題1.1 時序與控件結(jié)構(gòu)問題AutoJs腳本跑崩排在第一位的原因永遠(yuǎn)是時序。手機App的頁面渲染不像PC端那么可控同一個頁面網(wǎng)絡(luò)好與不好時控件的出現(xiàn)時間能差出一兩秒。直接text(確認(rèn)).findOne()只能等一次控件沒渲染出來就返回空后續(xù)代碼再對這個空對象調(diào)click()當(dāng)場拋異常。更隱蔽的是控件層級問題。很多App會把一段文案放在text屬性里把另一段描述放在content-desc里同一個按鈕在不同頁面狀態(tài)下的屬性還不一樣。如果你只認(rèn)一種屬性換一個頁面就全軍覆沒。這種問題不把查找邏輯封裝成帶兜底的策略根本沒法優(yōu)雅處理。1.2 機型差異與可維護性問題坐標(biāo)寫死的腳本換一臺分辨率不同的手機就是廢的。就算在同一臺手機上App更新一次UI坐標(biāo)全部偏移也是常有的事。所以只要涉及點擊和滑動就必須基于控件位置去計算而不是取固定坐標(biāo)。還有一個經(jīng)常被忽略的問題腳本維護。今天寫一個簽到腳本明天寫一個巡檢腳本每個人開頭都放一遍sleep(1000)、click(x, y)、console.log最后改起來到處是雷。工具方法本身就是一個沉淀的過程把共性的東西抽出來腳本主邏輯才能保持干凈。1.3 使用前的基本環(huán)境要求下面這些方法基于AutoJs常見發(fā)行版的API編寫4.x及以上基本通用。使用前需要確保三件事無障礙服務(wù)已開啟這是AutoJs執(zhí)行控件操作的前提懸浮窗權(quán)限已授予方便在跑批時隨時看日志存儲權(quán)限和截圖權(quán)限已開放涉及截圖存檔時要用。環(huán)境不對工具方法寫得再漂亮也跑不起來所以這個檢查放最前面說。2. 控件查找與等待讓腳本不再“踩空”2.1 為什么不用現(xiàn)成的findOne超時機制AutoJs的findOne(timeout)確實能設(shè)置超時但超時后的行為是直接拋異常中斷整個腳本。你只能在調(diào)用處包一層try/catch一個兩個還好腳本里幾十處查找都這么包代碼全是噪音。我更習(xí)慣用findOnce(0)配合輪詢自己實現(xiàn)等待邏輯。findOnce(0)不拋異常找不到就返回null把控制權(quán)完全留給自己找不到就繼續(xù)等、等夠了就返回空對象讓上層決定怎么處理而不是讓腳本直接暴斃。2.2 waitForNode與多屬性兜底查找核心就是這個waitForNode方法。傳入一個選擇器和一個超時時間內(nèi)部每200毫秒查一次直到查到節(jié)點或超時返回null。200毫秒這個間隔是實測出來的太短會頻繁占用主線程太長又會讓腳本反應(yīng)遲鈍。function waitForNode(selector, timeout) { const start Date.now(); while (Date.now() - start timeout) { const node selector.findOnce(0); if (node) { return node; } sleep(200); } return null; }在此基礎(chǔ)上我做了一層屬性兜底。很多App的按鈕文案不是放在text里而是放在content-desc里單查一種很容易漏。所以就有了一組更實用的方法function findByText(textStr, timeout) { return waitForNode(text(textStr), timeout || 3000); } function findByDesc(descStr, timeout) { return waitForNode(desc(descStr), timeout || 3000); } function findByTextOrDesc(textStr, timeout) { const node findByText(textStr, timeout); if (node) { return node; } return findByDesc(textStr, timeout); }這樣做的代價是多等一個超時周期但換來的是更高的命中率。實際使用中我的建議是優(yōu)先用findByText失敗了再走findByTextOrDesc。因為同一個頁面里text屬性的匹配通常比desc更精確。2.3 尋找可點擊父節(jié)點的方法還有一個高頻問題你要找的控件確實存在但它本身不可點擊。比如一個TextView外面包了一層LinearLayout點擊事件在父容器上。直接對這個子節(jié)點調(diào)用click()點下去沒有任何反應(yīng)。解決思路是向上逐層尋找最近的“可點擊”祖先節(jié)點。用parent()一層層往上走直到某個節(jié)點的clickable()返回true。function clickableParent(node) { let current node; while (current current.parent()) { if (current.clickable()) { return current; } current current.parent(); } return null; } function tapByText(textStr) { const node findByText(textStr, 3000); if (!node) { return false; } const target node.clickable() ? node : clickableParent(node); if (!target) { return false; } const b target.bounds(); return click((b.left b.right) / 2, (b.top b.bottom) / 2); }這套邏輯是我遇到過最多坑的地方尤其那種“明明找到了節(jié)點點了卻沒反應(yīng)”的詭異問題十有八九就是點擊事件掛在父級身上。3. 像真人一樣的點擊與滑動封裝3.1 點擊太規(guī)律有什么問題直接click(500, 1000)然后sleep(1000)再click(500, 1000)再sleep(1000)這種腳本跑起來就算不被平臺識別成異常行為至少也容易因為點擊位置落在控件邊緣而誤觸。等間距的延時對系統(tǒng)來說太規(guī)律了對用戶來說也太假了。我并不是要教大家怎么規(guī)避監(jiān)管而是從腳本穩(wěn)定性角度出發(fā)操作節(jié)奏帶一點隨機性能讓腳本更接近真實操作習(xí)慣也減少因為每次都點同一個坐標(biāo)導(dǎo)致的可預(yù)測性故障。3.2 隨機延時與隨機點工具隨機延時的實現(xiàn)很簡單但建議封裝成一個方法統(tǒng)一管理區(qū)間。我自己習(xí)慣設(shè)定一個基準(zhǔn)區(qū)間比如300到800毫秒這個區(qū)間用下來點擊最穩(wěn)。function randomDelay(min, max) { const ms Math.floor(Math.random() * (max - min 1)) min; sleep(ms); return ms; } function centerOf(node) { const b node.bounds(); return { x: Math.round((b.left b.right) / 2), y: Math.round((b.top b.bottom) / 2) }; } function randomPointIn(node, ratio) { const b node.bounds(); const offsetX Math.round((b.right - b.left) * (ratio || 0.1)); const offsetY Math.round((b.bottom - b.top) * (ratio || 0.1)); return { x: b.left offsetX Math.round(Math.random() * ((b.right - b.left) - 2 * offsetX)), y: b.top offsetY Math.round(Math.random() * ((b.bottom - b.top) - 2 * offsetY)) }; }randomPointIn里有個細(xì)節(jié)偏移量是按控件寬高比例算的不是固定像素。大按鈕可以偏移多點小按鈕必須偏移少點。如果固定偏移12像素碰到一個只有20像素高的按鈕很容易點到按鈕外面去。這個比例我一般取0.1到0.15既能制造隨機感又保證落點仍在控件內(nèi)部。把隨機延時和隨機落點組合起來就是一套完整的點擊工具function tapNode(node, options) { const minDelay (options options.minDelay) || 300; const maxDelay (options options.maxDelay) || 800; const delayMs randomDelay(minDelay, maxDelay); const pt randomPointIn(node, 0.15); const result click(pt.x, pt.y); if (options options.afterDelay) { sleep(options.afterDelay); } return { success: result, delayMs: delayMs, x: pt.x, y: pt.y }; }返回success和實際點擊坐標(biāo)很重要。腳本跑完后回看日志你能知道剛才到底點沒點上以及點在哪個位置排查問題快得多。3.3 基于控件的滑動輔助滑動也是同樣的道理。列表頁的下拉刷新、選項卡的左右切換如果直接寫死swipe(500, 1200, 500, 400, 300)換一臺屏幕比例不同的手機滑動軌跡就完全不對了。我的做法是先拿到目標(biāo)控件的bounds然后按控件區(qū)域計算起止點。比如在一個列表區(qū)域下拉刷新起點取列表中上方終點取列表下方滑動距離和控件實際高度保持匹配。function swipeFromNode(node, direction, distanceRatio) { const b node.bounds(); const cx (b.left b.right) / 2; const startY b.top (b.bottom - b.top) * 0.3; const endY b.top (b.bottom - b.top) * (0.3 (distanceRatio || 0.5)); const duration 300 Math.floor(Math.random() * 300); if (direction down) { return swipe(cx, startY, cx, endY, duration); } if (direction up) { return swipe(cx, endY, cx, startY, duration); } return false; }duration我同樣做了隨機化但幅度比點擊小300到600毫秒之間。因為滑動太快容易觸發(fā)App的慣性滾動太慢又會顯得很刻意這個區(qū)間是觀感最自然的。4. 屏幕、鎖屏與前臺應(yīng)用的兜底處理4.1 黑屏和鎖屏是所有自動化的頭號敵人我見過太多人寫好的腳本白天跑得好好的一到晚上或者手機放口袋里超過十分鐘再執(zhí)行就全程癱瘓。原因很簡單屏幕關(guān)了甚至鎖屏了控件樹還在但所有操作都會被系統(tǒng)攔下來。所以每次跑任務(wù)前先保證屏幕是亮的。device模塊提供了屏幕狀態(tài)檢測和喚醒接口但不同發(fā)行版API有差異所以我在外層做了一層兼容。部分版本用device.wakeUp()能直接點亮有些則必須發(fā)送電源鍵。function ensureScreenOn() { if (device.isScreenOn()) { return true; } if (typeof device.wakeUpIfNeeded function) { device.wakeUpIfNeeded(); sleep(800); } else { press(power); sleep(800); } if (!device.isScreenOn()) { press(power); sleep(1200); } return device.isScreenOn(); }關(guān)于解鎖我的經(jīng)驗是如果跑的是無人值守的定時腳本強烈建議關(guān)閉鎖屏密碼改成滑動解鎖或者不鎖屏。密碼解鎖的方法不是不能寫但每個ROM對鎖屏頁的控件結(jié)構(gòu)都不一樣為了這個做大量適配純屬投入產(chǎn)出不成比例。真遇到鎖屏更穩(wěn)妥的辦法是讓設(shè)備本身保持不鎖屏狀態(tài)或者把腳本的執(zhí)行時段放在不鎖屏的場景里。4.2 確保目標(biāo)應(yīng)用處于前臺的通用做法另一個常見問題是執(zhí)行任務(wù)時前臺不是目標(biāo)App。可能用戶中途切出去聊天了也可能上一次任務(wù)結(jié)束的時候把App退到了后臺。這時候直接按控件操作操作的是錯誤的界面輕則任務(wù)失敗重則誤觸其他應(yīng)用。我寫了一個組合方法先檢測當(dāng)前前臺應(yīng)用如果不是目標(biāo)包名就拉起它再等界面穩(wěn)定。function ensureFrontApp(packageName, waitText) { if (!currentPackage()) { return false; } if (currentPackage() ! packageName) { launch(packageName); sleep(1500); } if (waitText) { return findByText(waitText, 5000) ! null; } return true; }waitText這個參數(shù)很關(guān)鍵有時候launch()成功了但頁面還在廣告頁或者加載頁直接往下走還是會翻車。傳一個目標(biāo)頁面獨有的文案進去就相當(dāng)于給應(yīng)用啟動加了一層“頁面級等待”。4.3 攔截彈窗和權(quán)限提示App啟動后最常見的意外是各種彈窗更新提示、活動彈窗、權(quán)限申請、青少年模式。這些彈窗的關(guān)閉按鈕文案五花八門但大多是“取消”“以后再說”“我知道了”“暫不”這幾種。我把關(guān)閉彈窗做成了一個批量嘗試方法function closePopups(keywords) { const list keywords || [取消, 以后再說, 我知道了, 暫不, 確認(rèn)]; for (let i 0; i list.length; i) { const node findByText(list[i], 800); if (node) { const target node.clickable() ? node : clickableParent(node); if (target) { const pt randomPointIn(target, 0.2); click(pt.x, pt.y); sleep(600); } } } }注意這里的超時時間我只給了800毫秒比正常查找短很多。因為彈窗檢測只是一個“掃一遍”的動作如果每個關(guān)鍵詞都等3秒腳本每次啟動都要白等十幾秒浪費嚴(yán)重。5. 截屏、區(qū)域裁剪與文本識別的封裝5.1 什么時候必須走圖片識別路線控件查找不是萬能的。有些App的界面是用自繪組件或者WebView渲染的控件樹里只能看到一個大容器看不到具體文案。這個時候就必須走“截圖 圖片處理 文本識別”這條路。但OCR是個開銷不小的操作全屏識別一次時間可能超過一秒頻繁調(diào)用會拖垮整個腳本。所以我的原則是能通過控件屬性解決的絕不OCR必須OCR的也要先裁剪區(qū)域只識別關(guān)鍵區(qū)域。5.2 截圖存檔與區(qū)域裁剪截圖存檔本身就能派上用場。跑批任務(wù)結(jié)束后留檔、任務(wù)出問題后回看現(xiàn)場都離不開截圖。命名上我會帶時間戳方便排序查找。function getTimeStr() { const d new Date(); return d.getFullYear() - (d.getMonth() 1) - d.getDate() _ d.getHours() - d.getMinutes() - d.getSeconds(); } function captureAndSave(fileName) { const img captureScreen(); if (!img) { return null; } const dir /sdcard/腳本截圖/; files.createWithDirs(dir); const path files.join(dir, fileName _ getTimeStr() .png); images.save(img, path); img.recycle(); return path; }區(qū)域裁剪的核心價值在于減少OCR的識別范圍。比如一張頁面上只有一個通知欄區(qū)域需要識別那就先把這部分裁出來識別速度能快好幾倍。function clipRegion(img, region) { // region 格式: [x, y, width, height] const clip images.clip(img, region[0], region[1], region[2], region[3]); return clip; }5.3 文本識別的耐心型輪詢封裝對于純圖片界面判斷“某段文字是否出現(xiàn)”比判斷控件更麻煩。我封裝了一個輪詢方法每秒鐘截一次圖對指定區(qū)域做文本識別直到識別出目標(biāo)關(guān)鍵詞或超時。function waitForTextByOcr(keyword, timeout, region) { const start Date.now(); while (Date.now() - start timeout) { const img captureScreen(); if (img) { let clip img; if (region) { clip clipRegion(img, region); } const result ocr.recognize(clip); const content result result.text ? result.text : ; clip.recycle(); img.recycle(); if (content.indexOf(keyword) 0) { return true; } } sleep(1000); } return false; }這里要特別提醒OCR接口在不同AutoJs發(fā)行版上的調(diào)用方式差異很大上面代碼里的ocr.recognize需要替換成你所使用版本的實際API。另外OCR必然存在誤識別率尤其是中文。關(guān)鍵詞盡量選字形獨特、不會輕易被識別錯的短詞別拿一句長文案當(dāng)匹配條件。6. 日志、重試與失敗隔離讓腳本自己會說話6.1 帶時間戳的日志才叫日志沒有時間戳的日志等于沒有日志。腳本跑一個小時中間某個步驟失敗了光看到幾十行消息根本定位不到是哪個時間點、哪個環(huán)節(jié)出的問題。帶時間戳的輸出配合重試和完成標(biāo)記就能把整個執(zhí)行過程串成一條清晰的時間線。function logWithTime(msg) { const now new Date(); const h now.getHours(); const min now.getMinutes(); const s now.getSeconds(); const ts (h 10 ? 0 h : h) : (min 10 ? 0 min : min) : (s 10 ? 0 s : s); console.log([ ts ] msg); return ts msg; }6.2 有限重試與失敗隔離無人值守自動化腳本最怕無限循環(huán)。一個操作失敗后重試是必要的但絕對不能無限重試否則一旦遇到頑固問題腳本會卡在同一個步驟幾個小時整個任務(wù)時間線全部拖垮。我封裝了一個帶重試次數(shù)的工具失敗后等待時間遞增給系統(tǒng)更多恢復(fù)時間。這比固定間隔重試效果好得多。function retry(fn, options) { const maxRetries (options options.retries) || 3; const gap (options options.gap) || 1000; let lastErr null; for (let i 0; i maxRetries; i) { try { return fn(); } catch (e) { lastErr e; logWithTime(第 (i 1) 次嘗試失敗: e.message); sleep(gap * (i 1)); } } logWithTime(重試 maxRetries 次仍失敗放棄該步驟); throw lastErr; }重試間隔的遞增邏輯是第一次失敗等1秒第二次等2秒第三次等3秒。這是一個簡單的線性退避不搞指數(shù)退避是因為在手機自動化場景里每次失敗往往只是臨時性的界面抖動線性遞增足夠了。失敗隔離的意思更進一步單個步驟失敗不能拖垮整個任務(wù)。我把每個任務(wù)包在一個守衛(wèi)方法里任務(wù)內(nèi)異常不會中斷腳本主體。function runWithGuard(taskName, fn) { try { logWithTime(開始執(zhí)行: taskName); fn(); logWithTime(完成: taskName); } catch (e) { logWithTime(任務(wù)異常[ taskName ]: (e e.message)); } }跑批腳本里有多個步驟時這個守衛(wèi)方法特別有用。步驟A失敗了步驟B照樣能繼續(xù)跑最后日志匯總時一目了然。6.3 任務(wù)編排的小框架最后把這些組合成一個極簡的任務(wù)編排結(jié)構(gòu)。我習(xí)慣在腳本里維護一個任務(wù)列表按順序執(zhí)行每項任務(wù)之間有隨機間隔避免整個流程像發(fā)條一樣零誤差地推進。function runBatch(taskList) { for (let i 0; i taskList.length; i) { const task taskList[i]; runWithGuard(task.name, task.fn); if (i taskList.length - 1) { randomDelay(800, 1500); } } }7. 裝進一個盒子倉庫文件與完整示例7.1 tools.js的文件骨架上面所有工具方法我在實際項目中都是集中放在一個tools.js文件里腳本主邏輯只負(fù)責(zé)業(yè)務(wù)編排不摻雜物操作細(xì)節(jié)。文件骨架大概是這個結(jié)構(gòu)// 配置區(qū) const CONFIG { clickMinDelay: 300, clickMaxDelay: 800, nodeTimeout: 3000, screenShotDir: /sdcard/腳本截圖/ }; // 節(jié)點相關(guān) function waitForNode(selector, timeout) { /* ... */ } function findByText(textStr, timeout) { /* ... */ } function findByDesc(descStr, timeout) { /* ... */ } function findByTextOrDesc(textStr, timeout) { /* ... */ } function clickableParent(node) { /* ... */ } // 點擊滑動相關(guān) function randomDelay(min, max) { /* ... */ } function centerOf(node) { /* ... */ } function randomPointIn(node, ratio) { /* ... */ } function tapNode(node, options) { /* ... */ } function swipeFromNode(node, direction, distanceRatio) { /* ... */ } // 設(shè)備狀態(tài)相關(guān) function ensureScreenOn() { /* ... */ } function ensureFrontApp(packageName, waitText) { /* ... */ } function closePopups(keywords) { /* ... */ } // 截圖與識別相關(guān) function getTimeStr() { /* ... */ } function captureAndSave(fileName) { /* ... */ } function clipRegion(img, region) { /* ... */ } function waitForTextByOcr(keyword, timeout, region) { /* ... */ } // 日志與重試相關(guān) function logWithTime(msg) { /* ... */ } function retry(fn, options) { /* ... */ } function runWithGuard(taskName, fn) { /* ... */ } function runBatch(taskList) { /* ... */ } module.exports { waitForNode, findByText, findByDesc, findByTextOrDesc, clickableParent, randomDelay, randomPointIn, tapNode, swipeFromNode, ensureScreenOn, ensureFrontApp, closePopups, captureAndSave, waitForTextByOcr, logWithTime, retry, runWithGuard, runBatch };使用的時候在腳本開頭require(./tools.js)然后就可以把注意力全部放在業(yè)務(wù)邏輯上。7.2 一個具體的自動巡檢示例舉個例子。假設(shè)每天早上要打開一個內(nèi)部信息平臺App進入“今日公告”頁面確認(rèn)“無新增內(nèi)容”或者把最新公告文案記錄下來。這個場景很適合用來展示整套工具方法的組合使用。const tools require(./tools.js); function morningInspection() { tools.ensureScreenOn(); const appOk tools.ensureFrontApp(com.example.internal, 今日公告); if (!appOk) { tools.logWithTime(未能進入今日公告頁); return; } tools.closePopups([我知道了, 取消, 以后再說]); const titleNode tools.findByText(最新公告, 3000); if (!titleNode) { tools.logWithTime(頁面中未找到公告標(biāo)題區(qū)域); tools.captureAndSave(inspect_fail); return; } const contentNode tools.findByTextOrDesc(今日無新增, 2000); if (contentNode) { tools.logWithTime(今日無新增內(nèi)容); } else { tools.logWithTime(檢測到新增內(nèi)容已截圖留檔); tools.captureAndSave(inspect_new); } } tools.runWithGuard(早間巡檢, function () { tools.retry(morningInspection, { retries: 3, gap: 2000 }); });這段代碼里retry包在最外層意味著如果第一次巡檢因為網(wǎng)絡(luò)波動失敗最多會自動補跑兩次每次間隔遞增。單次巡檢的異常被外層守衛(wèi)接住不會導(dǎo)致整個腳本直接退出。截圖留檔的命名帶時間戳事后排查也能對得上。7.3 拿走后必改的幾個地方直接從本文復(fù)制代碼回去用之前有四處一定要改否則換一臺手機就跑不通目標(biāo)App的包名。currentPackage()和launch()依賴完整包名不同應(yīng)用包名不同需要自己確認(rèn)。等待文案。示例里的“今日公告”“最新公告”是占位文案要替換成目標(biāo)App里真實存在且唯一的界面文字。截圖目錄和文件名。/sdcard/腳本截圖/只是我個人的目錄習(xí)慣可以改成任何有讀寫權(quán)限的路徑。隨機延時的區(qū)間。如果你的目標(biāo)場景網(wǎng)絡(luò)較差控件加載慢建議把clickMaxDelay從800放大到1200給界面渲染留更多余量。拿回去之后別直接扔到生產(chǎn)腳本里跑先在目標(biāo)設(shè)備上單獨跑一遍findByText、tapNode這幾個方法確認(rèn)節(jié)點能找得到、點擊有反應(yīng)再把整套方法接入正式流程。這樣即使有問題排查范圍也能縮到最小。我在實際使用中最大的體會是工具方法從來不是一次性寫完就完事的它們會跟著腳本一起慢慢長。每遇到一個新的坑就往tools.js里補一個新方法補多了之后你會發(fā)現(xiàn)新腳本的開發(fā)速度越來越快因為大部分通用能力早就沉淀在里面了。最后再分享一個小技巧隨機延時的基準(zhǔn)區(qū)間不是固定的它應(yīng)該和你的網(wǎng)絡(luò)環(huán)境掛鉤。家里WiFi穩(wěn)定的時候可以把區(qū)間壓縮到200到500毫秒出門用流量時放大到500到1200毫秒這樣腳本的節(jié)奏永遠(yuǎn)跟得上真實環(huán)境的響應(yīng)速度。