iOS开发：如何重写类以实现Asset Catalog颜色的用户自定义覆盖

首先得明确：Apple并没有公开允许直接重写Asset Catalog相关的颜色获取类（你设想的colorForName:方法对应的系统类是私有API，强行重写不仅有崩溃风险，还可能过不了App Store审核）。不过我们可以换个更稳妥的思路——封装自己的颜色管理入口，统一处理默认Asset颜色和用户自定义颜色的逻辑，同时兼容你的衍生色算法。

核心方案：自定义颜色管理类 + 统一调用入口 #

1. 编写单例颜色管理类 #

这个类负责存储用户自定义颜色、处理颜色获取逻辑，以及调用你的衍生色算法。示例代码（OC版，Swift版思路一致）：

@interface AppColorManager : NSObject
@property (nonatomic, strong) UIColor *customPrimaryColor;
+ (instancetype)sharedManager;
- (UIColor *)colorForName:(NSString *)name;
@end

@implementation AppColorManager

+ (instancetype)sharedManager {
    static AppColorManager *manager = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        manager = [[AppColorManager alloc] init];
    });
    return manager;
}

- (UIColor *)colorForName:(NSString *)name {
    if ([name isEqualToString:@"primary_color"]) {
        // 优先返回用户自定义颜色，否则用Asset中的默认值
        return self.customPrimaryColor ?: [UIColor colorNamed:name];
    }
    
    // 处理衍生色（比如按钮阴影、明暗色等）
    if ([name hasPrefix:@"primary_derived_"]) {
        UIColor *baseColor = self.customPrimaryColor ?: [UIColor colorNamed:@"primary_color"] ?: [UIColor greenColor];
        // 调用你的衍生色计算算法
        return [self derivedColorForName:name fromBaseColor:baseColor];
    }
    
    // 非主色调相关的颜色，直接从Asset Catalog获取
    return [UIColor colorNamed:name];
}

// 你的衍生色计算逻辑（示例）
- (UIColor *)derivedColorForName:(NSString *)name fromBaseColor:(UIColor *)baseColor {
    CGFloat hue, saturation, brightness, alpha;
    if ([baseColor getHue:&hue saturation:&saturation brightness:&brightness alpha:&alpha]) {
        if ([name isEqualToString:@"primary_derived_shadow"]) {
            // 生成比基色暗20%的阴影色
            return [UIColor colorWithHue:hue saturation:saturation brightness:MAX(brightness - 0.2, 0) alpha:alpha];
        } else if ([name isEqualToString:@"primary_derived_highlight"]) {
            // 生成比基色亮15%的高亮色
            return [UIColor colorWithHue:hue saturation:saturation brightness:MIN(brightness + 0.15, 1) alpha:alpha];
        }
    }
    return baseColor;
}

@end

2. 封装UIColor分类，简化调用 #

为了让代码里的颜色调用更简洁，给UIColor加个分类：

@interface UIColor (AppTheming)
+ (UIColor *)appColorForName:(NSString *)name;
@end

@implementation UIColor (AppTheming)
+ (UIColor *)appColorForName:(NSString *)name {
    return [[AppColorManager sharedManager] colorForName:name];
}
@end

之后你在代码里获取颜色时，就用[UIColor appColorForName:@"primary_color"]替代原生的[UIColor colorNamed:]，这样所有颜色都会经过你的管理类处理。

3. 适配Interface Builder（可选） #

如果你希望在IB里也能预览运行时的自定义颜色效果，可以自定义IBDesignable控件，在控件内部使用你的颜色管理类：

IB_DESIGNABLE
@interface ThemedButton : UIButton
@end

@implementation ThemedButton

- (void)awakeFromNib {
    [super awakeFromNib];
    [self setupTheming];
}

- (void)prepareForInterfaceBuilder {
    [super prepareForInterfaceBuilder];
    [self setupTheming];
}

- (void)setupTheming {
    self.backgroundColor = [UIColor appColorForName:@"primary_color"];
    [self setTitleColor:[UIColor appColorForName:@"primary_text_color"] forState:UIControlStateNormal];
    self.layer.shadowColor = [[UIColor appColorForName:@"primary_derived_shadow"] CGColor];
    // 其他样式设置
}

@end

这样在IB里使用ThemedButton，运行时会自动应用自定义颜色，而默认状态下显示Asset中的颜色。

为什么不建议重写系统类？ #

Apple的Asset Catalog相关的底层类（比如你设想的MyOverriddenAssets对应的系统类）都是私有API，没有公开文档支持。强行通过Method Swizzling或者子类化重写，会带来两个问题：

• 稳定性风险：系统版本更新后，私有API可能发生变化，导致App崩溃。
• 审核风险：App Store审核会检测私有API调用，可能导致审核不通过。

而我们的方案完全基于公开API，既安全又能满足你的所有需求：

• 单Target架构下支持用户自定义主色
• 保留Asset Catalog管理默认颜色的便利性
• 完美兼容你的衍生色计算算法
• 支持视障适配（比如可以根据用户的动态类型/颜色反转需求，在管理类中额外处理）

内容的提问来源于stack exchange，提问作者Anticro