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