你好，這裡是 NkBe 的新站

Tue, 06 Oct 2026 00:00:00 GMT

這個站原本只是一頁導航，現在換成 Astro + Firefly 主題，之後會把專案紀錄和技術筆記寫在這裡。

目前還在整理中，專案請先看專案頁。

一加內核開源，發現新增「和平精英」專項檢測

Sat, 03 Oct 2026 00:00:00 GMT

在一加開源的 Ace 6 Ultra（聯發科 MT6993）內核模組原始碼中，出現了一個新的檔案 oplus_kernel_security_check.c。

檔案頭部註釋說明，這是為了「和平精英」的需求進行的內核完整性檢測，作者署名為 cenjun，日期標註為 2025 年 12 月。

它的思路並不複雜：不攔截，只記錄。ko 檔案照常載入，程序不會被終止，也沒有任何封禁動作，異常只會記錄為事件，等待用戶空間讀取。

🔍 檢測了什麼#

1. 系統調用表（Syscall Table）#

開機時，為整個表記錄一份 SHA256 指紋，之後每小時重新計算一次。
如果與初始值不符，就會記錄一條帶有時間戳記的事件。
限制：只比較表中的函數指標，不檢查函數本體，因此 inline hook 是無法檢測到的。

2. ko 模組載入（Kernel Module Loading）#

掛載在內核的 load_module 上，每次載入一個 ko 檔案，就會對其映像計算雜湊值，然後與名單進行比較：

不在名單中：記錄為未知模組
雜湊值不匹配：記錄為被篡改
雜湊值一致：放行

名單由系統程序 oplus_kohashpro 寫入，並且必須等待系統報告開機完成後，檢測才會啟動。每類事件最多保留 10 條，超出部分會丟棄最舊的。

⬆️ 對 root 用戶意味著什麼#

判定方式只有一條：是否在名單上。即使是自己編譯、完全無害的 ko 檔案，在它看來也與被篡改的 ko 檔案沒有區別。

KSU 的模組：不經過 load_module，不在檢測範圍內。
KernelSU 本體：如果以 LKM 方式載入，它自己的 ko 檔案會被記錄為未知模組（此項依程式碼邏輯推斷，尚未經實際設備驗證）。這也代表從理論上使用 GKI 或 Magisk 就能規避該項檢測。

不少 root 玩家表示，他們同樣反感作弊行為，也理解遊戲方維護公平環境的需要，只希望這類訊號僅作為參考，不要直接等同於作弊證據。

Note

以上內容均基於對公開原始碼的解讀。

原始碼來源：OnePlusOSS / android_kernel_modules_and_devicetree_oneplus_mt6993

適配 Minecraft 26.1.x：技術遷移實錄

Sat, 25 Apr 2026 00:00:00 GMT

深度解析 Java 25、Unobfuscated Loom 與 Mojang 官方對映的適配細節
由 Gemini 3.1 Pro 自我的 md 原稿重寫為 html，換行好像都是問題///

序言#

隨著 Minecraft 26.1.x 的釋出，Fabric 模組開發生態迎來了一次真正意義上的分水嶺。

這不只是一次例行的版本升級——而是 26.1 Fabric 所代表的工具鏈、對映體系與開發流程的整體轉向。

不僅 Java 版本躍升至 25，構建工具 Loom 的核心架構、對映機制與 GUI 系統都發生了根本性的重構。

本文將以 BoatFly 與 PetPhraseX 的完整適配過程為例，簡單說下有關本次遷移的技術細節與踩坑經驗。

第一部分：工具鏈與環境配置#

1.1 Java 版本升級至#

Minecraft 26.1.x 要求最低 Java 25 作為編譯與執行環境，這不只是版本號上的遞進，更涉及 JVM 的多項新特性與效能最佳化。

在 gradle.properties 中，我們需要明確指定目標版本，如：

1
org.gradle.jvmargs = -Xmx4096m -Dfile.encoding=UTF-8
2
target_java_version = 25
3
minecraft_version = 26.1.2

Warning

**注意：**若使用 Gradle Wrapper 需升級至 9.4.0+。

1.2 Fabric Loader 與 Loom 的版本對齊#

Loom 1.15-SNAPSHOT 是適配 26.1.x 的關鍵版本。它引入了全新的編譯流程，不再依賴 Yarn 對映的中間層轉換。

同時也建議將 Fabric Loader升級至 0.18.6+，以支援新的模組載入機制。

1
plugins {
2
    // 引入支援 Unobfuscated 流程的最新版 Loom 外掛
3
    id 'net.fabricmc.fabric-loom' version '1.16-SNAPSHOT'
4
}
5
dependencies {
6
    // 指定目標 Minecraft 版本為 26.1.2
7
    minecraft "com.mojang:minecraft:26.1.2"
8

9
    // 引入支援新模組載入機制的 Fabric Loader 0.18.6+
10
    compileOnly "net.fabricmc:fabric-loader:0.18.6"
11
    }

1.3 fabric.mod.json 後設資料規範更新#

伴隨 Fabric Loader 0.18.6+ 的升級，模組後設資料檔案的校驗規則迎來了強約束更新，過往寬鬆的欄位宣告將直接導致模組無法載入，甚至出現啟動器校驗不透過的問題。

核心變更集中在依賴宣告、環境限定與 Java 版本約束三個維度，尤其針對 Minecraft 26.1.x 與 Java 25 的強制要求，必須在後設資料中明確宣告。

Warning

必須在 depends 中明確宣告 "java": ">=25"，否則 Loader 可能會直接阻斷模組載入，無任何容錯空間。

1.4 IDE 開發環境適配最佳化#

針對 Java 25 與全新 Loom 工具鏈，主流 IDE 也需要完成對應的配置最佳化，才能避免同步失敗、原始碼對映錯亂、除錯斷點失效等問題。

以 IntelliJ IDEA 為例，核心適配步驟如下：

升級 IDEA 至 2025.3+ 版本，才能獲得 Java 25 語法的完整支援與 Gradle 9.4+ 的原生相容
在 專案結構 → SDK 中新增 Java 25 正式版 SDK，並將專案的 SDK、語言級別均設定為 Java 25
在 Gradle 設定中，將「使用 Gradle 來自」設定為 gradle-wrapper.properties，並指定 Gradle JVM 為 Java 25

第二部分：對映機制遷移#

2.1 從 Yarn 到 Mojang 的範式變革#

本次 26.1.x 適配最核心的變革，莫過於 Loom 1.15+ 帶來的 Unobfuscated 原生官方對映開發流程。

過往 Fabric 模組開發的標準流程，是基於社群維護的 Yarn 命名對映編寫程式碼，編譯時通過 Loom 轉換為 Intermediary 中間對映，最終在執行時匹配遊戲的混淆位元組碼。

而全新的 Unobfuscated 流程，直接基於 Mojang 官方釋出的 deobfuscation 對映進行開發，徹底移除了 Yarn 中間層的依賴：

編譯流程大幅簡化，無需執行對映轉換，構建速度將會有所提升
命名與官方原始碼完全對齊，避免了 Yarn 與官方對映的命名差異帶來的理解成本
與 Forge 生態的命名體系完全一致，跨載入器模組開發的適配成本大幅降低

在 build.gradle 中，無需再引入任何 Yarn 對映依賴，僅需保留 Minecraft 官方依賴即可完成對映配置，這也是本次工具鏈升級最具顛覆性的變化。

2.2 大規模包名與類名變更#

官方對映的引入，導致了數百個類的重新命名。以下是在我專案中常出現的變更對照：

1
// 文本
2
net.minecraft.text.Text → net.minecraft.network.chat.Component
3

4
// GUI
5
net.minecraft.client.gui.screen.Screen → net.minecraft.client.gui.screens.Screen
6
net.minecraft.client.gui.widget.ButtonWidget → net.minecraft.client.gui.components.Button
7

8
// 渲染
9
net.minecraft.client.gui.DrawContext → net.minecraft.client.gui.GuiGraphics

Warning

**注意：**除了命名變更，大量方法的引數順序、返回值型別也發生了調整，切勿僅做簡單的查詢替換，需逐行核對方法簽名的完整性，避免出現執行時崩潰。

第三部分：GUI 系統重構#

3.1 渲染生命週期的變更#

在我的專案中，最重大的 API 變更發生在 Screen 類。

舊版本使用 render()，新版本則改為 extractRenderState()——必須重新適應新的圖形提取模式。

Note

提示：GuiGraphicsExtractor 的 text() 預設為左對齊，不再內建居中功能，反正開發文件裡我沒看到。

1
@Override
2
public void extractRenderState(GuiGraphicsExtractor graphics, int mouseX, int mouseY, float delta) {
3
    super.extractRenderState(graphics, mouseX, mouseY, delta);
4

5
    // 手動計算居中位置
6
    int titleWidth = this.font.width(this.title);
7
    int centerX = (this.width - titleWidth) / 2;
8
    graphics.text(this.font, this.title, centerX, 10, 0xFFFFFF, true);
9
}

第四部分：Mixin 注入體系適配要點#

本次 26.1.x 版本升級中，Mixin 注入邏輯的調整，是多數模組啟動崩潰的核心誘因。

除了前文提到的類名、方法名全量變更，遊戲核心類的執行流程、位元組碼結構也有深層重構，過往的注入點會出現無效異常，甚至直接阻斷遊戲啟動。

以下為本次適配的核心規則，均來自 BoatFly 與 PetPhraseX 的實戰驗證。

4.1 注入目標的全量重定位#

官方對映體系下，Mixin 注入的核心目標，必須完全替換為 Mojang 官方的命名規範，而非簡單替換 Yarn 對映的名稱。

核心調整包含三個維度：

其一，@Mixin 註解的目標類，需替換為官方對映的全限定類名，不可繼續沿用 Yarn 體系的類路徑。

其二，@At 註解中的注入目標，無論是方法呼叫還是欄位訪問，都需同步更新為官方對映的命名與描述符。

其三，@Shadow 註解的欄位與方法，必須與官方對映的簽名完全一致，否則會同時出現編譯與執行期雙重異常。

4.2 注入規範的強約束更新#

伴隨 Loom 1.15+ 的升級，Mixin 新增了編譯期強校驗機制，過往寬鬆的注入寫法將直接導致構建失敗。

最核心的變更，是要求所有注入點必須顯式宣告 require 屬性，推薦強制每個注入點必須匹配到對應目標以防止靜默崩潰。

同時，介面注入、訪問器的目標類與方法，也需同步完成官方對映的替換，並嚴格按客戶端、服務端環境拆分配置，避免服務端載入客戶端專屬 Mixin 導致的崩潰。

4.3 配置檔案的規範調整#

Mixin 配置檔案需同步完成兩項核心調整，否則會直接導致 Mixin 無法載入。

第一，必須顯式宣告 compatibilityLevel 為 JAVA_25，確保 Mixin 適配 Java 25 的位元組碼版本。

第二，必須顯式宣告 required 為 true，明確告知 Loader 該配置為模組必需，避免載入時的警告與潛在異常。

第五部分：Fabric API 核心體系變更#

Fabric API 針對 26.1.x 同步完成了架構重構，大量常用事件、工具類被標記為棄用甚至移除，事件的觸發時機、引數列表也有破壞性變更。

5.1 客戶端生命週期事件重構#

伴隨 GUI 渲染系統的重寫，客戶端核心生命週期事件也同步完成了調整。

螢幕渲染相關事件，完全對應新的 extractRenderState 生命週期，替換了舊版本的 render 相關事件，觸發時機與傳入引數均有對應調整。

客戶端 Tick、螢幕開啟關閉等核心事件，也進行了名稱空間與分類的重構，需按新的事件路徑完成註冊，否則會出現事件不生效的問題。

5.2 聊天與文本系統適配#

除了前文提到的 Text 到 Component 的類名變更，聊天訊息的事件監聽、文本元件構建 API 也有全量調整。

文本元件的構建方法，需替換為官方對映對應的靜態方法，樣式設定的流式 API 也有對應調整。

聊天訊息相關事件進行了強約束重構，新增了訊息取消機制，攔截或修改聊天訊息需按新的規範返回對應結果，否則會出現訊息重複傳送、攔截失效的問題。

5.3 輸入與按鍵繫結系統調整#

客戶端輸入處理的重構，也帶來了按鍵繫結、滑鼠鍵盤事件的對應變更。

按鍵繫結需使用新的註冊 API，而非舊版本的直接例項化註冊。

按鍵按下/釋放、滑鼠點選滾動等輸入事件，也進行了名稱空間重構，引數列表新增了視窗上下文資訊，需同步完成適配。

第六部分：常見踩坑與解決方案#

在 BoatFly 與 PetPhraseX 的完整適配過程中，我們整理了多數開發者都會遇到的共性問題，對應的解決方案可大幅縮短適配週期。

6.1 編譯與環境類問題#

最常見的「無效的目標發行版: 25」報錯，核心原因無非三點：Gradle 版本過低、IDE 配置的 Java SDK 版本不正確、目標版本宣告錯誤。

對應解決方案也很明確：升級 Gradle Wrapper 至 9.4.0+ 版本，在 IDE 中配置 Java 25 正式版 SDK，並將專案與 Gradle 的 JVM 均設定為 Java 25，同時確認配置檔案中的目標版本號正確。

另一類常見的依賴同步失敗問題，多是 Loom 版本與 Minecraft 版本不匹配，需使用 1.15-SNAPSHOT 及以上的 Loom 版本，才能完整支援 26.1.x 的官方對映流程。

6.2 執行與載入類問題#

模組載入時提示「依賴約束不滿足」，核心是 fabric.mod.json 中的依賴宣告不符合新規範。

必須在依賴中顯式宣告 Java 25、對應的 Fabric Loader 與 Minecraft 版本範圍，否則 Loader 會直接阻斷模組載入，無任何容錯空間。

遊戲啟動時的「模組訪問許可權異常」，是 Java 25 強化了模組系統的訪問控制，需在執行引數中新增對應的模組開放配置，解決反射訪問的許可權問題。

6.3 功能與渲染類問題#

GUI 渲染時文本錯位、元件不顯示，多是未遷移至新的渲染生命週期，仍沿用舊的 render 方法，或是文本座標計算不符合新 API 的預設規則。

需將所有螢幕渲染邏輯遷移至 extractRenderState 方法，手動計算文本與元件的座標，不再依賴舊版本的內建居中功能。

Mixin 注入失效、功能不生效，需先開啟 Mixin 除錯模式，檢視詳細的注入日誌，核對注入目標的命名、描述符是否與官方對映完全一致，多數問題都來自命名的細微偏差。

總結#

Minecraft 26.1.x 的適配雖然涉及深度的技術重構，但也為模組開發生態帶來了長期的穩定性與可維護性。

透過採用官方對映、新的 GUI API 與改進的構建流程，我們現在能編寫更清晰、更易維護的程式碼。