手游上线后想换个图标做活动结果发现应用商店的图标是打包时写死的改一次就得重新提审、重新发版等审核通过活动热度都过了。这个痛点做发行的朋友应该都懂。动态换图标这个需求最早是iOS端先火起来的后来Android端也跟上了现在不少头部产品在节日、周年庆、渠道联运的时候都会用这套方案。我最近刚好在一个Unity项目里把双端都跑通了踩了不少坑这里把完整方案和排查过程整理出来给需要的人一个可以直接抄的参考。这篇内容适合有Unity基础、做过Android或iOS打包的开发者也适合想了解双端原生能力差异的技术负责人。核心会围绕Unity工程如何调用Android的activity-alias机制、iOS的setAlternateIconName接口以及两端在工程配置、权限、审核上的差异展开。读完你应该能自己动手把动态图标接进项目并且知道哪些地方容易翻车。1. 先搞清楚动态图标到底改的是什么很多人一上来就问Unity里怎么换图标其实这个问题问偏了。Unity本身不提供换图标的能力它只是个跨平台引擎真正干活的是两端的原生系统接口。所以正确的思路是Unity负责触发时机和参数传递原生层负责执行替换。理解这一点后面的方案才不会走歪。1.1 Android端改的是组件别名而不是图标文件Android的动态图标机制本质上是利用activity-alias这个清单文件标签。系统桌面启动器在渲染图标时读的是当前被启用的那个activity-alias的icon和label属性。你预先在AndroidManifest.xml里声明多个别名每个别名指向同一个主Activity但配置不同的图标资源。运行时通过PackageManager.setComponentEnabledSetting()启用其中一个、禁用其余桌面图标就会跟着变。这里有个关键点主Activity本身必须保持启用状态被切换的只是别名。如果你把主Activity也禁用了应用会直接崩溃或者无法启动。我见过有人图省事把主Activity的icon也改了结果切换后点图标进不去排查了半天。activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / /intent-filter /activity activity-alias android:name.IconDefault android:targetActivity.MainActivity android:enabledtrue android:exportedtrue android:iconmipmap/ic_launcher android:labelstring/app_name intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity-alias activity-alias android:name.IconFestival android:targetActivity.MainActivity android:enabledfalse android:exportedtrue android:iconmipmap/ic_launcher_festival android:labelstring/app_name intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity-alias注意每个别名都要带完整的intent-filter否则桌面找不到入口。另外android:enabled初始值只能有一个是true其余都是false这是硬性约束。1.2 iOS端改的是备用图标集合iOS这边走的是完全不同的路子。从iOS 10.3开始系统提供了setAlternateIconName:接口允许应用在运行时切换图标。但前提是你必须在Info.plist里用CFBundleAlternateIcons字典预先声明所有备用图标每个图标对应一个名字和图标文件。和Android不同的是iOS的备用图标必须是打包进bundle的资源不能运行时下载替换。而且图标文件有严格的尺寸和格式要求必须是PNG建议提供60x60、120x120、180x180等多个尺寸否则在某些设备上会显示模糊或者不显示。keyCFBundleIcons/key dict keyCFBundlePrimaryIcon/key dict keyCFBundleIconFiles/key array stringAppIcon60x60/string /array /dict keyCFBundleAlternateIcons/key dict keyFestivalIcon/key dict keyCFBundleIconFiles/key array stringFestivalIcon60x60/string /array keyUIPrerenderedIcon/key false/ /dict /dict /dictFestivalIcon这个名字就是后面代码里要传的参数必须和plist里的key完全一致大小写敏感。1.3 两端机制差异带来的设计约束把两端放在一起看你会发现它们的约束条件完全不同这直接决定了你的产品方案能做成什么样。对比维度AndroidiOS图标来源打包内置资源打包内置资源声明方式AndroidManifest的activity-aliasInfo.plist的CFBundleAlternateIcons切换接口setComponentEnabledSettingsetAlternateIconName数量限制理论上无硬限制系统建议不超过10个切换生效立即生效桌面刷新立即生效可能弹系统提示审核风险较低需说明用途可能被问询最要命的是iOS那个系统提示。调用setAlternateIconName时系统会弹一个您已更改XX的图标的alert这个提示无法通过公开API屏蔽。网上有些取巧的办法但都有被拒风险我不建议用。产品设计时要把这个提示考虑进去最好在用户主动点击切换图标后再触发而不是App启动时偷偷换。2. Unity工程侧的统一调用层怎么搭两端原生接口不一样如果每个业务代码都去写#if UNITY_ANDROID和#if UNITY_IOS维护起来会疯掉。我的做法是在Unity层封装一个统一接口业务只调一个方法平台差异全部藏在底层。2.1 定义C#侧的接口和平台分发先定义一个静态类作为入口参数就用字符串标识图标名两端各自映射。public static class AppIconChanger { public static void ChangeIcon(string iconKey) { #if UNITY_ANDROID !UNITY_EDITOR using (var unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer)) using (var activity unityPlayer.GetStaticAndroidJavaObject(currentActivity)) using (var iconUtil new AndroidJavaClass(com.yourgame.IconUtil)) { iconUtil.CallStatic(changeIcon, activity, iconKey); } #elif UNITY_IOS !UNITY_EDITOR _ChangeIconiOS(iconKey); #else Debug.Log($[Editor] 模拟切换图标: {iconKey}); #endif } [System.Runtime.InteropServices.DllImport(__Internal)] private static extern void _ChangeIconiOS(string iconName); }这里有个细节iconKey在Android端对应的是activity-alias的完整类名比如com.yourgame.IconFestival在iOS端对应的是plist里的key比如FestivalIcon。为了统一我在C#层做了一个映射表业务传festival这种语义化名字底层再转成各平台的实际标识。private static readonly Dictionarystring, string AndroidMap new Dictionarystring, string { { default, com.yourgame.IconDefault }, { festival, com.yourgame.IconFestival }, { anniversary, com.yourgame.IconAnniversary } }; private static readonly Dictionarystring, string iOSMap new Dictionarystring, string { { default, null }, // null表示恢复主图标 { festival, FestivalIcon }, { anniversary, AnniversaryIcon } };iOS恢复默认图标传null给setAlternateIconName这点和Android不一样Android是启用默认别名。2.2 Android原生插件的实现细节Android侧我写了一个IconUtil类编译成aar或者直接放Plugins/Android目录下。核心逻辑就是遍历所有别名启用目标、禁用其他。public class IconUtil { public static void changeIcon(Activity activity, String aliasName) { PackageManager pm activity.getPackageManager(); String pkg activity.getPackageName(); String[] allAliases { pkg .IconDefault, pkg .IconFestival, pkg .IconAnniversary }; for (String alias : allAliases) { int newState alias.equals(aliasName) ? PackageManager.COMPONENT_ENABLED_STATE_ENABLED : PackageManager.COMPONENT_ENABLED_STATE_DISABLED; pm.setComponentEnabledSetting( new ComponentName(pkg, alias), newState, PackageManager.DONT_KILL_APP ); } } }DONT_KILL_APP这个flag非常重要。如果不加切换图标时系统会杀掉应用进程用户体验极差。加上之后进程保留但桌面图标刷新可能有延迟通常几百毫秒到几秒不等取决于启动器实现。注意部分国产ROM比如某些定制系统对setComponentEnabledSetting的响应不一致可能出现图标不刷新或者刷新后点击无响应的情况。实测下来切换后主动发一个桌面刷新广播能缓解但不是所有启动器都监听这个广播。2.3 iOS原生插件的实现细节iOS侧写一个.mm文件放在Plugins/iOS目录导出C函数给Unity调用。#import UIKit/UIKit.h extern C void _ChangeIconiOS(const char* iconName) { NSString *name [NSString stringWithUTF8String:iconName]; UIApplication *app [UIApplication sharedApplication]; if (![app supportsAlternateIcons]) { NSLog([IconChanger] 当前系统不支持备用图标); return; } NSString *targetName [name isEqualToString:default] ? nil : name; [app setAlternateIconName:targetName completionHandler:^(NSError * _Nullable error) { if (error) { NSLog([IconChanger] 切换失败: %, error.localizedDescription); } else { NSLog([IconChanger] 切换成功: %, name); } }]; }supportsAlternateIcons这个检查不能省虽然iOS 10.3以上都支持但保险起见还是判断一下。另外setAlternateIconName必须在主线程调用Unity调用原生代码默认就在主线程一般没问题但如果你在子线程触发就要注意了。2.4 编辑器下的模拟与调试开发阶段不可能每次都打包真机测试所以我在#else分支里做了个模拟把当前图标名存到PlayerPrefs然后在编辑器里用EditorGUI画个预览。这样策划调图标切换逻辑时不用等打包直接在编辑器里就能验证流程。#if UNITY_EDITOR [UnityEditor.InitializeOnLoad] public static class IconEditorPreview { static IconEditorPreview() { // 在Game视图角落显示当前模拟图标 } } #endif这个模拟层虽然简单但省下的打包时间非常可观。一个完整的Android包动辄几分钟iOS更久有了模拟层逻辑验证阶段基本不用出包。3. 图标资源准备与打包配置的坑方案跑通只是第一步真正让人头疼的是资源准备和打包配置。这部分我踩的坑最多单独拎出来讲。3.1 Android图标资源的密度适配Android的mipmap目录有mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi五档每档图标尺寸不同。如果你只放一张图系统会拉伸在高分屏上糊得没法看。密度目录图标尺寸适用设备mipmap-mdpi48x48低端机mipmap-hdpi72x72中端机mipmap-xhdpi96x96主流机型mipmap-xxhdpi144x144高分屏mipmap-xxxhdpi192x192旗舰机我的做法是让美术出一张1024x1024的源图然后用脚本批量生成各档尺寸。Unity这边可以用AssetPostprocessor自动处理或者干脆在Android Studio里用Image Asset工具生成。另外Android 8.0以后支持自适应图标Adaptive Icon需要提供前景和背景两层。如果你的目标版本包含8.0以上建议同时配置mipmap-anydpi-v26目录下的XML否则系统可能会给你的图标加个白底或者裁切。!-- mipmap-anydpi-v26/ic_launcher_festival.xml -- adaptive-icon xmlns:androidhttp://schemas.android.com/apk/res/android background android:drawablecolor/icon_bg/ foreground android:drawablemipmap/ic_launcher_festival_fg/ /adaptive-icon3.2 iOS备用图标的命名与尺寸陷阱iOS这边最容易踩的坑是命名。CFBundleAlternateIcons里的key是逻辑名但CFBundleIconFiles数组里填的是实际文件名不带扩展名。这两个名字可以不一样但必须和bundle里的资源文件对应上。我遇到过一次切换后图标变成白板的情况排查发现是CFBundleIconFiles里写的文件名和实际放进bundle的文件名差了一个大小写。iOS的文件系统在打包后是大小写敏感的这个坑很隐蔽。尺寸方面iOS备用图标建议至少提供以下规格60x601x老设备120x1202x主流180x1803xPlus和全面屏如果只提供一张系统会缩放但缩放质量不如原生尺寸。我一般让美术出180x180的然后脚本降采样生成另外两张。3.3 Unity打包时的资源剥离问题Unity在打包时会做资源剥离Strip Engine Code和资源压缩有时候会把你放在Plugins/Android/res下的图标资源当成无用资源删掉。我遇到过一次打包后图标资源丢失切换时直接崩溃。解决办法有两个一是把图标资源放在Assets/Plugins/Android/res下并在mainTemplate.gradle里确保不被混淆二是用自定义gradle模板把资源目录显式声明。我推荐第二种可控性更强。// mainTemplate.gradle android { sourceSets { main { res.srcDirs [src/main/res, src/festival/res] } } }iOS这边相对简单资源直接放Plugins/iOS下Unity会自动拷进Xcode工程。但要注意Xcode工程的Copy Bundle Resources里必须包含这些图标文件有时候Unity生成的工程会漏掉需要手动加或者写PostProcessBuild脚本自动处理。4. 切换时机与用户体验的取舍技术跑通之后真正难的是产品层面的决策什么时候换、怎么换、换了之后怎么让用户知道。这部分没有标准答案我分享几个实测下来比较稳的做法。4.1 主动切换优于被动切换最理想的方式是在设置页放一个更换图标入口让用户自己选。这样既符合iOS的系统提示逻辑用户主动操作弹提示不突兀也避免了App偷偷换图标带来的不信任感。具体做法是在设置页列出所有可用图标每个图标配一个预览图用户点击后调用AppIconChanger.ChangeIcon()。切换成功后给个Toast提示iOS那边系统alert会自己弹不用额外处理。4.2 活动驱动的自动切换要谨慎有些运营需求是节日期间自动换图标这个在Android上可以做因为切换无感。但iOS上如果App启动时自动切换会弹系统alert用户会一脸懵。我的建议是iOS端不做自动切换或者只在用户打开App且停留超过一定时间后用一个小气泡引导用户点击更换节日图标把主动权交给用户。Android端自动切换也要注意如果用户在活动结束后没打开过App图标会一直停留在节日版。所以最好在活动结束后的首次启动时切回默认并且记录一个本地标记避免重复切换。4.3 切换状态的持久化与恢复用户切换图标后这个状态是存在系统里的App重装或者清除数据后会恢复默认。但有一种情况要注意Android上如果用户把App移到SD卡或者做了某些系统优化操作activity-alias的启用状态可能被重置。所以每次App启动时最好读一下当前启用的别名和本地记录的状态做比对不一致就以系统为准更新本地记录。public static string GetCurrentIconKey() { #if UNITY_ANDROID !UNITY_EDITOR // 通过PackageManager查询当前启用的alias // 返回对应的语义化key #elif UNITY_IOS !UNITY_EDITOR string current _GetCurrentIconiOS(); return string.IsNullOrEmpty(current) ? default : current; #else return PlayerPrefs.GetString(current_icon, default); #endif }iOS端可以用alternateIconName属性直接读当前图标名为nil就是默认图标。5. 审核与合规两端都不能忽视的红线动态图标这个功能技术上不难难的是过审。两端应用商店对这个功能的态度不太一样我分别说。5.1 iOS审核的注意事项iOS对备用图标的态度是允许但需说明。提交审核时建议在审核备注里写清楚这个功能的用途比如用于节日活动期间让用户自主更换App图标提升用户参与感。如果审核员问询要能提供图标切换的入口截图。有几个雷区千万别碰一是用备用图标伪装成其他App这个直接拒二是切换图标后功能发生变化比如切到某个图标就解锁隐藏功能这属于功能开关容易被判定为规避审核三是备用图标里包含违规内容。另外CFBundleAlternateIcons的数量别太多系统虽然没有硬性限制但超过10个可能会引起审核员注意。我一般控制在5个以内。5.2 Android审核的注意事项Android这边相对宽松activity-alias是官方支持的机制只要你的图标内容合规一般不会因为用了这个机制被拒。但要注意两点一是别用这个机制做应用双开或者隐藏应用之类的功能这违反政策二是如果切换图标后App名称也变了要确保新名称不侵权、不误导。国内应用商店对图标切换的审核尺度不一有的商店会要求你说明用途。我的经验是如果只是节日活动换图标正常提审基本没问题如果涉及频繁切换或者和活动强绑定最好提前和商店沟通。5.3 版本兼容的兜底策略不是所有设备都支持动态图标。Android 5.0以下没有setComponentEnabledSetting的完整支持iOS 10.3以下没有setAlternateIconName。虽然现在这些老系统占比很低但代码里还是要做判断不支持就静默失败别崩溃。public static bool IsIconChangeSupported() { #if UNITY_ANDROID !UNITY_EDITOR // 检查API Level 21 using (var version new AndroidJavaClass(android.os.Build$VERSION)) { return version.GetStaticint(SDK_INT) 21; } #elif UNITY_IOS !UNITY_EDITOR return _SupportsAlternateIcons(); #else return true; #endif }6. 实测中遇到的几个典型问题与排查过程这部分是我踩坑的实录每个问题都附上排查思路方便你遇到类似情况时对照。6.1 Android切换后图标不刷新现象调用切换接口后代码返回成功但桌面图标没变重启桌面后才更新。排查过程先确认setComponentEnabledSetting的返回值发现是COMPONENT_ENABLED_STATE_ENABLED说明设置成功了。然后怀疑是启动器缓存问题换了几台设备测试发现部分国产ROM确实不监听组件变更广播。解决方案切换后主动发一个Intent.ACTION_PACKAGE_CHANGED广播或者用ShortcutManager触发一次快捷方式更新间接促使桌面刷新。实测在大部分设备上能立即生效少数顽固的只能等系统自己刷新。Intent intent new Intent(Intent.ACTION_PACKAGE_CHANGED); intent.setData(Uri.parse(package: pkg)); activity.sendBroadcast(intent);6.2 iOS切换后图标显示为白板现象调用setAlternateIconName成功但图标位置显示一个白色方块。排查过程检查CFBundleIconFiles里的文件名发现和实际资源文件名不一致。进一步发现是Xcode打包时把图标文件重命名了因为文件名里带了特殊字符。解决方案图标文件名只用字母、数字和下划线别用中文、空格、连字符。改完重新打包问题消失。6.3 Unity打包后Android别名丢失现象编辑器里测试正常打包成APK后切换图标无效反编译APK发现activity-alias节点没了。排查过程检查AndroidManifest.xml发现Unity在合并manifest时把自定义的alias节点过滤掉了。原因是Unity的manifest合并规则对未知节点处理不一致。解决方案把alias配置写进Assets/Plugins/Android/AndroidManifest.xml并在mainTemplate.gradle里确保这个manifest被正确合并。或者用[Preserve]属性标记相关类防止被剥离。6.4 切换图标后App启动崩溃现象Android上切换图标后点击新图标启动App直接闪退。排查过程看logcat发现是ClassNotFoundException找不到主Activity。原因是主Activity被误禁用了或者alias的targetActivity写错了。解决方案确保主Activity始终处于enabled状态alias的targetActivity必须和主Activity的完整类名一致。另外检查混淆配置别把Activity类名混淆了。-keep public class * extends android.app.Activity -keep class com.yourgame.MainActivity { *; }6.5 iOS系统提示无法屏蔽的应对现象每次切换图标都弹系统alert产品经理要求去掉。排查过程查了公开API确认没有合法方式屏蔽。网上有些用runtime替换presentViewController的方案但风险极高。解决方案和产品沟通把切换入口做成用户主动触发并且在UI上提前告知切换后系统会弹出确认提示点击确定即可。用户有预期后接受度会高很多。硬要去掉提示得不偿失。7. 一些可以复用的工程化建议最后分享几个把方案落地到项目里的工程化经验都是实际项目里验证过的。7.1 图标配置表驱动别把图标名硬编码在代码里用一张配置表管理。我用的是ScriptableObject策划可以直接在Unity里配。[CreateAssetMenu(fileName IconConfig, menuName AppIcon/Config)] public class IconConfig : ScriptableObject { [System.Serializable] public class IconEntry { public string key; // 语义化key public string displayName; // 显示名 public Sprite preview; // 预览图 public string androidAlias; // Android别名 public string iOSName; // iOS图标名 } public ListIconEntry icons; }这样新增一个图标只需要加一行配置、放一张图不用改代码。7.2 切换流程的埋点动态图标是个运营功能效果需要数据支撑。我在切换成功、切换失败、用户查看图标列表这几个节点都加了埋点方便后续分析哪些图标受欢迎、切换转化率如何。埋点字段建议包含当前图标key、目标图标key、平台、系统版本、是否成功、失败原因。这些数据对后续活动策划很有参考价值。7.3 灰度与回滚新图标上线前建议先小流量灰度观察崩溃率和用户反馈。如果发现问题能快速回滚到默认图标。回滚逻辑很简单就是调用ChangeIcon(default)但要确保这个操作在异常情况下也能执行比如放在try-catch里。public static void SafeRollback() { try { ChangeIcon(default); } catch (System.Exception e) { Debug.LogError($[IconChanger] 回滚失败: {e.Message}); } }7.4 文档与交接动态图标这个功能涉及Unity、Android、iOS三端交接时容易漏。我一般会写一份简短的接入文档包含图标配置表位置、新增图标的步骤、两端资源目录、常见问题排查。这样即使换人维护也能快速上手。我个人在实际项目里的体会是动态图标这个功能技术复杂度不高但跨端协作和细节处理很磨人。真正决定成败的不是代码写得多漂亮而是资源准备是否规范、打包配置是否正确、审核沟通是否到位。把这几块做扎实剩下的就是按部就班地接入了。