视觉模式适配（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则是一个样式值。客户端在渲染时，则按照预定的规则读取对于的样式值。这种方式的关键在于这个读取--设置的过程，是集中化的，还是每个视图都需要自己控制。它取决了协议的设计水平，也决定了开发的成本。这个我们在后面优酷实践的部分会详细介绍一下。
通过开关设置不同的参数
服务端下发当前希望的模式，组件开发者把这个模式当作是普通的参数一样，对不同的参数，进行不同的渲染。这把所有的工作量都放到了组件开发的部分。设计最简单。这个在优酷也有对应的场景，我们后面会介绍一下。
演武台
具体到优酷来说，目前已经进行了这样一些实践。
流派：下发模式开关 + 资源 id 映射
代表：播放页沉浸式
截图：

具体介绍一下，播放页沉浸式的核心控制类ImmersivePageModeUtil，每个组件都通过读取它来确定自己的渲染结果。

public boolean getImmersiveMode() {
return mIsImmersiveMode;
}
" data-snippet-id="ext.afb805d3155cea21da9c03d845fac6a3" data-snippet-saved="false" data-codota-status="done"> public void setIsImmersiveMode(boolean isImmersiveMode) { mIsImmersiveMode = isImmersiveMode; }
public boolean getImmersiveMode() { return mIsImmersiveMode; }
复制

public static void setTextColor(TextView title, int colorImmersiveId, int colorId) {
    if (title == null) {
        return;
    }
    if (ImmersivePageModeUtil.getInstance().getImmersiveMode()) {
        title.setTextColor(ContextCompat.getColor(title.getContext(), colorImmersiveId));
    } else {
        title.setTextColor(ContextCompat.getColor(title.getContext(), colorId));
    }
}
复制代码

复制
播放页还有一部分内容是星球的评论sdk，评论sdk的模式切换方式就是典型的资源 id 映射。

 if (mIsImmersiveMode && !TextUtils.isEmpty(mImmersiveUrl)){
        //评论星球设置沉浸式
        ThemeManager.getInstance().loadScene("darkScence");
        HashMap<String, String> map = new HashMap<>(3);
        map.put(ThemeManager.KEY_OBSCURE_URL, mImmersiveUrl);
        map.put(ThemeManager.KEY_OBSCURE_BG_COLOR, IMMERSIVE_COLOR);
        map.put(ThemeManager.KEY_OBSCURE_LEVEL, String.valueOf(IMMERSIVE_LEVEL));
        ThemeManager.getInstance().setObscureBgMap(map);
        if (null != mCallback) {
            mCallback.onGetUrlSuccess(mImmersiveUrl);
        }
    } else {
        //评论星球设置默认模式
        ThemeManager.getInstance().loadScene("defaultScence");
        ThemeManager.getInstance().setObscureBgMap(null);
    }
复制代码

复制
流派：CSS样式表下发 + 自定义控件
代表：首页高清频道
截图：

高清频道的实现是基于优酷的统一组件渲染架构的能力，在优酷统一组件渲染架构中，我使用了万花筒的插件模型，对所有的组件渲染过程进行了抽象，为统一控制组件渲染行为提供了接口，而在组件内部，则设计了MVP的结构，所以我们可以通过在V的基类中进行操作，从而完成对组件样式的集中式设置，大大减少具体组件开发人员的工作量。
前提有了，剩下就是要打通从氛围配置到最终渲染的数据链路了。考虑到灵活性，我们把氛围配置放到了运营侧的柏拉图平台，然后通过哥伦布进行下发，客户端则在解析页面，抽屉，组件时，获取服务端样式描述数据，建立起氛围key与样式描述文件的关系，创建组件View时，由AbsPresenter根据样式协议找到相应的View应用氛围value，也提供代码中手动绑定view和氛围value的方式。


流派：UIMode + DesignToken
代表：精选页 / 会员页 / 搜索结果页
截图：






这个方案是基于我们的另一个业务架构模块公共组件库的，从下图中，可以看到，每个主题都是从一组组value一层层搭建起来的，而优酷的组件代码中，也直接引用的是这些designtoken的引用。这就为我们统一修改提供了技术基础。我们可以在暗黑模式下，对色值的designtoken设置另一套值，就可以对应用视觉进行整体的变化。这对于designtoken体系，是天然支持的。我们在资源文件中，新建一个-night文件夹，在需要的时候，调用上文提到的getDelegate().setLocalNightMode(AppCompatDelegate.MODE_NIGHT_YES）接口，进行模式的切换。


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

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