Add screenWidthDp and screenHeightDp support.

[xxjy]

在使用BasePopup这个库时发现的兼容性问题。
控件树测量过程中，如果Window设置了WRAP_CONTENT（一般在弹窗会这样设置），
ViewRootImpl.performTraversals会使用screenWidthDp、screenHeightDp作为测量值，
DecorView得到的测量结果和窗体的大小不一致，这时会用窗体的大小作为测量值再performMeasure一次。
正常情况下是没有问题的，在这个库中修改了DecorView的测量，使用screenWidthDp、screenHeightDp不正确的值测量时，DecorView得到了正确的测量结果（指的是和窗体大小一致），导致没有再测量一次，而这时DecorView的子View是用不正确的值测量出来的，出现适配问题。

假如一开始就使用正确的screenWidthDp、screenHeightDp就没有问题，所以修改了代码。

代码增加了isSupportScreenSizeDP字段，控制Configuration中的screenWidthDp和screenHeightDp适配，默认不开启。
当然这个设置也要isSupportSP为true的情况下才有效。

[JessYanCoding]

我大概理解了这个 pr 意思，你看我再复述一遍，看看我是否完全理解了你这次 pr 的用意:

configuration.screenWidthDp 是一个设备最初始的默认值，比如在一个分辨率为 1920 x 1080，density 为 3 的屏幕上，configuration.screenWidthDp 就为 640

AndroidAutoSize 会根据当前设备和设计图的情况修改 density，比如说现在 density 被 AndroidAutoSize 从 3 修改为了 4，这时如果按照 density 为 4 来计算 screenWidthDp，那 screenWidthDp 就应该为 480（1920/4），但是 configuration.screenWidthDp 不会根据 density 的改变而改变，这时 configuration.screenWidthDp 仍然为 640

你遇到的问题就是，如果 configuration.screenWidthDp 不根据 density 的改变，就会影响一些三方库的屏幕适配效果。

这个 PR 的用意就是想让 configuration.screenWidthDp 也能跟随 density 的改变而改变，让 configuration.screenWidthDp 随时保持和设计图的尺寸一致

虽然这里加了一个开关，但我的疑虑就是，如果打开这个功能的情况下，修改 configuration.screenWidthDp 是否会影响更多其他三方库和系统控件，这个功能是否只是为了适配 BasePopup 这一个库

[JessYanCoding]

我的疑虑主要来自于修改 configuration.screenWidthDp 带来的收益是否大于带来的影响，因为 configuration.screenWidthDp 和 density 都是全局的，修改后必然会影响其他三方库或者系统，因此我才退出了 副单位，所以我想问下修改 configuration.screenWidthDp 除了上文中提到的好处，还可以带来哪些好处，又会带来哪些已知的问题呢

[xxjy]

我大概理解了这个 pr 意思，你看我再复述一遍，看看我是否完全理解了你这次 pr 的用意:

configuration.screenWidthDp 是一个设备最初始的默认值，比如在一个分辨率为 1920 x 1080，density 为 3 的屏幕上，configuration.screenWidthDp 就为 640

AndroidAutoSize 会根据当前设备和设计图的情况修改 density，比如说现在 density 被 AndroidAutoSize 从 3 修改为了 4，这时如果按照 density 为 4 来计算 screenWidthDp，那 screenWidthDp 就应该为 480（1920/4），但是 configuration.screenWidthDp 不会根据 density 的改变而改变，这时 configuration.screenWidthDp 仍然为 640

你遇到的问题就是，如果 configuration.screenWidthDp 不根据 density 的改变，就会影响一些三方库的屏幕适配效果。

这个 PR 的用意就是想让 configuration.screenWidthDp 也能跟随 density 的改变而改变，让 configuration.screenWidthDp 随时保持和设计图的尺寸一致

虽然这里加了一个开关，但我的疑虑就是，如果打开这个功能的情况下，修改 configuration.screenWidthDp 是否会影响更多其他三方库和系统控件，这个功能是否只是为了适配 BasePopup 这一个库

这个pr的用意就和你理解的一样。

对于其他第三方库应该没有影响，configuration.screenWidthDp很少用到，一般获取屏幕大小不会使用这个参数，BasePopup这个库也没有用到。

对于系统控件的影响做了些搜索，主要是 ViewRootImpl用到了。

我觉得使用configuration.screenWidthDp这个参数目的就是要获取屏幕大小的，修改 density，不修改screenWidthDp，获取的值肯定是错误的。

之前没有类似的兼容性问题，主要是screenWidthDp用的少。ViewRootImpl用到了，但是在正常情况下又会重新测量一次，所以没有出现兼容性问题。

[xxjy]

我的疑虑主要来自于修改 configuration.screenWidthDp 带来的收益是否大于带来的影响，因为 configuration.screenWidthDp 和 density 都是全局的，修改后必然会影响其他三方库或者系统，因此我才退出了 副单位，所以我想问下修改 configuration.screenWidthDp 除了上文中提到的好处，还可以带来哪些好处，又会带来哪些已知的问题呢

目前我在项目改了，暂时没发现问题。

好处我觉得可能是开发者用到screenWidthDp 这个参数，就是要拿屏幕大小，修改 density，不修改screenWidthDp，开发者拿到的值肯定是跟自己预想的不一样。

[JessYanCoding]

我在想，如果三方库作者能依据 screenWidthDp 进行适配，并且 AndroidAutoSize 能根据修改 density 的情况提供正确的 screenWidthDp，那不是就能解决宿主项目和三方库项目设计图尺寸不一致的问题（三方库项目获取到的 screenWidthDp、screenHeightDp 就是设计图尺寸）

[xxjy]

我在想，如果三方库作者能依据 screenWidthDp 进行适配，并且 AndroidAutoSize 能根据修改 density 的情况提供正确的 screenWidthDp，那不是就能解决宿主项目和三方库项目设计图尺寸不一致的问题（三方库项目获取到的 screenWidthDp、screenHeightDp 就是设计图尺寸）

是的，这个修改就是为了提供正确的 screenWidthDp，screenWidthDp、screenHeightDp 某一个值就是设计图尺寸。

[JessYanCoding]

好的，这里我自己在想想是能不能提供给三方库一些可适配的方案。
感谢你对开源的贡献，你的代码写的非常规范，点赞。