平板适配方案

平板适配方案

非原创，作为记录使用。由于是新项目开发，最终使用的是今日头条适配方案，侵入低，效果好。 by talon

常用的适配方案

一、宽高限定符适配

含义

在res文件夹中，创建很多values-的文件夹，计算出对应的dimen的值，类似下面目录

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-800x480
│   ├── ├──values-860x540
│   ├── ├──values-1024x600
│   ├── ├──values-1024x768
│   ├── ├──...
│   ├── ├──values-2560x1440

缺点

这个方案有一个致命的缺陷，那就是需要精准命中才能适配，容错率差；并且我们在计算dimen也会有比较大的麻烦，虽然有自动生成的工具。

二、smallestWidth限定符适配

含义

与第一种方法类似，解决了第一种方法的容错差的问题，类似于mipmap中的资源，会自动找寻与自己相近的资源文件，在拉丁吴老师的文章中力挺这种方法。

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw360dp
│   ├── ├──values-sw384dp
│   ├── ├──values-sw400dp
│   ├── ├──...
│   ├── ├──values-sw600dp

三、鸿神 的 AndroidAutoLayout

含义

让你的Activity继承自AutoLayoutActivity，在AndroidManifest中就指定设计图的尺寸，在写布局文件时，就可以直接写px，框架会通过px自动换算

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

缺点

我们能够想到，因为框架要在运行时会在onMeasure里面做变换，我们自定义的控件可能会被影响或限制，可能有些特定的控件，需要单独适配，这里面可能存在的暗坑是不可预见的，还有一个比较重要的问题，那就是整个适配工作是有框架完成的，而不是系统完成的，一旦使用这个框架，未来一旦遇到很难解决的问题，替换起来是非常麻烦的，而且项目一旦停止维护，后续的升级就只能靠你自己了，这种代价团队能否承受？已经停止维护了

四、今日头条适配方案

含义

通过修改density值，强行把所有不同尺寸分辨率的手机的宽度dp值改成一个统一的值，这样就解决了所有的适配问题。

问题

• 在使用一些第三方View的时候，由于第三方View并不是按照我们的UI设计尺寸来的，所以会引起偏差。
  我们其实可以减少使用第三方的View，或者使用一些分辨率比较齐全的第三方View。

• 使用自定义dialog正常，但使用系统自带dialog时可能会出现显示不全的场景，这时需要修改dialog的大小。

  解决：https://blog.csdn.net/u011368551/article/details/108503710

实现方法

app/build.gradle

implementation 'me.jessyan:autosize:1.1.2'

manifest.xml application 标签内

<meta-data
            android:name="design_width_in_dp"
            android:value="853" />
        <meta-data
            android:name="design_height_in_dp"
            android:value="553" />