Google搞了一大套hdpi、xhdpi之类的这些东西，简单说来，就是为了让我们轻松实现“与设备密度无关的视觉大小一致性”，注意这里的“视觉大小一致性”，就是说无论是在手机、低分辨率平板、高分辨率平板上，一个控件或者一个图片在物理尺寸上都是一样大小的。
drawable目录：先高再第
我们经常会给应用程序切几套图片，放在drawable-mdpi、drawable-hdpi、drawable-xhdpi等目录下面。当应用在设备对应dpi目录下没有找到某个资源时，遵循“先高再低”原则，然后按比例缩放图片。
比如，当前为xhdpi设备，并且只有以下几个目录，则drawable的寻找顺序为：
xhdpi(2，当前设备对应的dpi)-->xxhdpi(3，比当前高的)-->xxxhdpi(如果没有更高的了)-->drawable-->hdpi(1.5，比当前低的)->mdpi(1.0，标准)，如果在xxhdpi中找到目标图片，则压缩2/3来使用，如果在mdpi中找到图片，则放大2倍来使用。
这很好理解，如果我们按规则放置两张图片，mdpi中为48x48，xxhdpi中为144x144，那么不管我们最后从哪个目录拿到图片，在xhdpi设备上显示的像素大小都是96x96，只是一个被拉伸而来，一个被压缩而来。由于xhdpi定义了96个像素点的物理尺寸，那么这张图的物理尺寸实际就被定下来了。
那么，一个结论就是，对于期望保持视觉大小一致的那部分图片而言，如果你也能接受android为你拉伸/压缩图片导致一定程度的模糊或者锐化，那么这些图片是不需要在每个drawable目录下都制作一份的。以现在主流设备来说一般可能在drawable-xxhdpi放置一份即可，这样可以尽量避免Android为我们放大图片所导致的OOM。
当然，在某些情况下，我们会主观希望打破android提供的“视觉大小一致”这种机制，此时我们就可以建立另外的drawable目录来放置需要变化的图片了。
values目录：就近匹配
那么，我们需要将mdpi目录下的值都乘以相应的倍数来放置在其他目录下面吗？
答案当然是否定的，由于我们对期望屏幕密度无关的值都定义为了dp单位，无论android从哪个目录最终找到该值，都会直接应用这个值与当前设备的密度来计算最终的尺寸。
那么，既然最后都要找到values，并且能够保证视觉大小一致性，那何必再添加其他values分辨率目录呢？答案是在某些情况下，我们主观希望某些尺寸不去保持视觉一致性。例如一个Button，在手机上那么大刚好，但如果在平板设备上，它还是和在手机上看起来一样大，那它就显得有点小了。
也就是说，我们应该把希望在任何设备上视觉大小都一样的尺寸都放置在values目录下并且只放置这一份，其他需要有变化的尺寸则放置在对应目录下即可。
更推荐采用values-xhdpi-2560x1600，我们很容易通过这里的屏幕分辨率+dpi计算得到该设备的物理尺寸，显而易见这是一个平板设备，如此我们的改动便不至于影响同DPI的低物理尺寸设备（手机），而物理尺寸差不多的设备是可以共用一套dimens.xml的。
那么，如果当前设备为xhdpi-1184x800，当前目录有values-xhdpi-1184x800，values-xhdpi-1184x960，values-xhdpi-1184x720，android的寻找顺序则是：
xhdpi-1184x800->values-xhdpi-1184x720->values-xhdpi
只向低于自己分辨率的目录下寻找，直到values-xhdpi，如果依然没有找到，按照之前的顺序继续进行。
也就是说，对于同dpi的多台不同分辨率平板设备，如果布局足够通用，我们可以只针对最低分辨率设计dimens即可，上面的例子中，则是values-xhdpi-1184x720。
我们还可以将这个分辨率写得更低，低到我们有把握：如果再出现比这个分辨率更低的设备，那么它的物理尺寸一定满足即使采用values-xhdpi中针对手机物理尺寸设计的大小也没有问题。