在今年年初，咱们公布了 Jetpack WindowManager 库 alpha02 版本，这是一个较为重大的版本更新，并且蕴含局部已弃用的 API (目前曾经公布到 1.0.0-alpha09 版)，本文将为您回顾这次版本更新的内容。
Jetpack WindowManager 库可帮忙您构建可能感知折叠和铰链等新设施性能的利用，应用以前不存在的新性能。在开发 Jetpack WindowManager 库时，咱们联合了开发者的反馈意见，并且在 Alpha 版本中继续迭代 API，以提供一个更洁净残缺的 API 界面。咱们始终在关注 WindowManager 空间中的不同畛域以提供更多的性能，咱们引入了 WindowMetrics，以便您能够在 Android 4.1 (API 级别 16) 及以上版本应用这些在 Android 11 退出的新 API。
首版公布后，咱们用了大量工夫来剖析开发者反馈，并在 alpha02 版本中进行了大量的更新，接下来咱们来看在 alpha02 版本中更新的具体内容！
新建一个 WindowManager
Alpha02 版本提供了一个简略的构造函数，这个构造函数只有一个参数，参数指向一个可见实体 (比方以后显示的 Activity) 的 Context:
val windowManager = WindowManager(context: Context)原有的构造函数 ) 仍可应用，但已被标记为废除:
@Deprecated
val windowManager = WindowManager(context: Context, windowBackend: WindowBackend?)当您想在一个常见的设施或模拟器上应用一个自定义的 WindowBackend 模仿一个可折叠设施时，可应用原有的构造函数进行测试。这个 样例工程 中的实现能够供您参考。
在 alpha02 版本，您仍可给参数 WindowBackend 传参为 null，咱们打算在将来的版本中将 WindowBackend 设置为必填参数，移除 deprecation 标记，以推动此接口在测试时应用。
增加 DisplayFeature 弃用 DeviceState
另一个重大变动是弃用了 DeviceState 类，同时也弃用了应用它告诉您利用的回调。之所以这样做，是因为咱们心愿提供更加通用的 API，这些通用的 API 容许零碎向您的利用返回所有可用的 DisplayFeature 实例，而不是定义全局的设施状态。咱们在 alpha06 的版本中曾经将 DeviceState 从公共 API 中移除，请改用 FoldingFeature。
alpha02 版本引入了带有更新了回调协定的新 DisplayFeature 类，以在 DisplayFeature 更改时告诉您的利用。您能够注册、反注册回调来应用这些办法:
registerLayoutChangeCallback(@NonNull Executor executor, @NonNull Consumer<WindowLayoutInfo> callback)
unregisterLayoutChangeCallback(@NonNull Consumer<WindowLayoutInfo> callback)WindowLayoutInfo 蕴含了位于 window 内的 DisplayFeature 实例列表。
FoldingFeature 类实现了 DisplayFeature 接口，其中蕴含了无关下列类型性能的信息:
TYPE_FOLD（折叠类型）TYPE_HINGE（铰链类型）设施可能的折叠状态如下:
△ DisplayFeature 可能的状态: 齐全开展、半开、翻转
须要留神的是这里没有与 DeviceState 中 POSTURE_UNKNOWN 和 POSTURE_CLOSED 姿势对应的状态。
要获取最新的状态信息，您能够应用已注册回调返回的 FoldingFeature 信息:
class LayoutStateChangeCallback : Consumer<WindowLayoutInfo> {override fun accept(newLayoutInfo: WindowLayoutInfo) {// 查看 newLayoutInfo. getDisplayFeatures() 的返回值，// 看它是否为 FoldingFeature 实例，并获取其中的信息。}
}如何应用这些信息，请参阅: https://github.com/android/user-interface-samples/tree/main/WindowManager。
更好的回调注册
上述示例代码的回调 API 也更加强壮了。在之前版本中，如果利用在 window 可用之前注册回调，将会抛出异样。
在 aplha02 版本中咱们批改了上述的行为。您可在对您利用设计有用的任何时候，注册这些回调，库会在 window 可用时发送初始 WindowLayoutInfo。
R8 规定
咱们在库中增加了 R8 的 “keep” 规定，以保留那些因为外部模块的组织架构而可能被删除的办法或类。这些规定会主动合并到利用最终的 R8 规定中，这样能够避免利用呈现如 alpha01 版本上的解体。
WindowMetrics
因为历史的命名习惯和各种可能的 Window Manager 状态，在 Android 上获取以后 window 的尺寸信息比拟艰难。Android 11 中一些被废除的办法 (例如 Display#getSize 和 Display#getMetrics) 和在 window 尺寸新的 API 的应用，都凸显了可折叠设施从全屏到多窗口和自适应窗口这一回升的趋势。为了简化这一过渡过程，咱们在 Android 11 中减少了 WindowMetrics API。
在第一次布局实现之前，WindowMetrics 能够让您轻松获取以后 window 状态信息，和零碎以后状态下最大 Window 尺寸信息。例如像 Surface Duo 这样的设施，设施会有一个默认的配置决定利用从哪一个屏幕启动，然而也能够跨过设施的铰链扩大到两块屏幕上。在默认的状态，’getMaximumWindowMetrics’ 办法返回利用以后所在屏幕的边界信息。当利用被挪动到处于跨屏状态，’getMaximumWindowMetrics’ 办法返回反映新状态的边界信息。这些信息最早在 onCreate 期间就会提供，您的 Activity 能够利用这些信息进行计算或者尽早做出决定，以便在第一工夫抉择正确的布局。
API 返回的后果不包含零碎 inset 信息，比方状态栏或导航栏，这是因为目前反对的所有 Android 版本中，在第一次布局实现之前，这些值对应的区域都不可用。对于应用 ViewCompat 去获取零碎可用 inset 信息，Chris Banes 的文章 – 解决视觉抵触|手势导航 (二) 是十分好的资源。API 返回的边界信息也不会对布局填充时可能发生变化的布局参数作出响应。
要拜访这些 API，您须要像上文阐明的那样先获取一个 WindowManager 对象:
val windowManager = WindowManager(context: Context)当初您就能够拜访 WindowMetrics API，并可轻松获取以后 window 的尺寸以及最大尺寸信息。
windowManager.currentWindowMetrics
windowManager.maximumWindowMetrics例如，如果您的利用在手机和平板电脑上的布局或导航模式截然不同，那么能够在视图填充之前依赖此信息对布局做出抉择。如果您认为用户会对布局的显著变动感到纳闷，您能够疏忽以后 window 尺寸信息的变动，抉择局部信息作为常量。在抉择填充哪些之前，您能够应用 window 最大尺寸信息。
只管 Android 11 平台曾经蕴含了在 onCreate 期间获取 inset 信息的 API，然而咱们还没有将这个 API 增加到 WindowManager 库中，这是因为咱们想理解这些性能中哪些对开发者有用。您能够踊跃反馈，以便咱们理解在您第一次布局之前，须要晓得哪些可能使编写布局更为简便的值或形象。
咱们心愿这些能够用在 Android 低版本上的 API 可能帮忙您构建响应 window 尺寸变动的利用，同时帮忙您替换上文提到的已废除 API。
分割咱们
咱们十分心愿失去您对这些 API 的反馈，尤其是您认为短少的那些，或者可让您开发变得更轻松的那些反馈。有一些应用场景咱们可能没有思考到，所以心愿您在 public tracker 上向咱们提交 bug 或性能需要。