1. 动态图标这件事，到底值不值得做
先抛结论：动态更换 App 图标这个功能，在手游运营里属于典型的"小投入、高感知"手段。玩家在手机桌面上看到的那个图标，是产品与用户之间最高频的视觉触点——每天解锁屏幕几十次，每次都会扫到。节日活动、版本大版本更新、联动 IP 上线、赛季开启，这些节点如果能把桌面图标同步换掉，相当于在用户最私密的界面上做了一次免费曝光。
但这件事在 Unity 手游里落地，坑比想象中多。Android 和 iOS 两套完全不同的机制，Unity 本身又不提供跨平台的图标切换 API，再加上国内安卓渠道包体五花八门、iOS 对图标资源有严格的预置要求，很多团队第一次做都会卡在"iOS 根本换不了"或者"Android 换完图标应用直接闪退"上。
这篇内容面向的是有 Unity 手游开发经验、需要落地动态图标功能的客户端同学，也适合做运营向功能规划的技术负责人参考。我会把 Android 的activity-alias方案、iOS 的setAlternateIconName方案、Unity 侧的桥接封装、资源打包策略、渠道适配、常见崩溃排查全部拆开讲，代码和配置都能直接抄。核心关键词围绕Unity、Android、iOS、App图标、activity-alias展开，读完你应该能独立把双端动态图标跑通。
先说清楚一个前提：动态图标不是"运行时随便换一张图"，而是预先在工程里注册好若干套图标资源，运行时在已注册的集合里切换。这个认知非常关键，后面 Android 和 iOS 的所有限制都源于此。很多新手以为可以像换 UI 图片一样动态加载，结果在两端都撞墙。
2. 双端方案的整体设计与选型逻辑
2.1 为什么 Android 和 iOS 必须走两套完全不同的路
Android 和 iOS 对"应用图标"的定义根本不在一个层面。Android 的图标是写在AndroidManifest.xml里的组件入口，系统通过Intent找到启动Activity，图标只是这个组件的一个属性。所以 Android 的思路是：注册多个"入口组件"，每个组件挂不同图标，切换时启用目标组件、禁用其他组件，系统桌面重新读取后图标就变了。
iOS 则完全不同。iOS 的图标是 App Bundle 里的资源，系统在安装时就扫描Info.plist里声明的备用图标集合，运行时只能在这个预置集合里通过setAlternateIconName切换。你没法在运行时往 Bundle 里塞新图标，这是沙盒机制决定的。
理解了这个底层差异，你就明白为什么不能指望一个统一 API 搞定两端。Unity 作为跨平台引擎，在这件事上只能做"桥接层"，真正的实现必须下沉到原生。
2.2 方案选型的三个核心考量
第一个考量是图标资源是否随包体预置。两端都要求预置，所以包体会增大。每套图标在 Android 上要准备 mipmap 各密度（mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi），在 iOS 上要准备 @2x/@3x 两套。假设你要做 4 套节日图标，Android 侧大约增加 4×5=20 个 PNG，iOS 侧增加 4×2=8 个 PNG。按每张 20KB 估算，增量在 500KB 到 1MB 之间，对现在动辄几百 MB 的手游来说可以接受，但要有意识控制套数。
第二个考量是切换的实时性。Android 通过activity-alias切换后，部分机型桌面会有 1 到 3 秒的延迟才刷新图标，甚至需要用户手动下拉通知栏或重启桌面才生效。iOS 切换是即时的，但会弹出一个系统提示框（"您已更改'XX'的图标"），这个提示无法去除，属于系统行为。运营侧要提前和用户预期对齐，别指望"无感切换"。
第三个考量是渠道包兼容性。国内安卓渠道众多，部分渠道会对AndroidManifest.xml做二次处理，activity-alias有可能被渠道工具误删或改写。所以动态图标功能要做降级保护：切换失败时静默回退到默认图标，绝不能因为图标切换导致启动崩溃。
2.3 整体架构分层
我把整个方案分成三层来设计，这样职责清晰、便于维护：
- Unity 表现层：负责触发时机（比如进入活动页、检测到节日）、UI 提示、本地记录当前图标状态。
- C# 桥接层：通过
AndroidJavaObject调用 Android 原生，通过DllImport调用 iOS 原生，统一暴露SetAppIcon(string iconKey)接口。 - 原生实现层：Android 侧操作
PackageManager启停activity-alias；iOS 侧调用setAlternateIconName。
这样分层的好处是，Unity 业务代码完全不关心平台差异，只调一个接口。后续要加新图标，只需要在原生工程注册资源、在配置表加一行，业务层零改动。
3. Android 端 activity-alias 方案深度拆解
3.1 activity-alias 的工作原理
activity-alias是 Android 提供的一种"别名组件"，它可以指向一个真实的Activity，但拥有独立的icon、label、enabled等属性。系统桌面在展示应用时，读取的是当前enabled=true且带MAIN/LAUNCHERintent-filter 的组件。
关键点在于：同一时刻只能有一个带 LAUNCHER 属性的组件处于 enabled 状态。如果你启用了两个，桌面上会出现两个图标（这是很多新手踩的坑）。所以切换逻辑必须是"先禁用旧的，再启用新的"，或者"启用新的同时禁用旧的"，顺序和时机都有讲究。
下面是一个标准的AndroidManifest.xml配置示例，注册了默认图标加三套备用图标：
<application android:icon="@mipmap/ic_launcher_default" ...> <!-- 默认入口，enabled 初始为 true --> <activity-alias android:name=".icon.DefaultAlias" android:targetActivity="com.unity3d.player.UnityPlayerActivity" android:enabled="true" android:exported="true" android:icon="@mipmap/ic_launcher_default" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity-alias> <!-- 春节图标，初始禁用 --> <activity-alias android:name=".icon.SpringAlias" android:targetActivity="com.unity3d.player.UnityPlayerActivity" android:enabled="false" android:exported="true" android:icon="@mipmap/ic_launcher_spring" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity-alias> <!-- 更多别名省略 --> </application>注意targetActivity必须指向你真实的启动 Activity。Unity 导出的 Android 工程默认启动 Activity 是com.unity3d.player.UnityPlayerActivity，如果你自定义了启动页，要改成你自己的。
3.2 切换逻辑的 Java 实现
切换的核心是PackageManager.setComponentEnabledSetting。这里有个非常关键的坑：禁用当前组件和启用目标组件必须分两步，且禁用操作要放在最后或者用正确的 flag，否则可能出现"两个图标同时消失"的瞬间。
public class IconSwitcher { private static final String PKG = "com.yourcompany.yourgame"; public static void switchIcon(Context ctx, String aliasName) { PackageManager pm = ctx.getPackageManager(); String target = PKG + ".icon." + aliasName; // 第一步：启用目标别名 pm.setComponentEnabledSetting( new ComponentName(PKG, target), PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP); // 第二步：禁用其他所有别名 String[] all = {"DefaultAlias", "SpringAlias", "SummerAlias", "NationalAlias"}; for (String a : all) { if (a.equals(aliasName)) continue; pm.setComponentEnabledSetting( new ComponentName(PKG, PKG + ".icon." + a), PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP); } } }DONT_KILL_APP这个 flag 必须加，否则每次切换系统会杀掉你的进程，玩家正在游戏里直接被踢出去，体验灾难。加了之后进程保留，但桌面图标刷新会有延迟，这是正常现象。
3.3 Unity 侧调用封装
Unity 通过AndroidJavaClass和AndroidJavaObject调用上面的 Java 代码。我习惯封装一个静态类，把平台判断也放进去：
public static class AppIconManager { public static void SetIcon(string iconKey) { #if UNITY_ANDROID && !UNITY_EDITOR try { using (var unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) using (var activity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity")) using (var switcher = new AndroidJavaClass("com.yourcompany.yourgame.IconSwitcher")) { switcher.CallStatic("switchIcon", activity, iconKey); } PlayerPrefs.SetString("current_icon", iconKey); PlayerPrefs.Save(); } catch (System.Exception e) { Debug.LogError("切换图标失败: " + e.Message); } #elif UNITY_IOS && !UNITY_EDITOR _SetIOSIcon(iconKey); #endif } }注意try-catch不能省。某些定制 ROM 上setComponentEnabledSetting会抛SecurityException或IllegalArgumentException，捕获后静默失败，保证游戏不崩。
3.4 图标资源命名与密度适配
Android 的 mipmap 目录要按密度放图。假设你的图标设计稿是 512×512，那么：
| 密度目录 | 尺寸 | 用途 |
|---|---|---|
| mipmap-mdpi | 48×48 | 低密度屏 |
| mipmap-hdpi | 72×72 | 中密度屏 |
| mipmap-xhdpi | 96×96 | 高密度屏 |
| mipmap-xxhdpi | 144×144 | 超高密度屏 |
| mipmap-xxxhdpi | 192×192 | 极高清屏 |
现在主流机型都是 xxhdpi 以上，但低密度目录不能省，否则老设备上图标会模糊。命名建议统一前缀，比如ic_launcher_spring、ic_launcher_summer，方便脚本批量处理。
提示：Android 8.0 以后支持自适应图标（Adaptive Icon），需要提供前景层和背景层两个资源。如果你的目标用户大量在 Android 8.0 以上，建议直接做自适应图标，否则在部分启动器上图标会被裁切成圆形或方形，视觉不统一。
4. iOS 端 setAlternateIconName 方案全流程
4.1 备用图标的预置规则
iOS 的备用图标必须在Info.plist里通过CFBundleIcons声明。结构如下：
<key>CFBundleIcons</key> <dict> <key>CFBundlePrimaryIcon</key> <dict> <key>CFBundleIconFiles</key> <array> <string>AppIcon60x60</string> </array> </dict> <key>CFBundleAlternateIcons</key> <dict> <key>SpringIcon</key> <dict> <key>CFBundleIconFiles</key> <array> <string>SpringIcon60x60</string> </array> <key>UIPrerenderedIcon</key> <false/> </dict> <key>SummerIcon</key> <dict> <key>CFBundleIconFiles</key> <array> <string>SummerIcon60x60</string> </array> <key>UIPrerenderedIcon</key> <false/> </dict> </dict> </dict>这里有几个硬性要求必须遵守。第一，备用图标的文件名必须遵循名称+尺寸的格式，比如SpringIcon60x60@2x.png、SpringIcon60x60@3x.png，系统会自动匹配。第二，图标必须是 PNG，不能有 alpha 通道（否则上架审核会被拒），不能有圆角（系统自动加）。第三，CFBundleAlternateIcons的 key 就是运行时传给setAlternateIconName的名字。
4.2 切换的 Objective-C 实现
iOS 侧代码比 Android 简单，但要注意主线程和回调：
void _SetIOSIcon(const char* iconName) { NSString *name = [NSString stringWithUTF8String:iconName]; // 传 nil 表示恢复默认图标 NSString *target = [name isEqualToString:@"Default"] ? nil : name; if (![[UIApplication sharedApplication] supportsAlternateIcons]) { NSLog(@"当前系统不支持备用图标"); return; } [[UIApplication sharedApplication] setAlternateIconName:target completionHandler:^(NSError * _Nullable error) { if (error) { NSLog(@"切换图标失败: %@", error.localizedDescription); } }]; }supportsAlternateIcons这个判断很重要，iOS 10.3 以下不支持，虽然现在存量极少，但加上更稳妥。另外setAlternateIconName必须在主线程调用，Unity 的 C# 调用默认就在主线程，一般没问题，但如果你在子线程触发，要手动 dispatch 回主线程。
4.3 Unity 调用 iOS 原生的桥接
iOS 侧通过DllImport声明外部函数，函数要放在.mm文件里（因为要用 Objective-C）：
#if UNITY_IOS && !UNITY_EDITOR [DllImport("__Internal")] private static extern void _SetIOSIcon(string iconName); public static void SetIOSIcon(string iconKey) { _SetIOSIcon(iconKey); } #endif.mm文件要放在Assets/Plugins/iOS/目录下，Unity 打包时会自动编译进 Xcode 工程。文件名随意，但函数名要和 C# 声明一致。
4.4 iOS 切换的系统提示问题
前面提过，iOS 切换图标会弹系统提示框。这个提示是UIAlertController形式的，文案固定为"您已更改'应用名'的图标"，无法通过公开 API 去除。有些团队尝试用 Method Swizzling 拦截presentViewController来隐藏它，但这属于私有 API 操作，有上架风险，我不建议在正式项目里用。
务实的做法是：把切换时机放在用户主动点击"更换图标"按钮之后，用户有心理预期，弹提示不突兀。千万别做成"进入游戏自动换图标"，那样用户会莫名其妙看到一个系统弹窗，体验很差。
5. Unity 侧统一封装与资源管理策略
5.1 统一接口设计
业务层只应该看到一个接口，我设计的签名是这样的：
public static class AppIcon { // iconKey 对应配置表里的 key，如 "default"、"spring"、"summer" public static void Switch(string iconKey, Action<bool> onComplete = null); public static string GetCurrent(); public static bool IsSupported(); }Switch内部做平台分发、异常捕获、状态记录、回调通知。GetCurrent从PlayerPrefs读取上次设置的 key，用于 UI 上高亮当前选中的图标。IsSupported在 Android 上恒为 true（只要 manifest 配了），iOS 上判断系统版本。
5.2 图标配置表设计
我习惯用一张 ScriptableObject 或 JSON 配置表管理所有图标，字段包括 key、显示名、解锁条件、资源路径：
| 字段 | 类型 | 说明 |
|---|---|---|
| key | string | 唯一标识，与原生注册名一致 |
| displayName | string | UI 显示名，如"春节限定" |
| unlockType | int | 0 默认解锁，1 活动解锁，2 付费解锁 |
| unlockParam | string | 解锁参数，如活动 ID |
| previewPath | string | UI 预览图路径 |
这样运营加一套新图标，只需要在原生工程注册资源、在配置表加一行，业务代码完全不用动。这是可维护性的关键。
5.3 状态同步与容错
有个容易被忽略的问题：用户在系统设置里清除应用数据后，PlayerPrefs会丢失，但 Android 的组件启用状态是持久的。这会导致记录和实际图标不一致。解决办法是在游戏启动时做一次校验：读取当前 enabled 的 alias，和PlayerPrefs对比，不一致就以实际为准更新记录。
Android 侧读取当前 alias 的代码：
public static String getCurrentAlias(Context ctx) { PackageManager pm = ctx.getPackageManager(); String[] all = {"DefaultAlias", "SpringAlias", "SummerAlias", "NationalAlias"}; for (String a : all) { int state = pm.getComponentEnabledSetting(new ComponentName(PKG, PKG + ".icon." + a)); if (state == PackageManager.COMPONENT_ENABLED_STATE_ENABLED) { return a; } } return "DefaultAlias"; }iOS 侧则直接读[[UIApplication sharedApplication] alternateIconName]，返回 nil 就是默认图标。
6. 实操全流程与关键环节记录
6.1 Android 打包配置的完整步骤
第一步，在 Unity 的Assets/Plugins/Android/下准备好AndroidManifest.xml（如果用了自定义 manifest）。如果没有，Unity 会用默认的，你需要从Temp或导出的 Gradle 工程里拷一份出来改。
第二步，把各套图标按密度放进Assets/Plugins/Android/res/mipmap-*目录。注意 Unity 对res目录的处理有讲究，推荐用Assets/Plugins/Android/res/这个路径，Unity 会自动合并进最终工程。
第三步，把IconSwitcher.java放进Assets/Plugins/Android/下，注意包名要和 manifest 里的package一致。
第四步，导出 Gradle 工程或直接 Build APK，用aapt dump badging your.apk检查 manifest 里 alias 是否正确写入。这一步很关键，很多问题出在 manifest 合并阶段。
6.2 iOS 打包配置的完整步骤
第一步，准备图标 PNG。每套图标需要@2x（120×120）和@3x（180×180）两个尺寸，命名如SpringIcon60x60@2x.png。
第二步，把这些 PNG 放进 Xcode 工程的资源目录。Unity 打包后，你需要手动或通过 PostProcessBuild 脚本把它们加到 Xcode 工程里。我推荐写一个IPostprocessBuildWithReport脚本自动拷贝，避免每次手动加。
第三步，修改Info.plist，加入CFBundleIcons结构。同样可以用 PostProcessBuild 脚本自动注入，用PlistDocument或直接字符串替换。
第四步，把.mm文件放进Assets/Plugins/iOS/，Unity 会自动编译。
6.3 自动化构建脚本示例
手动改 Xcode 工程太痛苦，我写了个 PostProcessBuild 脚本自动处理 iOS 图标注入：
public class IOSIconPostProcess : IPostprocessBuildWithReport { public int callbackOrder => 999; public void OnPostprocessBuild(BuildReport report) { if (report.summary.platform != BuildTarget.iOS) return; string projPath = report.summary.outputPath; string plistPath = Path.Combine(projPath, "Info.plist"); // 拷贝图标资源到工程 string srcDir = "Assets/AppIcons/iOS"; string dstDir = Path.Combine(projPath, "AppIcons"); CopyDirectory(srcDir, dstDir); // 注入 CFBundleIcons 配置 var plist = new PlistDocument(); plist.ReadFromFile(plistPath); var icons = plist.root.CreateDict("CFBundleIcons"); // ... 填充备用图标结构 plist.WriteToFile(plistPath); } }这个脚本能省掉大量重复劳动，尤其是图标套数多的时候。
6.4 切换时机的运营设计
技术上跑通只是第一步，什么时候切才是运营要思考的。我总结了几种常见时机：
- 节日自动切换：客户端内置节日表，到日期自动切，用户无感。适合春节、国庆这种全民节日。
- 活动页手动切换：在设置或活动页放一个"更换图标"入口，用户主动选。适合联动 IP、赛季主题。
- 付费解锁：把特殊图标作为付费点或成就奖励，增加用户粘性。
实测下来，手动切换的接受度最高，因为用户有掌控感。自动切换虽然省事，但部分用户会反感"我的手机被改了"。
7. 常见问题与排查技巧实录
7.1 Android 切换后出现两个图标
这是最高频的问题。原因通常是：启用新 alias 时没有禁用旧的，或者旧 alias 的enabled初始值就是 true 且没被禁用。排查方法是adb shell dumpsys package com.yourgame | grep enabled，看有几个组件是 enabled 状态。
解决要点：确保所有非默认 alias 的android:enabled初始值都是false，切换时严格"启用目标 + 禁用其他"。
7.2 Android 切换后图标不刷新
部分国产 ROM（尤其是深度定制的启动器）对组件状态变化响应迟钝。可以尝试发送一个广播触发桌面刷新：
Intent intent = new Intent(Intent.ACTION_MAIN); intent.addCategory(Intent.CATEGORY_HOME); ctx.sendBroadcast(intent);但这个方法不是所有 ROM 都有效，属于尽力而为。产品侧要接受"部分机型需要用户手动刷新桌面"的现实。
7.3 iOS 切换报错 "The requested icon is not available"
这个错误说明setAlternateIconName传的名字在Info.plist里找不到。排查顺序：先确认CFBundleAlternateIcons的 key 拼写，再确认图标文件名是否符合名称+尺寸格式，最后确认 PNG 是否真的被加进了 Bundle（用Xcode -> Build Phases -> Copy Bundle Resources检查）。
7.4 iOS 上架审核被拒
常见拒审原因有两个：图标带 alpha 通道，或者备用图标和主图标差异过大被判定为"功能不符"。前者用图片工具去掉 alpha 即可，后者要在审核备注里说明这是"主题图标功能"，并提供切换入口的截图。
7.5 常见问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| Android 出现双图标 | 多个 alias 同时 enabled | dumpsys 检查组件状态 |
| Android 图标不刷新 | ROM 启动器缓存 | 发 HOME 广播或提示用户 |
| Android 切换后闪退 | 未加 DONT_KILL_APP | 检查 flag 参数 |
| iOS 切换报错 | plist 未声明或名字错 | 核对 CFBundleAlternateIcons |
| iOS 无反应 | 系统版本低于 10.3 | 判断 supportsAlternateIcons |
| iOS 审核被拒 | 图标带 alpha | 重新导出无 alpha PNG |
注意：所有原生调用都要包在 try-catch 里，图标切换失败绝不能影响游戏主流程。我见过因为图标切换抛异常导致启动黑屏的案例，教训深刻。
8. 我踩过的坑和几条实在建议
第一，别在启动流程里做图标切换。启动阶段本来就紧张，再插入原生调用和可能的进程状态变化，容易引发时序问题。放在进入主界面之后，或者用户主动触发时。
第二，图标套数控制在 6 套以内。每套图标在两端都要占包体和审核成本，套数太多管理起来很痛苦。运营上按季度规划，一个季度最多两套。
第三，Android 的 alias 名字和 iOS 的 icon key 保持一致。我一开始两端用了不同的命名，结果配置表要维护两套映射，后来统一成同一套 key，代码清爽很多。
第四，测试一定要覆盖低端机和定制 ROM。模拟器上跑通不代表真机没问题，尤其是国产 ROM 的启动器行为差异很大。我建议至少找三台不同品牌的真机验证。
第五，给用户一个"恢复默认"的选项。有些用户换了图标后想换回来，如果找不到入口会很烦躁。默认图标永远作为一个可选项存在。
这套方案我在两个项目里落地过，Android 侧覆盖了主流机型，iOS 侧顺利过审。核心难点其实不在代码，而在对两端机制的理解和运营时机的把握。把预置资源、切换逻辑、容错降级这三块做扎实，动态图标就是个很稳的功能。后续如果想扩展，可以考虑结合服务端下发配置，让运营在不发版的情况下调整图标切换的日期和规则，这个我下次再单独聊。
