项目中使用到了多个values来进行适配的问题，想从根本上弄清楚系统在加载的时候，对文件夹取用策略的判断问题，用实际例子对比了一下swXXXdp与values-1920X1080和默认的values的加载其中的策略指定问题，混合模式下，系统对values的取用问题。
ok，开始吧。
添加values-1790X1080,values-1794X1076,values-1794X1080与values-sw361dp
前三个文件夹用来对比在跟屏幕真实分辨率相差一些数值的时候，系统会加载那个文件夹下的配置。
先用三个文件夹运行，观察结果：
当然是运行的完美契合的那个分辨率了，那么当我们在实际开发的时候，屏幕碎片化太大的时候，这种情况是可遇不可求的，故而需要去测试系统对与不完美契合的情况的处理，删除掉完美契合文件夹：
运行结果是：
加载到了1920X1148的values，那么说明在 1916X1152 与 1920X1148两个相近的宽高差值相同的文件夹中选择了高来进行优先选择，但是不能排除系统是把第一参数进行对比，而不是将values的匹配高进行优先匹配的，好吧，下面验证一下：
改名为：
运行结果：
加载的还是高匹配高的那个文件夹，那么结论：系统对不能完美匹配的values文件，遵循的是，宽高差值绝对值进行对比，如果宽高对于当前屏幕分辨率差值小的进行加载，如果当宽高绝对值差值相同的时候，以高匹配度高的values进行加载。
上面对比了在使用px来区分values的一些加载规则，那么当swXXXdp出现的时候，(sw----small width)小宽度概念，当系统的宽度dp值大于该值的时候，加载这套设置。
问题在于dp与px方式同时出现的时候，系统对于优先级的判定问题。下面进行判定：
加入混合的值文件夹：
运行结果：
google还是对dp情有独钟啊，1152/3= 384dp跟360还差那么多，要是在一个水平线上来进行对比的话，真真的应该加载1920X1152啊，完美适配的呢，说好的做彼此的天屎的，呸，天屎，算了。
但是不管google怎么优先级，从细分上来说，如果是为了适配smartbar这个坑的话，一般来说，用px的values-1920X1152方式来进行细分适配要更加的精确，更能完美处理掉这个问题，毕竟还是在同一个水平上来处理的。但是官方是推sw-XXXdp的。
综上所述：
values-swXXXdp > values-XXXXxXXXX > values ;
注： values-XXXXXxXXXXX 方式的时候，通过宽高跟屏幕分辨率的差值绝对值来进行对比，优先高。
