Dimension就是Android里的尺度标准了，其实呢，世界上本来有很多度量衡的，比如说我们常用的公制度量衡，还有英制度量衡，可能还有等等。。。
Android机型众多，分辨率，尺寸，形状（没错，Android系统还考虑过非规则显示屏）各异，这对于Android系统设计而言是一个挑战。对于一个实际的应用程序来说，怎么知道具体的设备多长多粗(*/ω＼*)呢。
确实呢，这不太好解决哦。然而，Google还是想到了一个办法。
Android面向应用开发呢，提出了一个叫做dip的长度单位；
而Android面向设备呢，要求它声明自己的xdpi和ydpi（注意，并不是dpi）。
废话不多说，直接切入Android代码了解下Dimension的那些事儿。主要的两个嘉宾是来自android.util的TypedValue和DisplayMetrics。这两个类比较简单，加起来代码也才800+行，中间很大篇幅还是注释。
TypedValue
TypedValue算是Android自己的用于Dimension换算的工具类，它有很多方法，其中的complexToDimensionPixelSize(int data, DisplayMetrics metrics)甚至在View的构造方法中用于解析xml中的长度值，可见TypedValue的可靠程度。然而，我们把注意力放在它的另一个方法applyDimension(int unit, float value, DisplayMetrics metrics)，这个方法的作用是把单位为px，dp，sp，pt（什么鬼？），in（什么鬼？），mm（什么鬼？）的长度换算到以px为单位的长度，全部代码如下：
/**
* Converts an unpacked complex data value holding a dimension to its final floating
* point value. The two parameters <var>unit</var> and <var>value</var>
* are as in {@link #TYPE_DIMENSION}.
*
* @param unit The unit to convert from.
* @param value The value to apply the unit to.
* @param metrics Current display metrics to use in the conversion --
* supplies display density and scaling information.
*
* @return The complex floating point value multiplied by the appropriate
* metrics depending on its unit.
*/
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;
}
这段代码的可读性已经简单到了相当的程度，我都不好意思多看一眼(///▽///)。然而，这确确实实是Android自己的代码，这时候，我又审视了一遍自己的态度，并不是越花哨的代码越好，而是越好的代码越“花哨”（看人家的注释，眉飞色舞！）。
这个方法推荐大家反复使用，因为同样的方法我们自己不能写得更简洁、更好。
这个方法中最有内涵的莫过于这一部分了啊：
好的，到了这里，除了pt，in，mm不明所以外差不多都懂了啊，而上图又都指向了另一个类DisplayMetrics。先草草地中断下TypedValue的了解，看看DisplayMetrics是个什么鬼。
DisplayMetrics
关于DisplayMetrics呢，有人说用了很多次了，可谓是花式编程不胜枚举。然而，会用就算了解了吗？（OS[注]：废话，都会用了，还有啥好了解的）
笔者个人认为，对于DisplayMetrics，我们了解的再多可能也不见得够啊。
刚才在TypedValue当中，我们见识了DisplayMetrics的三个成员，分别是density，scaledDensity和xdpi。头两个大家可能也认识，最后一个就蒙哔了对不对，啊~~
我们先简单的看一下，这几个成员的代码：
/**
* The logical density of the display. This is a scaling factor for the
* Density Independent Pixel unit, where one DIP is one pixel on an
* approximately 160 dpi screen (for example a 240x320, 1.5"x2" screen),
* providing the baseline of the system's display. Thus on a 160dpi screen
* this density value will be 1; on a 120 dpi screen it would be .75; etc.
*
* <p>This value does not exactly follow the real screen size (as given by
* {@link #xdpi} and {@link #ydpi}, but rather is used to scale the size of
* the overall UI in steps based on gross changes in the display dpi. For
* example, a 240x320 screen will have a density of 1 even if its width is
* 1.8", 1.3", etc. However, if the screen resolution is increased to
* 320x480 but the screen size remained 1.5"x2" then the density would be
* increased (probably to 1.5).
*
* @see #DENSITY_DEFAULT
*/
public float density;
/**
* A scaling factor for fonts displayed on the display. This is the same
* as {@link #density}, except that it may be adjusted in smaller
* increments at runtime based on a user preference for the font size.
*/
public float scaledDensity;
/**
* The exact physical pixels per inch of the screen in the X dimension.
*/
public float xdpi;
看完这仨的注释，我就奔溃了，真™越短越难啊。什么鬼？关键是代码里怎么还有个ydpi：
/**
* The exact physical pixels per inch of the screen in the Y dimension.
*/
public float ydpi;
这些东西究竟是干嘛的？猴子请来的逗哔么？
我抄起手边的一台手机，洋洋洒洒码了几行代码，读了读这几个量，结果如下：
图中的density dpi是我看见DisplayMetrics里的成员densityDpi时，不自禁打粗来的：
/**
* The screen density expressed as dots-per-inch. May be either
* {@link #DENSITY_LOW}, {@link #DENSITY_MEDIUM}, or {@link #DENSITY_HIGH}.
*/
public int densityDpi;
反正都不懂，不在乎多一个。
好了，到这里，我陷入了深深地思考“为什么我要了解这么深，这不是有病吗？”然而答案是否定的。
经过了艰苦卓绝的努力和试验和思考后，我得出了一些结论：
The End
人家说结束不过是另一个开始而已。嗯，确实呢，能看到这里首先谢谢各位的耐心。然而，一个好（坏？）消息是，我们终于要开始（手动斜眼）介绍Android应对众多形态各异的设备的手段了。。。
刚才的测试中，density和scaledDensity只是简单的dp，sp到px的换算比例而已，这是谁都知道的东西。它们都是3.0，说明1dp==3px，1sp==3px。但是，这个比例值3.0是如何决定的呢？嗯，这就要看density的注释中的那段话了，它说“如果densityDpi的值是160dpi的若干倍，那么density就是这个倍数了”（笔者英文不好，译得比较糙，不服你打我啊ヽ(｀⌒´)ノ）。
然而，density注释里又有一些呓语“一个240*320的屏幕即便1.8寸或1.3寸宽，density也可以是1”。这是怎么个情况呢？我一开始也晕，后来发现了蹊跷（此处阴险表情）。请大家注意下咯，我文中测试的手机显示densityDpi是480，而我其实也测了另外一台手机（此处阴险表情again）：
这台手机呢，也是480的densityDpi。然而，事实上，虽然两台手机的分辨率是一样的（1920*1080），尺寸却分别是5.0寸和5.2寸。到这里我想起了那句呓语，又于是联想到这么几点：
- 市场上确实存在分辨率相同但是尺寸有差异的手机，这些手机的densityDpi和density又恰巧一致；
- 对于程序猿而言，我们用到的density，scaledDensity和densityDpi很多，用到的xdpi，ydpi很少；
- xdpi，ydpi的注释表明它们才是实际的每英寸像素点数（这也是为啥两个手机的xdpi，ydpi会有明显差异的原因）。
综上，Google的意图大概可以这么解释：
- Google希望Android表达相同的内容在5.0寸和5.2寸的手机上所呈现的比例是接近的，而又不能增加程序猿的工作量，那么，就呈现相同的dpi而程序猿看好了，这就是为什么densityDpi相同的原因，因为，densityDpi相同就基本保证了内容显示比例的相同。
- 实际上的手机尺寸必然有差异，对于差异小的手机，统一到同一densityDpi，差异大的话，就可以区分开比如xxhdpi或hdpi的密度设定了（上述的两个手机的xdpi，ydpi都是比较高的，归到xhdpi（320dpi）不如归到xxhdpi（480dpi），所以densityDpi都显示为480了）。
- 如果一定要显示特定的物理长度的话，那么，density显然是做不到的，这时候xdpi和ydpi就能起到作用了。这也是为什么xdpi可以计算出in（英寸），mm（毫米）和pt（point，这是一个概念，这个点的尺寸在不同手机是等长的）。
可以想到，运行在有相同密度的不同尺寸的手机上时，Android面向程序猿是无差别的dp长度，程序猿可以肆意地设计内容，而不需要做什么适配。但是由于densityDpi和xdpi，ydpi的实际差别，可以想到Android系统在把一堆dp设定的内容映射为实际显示的屏幕内容的过程中，一定有基于densityDpi与xdpi，ydpi比例的换算过程。使得同一个显示对象，在相同密度不同尺寸的手机上，拥有相同的高宽像素数，却有不同的物理长度。
总结，density，densityDpi，scaledDensity是面向内容的长度单位（对程序猿友好，便于表达内容），xdpi，ydpi是面向实际设备的参数（这是个连接了物理世界度量衡和Android度量衡的数值）。
PS：
我用上文的技术做了一个直尺的应用，但是，由于实际的手机xdpi和ydpi值居然不相等，所以，显示横向的尺度相对来说是比较准确的，显示纵向的尺度就不太准了（因为我用TypedValue中MM的单位获取长度，而这个方法又是采用了xdpi来实现的，如果纵向绘制尺子的话，实际上得用ydpi来实现才对，不该用xdpi来做，除非xdpi和ydpi是相等的，而ydpi和xdpi不相等就会导致纵向绘制出现偏差，这个问题后续可改正）。
注：
OS是overlapping sound的简称，即内心独白，不是operating system！！
