视觉模式适配（DarkMode）的七种武器

仿照AppCompat类，将原生控件替换成自定义控件，统一控制 当我们引入appcompat-v7，有了AppCompatActivity的时候，我们发现我们渲染的TextView/Button等组件分别变成了AppCompatTextView和AppCompatButton。同理,我们可以借助于LayoutInflaterCompat设置我们自己的LayoutInflaterFactory。然后，参考google的方式，将xml里的原生控件，转化成我们的自定义控件。

// We can emulate Lollipop's android:theme attribute propagating down the view hierarchy
// by using the parent's context
if (inheritContext && parent != null) {
    context = parent.getContext();
}
if (readAndroidTheme || readAppTheme) {
    // We then apply the theme on the context, if specified
    context = themifyContext(context, attrs, readAndroidTheme, readAppTheme);
}
if (wrapContext) {
    context = TintContextWrapper.wrap(context);
}

View view = null;

// We need to 'inject' our tint aware Views in place of the standard framework versions
switch (name) {
    case "TextView":
        //view = new AppCompatTextView(context, attrs); 
        view = new SkinnableTextView(context, attrs); //自定义view
        break;
    case "ImageView":
        view = new AppCompatImageView(context, attrs);
        break;
    ......
}

if (view == null && originalContext != context) {
    // If the original context does not equal our themed context, then we need to manually
    // inflate it using the name so that android:theme takes effect.
    view = createViewFromTag(context, name, attrs);
}

if (view != null) {
    // If we have created a view, check it's android:onClick
    checkOnClickListener(view, attrs);
}

return view;

} " data-snippet-id="ext.31d55951ca97c8a347768df7cc13bc38" data-snippet-saved="false" data-codota-status="done"> public final View createView(View parent, final String name, @NonNull Context context, @NonNull AttributeSet attrs, boolean inheritContext, boolean readAndroidTheme, boolean readAppTheme, boolean wrapContext) { final Context originalContext = context; // We can emulate Lollipop's android:theme attribute propagating down the view hierarchy // by using the parent's context if (inheritContext && parent != null) { context = parent.getContext(); } if (readAndroidTheme || readAppTheme) { // We then apply the theme on the context, if specified context = themifyContext(context, attrs, readAndroidTheme, readAppTheme); } if (wrapContext) { context = TintContextWrapper.wrap(context); } View view = null; // We need to 'inject' our tint aware Views in place of the standard framework versions switch (name) { case "TextView": //view = new AppCompatTextView(context, attrs); view = new SkinnableTextView(context, attrs); //自定义view break; case "ImageView": view = new AppCompatImageView(context, attrs); break; ...... } if (view == null && originalContext != context) { // If the original context does not equal our themed context, then we need to manually // inflate it using the name so that android:theme takes effect. view = createViewFromTag(context, name, attrs); } if (view != null) { // If we have created a view, check it's android:onClick checkOnClickListener(view, attrs); } return view; }

每次需要换肤的时候就调用setDayNightMode函数, 它会去通知View层级中所有实现了Skinnable接口的对象. 调用他们的applyDayNight方法, 来切换他们的样式. 我们在View生成的时候, 记录下了它引用的一些资源id, 然后因为切换了UiMode后, 获取相同资源 id 得到的实质资源不一样的特性来完成夜间模式切换的方案. 类似CSS的视图控制方案 服务端下发一份类似CSS的样式表，key由客户端定义，对应客户端某一类的视图的某一个属性，value则是一个样式值。客户端在渲染时，则按照预定的规则读取对于的样式值。这种方式的关键在于这个读取--设置的过程，是集中化的，还是每个视图都需要自己控制。它取决了协议的设计水平，也决定了开发的成本。这个我们在后面优酷实践的部分会详细介绍一下。 通过开关设置不同的参数 服务端下发当前希望的模式，组件开发者把这个模式当作是普通的参数一样，对不同的参数，进行不同的渲染。这把所有的工作量都放到了组件开发的部分。设计最简单。

写在最后 上面列举了多种实现模式切换的方案，本身并没有优劣之分，具体使用哪种取决于业务需求和技术生态。比如，切换theme或者uimode的方案中就有需要recreate activtiy的痛点，资源id映射的方式又需要修改通常获得资源的方式，仿CSS设置为代码的自定义视图或实现特定接口的方式，虽然拥有很大的灵活性和通用性，又需要修改每一个的组件，这对于超级App的工作量是非常可怕的。

具体到DarkMode这个场景，它是对系统定义的一种视觉模式的适配。系统为它做好了一部分前期工作，这就让DesignToken方案显得简单又高效，在优酷，结合designToken体系和已有的换肤方案，可以覆盖绝大部分场景，而只需要进行一些细节的走查。而且DarkMode的切换在最新系统版本是系统行为，在较低的系统版本应该是由用户主动触发，所以似乎也没有由服务端控制的需求。