企业官网建设流程全解析

两周前，被运营追着问“春节皮肤什么时候能上”——新主题已经画好了，但按常规发版节奏，审核走完，春节也过完了。那段时间我正好在重构项目的主题模块，索性把“预置多套主题”的老路彻底换掉，改成了一套走“Android插件化换肤”思路的实现。换完以后，新皮肤是运营直接从后台下发的，主程序一行代码都没改，第二天就全量生效了。

这篇文章就把这套插件化换肤的思路和落地过程完整写出来。不吹概念，只讲我怎么设计皮肤包、怎么在运行时加载外部资源、怎么让已经创建的View“穿上”新皮肤，以及上线前踩过的那些边界坑。适合已经对Android资源系统有一定了解、想在项目里自研换肤框架或者改造现有主题模块的开发者看看。

1. 换肤方案的选型：预置主题为什么撑不住，插件化解决什么问题

1.1 预置多套主题的“能做”和“不能做”

早年间大多数App做换肤，都是直接在工程里放几套主题资源，用户点一下按钮，setTheme加recreate，瞬间切换。这种做法在主题数量少、UI改动不频繁的阶段是够用的。

但一旦需求变成“每季度一套视觉”“大促期间临时上一套活动皮肤”“给不同用户群体下发不同皮肤”，预置方案就卡住了：

• 包体膨胀。一套皮肤就算只换颜色和图片，少说也要几百KB，放四五套进去，安装包直接大两三兆，用户下载转化率会受影响。
• 发版周期长。新皮肤做完不能马上上，要走完整个发版流程。刚才说的春节皮肤就是典型的反面教材。
• 运营不灵活。上一套皮肤是运营活动的一部分，没法做到“今天设计稿定了，明天就能在所有用户手机上看到”。

所以当产品提出这类需求时，第一反应不应该是“再做两套内置主题”，而是重新审视整个主题机制——把皮肤和主程序解耦。

1.2 插件化换肤的实质：运行时替换资源，而不是加载代码

很多人听到“插件化”会下意识想到动态加载Dex、跑字节码、反射调方法，这套换肤方案完全不需要这些。

插件化换肤里的“插件”是一个只包含资源文件的独立Apk，我们动态把它挂载到运行时，让App去读它里面的res和resources.arsc。本质上是“资源级别的插件化”。

为什么能做到这一点？因为Android的资源ID是一个32位整数，结构大致是PP TT EEEE，PP是包ID，TT是资源类型，EEEE是资源序号。宿主App的默认包ID通常是0x7f，皮肤包默认也是0x7f，但它们分属不同的Apk文件。系统提供了一套机制，让一个Resources对象可以同时管理多个已挂载的Apk资源——这给了我们在运行时“加塞”资源的空间。

这里要强调一个认知：这套方案不能替换Java逻辑、不能改变Activity的结构，它只负责把View的background、textColor、src这些资源引用，替换成皮肤包里同名同类型的新资源。主题（Theme/Style）层面的切换是另一套工作，后面会专门说。

1.3 什么样的项目适合自研换肤框架

不是所有项目都有必要自研。我在选型前画了一张评估表，你可以对照自己团队的情况：

如果你的App属于右边这列，自研换肤的收益就很明显。核心链路做完大概一周，剩下时间基本都耗在边缘场景上——各种弹窗、状态栏、列表item、Activity重建。这篇文章会把这部分尽量讲全，帮你少走点弯路。

2. 皮肤包：一个只装资源的Apk该怎么设计

2.1 皮肤包里面装了什么

皮肤包本质上就是一个正常的Apk，但它里面没有代码逻辑，核心只有两部分：

• res/目录：编译好的资源，包括drawable、color、layout等。
• resources.arsc：资源索引表，记录了资源名、类型和ID之间的映射关系。

打包方式也简单：新建一个Android工程，只放资源文件，不写任何Java/Kotlin代码，打出来的Apk就是皮肤包。这个Apk不需要能安装运行，它只是给宿主App提供资源的“仓库”。

这里有个新手很容易误解的点：皮肤包必须是用Android打包工具链编译过的Apk，而不是一个普通的zip、一堆png或xml文件堆在一起。因为AssetManager只能解析编译后的资源格式，直接扔一个main_bg.png进去是不行的。

2.2 资源ID冲突：为什么不能直接拿宿主的R文件去用

刚开始做的时候，我犯过一个经典的错误：以为皮肤包里的资源只要能通过某个ID访问就行。

宿主App里所有资源的ID都写在R.java里，比如R.drawable.main_bg对应0x7f080123。这个数字是我写死在代码里的，但皮肤包是另一个工程编译出来的，它内部即使有一个同名main_bg，ID也大概率是另一个数字。如果你拿着宿主的0x7f080123去皮肤包的Resources里找资源，运气好查不到，运气差会拿到一个别的资源——表现出来就是背景图错乱、颜色诡异。

有人会用aapt参数强制把皮肤包的包ID改成和宿主一致，让两边资源ID完全对齐。这条路能走通，但不建议作为默认方案：不同Gradle插件版本对aapt参数的位置和写法要求不一样，升级一次工具链就要重新踩一遍配置坑；而且固定包ID一旦分配不好，还容易和系统资源区段冲突，排查起来非常痛苦。

2.3 真正的契约：靠资源名匹配，而不是ID匹配

我最终采用的方案是“资源名称匹配”，这也是多数成熟换肤框架的做法。

宿主里每一个需要换肤的资源，记下它的两个信息：资源类型（drawable、color等）和资源名称（比如main_bg）。换肤时，去皮肤包里用getIdentifier("main_bg", "drawable", 皮肤包包名)查到皮肤包里的资源ID，再通过皮肤包的Resources去加载。

这样皮肤包和宿主完全不需要共享ID。设计皮肤包的人只要保证一件事：资源和宿主同名同类型。宿主有res/drawable/main_bg.xml，皮肤包里也得有res/drawable/main_bg.xml；宿主有res/color/main_text_color.xml，皮肤包里也得放一个同名文件，内容随意。

这也意味着资源命名规范极其重要。我后来在项目里强制要求所有参与换肤的资源统一加main_、common_这类前缀，避免和其他模块里的资源撞名。否则换个皮肤，把别的模块的图片给换了，画面会很刺激。

2.4 一个可用的最小皮肤包工程配置

皮肤包工程可以非常简单，核心配置如下：

apply plugin: 'com.android.application' android { namespace "com.example.skin.spring" compileSdk 33 defaultConfig { applicationId "com.example.skin.spring" minSdk 21 targetSdk 30 } buildTypes { release { minifyEnabled false shrinkResources false signingConfig signingConfigs.debug } } } dependencies { }

关键点是：applicationId固定下来，后面负责识别皮肤包包名；关闭混淆和资源压缩，保证资源文件原样保留。打包执行：

./gradlew :skin:assembleRelease

产物就是skin-release.apk，把它放到服务器上或者直接放进App私有目录，就能被运行时加载。这里有一个工程层面的小建议：第一次做皮肤包时，最好同步维护一份“资源契约清单”，把宿主和皮肤包之间约定的资源名、类型列清楚。没有这份清单的时候，设计师和开发很容易互相甩锅：“明明皮肤包里有这个资源啊，为什么没生效？”结果一看，名字差一个字母。

3. 运行时加载：AssetManager与第二个Resources的兼容方案

3.1 为什么非要另造一个Resources

在Android里，Context.getResources()拿到的是Application启动时就创建好的Resources对象，它内部持有一个AssetManager，负责读取宿主Apk全部资源。这套东西在进程启动时已经定型，我们不会去动它。

换肤需要的是一个“增强版”Resources：既能访问宿主资源，又能访问皮肤包资源。做法是手工创建一个新的AssetManager，把宿主Apk路径和皮肤包路径都挂载进去，再基于这个AssetManager new一个Resources对象。

这是整个换肤方案的基石。理解了这个，后面所有代码都好懂了：皮肤资源从这个新的Resources里取，而View本身还挂在宿主Context下，两者互不干扰。

3.2 AssetManager的跨版本兼容写法

AssetManager这条路，不同Android版本上的开放程度不一样。早期版本可以通过反射调addAssetPath，高版本官方推荐用ApkAssets。实际项目中我采用了一种“能上新API就上新API，上不了就反射兜底”的写法：

public static Resources loadSkinResources(String skinPath, Resources hostResources) { try { AssetManager assetManager = AssetManager.class.getConstructor().newInstance(); // 先挂载宿主Apk，保证新Resources能访问宿主自身资源 assetManager.addAssetPath(hostResources.getResourceName(0).split(":")[0]); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { try { ApkAssets apkAssets = ApkAssets.loadFromPath(skinPath); AssetManager.class.getMethod("addApkAssets", ApkAssets.class) .invoke(assetManager, apkAssets); } catch (Throwable t) { // 高版本反射addAssetPath仍然可用，作为兜底 AssetManager.class.getMethod("addAssetPath", String.class) .invoke(assetManager, skinPath); } } else { AssetManager.class.getMethod("addAssetPath", String.class) .invoke(assetManager, skinPath); } return new Resources(assetManager, hostResources.getDisplayMetrics(), hostResources.getConfiguration()); } catch (Exception e) { Log.e("SkinEngine", "load skin resources failed", e); return hostResources; } }

我故意没有用context.getPackageResourcePath()来拿宿主路径，因为在一个非Activity的Context里，那个方法不一定返回期望结果。上面hostResources.getResourceName(0)这段代码，是拿到宿主第一个资源完整的包名:类型/名称字符串，截取前面的包名部分，再通过getIdentifier反查宿主包路径。这段看起来有点黑科技，但它确实在多个版本上验证过是稳定的。

3.3 皮肤包包名怎么识别

Resources.getIdentifier()需要一个包名参数，它指的是“资源所属的包名”，也就是皮肤包在AndroidManifest里的packageName。获取方式有三种：

• 用PackageManager.getPackageArchiveInfo()解析皮肤包Apk，返回的PackageInfo.packageName就是包名。
• 直接约定皮肤包固定包名，从文件名或配置文件读取。
• 解析Apk里的AndroidManifest二进制XML，这个最重，一般不用。

public static String getPackageNameFromApk(Context context, String apkPath) { try { PackageManager pm = context.getPackageManager(); PackageInfo info = pm.getPackageArchiveInfo(apkPath, 0); if (info != null) { return info.packageName; } } catch (Exception e) { Log.e("SkinEngine", "parse package failed", e); } // 兜底：从配置里读，前提是团队内部约定皮肤包固定包名 return SkinConfig.PLUGIN_PACKAGE_NAME; }

这里多说一句：getPackageArchiveInfo在部分ROM上会返回null，所以一定要有兜底逻辑。我在生产环境里就直接把皮肤包固定包名写进了配置，文件名也叫skin_spring.apk这种自解释格式，即使解析失败也能从配置里取。

3.4 SkinResources封装：先做一张懒加载的映射表

裸用Resources做换肤，代码会很散。更关键的是，getIdentifier()这个调用在系统内部有一套缓存机制，但第一次查询还是比较重的。我在SkinResources里维护了一张Map<String, Integer>，把“类型/名称”映射到皮肤资源ID，第一次查不到就记一个空值，避免反复查：

public class SkinResources { private final Resources hostRes; private Resources skinRes; private String pkg; private final Map<String, Integer> idCache = new HashMap<>(); public int findIdByName(String resName, String resType) { if (skinRes == null) return 0; String key = resType + "/" + resName; if (idCache.containsKey(key)) return idCache.get(key); int skinId = skinRes.getIdentifier(resName, resType, pkg); idCache.put(key, skinId); return skinId; } public Drawable getDrawable(int skinId) { if (Build.VERSION.SDK_INT >= 23) { return skinRes.getDrawable(skinId, null); } return skinRes.getDrawable(skinId); } public ColorStateList getColorStateList(int skinId) { return skinRes.getColorStateList(skinId); } }

这个类同时承担了“查询皮肤资源”和“兜底宿主资源”两个职责。当skinRes为空或者findIdByName返回0时，调用方直接使用宿主默认资源即可。

4. 引擎骨架：拦截View创建、记录换肤属性、逐个应用

4.1 LayoutInflater.Factory2：必须在View出生前介入

换肤要解决的核心问题是：怎么知道哪个View需要换哪个属性？总不能每次换肤都把整棵View树遍历一遍、挨个猜属性吧。

标准解法是用LayoutInflater.setFactory2()。setContentView()在解析XML布局、创建View时，会先把创建动作交给Factory2处理。我们在这里插一脚：等View创建完成后，读取XML布局属性里和换肤相关的项，记录到View的Tag里，方便后续换肤时直接取用。

这里有一个和AppCompatActivity打交道的关键坑：如果项目用的是AppCompatActivity，super.onCreate()的过程里，系统已经给LayoutInflater设置过一个AppCompat内部的Factory2。如果直接覆盖，AppCompat的View兼容逻辑就失效了。正确做法是把原来的Factory2保存下来，在自己创建的Factory里先调用旧的，拿到创建结果再打Tag：

public class SkinLayoutInflaterFactory implements LayoutInflater.Factory2 { private final LayoutInflater.Factory2 oldFactory; public SkinLayoutInflaterFactory(LayoutInflater.Factory2 oldFactory) { this.oldFactory = oldFactory; } @Override public View onCreateView(View parent, String name, Context context, AttributeSet attrs) { View view = null; if (oldFactory != null) { view = oldFactory.onCreateView(parent, name, context, attrs); } if (view == null) { view = createViewFallback(name, context, attrs); } if (view != null) { SkinTag tag = SkinTagParser.parse(context, attrs); if (tag != null) { view.setTag(R.id.skin_tag, tag); } } return view; } @Override public View onCreateView(String name, Context context, AttributeSet attrs) { return onCreateView(null, name, context, attrs); } }

安装时机要卡在super.onCreate()之后、setContentView()之前：

@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); LayoutInflater inflater = LayoutInflater.from(this); SkinLayoutInflaterFactory factory = new SkinLayoutInflaterFactory(inflater.getFactory2()); inflater.setFactory2(factory); setContentView(R.layout.activity_main); }

这个顺序是经过验证的：一开始我在setContentView()之后才设置Factory2，结果布局已经解析完了，一个Tag都没打上。

4.2 拦截View后记什么：SkinTag的设计

SkinTag不需要很复杂，我把每个需要换肤的属性抽象成一个SkinAttr：

public class SkinAttr { public String attrName; // background / src / textColor ... public String resType; // drawable / color ... public String resName; // main_bg ... public int defaultResId; // 宿主资源ID，回退用 } public class SkinTag { public List<SkinAttr> attrs = new ArrayList<>(); }

解析属性的核心代码是从AttributeSet里提取资源引用：

public static SkinTag parse(Context context, AttributeSet attrs) { SkinTag tag = null; Resources res = context.getResources(); for (String attrName : SKIN_ATTR_WHITE_LIST) { int resId = attrs.getAttributeResourceValue( "http://schemas.android.com/apk/res/android", attrName, 0); if (resId == 0) continue; String resName = res.getResourceEntryName(resId); String resType = res.getResourceTypeName(resId); if (tag == null) tag = new SkinTag(); tag.attrs.add(new SkinAttr(attrName, resType, resName, resId)); } return tag; }

我用了一个白名单，默认只处理background、src、textColor、textColorHint、progressDrawable这几个高频属性。不是所有属性都适合通用替换，比如layout_*这类布局参数就不该出现在皮肤包里。白名单机制能让引擎专注，也方便进行安全性审查。

这里有个坑：如果属性不是直接写在XML里，而是通过style="@style/xxx"注入的，上面的getAttributeResourceValue()拿不到值。完整解法要配合TypedArray去解析Style，工作量会大不少。我在通用方案里明确要求：需要换肤的属性不要在Style里写，避免解析遗漏。这是框架和使用方之间的约定，写清楚就不容易踩雷。

4.3 应用皮肤：getIdentifier、getDrawable、setBackground的完整链路

换肤的入口方法长这样：

public static void apply(View view, SkinResources skinResources) { SkinTag tag = (SkinTag) view.getTag(R.id.skin_tag); if (tag == null || skinResources == null || !skinResources.hasSkin()) return; for (SkinAttr attr : tag.attrs) { int skinId = skinResources.findIdByName(attr.resName, attr.resType); if (skinId == 0) continue; // 皮肤包没有这个资源，保持现状 switch (attr.attrName) { case "background": Drawable bg = skinResources.getDrawable(skinId); if (bg != null) view.setBackground(bg); break; case "src": if (view instanceof ImageView) { Drawable src = skinResources.getDrawable(skinId); if (src != null) ((ImageView) view).setImageDrawable(src); } break; case "textColor": if (view instanceof TextView) { ColorStateList csl = skinResources.getColorStateList(skinId); if (csl != null) ((TextView) view).setTextColor(csl); } break; } } }

这里有个新手最常踩的坑：千万不要写view.setBackgroundResource(skinId)。setBackgroundResource内部会调用view.getResources().getDrawable(id)，而View持有的Resources是宿主的，它会拿宿主资源去解析皮肤ID，结果自然不对。正确姿势只有一个：从SkinResources里拿到Drawable，再用view.setBackground(drawable)硬塞进去。

textColor还有一个细节：如果皮肤资源是一个selector，一定要用setTextColor(ColorStateList)而不是setTextColor(int)，否则selector的状态区分完全失效。

4.4 动态View、列表item、手动指定属性的三种补位方案

Factory2只能拦截XML里创建的View，代码里new出来的View不会经过它。所以在框架里我留了一个手动接口：

SkinManager.getInstance().apply(view, "background:main_bg;textColor:main_text_color,color");

字符串格式自己定义就行，内部解析成SkinAttr，打上Tag，立即调用apply，并把View加入待刷新集合。

列表item的换肤是另一个高频场景。RecyclerView的itemView虽然也是通过LayoutInflater创建的，Factory2能正常打Tag，但复用机制会让同一个itemView反复绑定不同数据。在onBindViewHolder里手动调用一次SkinManager.reApply(itemView)最稳妥。不要偷懒把每个item都注册进全局集合，否则列表滑动时全局集合会越来越大，刷新成本直线上升。

把这三个补充方案想清楚，引擎的覆盖面就基本完整了。

5. 上线前真正会翻车的边界场景

5.1 Activity被系统回收后重建：皮肤状态必须持久化

换肤框架最容易被忽视的场景是：用户换了皮肤，切到后台，系统内存吃紧把Activity回收了，用户切回来，Activity重新走onCreate——如果没有持久化皮肤状态，创建出来的新View全是默认皮肤，视觉上就会“闪回”一次。

解决思路是：换肤成功后，把皮肤文件路径和版本号写入SharedPreferences；Application启动时，在onCreate阶段尝试恢复。恢复之后，Activity重建时Factory2创建出来的View天然就是带皮肤的状态，不需要额外的无效闪烁。

另外，onResume里我也会做一次幂等的applyAll，主要是为了兜底那些动态创建、来不及打Tag的View。幂等的关键在用SkinTag里的defaultResId和当前皮肤ID做对比，相同就跳过，避免无意义的重复赋值。

5.2 Dialog、PopWindow、Toast、状态栏：窗口级的View也要管

只给Activity安装Factory2远远不够。

Dialog和PopupWindow用的是自己的LayoutInflater和Window，默认情况下不会经过Activity的Factory2。我的做法是在创建它们的时候手动安装同一个SkinLayoutInflaterFactory，并把它们所在的Window注册进换肤管理集合；Dialog注册OnShowListener，在显示时执行一次applyAll。

状态栏比较特殊，它不是一个普通View资源能解决的。Android的沉浸式状态栏，背景色和图标颜色需要调Window.setStatusBarColor()、WindowInsetsController这类系统API。我给这套机制单独抽象了一个WindowBarSkinStrategy，在换肤时根据皮肤包约定的状态栏资源名去查色值并设置。如果不做这一步，你就会看到内容区域换肤成功、顶栏还停留在上一个颜色的尴尬局面。

5.3 同一个Drawable被多处引用：ConstantState缓存惹的祸

有段时间我们遇到一个奇怪的现象：换肤后，一半的按钮背景变了，另一半没变。

排查发现，同一个资源ID对应的Drawable在Resources里被多个View共享，资源内部还缓存了ConstantState。某些场景下，我在第一次换肤时直接复用了旧Drawable对象，后面再换，系统拿到的还是老状态。

处理办法并不复杂：不要给旧Drawable做原地修改，每次换肤都从SkinResources重新解析出一个新的Drawable对象，再setBackground/ setImageDrawable。如果一次换肤后某些控件确实有残留状态，补一次view.invalidate()。列表里那种带selector的item，我则建议在Adapter里走专项替换，不依赖通用规则。

5.4 皮肤包资源缺失时回退与默认皮肤恢复

皮肤包和宿主之间的资源契约偶尔会“违约”——设计师在皮肤包里漏放了一个同名资源。我的策略是：findIdByName返回0就跳过，保持当前显示不变。这样漏资源最坏的结果是某个区域没换肤，而不是崩掉或花屏。

恢复默认皮肤时则相反，需要把那些“保持现状”的区域强制回退到宿主资源。此时不是“找不到就跳过”，而是“找不到就用defaultResId”。我通过一个forceDefault参数区分这两种行为。同时，恢复完默认皮肤后要清空持久化配置，否则下次进程重启又变回旧皮肤。

5.5 单例持有与内存泄漏的兜底

换肤管理器一般设计成单例，但它不能持有Activity或Dialog。我用ActivityLifecycleCallbacks在onDestroy时把对应Window从集合里移除；动态注册的View则通过OnAttachStateChangeListener在onViewDetachedFromWindow时移除引用，成员变量尽量用WeakReference。

还有一个细节：SkinResources持有AssetManager，AssetManager底层有Native资源，重复创建过多会浪费内存。框架里对同一皮肤文件做了单实例校验，重复loadSkin同一路径直接复用旧的SkinResources，不做二次挂载。

6. 性能、缓存与工程化落地要点

6.1 一次换肤到底干了多少活

把一次完整的换肤动作拆开看：

1. 加载皮肤文件，创建AssetsManager并挂载资源（只做一次）。
2. 解析皮肤包资源索引（首次getIdentifier最慢）。
3. 遍历所有已注册Window里的View树。
4. 对每个View读Tag，拿属性清单。
5. 查询皮肤资源ID，加载Drawable/ColorStateList。
6. 调用setBackground/ setTextColor/ setImageDrawable。

对几百个View的量级，在真机上整体耗时大概几十毫秒，低端机确实可能掉帧。所以我建议把第1、2步放到后台线程，第3到6步如果必须在主线程，做个简单的“只刷新有变化View”的diff逻辑就够了。这个优化优先级很高，别等用户真的觉得卡再去加。

6.2 资源查表与Drawable缓存

getIdentifier在系统内部虽然有缓存，但保留自己的映射表仍然值得：同一个资源名，第一次查不到就记为0，后续不用再问系统。Drawable对象本身也可以做一层LruCache，避免换肤时反复创建。不过缓存Drawable时要注意ConstantState的问题，缓存的是“新解析出来的对象”，而不是去旧对象上做修改。

我的缓存设计大概是两个Map：

// 名称/类型 -> 皮肤资源ID private final Map<String, Integer> idCache = new HashMap<>(); // 皮肤资源ID -> Drawable private final LruCache<Integer, Drawable> drawableCache = new LruCache<>(64);

颜色值不缓存，因为ColorStateList本身不重。

6.3 框架接入的目录结构与核心API

为了让新同事能快速上手，我把换肤相关代码收敛在独立包skinlib下：

skinlib/ SkinManager.java // 单例入口，加载/恢复/应用皮肤 SkinResources.java // 资源查询与缓存 SkinLayoutInflaterFactory.java // View创建拦截 SkinAttr.java / SkinTag.java // 换肤属性模型 SkinActivityLifecycle.java // Window生命周期管理

核心API就这几个：

接入方只需要在BaseActivity里调一行SkinCompat.init(this)，然后按资源契约往皮肤包工程里放资源即可。这个设计刻意没有侵入业务方太多，换肤框架不应该成为业务开发的负担。

6.4 还能怎么扩展：夜间模式、Compose、多皮肤并发

换肤框架做起来之后，很多需求其实是同一套底座的变体。

夜间模式本质上也是“资源的切换”，只是切换条件是系统uiMode而不是用户选的皮肤。可以把夜间模式看成一套内置的“系统皮肤”，优先级低于用户皮肤即可。实现时多套了一套Configuration判断，其余逻辑可以完全复用。

如果是新项目已经上了Compose，这套View体系的换肤机制就不适用了，但“加载外部皮肤包，生成主题配置对象”的思路不变——可以把皮肤包解析成Compose的ColorScheme数据源，然后动态更新MaterialTheme。

多皮肤并发的场景更偏工程化：皮肤版本校验、后台预下载、失败回滚、按用户分群下发，这些都可以基于这套资源挂载底座来做。

最后说一句个人体会：换肤框架做得越“通用”，踩的坑就越多。我给所有新接入的同事定的原则是：默认只换background、src、textColor三类属性，其他属性走白名单申请制。效果是，维护成本肉眼可见地低，设计师和开发之间的沟通成本也小了很多。如果你正准备在项目里做插件化换肤，建议先把这三类属性打通，跑通一版最小闭环，再往分割线、主题色、状态栏这些方向逐步扩展。能跑起来的换肤框架不一定要多复杂，但一定得有一份清晰的资源契约，和一套崩溃时不会把用户扔在半截皮肤里的兜底策略。