自前作《Unity Performance Tuning Bible》以來已過了數年，Unity、裝置以及調優的進行方式都有了變化。本序章將先概略回顧引擎與裝置的變化，再說明 2026 年的調優正朝向何處發展。
Unity 中變動最大的是繪製。Unity 6 在 URP 中導入了 Render Graph，最佳化工作的重心從自行重新排列命令，轉移為向引擎正確宣告資源的使用方式並確認其結果。著色器預熱與逐物件參數的傳遞方式，在 Unity 6 世代也新增了選項。C# 端在 Unity 6 期間不會有太大改變，但 Unity 7 會在編輯器與部分桌面播放器中導入 CoreCLR，GC 的機制也會大幅改變。另一方面，行動裝置目前仍是 IL2CPP 與 Boehm GC，因此以往的記憶體最佳化思路仍然有效。在建置與發佈方面，不需改寫程式碼即可調整容量、記憶體與速度之間平衡的設定也增加了。
裝置也有了很大的改變。以 GPU 的 Geekbench 分數*1比較，撰寫前作的 2022 年的高階機種 iPhone 14 Pro（A16）為 18,691，而 2026 年的 iPhone 18 Pro 與 iPhone Duo 所搭載的 A20 Pro 為 55,120，約為 3 倍。Android 方面，Galaxy S22（Snapdragon 8 Gen 1、Adreno 730）為 6,179，相對地 Galaxy S26 Ultra（Snapdragon 8 Elite Gen 5 for Galaxy、Adreno 840）為 27,501，超過 4 倍。
不過，低階機種並沒有太大的改變。2022 年在日本國內發售的 Galaxy A23 5G，配置為 Dimensity 700（Mali-G57 MC2）與 4GB 記憶體。2025 年發售的同系列 Galaxy A25 5G，SoC 雖換成了 Dimensity 6100+，但 GPU 仍是相同的 Mali-G57 MC2，分數為 1,400，記憶體也仍是 4GB。與 Galaxy S26 Ultra 相差約 20 倍。
iPhone 方面，在 2022 年時，包含 iPhone SE（第 2 代）在內，記憶體 3GB 以下的裝置仍被廣泛使用。到了 2026 年，iPhone 14 之後記憶體 6GB 以上的裝置成為主流，但早在 2022 年，足以應付日常使用的裝置就已普及，因此即使推出新機種，換機也不容易推進。直到 2025 年初仍在販售的 iPhone SE（第 3 代）與 iPhone 13 等 4GB 的裝置至今仍大量存在，3GB 的 iPhone SE（第 2 代）也仍有部分使用者在使用。
結果，在 Android 上長期困擾開發者的「要以哪些裝置為目標」這個問題，在 iOS 上也已無法忽視。從記憶體 12GB 的 iPhone 18 Pro，到 3GB 的 iPhone SE（第 2 代，2020 年發售），同一款遊戲必須支援的裝置範圍已經擴大。配合遊戲類型，依裝置效能切換繪製表現與品質設定的作法，比以往更受到需要（第 3 部第 3 章「依裝置切換繪製設定」）。
[*1] Geekbench Browser https://browser.geekbench.com/
話雖如此，我們所要解決的問題本身，與前作的時期並無太大差異：行動裝置 GPU 的記憶體頻寬、繪製大量物件時的 CPU 負載、著色器編譯所造成的尖峰、資產的釋放遺漏、各裝置的記憶體上限。許多新功能，都是針對這些既有問題的新工具。因此，本書並非只探討 Unity 6 之後才能使用的功能。角色動畫的負載對策、著色器超越函數的近似、AssetBundle 的壽命管理、提高 iOS 的記憶體上限等，也包含許多可以直接套用到更早版本專案的內容。
在第 1 部到第 3 部的開頭，我們重新整理了該領域在 2026 年發生了什麼變化，以及各章探討什麼。若想從症狀查詢章節，請參照卷首的「依課題查詢的索引指南」。
另一方面，在開發現場，2026 年最受關注的是 AI。AI 程式設計代理已成為日常用來分擔部分實作與審查的工具，效能調優也不例外。本書第 4 部第 3 章「將調優寶典做成 AI 程式設計代理的技能」，探討了將前作與本書的知識轉換為代理評估規則的嘗試。
不過，調優有一個在交給 AI 之前就必須具備的前提，那就是測量。若不測量哪裡慢就動手修改，就無法判斷是否真的變快了。因此就整個業界而言，首先推進的是測量自動化的相關作法。其方向是每次建置都以固定的步驟取得實機的數值，並與過去的測量結果比較，自動偵測劣化，藉此減少人工開啟 Profiler 的次數，避免太晚才發現問題。
在筆者們所屬的 CyberAgent 遊戲娛樂事業部，作為自動化的努力之一，也建置了讓 AI 代理即時觀察與操作 Unity 應用程式的執行階段橋接器。將它與裝置農場結合，由 CI 將「取得機種、安裝應用程式、依既定步驟操作、測量並取回結果」的整個流程交給代理負責。測量使用內建於實機應用程式的執行階段 Profiler，並將取得的資料傳送到伺服器，以便從瀏覽器與過去的測量結果並列確認，或在變化超過閾值時發出通知。傳送到伺服器的資料之後會由 AI 代理取得，從瓶頸的診斷進行到修正（第 4 部第 2 章「自動化每日建置的實機效能分析」）。
當然，這並不表示不再需要人的判斷。要看什麼、與什麼比較、在哪裡收手，這些基準仍然需要由人來掌握。能夠自動化的，只有已經存在這些基準的部分。本書搭配實測值提供判斷的素材，也是出於這個原因。