更換App圖標(biāo)：Android與iOS雙端實現(xiàn)全解析)
1. 為什么要做動態(tài)圖標(biāo)需求場景與方案選型做游戲運營的朋友一定深有體會版本更新、節(jié)日活動、聯(lián)動 IP 上線都是拉新和召回的關(guān)鍵節(jié)點。App 在桌面上的圖標(biāo)其實是用戶每天打開手機第一眼就看到的核心廣告位成本為零但觸達(dá)率是百分之百。很多手游團隊都會想能不能讓這個圖標(biāo)跟著運營節(jié)奏走比如春節(jié)換成喜慶的紅色主題新版本換成新角色立繪活動結(jié)束再一鍵換回原版。這就是“動態(tài)更換 App 圖標(biāo)”最典型的落地場景。Unity 開發(fā)者接到這個需求時第一反應(yīng)往往是頭疼。因為 Unity 引擎本身并沒有提供“運行時切換圖標(biāo)”的接口這件事繞不開原生層。Android 和 iOS 兩套系統(tǒng)對圖標(biāo)切換的開放程度完全不同Android 靠的是 Activity 別名activity-alias加組件開關(guān)理論上可以任意切換、隨意切換iOS 則從 iOS 10.3 開始提供了系統(tǒng)級的setAlternateIconNameAPI但限制不少比如圖標(biāo)不能帶透明通道每次切換還會彈系統(tǒng)確認(rèn)框。所以接到這個需求第一步不是急著寫代碼而是弄清楚你到底要哪種“動態(tài)”。如果只是包體打多個圖標(biāo)、安裝后用戶手動換那 Android 用 Launcher 圖標(biāo)本身就支持iOS 也能靠描述文件做到但這些都算不上真正的“動態(tài)”。本文討論的“動態(tài)”是指游戲運行過程中客戶端向服務(wù)端請求配置拿到目標(biāo)圖標(biāo)名之后調(diào)用原生接口直接把桌面圖標(biāo)換掉玩家不需要重新安裝 App。這套方案的技術(shù)棧涉及 Unity 與原生交互、雙端平臺差異、系統(tǒng)資源文件打包三塊內(nèi)容。適合已經(jīng)具備一定 Unity 工程經(jīng)驗的開發(fā)者參考你要看得懂 AndroidManifest.xml能寫簡單的 Objective-C 或 Swift知道怎么打 Android 的 aar 和 iOS 的 framework。如果這些還不熟也沒關(guān)系下面每個步驟我都會把原理講清楚照著做也能跑通。方案選型上我最終采用的是“原生能力封裝 Unity 統(tǒng)一調(diào)用層”的結(jié)構(gòu)。Android 端使用PackageManager.setComponentEnabledSetting切換兩個 activity-alias 的啟用狀態(tài)iOS 端使用UIApplication.shared.setAlternateIconNameUnity 側(cè)寫一個 C# 管理器通過 AndroidJavaObject 和 Objective-C 插件分別橋接。這樣設(shè)計的原因是動態(tài)圖標(biāo)的邏輯本質(zhì)上屬于“平臺強相關(guān)”功能如果試圖在 C# 層做統(tǒng)一抽象反而會因為系統(tǒng)差異過大致使抽象層漏洞百出不如各端各做各的只暴露兩個同名接口給上層。2. Android 端實現(xiàn)基于 activity-alias 的動態(tài)切換2.1 核心原理一個圖標(biāo)就是一個可開關(guān)的組件Android 桌面上每個 App 圖標(biāo)本質(zhì)上都對應(yīng)一個入口組件通常是帶MAIN和LAUNCHER意圖過濾器的 Activity或者指向某個 Activity 的activity-alias?！白烂鎴D標(biāo)”和“Activity 組件”的關(guān)系可以理解成快捷方式與目標(biāo)程序的關(guān)系桌面上那個圖標(biāo)只是指向 Activity 的一個殼。activity-alias的作用就是給同一個 Activity 再起一個“馬甲”。系統(tǒng)允許你在 Manifest 里給同一個 Activity 配置多個別名每個別名都可以擁有自己的圖標(biāo)和標(biāo)簽。默認(rèn)情況下哪個別名是啟用狀態(tài)桌面上就顯示哪個圖標(biāo)。關(guān)鍵來了通過PackageManager.setComponentEnabledSetting你可以在運行時把某個別名禁用、把另一個別名啟用。組件狀態(tài)一變系統(tǒng)會發(fā)出廣播Launcher 收到后刷新桌面圖標(biāo)。這就是 Android 動態(tài)換圖標(biāo)的底層邏輯不需要替換任何圖片資源只是切換組件的啟用/禁用狀態(tài)本質(zhì)是“換入口”。2.2 Manifest 配置兩個 alias一個 Activity先看一段我實際在項目中使用的 Manifest 配置application android:allowBackuptrue android:iconmipmap/ic_launcher android:labelstring/app_name activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity activity-alias android:name.MainActivity_Alias_Default android:enabledtrue android:exportedtrue android:iconmipmap/ic_launcher android:labelstring/app_name android:targetActivity.MainActivity intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity-alias activity-alias android:name.MainActivity_Alias_NewYear android:enabledfalse android:exportedtrue android:iconmipmap/ic_launcher_newyear android:labelstring/app_name_newyear android:targetActivity.MainActivity intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity-alias /application這里有個非常容易踩的坑主 Activity 本身不能同時帶 LAUNCHER 的 intent-filter否則系統(tǒng)會認(rèn)為 App 有兩個入口桌面會出現(xiàn)兩個圖標(biāo)或者切換失效。正確做法是主 Activity 只保留默認(rèn)的 MAIN 意圖真正的桌面入口全部由 alias 承擔(dān)。我在前期調(diào)研時看到不少團隊的代碼圖省事讓 Activity 自己和 alias 都帶 LAUNCHER結(jié)果就是每次切換后桌面殘留兩個圖標(biāo)玩家體驗極其糟糕。每個 alias 的android:icon指向不同的 mipmap 資源android:label可以順便連應(yīng)用名一起換。注意資源名要提前在 res 目錄下準(zhǔn)備好不能運行時動態(tài)指定不存在的資源。icon 資源本身建議用自適應(yīng)圖標(biāo)Adaptive Icon即mipmap-anydpi-v26目錄下同時配置前景和背景這樣切到不同圖標(biāo)時在不同廠商桌面上都能保持統(tǒng)一形狀。2.3 運行時切換代碼Java 層寫什么切換邏輯的核心代碼并不長我把它封裝在一個名為IconSwitcher.java的文件里public class IconSwitcher { private static final String ALIAS_DEFAULT .MainActivity_Alias_Default; private static final String ALIAS_NEW_YEAR .MainActivity_Alias_NewYear; public static void switchIcon(Context context, boolean useNewYear) { String targetAlias useNewYear ? ALIAS_NEW_YEAR : ALIAS_DEFAULT; String activeAlias useNewYear ? ALIAS_DEFAULT : ALIAS_NEW_YEAR; PackageManager pm context.getPackageManager(); ComponentName targetName new ComponentName(context.getPackageName(), context.getPackageName() targetAlias); ComponentName activeName new ComponentName(context.getPackageName(), context.getPackageName() activeAlias); pm.setComponentEnabledSetting( targetName, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP ); pm.setComponentEnabledSetting( activeName, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP ); } }注意ComponentName的構(gòu)造如果在 Manifest 里寫的是.MainActivity_Alias_Default那么 Java 側(cè)拼接時前面帶點new ComponentName(context, context.getPackageName() aliasName)。這里用context.getPackageName()獲取應(yīng)用包名不要硬編碼避免不同渠道包改寫包名后失效。DONT_KILL_APP標(biāo)志的意思是切換組件狀態(tài)時不要殺掉應(yīng)用進(jìn)程。因為動態(tài)換圖標(biāo)往往發(fā)生在游戲運行中比如玩家在活動頁面點了“換膚”按鈕你當(dāng)然不希望切換完游戲被系統(tǒng)殺掉。但要注意setComponentEnabledSetting本身是異步的調(diào)用后系統(tǒng)需要一點時間刷新桌面圖標(biāo)正常情況下 12 秒內(nèi)生效。如果你發(fā)現(xiàn)調(diào)用后桌面遲遲不刷新可以在切換后加一句Intent intent new Intent(Intent.ACTION_MAIN); intent.addCategory(Intent.CATEGORY_HOME); context.startActivity(intent);這一招是讓桌面重新布局、觸發(fā)圖標(biāo)刷新的常見土辦法。不過實測中大多數(shù)主流 Launcher 不調(diào)用也能自動刷新倒是部分深度定制的 ROM 需要這個額外觸發(fā)。2.4 從 Unity 調(diào)用AndroidJavaObject 與原生橋接Unity 側(cè)的調(diào)用特別簡單因為只涉及靜態(tài)方法。我在 C# 里寫了一個AndroidIconManagerpublic class AndroidIconManager { private static readonly string ClassName com.yourgame.nativebridge.IconSwitcher; public static void SwitchIcon(bool useNewYear) { #if UNITY_ANDROID !UNITY_EDITOR using (var jc new AndroidJavaClass(ClassName)) { jc.CallStatic(switchIcon, GetUnityActivity(), useNewYear); } #endif } private static AndroidJavaObject GetUnityActivity() { using (var unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer)) { return unityPlayer.GetStaticAndroidJavaObject(currentActivity); } } }這里有一個容易忽略的細(xì)節(jié)方法參數(shù)Context context在 Unity 側(cè)傳的是UnityPlayer.currentActivity。我們把 Activity 實例傳給原生層是因為setComponentEnabledSetting需要 Context而 Activity 本身就是 Context。如果你忘了傳直接在非 Activity 的 Context 下切換部分 ROM 上可能不會刷新圖標(biāo)。原生代碼封裝成 aar 后放到 Unity 工程的Plugins/Android目錄下即可。要提醒一點IconSwitcher類所在的包名和 Unity 工程的com.company.product包名可以不一致但這時context.getPackageName()返回的一定是 Unity 應(yīng)用的包名而不是靜態(tài)類所在包的包名。也就是說無論原生橋接代碼放在哪個包最終操作的對象都是 Unity 入口 Activity 和 Manifest 里聲明的組件這一點不會錯。3. iOS 端實現(xiàn)系統(tǒng) API 與 Info.plist 配合3.1 iOS 的限制為什么 Apple 的“動態(tài)”這么保守如果說 Android 的動態(tài)圖標(biāo)是一把自由開關(guān)那 iOS 就是一把帶安全鎖的鑰匙。Apple 提供的是UIApplication.shared.setAlternateIconName(_:completionHandler:)方法只允許你在 App 內(nèi)置的“備用圖標(biāo)集合”里做替換且每次切換都會彈窗提示用戶這張圖標(biāo)即將被替換。用戶點確認(rèn)后才生效。這意味著你不能在運行時通過網(wǎng)絡(luò)下載一張圖片當(dāng)圖標(biāo)必須在安裝包里預(yù)置所有可選圖標(biāo)。你的圖標(biāo)必須預(yù)聲明在 Info.plist 的CFBundleAlternateIcons字典里。替換圖標(biāo)時不能有透明通道Alpha 通道這是審核紅線很多人被拒都是栽在這里。同一個圖標(biāo)文件名一旦被系統(tǒng)緩存短時間內(nèi)頻繁切換可能不生效。從產(chǎn)品視角看iOS 的限制決定了你只能做“有限的動態(tài)”圖標(biāo)集合是固定的、由研發(fā)預(yù)置的服務(wù)端只能決定用哪一張不能決定上傳哪一張。這個差異一定要和運營同學(xué)提前對齊否則對方拿著 Android 版本的需求過來說“我要灰度測試 100 套圖標(biāo)”在 iOS 上這是不可能實現(xiàn)的。3.2 Info.plist 配置把備用圖標(biāo)登記在冊以 Xcode 工程為例打開 Info.plist 的 Source Code 視圖添加如下內(nèi)容keyCFBundleIcons/key dict keyCFBundlePrimaryIcon/key dict keyCFBundleIconFiles/key array stringAppIcon/string /array /dict keyCFBundleAlternateIcons/key dict keyNewYear/key dict keyCFBundleIconFiles/key array stringAppIconNewYear/string /array /dict keySummer/key dict keyCFBundleIconFiles/key array stringAppIconSummer/string /array /dict /dict /dictCFBundleAlternateIcons的 key 就是你自己定義的圖標(biāo)名NewYear、Summer這些名字后面會作為參數(shù)傳給系統(tǒng) API。CFBundleIconFiles數(shù)組里填的是 Assets.xcassets 里圖片集的名稱注意這個名稱不是物理文件名而是圖片集的 resource 名稱。這里有一個很隱蔽的坑如果 Assets.xcassets 中同時存在多個尺寸的同一圖標(biāo)比如 60pt、76pt、83.5pt系統(tǒng)會自行挑選合適尺寸你不需要手動指定。但如果你把圖標(biāo)直接作為獨立圖片文件丟進(jìn) Bundle而不是通過 Assets 管理就很容易出現(xiàn)“真機圖標(biāo)加載失敗退回原始圖標(biāo)”的情況。我在項目里統(tǒng)一改用 Assets 管理后這個問題就再沒出現(xiàn)過。3.3 切換代碼Objective-C 還是 Swift 都行iOS 端的切換邏輯更簡單因為系統(tǒng) API 封裝得很干凈。Objective-C 版本如下- (void)switchToIcon:(NSString *)iconName completion:(void (^)(BOOL success, NSError *error))completion { if (!iconName || iconName.length 0) { [UIApplication.sharedApplication setAlternateIconName:nil completionHandler:completion]; return; } [UIApplication.sharedApplication setAlternateIconName:iconName completionHandler:completion]; }傳nil表示切回主圖標(biāo)即CFBundlePrimaryIcon這是很多人會忽略的一個用法——你不需要定義一個“默認(rèn)圖標(biāo)”的備用名。Swift 版本邏輯完全相同UIApplication.shared.setAlternateIconName(iconName) { error in if let error error { print(切換失敗: \(error.localizedDescription)) } }從 Unity 側(cè)調(diào)用時通常把這段代碼放進(jìn)一個.mm文件里暴露給 C# 的 extern 方法。注意 Unity 的 iOS 插件機制.mm文件放到Plugins/iOS目錄C# 側(cè)用[DllImport(__Internal)]聲明即可。這個方法名稱要避免和系統(tǒng) API 同名防止符號沖突。3.4 審核注意事項Alpha 通道是最大雷區(qū)iOS 動態(tài)圖標(biāo)踩坑最多的地方就是圖標(biāo)素材的 Alpha 通道問題。Apple 明確要求備用圖標(biāo)不能包含透明像素否則上架審核會被拒被拒理由通常是“App icon cannot contain transparency”。這個問題在本地測試時還不一定能發(fā)現(xiàn)因為模擬器上看起來一切正常真機上也可能正常顯示但審核人員那邊一看到帶透明區(qū)域的圖標(biāo)直接打回。我的處理辦法是在做圖階段就要求美術(shù)導(dǎo)出 PNG 時去掉透明通道或統(tǒng)一填充純色背景后再交付。如果你拿到素材后發(fā)現(xiàn)確實帶透明區(qū)域可以用腳本來一次批量處理比如 Python 的 Pillow 庫把PIL.Image.open讀取后convert(RGB)強制去除 Alpha 通道。這一步建議納入 CI 或資產(chǎn)導(dǎo)出流水線人工手動檢查太容易漏。另外還有一條潛規(guī)則setAlternateIconName調(diào)用后系統(tǒng)彈窗要求用戶確認(rèn)而且每次調(diào)用之間建議間隔幾秒。如果游戲內(nèi)某個頁面頻繁觸發(fā)切換比如玩家瘋狂點擊換膚按鈕就會出現(xiàn)連續(xù)彈窗用戶體驗非常差。我在封裝層加了一個節(jié)流策略同一目標(biāo)圖標(biāo) 5 秒內(nèi)重復(fù)請求直接忽略避免連續(xù)彈窗。4. Unity 工程側(cè)的插件封裝與調(diào)用4.1 統(tǒng)一接口設(shè)計一套 C# API雙端分發(fā)雙端原生邏輯都做好了Unity 側(cè)要做的事是“屏蔽平臺差異”。我在項目里設(shè)計了一個靜態(tài)管理類DynamicIconManager對外只暴露兩個方法public static class DynamicIconManager { // 切到指定圖標(biāo)key 為預(yù)置圖標(biāo)名null 表示恢復(fù)默認(rèn) public static void SwitchIcon(string iconKey, System.Actionbool, string callback null) { if (string.IsNullOrEmpty(iconKey)) { RestoreDefaultIcon(callback); return; } #if UNITY_EDITOR Debug.Log($[DynamicIcon] Editor mode skip switch, target: {iconKey}); #elif UNITY_ANDROID AndroidIconManager.SwitchIcon(iconKey, callback); #elif UNITY_IOS IOSIconManager.SwitchIcon(iconKey, callback); #else Debug.LogWarning([DynamicIcon] Not supported platform); #endif } public static void RestoreDefaultIcon(System.Actionbool, string callback null) { SwitchIcon(null, callback); } }這樣設(shè)計的好處是業(yè)務(wù)層完全感知不到平臺差異。比如活動彈窗里有一個“換新裝扮圖標(biāo)”的按鈕業(yè)務(wù)腳本只需要這樣調(diào)public class NewYearActivity : MonoBehaviour { public void OnClickChangeIcon() { DynamicIconManager.SwitchIcon(NewYear, (success, msg) { if (success) { // 可以在這里彈個 Toast 或刷新 UI 狀態(tài) } else { Debug.LogWarning($換圖標(biāo)失敗: {msg}); } }); } }Android 和 iOS 的差異被完全隔離在這層抽象后面。但請注意這個抽象只能統(tǒng)一調(diào)用形式不能抹平能力邊界。比如 iOS 的彈窗確認(rèn)機制、Android 的桌面刷新延遲這些平臺特性還是要靠運營側(cè)和文檔去管控預(yù)期。4.2 Android 橋接增強支持多圖標(biāo)動態(tài)適配前面 Java 代碼演示的是固定兩個圖標(biāo)的情況但實際項目里往往有 46 個圖標(biāo)版本圖標(biāo)、活動圖標(biāo)、節(jié)日圖標(biāo)、默認(rèn)圖標(biāo)。這時再做useNewYear ? A : B這種判斷就太死板了。我重構(gòu)了一版用目標(biāo)圖標(biāo)名去 Manifest 里找對應(yīng) aliaspublic class IconSwitcher { public static void switchIcon(Context context, String iconKey) { String packageName context.getPackageName(); String targetAlias packageName .MainActivity_Alias_ iconKey; // 如果主圖標(biāo)對應(yīng)的 key 傳 Default則對應(yīng)的別名是 MainActivity_Alias_Default // 這一步需要讀取 Manifest 中已聲明的 alias避免把未注冊的組件名傳入 // 如果 target 不是當(dāng)前啟用的組件則啟用 target、禁用舊組件 // 具體實現(xiàn)可以通過 PackageManager.queryIntentActivities 動態(tài)查找也可以維護映射表 } }在具體實現(xiàn)中我傾向于維護一張映射表private static final MapString, String ALIAS_MAP new HashMap(); static { ALIAS_MAP.put(Default, .MainActivity_Alias_Default); ALIAS_MAP.put(NewYear, .MainActivity_Alias_NewYear); ALIAS_MAP.put(Summer, .MainActivity_Alias_Summer); // 每新增一個圖標(biāo)在這里登記 alias }這樣每次新增圖標(biāo)只需要三步美術(shù)出圖、Manifest 加一個 alias 節(jié)點、映射表加一行。要注意映射表中的 alias 名稱必須和 Manifest 里聲明的android:name完全一致多一個點少一個點都會導(dǎo)致ComponentName找不到組件切換直接失敗。還有一個經(jīng)驗之談動態(tài)切換前最好查詢當(dāng)前啟用的 alias避免重復(fù)設(shè)置同一個組件導(dǎo)致額外開銷?？梢杂肞ackageManager.getComponentEnabledSetting(componentName)拿到當(dāng)前狀態(tài)如果已經(jīng)是 ENABLED 就直接跳過。雖然設(shè)置同一個組件狀態(tài)不會報錯但多一次 Binder 調(diào)用在頻繁切換時會造成不必要的延遲。4.3 iOS 橋接增強正確傳參和回調(diào)iOS 側(cè)橋接時最容易出錯的是 C# 和 Objective-C 的字符串參數(shù)傳遞。C# 側(cè)聲明如下#if UNITY_IOS !UNITY_EDITOR [DllImport(__Internal)] private static extern void _switchAppIcon(string iconName, System.Actionint, string callback); #endifObjective-C 側(cè)實現(xiàn)void _switchAppIcon(const char *iconName, UnityCallback callback) { NSString *name iconName ? [NSString stringWithUTF8String:iconName] : nil; if (name.length 0) name nil; [[DynamicIconHelper sharedInstance] switchToIcon:name completion:^(BOOL success, NSError *error) { if (success) { callback(1, ok); } else { callback(0, error.localizedDescription.UTF8String ?: unknown); } }]; }這里必須小心 C# 回調(diào)函數(shù)的生命周期。System.Actionint, string傳給原生層時本質(zhì)上是一個函數(shù)指針如果 C# 側(cè)那個委托對象被 GC 回收了原生層再回調(diào)就會導(dǎo)致崩潰。穩(wěn)妥做法是在 C# 側(cè)用一個字典保存所有待回調(diào)的委托鍵可以是一個自增 ID原生層切換完成后再調(diào)用 C# 側(cè)的靜態(tài)方法取出委托并執(zhí)行。這種方法雖然繁瑣但抗風(fēng)險能力強不至于因為一個回調(diào)崩潰整個項目。4.4 資源與構(gòu)建圖標(biāo)素材進(jìn)包的正確姿勢Android 端所有圖標(biāo)資源必須放在modules/unityLibrary/src/main/res/mipmap-*目錄下Unity 打包時會合并進(jìn) APK/AAB。如果你用的是 Unity 2020 及以上版本還可以通過res目錄自定義資源。我把不同圖標(biāo)的 mipmap 資源做成一個獨立的 Android Library 模塊然后在 Unity 工程的build.gradle里依賴它。這樣做的優(yōu)勢是資源模塊可以獨立維護圖標(biāo)更新時不需要動 Unity 工程只需要重新構(gòu)建 aar。iOS 端所有備用圖標(biāo)要放進(jìn)主工程的Assets.xcassetsUnity 打包生成的 Xcode 工程中Assets.xcassets默認(rèn)位于Unity-iPhonetarget 名下。因為 Unity 打包時不會主動讀取你自定義的 Xcode 工程所以我的做法是iOS 橋接代碼和圖標(biāo)資源都放進(jìn)同一個 Unity 插件目錄Assets/Plugins/iOS其中.xcassets目錄會直接被 Unity 復(fù)制到生成的 Xcode 工程根目錄。只要你確認(rèn) Xcode 工程里Build Phase Copy Bundle Resources包含這組資源打包后就能正常訪問。這里有一個容易迷惑的點Assets.xcassets 是目錄不是文件。在 Unity 里往Plugins/iOS放的時候需要保留完整的.xcassets目錄結(jié)構(gòu)而不是只放里面的 PNG。Unity 對文件夾的復(fù)制是遞歸的所以沒有問題但版本控制時要注意.xcassets內(nèi)部的文件名盡量不要包含空格Xcode 能處理但容易出幺蛾子。5. 雙端實測經(jīng)驗與常見坑5.1 Android 桌面圖標(biāo)不刷新怎么辦這是 Android 端被問最多的問題我自己的實測結(jié)果是這樣的華為、小米、OPPO、vivo 等主流廠商的系統(tǒng) Launcher在組件啟用狀態(tài)變更后基本都能在 13 秒內(nèi)自動刷新圖標(biāo)但三星等海外機型上偶爾會出現(xiàn)調(diào)用完遲遲不更新的情況。這時候可以嘗試確認(rèn)調(diào)用成功檢查pm.getComponentEnabledSetting返回的新狀態(tài)是否已經(jīng)是 ENABLED。如果狀態(tài)沒變說明我們的包名或 alias 拼接有誤。強制刷新桌面通過startActivity觸發(fā)CATEGORY_HOME目的意的變化或者直接鎖屏再點亮屏幕多數(shù) Launcher 會重新讀取應(yīng)用列表。確認(rèn)沒有多入口殘留如果原有 Activity 和 alias 同時帶 LAUNCHER桌面會顯示兩個入口導(dǎo)致新圖標(biāo)的 alias 雖然切換成功了但用戶看到的是舊入口的圖標(biāo)。這個前面已經(jīng)強調(diào)過再重點重復(fù)一遍主 Activity 不能帶 LAUNCHER只讓 alias 帶。5.2 iOS 切圖標(biāo)后沒有變化、系統(tǒng)彈窗消失iOS 上最常見的現(xiàn)象是調(diào)用setAlternateIconName后彈窗出現(xiàn)又立刻消失桌面圖標(biāo)沒變。排查方向有兩個一是圖標(biāo)名傳錯了。setAlternateIconName的參數(shù)是CFBundleAlternateIcons字典的 key不是圖片集名字。我見過有同事把AppIconNewYear圖片集名當(dāng)參數(shù)傳進(jìn)去結(jié)果系統(tǒng)找不到對應(yīng)的備用圖標(biāo)名只能彈窗然后失敗。傳參應(yīng)該是NewYear。二是圖標(biāo)資源格式問題。如果有透明通道系統(tǒng)在處理時可能直接忽略請求。把圖片重新導(dǎo)出去掉 Alpha 通道后重試。還有一個 iOS 獨有的怪問題當(dāng)你連續(xù)快速調(diào)用切換 API 時系統(tǒng)可能只保留最后一次請求中間的彈窗全部被跳過。如果運營配置的活動頁有多個換膚入口務(wù)必做好節(jié)流和冪等目標(biāo)圖標(biāo)相同就不要再調(diào)用。5.3 圖標(biāo)切換與游戲內(nèi)狀態(tài)的同步功能上線前記得處理一個問題圖標(biāo)切換成功后游戲內(nèi)的“當(dāng)前圖標(biāo)狀態(tài)”UI 怎么同步比如玩家在設(shè)置頁看到“當(dāng)前圖標(biāo)春節(jié)版”切換成功后按鈕要變?yōu)橹没一蝻@示“已啟用”。這個狀態(tài)不要只靠本地記錄因為用戶可能殺進(jìn)程重進(jìn)或者系統(tǒng)恢復(fù)組件狀態(tài)極少見但存在。我的做法是切換成功回調(diào)里更新本地 PlayerPrefs每次進(jìn)入游戲時再調(diào)用原生查詢接口Android 用getComponentEnabledSetting反向推斷當(dāng)前啟用的是哪個 aliasiOS 用UIApplication.shared.alternateIconName獲取當(dāng)前備用圖標(biāo)名。這樣即使本地緩存被清掉UI 狀態(tài)依然能和系統(tǒng)真實狀態(tài)保持一致。封裝一個查詢接口到 C# 層其實很簡單public static string GetCurrentIconKey() { #if UNITY_ANDROID return AndroidIconManager.GetCurrentIconKey(); #elif UNITY_IOS return IOSIconManager.GetCurrentIconKey(); #else return Default; #endif }5.4 版本更新后的圖標(biāo)殘留問題有一種邊界情況要特別留意用戶安裝了舊版本圖標(biāo)被切到“春節(jié)版”然后游戲更新到新版本Manifest 里 alias 結(jié)構(gòu)調(diào)整或者把“春節(jié)版”圖標(biāo)刪掉了。這時桌面圖標(biāo)可能加載失敗顯示系統(tǒng)默認(rèn)圖標(biāo)。雖然概率不高但一旦出現(xiàn)用戶會認(rèn)為 App 壞了。避免這個問題的思路是版本升級時如果服務(wù)端下發(fā)布置要讓所有用戶回退到默認(rèn)圖標(biāo)客戶端可以在啟動階段檢測到新版本號后主動調(diào)用一次恢復(fù)默認(rèn)圖標(biāo)。但這里有個矛盾用戶還沒打開游戲你怎么讓他執(zhí)行恢復(fù)答案是無法預(yù)先恢復(fù)只能確保新版本中Defaultalias 是啟用的、舊 alias 不存在導(dǎo)致系統(tǒng)回退到主圖標(biāo)。我的建議是盡量不要移除舊 alias即使圖標(biāo)資源廢棄了也保留一個不使用的 alias 聲明防止升級時桌面圖標(biāo)崩潰。這與代碼重構(gòu)的直覺相反但在動態(tài)圖標(biāo)的場景下是實用經(jīng)驗。6. 集成流程與上線檢查清單最后整理一下從需求到上線的完整流程方便你直接照著排期。第一步需求評審階段。和運營確認(rèn)圖標(biāo)集合是否固定Android 端是否允許服務(wù)端下發(fā)任意 key 切換可以做動態(tài)拉取配置iOS 端是否接受系統(tǒng)彈窗確認(rèn)的限制這里必須讓運營在文檔上簽字確認(rèn)不然后面天天扯皮。第二步資源準(zhǔn)備階段。美術(shù)輸出所有圖標(biāo)必須包含不同尺寸Android 通用 mipmap 建議至少做 mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi 五檔iOS 讓 Xcode 自動適配 AppIcon 尺寸。美術(shù)輸出時就要確認(rèn) iOS 圖標(biāo)無透明通道。這一步我會寫一個小腳本做校驗掃描所有 PNG 的 Alpha 信息發(fā)現(xiàn)透明直接報錯。第三步原生封裝與聯(lián)調(diào)階段。Android 寫IconSwitcher.javaiOS 寫DynamicIconHelper.mmUnity 側(cè)寫DynamicIconManager.cs。先用 Unity Editor 模式跑通“假切換”邏輯再用真機驗證 Android 和 iOS。真機聯(lián)調(diào)階段至少覆蓋切默認(rèn)到活動、活動切回默認(rèn)、活動之間互切、切換后殺進(jìn)程重進(jìn)、弱網(wǎng)下連續(xù)切換。第四步服務(wù)端接入階段。如果要做服務(wù)端動態(tài)下發(fā)格式建議這樣{ iconKey: NewYear, startTime: 1704038400, endTime: 1706716800 }客戶端啟動時拉取配置如果當(dāng)前時間在時間段內(nèi)且 iconKey 存在則調(diào)用切換超過 endTime 則恢復(fù)默認(rèn)圖標(biāo)。建議客戶端本地緩存這份配置避免每次啟動都強依賴網(wǎng)絡(luò)同時要處理“切換失敗”的降級邏輯不要影響正常游戲流程切換失敗只在日志里打 Warning。第五步上線檢查清單。整理了一份簡要表格檢查項AndroidiOS圖標(biāo)素材已入包檢查 mipmap 資源是否齊全確認(rèn) Assets.xcassets 已打包Manifest/Info.plist 預(yù)聲明alias 全部聲明且只有一個啟用的CFBundleAlternateIcons 字典完整主入口無 LAUNCHER主 Activity 不帶 LAUNCHER不涉及切換邏輯真機驗證主流 ROM 各測一輪真機驗證彈窗與圖標(biāo)刷新恢復(fù)默認(rèn)路徑確認(rèn) Default alias 可恢復(fù)傳 nil 可恢復(fù)打包后資源檢查解包 APK/AAB 看 res看 Xcode 工程內(nèi) Copy Bundle Resources這套流程走下來雙端動態(tài)換圖標(biāo)的核心功能就已經(jīng)完成了。整個方案的復(fù)雜度主要集中在原生層和平臺差異處理上Unity 側(cè)的代碼量其實不大。只要把各端的坑提前埋好雷排掉后面運營每次做活動要換圖標(biāo)時你只需要讓美術(shù)出一套圖、服務(wù)端加一條配置客戶端一行代碼都不用改這件事就能非常優(yōu)雅地滾動起來。這也是我為什么推薦提前做好映射表和通用調(diào)用層的原因功能的價值不在首版跑通而在后續(xù)每次活動都能低成本復(fù)用。 Unity游戲動態(tài)更換App圖標(biāo)：Android與iOS雙端實現(xiàn)全解析
1. 為什么要做動態(tài)圖標(biāo)需求場景與方案選型做游戲運營的朋友一定深有體會版本更新、節(jié)日活動、聯(lián)動 IP 上線都是拉新和召回的關(guān)鍵節(jié)點。App 在桌面上的圖標(biāo)其實是用戶每天打開手機第一眼就看到的核心廣告位成本為零但觸達(dá)率是百分之百。很多手游團隊都會想能不能讓這個圖標(biāo)跟著運營節(jié)奏走比如春節(jié)換成喜慶的紅色主題新版本換成新角色立繪活動結(jié)束再一鍵換回原版。這就是“動態(tài)更換 App 圖標(biāo)”最典型的落地場景。Unity 開發(fā)者接到這個需求時第一反應(yīng)往往是頭疼。因為 Unity 引擎本身并沒有提供“運行時切換圖標(biāo)”的接口這件事繞不開原生層。Android 和 iOS 兩套系統(tǒng)對圖標(biāo)切換的開放程度完全不同Android 靠的是 Activity 別名activity-alias加組件開關(guān)理論上可以任意切換、隨意切換iOS 則從 iOS 10.3 開始提供了系統(tǒng)級的setAlternateIconNameAPI但限制不少比如圖標(biāo)不能帶透明通道每次切換還會彈系統(tǒng)確認(rèn)框。所以接到這個需求第一步不是急著寫代碼而是弄清楚你到底要哪種“動態(tài)”。如果只是包體打多個圖標(biāo)、安裝后用戶手動換那 Android 用 Launcher 圖標(biāo)本身就支持iOS 也能靠描述文件做到但這些都算不上真正的“動態(tài)”。本文討論的“動態(tài)”是指游戲運行過程中客戶端向服務(wù)端請求配置拿到目標(biāo)圖標(biāo)名之后調(diào)用原生接口直接把桌面圖標(biāo)換掉玩家不需要重新安裝 App。這套方案的技術(shù)棧涉及 Unity 與原生交互、雙端平臺差異、系統(tǒng)資源文件打包三塊內(nèi)容。適合已經(jīng)具備一定 Unity 工程經(jīng)驗的開發(fā)者參考你要看得懂 AndroidManifest.xml能寫簡單的 Objective-C 或 Swift知道怎么打 Android 的 aar 和 iOS 的 framework。如果這些還不熟也沒關(guān)系下面每個步驟我都會把原理講清楚照著做也能跑通。方案選型上我最終采用的是“原生能力封裝 Unity 統(tǒng)一調(diào)用層”的結(jié)構(gòu)。Android 端使用PackageManager.setComponentEnabledSetting切換兩個 activity-alias 的啟用狀態(tài)iOS 端使用UIApplication.shared.setAlternateIconNameUnity 側(cè)寫一個 C# 管理器通過 AndroidJavaObject 和 Objective-C 插件分別橋接。這樣設(shè)計的原因是動態(tài)圖標(biāo)的邏輯本質(zhì)上屬于“平臺強相關(guān)”功能如果試圖在 C# 層做統(tǒng)一抽象反而會因為系統(tǒng)差異過大致使抽象層漏洞百出不如各端各做各的只暴露兩個同名接口給上層。2. Android 端實現(xiàn)基于 activity-alias 的動態(tài)切換2.1 核心原理一個圖標(biāo)就是一個可開關(guān)的組件Android 桌面上每個 App 圖標(biāo)本質(zhì)上都對應(yīng)一個入口組件通常是帶MAIN和LAUNCHER意圖過濾器的 Activity或者指向某個 Activity 的activity-alias?！白烂鎴D標(biāo)”和“Activity 組件”的關(guān)系可以理解成快捷方式與目標(biāo)程序的關(guān)系桌面上那個圖標(biāo)只是指向 Activity 的一個殼。activity-alias的作用就是給同一個 Activity 再起一個“馬甲”。系統(tǒng)允許你在 Manifest 里給同一個 Activity 配置多個別名每個別名都可以擁有自己的圖標(biāo)和標(biāo)簽。默認(rèn)情況下哪個別名是啟用狀態(tài)桌面上就顯示哪個圖標(biāo)。關(guān)鍵來了通過PackageManager.setComponentEnabledSetting你可以在運行時把某個別名禁用、把另一個別名啟用。組件狀態(tài)一變系統(tǒng)會發(fā)出廣播Launcher 收到后刷新桌面圖標(biāo)。這就是 Android 動態(tài)換圖標(biāo)的底層邏輯不需要替換任何圖片資源只是切換組件的啟用/禁用狀態(tài)本質(zhì)是“換入口”。2.2 Manifest 配置兩個 alias一個 Activity先看一段我實際在項目中使用的 Manifest 配置application android:allowBackuptrue android:iconmipmap/ic_launcher android:labelstring/app_name activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity activity-alias android:name.MainActivity_Alias_Default android:enabledtrue android:exportedtrue android:iconmipmap/ic_launcher android:labelstring/app_name android:targetActivity.MainActivity intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity-alias activity-alias android:name.MainActivity_Alias_NewYear android:enabledfalse android:exportedtrue android:iconmipmap/ic_launcher_newyear android:labelstring/app_name_newyear android:targetActivity.MainActivity intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity-alias /application這里有個非常容易踩的坑主 Activity 本身不能同時帶 LAUNCHER 的 intent-filter否則系統(tǒng)會認(rèn)為 App 有兩個入口桌面會出現(xiàn)兩個圖標(biāo)或者切換失效。正確做法是主 Activity 只保留默認(rèn)的 MAIN 意圖真正的桌面入口全部由 alias 承擔(dān)。我在前期調(diào)研時看到不少團隊的代碼圖省事讓 Activity 自己和 alias 都帶 LAUNCHER結(jié)果就是每次切換后桌面殘留兩個圖標(biāo)玩家體驗極其糟糕。每個 alias 的android:icon指向不同的 mipmap 資源android:label可以順便連應(yīng)用名一起換。注意資源名要提前在 res 目錄下準(zhǔn)備好不能運行時動態(tài)指定不存在的資源。icon 資源本身建議用自適應(yīng)圖標(biāo)Adaptive Icon即mipmap-anydpi-v26目錄下同時配置前景和背景這樣切到不同圖標(biāo)時在不同廠商桌面上都能保持統(tǒng)一形狀。2.3 運行時切換代碼Java 層寫什么切換邏輯的核心代碼并不長我把它封裝在一個名為IconSwitcher.java的文件里public class IconSwitcher { private static final String ALIAS_DEFAULT .MainActivity_Alias_Default; private static final String ALIAS_NEW_YEAR .MainActivity_Alias_NewYear; public static void switchIcon(Context context, boolean useNewYear) { String targetAlias useNewYear ? ALIAS_NEW_YEAR : ALIAS_DEFAULT; String activeAlias useNewYear ? ALIAS_DEFAULT : ALIAS_NEW_YEAR; PackageManager pm context.getPackageManager(); ComponentName targetName new ComponentName(context.getPackageName(), context.getPackageName() targetAlias); ComponentName activeName new ComponentName(context.getPackageName(), context.getPackageName() activeAlias); pm.setComponentEnabledSetting( targetName, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP ); pm.setComponentEnabledSetting( activeName, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP ); } }注意ComponentName的構(gòu)造如果在 Manifest 里寫的是.MainActivity_Alias_Default那么 Java 側(cè)拼接時前面帶點new ComponentName(context, context.getPackageName() aliasName)。這里用context.getPackageName()獲取應(yīng)用包名不要硬編碼避免不同渠道包改寫包名后失效。DONT_KILL_APP標(biāo)志的意思是切換組件狀態(tài)時不要殺掉應(yīng)用進(jìn)程。因為動態(tài)換圖標(biāo)往往發(fā)生在游戲運行中比如玩家在活動頁面點了“換膚”按鈕你當(dāng)然不希望切換完游戲被系統(tǒng)殺掉。但要注意setComponentEnabledSetting本身是異步的調(diào)用后系統(tǒng)需要一點時間刷新桌面圖標(biāo)正常情況下 12 秒內(nèi)生效。如果你發(fā)現(xiàn)調(diào)用后桌面遲遲不刷新可以在切換后加一句Intent intent new Intent(Intent.ACTION_MAIN); intent.addCategory(Intent.CATEGORY_HOME); context.startActivity(intent);這一招是讓桌面重新布局、觸發(fā)圖標(biāo)刷新的常見土辦法。不過實測中大多數(shù)主流 Launcher 不調(diào)用也能自動刷新倒是部分深度定制的 ROM 需要這個額外觸發(fā)。2.4 從 Unity 調(diào)用AndroidJavaObject 與原生橋接Unity 側(cè)的調(diào)用特別簡單因為只涉及靜態(tài)方法。我在 C# 里寫了一個AndroidIconManagerpublic class AndroidIconManager { private static readonly string ClassName com.yourgame.nativebridge.IconSwitcher; public static void SwitchIcon(bool useNewYear) { #if UNITY_ANDROID !UNITY_EDITOR using (var jc new AndroidJavaClass(ClassName)) { jc.CallStatic(switchIcon, GetUnityActivity(), useNewYear); } #endif } private static AndroidJavaObject GetUnityActivity() { using (var unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer)) { return unityPlayer.GetStaticAndroidJavaObject(currentActivity); } } }這里有一個容易忽略的細(xì)節(jié)方法參數(shù)Context context在 Unity 側(cè)傳的是UnityPlayer.currentActivity。我們把 Activity 實例傳給原生層是因為setComponentEnabledSetting需要 Context而 Activity 本身就是 Context。如果你忘了傳直接在非 Activity 的 Context 下切換部分 ROM 上可能不會刷新圖標(biāo)。原生代碼封裝成 aar 后放到 Unity 工程的Plugins/Android目錄下即可。要提醒一點IconSwitcher類所在的包名和 Unity 工程的com.company.product包名可以不一致但這時context.getPackageName()返回的一定是 Unity 應(yīng)用的包名而不是靜態(tài)類所在包的包名。也就是說無論原生橋接代碼放在哪個包最終操作的對象都是 Unity 入口 Activity 和 Manifest 里聲明的組件這一點不會錯。3. iOS 端實現(xiàn)系統(tǒng) API 與 Info.plist 配合3.1 iOS 的限制為什么 Apple 的“動態(tài)”這么保守如果說 Android 的動態(tài)圖標(biāo)是一把自由開關(guān)那 iOS 就是一把帶安全鎖的鑰匙。Apple 提供的是UIApplication.shared.setAlternateIconName(_:completionHandler:)方法只允許你在 App 內(nèi)置的“備用圖標(biāo)集合”里做替換且每次切換都會彈窗提示用戶這張圖標(biāo)即將被替換。用戶點確認(rèn)后才生效。這意味著你不能在運行時通過網(wǎng)絡(luò)下載一張圖片當(dāng)圖標(biāo)必須在安裝包里預(yù)置所有可選圖標(biāo)。你的圖標(biāo)必須預(yù)聲明在 Info.plist 的CFBundleAlternateIcons字典里。替換圖標(biāo)時不能有透明通道Alpha 通道這是審核紅線很多人被拒都是栽在這里。同一個圖標(biāo)文件名一旦被系統(tǒng)緩存短時間內(nèi)頻繁切換可能不生效。從產(chǎn)品視角看iOS 的限制決定了你只能做“有限的動態(tài)”圖標(biāo)集合是固定的、由研發(fā)預(yù)置的服務(wù)端只能決定用哪一張不能決定上傳哪一張。這個差異一定要和運營同學(xué)提前對齊否則對方拿著 Android 版本的需求過來說“我要灰度測試 100 套圖標(biāo)”在 iOS 上這是不可能實現(xiàn)的。3.2 Info.plist 配置把備用圖標(biāo)登記在冊以 Xcode 工程為例打開 Info.plist 的 Source Code 視圖添加如下內(nèi)容keyCFBundleIcons/key dict keyCFBundlePrimaryIcon/key dict keyCFBundleIconFiles/key array stringAppIcon/string /array /dict keyCFBundleAlternateIcons/key dict keyNewYear/key dict keyCFBundleIconFiles/key array stringAppIconNewYear/string /array /dict keySummer/key dict keyCFBundleIconFiles/key array stringAppIconSummer/string /array /dict /dict /dictCFBundleAlternateIcons的 key 就是你自己定義的圖標(biāo)名NewYear、Summer這些名字后面會作為參數(shù)傳給系統(tǒng) API。CFBundleIconFiles數(shù)組里填的是 Assets.xcassets 里圖片集的名稱注意這個名稱不是物理文件名而是圖片集的 resource 名稱。這里有一個很隱蔽的坑如果 Assets.xcassets 中同時存在多個尺寸的同一圖標(biāo)比如 60pt、76pt、83.5pt系統(tǒng)會自行挑選合適尺寸你不需要手動指定。但如果你把圖標(biāo)直接作為獨立圖片文件丟進(jìn) Bundle而不是通過 Assets 管理就很容易出現(xiàn)“真機圖標(biāo)加載失敗退回原始圖標(biāo)”的情況。我在項目里統(tǒng)一改用 Assets 管理后這個問題就再沒出現(xiàn)過。3.3 切換代碼Objective-C 還是 Swift 都行iOS 端的切換邏輯更簡單因為系統(tǒng) API 封裝得很干凈。Objective-C 版本如下- (void)switchToIcon:(NSString *)iconName completion:(void (^)(BOOL success, NSError *error))completion { if (!iconName || iconName.length 0) { [UIApplication.sharedApplication setAlternateIconName:nil completionHandler:completion]; return; } [UIApplication.sharedApplication setAlternateIconName:iconName completionHandler:completion]; }傳nil表示切回主圖標(biāo)即CFBundlePrimaryIcon這是很多人會忽略的一個用法——你不需要定義一個“默認(rèn)圖標(biāo)”的備用名。Swift 版本邏輯完全相同UIApplication.shared.setAlternateIconName(iconName) { error in if let error error { print(切換失敗: \(error.localizedDescription)) } }從 Unity 側(cè)調(diào)用時通常把這段代碼放進(jìn)一個.mm文件里暴露給 C# 的 extern 方法。注意 Unity 的 iOS 插件機制.mm文件放到Plugins/iOS目錄C# 側(cè)用[DllImport(__Internal)]聲明即可。這個方法名稱要避免和系統(tǒng) API 同名防止符號沖突。3.4 審核注意事項Alpha 通道是最大雷區(qū)iOS 動態(tài)圖標(biāo)踩坑最多的地方就是圖標(biāo)素材的 Alpha 通道問題。Apple 明確要求備用圖標(biāo)不能包含透明像素否則上架審核會被拒被拒理由通常是“App icon cannot contain transparency”。這個問題在本地測試時還不一定能發(fā)現(xiàn)因為模擬器上看起來一切正常真機上也可能正常顯示但審核人員那邊一看到帶透明區(qū)域的圖標(biāo)直接打回。我的處理辦法是在做圖階段就要求美術(shù)導(dǎo)出 PNG 時去掉透明通道或統(tǒng)一填充純色背景后再交付。如果你拿到素材后發(fā)現(xiàn)確實帶透明區(qū)域可以用腳本來一次批量處理比如 Python 的 Pillow 庫把PIL.Image.open讀取后convert(RGB)強制去除 Alpha 通道。這一步建議納入 CI 或資產(chǎn)導(dǎo)出流水線人工手動檢查太容易漏。另外還有一條潛規(guī)則setAlternateIconName調(diào)用后系統(tǒng)彈窗要求用戶確認(rèn)而且每次調(diào)用之間建議間隔幾秒。如果游戲內(nèi)某個頁面頻繁觸發(fā)切換比如玩家瘋狂點擊換膚按鈕就會出現(xiàn)連續(xù)彈窗用戶體驗非常差。我在封裝層加了一個節(jié)流策略同一目標(biāo)圖標(biāo) 5 秒內(nèi)重復(fù)請求直接忽略避免連續(xù)彈窗。4. Unity 工程側(cè)的插件封裝與調(diào)用4.1 統(tǒng)一接口設(shè)計一套 C# API雙端分發(fā)雙端原生邏輯都做好了Unity 側(cè)要做的事是“屏蔽平臺差異”。我在項目里設(shè)計了一個靜態(tài)管理類DynamicIconManager對外只暴露兩個方法public static class DynamicIconManager { // 切到指定圖標(biāo)key 為預(yù)置圖標(biāo)名null 表示恢復(fù)默認(rèn) public static void SwitchIcon(string iconKey, System.Actionbool, string callback null) { if (string.IsNullOrEmpty(iconKey)) { RestoreDefaultIcon(callback); return; } #if UNITY_EDITOR Debug.Log($[DynamicIcon] Editor mode skip switch, target: {iconKey}); #elif UNITY_ANDROID AndroidIconManager.SwitchIcon(iconKey, callback); #elif UNITY_IOS IOSIconManager.SwitchIcon(iconKey, callback); #else Debug.LogWarning([DynamicIcon] Not supported platform); #endif } public static void RestoreDefaultIcon(System.Actionbool, string callback null) { SwitchIcon(null, callback); } }這樣設(shè)計的好處是業(yè)務(wù)層完全感知不到平臺差異。比如活動彈窗里有一個“換新裝扮圖標(biāo)”的按鈕業(yè)務(wù)腳本只需要這樣調(diào)public class NewYearActivity : MonoBehaviour { public void OnClickChangeIcon() { DynamicIconManager.SwitchIcon(NewYear, (success, msg) { if (success) { // 可以在這里彈個 Toast 或刷新 UI 狀態(tài) } else { Debug.LogWarning($換圖標(biāo)失敗: {msg}); } }); } }Android 和 iOS 的差異被完全隔離在這層抽象后面。但請注意這個抽象只能統(tǒng)一調(diào)用形式不能抹平能力邊界。比如 iOS 的彈窗確認(rèn)機制、Android 的桌面刷新延遲這些平臺特性還是要靠運營側(cè)和文檔去管控預(yù)期。4.2 Android 橋接增強支持多圖標(biāo)動態(tài)適配前面 Java 代碼演示的是固定兩個圖標(biāo)的情況但實際項目里往往有 46 個圖標(biāo)版本圖標(biāo)、活動圖標(biāo)、節(jié)日圖標(biāo)、默認(rèn)圖標(biāo)。這時再做useNewYear ? A : B這種判斷就太死板了。我重構(gòu)了一版用目標(biāo)圖標(biāo)名去 Manifest 里找對應(yīng) aliaspublic class IconSwitcher { public static void switchIcon(Context context, String iconKey) { String packageName context.getPackageName(); String targetAlias packageName .MainActivity_Alias_ iconKey; // 如果主圖標(biāo)對應(yīng)的 key 傳 Default則對應(yīng)的別名是 MainActivity_Alias_Default // 這一步需要讀取 Manifest 中已聲明的 alias避免把未注冊的組件名傳入 // 如果 target 不是當(dāng)前啟用的組件則啟用 target、禁用舊組件 // 具體實現(xiàn)可以通過 PackageManager.queryIntentActivities 動態(tài)查找也可以維護映射表 } }在具體實現(xiàn)中我傾向于維護一張映射表private static final MapString, String ALIAS_MAP new HashMap(); static { ALIAS_MAP.put(Default, .MainActivity_Alias_Default); ALIAS_MAP.put(NewYear, .MainActivity_Alias_NewYear); ALIAS_MAP.put(Summer, .MainActivity_Alias_Summer); // 每新增一個圖標(biāo)在這里登記 alias }這樣每次新增圖標(biāo)只需要三步美術(shù)出圖、Manifest 加一個 alias 節(jié)點、映射表加一行。要注意映射表中的 alias 名稱必須和 Manifest 里聲明的android:name完全一致多一個點少一個點都會導(dǎo)致ComponentName找不到組件切換直接失敗。還有一個經(jīng)驗之談動態(tài)切換前最好查詢當(dāng)前啟用的 alias避免重復(fù)設(shè)置同一個組件導(dǎo)致額外開銷?？梢杂肞ackageManager.getComponentEnabledSetting(componentName)拿到當(dāng)前狀態(tài)如果已經(jīng)是 ENABLED 就直接跳過。雖然設(shè)置同一個組件狀態(tài)不會報錯但多一次 Binder 調(diào)用在頻繁切換時會造成不必要的延遲。4.3 iOS 橋接增強正確傳參和回調(diào)iOS 側(cè)橋接時最容易出錯的是 C# 和 Objective-C 的字符串參數(shù)傳遞。C# 側(cè)聲明如下#if UNITY_IOS !UNITY_EDITOR [DllImport(__Internal)] private static extern void _switchAppIcon(string iconName, System.Actionint, string callback); #endifObjective-C 側(cè)實現(xiàn)void _switchAppIcon(const char *iconName, UnityCallback callback) { NSString *name iconName ? [NSString stringWithUTF8String:iconName] : nil; if (name.length 0) name nil; [[DynamicIconHelper sharedInstance] switchToIcon:name completion:^(BOOL success, NSError *error) { if (success) { callback(1, ok); } else { callback(0, error.localizedDescription.UTF8String ?: unknown); } }]; }這里必須小心 C# 回調(diào)函數(shù)的生命周期。System.Actionint, string傳給原生層時本質(zhì)上是一個函數(shù)指針如果 C# 側(cè)那個委托對象被 GC 回收了原生層再回調(diào)就會導(dǎo)致崩潰。穩(wěn)妥做法是在 C# 側(cè)用一個字典保存所有待回調(diào)的委托鍵可以是一個自增 ID原生層切換完成后再調(diào)用 C# 側(cè)的靜態(tài)方法取出委托并執(zhí)行。這種方法雖然繁瑣但抗風(fēng)險能力強不至于因為一個回調(diào)崩潰整個項目。4.4 資源與構(gòu)建圖標(biāo)素材進(jìn)包的正確姿勢Android 端所有圖標(biāo)資源必須放在modules/unityLibrary/src/main/res/mipmap-*目錄下Unity 打包時會合并進(jìn) APK/AAB。如果你用的是 Unity 2020 及以上版本還可以通過res目錄自定義資源。我把不同圖標(biāo)的 mipmap 資源做成一個獨立的 Android Library 模塊然后在 Unity 工程的build.gradle里依賴它。這樣做的優(yōu)勢是資源模塊可以獨立維護圖標(biāo)更新時不需要動 Unity 工程只需要重新構(gòu)建 aar。iOS 端所有備用圖標(biāo)要放進(jìn)主工程的Assets.xcassetsUnity 打包生成的 Xcode 工程中Assets.xcassets默認(rèn)位于Unity-iPhonetarget 名下。因為 Unity 打包時不會主動讀取你自定義的 Xcode 工程所以我的做法是iOS 橋接代碼和圖標(biāo)資源都放進(jìn)同一個 Unity 插件目錄Assets/Plugins/iOS其中.xcassets目錄會直接被 Unity 復(fù)制到生成的 Xcode 工程根目錄。只要你確認(rèn) Xcode 工程里Build Phase Copy Bundle Resources包含這組資源打包后就能正常訪問。這里有一個容易迷惑的點Assets.xcassets 是目錄不是文件。在 Unity 里往Plugins/iOS放的時候需要保留完整的.xcassets目錄結(jié)構(gòu)而不是只放里面的 PNG。Unity 對文件夾的復(fù)制是遞歸的所以沒有問題但版本控制時要注意.xcassets內(nèi)部的文件名盡量不要包含空格Xcode 能處理但容易出幺蛾子。5. 雙端實測經(jīng)驗與常見坑5.1 Android 桌面圖標(biāo)不刷新怎么辦這是 Android 端被問最多的問題我自己的實測結(jié)果是這樣的華為、小米、OPPO、vivo 等主流廠商的系統(tǒng) Launcher在組件啟用狀態(tài)變更后基本都能在 13 秒內(nèi)自動刷新圖標(biāo)但三星等海外機型上偶爾會出現(xiàn)調(diào)用完遲遲不更新的情況。這時候可以嘗試確認(rèn)調(diào)用成功檢查pm.getComponentEnabledSetting返回的新狀態(tài)是否已經(jīng)是 ENABLED。如果狀態(tài)沒變說明我們的包名或 alias 拼接有誤。強制刷新桌面通過startActivity觸發(fā)CATEGORY_HOME目的意的變化或者直接鎖屏再點亮屏幕多數(shù) Launcher 會重新讀取應(yīng)用列表。確認(rèn)沒有多入口殘留如果原有 Activity 和 alias 同時帶 LAUNCHER桌面會顯示兩個入口導(dǎo)致新圖標(biāo)的 alias 雖然切換成功了但用戶看到的是舊入口的圖標(biāo)。這個前面已經(jīng)強調(diào)過再重點重復(fù)一遍主 Activity 不能帶 LAUNCHER只讓 alias 帶。5.2 iOS 切圖標(biāo)后沒有變化、系統(tǒng)彈窗消失iOS 上最常見的現(xiàn)象是調(diào)用setAlternateIconName后彈窗出現(xiàn)又立刻消失桌面圖標(biāo)沒變。排查方向有兩個一是圖標(biāo)名傳錯了。setAlternateIconName的參數(shù)是CFBundleAlternateIcons字典的 key不是圖片集名字。我見過有同事把AppIconNewYear圖片集名當(dāng)參數(shù)傳進(jìn)去結(jié)果系統(tǒng)找不到對應(yīng)的備用圖標(biāo)名只能彈窗然后失敗。傳參應(yīng)該是NewYear。二是圖標(biāo)資源格式問題。如果有透明通道系統(tǒng)在處理時可能直接忽略請求。把圖片重新導(dǎo)出去掉 Alpha 通道后重試。還有一個 iOS 獨有的怪問題當(dāng)你連續(xù)快速調(diào)用切換 API 時系統(tǒng)可能只保留最后一次請求中間的彈窗全部被跳過。如果運營配置的活動頁有多個換膚入口務(wù)必做好節(jié)流和冪等目標(biāo)圖標(biāo)相同就不要再調(diào)用。5.3 圖標(biāo)切換與游戲內(nèi)狀態(tài)的同步功能上線前記得處理一個問題圖標(biāo)切換成功后游戲內(nèi)的“當(dāng)前圖標(biāo)狀態(tài)”UI 怎么同步比如玩家在設(shè)置頁看到“當(dāng)前圖標(biāo)春節(jié)版”切換成功后按鈕要變?yōu)橹没一蝻@示“已啟用”。這個狀態(tài)不要只靠本地記錄因為用戶可能殺進(jìn)程重進(jìn)或者系統(tǒng)恢復(fù)組件狀態(tài)極少見但存在。我的做法是切換成功回調(diào)里更新本地 PlayerPrefs每次進(jìn)入游戲時再調(diào)用原生查詢接口Android 用getComponentEnabledSetting反向推斷當(dāng)前啟用的是哪個 aliasiOS 用UIApplication.shared.alternateIconName獲取當(dāng)前備用圖標(biāo)名。這樣即使本地緩存被清掉UI 狀態(tài)依然能和系統(tǒng)真實狀態(tài)保持一致。封裝一個查詢接口到 C# 層其實很簡單public static string GetCurrentIconKey() { #if UNITY_ANDROID return AndroidIconManager.GetCurrentIconKey(); #elif UNITY_IOS return IOSIconManager.GetCurrentIconKey(); #else return Default; #endif }5.4 版本更新后的圖標(biāo)殘留問題有一種邊界情況要特別留意用戶安裝了舊版本圖標(biāo)被切到“春節(jié)版”然后游戲更新到新版本Manifest 里 alias 結(jié)構(gòu)調(diào)整或者把“春節(jié)版”圖標(biāo)刪掉了。這時桌面圖標(biāo)可能加載失敗顯示系統(tǒng)默認(rèn)圖標(biāo)。雖然概率不高但一旦出現(xiàn)用戶會認(rèn)為 App 壞了。避免這個問題的思路是版本升級時如果服務(wù)端下發(fā)布置要讓所有用戶回退到默認(rèn)圖標(biāo)客戶端可以在啟動階段檢測到新版本號后主動調(diào)用一次恢復(fù)默認(rèn)圖標(biāo)。但這里有個矛盾用戶還沒打開游戲你怎么讓他執(zhí)行恢復(fù)答案是無法預(yù)先恢復(fù)只能確保新版本中Defaultalias 是啟用的、舊 alias 不存在導(dǎo)致系統(tǒng)回退到主圖標(biāo)。我的建議是盡量不要移除舊 alias即使圖標(biāo)資源廢棄了也保留一個不使用的 alias 聲明防止升級時桌面圖標(biāo)崩潰。這與代碼重構(gòu)的直覺相反但在動態(tài)圖標(biāo)的場景下是實用經(jīng)驗。6. 集成流程與上線檢查清單最后整理一下從需求到上線的完整流程方便你直接照著排期。第一步需求評審階段。和運營確認(rèn)圖標(biāo)集合是否固定Android 端是否允許服務(wù)端下發(fā)任意 key 切換可以做動態(tài)拉取配置iOS 端是否接受系統(tǒng)彈窗確認(rèn)的限制這里必須讓運營在文檔上簽字確認(rèn)不然后面天天扯皮。第二步資源準(zhǔn)備階段。美術(shù)輸出所有圖標(biāo)必須包含不同尺寸Android 通用 mipmap 建議至少做 mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi 五檔iOS 讓 Xcode 自動適配 AppIcon 尺寸。美術(shù)輸出時就要確認(rèn) iOS 圖標(biāo)無透明通道。這一步我會寫一個小腳本做校驗掃描所有 PNG 的 Alpha 信息發(fā)現(xiàn)透明直接報錯。第三步原生封裝與聯(lián)調(diào)階段。Android 寫IconSwitcher.javaiOS 寫DynamicIconHelper.mmUnity 側(cè)寫DynamicIconManager.cs。先用 Unity Editor 模式跑通“假切換”邏輯再用真機驗證 Android 和 iOS。真機聯(lián)調(diào)階段至少覆蓋切默認(rèn)到活動、活動切回默認(rèn)、活動之間互切、切換后殺進(jìn)程重進(jìn)、弱網(wǎng)下連續(xù)切換。第四步服務(wù)端接入階段。如果要做服務(wù)端動態(tài)下發(fā)格式建議這樣{ iconKey: NewYear, startTime: 1704038400, endTime: 1706716800 }客戶端啟動時拉取配置如果當(dāng)前時間在時間段內(nèi)且 iconKey 存在則調(diào)用切換超過 endTime 則恢復(fù)默認(rèn)圖標(biāo)。建議客戶端本地緩存這份配置避免每次啟動都強依賴網(wǎng)絡(luò)同時要處理“切換失敗”的降級邏輯不要影響正常游戲流程切換失敗只在日志里打 Warning。第五步上線檢查清單。整理了一份簡要表格檢查項AndroidiOS圖標(biāo)素材已入包檢查 mipmap 資源是否齊全確認(rèn) Assets.xcassets 已打包Manifest/Info.plist 預(yù)聲明alias 全部聲明且只有一個啟用的CFBundleAlternateIcons 字典完整主入口無 LAUNCHER主 Activity 不帶 LAUNCHER不涉及切換邏輯真機驗證主流 ROM 各測一輪真機驗證彈窗與圖標(biāo)刷新恢復(fù)默認(rèn)路徑確認(rèn) Default alias 可恢復(fù)傳 nil 可恢復(fù)打包后資源檢查解包 APK/AAB 看 res看 Xcode 工程內(nèi) Copy Bundle Resources這套流程走下來雙端動態(tài)換圖標(biāo)的核心功能就已經(jīng)完成了。整個方案的復(fù)雜度主要集中在原生層和平臺差異處理上Unity 側(cè)的代碼量其實不大。只要把各端的坑提前埋好雷排掉后面運營每次做活動要換圖標(biāo)時你只需要讓美術(shù)出一套圖、服務(wù)端加一條配置客戶端一行代碼都不用改這件事就能非常優(yōu)雅地滾動起來。這也是我為什么推薦提前做好映射表和通用調(diào)用層的原因功能的價值不在首版跑通而在后續(xù)每次活動都能低成本復(fù)用。