企业官网建设流程全解析

做 Unity 手游的朋友应该都遇到过这种需求：游戏外显的 App 图标想要在特定节点换一张，比如节日活动换皮肤、版本更新换视觉、甚至用户完成某个任务后解锁专属图标。这个需求听起来不大，真正做起来却有不少门道——Android 端与 iOS 端的系统机制完全不同，Unity 层能拿到的接口能力也大相径庭，稍不留神就会做成“只能换 Android、iOS 直接摆烂”的半吊子方案。

我前阵子刚把一个双端动态换图标的完整方案落地到线上项目，从 Unity 层到底层原生代码，踩了不少坑，也总结出一套能直接抄作业的路径。这篇就围绕 Android 与 iOS 两端的技术差异、Unity 侧的桥接方式、常见疑难杂症排查来展开，尽量把每一步的为什么和怎么做都讲透。

1. 整体方案设计与双端机制拆解

动态更换 App 图标这件事，首先要认清一个现实：Android 和 iOS 的操作系统权限、更换逻辑、生效机制完全是两套玩法。如果你指望 Unity 写一套 C# 代码双端通吃，那基本是做梦。正确思路是在 Unity 层做统一的逻辑入口，底层分别对接 Android 的组件启用机制和 iOS 的系统限制。

1.1 Android 的多图标切换原理：Activity-alias 与 ComponentEnabledSetting

Android 端能够实现动态更换图标，核心依赖的是系统提供的ComponentEnabledSetting机制。应用安装后，AndroidManifest 中可以声明多个activity-alias，每个 alias 指向同一个真实的 Activity（通常是 Unity 的启动 Activity），但各自持有不同的 icon 和 label。运行时通过PackageManager.setComponentEnabledSetting()来启用目标 alias、禁用当前 alias，桌面上的图标就会随着组件状态变化而刷新。

这套机制的关键在于：桌面上显示的图标实际上是 PMS（PackageManagerService）根据“当前启用的、带CATEGORY_LAUNCHER的组件”来决定的。你禁用了旧的入口，启用了新的入口，桌面 Launcher 收到组件变更广播后就会重新读取图标资源。原理听起来很简单，真正落地有细节，后面实操章节会逐一展开。

值得一提的是，Android 13 之后系统版本对setComponentEnabledSetting的调用没有做额外限制，依然是公开 API，不需要申请任何特殊权限。但国内厂商 ROM 对桌面图标刷新有各自的缓存策略，有的机型需要重启 Launcher 甚至等待几分钟才生效，这点要在设计阶段就有心理预期。

1.2 iOS 的硬限制：官方不支持动态换图标

iOS 端就没有这么幸运了。苹果从系统层面就不允许 App 在运行时修改自己的桌面图标，Info.plist里的CFBundleIcons是安装时固定的，不存在任何公开 API 能让你在 App 运行过程中去切换主屏图标。App Store 审核条款里也只允许“通过设置页手动选择图标”的静态方案，本质上还是用户改了之后重启 SpringBoard 才能生效，并且这套能力只开放给原生 App 的特定场景，Unity 手游基本拿不到。

所以 iOS 端现实可行的路线是先降低预期：不做真正意义的实时换图标，而是退而求其次，使用系统支持的替代展示方案。我项目里最终采用的是“桌面快捷方式图标 + 3D Touch/长按菜单图标”的组合，通过UIApplicationShortcutItem动态更新快捷入口的 icon 和标题，让用户在桌面上长按 App 图标时能看到游戏当前的活动视觉。这就是 iOS 端在合法范围内能做到的最大程度“动态感”。

1.3 Unity 层的统一调用入口设计

既然双端底层机制差异巨大，Unity 层必须设计一个高度抽象的接口。我的做法是写一个静态类DynamicIconManager，对外暴露两个方法：SwitchIcon(string iconId)和ResetDefaultIcon()。方法内部通过Application.platform判断当前平台，Android 走 AndroidJavaObject 桥接，iOS 走#if UNITY_IOS的原生回调。

public static class DynamicIconManager { public static void SwitchIcon(string iconId) { if (Application.platform == RuntimePlatform.Android) { AndroidNativeBridge.SwitchIcon(iconId); } else if (Application.platform == RuntimePlatform.IPhonePlayer) { #if UNITY_IOS iOSNativeBridge.SwitchShortcutIcon(iconId); #endif } } public static void ResetDefaultIcon() { if (Application.platform == RuntimePlatform.Android) { AndroidNativeBridge.ResetIcon(); } else if (Application.platform == RuntimePlatform.IPhonePlayer) { #if UNITY_IOS iOSNativeBridge.ResetShortcutIcon(); #endif } } }

设计这套接口时我特别强调一个原则：C# 层永远不要出现 if-else 的双端逻辑分支里塞业务代码，所有双端差异都隐藏在桥接层。这样游戏策划和上层业务调用时感知不到平台差异，只需要传一个 iconId 进来，底层会自动找对应的资源。

接口背后的游戏业务场景通常是：运营后台下发活动配置，客户端收到指令后调用DynamicIconManager.SwitchIcon("halloween_icon")，切换成功后上报统计，失败则静默降级。整个流程对玩家无感，不会因为图标切换失败弹任何错误提示。

2. Android 端完整实操：从 Manifest 到 Unity 桥接

Android 端是实现动态换图标的主战场，这里的每一步都需要谨慎处理。我会把从 AndroidManifest 编写、资源目录规划到 Unity 调用 Java 层的完整链路拆开讲，每个文件贴出核心代码并解释关键点。

2.1 AndroidManifest 多入口配置与资源目录规划

首先在 Android 项目的AndroidManifest.xml里，默认入口之外需要声明若干个activity-alias。这里的关键约束有两个：一是必须给每个 alias 设置独立的android:icon和android:label，二是每个 alias 的android:enabled初始值必须是true，否则首次安装后系统会找不到默认入口。

<application android:label="我的游戏" ...> <!-- 默认入口 --> <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> <!-- 活动图标入口A --> <activity-alias android:name="com.gametest.MainActivity_A" android:targetActivity="com.unity3d.player.UnityPlayerActivity" android:icon="@mipmap/ic_launcher_a" android:label="我的游戏" android:enabled="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity-alias> <!-- 活动图标入口B --> <activity-alias android:name="com.gametest.MainActivity_B" android:targetActivity="com.unity3d.player.UnityPlayerActivity" android:icon="@mipmap/ic_launcher_b" android:label="我的游戏" android:enabled="false"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity-alias> </application>

默认入口和每个 alias 都要带<intent-filter>且包含MAIN和LAUNCHER，这是桌面识别 App 入口组件的必要条件。资源方面，在mipmap目录下为每个图标准备一套多分辨率文件，建议至少覆盖mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi五档，否则某些机型上会出现图标模糊或缩放异常。

这里有一个容易踩的坑：Unity 构建时默认会把 AndroidManifest 合并，如果服务端导出的是单个activity，在 Gradle 构建阶段有可能会被自动生成的 Manifest 覆盖。正确做法是修改Assets/Plugins/Android/AndroidManifest.xml中的配置，并且关闭 Player Settings 里的Custom Main Manifest选项冲突项，保证构建时采用我们自定义的 Manifest。

2.2 Java 侧切换逻辑：PackageManager 启停组件的完整实现

Android 原生侧需要提供一个 Java 类用于切换组件状态。核心逻辑就三行代码：拿到PackageManager、根据包名和类名构造ComponentName、调用setComponentEnabledSetting。但为了让 Unity 侧调用方便，我把每次切换封装成自动处理旧组件禁用、新组件启用的逻辑，避免业务层重复写状态追踪代码。

public class DynamicIconHelper { public static final String DEFAULT_ALIAS = "com.gametest.MainActivity"; // 默认入口 public static final String ALIAS_A = "com.gametest.MainActivity_A"; public static final String ALIAS_B = "com.gametest.MainActivity_B"; public static final String ALIAS_C = "com.gametest.MainActivity_C"; public static void switchIcon(Context context, String aliasName) { PackageManager pm = context.getPackageManager(); String packageName = context.getPackageName(); // 先禁用默认入口 pm.setComponentEnabledSetting( new ComponentName(packageName, DEFAULT_ALIAS), PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP ); // 启用目标 alias pm.setComponentEnabledSetting( new ComponentName(packageName, aliasName), PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP ); } public static void resetIcon(Context context) { PackageManager pm = context.getPackageManager(); String packageName = context.getPackageName(); // 启用默认入口 pm.setComponentEnabledSetting( new ComponentName(packageName, DEFAULT_ALIAS), PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP ); // 禁用其他所有 alias pm.setComponentEnabledSetting( new ComponentName(packageName, ALIAS_A), PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP ); pm.setComponentEnabledSetting( new ComponentName(packageName, ALIAS_B), PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP ); pm.setComponentEnabledSetting( new ComponentName(packageName, ALIAS_C), PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP ); } }

这里我需要重点解释为什么DONT_KILL_APP这个 flag 是必须的：如果省略它，系统会直接杀掉当前进程来使组件变更生效。手游肯定不想因为换图标重启游戏，所以必须加上。还有一点，当 alias 处于启用状态时，如果用pm.getApplicationInfo去查图标，拿到的是当时启用的 alias 对应的图标资源，这个特性可以用来做切换结果的自检。

权限方面，setComponentEnabledSetting本身就可以被第三方调用，但如果你的应用不声明CHANGE_COMPONENT_ENABLED_STATE权限，部分 ROM（尤其三星早期系统）会拦截调用。稳妥起见，在 Manifest 里加上<uses-permission android:name="android.permission.CHANGE_COMPONENT_ENABLED_STATE" />。

2.3 Unity 调用 Android 原生层的完整桥接代码

Unity 侧调用 Java 方法用的是AndroidJavaObject反射机制，这里我不推荐每次切换都现写反射逻辑，而是建立一个静态的桥接工具类，缓存AndroidJavaClass和AndroidJavaObject，避免频繁创建导致的性能损耗和 GC 压力。

public class AndroidNativeBridge { private static AndroidJavaClass _unityPlayer; private static AndroidJavaObject _currentActivity; private static AndroidJavaClass _helperClass; private static void Init() { if (_helperClass != null) return; _unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"); _currentActivity = _unityPlayer.GetStatic<AndroidJavaObject>("currentActivity"); _helperClass = new AndroidJavaClass("com.gametest.DynamicIconHelper"); } public static void SwitchIcon(string aliasName) { Init(); _helperClass.CallStatic("switchIcon", _currentActivity, aliasName); } public static void ResetIcon() { Init(); _helperClass.CallStatic("resetIcon", _currentActivity); } }

有几个细节值得注意。第一，com.unity3d.player.UnityPlayer这个类只有 Unity 打包出的 APK 里存在，调试期或非 Unity 工程不能直接用，好在我们的场景就是 Unity 手游，没这个问题。第二，currentActivity是Activity类型，在 AndroidJavaObject 里是引用类型，传给 Java 方法时直接作为参数传递即可，不需要特殊转换。第三，如果同时传多个参数，比如(context, aliasName, callbackId)，反射调用的参数顺序必须与 Java 方法签名一致，否则会抛出ArgumentException。

2.4 Android 图标切换的生效时间与缓存问题

很多开发者做完上述步骤后会遇到“图标确实切换了，但要等很久桌面才变”的情况。这正是 Android 换图标的磨人之处：setComponentEnabledSetting是系统层面的组件状态变更，但桌面 Launcher 是否立刻响应，取决于各 ROM 的 Launcher 实现。

原生 AOSP 系统通常在组件变更后几秒内就会刷新桌面图标，但国内主流厂商如华为、小米、OPPO、vivo 的 Launcher 都有自己的桌面数据缓存，刷新周期从几秒到几分钟不等。实测下来小米 MIUI 反应最快，基本 1 到 2 秒内就能看到变化；华为 EMUI 有时需要杀掉 Launcher 进程才能强制刷新；OPPO ColorOS 有概率等 5 分钟以上。这里能做的优化是：切换成功后发送一个桌面刷新广播，部分 ROM 对这个广播有响应。

public static void refreshLauncher(Context context) { // 部分 ROM 支持的桌面刷新广播 Intent intent = new Intent("android.intent.action.LOCALE_CHANGED"); intent.setPackage("android"); context.sendBroadcast(intent); // 另一种常见做法：发送 ACTION_MY_PACKAGE_REPLACED 广播 Intent replaceIntent = new Intent(Intent.ACTION_MY_PACKAGE_REPLACED); replaceIntent.setPackage(context.getPackageName()); context.sendBroadcast(replaceIntent); }

广播效果在不同 ROM 上差异很大，某些机型收不到。从项目角度，不要对“切换后立即生效”抱有过高期待，尤其是国内渠道包，一定要在用户可感知的范围内做兜底设计：比如切换成功后弹一个 Toast 提示“图标将在稍后更新”，避免玩家以为没生效而反复点击。

3. iOS 端合规替代方案：Shortcut Icon 与过渡策略

iOS 端既然无法真正动态替换主屏图标，只能走替代方案。我的做法是用原生层的UIApplicationShortcutItem能力来实现视觉上的“动态感”，同时把图标配置通过 Unity 的 C# 接口传递到原生侧。

3.1 为什么 iOS 的 Shortcut Icon 是唯一合规出路

iOS 系统的UIApplicationShortcutItem是苹果官方提供的桌面快捷操作入口，用户长按应用图标就可以弹出自定义菜单，每个菜单项可以带图标和标题。这个机制下，快捷菜单里的图标可以动态替换，只要调用UIApplication.sharedApplication.shortcutItems的 setter 重新赋值即可。

很多人会问：这样和“换 App 图标”有什么关系？关系在于用户长按桌面上游戏的图标时，弹出的快捷菜单里的图标和标题会实时变化。如果把游戏当前版本或活动视觉做成 shortcut 项的第一个入口，用户在桌面看到的第一视觉就是动态变化的。虽然不是真正的替换主图标，但体验上确实给玩家一种“图标在跟着活动走”的感觉。

我踩过的坑是：UIApplicationShortcutItem的图标类型只支持系统内置的UIApplicationShortcutIconType，自定义图标则需要用UIApplicationShortcutIcon(iconFile: UIImage)或者iconFile名称指向资源文件。在 Unity 工程里，自定义图片必须放到 Xcode 工程资源或者通过 Unity 的PostProcessBuild脚本注入，否则编译后图标资源丢失导致 crash。推荐做法是直接将 PNG 图片放到Assets/Plugins/iOS目录下，Unity 打包时会自动拷贝进 Xcode 工程。

3.2 iOS 原生侧 Shortcut 管理代码

先看原生实现。Objective-C 的代码逻辑不复杂，主要是构建UIApplicationShortcutItem数组，然后设置给UIApplication。我提供一个统一的管理类方法，Unity 侧通过UnitySendMessage或者导出extern "C"的 C 函数来调用。

#import <UIKit/UIKit.h> void UpdateShortcutItems(const char* iconName, const char* title) { NSString *iconStr = [NSString stringWithUTF8String:iconName]; NSString *titleStr = [NSString stringWithUTF8String:title]; UIApplicationShortcutIcon *icon = [UIApplicationShortcutIcon iconWithTemplateImageName:iconStr]; UIApplicationShortcutItem *item = [[UIApplicationShortcutItem alloc] initWithType:@"dynamic_icon" localizedTitle:titleStr localizedSubtitle:nil icon:icon userInfo:nil]; [UIApplication sharedApplication].shortcutItems = @[item]; } const char* _GetShortcutItemsJson() { // 可选的查询方法，用于反查当前快捷项 NSArray *items = [UIApplication sharedApplication].shortcutItems; // 省略 json 序列化，直接返回空字符串 return ""; }

这段代码的关键在于iconWithTemplateImageName:用的是模板图片，图片本身应该只有 alpha 通道，系统会自动染色。新手容易在这里踩坑：如果用普通彩色 PNG，渲染出来会是一坨黑。模板图标的制作要求是内容部分白色或透明，具体细节不同 iOS 版本有差异，建议直接用Assets.xcassets里新建Image Set，勾选Render As Template Image属性。

3.3 Unity 与 iOS 原生层通信的两种方式

Unity 调 iOS 原生代码，常规手段是直接把 C 函数声明在 C# 侧用[DllImport("__Internal")]引用。注意，必须是#if UNITY_IOS的条件编译块，因为 Android 和 Editor 环境下没有__Internal这个库。这是最直接的桥接。

public class iOSNativeBridge { #if UNITY_IOS [DllImport("__Internal")] private static extern void UpdateShortcutItems(string iconName, string title); #endif public static void SwitchShortcutIcon(string iconId) { #if UNITY_IOS string iconName = GetIconResourceName(iconId); string title = GetShortcutTitle(iconId); UpdateShortcutItems(iconName, title); #endif } }

另一种高级用法是UnitySendMessage，让原生层主动向 Unity 的某个 GameObject 发送消息，适用于原生层处理完异步回调后需要通知 C# 的场景。比如切换完成后的打点上报，用UnitySendMessage("GameManager", "OnIconSwitchFinished", "ios_success")回到 C# 层处理。两种方式混合使用，可以覆盖绝大多数双端通信需求。

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

动态换图标这个功能涉及的链路长，从构建配置到运行时表现都可能出问题。这一节把我实际遇到的典型问题和排查方法整理成一份速查手册，能直接对着排。

4.1 Android 桌面图标未变化的排查路径

• 确认组件状态确实变更：在切换代码后调用ApplicationInfo或PackageManager.getApplicationIcon()，看返回的图标资源是否已经变成新资源。如果资源已经变了但桌面没变，那是 Launcher 缓存问题；如果资源都没变，说明setComponentEnabledSetting没有真正生效或 alias 名称配错。
• 检查 alias 组件的 exported 属性：Android 12 及以后版本，activity-alias同样要求显式声明android:exported="true"，否则安装时PackageManager会拒绝安装。我当时就遇到过打包成功但部分系统上安装直接失败的情况，排查原因是 Manifest 的 alias 漏了exported。
• 检查同一个入口是否被多次禁用：如果业务层重复调用SwitchIcon，比如先切到 A 再切到 B，但 A 的 alias 在禁用后又被设置成启用状态，会导致桌面出现两个相同图标。务必在 Java 层维护一个当前启用组件的状态位，切换前先检查是不是相同的目标。
• 单车用户权限问题：部分出厂应用双开、应用分身功能会定制 PMS 的行为，导致DONT_KILL_APP标志无效。这类问题通常只能做日志上报排查，无法通过代码完全规避，建议把系统版本和 ROM 型号一起上报。

4.2 iOS Shortcut 图标不显示或变黑问题

最常见的问题是模板图片渲染不正确。如果你用的是彩色 PNG，系统会按 alpha 通道抠出形状然后统一染成黑色或白色，显示出来就是一块黑的。排错方法就是看原图：在 Xcode 里打开资源，渲染设置确认勾选了Render As Template Image。如果确认无误还是不显示，检查图片尺寸，UIApplicationShortcutIcon推荐使用 35x35pt 的尺寸，分辨率适配 1x、2x、3x。

4.3 构建物大小与多图标资源带来的包体膨胀

多套 mipmap 图标会带来包体增大。我在项目里为了少打包几套图，最初只放了xxxhdpi一套，结果部分中低端机型上系统去读对应尺寸资源时找不到，只能从高密度缩放，桌面图标有点糊。最终方案是五档齐全但严格控制单档图片大小：每个图标 PNG 控制在 80KB 以内，格式选支持 alpha 的 WebP 更好，Android Studio 会自动把 webp 打包进 mipmap，体积比 PNG 省一半以上。

iOS 端同样要控制资源体积，不要直接把 1024x1024 的宣传图塞进 shortcut 图标资源，用 120x120 的模板图即可，包体能轻松省下几百 KB。

4.4 运行时崩溃：找不到指定组件异常

Android 侧如果 alias 名称写错，ComponentName构造不会报错，但setComponentEnabledSetting会抛IllegalArgumentException。这类崩溃通常发生在测试阶段，线上很少。但有一种情况要注意：如果应用用了多 APK 或者插件化方案，alias 声明的类可能在主 APK 里找不到，初始化时就会抛ClassNotFoundException。排查时先确认 alias 的targetActivity是真实存在的类名，并且路径和 Manifest 中的包名完全一致。

4.5 双端图标切换的服务端联动设计

最后聊一个工程实践层面的细节：动态换图标不应只是客户端本地行为，最好能和服务端联动。我在项目里的实现方式是：运营后台配置IconConfig，下发 JSON 给客户端，客户端本地解析出icondId后调用DynamicIconManager.SwitchIcon。同时客户端会记录当前生效的图标 ID 和切换时间，拉取配置时做本地覆盖比对，避免每次进游戏都重新切换导致桌面反复刷新。

{ "iconSwitch": { "enabled": true, "iconId": "halloween_2024", "startTime": "2024-10-20 00:00:00", "endTime": "2024-11-05 23:59:59" } }

切换成功的打点数据也建议走服务端。应用商店后台看不到图标变化的实时数据，只有客户端上报才能知道不同渠道包的转化率和玩家对活动图标的点击变化，这块数据对运营调优很有价值。

5. 经验总结与工程化建议

做完整套双端动态换图标方案后，回头看整个技术选型和落地过程，有几条经验挺有分量，值得单独拎出来讲。

5.1 双端能力边界决定产品预期

动态换图标在 Android 端是能力，在 iOS 端是妥协方案。产品经理提需求时，一定不要承诺“双端都能真正换主屏图标”，否则交付时会被吐槽。正确做法是提前在需求文档里写清双端差异：Android 走 activity-alias 真切换，iOS 走 shortcut 动态视觉更新。这些差异最好在产品立项时就跟运营对齐，避免开发到一半推翻重来。

5.2 抽象层设计的收益会随时间放大

Unity 项目经常会接渠道 SDK、打包出多个渠道包，动态换图标这种能力如果散落在各个渠道包的 Java 层里统一维护会很痛苦。把接口收敛到 C# 的DynamicIconManager，所有渠道包只需要在原生层提供相同的 Java 方法签名，Unity 层代码完全不需要改。上个月我们接一个新的联运渠道，原生层实现完switchIcon方法就能直接用，这个抽象的价值会随着渠道数量增加而放大。

5.3 测试清单要覆盖 ROM 版本和 iOS 版本矩阵

动态换图标的兼容性问题多数集中在 Android ROM 差异上。我的测试清单是按这样的矩阵来排的：

• Android 原生 AOSP 9、10、11、12、13、14
• 小米 MIUI 12、13、14、15
• 华为 EMUI 9、10、11、HarmonyOS 2、3、4
• OPPO ColorOS 11、12、13
• vivo OriginOS 2、3、4
• 荣耀 MagicOS 6、7、8

iOS 侧主要测的版本是 15、16、17 系统下shortcutItems的表现。iOS 的 shortcut 机制相对稳定，低概率会遇到某个系统重置了快捷项，需要重新设置，此时客户端可以在ApplicationDidBecomeActive时做一次 check 并重设。

5.4 灰度发布与后台开关的必要性

最后一个小建议：上线时不要把动态换图标做成默认强逻辑。给功能加一个远程开关，首次发布时先关闭，灰度 10% 用户观察崩溃率和图标刷新成功率，确认稳定后再全量放开。图标切换不是用户主动触发的功能，属于后台静默行为，一旦出现批量崩溃用户是无感的，只会觉得 App 闪退，到那时排查问题的成本远高于做灰度开关的成本。

从我实际运营的数据看，Android 端切换成功率大约在 98% 到 99% 之间，失败的 1% 到 2% 里绝大多数是 Launcher 缓存问题，重装或清桌面数据后都能恢复。iOS 端 shortcut 的更新几乎无感，只要图标资源正确，没有遇到过异常。

这套方案目前已经稳定跑了两个大版本，后续如果有条件我还想把 iOS 端做成“设置页面手动选择图标”的完整路径，进一步逼近 Android 的体验，但至少当前这个双端方案已经能满足运营侧的动态换图标诉求了。