Android多分辨率适配框架（1）— 核心基础

探索Android软键盘的疑难杂症
深入探讨Android异步精髓Handler
详解Android主流框架不可或缺的基石
站在源码的肩膀上全解Scroller工作机制

Android多分辨率适配框架（1）— 核心基础
Android多分辨率适配框架（2）— 原理剖析
Android多分辨率适配框架（3）— 使用指南

自定义View系列教程00–推翻自己和过往，重学自定义View
自定义View系列教程01–常用工具介绍
自定义View系列教程02–onMeasure源码详尽分析
自定义View系列教程03–onLayout源码详尽分析
自定义View系列教程04–Draw源码分析及其实践
自定义View系列教程05–示例分析
自定义View系列教程06–详解View的Touch事件处理
自定义View系列教程07–详解ViewGroup分发Touch事件
自定义View系列教程08–滑动冲突的产生及其处理

PS：Android多分辨率适配框架视频教程同步更新啦

前言

Android的源码公开策略丰富了手持设备的多样性，但随之而来的却是较为严重的”碎片化”——版本繁多、尺寸多样、功能定制。在Android项目开发中，软件工程师都会面临一个问题：如何适配多不同分辨率的设备/p>

许多人采用的是这样的方式：利用不同的dimens和drawable资源适配不同分辨率的设备。这么做当然没错，可是它也同时带来一些弊端

• 在调试UI时挨个修改多个dimen文件中的每个值。
  多数时候会先做一个分辨率出来，比如1920*1080；然后再对照这个效果适配其他分辨率的展示效果。如果要调整某个尺寸的大小，那么先要找到其对应的dimens文件，再去修改。
• UI标注的困惑
  UI设计师一般只会在一套UI上标注具体的尺寸大小和颜色。比如，只在1920*1080上标注了一个TextView的长度是100px，那么在1280*720上的分辨率上该控件的大小又该是多少呢己再换算一下/li>
• 多套drawable容易导致APK文件较大。
  图片多了，那么资源所占的体积必然会随之增大；在发布前为了减小APK的大小，可能又不得不做一些瘦身的操作，至于效果有时也觉得不痛不痒，乏善可陈。
• 不同drawable资源带来的繁琐
  如果某个切图需要修改，那么就需要替换各个drawable中对应的图片。这个过程中，如果错放了或者漏放了某个尺寸的图片，那么又是一个小悲剧了，它会导致图片在某些分辨率的手机上失真

嗯哼，毫不避讳的说：以上这些坑我都掉进去过，有的坑还有点深，快到我脖子了。
踩了几次坑之后，我多么希望有这么一个框架：一套图片，一套布局，一个dimen完成多分辨率的适配！

在此期盼下，三年前，我开始了第一次尝试：

在此以华为P7为例，解释inch、px、pt、dpi、dip、densityDpi、TypedValue、sp等等Android中常见的度量单位

inch

inch即为英寸，它表示设备的物理屏幕的对角线长度。
比如该例中P7的屏幕尺寸为5英寸，表示的就是手机的右上角与左下角之间的距离，其中1 inch = 2.54 cm

px

pixel简称为px，它表示屏幕的像素，也就是大家常说的屏幕分辨率。
比如在该例中P7的分辨率为1920*1080，它表示屏幕的X方向上有1080个像素，Y方向上有1920个像素。

pt

pt类似于px，但常用于字体的单位，不再赘述

dpi和densityDpi

dot per inch简称为dpi，它表示每英寸上的像素点个数，所以它也常为屏幕密度。
在Android中使用DisplayMetrics中的densityDpi字段表示该值，并且不少文档中常用dpi来简化或者指代densityDpi。

在手机屏幕一定的情况下，如果分辨率越高那么该值则越大，这就意味着画面越清晰、细腻和逼真。
在此，仍然以华为P7为例，计算其dpi值。先利用勾股定理得其对角线的像素值为2202.91，再除以对角线的大小5，即2202.91/5=440.582；此处计算出的440.582便是该设备的屏幕密度。

Android中依据densityDpi的不同将设备分成了多个显示级别：
ldpi、mdpi、hdpi、xhdpi、xxhdpi
这些显示级别分别表示一定范围的dpi，比如160dpi—240dpi都称为hdpi，更多详情请参见下图。

例如：在布局中指定了某个控件的高为100dp，那么它在ldpi的手机上高为75px，在mdpi的手机上高为100px，在xhdpi手机上高为200px；以此类推，其高在不同屏幕中显示的比例保持了一致

sp

scale-independent pixel简称为sp，它类似于dp，但主要用于表示字体的大小，不再赘述

TypedValue
刚才提到，依据densityDpi的不同将设备分成了多个显示级别：ldpi、mdpi、hdpi、xhdpi、xxhdpi。看到这句话时想必很多人都觉得这个玩意太眼熟了，在res下不是有drawable-ldpi、drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi、drawable-xxxdpi文件夹么的，但是它们有什么联系么
之前也说了：Android设备千差万别，不同设备的屏幕密度(densityDpi)自然也就各不相同，有的属于mdpi，某些又属于xhdpi，或者xxhdpi等等其他显示级别。设计师为了让同一个APP在各种手机上都获得较好的显示效果就会针对densityDpi的不同而单独提供一套UI图。
比如，客户要求APP适配显示级别为：ldpi、mdpi、hdpi、xhdpi、xxhdpi的设备，那么UI设计师就需要5套尺寸不一的UI图分别放入res下的drawable-ldpi、drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi文件夹里。当手机设备的显示级别为hdpi时，此时APP会去加载drawable-hdpi中对应图片；同理如果手机的显示级别为xxhdpi那么APP就会去自动加载drawable-xxhdpi中的资源图片。

关于此处的这种对应关系，我们再来看一段代码：

在此，我们可以发现：
如果将图片放入drawable-ldpi，则其TypedValue.density 的值为120
如果将图片放入drawable-mdpi，则其TypedValue.density的值为160

类似地操作总结如下图：

该方法的作用是把Android系统中的非标准度量尺寸(比如dip、sp、pt等)转变为标准度量尺寸px。在这段代码里，同样可以见到一个density；但是请注意它是DisplayMetrics中的字段而不是TypedValue的，请注意区分。

探究drawable图片的加载

这得从一次掉坑的经历说起。

有天下午，都快下班了，测试妹子跑到我工位前，急匆匆地说：图片失真了。哎，又不是失身，急啥嘛。我慢条斯理地瞅瞅了代码：代码没错呀，以前也都是这些的呀。到底是哪里出了幺蛾子呢过一番排查，发现是图片放错了地方：本来是该放到drawable-xxhdpi中的但是小手一抖错放到了drawable-xhdpi中导致了图片放大失真。

嗯哼，这个坑我们可能自己踩过，或者说这个现象我们略知一二，但是导致这个现象的原因是什么呢的背后隐藏着什么呢/p>

来吧，一起瞅瞅。

在此，准备了一张图，该图就是我的CSDN博客头像

最后，在Java代码中获取图片的宽高及其所占内存的大小，代码如下：

输出结果如下：
width=144，height=180，byteCount=103680
嗯哼，获取到的图片宽高和其原本的宽高一致。那么这个byteCount又是怎么算出来的呢
Android系统在利用drawable中的图片生成Bitmap时默认采用的色彩模式是Bitmap.Config.ARGB_8888；在该模式中一共有四个通道，其中A表示Alpha，R表示Red，G表示Green，B表示Blue；并且这四个通道每个各占8位即一个字节，所以合起来共计4个字节。于是可以算出：144*180*4=103680字节

现在将图片移至drawable-hdpi中，运行后查看效果：

输出结果如下：
width=576，height=720，byteCount=1658880
这就更明显了，图片的宽和高都变大了4倍，图片所占的内存大小也随之变大了16倍。

嗯哼，如果将图片放入drawable-mdpi，drawable-xhdpi，drawable-xxxhdpi中也会发现类似的现象：图片的宽高及其所占内存在按照比例放大或者缩小，详情请参见下图

在该方法中第6行调用openRawResource()后，value中就保存了该资源所在文件夹的destiny，这点和刚才的讲解是一致的，不再赘述。在此之后，继续执行decodeResourceStream()