前言

View的绘制流程，其实也就是工作流程，指的就是Measure（测量）、Layout（布局）和Draw（绘制）。其中，measure用来测量View的宽和高，layout用来确定View的位置，draw则用来绘制View，这里解析的Android SDK为为Android 9.0版本。

Activity的构成

在了解绘制流程之前，我们首先要了解Activity的构成，我们都知道Activity要用setcontentView()来加载布局，但是这个方法具体是怎么实现的呢，如下所示：

public void setContentView(@LayoutRes int layoutResID) {


    getWindow().setContentView(layoutResID);

    initWindowDecorActionBar();

}



public Window getWindow() {

    return mWindow;

}

这里有一个getWindow()，返回的是一个mWindow,那这个是什么呢，我们接在在Activity原来里的attach()方法里可以看到如下代码：

final void attach(Context context, ActivityThread aThread,        Instrumentation instr, IBinder token, int ident,

        Application application, Intent intent, ActivityInfo info,

        CharSequence title, Activity parent, String id,

        NonConfigurationInstances lastNonConfigurationInstances,

        Configuration config, String referrer, IVoiceInteractor voiceInteractor,

        Window window, ActivityConfigCallback activityConfigCallback) {

    attachBaseContext(context);



    mFragments.attachHost(null /*parent*/);



    mWindow = new PhoneWindow(this, window, activityConfigCallback);

    mWindow.setWindowControllerCallback(this);

    mWindow.setCallback(this);

    mWindow.setOnWindowDismissedCallback(this);

    mWindow.getLayoutInflater().setPrivateFactory(this);

    

    ......

}

我们发现了原来mWindow实例化了PhoneWindow，那意思就是说Activity通过setcontentView()加载布局的方法其实就是调用了PhoneWindow的setcontentView()方法，那我们接着往下看PhoneWindow类里面具体是怎么样的。

@Overridepublic void setContentView(int layoutResID) {



    // Note: FEATURE_CONTENT_TRANSITIONS may be set in the process of installing the window

    // decor, when theme attributes and the like are crystalized. Do not check the feature

    // before this happens.

    if (mContentParent == null) {

        installDecor();  //在这里

    } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {

        mContentParent.removeAllViews();

    }



    if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {

        final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,

                getContext());

        transitionTo(newScene);

    } else {

        mLayoutInflater.inflate(layoutResID, mContentParent);

    }

    mContentParent.requestApplyInsets();

    final Callback cb = getCallback();

    if (cb != null && !isDestroyed()) {

        cb.onContentChanged();

    }

    mContentParentExplicitlySet = true;

}

点进PhoneWindow这个类我们可以知道这里的PhoneWindow是继承Window的，Window是一个抽象类。然后我们看里面的一些关键地方，比如installDecor()方法，我们看看里面具体做了啥。

private void installDecor() {    mForceDecorInstall = false;

    if (mDecor == null) {

        mDecor = generateDecor(-1); //注释1

        mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);

        mDecor.setIsRootNamespace(true);

        if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {

            mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);

        }

    } else {

        mDecor.setWindow(this);

    }

    if (mContentParent == null) {

        mContentParent = generateLayout(mDecor);    //注释2



        ......

    }

}

里面有一个标记注释为1的generateDecor()方法，我们看看具体做了啥。

protected DecorView generateDecor(int featureId) {


    // System process doesn't have application context and in that case we need to directly use

    // the context we have. Otherwise we want the application context, so we don't cling to the

    // activity.

    Context context;

    if (mUseDecorContext) {

        Context applicationContext = getContext().getApplicationContext();

        if (applicationContext == null) {

            context = getContext();

        } else {

            context = new DecorContext(applicationContext, getContext());

            if (mTheme != -1) {

                context.setTheme(mTheme);

            }

        }

    } else {

        context = getContext();

    }

    return new DecorView(context, featureId, this, getAttributes());

}

发现创建了一个DecorView，而这个DecorView继承了Framelayout，DecorView就是Activity的根View，接着我们回到标记注释2的generateLayout()方法，看看做了啥。

    

protected ViewGroup generateLayout(DecorView decor) {


    ......



    // Inflate the window decor.

    //根据不同情况加载不同的布局给layoutResource

    

    int layoutResource;

    int features = getLocalFeatures();

    // System.out.println("Features: 0x" + Integer.toHexString(features));

    if ((features & (1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {

        layoutResource = R.layout.screen_swipe_dismiss;

        setCloseOnSwipeEnabled(true);

    } else if ((features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_RIGHT_ICON))) != 0) {

        if (mIsFloating) {

            TypedValue res = new TypedValue();

            getContext().getTheme().resolveAttribute(

                    R.attr.dialogTitleIconsDecorLayout, res, true);

            layoutResource = res.resourceId;

        } else {

            layoutResource = R.layout.screen_title_icons;

        }

        // XXX Remove this once action bar supports these features.

        removeFeature(FEATURE_ACTION_BAR);

        // System.out.println("Title Icons!");

    } else if ((features & ((1 << FEATURE_PROGRESS) | (1 << FEATURE_INDETERMINATE_PROGRESS))) != 0

            && (features & (1 << FEATURE_ACTION_BAR)) == 0) {

        // Special case for a window with only a progress bar (and title).

        // XXX Need to have a no-title version of embedded windows.

        layoutResource = R.layout.screen_progress;

        // System.out.println("Progress!");

    } else if ((features & (1 << FEATURE_CUSTOM_TITLE)) != 0) {

        // Special case for a window with a custom title.

        // If the window is floating, we need a dialog layout

        if (mIsFloating) {

            TypedValue res = new TypedValue();

            getContext().getTheme().resolveAttribute(

                    R.attr.dialogCustomTitleDecorLayout, res, true);

            layoutResource = res.resourceId;

        } else {

            layoutResource = R.layout.screen_custom_title;

        }

        // XXX Remove this once action bar supports these features.

        removeFeature(FEATURE_ACTION_BAR);

    } else if ((features & (1 << FEATURE_NO_TITLE)) == 0) {

        // If no other features and not embedded, only need a title.

        // If the window is floating, we need a dialog layout

        if (mIsFloating) {

            TypedValue res = new TypedValue();

            getContext().getTheme().resolveAttribute(

                    R.attr.dialogTitleDecorLayout, res, true);

            layoutResource = res.resourceId;

        } else if ((features & (1 << FEATURE_ACTION_BAR)) != 0) {

            layoutResource = a.getResourceId(

                    R.styleable.Window_windowActionBarFullscreenDecorLayout,

                    R.layout.screen_action_bar);

        } else {

            layoutResource = R.layout.screen_title; //在这里！！！！！！！ 

        }

        // System.out.println("Title!");

    } else if ((features & (1 << FEATURE_ACTION_MODE_OVERLAY)) != 0) {

        layoutResource = R.layout.screen_simple_overlay_action_mode;

    } else {

        // Embedded, so no decoration is needed.

        layoutResource = R.layout.screen_simple;

        // System.out.println("Simple!");

    }



    ......



    mDecor.finishChanging();



    return contentParent;

}

generateLayout()方法代码比较长，这里截取了一部分，主要内容就是根据不同的情况加载不同的布局给layoutresource，在这里面有一个基础的XML，就是R.layout.screen_title。这个XMl文件里面有一个ViewStub和两个FrameLayout，ViewStub主要是显示Actionbar的，两个FarmeLayout分别显示TitleView和ContentView，也就是我们的标题和内容。看到这里我们也就知道，一个Activity包含一个Window对象，而Window是由PhoneWindow来实现的。PhoneWindow将DecorView作为整个应用窗口的根View，而这个DecorView又分为两个区域，分别就是TitleView和ContentView，平常所显示的布局就是在ContentView中。

View的整体绘制流程路口

上一节讲了Activity的构成，最后讲到了DecorView的创建和加载它的资源，但是这个时候DecorView的内容还无法显示，因为还没用加载到Window中，接下来我们看它是怎么被加载到Window中。

还是老样子，DecorView创建完毕的时并且要加载到Window中，我们还是要先了解Activity的创建流程，当我们使用Activit的startActivity()方法时，最终就是调用ActivityThread的handleLaunchActivity方法来创建Activity。而绘制会从根视图ViewRootImpl的performTraversals()方法开始从上到下遍历整个视图树，每个 View 控制负责绘制自己，而ViewGroup还需要负责通知自己的子 View进行绘制操作。视图操作的过程可以分为三个步骤，分别是测量(Measure)、布局(Layout)和绘制(Draw)。

ViewRootImpl是WindowManager和DecorView的纽带，View的三大流程均是通过这里来完成的，在ActivityThread中，当Activity对象被创建，会将DecorView加入到Window中，同时创建ViewRootImpl对象，并将ViewRootImpl对象和DecorView建立关联。

刚刚也说过了，View的绘制流程是从ViewRootImpl类的performTraversals()方法开始的，它会依次调用performMeasure()、performLayout()和performDraw()三个方法。其中在performTraversals()调用measure()方法，在measure()方法又会调用onMeasure()方法，在onMeasure()方法中则会对所有的子元素进行measure过程，这个时候measure流程就从父容器传递到子元素中了，这样就完成了依次measure过程，接着子元素会重复父容器的measure过程，如此返回完成了整个View数的遍历。

理解MeasureSpec

为了理解View的测量过程，我们还需理解MeasureSpec，它在很大程度上决定了一个View的尺寸规格，而且也参与到了View的measure过程中。在测量过程中，系统会将View的LayoutParams根据父容器所施加的规则转换成对应的MeasureSpec，然后在根据这个measureSpec来测量出View的宽和高。

MeasureSpec是View的内部类，它代表哦啦一个32位的int值，高2位代表SpecMode，低30位代表SpecSize，SpecMode是指测量模式，而SpecSize是指在某种测量模式下的规格大小，如以下代码所示：

public static class MeasureSpec {    private static final int MODE_SHIFT = 30;

    private static final int MODE_MASK  = 0x3 << MODE_SHIFT;



    ......

    

    public static final int UNSPECIFIED = 0 << MODE_SHIFT;



    public static final int EXACTLY     = 1 << MODE_SHIFT;

    

    public static final int AT_MOST     = 2 << MODE_SHIFT;

    

    public static int makeMeasureSpec(@IntRange(from = 0, to = (1 << MeasureSpec.MODE_SHIFT) - 1) int size,

                                      @MeasureSpecMode int mode) {

        if (sUseBrokenMakeMeasureSpec) {

            return size + mode;

        } else {

            return (size & ~MODE_MASK) | (mode & MODE_MASK);

        }

    }



    public static int makeSafeMeasureSpec(int size, int mode) {

        if (sUseZeroUnspecifiedMeasureSpec && mode == UNSPECIFIED) {

            return 0;

        }

        return makeMeasureSpec(size, mode);

    }



    

    @MeasureSpecMode

    public static int getMode(int measureSpec) {

        //noinspection ResourceType

        return (measureSpec & MODE_MASK);

    }



    

    public static int getSize(int measureSpec) {

        return (measureSpec & ~MODE_MASK);

    }



    static int adjust(int measureSpec, int delta) {

        final int mode = getMode(measureSpec);

        int size = getSize(measureSpec);

        if (mode == UNSPECIFIED) {

            // No need to adjust size for UNSPECIFIED mode.

            return makeMeasureSpec(size, UNSPECIFIED);

        }

        size += delta;

        if (size < 0) {

            Log.e(VIEW_LOG_TAG, "MeasureSpec.adjust: new size would be negative! (" + size +

                    ") spec: " + toString(measureSpec) + " delta: " + delta);

            size = 0;

        }

        return makeMeasureSpec(size, mode);

    }



    

    ......

}

MeasureSpec通过SpecMode和SpecSize打包成一个int值来避免过多的对象内存分配，为了方便操作，其提供了打包和解包方法。SpecMode和SpecSize也是一个int值，一组SpecMode和SpecSize可以打包成一个MeasureSpec，而也可以通过解包得到SpecMode和SpecSize。这里说一下打包成的MeasureSpec是一个int值，不是这个类本身。

对于SpecMode，有三种类型：

• UPSPECIFIED：父容器不对View有任何限制，要多大给多大，这种情况一般用于系统内部，表示一种测量状态。




• EXACTLY：父容器已经检测出View所需要的精确大小，这个时候View的最终大小就是SpecSize所指定的值。它对应于LayoutParams中的match_parent和具体的数值这两种模式。




• AT_MOST：父容器指定一个可用大小即SpecSize，View的大小不能大于这个值，具体是什么值要看不同View的具体实现。它对应于LayoutParams中的wrap_content。
  

前言

在编程中经常会使用线程来异步处理任务，但是每个线程的创建和销毁都需要一定的开销。如果每次执行一个任务都需要一个新进程去执行，则这些线程的创建和销毁将消耗大量的资源；并且线程都是“各自为政”的，很难对其进行控制，更何况有一堆的线程在执行。这时候就需要线程池来对线程进行管理。在Java 1.5中提供了Executor框架用于把任务的提交和执行解耦。任务的提交交给RUnnable或者Callable，而Executor框架用来处理任务。Executor框架中最核心的成员就是ThreadPoolExecutor，它是线程池的核心实现类。本篇文章就着重讲解ThreadPoolExecutor。

dependencies {

    implementation 'com.github.gzu-liyujiang.AndroidPicker:WheelPicker:版本号'

}

dependencies {

    implementation 'com.github.gzu-liyujiang.AndroidPicker:FilePicker:版本号'

}

dependencies {

    implementation 'com.github.gzu-liyujiang.AndroidPicker:ColorPicker:版本号'

}

dependencies {

    implementation 'com.github.gzu-liyujiang.AndroidPicker:WheelPicker:1.5.6.20181018'

}

dependencies {

    implementation 'com.github.gzu-liyujiang.AndroidPicker:Common:2.0.0'

    implementation 'com.github.gzu-liyujiang.AndroidPicker:WheelPicker:2.0.0'

}

picker.setXXX(...);

picker.setOffset(...);

picker.setCycleDisable(false);

picker.setLineSpaceMultiplier(...);

picker.setItemHeight(...);

picker.setTextColor(...);

picker.setTextSize(...);

picker.setTextPadding(...);

picker.setTextSizeAutoFit(...);

picker.setTypeface(...);

picker.setLabel(...);

picker.setOnlyShowCenterLabel(...))

picker.setSelectedItem(...);

picker.setSelectedIndex(...);

picker.setUseWeight(true);

picker.setDividerRatio(WheelView.DividerConfig.FILL);

picker.setCanceledOnTouchOutside(...);

picker.setDividerConfig(...);

picker.setDividerColor(...);

picker.setDividerRatio(...);

picker.setDividerVisible(...);

picker.setContentPadding(...);

picker.setShadowColor(...)

picker.setHeaderView(...);

picker.setFooterView(...);

picker.getContentView();

picker.getCancelButton();

picker.getSubmitButton();

        CustomHeaderAndFooterPicker picker = new CustomHeaderAndFooterPicker(this);

        picker.setOnOptionPickListener(new OptionPicker.OnOptionPickListener() {

            @Override

            public void onOptionPicked(int position, String option) {

                showToast(option);

            }

        });

        picker.show();

如何使用：

Android-PickerView 库使用示例：

1.添加Jcenter仓库 Gradle依赖：

compile 'com.contrarywind:Android-PickerView:4.1.9'

或者

Maven

com.contrarywind
Android-PickerView
4.1.9
pom

2.在项目中添加如下代码：

//时间选择器
TimePickerView pvTime = new TimePickerBuilder(MainActivity.this, new OnTimeSelectListener() {
                           @Override
                           public void onTimeSelect(Date date, View v) {
                               Toast.makeText(MainActivity.this, getTime(date), Toast.LENGTH_SHORT).show();
                           }
                       }).build();

//条件选择器
 OptionsPickerView pvOptions = new OptionsPickerBuilder(MainActivity.this, new OnOptionsSelectListener() {
            @Override
            public void onOptionsSelect(int options1, int option2, int options3 ,View v) {
                //返回的分别是三个级别的选中位置
                String tx = options1Items.get(options1).getPickerViewText()
                        + options2Items.get(options1).get(option2)
                        + options3Items.get(options1).get(option2).get(options3).getPickerViewText();
                tvOptions.setText(tx);
            }
        }).build();
 pvOptions.setPicker(options1Items, options2Items, options3Items);
 pvOptions.show();

大功告成~

3.如果默认样式不符合你的口味，可以自定义各种属性：

Calendar selectedDate = Calendar.getInstance();
 Calendar startDate = Calendar.getInstance();
 //startDate.set(2013,1,1);
 Calendar endDate = Calendar.getInstance();
 //endDate.set(2020,1,1);
 
  //正确设置方式 原因：注意事项有说明
  startDate.set(2013,0,1);
  endDate.set(2020,11,31);

 pvTime = new TimePickerBuilder(this, new OnTimeSelectListener() {
            @Override
            public void onTimeSelect(Date date,View v) {//选中事件回调
                tvTime.setText(getTime(date));
            }
        })
                .setType(new boolean[]{true, true, true, true, true, true})// 默认全部显示
                .setCancelText("Cancel")//取消按钮文字
                .setSubmitText("Sure")//确认按钮文字
                .setContentSize(18)//滚轮文字大小
                .setTitleSize(20)//标题文字大小
                .setTitleText("Title")//标题文字
                .setOutSideCancelable(false)//点击屏幕，点在控件外部范围时，是否取消显示
                .isCyclic(true)//是否循环滚动
                .setTitleColor(Color.BLACK)//标题文字颜色
                .setSubmitColor(Color.BLUE)//确定按钮文字颜色
                .setCancelColor(Color.BLUE)//取消按钮文字颜色
                .setTitleBgColor(0xFF666666)//标题背景颜色 Night mode
                .setBgColor(0xFF333333)//滚轮背景颜色 Night mode
                .setDate(selectedDate)// 如果不设置的话，默认是系统时间*/
                .setRangDate(startDate,endDate)//起始终止年月日设定
                .setLabel("年","月","日","时","分","秒")//默认设置为年月日时分秒
                .isCenterLabel(false) //是否只显示中间选中项的label文字，false则每项item全部都带有label。
                .isDialog(true)//是否显示为对话框样式
                .build();
pvOptions = new  OptionsPickerBuilder(this, new OptionsPickerView.OnOptionsSelectListener() {
            @Override
            public void onOptionsSelect(int options1, int option2, int options3 ,View v) {
                //返回的分别是三个级别的选中位置
                String tx = options1Items.get(options1).getPickerViewText()
                        + options2Items.get(options1).get(option2)
                        + options3Items.get(options1).get(option2).get(options3).getPickerViewText();
                tvOptions.setText(tx);
            }
        }) .setOptionsSelectChangeListener(new OnOptionsSelectChangeListener() {
                              @Override
                              public void onOptionsSelectChanged(int options1, int options2, int options3) {
                                  String str = "options1: " + options1 + "\noptions2: " + options2 + "\noptions3: " + options3;
                                  Toast.makeText(MainActivity.this, str, Toast.LENGTH_SHORT).show();
                              }
                          })
                .setSubmitText("确定")//确定按钮文字
                .setCancelText("取消")//取消按钮文字
                .setTitleText("城市选择")//标题
                .setSubCalSize(18)//确定和取消文字大小
                .setTitleSize(20)//标题文字大小
                .setTitleColor(Color.BLACK)//标题文字颜色
                .setSubmitColor(Color.BLUE)//确定按钮文字颜色
                .setCancelColor(Color.BLUE)//取消按钮文字颜色
                .setTitleBgColor(0xFF333333)//标题背景颜色 Night mode
                .setBgColor(0xFF000000)//滚轮背景颜色 Night mode
                .setContentTextSize(18)//滚轮文字大小
                .setLinkage(false)//设置是否联动，默认true
                .setLabels("省", "市", "区")//设置选择的三级单位
                .isCenterLabel(false) //是否只显示中间选中项的label文字，false则每项item全部都带有label。
                .setCyclic(false, false, false)//循环与否
                .setSelectOptions(1, 1, 1)  //设置默认选中项
                .setOutSideCancelable(false)//点击外部dismiss default true
                .isDialog(true)//是否显示为对话框样式
                .isRestoreItem(true)//切换时是否还原，设置默认选中第一项。
                .build();

        pvOptions.setPicker(options1Items, options2Items, options3Items);//添加数据源

4.如果需要自定义布局：

// 注意：自定义布局中，id为 optionspicker 或者 timepicker 的布局以及其子控件必须要有，否则会报空指针
        // 具体可参考demo 里面的两个自定义布局
        pvCustomOptions = new OptionsPickerBuilder(this, new OptionsPickerView.OnOptionsSelectListener() {
            @Override
            public void onOptionsSelect(int options1, int option2, int options3, View v) {
                //返回的分别是三个级别的选中位置
                String tx = cardItem.get(options1).getPickerViewText();
                btn_CustomOptions.setText(tx);
            }
        })
                .setLayoutRes(R.layout.pickerview_custom_options, new CustomListener() {
                    @Override
                    public void customLayout(View v) {
                        //自定义布局中的控件初始化及事件处理
                        final TextView tvSubmit = (TextView) v.findViewById(R.id.tv_finish);
                        final TextView tvAdd = (TextView) v.findViewById(R.id.tv_add);
                        ImageView ivCancel = (ImageView) v.findViewById(R.id.iv_cancel);
                        tvSubmit.setOnClickListener(new View.OnClickListener() {
                            @Override
                            public void onClick(View v) {
                                pvCustomOptions.returnData(tvSubmit);
                            }
                        });
                        ivCancel.setOnClickListener(new View.OnClickListener() {
                            @Override
                            public void onClick(View v) {
                                pvCustomOptions.dismiss();
                            }
                        });

                        tvAdd.setOnClickListener(new View.OnClickListener() {
                            @Override
                            public void onClick(View v) {
                                getData();
                                pvCustomOptions.setPicker(cardItem);
                            }
                        });

                    }
                })
                .build();
        pvCustomOptions.setPicker(cardItem);//添加数据

5.对使用还有疑问的话，可参考demo代码

请戳我查看demo代码

6.若只需要WheelView基础控件自行扩展实现逻辑，可直接添加基础控件库，Gradle 依赖：

compile 'com.contrarywind:wheelview:4.1.0'

WheelView 使用代码示例：

xml布局：

            android:id="@+id/wheelview"
            android:layout_width="match_parent"
            android:layout_height="wrap_content" />

Java 代码：

WheelView wheelView = findViewById(R.id.wheelview);

        wheelView.setCyclic(false);

        final List mOptionsItems = new ArrayList<>();
        mOptionsItems.add("item0");
        mOptionsItems.add("item1");
        mOptionsItems.add("item2");
  
        wheelView.setAdapter(new ArrayWheelAdapter(mOptionsItems));
        wheelView.setOnItemSelectedListener(new OnItemSelectedListener() {
            @Override
            public void onItemSelected(int index) {
                Toast.makeText(MainActivity.this, "" + mOptionsItems.get(index), Toast.LENGTH_SHORT).show();
            }
        });

前言

我在前面两篇文章中详细介绍了 今日头条适配方案 和 SmallestWidth 限定符适配方案 的原理，并验证了它们的可行性，以及总结了它们各自的优缺点，可以说这两个方案都是目前比较优秀、比较主流的 Android 屏幕适配方案，而且它们都已经拥有了一定的用户基数

但是对于一些才接触这两个方案的朋友，肯定或多或少还是不知道如何选择这两个方案，我虽然在之前的文章中给出了它们各自的优缺点，但是并没有用统一的标准对它们进行更细致的对比，所以也就没办法更形象的体现它们的优劣，那下面我就用统一的标准对它们进行对比，看看它们的对比情况

方案对比

我始终坚定地认为在这两个方案中，并不能以单个标准就能评判出谁一定比谁好，因为它们都有各自的优缺点，都不是完美的，从更客观的角度来看，它们谁都不能成为最好的那个，只有可能明确了它们各自的优缺点，知道在它们的优缺点里什么是我能接受的，什么是我不能接受的，是否能为了某些优点做出某些妥协，从而选择出一个最适合自己项目的屏幕适配方案

单纯的争论谁是最好的 Android 屏幕适配方案没有任何意义，每个人的需求不一样，站的角度不一样，评判标准也不一样，你能接受的东西他不一定能接受，你觉得不可接受的东西他却觉得可以接受，你有你的理由，他有他的理由，想让一个观点让所有人都能接受太难了！所以我在这里只是列出它们的对比项和对比结果，尽可能的做到客观，最后的选择结果请自行决定，如果还有什么遗漏的对比项，请补充！

可以看到 SmallestWidth 限定符适配方案 和 今日头条适配方案 的适配效果其实都是差不多的，我在前面的文章中也通过公式计算过它们的精确度，SmallestWidth 限定符适配方案 运行在未覆盖的机型上虽然也可以适配，但是却会出现一定的误差，所以 今日头条适配方案 的适配精确度确实要比 SmallestWidth 限定符适配方案 略高的，不过只要 SmallestWidth 限定符适配方案 合理的分配资源文件，适配效果的差距应该也不大

SmallestWidth 限定符适配方案 主打的是稳定性，在运行过程中极少会出现安全隐患，适配范围也可控，不会产生其他未知的影响，而 今日头条适配方案 主打的是降低开发成本、提高开发效率，使用上更灵活，也能满足更多的扩展需求，简单一句话概括就是，这两兄弟，一个求稳，一个求快，好了，我就介绍这么多了，自己选择吧！

由来

下面就开始介绍我根据 今日头条屏幕适配方案 优化的屏幕适配框架 AndroidAutoSize，大家千万不要认为，我推出的屏幕适配框架 AndroidAutoSize 是根据 今日头条屏幕适配方案 优化的，我本人就一定支持 今日头条屏幕适配方案 是最好的 Android 屏幕适配方案这个观点，它确实很优秀，但同样也有很多不足，我最真实的观点在上面就已经表述咯，至于我为什么要根据 今日头条屏幕适配方案 再封装一个屏幕适配框架，无外乎就以下几点原因:

• SmallestWidth 限定符适配方案 已经有多个优秀的开源解决方案了，它们已经能满足我们日常开发中的所有需求




• 今日头条 官方技术团队只公布了 今日头条屏幕适配方案 的 文章 以及核心代码，但并没有在 Github 上创建公开的仓库，一个新的方案必定要有一个成长迭代的过程，在此期间，一定需要一个可以把所有使用者聚集起来的公共社区，可以让所有使用该方案的使用者在上面交流，大家一起总结、一起填坑，这样才能让该方案更成熟稳定，这就是开源的力量




• 今日头条 官方技术团队公布的核心代码并不能满足我的所有需求，已经开源的其他基于 今日头条屏幕适配方案 的开源项目以及解决方案也不能满足我的所有需求，而我有更好的实现想法




• MVPArms 需要一个适配效果还不错并且切换维护成本也比较低的屏幕适配框架，以帮助使用者用较低的成本、工作量将已经停止维护的 AndroidAutoLayout 快速替换掉

我建议大家都可以去实际体验一下 今日头条屏幕适配方案 和 SmallestWidth 限定符适配方案，感受下它们的异同，我给的建议是，可以在项目中先使用 今日头条屏幕适配方案，感受下它的使用方式以及适配效果，今日头条屏幕适配方案 的侵入性非常低，如果在使用过程中遇到什么不能解决的问题，马上可以切换为其他的屏幕适配方案，在切换的过程中也花费不了多少工作量，试错成本非常低

但如果你在项目中先使用 SmallestWidth 限定符适配方案，之后在使用的过程中再遇到什么不能解决的问题，这时想切换为其他的屏幕适配方案，这工作量可就大了，每个 Layout 文件都含有大量的 dimens 引用，改起来这工作量得有多大，想想都觉得后怕，这就是侵入性太高导致的最致命的问题

与今日头条屏幕适配方案的关系

AndroidAutoSize 与 今日头条屏幕适配方案 的关系，相当于汽车和发动机的关系，今日头条屏幕适配方案 官方公布的代码，只实现了修改系统 density 的相关逻辑，这的确在屏幕适配中起到了最关键的作用，但这还远远还不够

要想让使用者能够更傻瓜式的使用该方案，并且能够应对日常开发中的所有复杂需求，那在架构框架时，还需要考虑 API 的易用性以及合理性、框架的扩展性以及灵活性、功能的全面性、注释和文档的易读性等多个方面的问题

于是我带着我的这些标准在网上搜寻了很久，发现并没有任何一个开源框架或解决方案能够达到我的所有标准，它们大多数还只是停留在将 今日头条屏幕适配方案 封装成工具类来引入项目的阶段，这样在功能的扩展上有限制，并且对用户的使用体验也不好，而我想做的是一个全面性的产品级屏幕适配框架，这离我最初的构想，差距还非常大，于是我只好自己动手，将我的所有思想实现，这才有了 AndroidAutoSize

写完 AndroidAutoSize 框架后，因为对 今日头条屏幕适配方案 有了更加深入的理解，所以才写了 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案，以帮助大家更清晰的理解 今日头条屏幕适配方案

与 AndroidAutoLayout 的关系

AndroidAutoSize 因为名字和 鸿神 的 AndroidAutoLayout 非常相似，并且在填写设计图尺寸的方式上也极为相似，再加上我写的屏幕适配系列的文章也发布在了 鸿神 的公众号上，所以很多人以为 AndroidAutoSize 是 鸿神 写的 AndroidAutoLayout 的升级版，这里我哭笑不得 😂，我只好在这里说一句，大家好，我叫 JessYan，的确可以理解为 AndroidAutoSize 是 AndroidAutoLayout 的升级版，但是它是我写的，关注一波呗

但 AndroidAutoSize 和 AndroidAutoLayout 的原理，却天差地别，比如 AndroidAutoLayout 只能使用 px 作为布局单位，而 AndroidAutoSize 恰好相反，在布局中 dp、sp、pt、in、mm 所有的单位都能支持，唯独不支持 px，但这也意味着 AndroidAutoSize 和 AndroidAutoLayout 在项目中可以共存，互不影响，所以使用 AndroidAutoLayout 的老项目也可以放心的引入 AndroidAutoSize，慢慢的完成屏幕适配框架的切换

之所以将框架取名为 AndroidAutoSize，第一，是想致敬 AndroidAutoLayout 对 Android 屏幕适配领域的贡献，第二，也想成为在 Android 屏幕适配领域有重要影响力的框架

结构

我在上面就已经说了很多开源框架以及解决方案，只是把 今日头条屏幕适配方案 简单的封装成一个工具类然后引入项目，这时很多人就会说了 今日头条屏幕适配方案 官方公布的全部代码都只有 30 行不到，你不把它封装成工具类，那封装成什么？该怎么封装？下面就来看看 AndroidAutoSize 的整体结构

├── external

│   ├── ExternalAdaptInfo.java

│   ├── ExternalAdaptManager.java

│── internal

│   ├── CancelAdapt.java

│   ├── CustomAdapt.java

│── unit

│   ├── Subunits.java

│   ├── UnitsManager.java

│── utils

│   ├── AutoSizeUtils.java

│   ├── LogUtils.java

│   ├── Preconditions.java

│   ├── ScreenUtils.java

├── ActivityLifecycleCallbacksImpl.java

├── AutoAdaptStrategy.java

├── AutoSize.java

├── AutoSizeConfig.java

├── DefaultAutoAdaptStrategy.java

├── DisplayMetricsInfo.java

├── FragmentLifecycleCallbacksImpl.java

├── InitProvider.java

AndroidAutoSize 根据 今日头条屏幕适配方案 官方公布的 30 行不到的代码，经过不断的优化和扩展，发展成了现在拥有 18 个类文件，上千行代码的全面性屏幕适配框架，在迭代的过程中完善和优化了很多功能，相比 今日头条屏幕适配方案 官方公布的原始代码，AndroidAutoSize 更加稳定、更加易用、更加强大，欢迎阅读源码，注释非常详细哦！

功能介绍

AndroidAutoSize 在使用上非常简单，只需要填写设计图尺寸这一步即可接入项目，但需要注意的是，AndroidAutoSize 有两种类型的布局单位可以选择，一个是 主单位 (dp、sp)，一个是 副单位 (pt、in、mm)，两种单位面向的应用场景都有不同，也都有各自的优缺点

• 主单位: 使用 dp、sp 为单位进行布局，侵入性最低，会影响其他三方库页面、三方库控件以及系统控件的布局效果，但 AndroidAutoSize 也通过这个特性，使用 ExternalAdaptManager 实现了在不修改三方库源码的情况下适配三方库的功能




• 副单位: 使用 pt、in、mm 为单位进行布局，侵入性高，对老项目的支持比较好，不会影响其他三方库页面、三方库控件以及系统控件的布局效果，可以彻底的屏蔽修改 density 所造成的所有未知和已知问题，但这样 AndroidAutoSize 也就无法对三方库进行适配

大家可以根据自己的应用场景在 主单位 和 副单位 中选择一个作为布局单位，建议想引入老项目并且注重稳定性的人群使用 副单位，只是想试试本框架，随时可能切换为其他屏幕适配方案的人群使用 主单位

其实 AndroidAutoSize 可以同时支持 主单位 和 副单位，但 AndroidAutoSize 可以同时支持 主单位 和 副单位 的目的，只是为了让使用者可以在 主单位 和 副单位 之间灵活切换，因为切换单位的工作量可能非常巨大，不能立即完成，但领导又要求马上打包上线，这时就可以起到一个很好的过渡作用

主单位

主单位 的 Demo 在 demo

基本使用

将 AndroidAutoSize 引入项目后，只要在 app 的 AndroidManifest.xml 中填写上设计图尺寸，无需其他过多配置 (如果你没有其他自定义需求的话)，AndroidAutoSize 即可自动运行，像下面这样👇

在使用主单位时，design_width_in_dp 和 design_height_in_dp 的单位必须是 dp，如果设计师给你的设计图，只标注了 px 尺寸 (现在已经有很多 UI 工具可以自动标注 dp 尺寸了)，那请自行根据公式 dp = px / (DPI / 160) 将 px 尺寸转换为 dp 尺寸，如果你不知道 DPI 是多少？那请以自己测试机的 DPI 为准，如果连怎么得到设备的 DPI 都不知道？百度吧好伐，如果你实在找不到设备的 DPI 那就直接将 px 尺寸除以 3 或者 2 也是可以的

如果你只是想使用 AndroidAutoSize 的基础功能，AndroidAutoSize 的使用方法在这里就结束了，只需要上面这一步，即可帮助你以最简单的方式接入 AndroidAutoSize，但是作为一个全面性的屏幕适配框架，在保证基础功能的简易性的同时，也必须保证复杂的需求也能在框架内被解决，从而达到一个小闭环，所以下面介绍的内容全是前人踩坑踩出来的一些必备功能，如果你没这个需求，或者觉得麻烦，可以按需查看或者跳过，下面的内容建议和 Demo 配合起来阅读，效果更佳

注意事项

• 你在 AndroidManifest.xml 中怎么把设计图的 px 尺寸转换为 dp 尺寸，那在布局时，每个控件的大小也需要以同样的方式将设计图上标注的 px 尺寸转换为 dp 尺寸，千万不要在 AndroidManifest.xml 中填写的是 dp 尺寸，却在布局中继续填写设计图上标注的 px 尺寸

• 
  design_width_in_dp 和 design_height_in_dp 虽然都需要填写，但是 AndroidAutoSize 只会将高度和宽度其中的一个作为基准进行适配，一方作为基准，另一方就会变为备用，默认以宽度为基准进行适配，可以通过 AutoSizeConfig#setBaseOnWidth(Boolean) 不停的切换，这意味着最后运行到设备上的布局效果，在高度和宽度中只有一方可以和设计图上一模一样，另外一方会和设计图出现偏差，为什么不像 AndroidAutoLayout 一样，高和宽都以设计图的效果等比例完美呈现呢？这也很简单，你无法保证所有设备的高宽比例都和你设计图上的高宽比例一致，特别是在现在全面屏全面推出的情况下，如果这里不这样做的话，当你的项目运行在与设计图高宽比例不一致的设备上时，布局会出现严重的变形，这个几率非常大，详情请看 这里
  

自动运行是如何做到的？

很多人有疑惑，为什么使用者只需要在 AndroidManifest.xml 中填写一下 meta-data 标签，其他什么都不做，AndroidAutoSize 就能自动运行，并在 App 启动时自动解析 AndroidManifest.xml 中填写的设计图尺寸，这里很多人不敢相信，问我真的只需要填写下设计图尺寸框架就可以正常运行吗？难道使用了什么 黑科技?

其实这里并没有用到什么 黑科技，原理反而非常简单，只需要声明一个 ContentProvider，在它的 onCreate 方法中启动框架即可，在 App 启动时，系统会在 App 的主进程中自动实例化你声明的这个 ContentProvider，并调用它的 onCreate 方法，执行时机比 Application#onCreate 还靠前，可以做一些初始化的工作，get 到了吗？

这里需要注意的是，如果你的项目拥有多进程，系统只会在主进程中实例化一个你声明的 ContentProvider，并不会在其他非主进程中实例化 ContentProvider，如果在当前进程中 ContentProvider 没有被实例化，那 ContentProvider#onCreate 就不会被调用，你的初始化代码在当前进程中也就不会执行，这时就需要在 Application#onCreate 中调用下 ContentProvider#query 执行一下查询操作，这时 ContentProvider 就会在当前进程中实例化 (每个进程中只会保证有一个实例)，所以应用到框架中就是，如果你需要在多个进程中都进行屏幕适配，那就需要在 Application#onCreate 中调用 AutoSize#initCompatMultiProcess 方法

进阶使用

虽然 AndroidAutoSize 不需要其他过多的配置，只需要在 AndroidManifest.xml 中填写下设计图尺寸就能正常运行，但 AndroidAutoSize 还是为大家准备了很多可配置选项，尽最大可能满足大家日常开发中的所有扩展需求

所有的全局配置选项在 Demo 中都有介绍，每个 API 中也都有详细的注释，在这里就不过多介绍了

自定义 Activity

在 AndroidManifest.xml 中填写的设计图尺寸，是整个项目的全局设计图尺寸，但是如果某些 Activity 页面由于某些原因，设计师单独出图，这个页面的设计图尺寸和在 AndroidManifest.xml 中填写的设计图尺寸不一样该怎么办呢？不要急，AndroidAutoSize 已经为你考虑好了，让这个页面的 Activity 实现 CustomAdapt 接口即可实现你的需求，CustomAdapt 接口的第一个方法可以修改当前页面的设计图尺寸，第二个方法可以切换当前页面的适配基准，下面的注释都解释的很清楚

public class CustomAdaptActivity extends AppCompatActivity implements CustomAdapt {



     /**

     * 是否按照宽度进行等比例适配 (为了保证在高宽比不同的屏幕上也能正常适配, 所以只能在宽度和高度之中选择一个作为基准进行适配)

     *

     * @return {@code true} 为按照宽度进行适配, {@code false} 为按照高度进行适配

     */

    @Override

    public boolean isBaseOnWidth() {

        return false;

    }



     /**

     * 这里使用 iPhone 的设计图, iPhone 的设计图尺寸为 750px * 1334px, 高换算成 dp 为 667 (1334px / 2 = 667dp)

     * 


     * 返回设计图上的设计尺寸, 单位 dp

     * {@link #getSizeInDp} 须配合 {@link #isBaseOnWidth()} 使用, 规则如下:

     * 如果 {@link #isBaseOnWidth()} 返回 {@code true}, {@link #getSizeInDp} 则应该返回设计图的总宽度

     * 如果 {@link #isBaseOnWidth()} 返回 {@code false}, {@link #getSizeInDp} 则应该返回设计图的总高度

     * 如果您不需要自定义设计图上的设计尺寸, 想继续使用在 AndroidManifest 中填写的设计图尺寸, {@link #getSizeInDp} 则返回 {@code 0}

     *

     * @return 设计图上的设计尺寸, 单位 dp

     */

    @Override

    public float getSizeInDp() {

        return 667;

    }

}

如果某个 Activity 想放弃适配，让这个 Activity 实现 CancelAdapt 接口即可，比如修改 density 影响到了老项目中的某些 Activity 页面的布局效果，这时就可以让这个 Activity 实现 CancelAdapt 接口

public class CancelAdaptActivity extends AppCompatActivity implements CancelAdapt {



}

自定义 Fragment

Fragment 的自定义方式和 Activity 是一样的，只不过在使用前需要先在 App 初始化时开启对 Fragment 的支持

AutoSizeConfig.getInstance().setCustomFragment(true);

实现 CustomAdapt

public class CustomAdaptFragment extends Fragment implements CustomAdapt {



    @Override

    public boolean isBaseOnWidth() {

        return false;

    }



    @Override

    public float getSizeInDp() {

        return 667;

    }

}

实现 CancelAdapt

public class CancelAdaptFragment extends Fragment implements CancelAdapt {



}

适配三方库页面

在使用主单位时可以使用 ExternalAdaptManager 来实现在不修改三方库源码的情况下，适配三方库的所有页面 (Activity、Fragment)

由于 AndroidAutoSize 要求需要自定义适配参数或取消适配的页面必须实现 CustomAdapt、CancelAdapt，这时问题就来了，三方库是通过远程依赖的，我们无法修改它的源码，这时我们怎么让三方库的页面也能实现自定义适配参数或取消适配呢？别急，这个需求 AndroidAutoSize 也已经为你考虑好了，当然不会让你将三方库下载到本地然后改源码！

• 通过 ExternalAdaptManager#addExternalAdaptInfoOfActivity(Class, ExternalAdaptInfo) 将需要自定义的类和自定义适配参数添加进方法即可替代实现 CustomAdapt 的方式，这里 展示了使用方式，以及详细的注释




• 通过 ExternalAdaptManager#addCancelAdaptOfActivity(Class) 将需要取消适配的类添加进方法即可替代实现 CancelAdapt 的方式，这里 也展示了使用方式，以及详细的注释

需要注意的是 ExternalAdaptManager 的方法虽然可以添加任何类，但是只能支持 Activity、Fragment，并且 ExternalAdaptManager 是支持链式调用的，以便于持续添加多个页面

当然 ExternalAdaptManager 不仅可以对三方库的页面使用，也可以让自己项目中的 Activity、Fragment 不用实现 CustomAdapt、CancelAdapt 即可达到自定义适配参数和取消适配的功能

副单位

前面已经介绍了 副单位 的应用场景，这里就直接介绍 副单位 如何使用，副单位 的 Demo 在 demo-subunits

基本使用

首先和 主单位 一样也需要先在 app 的 AndroidManifest.xml 中填写上设计图尺寸，但和 主单位 不一样的是，当在使用 副单位 时 design_width_in_dp 和 design_height_in_dp 的单位不需要一定是 dp，可以直接填写设计图的 px 尺寸，在布局文件中每个控件的大小也可以直接填写设计图上标注的 px 尺寸，无需再将 px 转换为 dp，这是 副单位的 特性之一，可以帮助大家提高开发效率

由于 AndroidAutoSize 提供了 pt、in、mm 三种类型的 副单位 供使用者选择，所以在使用 副单位 时，还需要在 APP 初始化时，通过 UnitsManager#setSupportSubunits(Subunits) 方法选择一个你喜欢的副单位，然后在布局文件中使用这个副单位进行布局，三种类型的副单位，其实效果都是一样，大家按喜欢的名字选择即可

由于使用副单位是为了彻底屏蔽修改 density 所造成的对三方库页面、三方库控件以及系统控件的布局效果的影响，所以在使用副单位时建议调用 UnitsManager#setSupportDP(false) 和 UnitsManager#setSupportSP(false)，关闭 AndroidAutoSize 对 dp 和 sp 的支持，AndroidAutoSize 为什么不在使用 副单位 时默认关闭对 dp、sp 的支持？因为允许同时支持 主单位 和 副单位 可以帮助使用者在 主单位 和 副单位 之间切换时更好的过渡，这点在前面就已经提到过

UnitsManager 的详细使用方法，在 demo-subunits 中都有展示，注释也十分详细

自定义 Activity 和 Fragment

在使用 副单位 时自定义 Activity 和 Fragment 的方式是和 主单位 是一样的，这里就不再过多介绍了

适配三方库页面

如果你的项目在使用 副单位 并且关闭了对 主单位 (dp、sp) 的支持，这时 ExternalAdaptManager 对三方库的页面是不起作用的，只对自己项目中的页面起作用，除非三方库的页面也使用了副单位 (pt、in、mm) 进行布局

其实 副单位 之所以能彻底屏蔽修改 density 所造成的对三方库页面、三方库控件以及系统控件的布局效果的影响，就是因为三方库页面、三方库控件以及系统控件基本上使用的都是 dp、sp 进行布局，所以只要 AndroidAutoSize 关闭了对 dp、sp 的支持，转而使用 副单位 进行布局，就能彻底屏蔽修改 density 所造成的对三方库页面、三方库控件以及系统控件的布局效果的影响

但这也同样意味着使用 副单位 就不能适配三方库的页面了，ExternalAdaptManager 也就对三方库的页面不起作用了

布局实时预览

在开发阶段布局时的实时预览是一个很重要的环节，很多情况下 Android Studio 提供的默认预览设备并不能完全展示我们的设计图，所以我们就需要自己创建模拟设备，dp、pt、in、mm 这四种单位的模拟设备创建方法请看 这里

总结

AndroidAutoSize 在经历了 240+ commit、60+ issues、6 个版本 的洗礼后，逐渐的稳定了下来，已经在上个星期发布了首个正式版，在这里要感谢将 AndroidAutoSize 接入到自己项目中的上千个使用者，感谢他们的信赖，AndroidAutoSize 创建的初衷就是为了让所有使用 今日头条屏幕适配方案 的使用者能有一个可以一起交流、沟通的聚集地，所以后面也会持续的收集并解决 今日头条屏幕适配方案的常见问题，让 今日头条屏幕适配方案 变得更加成熟、稳定

至此本系列的第三篇文章也就完结了，这也预示着这个系列连载的终结，这篇文章建议结合系列的第一篇文章 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案 一起看，这样可以对 今日头条屏幕适配方案 有一个更深入的理解，如果你能将整个系列的文章都全部认真看完，那你对 Android 屏幕适配领域的相关知识绝对会有一个飞速的提升!

当你的项目需要切换某个框架时，你会怎么去考察、分析、对比现有的开源方案，并有足够的理由去选择或优化一个最适合自己项目的方案呢？其实整个系列文章可以看作是我怎么去选择同类型开源方案的过程，你以后当遇到同样的选择也可以参照我的思维方式去处理，当然如果以后面试官问到你屏幕适配相关的问题，你能将我如何选择、分析、对比已有方案的过程以及文章中的核心知识点告诉给面试官，那肯定比你直接说一句我使用的是某某开源库有价值得多

前言

ok，根据上一篇文章 骚年你的屏幕适配方式该升级了!-今日头条适配方案 的承诺，本文是这个系列的第二篇文章，这篇文章会详细讲解 smallestWidth 限定符屏幕适配方案

了解我的朋友一定知道，MVPArms 一直使用的是 鸿神 的 AndroidAutoLayout 屏幕适配方案，得益于 AndroidAutoLayout 的便捷，所以我对屏幕适配领域研究的不是很多，AndroidAutoLayout 停止维护后，我也一直在找寻着替代方案，直到 今日头条屏幕适配方案 刷屏，后来又无意间看到了 smallestWidth 限定符屏幕适配方案，这才慢慢的将研究方向转向了屏幕适配领域

最近一个月才开始慢慢恶补 Android 屏幕适配的相关知识，对这两个方案也进行了更深入的研究，可以说从一个小白慢慢成长而来，所以我明白小白的痛，因此在上一篇文章 骚年你的屏幕适配方式该升级了!-今日头条适配方案 中，把 今日头条屏幕适配方案 讲得非常的细，尽量把每一个知识点都描述清晰，深怕小白漏掉每一个细节，这篇文章我也会延续上一篇文章的优良传统，将 smallestWidth 限定符屏幕适配方案 的每一个知识点都描述清晰

顺便说一句，感谢大家对 AndroidAutoSize 的支持，我只是在上一篇文章中提了一嘴我刚发布的屏幕适配框架 AndroidAutoSize，还没给出详细的介绍和原理剖析 (原计划在本系列的第三篇文章中发布)，AndroidAutoSize 就被大家推上了 Github Trending，一个多星期就拿了 2k+ stars，随着关注度的增加，我在这段时间里也累坏了，issues 就没断过，不到半个月就提交了 200 多次 commit，但累并快乐着，在这里要再次感谢大家对 AndroidAutoSize 的认可

大家要注意了！这些观点其实针对的是所有以百分比缩放布局的库，而不只是今日头条屏幕适配方案，所以这些观点也同样适用于 smallestWidth 限定符屏幕适配方案，这点有很多人存在误解，所以一定要注意！

Android 的 系统碎片化、机型以及屏幕尺寸碎片化、屏幕分辨率碎片化 有多严重大家可以通过 友盟指数 了解一下，有些时候在某些事情的决断标准上，并不能按照事情的对错来决断，大多数情况还是要分析成本，收益等多种因素，通过利弊来决断，每个人的利弊标准又都不一样，所以每个人的观点也都会有差别，但也都应该得到尊重，所以我只是说说自己的观点，也不否认任何人的观点

方案是死的人是活的，在某些大屏手机或平板电脑上，您也可以采用其他适配方案和百分比库结合使用，比如针对某个屏幕区间的设备单独出一套设计图以显示比小屏幕手机更多更精细的内容，来达到与百分比库互补的效果，没有一个方案可以说自己是完美的，但我们能清晰的认识到不同方案的优缺点，将它们的优点相结合，才能应付更复杂的开发需求，产出最好的产品

友情提示: 下面要介绍的 smallestWidth 限定符屏幕适配方案，原理也同样是按照百分比缩放布局，理论上也会存在上面所说的 大屏手机和小屏手机显示的内容相同 的问题，选择与否请仔细斟酌

简介 smallestWidth 限定符适配方案

这个方案的的使用方式和我们平时在布局中引用 dimens 无异，核心点在于生成 dimens.xml 文件，但是已经有大神帮我们做了这 一步

├── src/main

│   ├── res

│   ├── ├──values

│   ├── ├──values-800x480

│   ├── ├──values-860x540

│   ├── ├──values-1024x600

│   ├── ├──values-1024x768

│   ├── ├──...

│   ├── ├──values-2560x1440

如果有人还记得上面这种 宽高限定符屏幕适配方案 的话，就可以把 smallestWidth 限定符屏幕适配方案 当成这种方案的升级版，smallestWidth 限定符屏幕适配方案 只是把 dimens.xml 文件中的值从 px 换成了 dp，原理和使用方式都是没变的，这些在上面的文章中都有介绍，下面就直接开始剖析原理，smallestWidth 限定符屏幕适配方案 长这样👇

├── src/main

│   ├── res

│   ├── ├──values

│   ├── ├──values-sw320dp

│   ├── ├──values-sw360dp

│   ├── ├──values-sw400dp

│   ├── ├──values-sw411dp

│   ├── ├──values-sw480dp

│   ├── ├──...

│   ├── ├──values-sw600dp

│   ├── ├──values-sw640dp

原理

其实 smallestWidth 限定符屏幕适配方案 的原理也很简单，开发者先在项目中根据主流屏幕的 最小宽度 (smallestWidth) 生成一系列 values-swdp 文件夹 (含有 dimens.xml 文件)，当把项目运行到设备上时，系统会根据当前设备屏幕的 最小宽度 (smallestWidth) 去匹配对应的 values-swdp 文件夹，而对应的 values-swdp 文件夹中的 dimens.xml 文字中的值，又是根据当前设备屏幕的 最小宽度 (smallestWidth) 而定制的，所以一定能适配当前设备

如果系统根据当前设备屏幕的 最小宽度 (smallestWidth) 没找到对应的 values-swdp 文件夹，则会去寻找与之 最小宽度 (smallestWidth) 相近的 values-swdp 文件夹，系统只会寻找小于或等于当前设备 最小宽度 (smallestWidth) 的 values-swdp，这就是优于 宽高限定符屏幕适配方案 的容错率，并且也可以少生成很多 values-swdp 文件夹，减轻 App 的体积

什么是 smallestWidth

smallestWidth 翻译为中文的意思就是 最小宽度，那这个 最小宽度 是什么意思呢？

系统会根据当前设备屏幕的 最小宽度 来匹配 values-swdp，为什么不是根据 宽度 来匹配，而要加上 最小 这两个字呢？

这就要说到，移动设备都是允许屏幕可以旋转的，当屏幕旋转时，屏幕的高宽就会互换，加上 最小 这两个字，是因为这个方案是不区分屏幕方向的，它只会把屏幕的高度和宽度中值最小的一方认为是 最小宽度，这个 最小宽度 是根据屏幕来定的，是固定不变的，意思是不管您怎么旋转屏幕，只要这个屏幕的高度大于宽度，那系统就只会认定宽度的值为 最小宽度，反之如果屏幕的宽度大于高度，那系统就会认定屏幕的高度的值为 最小宽度

如果想让屏幕宽度随着屏幕的旋转而做出改变该怎么办呢？可以再根据 values-wdp (去掉 sw 中的 s) 生成一套资源文件

如果想区分屏幕的方向来做适配该怎么办呢？那就只有再根据 屏幕方向限定符 生成一套资源文件咯，后缀加上 -land 或 -port 即可，像这样，values-sw400dp-land (最小宽度 400 dp 横向)，values-sw400dp-port (最小宽度 400 dp 纵向)

smallestWidth 的值是怎么算的

要先算出当前设备的 smallestWidth 值我们才能知道当前设备该匹配哪个 values-swdp 文件夹

ok，还是按照上一篇文章的叙述方式，现在来举栗说明，帮助大家更好理解

我们假设设备的屏幕信息是 1920 * 1080、480 dpi

根据上面的规则我们要在屏幕的高度和宽度中选择值最小的一方作为最小宽度，1080 < 1920，明显 1080 px 就是我们要找的 最小宽度 的值，但 最小宽度 的单位是 dp，所以我们要把 px 转换为 dp

帮助大家再巩固下基础，下面的公式一定不能再忘了！

px / density = dp，DPI / 160 = density，所以最终的公式是 px / (DPI / 160) = dp

所以我们得到的 最小宽度 的值是 360 dp (1080 / (480 / 160) = 360)

现在我们已经算出了当前设备的最小宽度是 360 dp，我们晓得系统会根据这个 最小宽度 帮助我们匹配到 values-sw360dp 文件夹下的 dimens.xml 文件，如果项目中没有 values-sw360dp 这个文件夹，系统才会去匹配相近的 values-swdp 文件夹

dimens.xml 文件是整个方案的核心所在，所以接下来我们再来看看 values-sw360dp 文件夹中的这个 dimens.xml 是根据什么原理生成的

dimens.xml 生成原理

因为我们在项目布局中引用的 dimens 的实际值，来源于根据当前设备屏幕的 最小宽度 所匹配的 values-swdp 文件夹中的 dimens.xml，所以搞清楚 dimens.xml 的生成原理，有助于我们理解 smallestWidth 限定符屏幕适配方案

说到 dimens.xml 的生成，就要涉及到两个因数，第一个因素是 最小宽度基准值，第二个因素就是您的项目需要适配哪些 最小宽度，通俗理解就是需要生成多少个 values-swdp 文件夹

第一个因素

最小宽度基准值 是什么意思呢？简单理解就是您需要把设备的屏幕宽度分为多少份，假设我们现在把项目的 最小宽度基准值 定为 360，那这个方案就会理解为您想把所有设备的屏幕宽度都分为 360 份，方案会帮您在 dimens.xml 文件中生成 1 到 360 的 dimens 引用，比如 values-sw360dp 中的 dimens.xml 是长这样的

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1dp</dimen>
    <dimen name="dp_2">2dp</dimen>
    <dimen name="dp_3">3dp</dimen>
    <dimen name="dp_4">4dp</dimen>
    <dimen name="dp_5">5dp</dimen>
    <dimen name="dp_6">6dp</dimen>
    <dimen name="dp_7">7dp</dimen>
    <dimen name="dp_8">8dp</dimen>
    <dimen name="dp_9">9dp</dimen>
    <dimen name="dp_10">10dp</dimen>
    ...
    <dimen name="dp_356">356dp</dimen>
    <dimen name="dp_357">357dp</dimen>
    <dimen name="dp_358">358dp</dimen>
    <dimen name="dp_359">359dp</dimen>
    <dimen name="dp_360">360dp</dimen>
</resources>

values-sw360dp 指的是当前设备屏幕的 最小宽度 为 360dp (该设备高度大于宽度，则最小宽度就是宽度，所以该设备宽度为 360dp)，把屏幕宽度分为 360 份，刚好每份等于 1dp，所以每个引用都递增 1dp，值最大的 dimens 引用 dp_360 值也是 360dp，刚好覆盖屏幕宽度

下面再来看看将 最小宽度基准值 定为 360 时，values-sw400dp 中的 dimens.xml 长什么样

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1.1111dp</dimen>
    <dimen name="dp_2">2.2222dp</dimen>
    <dimen name="dp_3">3.3333dp</dimen>
    <dimen name="dp_4">4.4444dp</dimen>
    <dimen name="dp_5">5.5556dp</dimen>
    <dimen name="dp_6">6.6667dp</dimen>
    <dimen name="dp_7">7.7778dp</dimen>
    <dimen name="dp_8">8.8889dp</dimen>
    <dimen name="dp_9">10.0000dp</dimen>
    <dimen name="dp_10">11.1111dp</dimen>
    ...
    <dimen name="dp_355">394.4444dp</dimen>
    <dimen name="dp_356">395.5556dp</dimen>
    <dimen name="dp_357">396.6667dp</dimen>
    <dimen name="dp_358">397.7778dp</dimen>
    <dimen name="dp_359">398.8889dp</dimen>
    <dimen name="dp_360">400.0000dp</dimen>
</resources>

values-sw400dp 指的是当前设备屏幕的 最小宽度 为 400dp (该设备高度大于宽度，则最小宽度就是宽度，所以该设备宽度为 400dp)，把屏幕宽度同样分为 360份，这时每份就等于 1.1111dp 了，每个引用都递增 1.1111dp，值最大的 dimens 引用 dp_360 同样刚好覆盖屏幕宽度，为 400dp

通过两个 dimens.xml 文件的比较，dimens.xml 的生成原理一目了然，方案会先确定 最小宽度基准值，然后将每个 values-swdp 中的 dimens.xml 文件都分配与 最小宽度基准值 相同的份数，再根据公式 屏幕最小宽度 / 份数 (最小宽度基准值) 求出每份占多少 dp，保证不管在哪个 values-swdp 中，份数 (最小宽度基准值) * 每份占的 dp 值 的结果都是刚好覆盖屏幕宽度，所以在 份数 不变的情况下，只需要根据屏幕的宽度在不同的设备上动态调整 每份占的 dp 值，就能完成适配

这样就能保证不管将项目运行到哪个设备上，只要当前设备能匹配到对应的 values-swdp 文件夹，那布局中的 dimens 引用就能根据当前屏幕的情况进行缩放，保证能完美适配，如果没有匹配到对应的 values-swdp 文件夹，也没关系，它会去寻找与之相近的 values-swdp 文件夹，虽然在这种情况下，布局中的 dimens 引用的值可能有些许误差，但是也能保证最大程度的完成适配

说到这里，那大家就应该就会明白我为什么会说 smallestWidth 限定符屏幕适配方案 的原理也同样是按百分比进行布局，如果在布局中，一个 View 的宽度引用 dp_100，那不管运行到哪个设备上，这个 View 的宽度都是当前设备屏幕总宽度的 360分之100，前提是项目提供有当前设备屏幕对应的 values-swdp，如果没有对应的 values-swdp，就会去寻找相近的 values-swdp，这时就会存在误差了，至于误差是大是小，这就要看您的第二个因数怎么分配了

其实 smallestWidth 限定符屏幕适配方案 的原理和 今日头条屏幕适配方案 挺像的，今日头条屏幕适配方案 是根据屏幕的宽度或高度动态调整每个设备的 density (每 dp 占当前设备屏幕多少像素)，而 smallestWidth 限定符屏幕适配方案 同样是根据屏幕的宽度动态调整每个设备 每份占的 dp 值

第二个因素

第二个因数是需要适配哪些 最小宽度？比如您想适配的 最小宽度 有 320dp、360dp、400dp、411dp、480dp，那方案就会为您的项目生成 values-sw320dp、values-sw360dp、values-sw400dp、values-sw411dp、values-sw480dp 这几个资源文件夹，像这样👇

├── src/main

│   ├── res

│   ├── ├──values

│   ├── ├──values-sw320dp

│   ├── ├──values-sw360dp

│   ├── ├──values-sw400dp

│   ├── ├──values-sw411dp

│   ├── ├──values-sw480dp

方案会为您需要适配的 最小宽度，在项目中生成一系列对应的 values-swdp，在前面也说了，如果某个设备没有为它提供对应的 values-swdp，那它就会去寻找相近的 values-swdp，但如果这个相近的 values-swdp 与期望的 values-swdp 差距太大，那适配效果也就会大打折扣

那是不是 values-swdp 文件夹生成的越多，覆盖越多市面上的设备，就越好呢？

也不是，因为每个 values-swdp 文件夹其实都会占用一定的 App 体积，values-swdp 文件夹越多，App 的体积也就会越大

所以一定要合理分配 values-swdp，以越少的 values-swdp 文件夹，覆盖越多的机型

验证方案可行性

原理讲完了，我们还是按照老规矩，来验证一下这个方案是否可行？

假设设计图总宽度为 375 dp，一个 View 在这个设计图上的尺寸是 50dp * 50dp，这个 View 的宽度占整个设计图宽度的 13.3% (50 / 375 = 0.133)

在使用 smallestWidth 限定符屏幕适配方案 时，需要提供 最小宽度基准值 和需要适配哪些 最小宽度，我们就把 最小宽度基准值 设置为 375 (和 设计图 一致)，这时方案就会为我们需要适配的 最小宽度 生成对应的 values-swdp 文件夹，文件夹中的 dimens.xml 文件是由从 1 到 375 组成的 dimens 引用，把所有设备的屏幕宽度都分为 375 份，所以在布局文件中我们应该把这个 View 的高宽都引用 dp_50

下面就来验证下在使用 smallestWidth 限定符屏幕适配方案 的情况下，这个 View 与屏幕宽度的比例在分辨率不同的设备上是否还能保持和设计图中的比例一致

验证设备 1

设备 1 的屏幕总宽度为 1080 px，屏幕总高度为 1920 px，DPI 为 480

设备 1 的屏幕高度大于屏幕宽度，所以 设备 1 的 最小宽度 为屏幕宽度，再根据公式 px / (DPI / 160) = dp，求出 设备 1 的 最小宽度 的值为 360 dp (1080 / (480 / 160) = 360)

根据 设备 1 的 最小宽度 应该匹配的是 values-sw360dp 这个文件夹，假设 values-sw360dp 文件夹及里面的 dimens.xml 已经生成，且是按 最小宽度基准值 为 375 生成的，360 / 375 = 0.96，所以每份占的 dp 值为 0.96，dimens.xml 里面的内容是长下面这样的

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">0.96dp</dimen>
    <dimen name="dp_2">1.92dp</dimen>
    <dimen name="dp_3">2.88dp</dimen>
    <dimen name="dp_4">3.84dp</dimen>
    <dimen name="dp_5">4.8dp</dimen>
    ...
    <dimen name="dp_50">48dp</dimen>
    ...
    <dimen name="dp_371">356.16dp</dimen>
    <dimen name="dp_372">357.12dp</dimen>
    <dimen name="dp_373">358.08dp</dimen>
    <dimen name="dp_374">359.04dp</dimen>
    <dimen name="dp_375">360dp</dimen>
</resources>

可以看到这个 View 在布局中引用的 dp_50，最终在 values-sw360dp 中定格在了 48 dp，所以这个 View 在 设备 1 上的高宽都为 48 dp，系统最后会将高宽都换算成 px，根据公式 dp * (DPI / 160) = px，所以这个 View 的高宽换算为 px 后等于 144 px (48 * (480 / 160) = 144)

144 / 1080 = 0.133，View 的实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以完成了等比例缩放

某些设备的高宽是和 设备 1 相同的，但是 DPI 可能不同，而由于 smallestWidth 限定符屏幕适配方案 并没有像 今日头条屏幕适配方案 一样去自行修改 density，所以系统就会使用默认的公式 DPI / 160 求出 density，density 又会影响到 dp 和 px 的换算，因此 DPI 的变化，是有可能会影响到 smallestWidth 限定符屏幕适配方案 的

所以我们再来试试在这种特殊情况下 smallestWidth 限定符屏幕适配方案 是否也能完成适配

验证设备 2

设备 2 的屏幕总宽度为 1080 px，屏幕总高度为 1920 px，DPI 为 420

设备 2 的屏幕高度大于屏幕宽度，所以 设备 2 的 最小宽度 为屏幕宽度，再根据公式 px / (DPI / 160) = dp，求出 设备 2 的 最小宽度 的值为 411.429 dp (1080 / (420 / 160) = 411.429)

根据 设备 2 的 最小宽度 应该匹配的是 values-sw411dp 这个文件夹，假设 values-sw411dp 文件夹及里面的 dimens.xml 已经生成，且是按 最小宽度基准值 为 375 生成的，411 / 375 = 1.096，所以每份占的 dp 值为 1.096，dimens.xml 里面的内容是长下面这样的👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1.096dp</dimen>
    <dimen name="dp_2">2.192dp</dimen>
    <dimen name="dp_3">3.288dp</dimen>
    <dimen name="dp_4">4.384dp</dimen>
    <dimen name="dp_5">5.48dp</dimen>
    ...
    <dimen name="dp_50">54.8dp</dimen>
    ...
    <dimen name="dp_371">406.616dp</dimen>
    <dimen name="dp_372">407.712dp</dimen>
    <dimen name="dp_373">408.808dp</dimen>
    <dimen name="dp_374">409.904dp</dimen>
    <dimen name="dp_375">411dp</dimen>
</resources>

可以看到这个 View 在布局中引用的 dp_50，最终在 values-sw411dp 中定格在了 54.8dp，所以这个 View 在 设备 2 上的高宽都为 54.8 dp，系统最后会将高宽都换算成 px，根据公式 dp * (DPI / 160) = px，所以这个 View 的高宽换算为 px 后等于 143.85 px (54.8 * (420 / 160) = 143.85)

143.85 / 1080 = 0.133，View 的实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以完成了等比例缩放

虽然 View 在 设备 2 上的高宽是 143.85 px，比 设备 1 的 144 px 少了 0.15 px，但是误差非常小，整体的比例并没有发生太大的变化，是完全可以接受的

这个误差是怎么引起的呢，因为 设备 2 的 最小宽度 的实际值是 411.429 dp，但是匹配的 values-sw411dp 舍去了小数点后面的位数 (切记！系统会去寻找小于或等于 411.429 dp 的 values-swdp，所以 values-sw412dp 这个文件夹，设备 2 是匹配不了的)，所以才存在了一定的误差，因此上面介绍的第二个因数是非常重要的，这直接决定误差是大还是小

可以看到即使在高宽一样但 DPI 不一样的设备上，smallestWidth 限定符屏幕适配方案 也能完成等比例适配，证明这个方案是可行的，如果大家还心存疑虑，也可以再试试其他分辨率的设备，其实到最后得出的比例都是在 0.133 左右，唯一的变数就是第二个因数，如果您生成的 values-swdp 与设备实际的 最小宽度 差别不大，那误差也就在能接受的范围内，如果差别很大，那就直接 GG

优点

1. 非常稳定，极低概率出现意外




2. 不会有任何性能的损耗




3. 适配范围可自由控制，不会影响其他三方库




4. 在插件的配合下，学习成本低

缺点

1. 在布局中引用 dimens 的方式，虽然学习成本低，但是在日常维护修改时较麻烦




2. 侵入性高，如果项目想切换为其他屏幕适配方案，因为每个 Layout 文件中都存在有大量 dimens 的引用，这时修改起来工作量非常巨大，切换成本非常高昂




3. 无法覆盖全部机型，想覆盖更多机型的做法就是生成更多的资源文件，但这样会增加 App 体积，在没有覆盖的机型上还会出现一定的误差，所以有时需要在适配效果和占用空间上做一些抉择




4. 如果想使用 sp，也需要生成一系列的 dimens，导致再次增加 App 的体积




5. 不能自动支持横竖屏切换时的适配，如上文所说，如果想自动支持横竖屏切换时的适配，需要使用 values-wdp 或 屏幕方向限定符 再生成一套资源文件，这样又会再次增加 App 的体积




6. 不能以高度为基准进行适配，考虑到这个方案的名字本身就叫 最小宽度限定符适配方案，所以在使用这个方案之前就应该要知道这个方案只能以宽度为基准进行适配，为什么现在的屏幕适配方案只能以高度或宽度其中的一个作为基准进行适配，请看 这里

使用中的问题

这时有人就会问了，设计师给的设计图只标注了 px，使用这个方案时，那不是还要先将 px 换算成 dp？

其实也可以不用换算的，那这是什么骚操作呢？

很简单，你把设计图的 px 总宽度设置成 最小宽度基准值 就可以了，还是以前面验证可行性的例子

我们在前面验证可行性时把 最小宽度基准值 设置成了 375，为什么是 375 呢？因为设计图的总宽度为 375 dp，如果换算成 px，总宽度就是 750 px，我们这时把 最小宽度基准值 设置成 750，然后看看 values-sw360dp 中的 dimens.xml 长什么样👇<?xml version="1.0" encoding="UTF-8"?>

<resources>
    <dimen name="px_1">0.48dp</dimen>
    <dimen name="px_2">0.96dp</dimen>
    <dimen name="px_3">1.44dp</dimen>
    <dimen name="px_4">1.92dp</dimen>
    <dimen name="px_5">2.4dp</dimen>
    ...
    <dimen name="px_50">24dp</dimen>
    ...
    <dimen name="px_100">48dp</dimen>
    ...
    <dimen name="px_746">358.08dp</dimen>
    <dimen name="px_747">358.56dp</dimen>
    <dimen name="px_748">359.04dp</dimen>
    <dimen name="px_749">359.52dp</dimen>
    <dimen name="px_750">360dp</dimen>
</resources>

360 dp 被分成了 750 份，相比之前的 375 份，现在 每份占的 dp 值 正好减少了一半，还记得在验证可行性的例子中那个 View 的尺寸是多少吗？50dp * 50dp，如果设计图只标注 px，那这个 View 在设计图上的的尺寸应该是 100px * 100px，那我们直接根据设计图上标注的 px，想都不用想直接在布局中引用 px_100 就可以了，因为在 375 份时的 dp_50 刚好等于 750 份时的 px_100 (值都是 48 dp)，所以这时的适配效果和之前验证可行性时的适配效果没有任何区别

看懂了吗？直接将 最小宽度基准值 和布局中的引用都以 px 作为单位就可以直接填写设计图上标注的 px！

总结

关于文中所列出的优缺点，列出的缺点数量确实比列出的优点数量多，但 缺点 3，缺点 4，缺点 5 其实都可以归纳于 占用 App 体积 这一个缺点，因为他们都可以通过增加资源文件来解决问题，而 缺点 6 则是这个方案的特色，只能以宽度为基准进行适配，这个从这个方案的名字就能看出

请大家千万不要曲解文章的意思，不要只是单纯的对比优缺点的数量，缺点的数量大于优点的数量就一定是这个方案不行？没有一个方案是完美的，每个人的需求也都不一样，作为一篇科普类文章我只可能把这个方案描述得尽可能的全面

这个方案能给你带来什么，不能给你带来什么，我必须客观的描述清楚，这样才有助你做出决定，你应该注重的是在这些优缺点里什么是我能接受的，什么是我不能接受的，是否能为了某些优点做出某些妥协，而不只是单纯的去看数量，这样毫无意义，有些人就是觉得稳定性最重要，其他的都可以做出妥协，那其他缺点对于他来说都是无所谓的

好了，这个系列的第二篇文章讲完了，这篇文章也是按照上篇文章的优良传统，写的非常详细，哪怕是新手我相信也应该能看懂，为什么这么多人都不知道自己该选择什么样的方案，就是因为自己都没搞懂这些方案的原理，懂了原理过后才知道这些方案是否是自己想要的

接下来的第三篇文章会详细讲解两个方案的深入对比以及该如何选择，并剖析我根据 今日头条屏幕适配方案 优化的屏幕适配框架 AndroidAutoSize 的原理，敬请期待

如果大家想使用 smallestWidth 限定符屏幕适配方案，可以参考 这篇文章，里面提供有自动生成资源文件的插件和 Demo，由于我并没有在项目中使用 smallestWidth 限定符屏幕适配方案，所以如果在文章中有遗漏的知识点请谅解以及补充，感谢！

前言

这个月在 Android 技术圈中 屏幕适配 这个词曝光率挺高的，为什么这么说呢？因为这个月陆续有多个大佬发布了屏幕适配相关的文章，公布了自己认可的屏幕适配方案

上上个星期 Blankj 老师发表了一篇力挺今日头条屏幕适配方案的 文章，提出了很多优化的方案，并开源了相关源码

上个星期 拉丁吴 老师在 鸿神 的公众号上发布了一篇 文章，详细描述了市面上主流的几种屏幕适配方案，并发布了他的 smallestWidth 限定符适配方案和相关源码 (其实早就发布了)，文章写的很好，建议大家去看看

其实大家最关注的不是市面上有多少种屏幕适配方案，而是自己的项目该选择哪种屏幕适配方案，可以看出两位老师最终选择的屏幕适配方案都是不同的

我下面就来分析分析，我作为一个才接触这两个屏幕适配方案的吃瓜群众，我是怎么来验证这两种屏幕适配方案是否可行，以及怎样根据它们的优缺点来选择一个最适合自己项目的屏幕适配方案

浅谈适配方案

在 拉丁吴 老师的文章中谈到了两个比较经典的屏幕适配方案，在我印象中十分深刻，我想大多数兄弟都用过，在我的开发生涯里也是有很长一段时间都在用这两种屏幕适配方案

第一种就是宽高限定符适配，什么是宽高限定符适配呢

├── src/main

│   ├── res

│   ├── ├──values

│   ├── ├──values-800x480

│   ├── ├──values-860x540

│   ├── ├──values-1024x600

│   ├── ├──values-1024x768

│   ├── ├──...

│   ├── ├──values-2560x1440

就是这种，在资源文件下生成不同分辨率的资源文件，然后在布局文件中引用对应的 dimens，大家一定还有印象

第二种就是 鸿神 的 AndroidAutoLayout

这两种方案都已经逐渐退出了历史的舞台，为什么想必大家都知道，不知道的建议看看 拉丁吴 老师的文章，所以这两种方案我在文章中就不在阐述了，主要讲讲现在最主流的两种屏幕适配方案，今日头条适配方案 和 smallestWidth 限定符适配方案

建议大家不清楚这两个方案的先看看这两篇文章，才清楚我在讲什么，后面我要讲解它们的原理，以及验证这两种方案是否真的可行，最后对他们进行深入对比，对于他们的一些缺点给予对应的解决方案，绝对干货

今日头条屏幕适配方案

原理

上面已经告知，不了解这两个方案的先看看上面的两篇文章，所以这里我就假设大家已经看了上面的文章或者之前就了解过这两个方案，所以在本文中我就不再阐述 DPI、Density 以及一些比较基础的知识点，上面的文章已经阐述的够清楚了

今日头条屏幕适配方案的核心原理在于，根据以下公式算出 density

当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density

density 的意思就是 1 dp 占当前设备多少像素

为什么要算出 density，这和屏幕适配有什么关系呢？

public static float applyDimension(int unit, float value,

                                       DisplayMetrics metrics)

    {

        switch (unit) {

        case COMPLEX_UNIT_PX:

            return value;

        case COMPLEX_UNIT_DIP:

            return value * metrics.density;

        case COMPLEX_UNIT_SP:

            return value * metrics.scaledDensity;

        case COMPLEX_UNIT_PT:

            return value * metrics.xdpi * (1.0f/72);

        case COMPLEX_UNIT_IN:

            return value * metrics.xdpi;

        case COMPLEX_UNIT_MM:

            return value * metrics.xdpi * (1.0f/25.4f);

        }

        return 0;

    }

大家都知道，不管你在布局文件中填写的是什么单位，最后都会被转化为 px，系统就是通过上面的方法，将你在项目中任何地方填写的单位都转换为 px 的

所以我们常用的 px 转 dp 的公式 dp = px / density，就是根据上面的方法得来的，density 在公式的运算中扮演着至关重要的一步

要看懂下面的内容，还得明白，今日头条的适配方式，今日头条适配方案默认项目中只能以高或宽中的一个作为基准，进行适配，为什么不像 AndroidAutoLayout 一样，高以高为基准，宽以宽为基准，同时进行适配呢

这就引出了一个现在比较棘手的问题，大部分市面上的 Android 设备的屏幕高宽比都不一致，特别是现在大量全面屏的问世，这个问题更加严重，不同厂商推出的全面屏手机的屏幕高宽比都可能不一致

这时我们只以高或宽其中的一个作为基准进行适配，就会有效的避免布局在高宽比不一致的屏幕上出现变形的问题

明白这个后，我再来说说 density，density 在每个设备上都是固定的，DPI / 160 = density，屏幕的总 px 宽度 / density = 屏幕的总 dp 宽度

• 设备 1，屏幕宽度为 1080px，480DPI，屏幕总 dp 宽度为 1080 / (480 / 160) = 360dp




• 设备 2，屏幕宽度为 1440，560DPI，屏幕总 dp 宽度为 1440 / (560 / 160) = 411dp

可以看到屏幕的总 dp 宽度在不同的设备上是会变化的，但是我们在布局中填写的 dp 值却是固定不变的

这会导致什么呢？假设我们布局中有一个 View 的宽度为 100dp，在设备 1 中 该 View 的宽度占整个屏幕宽度的 27.8% (100 / 360 = 0.278)

但在设备 2 中该 View 的宽度就只能占整个屏幕宽度的 24.3% (100 / 411 = 0.243)，可以看到这个 View 在像素越高的屏幕上，dp 值虽然没变，但是与屏幕的实际比例却发生了较大的变化，所以肉眼的观看效果，会越来越小，这就导致了传统的填写 dp 的屏幕适配方式产生了较大的误差

这时我们要想完美适配，那就必须保证这个 View 在任何分辨率的屏幕上，与屏幕的比例都是相同的

这时我们该怎么做呢？改变每个 View 的 dp 值？不现实，在每个设备上都要通过代码动态计算 View 的 dp 值，工作量太大

如果每个 View 的 dp 值是固定不变的，那我们只要保证每个设备的屏幕总 dp 宽度不变，就能保证每个 View 在所有分辨率的屏幕上与屏幕的比例都保持不变，从而完成等比例适配，并且这个屏幕总 dp 宽度如果还能保证和设计图的宽度一致的话，那我们在布局时就可以直接按照设计图上的尺寸填写 dp 值

屏幕的总 px 宽度 / density = 屏幕的总 dp 宽度

在这个公式中我们要保证 屏幕的总 dp 宽度 和 设计图总宽度 一致，并且在所有分辨率的屏幕上都保持不变，我们需要怎么做呢？屏幕的总 px 宽度 每个设备都不一致，这个值是肯定会变化的，这时今日头条的公式就派上用场了

当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density

这个公式就是把上面公式中的 屏幕的总 dp 宽度 换成 设计图总宽度，原理都是一样的，只要 density 根据不同的设备进行实时计算并作出改变，就能保证 设计图总宽度 不变，也就完成了适配

验证方案可行性

上面已经把原理分析的很清楚了，很多文章只是一笔带过这个公式，公式虽然很简单但我们还是想晓得这是怎么来的，所以我就反向推理了一遍，如果还是看不懂，那我只能说我尽力了，原理讲完了，那我们再来现场验证一下这个方案是否可行?

假设设计图总宽度为 375 dp，一个 View 在这个设计图上的尺寸是 50dp * 50dp，这个 View 的宽度占整个设计图宽度的 13.3% (50 / 375 = 0.133)，那我们就来验证下在使用今日头条屏幕适配方案的情况下，这个 View 与屏幕宽度的比例在分辨率不同的设备上是否还能保持和设计图中的比例一致

验证设备 1

屏幕总宽度为 1080 px，根据今日头条的的公式求出 density，1080 / 375 = 2.88 (density)

这个 50dp * 50dp 的 View，系统最后会将高宽都换算成 px，50dp * 2.88 = 144 px (根据公式 dp * density = px)

144 / 1080 = 0.133，View 实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以完成了等比例缩放

某些设备总宽度为 1080 px，但是 DPI 可能不同，是否会对今日头条适配方案产生影响？其实这个方案根本没有根据 DPI 求出 density，是根据自己的公式求出的 density，所以这对今日头条的方案没有影响

上面只能确定在所有屏幕总宽度为 1080 px 的设备上能完成等比例适配，那我们再来试试其他分辨率的设备

验证设备 2

屏幕总宽度为 1440 px，根据今日头条的的公式求出 density，1440 / 375 = 3.84 (density)

这个 50dp * 50dp 的 View，系统最后会将高宽都换算成 px，50dp * 3.84 = 192 px (根据公式 dp * density = px)

192 / 1440 = 0.133，View 实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以也完成了等比例缩放

两个不同分辨率的设备都完成了等比例缩放，证明今日头条屏幕适配方案在不同分辨率的设备上都是有效的，如果大家还心存疑虑，可以再试试其他分辨率的设备，其实到最后得出的比例不会有任何偏差, 都是 0.133

优点

1. 使用成本非常低，操作非常简单，使用该方案后在页面布局时不需要额外的代码和操作，这点可以说完虐其他屏幕适配方案




2. 侵入性非常低，该方案和项目完全解耦，在项目布局时不会依赖哪怕一行该方案的代码，而且使用的还是 Android 官方的 API，意味着当你遇到什么问题无法解决，想切换为其他屏幕适配方案时，基本不需要更改之前的代码，整个切换过程几乎在瞬间完成，会少很多麻烦，节约很多时间，试错成本接近于 0




3. 可适配三方库的控件和系统的控件(不止是 Activity 和 Fragment，Dialog、Toast 等所有系统控件都可以适配)，由于修改的 density 在整个项目中是全局的，所以只要一次修改，项目中的所有地方都会受益




4. 不会有任何性能的损耗

缺点

暂时没发现其他什么很明显的缺点，已知的缺点有一个，那就是第三个优点，它既是这个方案的优点也同样是缺点，但是就这一个缺点也是非常致命的

只需要修改一次 density，项目中的所有地方都会自动适配，这个看似解放了双手，减少了很多操作，但是实际上反应了一个缺点，那就是只能一刀切的将整个项目进行适配，但适配范围是不可控的

这样不是很好吗？这样本来是很好的，但是应用到这个方案是就不好了，因为我上面的原理也分析了，这个方案依赖于设计图尺寸，但是项目中的系统控件、三方库控件、等非我们项目自身设计的控件，它们的设计图尺寸并不会和我们项目自身的设计图尺寸一样

当这个适配方案不分类型，将所有控件都强行使用我们项目自身的设计图尺寸进行适配时，这时就会出现问题，当某个系统控件或三方库控件的设计图尺寸和和我们项目自身的设计图尺寸差距非常大时，这个问题就越严重

举个栗子

假设一个三方库的 View，作者在设计时，把它设计为 100dp * 100dp，设计图的最大宽度为 1000dp，这个 View 在设计图中的比例是 100 / 1000 = 0.1，意思是这个 View 的宽度在设计图中占整个宽度的 10%，如果我们要完成等比例适配，那这个三方库 View 在所有的设备上与屏幕的总宽度的比例，都必须保持在 10%

这时在一个使用今日头条屏幕适配方案的项目上，设置的设计图最大宽度如果是 1000dp，那这个三方库 View，与项目自身都可以完美的适配，但当我们项目自身的设计图最大宽度不是 1000dp，是 500dp 时，100 / 500 = 0.2，可以看到，比例发生了较大的变化，从 10% 上升为 20%，明显这个三方库 View 高于作者的预期，比之前更大了

这就是两个设计图尺寸不一致导致的非常严重的问题，当两个设计图尺寸差距越大，那适配的效果也就天差万别了

解决方案

方案 1

调整设计图尺寸，因为三方库可能是远程依赖的，无法修改源码，也就无法让三方库来适应我们项目的设计图尺寸，所以只有我们自身作出修改，去适应三方库的设计图尺寸，我们将项目自身的设计图尺寸修改为这个三方库的设计图尺寸，就能完成项目自身和三方库的适配

这时项目的设计图尺寸修改了，所以项目布局文件中的 dp 值，也应该按照修改的设计图尺寸，按比例增减，保持与之前设计图中的比例不变

但是如果为了适配一个三方库修改整个项目的设计图尺寸，是非常不值得的，所以这个方案支持以 Activity 为单位修改设计图尺寸，相当于每个 Activity 都可以自定义设计图尺寸，因为有些 Activity 不会使用三方库 View，也就不需要自定义尺寸，所以每个 Activity 都有控制权的话，这也是最灵活的

但这也有个问题，当一个 Activity 使用了多个设计图尺寸不一样的三方库 View，就会同样出现上面的问题，这也就只有把设计图改为与几个三方库比较折中的尺寸，才能勉强缓解这个问题

方案 2

第二个方案是最简单的，也是按 Activity 为单位，取消当前 Activity 的适配效果，改用其他的适配方案

使用中的问题

有些文章中提到了今日头条屏幕适配方案可以将设计图尺寸填写成以 px 为单位的宽度和高度，这样我们在布局文件中，也就能直接填写设计图上标注的 px 值，省掉了将 px 换算为 dp 的时间 (大部分公司的设计图都只标注 px 值)，而且照样能完美适配

但是我建议大家千万不要这样做，还是老老实实的以 dp 为单位填写 dp 值，为什么呢？

直接填写 px 虽然刚开始布局的时候很爽，但是这个坑就已经埋上了，会让你后面很爽，有哪些坑？

第一个坑

这样无疑于使项目强耦合于这个方案，当你遇到无法解决的问题想切换为其他屏幕适配方案的时候，layout 文件里曾经填写的 px 值都会作为 dp

比如你的设计图实际宽度为 1080px，你不换算为 360dp (1080 / 3 = 360)，却直接将 1080px 作为这个方案的设计图尺寸，那你在 layout 文件中，填写的也都是设计图上标注的 px 值，但是单位却是 dp

一个在设计图上 300px * 300px 的 View，你可以直接在 layout 文件中填写为 300dp，而由于这个方案可以动态改变 density 的原因还是可以做到等比例适配，非常爽!

但你不要忘了，这样你就强耦合于这个方案了，因为当你不使用这个方案时，density 是不可变的!

举个栗子

使用这个方案时，在屏幕宽度为 1080px 的设备上，将设计图宽度直接填写为 1080，根据今日头条公式

当前设备屏幕总宽度 / 设计图总宽度 = density

这时得出 density 为 1 (1080 / 1080 = 1)，所以你在 layout 文件中你填写的 300dp 最后转换为 px 也是 300px (300dp * 1 = 300px 根据公式 dp * density = px)

在这个方案的帮助下非常完美，和设计图一模一样完成了适配

但当你不使用这个方案时，density 的换算公式就变为官方的 DPI / 160 = density，

在这个屏幕宽度为 1080px，480dpi 的设备上，density 就固定为 3 (480 / 160 = 3)

这时再来看看你之前在 layout 文件中填写的 dp，换算成 px 为 900 px (300dp * 3 = 900px 根据公式 dp * density = px)

原本在在设计图上为 300px 的 View，这时却达到了惊人的 900px，3倍的差距，恭喜你，你已经强耦合于这个方案了，你要不所有 layout 文件都改一遍，要不继续使用这个方案

第二个坑

第二个坑其实就是刚刚在上面说的今日头条适配方案的缺点，当某个系统控件或三方库控件的设计图尺寸和和我们项目自身的设计图尺寸差距非常大时，这个问题就越严重

你如果直接填写以 px 为设计图的尺寸，这不用想，肯定和所有的三方库以及系统控件的设计图尺寸都不一样，而且差距都非常之大，至少两三倍的差距，这时你在当前页面弹个 Toast 就可以明显看到，比之前小很多，可以说是天差万别，用其他三方库 View，也是一样的，会小很多

因为你以 px 为单位填写设计图尺寸，人家却用的 dp，差距能不大吗，你如果老老实实用 dp，哪怕三方库的设计图尺寸和你项目自身的设计图尺寸不一样，那也差距不大，小到一定程度，基本都不用调整，可以忽略不计，而且很多三方库的设计图尺寸其实也都是那几个大众尺寸，很大可能和你项目自身的设计图尺寸一样

总结

可以看到我讲的非常详细，可以说比今日头条官方以及任何博客写的都清楚，从原理到优缺点再到解决方案一应俱全，因为篇幅有限，如果我还想把 smallestWidth 限定符适配方案写的这么详细，那估计这篇文章得有一万字了

所以我把这次的屏幕适配文章归位一个系列，一共分为三篇，第一篇详细的讲 今日头条屏幕适配方案，第二篇详细的讲 smallestWidth 限定符适配方案，第三篇详细讲两个方案的深入对比以及如何选择，并发布我根据 今日头条屏幕适配方案 优化的屏幕适配框架 AndroidAutoSize

今日头条屏幕适配方案 官方公布的核心源码只有 30 行不到，但我这个框架的源码有 1500 行以上，在保留原有特性的情况下增加了不少功能和特性，功能增加了不少，但是使用上却变简单了

只要这一步填写了设计图的高宽以 dp 为单位，你什么都不做，框架就开始适配了

大家可以提前看看我是怎么封装和优化的，我后面的第三篇文章会给出这个框架的原理分析，敬请期待

关于大家的评论以及关注的问题，我在这里统一回复一下:

感谢，大家的关注和回复，我介绍这个今日头条的屏幕适配方案并不是说他有多么完美，只是他确实有效而且能帮我们减少很多开发成本

对于很多人说的 DPI 的存在，不就是为了让大屏能显示更多的内容，如果一个大屏手机和小屏手机，显示的内容都相同，那用户买大屏手机又有什么意义呢，我觉得大家对 DPI 的理解是对的，这个观点我也是认同的，Google 设计 DPI 时可能也是这么想的，但是有一点大家没考虑到，Android 的碎片化太严重了

为什么 Android 诞生这么多年，Android 的百分比库层出不穷，按理说他们都违背了上面说的这个理念，但为什么还有这么多人去研究百分比库通过各种方式去实现百分比布局 (谷歌官方也曾出过百分比库)？为什么？很简单，因为需求啊！为什么需求，因为开发成本低啊！为什么今日头条的这个屏幕适配方案现在能这么火，因为他的开发成本是目前所有屏幕适配方案中最低的啊！

DPI 的意义谁又不懂呢？难道就你懂，今日头条这种大公司的程序员不懂这个道理吗？今日头条这么大的公司难道不想把每个机型每个版本的设备都适配完美，让自己的 App 体验更好，哪怕付出更大的成本，有些时候想象是美好的，但是这个投入的成本，谁又能承担呢，连今日头条这么大的公司，这么雄厚的资本都没选择投入更大的成本，对每个机型进行更精细化的适配，难道市面上的中小型公司又有这个能力投入这么大的成本吗？

鱼和熊掌不可兼得，DPI 的意义在 Google 的设计理念中是完全正确的，但不是所有公司都能承受这个成本，想必今日头条的程序员，也是因为今日头条 App 的用户量足够多，机型分布足够广，也是被屏幕适配这个问题折磨的不要不要的，才想出这么个不这么完美但是却很有效的方案

dependencies {

    compile project(':autolayout')

}

<meta-data android:name="design_width" android:value="768">

meta-data>

<meta-data android:name="design_height" android:value="1280">

meta-data>

    

public class UseDeviceSizeApplication extends Application

{

    @Override

    public void onCreate()

    {

        super.onCreate();

        AutoLayoutConifg.getInstance().useDeviceSize();

    }

}

@Override

public View getView(int position, View convertView, ViewGroup parent)

{

    ViewHolder holder = null;

    if (convertView == null)

    {

        holder = new ViewHolder();

        convertView = LayoutInflater.from(mContext).inflate(R.layout.list_item, parent, false);

        convertView.setTag(holder);

        //对于listview，注意添加这一行，即可在item上使用高度

        AutoUtils.autoSize(convertView);

    } else

    {

        holder = (ViewHolder) convertView.getTag();

    }



    return convertView;

}

public ViewHolder(View itemView)

{

      super(itemView);

      AutoUtils.autoSize(itemView);

}



//...

@Override

public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType)

{

     View convertView = LayoutInflater.from(mContext).inflate(R.layout.recyclerview_item, parent, false);

     return new ViewHolder(convertView);

}