App 加固後閃退，如何按層定位原因

先凍結候選包和復現條件

排查最常見的失真來自測試物件變化。研發重新構建、測試重新簽名、渠道修改資源或加固配置被覆蓋後，檔名仍可能相同。此時日誌、堆疊和修復動作指向的不是同一個產物，任何因果判斷都不可靠。

至少記錄包名、版本、檔案 SHA-256、簽名證書摘要、構建來源、保護配置版本、渠道狀態、裝置型號、系統版本、ABI、安裝方式、賬號資料和網路條件。同時準備由同一源版本生成的未加固基線。

復現步驟應從應用處於什麼狀態開始寫：全新安裝、覆蓋升級、程序被殺、冷啟動、深鏈、推送、後臺恢復或特定賬號。只寫點選圖示後閃退，無法區分啟動、資料遷移和業務入口問題。

• 基線與候選來自同一源版本
• 檔案和簽名身份可複核
• 裝置、安裝和賬號條件固定
• 復現步驟能夠由另一人重複

incident: protected-candidate-startup
candidate:
  artifact_sha256: REDACTED
  signing_sha256: REDACTED
  protection_config: config-v3
environment:
  os: target-version
  abi: arm64-v8a
  install: upgrade-from-production
reproduction:
  entry: launcher
  account_state: signed-in
first_difference:
  phase: native-library-load
  protected: failed
  baseline: passed
next_variable: native-group-auth
rollback_candidate: config-v2

按時間線尋找最早差異，不追最後一條報錯

Android 冷啟動包含程序建立、Application 初始化、主執行緒、Activity 建立、佈局和首次繪製。在真實應用中，ContentProvider、啟動框架、熱修復、動態類載入、Native 庫和第三方 SDK 還會插入這條時間線。一個早期失敗可能導致後續類缺失、資源未初始化或空指標。

把基線和保護候選的時間線並排記錄：程序是否建立，Application 是否進入，Provider 是否完成，類載入器是否準備，關鍵 SO 是否裝載，JNI 是否註冊，首幀是否出現，業務入口是否返回。最早一個不一致的節點就是下一輪證據採集的中心。

如果崩潰發生在監控 SDK 初始化前，線上平臺可能沒有事件。需要結合系統日誌、平臺崩潰報告、Native tombstone 或受控診斷構建，但公開內容不得洩露真實包名、符號、地址和裝置標識。

Java、Native、資源和第三方 SDK 要分層排查

Java 與 Kotlin 層重點檢查反射、註解、序列化、動態類載入、泛型簽名、元件類名和由字串引用的入口。名稱混淆、控制流或程式碼遷移可能破壞這些隱式契約。應根據真實依賴補最小保留規則，而不是把整個包排除後宣佈問題解決。

Native 層檢查目標 ABI、所有依賴、NDK API 下限、JNI 註冊、異常、執行緒和符號。Android NDK 文件說明部分符號在裝載時解析，目標系統不存在的 API 可能讓庫在業務分支執行前就失敗。

資源與 Manifest 可能影響主題、啟動圖、Provider、FileProvider、WebView、動態特性和渠道 SDK。第三方登入、支付、推送、地圖、音影片、熱修復和風控 SDK 還可能具有自校驗或隱式初始化順序，需要使用真實業務賬號和環境驗證。

用單變數實驗縮小保護故障半徑

找到最早差異後，把候選保護範圍按功能或依賴分組。每次只回退或調整一個組，並保持原始碼、依賴、簽名、渠道、裝置和業務輸入不變。新的構建必須獲得新的檔案摘要和配置版本。

如果調整後現象消失，還需要復現一次原配置並重新出現，或者透過更直接的證據證明因果。例如某個 JNI 註冊組恢復後註冊成功且關鍵呼叫透過，比單次不崩潰更有說服力。這個過程是觀察、重檢、判斷和邊界四步，而不是試到能開啟為止。

二分範圍適合快速縮小區域，但最終仍要找到具體契約：名稱、簽名、執行緒、裝載、資源或效能。只把整個業務模組永久排除，可能把高價值程式碼留在未保護狀態，也沒有形成可維護的規則。

閃退、ANR 和效能退化不能混成一個問題

程序異常退出、主執行緒長時間無響應和啟動變慢的證據不同。Android 官方建議從 ANR cluster signature 和執行緒狀態開始，並提醒 nativePollOnce 等幀可能只是取樣時主執行緒空閒，不一定是根因。看到 Native 名稱不代表問題一定來自 SO。

啟動效能應同時觀察 TTID 與 TTFD。保護後首幀正常但資料初始化明顯推遲，使用者仍會感到不可用。反過來，首幀稍慢但關鍵業務穩定，也需要由專案預算決定是否接受，不能用統一數字替所有應用做判斷。

線上崩潰和 ANR 資料要與版本、檔案身份、裝置和渠道關聯。平臺聚類可能合併相似堆疊，但工程團隊仍要確認該事件是否來自保護候選、是否在基線存在、是否只集中於特定系統或 ABI。

• 區分 crash、ANR、卡頓和業務錯誤
• 同時記錄 TTID 與 TTFD
• 崩潰符號與候選包版本匹配
• 按系統、ABI 和渠道觀察聚類
• 不把取樣棧頂自動當作根因

修復完成後回到釋出範圍，而不是停在復現裝置

某臺裝置不再閃退，只說明當前復現點消失。修復候選必須重新執行全新安裝、從線上版本升級、冷啟動、後臺恢復、深鏈或推送入口、關鍵業務、目標系統、目標 ABI 和第三方 SDK 路徑。

還要確認保護範圍沒有被無意縮空。靜態檢查可以核對目的碼是否仍進入預期保護層，執行檢查確認穩定性和輸出一致。修復如果透過永久排除整個核心模組實現，應重新評估風險和替代控制。

最終報告分為已驗證、失敗、未執行和不適用。缺少裝置或環境時限制灰度並列出下一步，不用另一個版本的成功記錄代替。釋出還要具備監控、停止條件和已經演練的回滾包。