平板适配方案

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

常用的适配方案
一、宽高限定符适配
含义
在res文件夹中，创建很多values-的文件夹，计算出对应的dimen的值，类似下面目录

├── src/main
│ ├── res
│ ├── ├──values
│ ├── ├──values-800×480
│ ├── ├──values-860×540
│ ├── ├──values-1024×600
│ ├── ├──values-1024×768
│ ├── ├──…
│ ├── ├──values-2560×1440 

缺点
这个方案有一个致命的缺陷，那就是需要精准命中才能适配，容错率差；并且我们在计算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″ />

————————————————
版权声明：本文为CSDN博主「Android唐浮」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u011368551/article/details/104256709