企业官网建设流程全解析

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

做过手游运营的人大概都遇到过这种场景：春节要换喜庆图标，情人节要换粉色图标，跟某个品牌联名要换联名款图标，甚至某些渠道要求首发期间用特定图标。如果每次都要重新打包提审，那运营节奏基本就废了——安卓渠道几十个包要重新出，iOS还要等审核，等活动上线黄花菜都凉了。

动态更换App图标这个需求，本质上就是让App在不重新安装、不重新提审的前提下，把桌面上那个图标换成另一张图。听起来简单，但Android和iOS两端的实现机制完全不同，坑也完全不一样。Android靠的是activity-alias这个组件的启用与禁用，iOS靠的是系统提供的setAlternateIconName接口。Unity作为跨平台引擎，本身并没有封装这套能力，需要我们自己写原生插件桥接。

这篇文章适合三类人看：一是正在做手游运营活动、需要动态换图标的一线开发；二是想了解Unity与原生平台交互方式的工程师；三是技术负责人，需要评估这个方案的成本和风险。我会把Android和iOS两端的完整实现路径、参数配置、踩坑记录都摊开讲，代码可以直接抄。

先说结论：Android端灵活度极高，可以做到秒级切换、无需重启；iOS端受系统限制较多，切换时会有系统弹窗提示，且必须提前在Info.plist里声明所有备选图标。两端都需要在Unity侧做一层统一封装，让业务层调用起来无感知。

2. 整体方案设计与技术选型思路

2.1 为什么不用"替换资源文件"这种土办法

我见过有人尝试在运行时直接替换APK里的图标资源，或者用反射去改PackageManager里的信息。这条路在Android上理论可行但极其危险：一是需要root权限，普通用户根本用不了；二是会破坏应用签名校验，导致应用被系统判定为篡改；三是不同ROM行为不一致，兼容性灾难。所以正规做法一定是走系统提供的官方接口。

Android官方给的方案就是activity-alias。它的原理是：你可以在AndroidManifest里为同一个Activity声明多个别名，每个别名可以有自己的android:icon和android:label。系统桌面显示的图标，实际上是这些别名中当前处于启用状态的那一个。你只要动态地启用目标别名、禁用其他别名，桌面图标就会跟着变。这个机制从Android 1.0时代就存在，稳定性和兼容性都经过了十几年验证。

iOS的方案是UIApplication的setAlternateIconName:completionHandler:方法，从iOS 10.3开始提供。它的原理是：你在Info.plist的CFBundleIcons字典里预先声明所有备选图标，运行时通过这个接口告诉系统"我要用第几个"。系统会自己处理图标切换，但会弹一个"您已更改'XX'的图标"的提示框，这个提示无法去掉，是系统行为。

2.2 Unity侧的统一封装思路

Unity本身不提供任何图标切换API，所以我们必须写原生插件。整体架构分三层：

• Unity业务层：调用一个统一的AppIconChanger.SetIcon(string iconKey)方法，传入图标标识。
• C#桥接层：通过AndroidJavaObject调用Android的Java方法，通过DllImport调用iOS的Objective-C方法。
• 原生实现层：Android用Java写一个工具类操作PackageManager，iOS用Objective-C写一个类调用setAlternateIconName。

这样设计的好处是业务层完全不用关心平台差异，换图标就像调一个普通方法一样简单。下面这张表对比了两端的核心差异，先有个整体印象：

2.3 方案选型中容易忽略的考量点

第一个考量点是图标资源的存放位置。Android的别名图标必须放在res/mipmap目录下，作为编译期资源打包进APK，不能从网络下载后动态设置。这意味着每增加一个备选图标，APK体积就会增加。一个中等复杂度的图标，各密度加起来大概50到200KB，如果准备20个活动图标，APK可能膨胀2到4MB。这个成本要在方案设计阶段就评估清楚。

第二个考量点是iOS的弹窗体验。很多产品经理第一次听到"切换图标会弹系统提示"时是拒绝的，觉得破坏用户体验。但这个弹窗无法绕过，只能接受。实际做法是在弹窗出现前先给用户一个自定义的确认弹窗，用户点确认后再调用系统接口，这样系统弹窗就变成了"二次确认"，心理上更容易接受。

第三个考量点是状态持久化。用户切换图标后，如果App被卸载重装，图标会恢复默认。如果用户换了设备，也不会同步。所以图标状态需要存在本地，App启动时读取并确保当前图标与记录一致。Android端尤其要注意：如果用户在系统设置里手动改了图标（部分ROM支持），你的记录就和实际不一致了，启动时需要做一次校正。

3. Android端核心实现细节拆解

3.1 AndroidManifest中的activity-alias配置

这是整个Android方案的基石。假设你的主Activity是com.example.game.MainActivity，你想准备三个图标：默认、春节、情人节。配置大概长这样：

<activity android:name="com.example.game.MainActivity" 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="com.example.game.MainActivity.default" android:targetActivity="com.example.game.MainActivity" 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="com.example.game.MainActivity.spring" android:targetActivity="com.example.game.MainActivity" android:icon="@mipmap/ic_launcher_spring" android:label="@string/app_name_spring" 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本身不要再带LAUNCHER的intent-filter，否则会出现两个图标。正确做法是把LAUNCHER的intent-filter只放在alias上，主Activity只保留其他必要的filter。第二，每个alias的name必须唯一，建议用包名加后缀的格式。第三，enabled属性：默认图标对应的alias设为true，其他设为false。第四，targetActivity必须指向真实存在的Activity，且该Activity的exported要为true。

注意：如果你的项目用了Android App Bundle（AAB）发布，activity-alias的配置同样有效，但要注意Google Play对图标资源的处理。AAB会根据设备密度分发资源，但alias的启用状态是运行时的，不受影响。

3.2 Java侧切换逻辑的完整实现

在Unity的Android插件目录下（通常是Assets/Plugins/Android），新建一个Java文件，比如AppIconChanger.java：

package com.example.game; import android.content.ComponentName; import android.content.Context; import android.content.pm.PackageManager; public class AppIconChanger { private static final String PKG = "com.example.game"; private static final String[] ALL_ALIASES = { "com.example.game.MainActivity.default", "com.example.game.MainActivity.spring", "com.example.game.MainActivity.valentine" }; public static void setIcon(Context context, String aliasSuffix) { String targetAlias = PKG + ".MainActivity." + aliasSuffix; PackageManager pm = context.getPackageManager(); for (String alias : ALL_ALIASES) { int newState = alias.equals(targetAlias) ? PackageManager.COMPONENT_ENABLED_STATE_ENABLED : PackageManager.COMPONENT_ENABLED_STATE_DISABLED; pm.setComponentEnabledSetting( new ComponentName(PKG, alias), newState, PackageManager.DONT_KILL_APP ); } } }

这段代码的核心是setComponentEnabledSetting。第三个参数DONT_KILL_APP非常关键——如果不加这个标志，系统会在切换组件状态时杀掉应用进程，用户体验就是"点一下图标，App闪退了"。加上之后，切换是静默完成的，App继续运行。

但这里有个Android系统的经典坑：切换alias后，桌面图标的刷新有延迟。有些设备上会立即刷新，有些设备要等几秒，还有些设备需要用户回到桌面才刷新。这是系统Launcher的行为，无法从应用侧强制。实测下来，大部分主流机型在1到3秒内会刷新，个别ROM可能需要更久。如果产品要求"点了立刻变"，那要提前跟产品沟通这个限制。

3.3 Unity C#侧调用Android的桥接代码

Unity侧通过AndroidJavaClass和AndroidJavaObject来调用上面的Java方法：

public static void SetIconAndroid(string aliasSuffix) { using (var unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) using (var activity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity")) using (var changer = new AndroidJavaClass("com.example.game.AppIconChanger")) { changer.CallStatic("setIcon", activity, aliasSuffix); } }

这段代码看起来简单，但有两个容易出错的地方。第一，currentActivity必须在主线程获取，如果在子线程调用会拿到null。第二，AndroidJavaClass和AndroidJavaObject都实现了IDisposable，用using包起来可以及时释放JNI引用，避免内存泄漏。我见过项目里因为没释放导致JNI引用表溢出的案例，排查了很久。

另外，如果你的项目开启了ProGuard或R8混淆，要确保AppIconChanger类不被混淆，在proguard-rules里加一行-keep class com.example.game.AppIconChanger { *; }。否则打包后反射调用会失败，报ClassNotFoundException。

3.4 图标资源命名与密度适配

Android的图标资源要放在Assets/Plugins/Android/res/mipmap-*目录下，按密度分文件夹：

• mipmap-mdpi：48x48
• mipmap-hdpi：72x72
• mipmap-xhdpi：96x96
• mipmap-xxhdpi：144x144
• mipmap-xxxhdpi：192x192

如果偷懒只放一个mipmap-xxhdpi，在低密度设备上系统会缩放，图标会糊。实测下来，至少要把mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi五个密度都放齐，才能保证所有设备上清晰。

还有一个细节：自适应图标（Adaptive Icon）。从Android 8.0开始，图标支持前景层和背景层分离。如果你的备选图标要做自适应，需要在mipmap-anydpi-v26目录下放XML描述文件，引用前景和背景资源。这个配置比普通图标复杂，但效果更好——系统会根据不同Launcher的形状（圆形、方形、圆角方形）自动裁剪。如果活动图标对视觉效果要求高，建议做自适应版本。

4. iOS端核心实现细节拆解

4.1 Info.plist中备选图标的声明方式

iOS的备选图标必须在Info.plist里预先声明，格式如下：

<key>CFBundleIcons</key> <dict> <key>CFBundlePrimaryIcon</key> <dict> <key>CFBundleIconFiles</key> <array> <string>AppIcon60x60</string> </array> </dict> <key>CFBundleAlternateIcons</key> <dict> <key>spring</key> <dict> <key>CFBundleIconFiles</key> <array> <string>spring60x60</string> </array> <key>UIPrerenderedIcon</key> <false/> </dict> <key>valentine</key> <dict> <key>CFBundleIconFiles</key> <array> <string>valentine60x60</string> </array> <key>UIPrerenderedIcon</key> <false/> </dict> </dict> </dict>

这里的spring和valentine就是备选图标的key，后面调用接口时要用到。CFBundleIconFiles数组里填的是图标文件名（不带扩展名），系统会自动匹配@2x和@3x版本。比如你放了spring60x60@2x.png和spring60x60@3x.png，系统会自动选。

注意：iOS的备选图标必须是PNG格式，且不能有alpha通道（透明通道）。如果图标有透明区域，提交App Store时会被拒。这个坑很多人踩过，做图的时候一定要让设计导出不带透明的版本。

4.2 Objective-C切换接口的封装

在iOS插件目录下新建AppIconChanger.mm（用.mm后缀支持Objective-C++，方便和Unity交互）：

#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; } [[UIApplication sharedApplication] setAlternateIconName:name completionHandler:^(NSError * _Nullable error) { if (error) { NSLog(@"Set icon failed: %@", error.localizedDescription); } }]; } }

这段代码有几个关键处理。第一，supportsAlternateIcons要先判断，虽然iOS 10.3以上都支持，但保险起见还是检查一下。第二，传nil表示恢复默认图标，所以当传入"default"时要转成nil。第三，completionHandler里的错误要打日志，方便排查。

4.3 Unity C#侧调用iOS的桥接代码

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

DllImport("__Internal")是Unity调用iOS静态库的标准写法。注意#if UNITY_IOS && !UNITY_EDITOR这个条件编译，因为编辑器下没有__Internal这个库，不加条件会在编辑器里报错。

4.4 iOS弹窗问题的处理策略

前面提到，iOS切换图标时系统会弹一个提示框。这个弹窗的文案是系统固定的，无法自定义。实际产品中，通常的做法是：

1. 用户点击"切换图标"按钮。
2. 弹出自定义确认框："确定要更换图标吗？系统会弹出确认提示，请点击'使用'。"
3. 用户点确认后，调用setAlternateIconName。
4. 系统弹窗出现，用户点"使用"。
5. 图标切换完成。

这样处理的好处是用户对系统弹窗有心理预期，不会觉得突兀。另外，系统弹窗出现时，App的界面会被短暂遮挡，如果此时有动画或音效在播放，要注意暂停和恢复。

还有一个细节：iOS切换图标后，App不会重启，但桌面图标刷新可能有延迟。实测下来，大部分设备在1秒内刷新，个别情况需要用户手动回到桌面。这个和Android类似，属于系统行为。

5. Unity统一封装与业务层调用

5.1 统一接口设计

把两端的实现包在一个静态类里，业务层只需要调一个方法：

public static class AppIconChanger { public static void SetIcon(string iconKey) { #if UNITY_ANDROID && !UNITY_EDITOR SetIconAndroid(iconKey); #elif UNITY_IOS && !UNITY_EDITOR SetIconiOS(iconKey); #else Debug.Log($"[Editor] Set icon to: {iconKey}"); #endif PlayerPrefs.SetString("current_icon", iconKey); PlayerPrefs.Save(); } public static string GetCurrentIcon() { return PlayerPrefs.GetString("current_icon", "default"); } }

iconKey的命名要两端统一。比如Android的alias后缀是spring，iOS的plist key也是spring，这样业务层传"spring"就能两端通用。默认图标统一用"default"。

5.2 启动时的状态校正

App启动时要做一次校正，确保实际图标和记录一致。Android端可以查询当前启用的alias：

public static String getCurrentAlias(Context context) { PackageManager pm = context.getPackageManager(); for (String alias : ALL_ALIASES) { int state = pm.getComponentEnabledSetting(new ComponentName(PKG, alias)); if (state == PackageManager.COMPONENT_ENABLED_STATE_ENABLED) { return alias.substring(alias.lastIndexOf('.') + 1); } } return "default"; }

iOS端可以查询alternateIconName：

extern "C" { const char* _GetCurrentAppIcon() { NSString *name = [[UIApplication sharedApplication] alternateIconName]; if (name == nil) { return strdup("default"); } return strdup([name UTF8String]); } }

启动时对比查询结果和PlayerPrefs记录，如果不一致，以实际为准更新记录。这样即使用户在系统设置里手动改了图标，App也能正确识别。

5.3 业务层的调用时机

换图标的调用时机通常有三个：

• 用户主动触发：在设置页面放一个"更换图标"入口，用户点击后选择。
• 活动自动触发：比如检测到当前是春节期间，App启动时自动切换到春节图标。
• 运营后台下发：通过配置接口下发当前应该使用的图标key，App启动时读取并切换。

第一种最可控，第二种要注意用户是否已经手动改过图标，不要覆盖用户的选择。第三种最灵活，但要注意配置接口的容错——如果下发的key在本地不存在，要回退到默认图标，不能崩溃。

6. 常见问题与排查技巧实录

6.1 Android端典型问题速查

6.2 iOS端典型问题速查

6.3 我踩过的几个坑

第一个坑是Android的alias命名。我一开始用了MainActivity_spring这种下划线格式，结果在某些ROM上解析异常。后来改成点号分隔的MainActivity.spring就正常了。虽然官方文档没说下划线不行，但实测下来点号更稳。

第二个坑是iOS的图标缓存。有次测试时切换图标后，桌面显示的还是旧图标，以为是代码问题，排查了半天才发现是iOS的图标缓存。解决办法是卸载重装，或者等一段时间。这个缓存机制在开发阶段很烦，但线上用户基本感知不到。

第三个坑是Unity的Android插件目录结构。Java文件必须放在Assets/Plugins/Android下，且包名要和Java文件里的package声明一致。我有次把文件放错了目录，打包后一直报找不到类，查了很久才发现是目录问题。

第四个坑是iOS的plist合并。如果项目用了多个插件，每个插件都有自己的Info.plist片段，Unity在打包时会合并。如果两个插件都声明了CFBundleIcons，会冲突。解决办法是只在一个地方声明，或者用PostProcessBuild脚本动态合并。

7. 性能与体积影响的实测数据

动态图标方案对包体的影响主要来自图标资源。我拿一个实际项目做了测试，准备了10个备选图标，每个图标5个密度，Android端APK增大了约3.2MB，iOS端IPA增大了约2.8MB。如果图标数量增加到20个，增量大概翻倍。

对运行时性能的影响几乎可以忽略。Android端切换alias是一次PackageManager调用，耗时在10毫秒以内。iOS端切换图标稍慢，因为系统要处理图标缓存，实测在200到500毫秒之间，但这是异步的，不阻塞主线程。

内存方面，图标资源是编译期打包的，运行时不会全部加载到内存，只有当前显示的图标会被系统加载。所以不用担心内存问题。

如果包体实在紧张，可以考虑用图标压缩。PNG图标用TinyPNG之类的工具压缩，通常能减少30%到50%的体积。但要注意压缩后不能有肉眼可见的失真，尤其是图标边缘。

8. 一些延伸玩法和注意事项

动态图标除了换节日图标，还有几个延伸玩法。一是用户个性化，让用户自己选喜欢的图标，增加归属感。二是成就解锁，比如玩家达到某个等级后解锁专属图标。三是联名活动，和品牌方合作时用联名图标，活动结束后切回默认。

但有几个注意事项必须强调。第一，不要频繁切换。虽然技术上可以做到每次启动都切，但频繁切换会让用户困惑，也增加系统负担。建议一天最多切一次，且要有明确的触发条件。第二，要给用户选择权。自动切换图标前最好征得用户同意，或者在设置里提供"关闭自动切换"的选项。第三，测试要覆盖多机型。Android碎片化严重，不同ROM对alias的支持有差异，至少要覆盖主流品牌的主力机型。

最后分享一个小技巧：如果产品要求"切换图标后立即生效"，可以在切换后调用一次Launcher的刷新。Android端可以发送一个Intent.ACTION_MAIN的广播，部分Launcher会响应并刷新。但这个不是标准API，效果因Launcher而异，只能作为锦上添花，不能作为主要依赖。

我在实际项目中的体会是，动态图标这个功能技术难度不算高，但细节特别多，两端加起来大概需要3到5个工作日完成开发和测试。最大的成本不在写代码，而在准备图标资源和多机型测试。如果团队里没有熟悉原生开发的同学，建议预留充足的时间，或者考虑用现成的插件市场方案，虽然要花钱，但能省不少事。