反思 _ 开启B站少女心模式，探究APP换肤机制的设计与实现(2)

**/
@ColorRes
public static int getColorRes(@ColorRes int colorRes) {
// 伪代码
if (isLightMode) { // 日间模式
return colorRes; // skinPrimaryTextColor
} else { // 夜间模式
return colorRes + “_Dark”; // skinPrimaryTextColor_Dark
}
}

// 代码中使用该方法，设置标题和次级标题颜色
tv.setTextColor(SkinUtil.getColorRes(R.color.skinPrimaryTextColor));
tvSubTitle.setTextColor(SkinUtil.getColorRes(R.color.skinSecondaryTextColor));

很明显，return colorRes + "_Dark"这行代码作为int类型的返回值是不成立的，读者无需关注具体实现，因为这种封装仍 未摆脱笨重的 if-else 实现 的本质。

可以预见，随着主题数量逐步增多，换肤相关的代码越来越臃肿，最关键的问题是，所有控件的相关颜色都强耦合于换肤相关代码本身，每个UI容器（Activity/Fragment/自定义View）等需要追加Java代码手动设置。

此外，当皮肤数量达到一定规模时，color资源的庞大势必影响到apk体积，因此主题资源的动态加载发势在必行，用户安装应用时默认只有一个主题，其它主题 按需下载和安装 ，比如淘宝：

到了这里，皮肤包 的概念应运而出，开发者需要将单个主题的颜色资源视为一个 皮肤包，在不同的主题下，对不同的皮肤包进行加载和资源替换：

#000000 ... #FFFFFF ...

这样，对于业务代码而言，开发者不再需要关注具体是哪个主题，只需要按常规的方式进行颜色的指定，系统会根据当前的颜色资源对View进行填充：

回到本小节最初的问题，产品化思维也是一个优秀的开发者不可或缺的能力：先根据需求罗列不同的实现方案，做出对应的权衡，最后动手编码。

三、整合思路

目前为止，一切都还停留在需求提出和设计阶段，随着需求的明确，技术难点逐一罗列在开发者面前。

1.动态刷新机制

开发者面临的第一个问题：如何实现换肤后的 动态刷新 功能。

以微信注册页面为例，手动切换到深色模式后，微信进行了页面的刷新：

读者不禁会问，动态刷新的意义是什么 ，让当前页面重建或者APP重启不行吗？

当然可行，但是 不合理 ，因为页面重建意味着页面状态的丢失，用户无法接受一个表单页面已填信息被重置；而如果要弥补这个问题，对每个页面重建追加状态的保存（Activity.onSaveInstanceState()），在实现的角度来看，也是一个巨大的工程量。

因此动态刷新势在必行——用户无论是在应用内切换了皮肤包，还是手动切换了系统的深色模式，我们如何将这个通知进行下发，保证所有页面都完成对应的刷新呢？

2.保存所有页面的Activity

读者知道，我们可以通过Application.registerActivityLifecycleCallbacks()方法观察到应用内所有Activity的生命周期，这也意味着我们可以持有所有的Activity：

public class MyApp extends Application {

// 当前应用内的所有Activity
private List mPages = new ArrayList();

@Override
public void onCreate() {
super.onCreate();
registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
@Override
public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) {
mPages.add(activity);
}

@Override
public void onActivityDestroyed(@NonNull Activity activity) {
mPages.remove(activity);
}

// …省略其它生命周期
});
}
}

有了所有的Activity的引用，开发者就可以在接到换肤通知的时候，第一时间尝试让所有页面的所有View去更新换肤。

3.成本问题

但巨大的谜团随之映入眼帘，对于控件而言，更新换肤这个概念本身并不存在。

什么意思呢？ 当换肤通知到达时，我无法令TextView更新文字颜色，也无法令View更新背景颜色——它们都只是系统的控件，执行的都是最基础的逻辑，说白了，开发者根本无法进行编码。

有同学说，那我直接让整个页面的整个View树所有View都全部重新渲染可以吗？可以，但是又回到了最初的问题，那就是所有View本身的状态也被重置了（比如EditText的文字被清零），退一步讲，即使这一点可以被接受，那么整个View树的重新渲染也会极大影响性能。

那么，如何尽可能的 节省页面动态刷新的成本 ？

开发者希望，换肤发生时，只对指定控件的指定属性进行动态更新，比如，TextView只关注更新background和textColor，ViewGroup只关注background，其他的属性不需要重置和修改，将设备的每一分性能都利用到极致：

public interface SkinSupportable {
void updateSkin();
}

class SkinCompatTextView extends TextView implements SkinSupportable {

public void updateSkin() {
// 使用当前最新的资源更新 background 和 textColor
}
}

class SkinCompatFrameLayout extends FrameLayout implements SkinSupportable {

public void updateSkin() {
// 使用当前最新的资源更新 background
}
}

如代码所示，SkinSupportable是一个接口，实现该接口的类意味着都支持动态刷新，当换肤发生时，我们只需要拿到当前的Activity，并通过遍历View树，让所有SkinSupportable的实现类都去执行updateSkin方法进行自身的刷新，那么整个页面也就完成了换肤的刷新，同时不会影响View本身当前其他的属性。

当然，这也意味着开发者需要将常规的控件进行一轮覆盖性的封装，并提供出对应的依赖：

implementation ‘skin.support:skin-support:1.0.0’ // 基础控件支持，比如SkinCompatTextView、SkinCompatFrameLayout等
implementation ‘skin.support:skin-support-cardview:1.0.0’ // 三方控件支持，比如SkinCompatCardView
implementation ‘skin.support:skin-support-constraint-layout:1.0.0’ // 三方控件支持，比如SkinCompatConstraintLayout

从长期来看，针对控件一一封装，提供可组合选择的依赖，对于换肤库的设计者而言，库本身的开发成本其实并不高。

4.牵一发而动全身

但负责业务开发的开发者叫苦不迭。

按照目前的设计，岂不是工程的xml文件中所有控件都需要重新进行替换？

<skin.support.SkinCompatTextView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:text=“Hello World”
android:textColor=“@color/skinPrimaryTextColor” />

从另一个角度来看，这又是额外的成本，如果哪一天想要剔除或者替换换肤库，那么无异于一次新的重构。

因此设计者需要尽量避免类似 牵一发而动全身 的设计，最好是让开发者无感知的感受到换肤库的 动态更新。

5.着手点: LayoutInflater.Factory2

对 LayoutInflater 不了解的读者，可以参考笔者的 这篇文章 。

了解LayoutInflater的读者应该知道，在解析xml文件并实例化View的过程中，LayoutInflater通过自身的Factory2接口，将基础控件拦截并创建成对应的AppCompatXXXView，既避免了反射创建View对性能的影响，也保证了向下的兼容性:

switch (name) {
// 解析xml，基础组件都通过new方式进行创建
case “TextView”:
view = new AppCompatTextView(context, attrs);
break;
case “ImageView”:
view = new AppCompatImageView(context, attrs);
break;
case “Button”:
view = new AppCompatButton(context, attrs);
break;
case “EditText”:
view = new AppCompatEditText(context, attrs);
break;
// …
default:
// 其他通过反射创建
}

一图以蔽之：

因此，LayoutInflater本身的实现思路为我们提供了一个非常好的着手点，我们只需要对这段逻辑进行拦截，将控件的实例化委托给换肤库即可：

如图所示，我们使用SkinCompatViewInflater拦截替换了系统LayoutInflater本身的逻辑，以CardView为例，解析标签时，将CardView生成的逻辑委托给下面的依赖库，如果工程中添加了对应的依赖，那么就能生成对应的SkinCompatCardView，其自然支持了动态换肤功能。

当然，这一切逻辑的实现，起源于工程添加对应的依赖,然后在APP启动时进行初始化：

implementation ‘skin.support:skin-support:1.0.0’
implementation ‘skin.support:skin-support-cardview:1.0.0’
// implementation ‘skin.support:skin-support-constraint-layout:1.0.0’ // 未添加ConstraintLayout换肤支持

// App.onCreate()
SkinCompatManager.withApplication(this)
.addInflater(new SkinAppCompatViewInflater()) // 基础控件换肤
.addInflater(new SkinCardViewInflater()) // cardView
//.addInflater(new SkinConstraintViewInflater()) // 未添加ConstraintLayout换肤支持
.init();

以ConstraintLayout为例，当没有对应的依赖时（），则会默认通过反射进行构造，生成标签本身对应的ConstraintLayout，其本身因为未实现SkinSupportable，自然不会进行换肤更新。

这样，库的设计者为换肤库提供了足够的灵活性，既避免了对现有工程大刀阔斧的修改，又保证极低的使用和迁移成本，如果我希望 移除 或者 替换 换肤库，只需要删除build.gradle中的依赖和Application中初始化的代码就可以了。

四、深入性探讨

接下来笔者将针对换肤库本身更多细节进行深入性的探讨。

1、皮肤包加载策略

策略模式 在换肤库的设计过程中也有非常良好的体现。

对于不同的皮肤包而言，其 加载、安装的策略理应是不同的 ，举例来说：

• 1、每个APP都有一个默认的皮肤包（通常是日间模式），策略需要安装后立即对其进行加载；
• 2、如果皮肤包是远程的，用户点击切换皮肤，需要从远程拉取，下载成功后进行安装加载；
• 3、皮肤包下载安装成功，之后应该从本地SD卡进行加载；
• 4、其他自定义加载策略，比如远程的皮肤包有加密，本地加载后解密等。

因此，设计者应将皮肤包的加载和安装抽象为一个SkinLoaderStrategy接口，便于开发者更方便和灵活性的按需配置。

此外，由于加载行为本身极大可能是耗时操作，因此应该控制好线程的调度，并及时通过定义SkinLoaderListener回调，对加载的进度和结果进行及时的通知：

/**

• 皮肤包加载策略.
  /
  public interface SkinLoaderStrategy {
  /*
• 加载皮肤包.
  */
  String loadSkinInBackground(Context context, String skinName, SkinLoaderListener listener);
  }

/**

• 皮肤包加载监听.
  /
  public interface SkinLoaderListener {
  /*
• 开始加载.
  */
  void onStart();

/**

• 加载成功.
  */
  void onSuccess();

/**

• 加载失败.
  */
  void onFailed(String errMsg);
  }

2、进一步节省性能

上文中，笔者提到，因为持有了所有的Activity的引用，所以换肤库在换肤后，可以尝试让所有页面的所有View去更新换肤。

实际上「更新所有页面动」通常是没必要的，更合理的方式是提供一个可配置项，换肤成功时，默认只刷新前台的Activity，其它页面在onResume执行后再更新，这样能够大幅度降低渲染带来的性能影响。

此外，每次换肤重复的遍历View树进行刷新也是一个耗时的操作，可以通过在LayoutInflater创建View树的同时，将实现了SkinSupportable的View存在页面所属的一个集合中，当换肤发生时，只需要针对集合中的View进行更新即可。

最后，可以将上述文字中的Activity和View都通过弱引用去持有，以降低内存泄漏的可能。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

结尾

最后，针对上面谈的内容，给大家推荐一个Android资料，应该对大家有用。

首先是一个知识清单：（对于现在的Android及移动互联网来说，我们需要掌握的技术）

泛型原理丶反射原理丶Java虚拟机原理丶线程池原理丶
注解原理丶注解原理丶序列化
Activity知识体系（Activity的生命周期丶Activity的任务栈丶Activity的启动模式丶View源码丶Fragment内核相关丶service原理等）
代码框架结构优化（数据结构丶排序算法丶设计模式）
APP性能优化（用户体验优化丶适配丶代码调优）
热修复丶热升级丶Hook技术丶IOC架构设计
NDK（c编程丶C++丶JNI丶LINUX）
如何提高开发效率？
MVC丶MVP丶MVVM
微信小程序
Hybrid
Flutter

接下来是资料清单：（敲黑板！！！）

---

1.数据结构和算法

2.设计模式

3.全套体系化高级架构视频；七大主流技术模块，视频+源码+笔记

4.面试专题资料包（怎么能少了一份全面的面试题总结呢~）

不论遇到什么困难，都不应该成为我们放弃的理由！共勉~

如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

g-5XREXCTl-1713530948027)]

4.面试专题资料包（怎么能少了一份全面的面试题总结呢~）

[外链图片转存中…(img-mSn5xHpP-1713530948027)]

不论遇到什么困难，都不应该成为我们放弃的理由！共勉~

如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。

[外链图片转存中…(img-JKZaWvEL-1713530948028)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！