Android 屏幕适配相关知识

        屏幕适配一直是Android开发者比较痛恨的工作,因为国内定制机型屏幕碎片化简直炸裂，现在又多了凹面屏（刘海儿屏），真的是。。。
        至于屏幕适配技术也是非常之多了，但目前大家最为推崇的还属今日头条的适配方案，效果可以说是几近完美了。经常能在郭神公众号看到屏幕适配方案的blog，也是越看越迷糊了！！！

        这里分享一个今天看到的吧！搬一些内容整合一下。https://mp.weixin.qq.com/s/v_aauFjx-f91WrpCAaNMVQ

---

先来了解几个名词
1. 像素(px):
        ，1px = 1像素点，一般设计图就以px为单位
2. 分辨率:
        手机在横向、纵向上的像素点数总和一般描述成宽高, 即横向像素点个数 * 纵向像素点个数（如1080 x 1920）
3. 屏幕尺寸(in):
        ，即手机对角线长度，一英寸大约2.54cm， 常见的尺寸有4.7寸、5寸、5.5寸、6寸
4. 屏幕像素密度(dpi):
        ，指每英寸的像素点数。 例如每英寸内有160个像素点，则其像素密度为160dpi。Android官方也把160定为一个基准。
5. 密度无关像素（dp或dip):
        ，只跟像素密度有关,与终端上的实际物理像素点无关,可以保证在不同屏幕像素密度的设备上显示相同的效果，是Android特有的长度单位。郭神说叫他密度独立像素更准确一些!
        例：假如同样都是画一条长度是屏幕一半的线，如果使用px作为计量单位，那么在480x800分辨率手机上设置应为240px；在320x480的手机上应设置为160px，二者设置就不同了；如果使用dp为单位，在这两种分辨率下，都显示为屏幕一半的长度。
6. 独立比例像素（sp或sip）:
        ，Android中字体大小专用单位, 推荐使用12sp、14sp、18sp、22sp作为字体大小，不推荐使用奇数和小数，容易造成精度丢失。

Android屏幕参数分布图.jpg

        这张图算是Android手机屏幕参数老早以前的了，ldpi和hdpi的手机应该已经不存在了，当今最高的也差不多1440x2560了（但是2k屏采用得还算比较少），大部分中高端机型都在1080x1920，所以这张图差不多够用。

重中之重来了,两个需要知道的公式

  **手机屏幕像素密度计算
  dpi = px / in;  <像素密度 = 像素 / 尺寸>

  **px转dp计算公式
  dp = （dpi / 160 ） * 1px;

像素密度计算公式.png

                    比如一部手机的分辨率是1080x1920（px），屏幕大小是5寸,
               那么如下计算出来适配该设备,剩下的事就是工具类计算出来使用了
                              440/160 = 2.75      1dp = 2.75px

px to dp.jpg.png

接下来整合的是屏幕适配方法

这几种方法入手,也是最原生的方式

• 控件使用适配
• layout文件夹适配
• 图片使用适配
• 代码测量适配
• 后台接口适配

下面逐一介绍,如果时间很紧可以简略看一下标题,面试也能用上!

一、控件使用适配
                1. 使用密度无关像素指定尺寸,也就是dp或sp,px是绝对不能直接使用的
         有一定适配经验的朋友应该都是知道的。
                2. 使用相对布局或线性布局，禁用绝对布局
        这也是屏幕适配中念烂了的一句话。对于线性布局（Linearlayout）、相对布局（RelativeLayout）、帧布局（FrameLayout）以及新增的加强版帧布局（CoordinatorLayout）根据需求进行选择。CoordinatorLayout在 Material Design设计风格上使用有很好的优势。
        RelativeLayouts是一个相对位置排版，即使屏幕的大小改变，视图之前的相对位置都不会变化，与屏幕大小无关，灵活性很强，而LinearLayout法准确地控制子视图之间的位置关系，只能简单的一个挨着一个地排列，所以，对于屏幕适配来说，使用相对布局（RelativeLayout）将会是更好的解决方案，至于绝对布局（AbsoluteLayout）已经没有适配而言，可以放弃。
                 3. 使用wrap_content、match_parent和权重weight
        使用 “wrap_content”和 “match_parent”尺寸值而不是硬编码的尺寸，系统会自动计算相应的数值，视图就会相应地使用自身所需的空间或填满可用空间，让布局正确适应各种屏幕尺寸和屏幕方向，组件的权重比同理。同时weight在很多排版布局的时候非常直接有效,可以避免增加很多属性代码。
                 4.使用minWidth、minHeight、lines等属性        
        很多时候我们显示的数据都是由后台返回的，再由我们加工处理后去适配我们的组件，这些数据的长度我们是无法确定的，而正常情况下我们构思的布局都仅是适用于理想的情况下，为了保证界面的对齐、数据显示完整等等的原因，我们需要在构思布局时增加对组件最小宽高度、行数等属性的设置，确保在特殊的数据下不会破坏我们的整体布局。
                 5. dimens使用
        组件的长宽我们可以通过dimens来定义，不同的屏幕尺寸可以定义不同的数值，或者是不同的语言显示我们也可以定义不同的数值，因为翻译后的长度一般都不会跟中文的一致。

以上几种方式可以解决屏幕适配性的问题，但是那些通过伸缩控件来适应各种不同屏幕大小的布局，
未必就是提供了最好的用户体验。
你的应用程序应该不仅仅实现了可自适应的布局，
还应该提供一些方案根据屏幕的配置来加载不同的布局，
可以通过配置限定符(configuration qualifiers)来实现。
配置限定符允许程序在运行时根据当前设备的配置自动加载合适的资源
(比如为不同尺寸屏幕设计不同的布局)

        为了避免篇幅太长,我就直接列出来,大家对其可以展开了解,这也是值得深究的

---

二、layout文件夹适配

• 使用Size限定符
• 最小宽度限定符
• 使用布局别名
• 使用屏幕方向限定符
• 多套layout适配

三、 图片使用适配
       1. 普通图片和图标：建议安装官方的密度类型进行切图即可，但一般我们只需xxhdpi或xxxhdpi的切图即可满足我们的需求；图标尽量使用 svg格式的,非常实用!
       2. 自动拉伸位图：Nine-Patch的图片类型,也就是我们常说的.9图片,这个有工具制作的!
       3. ImageView的 ScaleType适配

android:scaleType=“center”
保持原图的大小，显示在ImageView的中心。
当原图的size大于ImageView的size时，多出来的部分被截掉。

android:scaleType=“center_inside”
以原图正常显示为目的，如果原图大小大于ImageView的size，
就按照比例缩小原图的宽高，居中显示在ImageView中。
如果原图size小于ImageView的size，则不做处理居中显示图片。

android:scaleType=“center_crop” 
以原图填满ImageView为目的，如果原图size大于ImageView的size，
则与center_inside一样，按比例缩小，居中显示在ImageView上。
如果原图size小于ImageView的size，则按比例拉升原图的宽和高，填充ImageView居中显示。

android:scaleType=“matrix” 
不改变原图的大小，从ImageView的左上角开始绘制，超出部分做剪切处理。

androd:scaleType=“fit_xy” 
把图片按照指定的大小在ImageView中显示，拉伸显示图片，不保持原比例，填满ImageView.

android:scaleType=“fit_start” 
把原图按照比例放大缩小到ImageView的高度，显示在ImageView的start（前部/上部）。

android:sacleType=“fit_center” 
把原图按照比例放大缩小到ImageView的高度，显示在ImageView的center（中部/居中显示）。

android:scaleType=“fit_end” 
把原图按照比例放大缩小到ImageView的高度，显示在ImageVIew的end（后部/尾部/底部）

四、 代码测量适配
        在代码中使用Google提供的API对设备的屏幕宽度进行测量，然后按照需求进行设置。
对于当前控件的宽高设置，需要做的操作是首先要获取到该控件的父控件，使用父控件对当前控件的宽高进行设置操作！

五、 后台接口适配
        本地加载图片前判断手机分辨率或像素密度，向服务器请求对应级别图片。(这种想想也是可能性为零的,后台哪想给你弄这些玩意儿,除非自己包揽前后端,并且这种方式对用户流量消耗较大,不建议采用)

---

总之,根据自己需求操作,这些内容也只是作为一个技术理论层面学习,实际操作大家懂明白感受!
最后不得不吐槽一下,的书写格式真的是必Markdown还要Markdown,写得我也是心累,一大片的空格符!比起Markdown要逊色好多,差不多只是截取了部分书写格式,但绝对没有Markdown好用!

今天一天的写照.jpg