手游运营最折腾人的需求之一就是每逢节假日或者版本大更产品都会补一句“图标能不能也换一下”。这句话听着轻巧落在 Unity 工程上却得分两头折腾Android 要动系统组件开关iOS 要走系统备用图标接口两层之间没有任何一层可以直接共用。这套在 Unity 手游项目里反复验证过的动态更换 App 图标双端方案我完整写下来从原生机制、清单配置、C# 封装一直讲到上线前要绕的审核和缓存问题一次讲透。适合需要在 Unity 里接这个功能的客户端开发也适合想先判断这个功能值不值得做的技术负责人参考。1. 动态换图标的真实需求与两端能力对照1.1 手游里“换图标”究竟是干什么用的一次版本更新往往伴随着图标投放新英雄形象、新赛季主视觉、春节或圣诞限定活动皮肤。我把实际遇到的需求归成三类运营活动临时换标节日、线上活动期间换图标结束后再换回默认。版本宣发长期换标大版本更新后直接换主视觉持续影响下载转化。A/B 测试换标同一样式不同配色或文案小范围测试根据点击率决定最终图标方案。第一类和第三类是动态换图标的刚需场景。过去不少团队的做法是等平台审核上架新版本一个图标也要走一次完整发布流程周期以天甚至周计算。动态方案能在小时内完成切换不需要重新上架 APK 或 IPA对活动运营的响应速度是质变。这里还要强调一个容易被忽略的认知换图标不是单纯换一张美术图。Android 的 activity-alias 入口和 iOS 的系统备用图标都会被系统当作“应用身份”的一部分记录。如果把图标换成和游戏完全无关的图或者因为活动整改导致图标与商店截图不一致平台侧可能判定为违规变更严重的会触发重新审核。我见过有团队上线后把图标换成活动海报结果被平台要求整改的案例。图标上带文字和角标要格外谨慎特别是 iOS应用图标的可视区域有固定安全尺寸文字很容易被裁掉。1.2 为什么 Android 和 iOS 不能共用一套代码这两端根本没有共同的“换图标 API”。Android 端我使用的是最经典的 activity-alias 替身机制系统启动器通过扫描带 MAIN/LAUNCHER 意图的组件来展示图标开发者可以维护多个替身入口运行时用 PackageManager 启用或禁用组件来实现“换图标”。iOS 端则只有一个官方入口UIApplication.setAlternateIconName(_:completionHandler:)系统自己管理备用图标开发者能做的只是把名字传进去。两端的差异不只是接口不同连行为都差得很远Android 切换没有提示框但部分 OEM 手机的启动器有缓存延迟iOS 每次切换都会弹系统确认框无法绕过。这意味着你在 C# 层能把差异封进一个接口但业务侧一定要知道两边的用户表现不一样否则验收时容易吵起来。为了快速对齐这里给一张我实际跑过项目后整理出的对照表维度AndroidiOS核心机制activity-alias PackageManager 组件启停setAlternateIconName最低版本老版本系统即可用建议以 Android 4.1 以上覆盖测试iOS 10.3 及以上切换弹出提示无系统弹窗有系统确认框无法屏蔽启动器图标刷新部分 OEM 有缓存延迟系统即时更新约 1 秒动画状态持久化系统保存组件状态系统保存直到恢复默认或卸载资源格式普通 mipmap 或自适应图标Info.plist 声明的备用图标资源iOS 那个“无法屏蔽的系统确认框”从 10.3 到现在都没有开放关闭开关。所以做需求排期时别把“无缝无感”写在预期里否则后面运营验收会很尴尬。2. 工程改造先行AndroidManifest 与 Info.plist 的正确配置姿势2.1 Android 的 activity-alias 替身图标机制先交代原理。在 Android 系统里桌面显示的应用图标本质上是“启动入口 Activity”的图标。安装器通过PackageManager查询带有android.intent.action.MAIN和android.intent.category.LAUNCHER的组件拿到最终在桌面呈现的图标和名称。所以“换图标”最直接的办法是准备多个不同名称和资源的“入口组件”让它们都指向同一个 MainActivity然后在运行时切换这几个组件的启用状态。在 AndroidManifest 里配置长这样。包名我按com.yourgame.demo来写实际换成自己的 applicationId 即可activity android:name.MainActivity android:exportedtrue android:launchModesingleTask android:screenOrientationsensorLandscape / activity-alias android:name.MainActivity_Alias_Default android:enabledtrue android:exportedtrue android:iconmipmap/ic_launcher_default 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_Festival android:enabledfalse android:exportedtrue android:iconmipmap/ic_launcher_festival 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。它本身不占一个 Activity 实例只是给目标 Activity 提供一层“别名”别名可以单独配置 icon、label 和入口过滤条件。我把默认图标和节日图标分别挂在两个 alias 上安装包中让默认 alias 处于enabledtrue节日 alias 保持enabledfalse。运行时把开关状态对调桌面图标就会跟着切换。这里有个极易踩的细节主 Activity 本身不要再配置 LAUNCHER否则系统在安装时会认为存在多个启动入口部分系统会直接在桌面显示两个图标。尤其是老项目之前为了调试方便会顺手在主 Activity 上配 LAUNCHER接入动态图标体系后忘了移除最后出现“双图标”问题定位到清单文件时人都麻了。2.2 iOS 备用图标在 Info.plist 里的声明规则iOS 这边机制更“管制”。从 iOS 10.3 起系统提供setAlternateIconName但前提是必须在Info.plist里把备用图标的资源提前声明清楚。规则看着简单出错率却不低图标文件必须在主 Bundle 里文件名不能带扩展名并且资源要覆盖各尺寸规范。备用图标挂在CFBundleIcons字典下keyCFBundleIcons/key dict keyCFBundleAlternateIcons/key dict keyicon_festival/key dict keyCFBundleIconFiles/key array stringicon_festival/string /array /dict /dict /dict这里的icon_festival既是字典 key也是传给原生接口的“图标名”。CFBundleIconFiles里的字符串指向 Bundle 中实际存在的图片资源。这个声明看起来不复杂但在 Unity 工程里有两个脆弱点一是 Unity 构建 Xcode 工程时会自动生成一份CFBundleIcons主图标配置你手动去 Info.plist 里加备用图标时很容易把主配置覆盖掉二是图标文件如果没打进 Bundle 根目录plist 里声明得再完整也白搭。另外要留意备用图标的尺寸。iOS 主图标一般要求 1024x1024 的源图备用图标虽然由CFBundleIconFiles指定文件名但系统仍会按多尺寸缩放使用建议源图也按 1024x1024 输出再让 Xcode 在构建时生成所需尺寸。如果你只放了一张 180x180 的小图某些系统版本上会显示得很模糊看起来像劣质素材。2.3 Unity 构建工程中维护双端配置的习惯我在 Unity 里做这个功能时默认约定是这样的Android 的清单配置放在Assets/Plugins/Android/AndroidManifest.xml图标资源放在同目录下的res/mipmap-*中。Unity 导出 APK 时会自动合并不需要每次构建后再去翻 Android 工程。iOS 的 plist 配置不手改原始文件而是写一个PostProcessBuild构建后处理脚本在每次导出 Xcode 工程后自动往Info.plist注入CFBundleAlternateIcons。所有图标资源文件统一放到Assets/Plugins/iOS/Resources/icon_festival.png这类路径下后续脚本负责在构建时把它们复制进 Bundle 根目录。之所以坚持用脚本而不是手动改是因为 Unity 每次导出 iOS 工程都会重新生成Info.plist和资源结构。只靠“记得每次构建后去 Xcode 里手动改一次”几乎百分之百会漏尤其是赶版本、熬夜、多个人轮班的时候。把配置固化进构建管线换电脑、换同事都能稳定复现这才是工程化该有的样子。3. Android 原生切换实现PackageManager 组件开关与 Unity 调用3.1 用 PackageManager 控制组件启停的原理Android 端真正执行切换的代码不长原理也很直白PackageManager.setComponentEnabledSetting()是系统提供给应用控制“组件是否可用”的接口传入要控制的组件名和状态系统会同步更新已安装应用的组件状态。这个操作不需要特殊权限不需要 root普通三方应用就能调用。关键参数有ComponentName完整类名这里填 alias 的全名比如com.yourgame.demo.MainActivity_Alias_Default。newStateCOMPONENT_ENABLED_STATE_ENABLED或COMPONENT_ENABLED_STATE_DISABLED。flags一般传DONT_KILL_APP表示尽最大努力不杀掉当前进程。组件状态的变更不是即时销毁进程对当前运行中的进程影响很小但系统注册的相关信息会立即更新。启动器通常会在收到PACKAGE_CHANGED广播后重新读取图标这也是为什么 Pixel 这类原生启动器刷新很及时部分 OEM 启动器却要等一会儿才能看到变化的原因。实际操作中我建议按“先启用目标 alias再禁用旧 alias”的顺序执行。这样系统任意时刻都至少保留一个有效入口避免启动器把应用误判为“无启动入口”而出现短暂空白或图标消失的情况。如果顺序反过来个别定制 ROM 在禁用旧入口的瞬间会触发扫描表现就是桌面上应用图标闪一下消失过一会儿又出现用户观感很不好。3.2 Java 侧封装与 C# 侧调用代码在 Unity 里我习惯把 Android 原生逻辑写成一个极简的 Java 类放在Assets/Plugins/Android/目录下。类名带上项目包名前缀避免不同插件间的类名冲突package com.yourgame.demo.icon; import android.content.ComponentName; import android.content.Context; import android.content.pm.PackageManager; public class AppIconSwitcher { public static void enableAlias(Context context, String aliasName) { PackageManager pm context.getPackageManager(); pm.setComponentEnabledSetting( new ComponentName(context, aliasName), PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP); } public static void disableAlias(Context context, String aliasName) { PackageManager pm context.getPackageManager(); pm.setComponentEnabledSetting( new ComponentName(context, aliasName), PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP); } }C# 层调用时通过 Unity 自带的AndroidJavaClass、AndroidJavaObject反射进 Java 层不需要额外添加 Android 依赖库。核心代码public static void AndroidSetIconAlias(string aliasName, bool enable) { using (var player new AndroidJavaClass(com.unity3d.player.UnityPlayer)) { var activity player.GetStaticAndroidJavaObject(currentActivity); using (var switcher new AndroidJavaClass(com.yourgame.demo.icon.AppIconSwitcher)) { string method enable ? enableAlias : disableAlias; switcher.CallStatic(method, activity, aliasName); } } }这里有个容易踩的坑currentActivity拿到的 Activity 是 UnityPlayerActivity 的实例某些项目的主 Activity 是自定义继承类。多数情况下直接用它做 Context 没有问题但如果你的主 Activity 在启动流程里做过自定义Intent处理建议在 Java 层缓存一份 ApplicationContext所有切换操作统一用全局上下文避免偶发的引用生命周期问题。另外提醒一下切换操作在个别定制系统上会被当作“应用组件变化”而触发整包广播。如果你的应用里有监听PACKAGE_CHANGED来做重量级逻辑的代码要注意收敛避免用户切换图标瞬间造成卡顿或者误触发逻辑。我在项目里实际观察到的影响量级很小但多一层保险总没错。3.3 OEM 启动器缓存与多图标共存风险做完切换后最常遇到的反馈是“我点了没反应”。注意可能开关已经生效了只是图标刷新有延迟。以我实际测试的情况来看Pixel 和原生 Android 上切换后大约 2 到 3 秒图标就会更新小米 MIUI 经常需要回桌面等 5 秒以上部分版本甚至出现需要重启启动器进程或重启手机才能看到新图标的情况。华为 EMUI、vivo OriginOS、OPPO ColorOS 在个别版本上也有图标缓存。这不代表方案失效是启动器 icon cache 在作祟。针对这个问题我有几个实战经验切换时先启用新 alias、再禁旧 alias避免任何瞬间的“无入口”状态。提醒测试人员切换完成后回桌面观察不要待在应用内看——应用内看不到桌面图标变化。灰度阶段把 MIUI、EMUI、ColorOS、OriginOS、Flyme 这五类系统列入必测清单原生 Android 反而可以放后面测。还有一点是关于多图标的系统级风险。同一个别名资源不能有两个同时“活着”否则安装器会认为应用有多个启动入口应用列表可能出现两个图标或安装阶段报错。测试时如果用过 adb 手动改组件状态记得在回归用例里检查当前到底哪个 alias 处于启用状态别把测试机搞成一个“混沌状态”再开始验证。4. iOS 原生切换实现setAlternateIconName 的桥接与限制4.1 系统确认弹窗与图标切换的时序行为换到 iOS首先要接受一个现实切换备用图标时系统一定会弹确认框提示“应用图标将更新”。这个弹窗从 iOS 10.3 到现在都没有关闭开关任何试图绕过弹窗的做法都是高风险动作不建议碰。如果游戏产品坚持要“无感切换”在需求沟通阶段就必须把这个限制说明白否则排期、体验预期全都会错位。另一个常见迷惑是为什么调用后图标不是立刻变实测下来从调用setAlternateIconName到桌面图标刷新大约 1 秒左右系统会有一个小过渡动画。如果你在应用内给玩家提示“图标已更换”玩家切到桌面正好看到新图标节奏是刚好卡上的。还要注意iOS 的备用图标状态系统会一直记着。如果你切到icon_festival后不主动换回在用户卸载重装之前图标会一直是节日款。这和 Android 的组件状态持久化类似所以业务逻辑要做好状态记录别出现运营说“换回默认”代码却没执行导致活动结束两周图标还挂着的乌龙。4.2 Objective-C 插件与 C# 回调机制Unity 调 iOS 原生能力常规做法是写一个 Objective-C 或 C 的静态插件导出 C 函数给 C# 的DllImport(__Internal)调用。备用图标插件代码大概长这样#import UIKit/UIKit.h typedef void (*IconChangeCallback)(bool success, const char* error); static IconChangeCallback s_callback NULL; extern C void _SetAppIcon(const char* iconName, IconChangeCallback callback) { s_callback callback; if (available(iOS 10.3, *)) { NSString *target nil; if (iconName ! NULL strlen(iconName) 0) { target [NSString stringWithUTF8String:iconName]; } dispatch_async(dispatch_get_main_queue(), ^{ [[UIApplication sharedApplication] setAlternateIconName:target completionHandler:^(NSError * _Nullable error) { dispatch_async(dispatch_get_main_queue(), ^{ if (error) { if (s_callback) s_callback(false, error.localizedDescription.UTF8String); } else { if (s_callback) s_callback(true, NULL); } }); }]; }); } else { if (s_callback) s_callback(false, iOS 10.3 or later is required); } }C# 侧调用时回调函数必须声明成静态委托并加上MonoPInvokeCallback标签。这是 Unity 在 iOS 这类 AOT 平台上跑 C# 回调的固定写法不加这个标签运行时很容易直接崩掉#if UNITY_IOS !UNITY_EDITOR [DllImport(__Internal)] private static extern void _SetAppIcon(string iconName, IconChangeCallback callback); #endif private delegate void IconChangeCallback(bool success, [MarshalAs(UnmanagedType.LPStr)] string error); [AOT.MonoPInvokeCallback(typeof(IconChangeCallback))] private static void OnIconChangeResult(bool success, string error) { if (success) Debug.Log(iOS icon changed); else Debug.LogError(iOS icon change failed: error); }调用的时候直接执行#if UNITY_IOS !UNITY_EDITOR _SetAppIcon(icon_festival, OnIconChangeResult); #endif有个容易忽略的点如果iconName传空字符串插件代码里会把target置为 nil这是官方支持的“恢复默认图标”路径。别把这个行为混同为“传错名字”传错名字系统会返回无效图标名的错误错误码在回调里可以看到。4.3 恢复默认图标与完成回调不触发的处理恢复默认图标本质上也是调用同一个 API只是传入 nil。如果业务上要做“活动结束换回原图标”C# 层就是_SetAppIcon(string.Empty, OnIconChangeResult);这里要重点提醒官方文档对完成回调的说明是“并非每次都保证调用”。实际测试也印证了某些情况下比如用户在确认弹窗出现时直接杀掉应用回调可能根本不会回来。所以业务逻辑千万不要依赖这个回调去推动关键流程。我的建议是“发起切换后默认视为成功”靠持久化状态兜底而不是死等回调通知。如果你需要在应用下一次启动时判断当前图标到底是什么iOS 没有公开接口直接查询“当前备用图标名”。目前唯一可靠的办法是自己在本地记录。这个我在第 5 章统一封装时会一并处理。5. C# 层统一接口一套代码管理双端图标状态5.1 抽象接口与平台条件编译把双端原生能力封装成一个 C# 静态类业务侧只需要知道“图标别名”一个概念。接口设计要精简ChangeIcon(string iconKey, Actionbool, string callback)、ResetIcon(Actionbool, string callback)、GetCurrentIconKey()。条件编译用 Unity 标准宏即可public static class AppIconManager { public static void ChangeIcon(string iconKey, Actionbool, string callback) { #if UNITY_EDITOR Debug.LogWarning($[AppIcon] Editor no-op: {iconKey}); callback?.Invoke(false, unsupported in editor); #elif UNITY_ANDROID AndroidSetIcon(iconKey, true, callback); // 旧的 alias 由 Java 侧根据当前状态关闭 #elif UNITY_IOS IOSSetIcon(iconKey, callback); #endif } public static void ResetIcon(Actionbool, string callback) { #if UNITY_ANDROID AndroidSetIcon(DefaultIconKey, true, callback); #elif UNITY_IOS IOSSetIcon(string.Empty, callback); #endif } }这里的AndroidSetIcon和IOSSetIcon分别是前面章节封装的原生层入口。业务侧调用永远只有一行两个平台在行为上的差异全部收在对接文档里而不是让 UI 逻辑到处写#if。这样不但调用侧清爽后续如果还要扩展 Windows 或主机平台也就是多一个条件编译分支的事。5.2 图标状态持久化与启动恢复逻辑我用一个PlayerPrefs字段存当前图标 Key刻意不直接依赖原生系统状态。原因有两个iOS 无法查询当前备用图标名Android 虽然能查组件状态但 C# 层多包一层也无妨而且还能兼容后续扩展的自定义图标系统。private const string IconKeyPref APP_ICON_CURRENT_KEY; public static void MarkIconApplied(string key) { PlayerPrefs.SetString(IconKeyPref, key ?? string.Empty); PlayerPrefs.Save(); } public static string GetCurrentIconKey() { return PlayerPrefs.GetString(IconKeyPref, string.Empty); }在启动恢复这块我的经验和一般直觉相反不要在游戏启动时自动把图标恢复成上次的备用状态尤其是 iOS。因为 iOS 切换会弹系统确认框玩家启动游戏时突然弹一个“图标将更新”观感非常吓人。更合理的方案是“被动恢复”——如果运营指定的活动图标和本地记录不一致等玩家进入主界面、完成新手引导或其他某个自然节点后再按需切换如果只是单纯重启游戏、没有任何业务变化那就完全不要动图标。Android 端相对宽松因为切换无弹窗你可以在启动后调用一次把状态校准到期望值。但我同样建议只在“当前状态和期望状态不一致”时才执行避免每次启动都做无谓的组件开关操作也能减少不必要的系统广播。5.3 Editor 与真机环境的降级处理Unity Editor 里没有 Android/iOS 原生环境接口必须做降级。我的处理是Editor 里直接Debug.LogWarning并回调unsupported in editor同时用一个静态变量模拟图标状态方便策划验证 UI 和本地状态逻辑。这样做的好处是活动运营在编辑器里点“换节日图标”按钮不会白屏只会看到一条警告而 UI 状态切换逻辑依然可以正常走通。真机上的降级要注意iOS 模拟器对setAlternateIconName的支持并不完整部分模拟器版本存在回调不触发或弹窗行为异常的情况所以真机调试仍然是最靠谱的验证方式。Android 模拟器基本没问题但某些云真机平台对PackageManager组件状态的模拟并不完整测试结果只能作为参考。6. 上线前绕不过的坑审核、缓存、行为变更6.1 应用商店审核时的说明策略动态更换图标不是平台禁止的能力但审核细节不少。先说明 iOS。苹果审核环境里应用应该以默认图标状态提交审核不要在审核期间让系统认为你处于“备用图标”状态。也就是说审核包最好不包含自动更换图标的逻辑或者至少在审核环境下强制使用默认图标。否则审核员打开应用看到图标是节日款而商店截图和页面宣传显示默认款很可能因为这个不一致被要求整改。另外不要在审核期间尝试“静默恢复默认图标”那会弹确认框只会把情况弄得更奇怪。Android 在 Google Play 上相对宽松activity-alias 是公开机制不算违规。但注意如果你的应用在安装包中同时启用了多个 LAUNCHER 组件Play 后台可能显示“应用图标数量异常”甚至有拒审案例。所以仍然强调那句话确保安装包永远只有一个默认启用的 LAUNCHER 入口。还有一点值得单独拎出来说换图标和商店素材要保持一致。把游戏图标换成活动海报而商店截图还是旧风格搜索和转化数据都会受影响。审核不是唯一风险用户认知的一致性才是更大成本。6.2 Android 12 与 iOS 新版系统的行为变化Android 12 之后系统对exported属性要求更严格。如果 MainActivity 或 alias 漏写exported安装阶段可能直接报错或行为异常。所以我们的清单模板里所有带 LAUNCHER 的组件都明确写了android:exportedtrue。老项目接入动态图标时尤其容易踩这个坑因为旧清单可能根本没这个属性跑在老系统上没事跑到 Android 12 直接翻车。Android 13 之后“主题图标”功能逐渐普及。用户如果开启主题图标系统会把应用图标替换成基于monochrome图层生成的主题样式这会覆盖掉你精心准备的活动图标视觉。解决方案是在自适应图标里补上monochrome图层否则主题开关一开你的节日图标可能被系统变成一块单色剪影。这块属于新系统带来的新坑做素材时要把三种图层前景、背景、单色一起输出。iOS 这边13 以上的系统对CFBundleIcons的结构解析更严格图标资源缺失时可能直接回退到主图标而不是报错。这意味着你声明了备用图标但文件没打进去用户看到的是“没变化”而不是错误提示排查时很容易误以为代码没生效。遇到“代码调用成功但图标没变”的问题第一件事是检查 Bundle 里到底有没有那个文件而不是先怀疑原生代码。6.3 灰度验证与回滚方案动态换图标是运营动作但它同样需要灰度。我的建议是功能上线后先在测试包上完整走一遍“更换→重启→回滚”流程然后在内部少量设备上验证图标刷新表现最后再让运营通过后台控制开关触达真实用户。不要第一天就让全量玩家换新图标万一某种机型不刷新线上就会有一批玩家顶着旧图标跑活动运营数据也会失真。实际操作链路我推荐这样定在后台配置一个图标开关比如app_icon_2025_festival客户端根据开关值调用ChangeIcon。本地记录当前图标 Key灰度过程中如果发现异常后台直接下发默认图标 Key客户端调用ResetIcon。灰度周期建议覆盖至少一次启动器图标缓存刷新周期常见机型确认刷新后再放量。回滚方面Android 端因为启动器缓存问题需要额外耐心短时间内来回切换更容易触发缓存不刷新所以回滚后要多观察一会儿必要时在测试团队里做一次“切换回默认后重启手机”的验证确认缓存不会把旧图标残留在桌面。iOS 端相对直白回滚调用一次恢复默认即可剩下的只有系统动画那一秒。这套功能做完到现在我的体会是代码量真的不大难的是把两端行为差异、审核限制、缓存表现这些“隐形成本”全部算进排期里。动态图标属于典型的代码一天写完、填坑填三个月的功能。但一旦把工程配置、原生封装、状态持久化和灰度开关都规整好它给运营带来的灵活度绝对对得起前期投入。如果你正打算在 Unity 手游里接动态换图标建议先对照文中的配置清单检查自己的工程结构再动代码也不迟。