開完會往地鐵站走的時候我突然想到一個問題如果這會兒手邊只有一臺手機(jī)但同事剛把 Git 分支推上去說“幫忙跑一下構(gòu)建看看能不能過”我該怎么回他以前我的答案是“等我回工位”后來我發(fā)現(xiàn)這個答案其實(shí)可以變成“等我一分鐘”。這不是什么黑科技而是把手機(jī)變成一個輕量級 Java 構(gòu)建環(huán)境的事核心就是一套順手的腳本。這篇文章想講清楚一件事用手機(jī)配合腳本完成 Java 項目的構(gòu)建不是折騰而是一條可以落地的工程方案。它解決的不是“手機(jī)能不能替代電腦”而是“在沒有電腦的碎片時間里如何用最短路徑驗證代碼、出構(gòu)建結(jié)果、給同事反饋”。文章會從環(huán)境搭建、腳本設(shè)計、完整示例、常見報錯到工程建議展開全程給出可直接復(fù)制的命令和腳本讀完后你也能在手機(jī)上搭出一套屬于自己的 Java 構(gòu)建流水線。1. 先想清楚手機(jī)構(gòu)建 Java 項目真正解決什么問題很多人聽到“手機(jī)構(gòu)建 Java 項目”的第一反應(yīng)是能跑嗎跑得動嗎這有意義嗎這三個問題其實(shí)問的是同一個東西——手機(jī)構(gòu)建的價值邊界在哪里。先給結(jié)論手機(jī)構(gòu)建適合“輕量驗證型開發(fā)”不適合“重型任務(wù)”。什么是輕量驗證型開發(fā)比如你人在外面同事說某個模塊在 JDK 17 下編譯報錯你需要快速拉代碼、跑一次 Maven 編譯看報錯。再比如你寫了一個公共工具類想在本機(jī)跑一遍單元測試確認(rèn)沒破壞已有邏輯。又比如你維護(hù)一個個人開源項目需要頻繁出包給用戶測試。這些場景的特點(diǎn)是單模塊或少量模塊、依賴可控、構(gòu)建時間在幾分鐘量級、不需要大規(guī)模并行測試。手機(jī)完全能勝任。什么是不適合的幾千個依賴的大型企業(yè)級多模塊項目、需要跑完整集成測試的發(fā)布流程、對內(nèi)存和 CPU 消耗極其夸張的代碼生成任務(wù)。這些場景下手機(jī)的性能瓶頸會被無限放大還不如把構(gòu)建任務(wù)丟給遠(yuǎn)程服務(wù)器。再說回“腳本”這個詞。很多人在手機(jī)上構(gòu)建項目是打開一個 IDE 軟件點(diǎn)按鈕、看日志。這不是不可以但效率很低而且不同軟件之間的行為不一致。腳本的價值在于把構(gòu)建行為標(biāo)準(zhǔn)化。環(huán)境自檢、依賴?yán)?、編譯、打包、日志輸出、產(chǎn)物歸檔全部固化成命令任何一次執(zhí)行都和上一次一致。這才是手機(jī)構(gòu)建真正的效率來源。所以這篇文章討論的不是“手機(jī)能不能裝 Java”而是“如何用腳本把手機(jī)上的 Java 構(gòu)建流程變成一條穩(wěn)定的流水線”。讀者畫像也很清晰經(jīng)常出差但不想背厚重電腦的開發(fā)者、在校學(xué)生、用舊手機(jī)做開發(fā)實(shí)驗的折騰型玩家、以及需要快速驗證代碼片段的技術(shù)博主。2. 環(huán)境認(rèn)知手機(jī)構(gòu)建的原理與方案對比要把構(gòu)建這件事搬上手機(jī)首先要理解手機(jī)和我們熟悉的電腦在環(huán)境上的本質(zhì)差異。手機(jī)上沒有傳統(tǒng)意義上的 Windows/Linux/macOS 文件系統(tǒng)沒有默認(rèn)的包管理機(jī)制沒有完整的編譯工具鏈。現(xiàn)在的手機(jī)操作系統(tǒng)普遍基于 Linux 內(nèi)核但用戶能接觸到的層級通常被鎖在一個沙箱里。要打破這個沙箱主流方案有三類終端模擬器方案、本地 IDE 方案、云開發(fā)環(huán)境方案。終端模擬器方案是目前最接近“電腦開發(fā)體驗”的路線。以 Termux 為代表它在不越獄、不 root 的前提下為 Android 手機(jī)提供了一套獨(dú)立的 Linux 用戶環(huán)境自帶包管理器可以直接安裝 OpenJDK、Git、Maven 等工具。這個方案的最大優(yōu)勢是可以使用熟悉的 Shell 腳本和命令行工具鏈和服務(wù)器上的操作習(xí)慣完全一致。缺點(diǎn)是初次配置需要一點(diǎn)耐心而且對手機(jī)系統(tǒng)版本有要求。本地 IDE 方案以 AIDE 為代表手機(jī)安裝后可以直接打開 Java 工程用圖形界面寫代碼、點(diǎn)按鈕構(gòu)建。優(yōu)點(diǎn)是上手快界面長得很像桌面 IDE缺點(diǎn)是自動化能力弱想集成自定義腳本比較麻煩而且項目類型支持有限。云開發(fā)環(huán)境方案是把構(gòu)建過程放到云端容器里手機(jī)上只保留一個遠(yuǎn)程終端或 Web IDE。GitHub Codespaces、云 IDE 類工具都屬于這個范疇。這個方案最接近“重型項目也能跑”的理想狀態(tài)但前提是網(wǎng)絡(luò)穩(wěn)定而且很多服務(wù)需要額外付費(fèi)或授權(quán)不適合完全離線使用。三個方案怎么選我的判斷是如果你是為了驗證腳本、跑通流程、或者想在手機(jī)上獲得最接近真機(jī)的開發(fā)體驗選 Termux。因為它把“構(gòu)建”還原成了“命令 腳本”這是后面所有自動化操作的基礎(chǔ)。AIDE 適合完全不碰腳本的人云環(huán)境適合有穩(wěn)定網(wǎng)絡(luò)和付費(fèi)意愿的人。下表直接對比三種方案的核心差異對比維度Termux 終端環(huán)境AIDE 類似 IDE云開發(fā)環(huán)境環(huán)境完整度高可安裝 JDK/Maven/Git中一般只支持自帶構(gòu)建配置高容器環(huán)境可按需定制腳本自動化天然支持 Shell 腳本弱不適合深度自動化支持但依賴云端執(zhí)行使用門檻中需要命令行基礎(chǔ)低界面交互友好低到中需要網(wǎng)絡(luò)和賬號離線可用支持裝好后基本可脫網(wǎng)支持不支持設(shè)備要求Android 7 以上較穩(wěn)妥低配可運(yùn)行無特殊要求但瀏覽器性能有影響適合場景自定義構(gòu)建、腳本開發(fā)簡單修改、快速驗證大型項目、團(tuán)隊協(xié)作從實(shí)現(xiàn)“手機(jī)構(gòu)建 Java 項目腳本”這個目標(biāo)來看Termux 是繞不開的核心環(huán)境后面所有演示都基于它展開。如果你用的是 iPhoneTermux 這條路走不通可以考慮通過遠(yuǎn)程云環(huán)境間接實(shí)現(xiàn)但嚴(yán)格意義上那不是“手機(jī)本地構(gòu)建”不在本文演示范圍內(nèi)。3. 環(huán)境準(zhǔn)備在 Termux 里搭出 Java 構(gòu)建鏈3.1 安裝 Termux 與基礎(chǔ)倉庫更新Termux 是一個運(yùn)行在 Android 上的開源終端模擬器里面包含了一個精簡的 Linux 用戶環(huán)境。安裝本身不復(fù)雜但要注意目前官方渠道的安裝包可能在 Google Play 或 GitHub Releases 上版本變動比較頻繁建議以實(shí)際可用版本為準(zhǔn)。安裝完成后打開 Termux第一步是更新包管理器索引和基礎(chǔ)組件。這一步非常重要因為 Termux 的包管理基于 pkg 命令如果索引不是最新的后面安裝 JDK 時很可能遇到找不到包或者版本不對的問題。執(zhí)行下面兩條命令pkg update pkg upgrade -y這個過程會拉取大量軟件包元數(shù)據(jù)耗時取決于網(wǎng)絡(luò)環(huán)境。執(zhí)行完畢后終端會回到命令提示符狀態(tài)沒有報錯就是正常。如果中途出現(xiàn)彈窗詢問“是否繼續(xù)”直接輸入 y 并回車即可。3.2 安裝 JDK、Maven 與 GitJava 構(gòu)建的三件套依次是 JDK、構(gòu)建工具M(jìn)aven 或 Gradle、Git。Termux 的官方倉庫里直接維護(hù)了 OpenJDK 包不需要像在傳統(tǒng) Linux 上那樣手動下載壓縮包。安裝命令如下pkg install -y openjdk-17這里以 openjdk-17 為例因為 Java 17 是目前很多后端項目和服務(wù)端框架的基礎(chǔ)版本。如果你的項目要求其他版本可以改成 openjdk-11 或 openjdk-21具體以 Termux 倉庫實(shí)際提供的版本為準(zhǔn)不要生搬硬套“必須 17”的說法。然后安裝構(gòu)建工具和版本管理工具pkg install -y maven git裝完后可以在終端里檢查主命令是否生效java -version mvn -version git --version三條命令都出現(xiàn)版本信息就說明基礎(chǔ)環(huán)境已經(jīng)打通。這里要補(bǔ)充一個容易踩的坑有些 Termux 版本安裝 JDK 后java 命令能識別但 javac 命令找不到。如果你后續(xù)要用腳本執(zhí)行 javac 手動編譯記得單獨(dú)驗證一下 javac 是否在 PATH 中。3.3 確認(rèn) PATH 與處理“命令找不到”“命令找不到”是手機(jī)上配置 Java 環(huán)境最常見的報錯。比如說你已經(jīng)安裝了 Maven但執(zhí)行 mvn 時提示 command not found這就是典型的 PATH 問題。在 Termux 中用戶安裝的軟件一般會被軟鏈接到$PREFIX/bin目錄$PREFIX的默認(rèn)值是/data/data/com.termux/files/usr。你可以用以下命令查看當(dāng)前 PATHecho $PATH正常情況下輸出中應(yīng)該包含類似/data/data/com.termux/files/usr/bin的路徑。如果沒有可以在~/.bashrc或~/.zshrc中補(bǔ)上。修改后執(zhí)行source ~/.bashrc生效。還有一種情況是你之前手動解壓過某個 JDK 到自定義目錄并且自定義配置覆蓋了系統(tǒng)默認(rèn)配置。此時需要檢查當(dāng)前 JAVA_HOME 指向哪里echo $JAVA_HOME which java如果輸出指向了奇怪的路徑直接把~/.bashrc中對應(yīng)的 export 行刪掉或注釋掉重新打開終端。3.4 可選配置 Maven 鏡像加速依賴下載手機(jī)端的網(wǎng)絡(luò)環(huán)境通常不如電腦穩(wěn)定而且 Maven 默認(rèn)從中央倉庫下載依賴速度可能很慢。一個常用且穩(wěn)妥的做法是配置國內(nèi)鏡像倉庫這里以阿里云 Maven 鏡像為例。進(jìn)入 Maven 配置目錄nano $PREFIX/etc/maven/settings.xml如果你的 Termux 用的是系統(tǒng)級目錄也可以先看下當(dāng)前的 Maven 配置文件路徑mvn help:effective-settings在配置文件中找到mirrors節(jié)點(diǎn)加入下面的 mirrormirror idaliyunmaven/id mirrorOfcentral/mirrorOf nameAliyun Maven Central Mirror/name urlhttps://maven.aliyun.com/repository/public/url /mirror保存退出后后續(xù) Maven 依賴?yán)∷俣葧忻黠@提升。需要強(qiáng)調(diào)的是鏡像配置屬于“錦上添花”的選項沒有它也能構(gòu)建只是慢一點(diǎn)。不要為了追求速度去配置來源不明的鏡像倉庫尤其是含有“私服”“破解”等字樣的存在依賴安全和供應(yīng)鏈風(fēng)險。4. 從 0 到 1手寫一個干凈的構(gòu)建腳本環(huán)境搭好后開始進(jìn)入這篇文章的核心寫構(gòu)建腳本。腳本的作用是把復(fù)雜的構(gòu)建命令標(biāo)準(zhǔn)化讓手機(jī)上的構(gòu)建變成“一行命令一個結(jié)果”。4.1 腳本目標(biāo)與設(shè)計原則在設(shè)計這個腳本之前先明確它要滿足的基本目標(biāo)自動檢測 Java 和 Maven 環(huán)境是否存在。支持可選參數(shù)比如是否跳過測試、是否執(zhí)行 clean。編譯、打包、輸出日志。檢測構(gòu)建結(jié)果非零退出碼表示失敗。產(chǎn)物歸檔到指定目錄避免覆蓋?；谶@些目標(biāo)腳本設(shè)計遵循三個原則。第一最小依賴。能用標(biāo)準(zhǔn) Shell 語法實(shí)現(xiàn)的功能就不要引入額外的工具。手機(jī)上不像電腦服務(wù)器那樣有一堆現(xiàn)成工具腳本越少依賴越容易跑通。第二防御式檢查。每一步做之前先檢查前置條件失敗了盡早退出而不是走到最后才發(fā)現(xiàn)環(huán)境問題。第三日志友好。輸出要帶時間戳和明確的信息級別這樣排查問題時有據(jù)可查。4.2 環(huán)境自檢腳本第一個腳本負(fù)責(zé)檢查基礎(chǔ)環(huán)境。把它命名為check_env.sh放在項目根目錄下。腳本會逐一檢查 java、javac、mvn、git 四個命令任意一個缺失都會給出提示并返回非零退出碼。文件路徑/data/data/com.termux/files/home/scripts/check_env.sh#!/data/data/com.termux/files/usr/bin/bash # 手機(jī)構(gòu)建環(huán)境自檢腳本 # 用法: bash check_env.sh echo 開始檢查 Java 構(gòu)建環(huán)境 check_cmd() { command -v $1 /dev/null 21 { echo [OK] $1: $($1 --version 21 | head -n 1) } || { echo [FAIL] 未找到命令: $1 return 1 } } FAILED0 check_cmd java || FAILED1 check_cmd javac || FAILED1 check_cmd mvn || FAILED1 check_cmd git || FAILED1 echo if [ $FAILED -eq 0 ]; then echo 環(huán)境檢查通過可以開始構(gòu)建 else echo 環(huán)境檢查失敗請先安裝缺失組件 exit 1 fi這段腳本里有一個值得解釋的設(shè)計command -v是 Bash 內(nèi)置命令用于檢測某個命令是否存在以及它的路徑比which更穩(wěn)定因為它在命令缺失時也能正常返回狀態(tài)碼不會誤報。head -n 1是為了只顯示版本信息的第一行避免 java 或 mvn 輸出版權(quán)聲明等冗余內(nèi)容。執(zhí)行方式chmod x check_env.sh bash check_env.sh4.3 一鍵構(gòu)建腳本第二個腳本是真正的主角負(fù)責(zé)執(zhí)行完整構(gòu)建流程。它支持以下參數(shù)參數(shù)含義默認(rèn)值--clean執(zhí)行 clean 階段不執(zhí)行--skipTests跳過測試不跳過--output目錄指定產(chǎn)物輸出目錄build_output文件路徑/data/data/com.termux/files/home/scripts/build_project.sh#!/data/data/com.termux/files/usr/bin/bash # 通用 Java 項目構(gòu)建腳本 # 用法: # bash build_project.sh [--clean] [--skipTests] [--outputdir] PROJECT_DIR$(cd $(dirname $0)/.. pwd) OUTPUT_DIRbuild_output MVN_ARGSvalidate compile # 解析參數(shù) for arg in $; do case $arg in --clean) MVN_ARGSclean $MVN_ARGS ;; --skipTests) MVN_ARGS$MVN_ARGS -DskipTests ;; --output*) OUTPUT_DIR${arg#*} ;; *) echo 未知參數(shù): $arg exit 1 ;; esac done cd $PROJECT_DIR || { echo 無法進(jìn)入項目目錄: $PROJECT_DIR; exit 1; } echo echo 項目目錄: $PROJECT_DIR echo 輸出目錄: $OUTPUT_DIR echo Maven 命令: mvn $MVN_ARGS echo 當(dāng)前時間: $(date %Y-%m-%d %H:%M:%S) echo echo 開始編譯打包... mvn $MVN_ARGS package -q 21 | tee build.log BUILD_EXIT_CODE${PIPESTATUS[0]} echo if [ $BUILD_EXIT_CODE -eq 0 ]; then echo 構(gòu)建成功 else echo 構(gòu)建失敗請查看 build.log exit 1 fi # 歸檔產(chǎn)物 mkdir -p $OUTPUT_DIR find target -maxdepth 1 -type f -name *.jar -o -name *.war | while read -r f; do cp $f $OUTPUT_DIR/ echo 已歸檔: $OUTPUT_DIR/$(basename $f) done echo 構(gòu)建流程結(jié)束這個腳本有幾個細(xì)節(jié)值得展開說明。PROJECT_DIR$(cd $(dirname $0)/.. pwd)這一行意思是自動定位腳本文件所在目錄的上級目錄作為項目根目錄。這樣你把腳本放在項目下的scripts/子目錄時無論終端當(dāng)前在哪個目錄執(zhí)行它都能找到正確的項目位置。mvn $MVN_ARGS package -q 21 | tee build.log這里用了管道和tee作用是讓構(gòu)建日志既顯示在屏幕上又保存到文件里。后面的${PIPESTATUS[0]}則是 Bash 中獲取管道中第一個命令退出碼的標(biāo)準(zhǔn)寫法如果不這樣寫拿到的是tee的退出碼非常容易掩蓋構(gòu)建真實(shí)的失敗原因。這段腳本是后續(xù)整個自動化流程的基礎(chǔ)。你可以把它放到任意 Java 項目的scripts/目錄下方便統(tǒng)一管理。4.4 產(chǎn)物歸檔與日志命名規(guī)范構(gòu)建腳本最后做了產(chǎn)物歸檔這里補(bǔ)充說明一下命名規(guī)范。日志文件名固定為build.log在下一次構(gòu)建時會被覆蓋。如果你希望保留歷史日志可以把時間戳加入文件名LOG_FILEbuild_$(date %Y%m%d_%H%M%S).log產(chǎn)物目錄同理每次構(gòu)建后的 jar 包如果重名會被直接覆蓋。要避免覆蓋可以按日期或構(gòu)建版本號創(chuàng)建子目錄OUTPUT_DIRbuild_output/$(date %Y%m%d_%H%M%S)這兩種做法根據(jù)實(shí)際需要取舍。保留歷史日志對排查偶發(fā)問題非常有幫助特別是“昨天還能構(gòu)建今天突然失敗”的情況翻日志會發(fā)現(xiàn)原來是依賴版本被某次更新動了。5. 完整實(shí)戰(zhàn)用腳本完成一個真實(shí) Java 項目的構(gòu)建5.1 拉取代碼到手機(jī)先找一個真實(shí)的 Java 項目來驗證腳本。這里以你維護(hù)或參與的一個普通 Maven 項目為例假設(shè) Git 倉庫地址是 SSH 或 HTTPS 形式。在 Termux 中執(zhí)行的代碼拉取命令和電腦上完全一致git clone https://your-git-host/your-team/demo-java-project.git cd demo-java-project在項目目錄下確認(rèn)pom.xml文件存在ls -la pom.xml如果輸出顯示文件存在就可以執(zhí)行構(gòu)建腳本了。如果連 pom.xml 都沒有說明這個項目不是 Maven 項目腳本需要調(diào)整為 Gradle 對應(yīng)版本。5.2 把腳本放進(jìn)項目目錄建議在項目根目錄下建一個scripts/子目錄把前面兩個腳本放進(jìn)去。目錄結(jié)構(gòu)類似demo-java-project/ ├── pom.xml ├── src/ ├── scripts/ │ ├── check_env.sh │ └── build_project.sh └── build_output/把腳本放在項目里有兩個好處一是腳本和項目代碼一起走 Git 版本管理團(tuán)隊其他人也能復(fù)用二是PROJECT_DIR定位邏輯更清晰腳本天然知道項目根目錄在哪里。如果你不想每個項目都復(fù)制一份腳本也可以把腳本放在固定目錄比如~/scripts/下然后通過參數(shù)指定項目路徑。這里不展開復(fù)雜設(shè)計先用最直觀的“項目內(nèi)腳本”方式。5.3 執(zhí)行腳本并查看預(yù)期輸出執(zhí)行環(huán)境自檢bash scripts/check_env.sh預(yù)期輸出大致是 開始檢查 Java 構(gòu)建環(huán)境 [OK] java: openjdk 17.0.x 2024-xx-xx [OK] javac: 17.0.x [OK] mvn: Apache Maven 3.x.x [OK] git: git version 2.x.x 環(huán)境檢查通過可以開始構(gòu)建 然后執(zhí)行構(gòu)建bash scripts/build_project.sh --clean預(yù)期輸出包含 項目目錄: /data/data/com.termux/files/home/demo-java-project 輸出目錄: build_output Maven 命令: mvn clean validate compile package -q 當(dāng)前時間: 2025-01-10 14:23:45 開始編譯打包... 構(gòu)建成功 已歸檔: build_output/demo-java-project-1.0.0.jar 構(gòu)建流程結(jié)束看到“構(gòu)建成功”和“已歸檔”兩行說明整個流程已經(jīng)跑通。5.4 失敗時的第一步排查如果構(gòu)建失敗腳本最終會輸出 構(gòu)建失敗請查看 build.log。此時第一步不是重新運(yùn)行而是打開 build.log 查看關(guān)鍵信息tail -n 50 build.log通常能看到兩類錯誤。一類是編譯錯誤代碼中出現(xiàn)了語法問題或類型不匹配需要定位到具體報錯文件和行號。另一類是依賴解析失敗Maven 無法從倉庫下載某個依賴。依賴解析失敗時檢查網(wǎng)絡(luò)連接、鏡像配置、以及該依賴坐標(biāo)是否寫錯。這里要強(qiáng)調(diào)一個手機(jī)端特有的問題Termux 在某些 Android 系統(tǒng)上后臺運(yùn)行時會被系統(tǒng)回收進(jìn)程導(dǎo)致構(gòu)建中斷。如果構(gòu)建過程超過幾分鐘建議在 Termux 設(shè)置里開啟“Acquire wakelock”選項或者使用termux-wake-lock命令讓手機(jī)保持喚醒狀態(tài)。這個細(xì)節(jié)如果沒提前處理好你會碰到“構(gòu)建其實(shí)沒失敗是手機(jī)鎖屏后把進(jìn)程殺了”的詭異現(xiàn)象。6. 版本升級自動構(gòu)建、定時構(gòu)建與聯(lián)動腳本如果一個腳本只能手動執(zhí)行本質(zhì)上還是把電腦上的命令搬到了手機(jī)上價值有限。真正能發(fā)揮手機(jī)構(gòu)建腳本優(yōu)勢的是把它嵌入到自動化流程里。6.1 循環(huán)構(gòu)建與持續(xù)驗證假設(shè)你在做一個小型庫項目提交代碼前想連續(xù)跑 10 次構(gòu)建確認(rèn)不存在偶發(fā)問題。這種情況下寫一個簡單的循環(huán)腳本非常順手。文件路徑~/scripts/loop_build.sh#!/data/data/com.termux/files/usr/bin/bash # 循環(huán)構(gòu)建腳本用于穩(wěn)定性驗證 # 用法: bash loop_build.sh [次數(shù)] COUNT${1:-10} SUCCESS0 FAILED0 for ((i1; iCOUNT; i)); do echo 第 $i 次構(gòu)建開始 $(date %H:%M:%S) bash $HOME/scripts/build_project.sh --clean --skipTests /dev/null 21 if [ $? -eq 0 ]; then SUCCESS$((SUCCESS1)) echo 第 $i 次構(gòu)建成功 else FAILED$((FAILED1)) echo 第 $i 次構(gòu)建失敗 fi done echo 循環(huán)構(gòu)建結(jié)束 echo 成功: $SUCCESS, 失敗: $FAILED這里把構(gòu)建腳本的輸出重定向到/dev/null只保留循環(huán)腳本自己的匯總信息。這樣觀察起來更清晰不會被大量 Maven 日志淹沒。一個非常實(shí)用的延伸場景手機(jī)長時間跑構(gòu)建腳本時相當(dāng)于在給手機(jī)做“設(shè)備老化測試”。你可以一邊充電一邊循環(huán)跑觀察電量消耗、機(jī)身溫度、構(gòu)建耗時是否隨著次數(shù)增加而變長。如果第 1 次構(gòu)建 50 秒第 30 次構(gòu)建變成 90 秒大概率是 SoC 熱降頻導(dǎo)致性能衰減這也能幫你反向理解手機(jī)上跑構(gòu)建的性能邊界。6.2 與 Git Hook 聯(lián)動Git Hook 是 Git 提供的事件回調(diào)機(jī)制可以在特定動作發(fā)生時自動觸發(fā)腳本。在手機(jī)端最實(shí)用的場景是pre-commit和post-commit。前者在提交前跑一遍輕量編譯后者在提交后自動把產(chǎn)物歸檔。在項目目錄下操作mkdir -p .git/hooks編輯.git/hooks/pre-commit#!/data/data/com.termux/files/usr/bin/bash # 提交前自動編譯失敗則阻止提交 cd $(pwd) || exit 1 mvn compile -q 21 | tee /tmp/pre-commit-build.log exit_code${PIPESTATUS[0]} if [ $exit_code -ne 0 ]; then echo 提交前編譯失敗已阻止提交 exit 1 fi echo 提交前編譯通過編輯完成后需要給文件可執(zhí)行權(quán)限chmod x .git/hooks/pre-commit這個 hook 的作用很直接如果你改了代碼但編譯都不過根本走不到 commit 那一步。這在手機(jī)上尤其重要因為手機(jī)沒有電腦那樣的多窗口 IDE 實(shí)時反饋很容易改完代碼不知道有什么低級語法錯誤。要注意的是Git Hook 是項目本地的不會隨分支推送到遠(yuǎn)端。團(tuán)隊協(xié)作時如果希望所有成員都使用同一套腳本更合理的做法是把腳本放到項目scripts/目錄并提交到倉庫然后在 README 里寫清楚使用方式讓成員自行配置軟鏈接到.git/hooks/。7. 常見問題與排查方法手機(jī)端構(gòu)建 Java 項目的過程中我整理了幾個最常遇到的問題這些問題在電腦上很少出現(xiàn)但在手機(jī)上非常典型。問題現(xiàn)象可能原因排查方式解決方案執(zhí)行 java 提示 command not foundJDK 未安裝或 PATH 未配置執(zhí)行pkg list-installed檢查 openjdk 是否安裝執(zhí)行echo $PATH查看是否包含 $PREFIX/bin重新安裝pkg install openjdk-17修改 ~/.bashrc 補(bǔ)充 PATHMaven 構(gòu)建時下載依賴非常慢默認(rèn)從中央倉庫下載網(wǎng)絡(luò)鏈路不佳查看終端輸出長時間卡在 Downloading 階段配置阿里云鏡像倉庫或使用離線依賴緩存構(gòu)建執(zhí)行一半手機(jī)被殺進(jìn)程系統(tǒng)后臺管理策略回收 Termux 進(jìn)程檢查 Termux 進(jìn)程是否在后臺存活使用termux-wake-lock保持喚醒或在系統(tǒng)設(shè)置中允許 Termux 后臺運(yùn)行代碼在電腦上能編譯手機(jī)上報錯項目依賴了桌面環(huán)境的特殊工具鏈或 JDK 版本不一致對比錯誤日志中的 javac 參數(shù)和 JDK 版本使用與電腦環(huán)境一致的 JDK 版本檢查項目配置的 maven.compiler.source/targetmvn package 執(zhí)行成功但找不到 jar 包產(chǎn)物路徑不在 target 根目錄或打包方式特殊執(zhí)行find . -name *.jar -type f查看實(shí)際打包位置調(diào)整腳本中的產(chǎn)物查找范圍或直接在 pom.xml 中配置 finalName執(zhí)行 git 報“無法將 git 項識別為 cmdlet”在 Windows 風(fēng)格的 PowerShell 中執(zhí)行了 bash 腳本確認(rèn)當(dāng)前終端是 Termux 的 bash而不是其他終端模擬器在 Termux 中執(zhí)行bash 腳本名不要直接雙擊或拖入非 bash 環(huán)境最后一行提到的情況很有意思。很多熟悉 Windows 開發(fā)的同學(xué)拿到這段腳本后習(xí)慣性地在 Windows 命令行或 PowerShell 里執(zhí)行結(jié)果報錯說 git 命令不存在或者語法不兼容。這里要明確一點(diǎn)本文所有腳本基于 Bash Shell 編寫Termux 使用的是 Linux 風(fēng)格環(huán)境和 Windows 的 cmd/PowerShell 不通用。如果非要在 Windows 上用需要把腳本改成.bat或 PowerShell 版本這不是本文的范圍。另外還有一個容易被忽略的細(xì)節(jié)手機(jī)上的文件系統(tǒng)路徑不允許像 Windows 那樣隨意帶空格。Termux 的默認(rèn)用戶目錄/data/data/com.termux/files/home沒有空格這也是為什么在手機(jī)上跑腳本反而不容易出現(xiàn)電腦上“路徑包含空格導(dǎo)致命令行解析錯誤”的問題。8. 最佳實(shí)踐與工程建議到這里手機(jī)上的構(gòu)建鏈路已經(jīng)能跑通了。但要把這套東西用在真正的日常開發(fā)中還需要一些工程層面的修煉。第一腳本必須納入版本管理。不要只在手機(jī)本地保留一份腳本。把腳本提交到 Git 倉庫電腦和手機(jī)共用一套這樣換機(jī)、重裝系統(tǒng)后不會丟失。腳本不是一次性產(chǎn)物它和源代碼一樣有迭代、有 bug、有優(yōu)化空間。第二日志要長期留存。我在腳本中把日志輸出到了build.log但建議每次構(gòu)建后把日志歸檔到帶時間戳的文件。這樣遇到“昨天還正常、今天突然失敗”的情況可以翻出歷史日志做對比而不是靠大腦回憶。手機(jī)存儲空間相對有限可以定期清理三天前的日志或者只保留最后一次失敗日志。第三權(quán)限上遵循最小化原則。在手機(jī)上配置 SSH 訪問 Git 倉庫時盡量使用獨(dú)立的 deploy key不要直接把個人主賬號的私鑰放到手機(jī)里。手機(jī)比電腦更容易丟失一旦設(shè)備丟失私鑰泄露的后果比電腦嚴(yán)重得多。如果項目使用 HTTPS 拉取代碼更推薦配置憑據(jù)助手避免把明文密碼寫在腳本里。任何腳本中都不應(yīng)該出現(xiàn)密碼、Token、密鑰等信息。第四遠(yuǎn)程構(gòu)建工具鏈可以并行使用。手機(jī)上本地構(gòu)建適合快速驗證但如果是正經(jīng)的發(fā)布構(gòu)建、全量測試Jenkins 等 CI 工具依然是更可靠的選擇。你可以在手機(jī)上寫一個觸發(fā) Jenkins 遠(yuǎn)程構(gòu)建的腳本用 curl 調(diào)用遠(yuǎn)端接口。這樣既享受了手機(jī)隨時操作的能力又借助了服務(wù)器的算力。但要注意這種遠(yuǎn)程構(gòu)建必須走正規(guī)的認(rèn)證通道不要在腳本中明文存放 Jenkins API Token。第五不要把一個腳本做成“萬能構(gòu)建器”。不同項目的依賴差異、JDK 版本要求、構(gòu)建參數(shù)都不一樣。最好的做法是每個項目在scripts/目錄下維護(hù)自己的構(gòu)建腳本公共邏輯抽成公共函數(shù)庫而不是試圖用一份配置適配所有項目。否則一旦某個項目特殊腳本里的判斷邏輯會膨脹到無法維護(hù)。第六理解手機(jī)構(gòu)建的性能邊界。構(gòu)建耗時、內(nèi)存占用、機(jī)身溫度這三個指標(biāo)決定了一個項目適不適合在手機(jī)上跑。如果你發(fā)現(xiàn)一個項目的完整構(gòu)建會讓手機(jī)卡頓到無法使用那就果斷放棄本地構(gòu)建改用遠(yuǎn)程觸發(fā)。能本地構(gòu)建就本地構(gòu)建不能就遠(yuǎn)程不要為了“秀操作”硬扛。第七關(guān)注安全邊界。在手機(jī)上克隆公司內(nèi)部項目前一定要確認(rèn)項目的訪問權(quán)限合規(guī)。不要用個人手機(jī)拉取公司私有倉庫到個人設(shè)備上除非公司制度明確允許。這是很多人在“手機(jī)開發(fā)”這件事上容易忽略的合規(guī)問題。文章里演示的是一個人可訪問的公開項目或自有項目風(fēng)險可控但如果是團(tuán)隊私密代碼一定要謹(jǐn)慎。9. 總結(jié)與后續(xù)學(xué)習(xí)方向手機(jī)構(gòu)建 Java 項目腳本這條路真正跑通后你會發(fā)現(xiàn)它帶來的不只是“能用手機(jī)構(gòu)建”這一點(diǎn)新鮮感而是改變了一種開發(fā)習(xí)慣你不再依賴固定的物理位置什么時候想驗證代碼掏出口袋里的設(shè)備就能做。腳本的好處是讓整個過程標(biāo)準(zhǔn)化每次執(zhí)行的結(jié)果都可預(yù)期出了問題也有日志可查。這篇文章從環(huán)境準(zhǔn)備、基礎(chǔ)命令、腳本設(shè)計到自動化聯(lián)動用了很大的篇幅把細(xì)節(jié)講透核心是希望你理解手機(jī)構(gòu)建不是“把電腦壓扁塞進(jìn)手機(jī)”而是“在受限環(huán)境中重新思考構(gòu)建流程”。真正值得養(yǎng)成的能力是不管在哪臺設(shè)備上都能快速搭出一套可復(fù)用的構(gòu)建系統(tǒng)。接下來可以繼續(xù)深入的方向一是把腳本擴(kuò)展成 Gradle 版本適配更多類型的項目二是研究 Termux 定時任務(wù)讓手機(jī)在凌晨自動拉代碼、構(gòu)建、發(fā)布到內(nèi)網(wǎng)測試包實(shí)現(xiàn)無人值守三是結(jié)合 GitLab CI、Jenkins 等工具設(shè)計一套“手機(jī)觸發(fā)、遠(yuǎn)程執(zhí)行”的構(gòu)建體系。每一步都能加深你對構(gòu)建鏈路和自動化工程的理解。最后給一個實(shí)際建議不要急著把所有項目都搬到手機(jī)上先挑一個個人維護(hù)的小工具項目跑通腳本、跑幾次真實(shí)構(gòu)建體驗一下手機(jī)構(gòu)建的優(yōu)點(diǎn)和限制。等你習(xí)慣了這套流程再決定是否擴(kuò)展到更大的項目。工具說到底是為了解決問題手機(jī)構(gòu)建腳本的價值最終要由你的使用頻率和實(shí)際收益來證明。