本文主要是介绍反思 _ 开启B站少女心模式,探究APP换肤机制的设计与实现,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
换肤规范的目的是什么?对于UI设计和开发人员而言,设计与开发都应该基于统一且完整的规范之上进行,以掘金APP为例:
对于UI设计人员,在APP不同的主题下,控件的颜色不再是一个单一的值,而应该用一个通用的key
来进行定义,如上图所示,「标题」的颜色,在日间应该是黑色#000000
,而深色模式下则应该为白色#FFFFFF
,同理,「次级标题」、「主背景色」、「分割线颜色」,都应该随着不同的主题下,对应不同的值。
设计人员在设计时,仅需要针对页面每一个元素填充好对应的key
,根据规范很清晰地完成UI设计:
颜色Key | 日间模式 | 深色模式 | 备注 |
---|---|---|---|
skinPrimaryTextColor | #000000 | #FFFFFF | 标题字体颜色 |
skinSecondaryTextColor | #CCCCCC | #CCCCCC | 次级标题字体颜色 |
skinMainBgColor | #FFFFFF | #333333 | 页面主背景色 |
skinSecondaryBgColor | #EEEEEE | #000000 | 次级背景、分隔线背景色 |
其他更多… | |||
skinProgressBarColor | #000000 | #FFFFFF | 进度条颜色 |
这对于开发人员的效率提升更加明显,开发者不再需要关心具体颜色的值,只需要将对应的color
填充到布局中即可:
二、构建产品化思维:皮肤包
如何衡量一个开发人员的能力——对复杂功能快速、稳定的交付?
如果只是单纯的认可这个理念,那么对于换肤功能的实现反而简单了,以标题颜色skinPrimaryTextColor
为例,我只需要声明两个color
资源:
笔者成功摆脱了复杂的编码实现,在Activity
中我只需2行代码即可:
public void initView() {
if (isLightMode) { // 日间模式
tv.setTextColor(R.color.skinPrimaryTextColor);
} else { // 夜间模式
tv.setTextColor(R.color.skinPrimaryTextColor_Dark);
}
}
这种实现并非一无是处,从实现的难度而言,至少能够保护开发者为数不多的发囊。
当然,这种方案有「优化空间」,比如提供封装的工具方法 看似摆脱 无尽的if-else
:
/**
- 获取当前皮肤下真正的color资源,所有color的获取都必须通过该方法。
**/
@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
:
p 《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》无偿开源 徽信搜索公众号【编程进阶路】 ublic 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;
// …
extView(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;
// …
这篇关于反思 _ 开启B站少女心模式,探究APP换肤机制的设计与实现的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!