企业官网建设流程全解析

1. 动态图标这件事，到底在解决什么问题

做过手游运营的人都有一个共识：图标是产品在用户手机桌面上唯一的“免费广告位”。一个玩家装了你的游戏，哪怕三天没点开，只要图标还在桌面上，就有被想起来的机会。但静态图标的问题是，它永远长一个样，节日活动、版本更新、联动企划这些运营节点，用户是感知不到的——除非他主动点进来。

动态更换 App 图标要解决的就是这件事：让桌面上的图标本身成为运营内容的一部分。春节换成红金配色，周年庆换成限定立绘，联动期间换成 IP 角色，甚至可以根据玩家在游戏内的进度解锁不同图标。这套玩法在日本手游里已经很成熟了，国内也有不少产品在做，但真正落到 Unity 工程里，Android 和 iOS 两端的实现路径差异很大，坑也不少。

这篇文章面向的是有 Unity 手游开发经验、需要落地动态图标功能的客户端同学。我会把 Android 的activity-alias方案和 iOS 的setAlternateIconName方案完整拆开讲，包括 Unity 侧怎么和原生层通信、图标资源怎么组织、切换时机的选择、以及我在实际项目里踩过的那些坑。看完你应该能直接在自己的工程里复现一套可用的方案。

先说结论：Android 靠activity-alias预注册多个入口，通过PackageManager控制启用状态；iOS 靠系统提供的setAlternateIconNameAPI，图标资源需要在 Xcode 工程里预先配置好。两端都不是“运行时随便换一张图”那么简单，本质都是预置多套图标 + 运行时切换激活项。理解了这个本质，后面的实现就顺了。

2. 双端方案的整体设计与选型考量

2.1 为什么不能“运行时动态生成图标”

很多刚接触这个需求的同学第一反应是：能不能在运行时把一张图片写进某个目录，然后让系统读它当图标？答案是两端都不行，原因不同但结论一致。

Android 的桌面图标是由Launcher（桌面应用）通过PackageManager查询Activity的icon属性渲染的，这个属性在AndroidManifest.xml里声明，属于安装时就确定的静态信息。你运行时改不了已安装 APK 的 manifest。iOS 更严格，图标资源在打包时就编译进了Assets.car，系统只认 bundle 里预先注册好的那几套。

所以正确的思路是：打包时预置 N 套图标，运行时告诉系统“现在用第几套”。Android 通过启用/禁用不同的activity-alias来切换，iOS 通过setAlternateIconName指定当前使用哪套备选图标。这个认知是后面所有实现的基础，绕不过去。

2.2 Android 与 iOS 的机制差异对比

两端虽然目标一致，但底层机制差别很大，直接决定了工程组织方式的不同。我整理了一张对比表，方便你快速建立整体印象：

这张表里有两个点需要特别强调。第一，iOS 切换图标时系统会强制弹一个提示框，这是系统行为，无法屏蔽，产品经理如果要求“无感切换”你要提前沟通清楚。第二，Android 的activity-alias数量虽然没有硬限制，但每多一个 alias 就多一个组件注册，过多会影响安装速度和桌面加载，实践中控制在 5 到 8 套比较合理。

2.3 Unity 层的架构设计

Unity 作为跨平台引擎，本身不提供动态图标 API，所以必须走原生插件这条路。我的建议是设计一个统一的 C# 接口层，把两端差异屏蔽掉，业务层只调用一个方法：

public static class AppIconManager { public static void SetIcon(string iconKey) { #if UNITY_ANDROID && !UNITY_EDITOR using (var jc = new AndroidJavaClass("com.yourgame.icon.IconHelper")) { jc.CallStatic("setIcon", iconKey); } #elif UNITY_IOS && !UNITY_EDITOR IconHelperIOS.SetIcon(iconKey); #endif } }

iconKey是一个字符串标识，比如"default"、"spring_festival"、"anniversary"，两端各自维护 key 到具体资源的映射。这样业务层完全不用关心平台差异，运营配置表里直接写 key 就行。这个设计的关键在于key 的命名规范要统一，Android 的 alias name 和 iOS 的 alternate icon name 都基于同一个 key 派生，避免两边对不上。

3. Android 端 activity-alias 方案详解

3.1 activity-alias 的工作原理

activity-alias是 Android manifest 里的一个组件声明，它可以给一个已存在的 Activity 起一个“别名”，并且这个别名可以有自己的 icon、label 和 enabled 状态。桌面 Launcher 在扫描应用时，会把所有enabled=true且带MAIN/LAUNCHERintent-filter 的组件都列出来作为入口。

关键点在于：同一时刻只应该有一个 alias 处于 enabled 状态，否则桌面上会出现多个图标。默认情况下，主 Activity 自己是 enabled 的，所有 alias 都是 disabled。切换图标时，先禁用当前启用的那个，再启用目标 alias，系统就会用新 alias 的 icon 重新渲染桌面图标。

这个机制有个副作用：切换瞬间桌面图标会消失再出现，视觉上有个闪烁。实测在大部分主流 Launcher 上这个闪烁很短，用户基本无感，但在某些定制 ROM 上可能会明显一些。这是方案本身的限制，没有完美规避办法。

3.2 AndroidManifest 的配置写法

假设你的主 Activity 是com.unity3d.player.UnityPlayerActivity，我们要预置三套图标：默认、春节、周年庆。manifest 大致长这样：

<activity android:name="com.unity3d.player.UnityPlayerActivity" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity-alias android:name=".icon.Default" android:targetActivity="com.unity3d.player.UnityPlayerActivity" android:icon="@mipmap/ic_launcher_default" android:label="@string/app_name" android:enabled="true" android:exported="true"> <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.SpringFestival" android:targetActivity="com.unity3d.player.UnityPlayerActivity" android:icon="@mipmap/ic_launcher_spring" android:label="@string/app_name" android:enabled="false" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity-alias>

这里有个容易踩的坑：主 Activity 自己也要处理。如果你把主 Activity 的 LAUNCHER intent-filter 保留着，同时又启用了 alias，桌面会出现两个图标。正确做法是把主 Activity 的 LAUNCHER filter 去掉，完全交给 alias 来承担入口职责，默认 alias 设为 enabled。这样任何时刻都只有一个入口生效。

注意：修改 manifest 后如果测试发现桌面出现双图标，先检查主 Activity 是否还残留 LAUNCHER intent-filter。这是最高频的问题。

3.3 原生层切换逻辑的实现

Android 侧的 Java 代码核心就是操作PackageManager的组件启用状态。下面是一个可用的实现：

package com.yourgame.icon; import android.content.ComponentName; import android.content.Context; import android.content.pm.PackageManager; public class IconHelper { private static final String PKG = "com.yourgame.app"; private static final String[] ALL_ALIAS = { "com.yourgame.app.icon.Default", "com.yourgame.app.icon.SpringFestival", "com.yourgame.app.icon.Anniversary" }; public static void setIcon(String iconKey) { Context ctx = getActivity(); PackageManager pm = ctx.getPackageManager(); String target = PKG + ".icon." + mapKey(iconKey); for (String alias : ALL_ALIAS) { int state = alias.equals(target) ? PackageManager.COMPONENT_ENABLED_STATE_ENABLED : PackageManager.COMPONENT_ENABLED_STATE_DISABLED; pm.setComponentEnabledSetting( new ComponentName(PKG, alias), state, PackageManager.DONT_KILL_APP); } } private static String mapKey(String key) { switch (key) { case "spring_festival": return "SpringFestival"; case "anniversary": return "Anniversary"; default: return "Default"; } } }

DONT_KILL_APP这个 flag 很重要，它保证切换组件状态时不会杀掉当前进程。如果不加，切换图标会导致游戏进程被杀，玩家正在玩的局就没了，这是绝对不能接受的。实测加上这个 flag 后切换是平滑的，游戏不受影响。

3.4 状态持久化与冷启动恢复

setComponentEnabledSetting设置的状态是持久化的，系统会记住，重启手机也有效。但有个问题：如果玩家卸载重装，状态会重置为 manifest 里的初始值，也就是默认图标。所以你的游戏需要在启动时检查一遍当前应该用哪套图标，如果和实际不符就纠正过来。

我的做法是在游戏启动的初始化流程里，读取本地存储的“当前图标 key”，和运营配置的“当前应该用的 key”比对，不一致就调用一次SetIcon。这样即使玩家重装了，第一次进游戏后图标也会自动纠正。注意这个纠正动作放在启动流程靠后的位置，不要阻塞首屏加载。

4. iOS 端 setAlternateIconName 方案详解

4.1 备选图标的预置方式

iOS 的动态图标走的是setAlternateIconName这条路，前提是在 Xcode 工程里预先声明好所有备选图标。有两种配置方式：一种是在Info.plist里手动写CFBundleAlternateIcons字典，另一种是在 Xcode 的 Assets Catalog 里配置。我推荐后者，因为可视化配置不容易出错，而且 Xcode 会自动处理尺寸切图。

具体操作是在 Unity 导出的 Xcode 工程的Assets.xcassets里，为每个备选图标建一个 AppIcon 类型的 asset，命名比如AppIcon_Spring、AppIcon_Anniversary。然后在 target 的 Build Settings 里确认Include All App Icon Assets打开，或者在 Info.plist 里显式声明。

这里有个尺寸的坑：iOS 的 App Icon 需要多个尺寸，从 20pt 到 1024pt 一共十几个规格。如果手动切图很容易漏，建议用一套脚本从 1024 的源图自动生成所有尺寸。Unity 侧可以用 Editor 脚本在构建后处理，也可以让美术直接出全套。

4.2 Unity 与 iOS 原生通信

iOS 侧需要写一个 Objective-C 或 Swift 的桥接文件，暴露一个 C 函数给 Unity 调用。下面是 Objective-C 的实现：

#import <UIKit/UIKit.h> extern "C" void _SetAppIcon(const char* iconName) { NSString *name = [NSString stringWithUTF8String:iconName]; if ([name isEqualToString:@"default"]) { name = nil; } if (![UIApplication sharedApplication].supportsAlternateIcons) { return; } NSString *current = [UIApplication sharedApplication].alternateIconName; if ((name == nil && current == nil) || [name isEqualToString:current]) { return; } [[UIApplication sharedApplication] setAlternateIconName:name completionHandler:^(NSError *error) { if (error) { NSLog(@"[AppIcon] switch failed: %@", error); } }]; }

C# 侧用DllImport调用：

#if UNITY_IOS && !UNITY_EDITOR [DllImport("__Internal")] private static extern void _SetAppIcon(string iconName); #endif

注意setAlternateIconName传nil表示恢复默认图标，所以 key 为"default"时要转成nil。另外这个 API 必须在主线程调用，Unity 的 C# 调用默认就在主线程，一般没问题，但如果你在子线程里触发切换就要注意切回主线程。

4.3 系统弹窗的处理

iOS 切换图标时系统会弹一个“您已更改‘XXX’的图标”的提示框，这是系统强制行为，无法通过公开 API 屏蔽。产品如果坚持要无感，只能走一些非正规手段（比如在弹窗出现的瞬间切换 keyWindow），但这类做法有审核风险，我不建议在正式项目里用。

我的处理方式是提前和产品沟通，把这个弹窗当成“切换成功的反馈”来用。实际上玩家看到这个提示反而知道图标换了，体验上不算负面。如果实在想弱化，可以控制切换频率，比如一个版本只换一两次，而不是每次进游戏都检查。

提示：iOS 模拟器对setAlternateIconName的支持不完整，测试务必用真机。这是我在项目里浪费过半天时间的教训。

5. 图标资源组织与切换时机设计

5.1 资源命名与目录规范

两端资源要统一管理，否则运营配一套图，客户端要手动对应到两个平台，很容易出错。我的建议是建立一套命名规范，以 key 为核心：

• Android：mipmap-xxhdpi/ic_launcher_{key}.png，manifest 里 alias name 用{Key}驼峰
• iOS：AppIcon_{Key}asset，setAlternateIconName传AppIcon_{Key}

key 本身用下划线小写，比如spring_festival。这样从运营配置表到两端资源的映射是机械的、可脚本化的。我甚至写过一个 Editor 工具，读取配置表自动生成 Android 的 manifest 片段和 iOS 的 asset 目录结构，美术只要按规范放图就行。

5.2 切换时机的选择

什么时候切换图标，这个决策比技术实现更影响效果。常见的几种时机：

第一种是跟随运营活动，活动开始当天切换，结束切回。这种最直观，但要注意活动开始时间如果是凌晨，玩家可能第二天才看到，可以配合推送提醒。

第二种是跟随玩家进度解锁，比如通关某章节解锁限定图标。这种能提升玩家的收集欲，但需要 UI 让玩家自己选择用哪套，否则自动切换会让玩家困惑“我的图标怎么变了”。

第三种是玩家手动选择，在设置里提供图标切换入口。这种最可控，但需要额外的 UI 开发，而且 iOS 每次切换都弹窗，玩家频繁切换体验不好。

我实际项目里用的是第一种加第三种：活动期间自动切，同时设置里保留手动切换入口让玩家可以选回默认。这样既保证了运营曝光，又尊重了玩家选择权。

5.3 首次启动的默认状态处理

新装用户第一次启动时，图标是打包时的默认图标。如果此时正好有活动，需要在启动流程里切到活动图标。但这里有个体验问题：玩家刚装完游戏，第一次打开，退出后发现图标变了，会觉得奇怪。

我的处理是首次启动不切换，等玩家完成新手引导后再切。这样玩家对游戏已经有认知了，图标变化不会造成困惑。具体实现就是在新手引导完成的回调里触发一次图标检查。这个细节看似小，但对新用户的第一印象影响不小。

6. 实操中的常见问题与排查技巧

6.1 Android 端高频问题速查

这里面“部分机型不生效”是最头疼的。某些国产 ROM 的 Launcher 会缓存图标，切换后不刷新。我试过的缓解办法是切换后发一个广播通知 Launcher 刷新，但效果因 ROM 而异。如果遇到顽固的，只能在游戏内提示玩家“图标将在下次重启桌面后更新”。这是 Android 生态碎片化的老问题，没有银弹。

6.2 iOS 端高频问题速查

iOS 这边问题相对少，但有几个必踩的：

第一个是图标资源缺失。如果setAlternateIconName传了一个不存在的 name，completionHandler 会返回 error，但不会崩溃，图标保持不变。所以一定要在 completionHandler 里打日志，否则你会以为切换成功了其实没有。

第二个是审核问题。App Store 审核指南对动态图标没有明确禁止，但如果你的备选图标和主图标差异过大，或者包含误导性内容，可能被拒。我的经验是备选图标保持和主图标一致的视觉风格，只是配色或元素变化，这样最安全。

第三个是iPad 兼容。iPad 的图标尺寸和 iPhone 不同，如果你的游戏支持 iPad，备选图标要准备 iPad 规格的切图，否则在 iPad 上切换会失败或显示异常。

6.3 跨平台测试清单

上线前建议按这个清单过一遍：

• Android 各主流 ROM（小米、华为、OPPO、vivo）真机测试切换
• Android 冷启动、热启动、杀进程后重启的状态一致性
• iOS 真机（非模拟器）切换，确认弹窗和图标变化
• iOS 卸载重装后的默认状态
• 两端同时有活动时，切换逻辑不冲突
• 切换过程中游戏进程不被杀、不卡顿
• 图标资源在各分辨率下清晰无拉伸

这份清单是我踩坑踩出来的，尤其是 ROM 兼容那一条，模拟器和原生系统测着都没问题，一到真机就出幺蛾子。

7. 一些实操心得和后续扩展方向

动态图标这个功能，技术实现本身不算复杂，难的是把两端差异抹平、把运营流程打通、把各种边界情况处理好。我在项目里最大的体会是：不要把它当成一个纯技术需求，要当成一个运营能力来建设。技术侧提供稳定的切换接口和资源管理规范，运营侧才能放心地把它用起来。

后续可以扩展的方向有几个。一是把图标切换和推送结合，切换图标的同时发一条推送告诉玩家“新图标已上线”，提升感知。二是做图标解锁系统，把图标作为游戏内成就的奖励，增加收集乐趣。三是做 A/B 测试，不同玩家群体用不同图标，看哪个点击率更高。这些都是在基础能力之上的运营玩法，技术底座搭好了，上层怎么玩都行。

最后分享一个小技巧：Android 的 alias 切换其实可以做到“预加载”，就是在游戏启动时就把所有 alias 的 icon 资源加载好，切换时直接改状态，这样闪烁会更短。具体做法是在 Application 的 onCreate 里遍历一遍所有 alias 的 icon，触发系统缓存。这个优化在低端机上效果比较明显，高端机感知不强，可以按需使用。