前言

随着近年来手机行业的飞速发展，手机从功能机进入到智能机，手机屏幕占比也随着技术和系统的进步越来越大，特别是Android 10推出以后，折叠屏逐渐成为Android手机发展的趋势。

图 1 Android手机屏幕发展趋势

京东小程序近年来也支持了越来越多的业务和应用，做好小程序的折叠屏的适配也是符合未来的发展趋势，能为用户和业务方提供更好的体验和价值。

Android应用折叠屏适配摘要

应用在折叠屏运行时，可以从一个屏幕切换到另一个屏幕。应用应该做好配置变更的适配和界面状态的保存，以保证应用当前任务能无缝迁移到转换后的屏幕，从而为用户提供出色的连续性体验。

1.resizeableActivity

默认情况下，Activity resizableActivity 属性为 true，系统假定该应用完全支持多窗口并且可调整大小。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nqkGCPeN-1683514750533)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/be079d2f136e4818a7cd945a6332e3c8~tplv-k3u1fbpfcp-zoom-1.image)]

图 2 Android手机折叠屏

如果您不希望自己的应用在多窗口模式下调整大小，你可以设置Activity resizableActivity 属性为false，系统会将应用置于兼容模式。某些原始设备制造商 (OEM) 可能会实施一项功能，即每当 Activity 的显示区域发生更改时，都会在屏幕上添加一个小型重启图标。这为用户提供了在新配置中重启 Activity 的机会。下图示例展示了一次内屏到外屏，外屏到内屏切换中系统相关处理。

图 3 折叠屏应用重启示例

此外，用户需要“设置”-“显示”中打开应用的“在外屏上继续使用应用程序”开关，否则，切换到外屏时系统将回到锁屏界面，应用会被压至后台。不支持resize的应用会无法打开此开关。

图 4 Android折叠屏展示开关

2.屏幕宽高比

Android 10 (API 级别 29) 或更高版本支持更多种宽高比。对于可折叠设备而言，设备类型可以是超长、超薄的屏幕（例如屏幕宽高比为 21:9 的折叠设备），也可以是 1:1 的屏幕。

如要与尽可能多的设备兼容，您应该尽量多针对以下屏幕宽高比测试自己的应用:

图 5 Android手机屏幕宽高比

如果无法支持上述某些高宽比，您可以使用 maxAspectRatio（同之前一样）以及 minAspectRatio 来指明自己应用可以处理的最高宽高比和最低宽高比。如果屏幕宽高比超出这些限制，应用可能会进入兼容模式。

3.处理配置变更

某些设备配置可能会在运行时发生变化（例如屏幕方向、键盘可用性，以及当用户启用多窗口模式时）。发生这种变化时，Android 会重启正在运行的 Activity（先后调用 onDestroy() 和 onCreate()）。重启行为旨在通过利用与新设备配置相匹配的备用资源来自动重新加载您的应用，从而帮助它适应新配置。

如要妥善处理重启行为，Activity 必须恢复其先前的状态。您可以同时使用 onSaveInstanceState()、ViewModel 对象以及持久存储，以在配置变更时保存并恢复 Activity 的界面状态。

然而，您可能会遇到这种情况：重启应用并恢复大量数据不仅成本高昂，而且会造成糟糕的用户体验。在此情况下，我们通常可以自行处理配置变更，以避免系统资源变更引起Activity重启，通过在标签中添加android:configChanges声明实现。android:configChanges 属性文档中列出该属性的可能值。最常用的值包括 “orientation”、“screenSize” 和 "keyboardHidden” 等。

总之，为了做好Android应用的折叠屏适配，应用应能妥善地保存界面状态和支持配置变更，并进行详细的测试，详细适配指导方案可以参考官方文档。

小程序折叠屏适配现状

小程序不同于原生的Android应用，微信小程序框架目前是基于webview渲染，小程序逻辑层、视图层等进行相关视图、组件的计算渲染时依赖于获取到的设备尺寸数据，当屏幕尺寸发生变化时，不可避免的会造成布局样式的错乱。小程序业内目前还没有官方的折叠屏适配方案。以健康宝微信小程序为例，发生折叠后，不仅界面上存在问题，还存在无法从历史任务栈中打开的问题。

图 6 微信应用Android手机折叠屏效果

此外，从微信开发社区我们了解到，有不少开发者对于小程序折叠屏适配还是有诉求的。

图 7 微信小程序折叠屏适配诉求

京东小程序折叠屏适配

1.京东小程序折叠屏问题

京东小程序也存在元素尺寸不合适、折叠后无法从任务栈中再次打开等问题，我们看一下京东快递小程序的现象。

图 8 京东小程序适配前

内屏打开小程序状态：

图 9 京东小程序适配前-内屏

内屏转外屏状态：

图 10 京东小程序适配前-内屏转外屏

外屏打开小程序状态：

图 11 京东小程序适配前-外屏

外屏转内屏状态：

图 12 京东小程序适配前-外屏转内屏

总之，就是在无论是内屏还是外屏，初次打开时获取到的屏幕尺寸数据是对的，小程序能按照适合的尺寸渲染元素；一旦发生折叠，在新的状态要么是元素过大不适合窄屏，要么是元素过小不适合宽屏。

那么问题来了，为什么在初试打开状态页面上的元素是大小合适的呢？

2.小程序多屏幕适配

rpx （ responsive pixel）响应单位

rpx是微信小程序独有的、解决屏幕自适应的尺寸单位，在小程序开发中，推荐使用rpx这种响应式的像素单位进行开发

可以根据屏幕宽度进行自适应，不论大小屏幕，规定屏幕宽为750rpx，以 iPhone6 为基准，iPhone6 的屏幕宽度为 375px，则 750rpx = 375px

真实设备获取到的物理像素是多种多样的，在小程序内部通过真实物理像素与375的比值得到缩放比例，真正渲染使用时再转换为对应的像素，通过 rpx 设置元素和字体的大小，小程序在不同尺寸的屏幕下，可以实现自动适配。

3.折叠屏问题分析

元素尺寸问题：

在折叠屏展开状态打开小程序，此时取到的设备尺寸等均为展开时的数据，屏幕折叠后，元素大小没有发生变化，但是承载小程序的容器大小变化了，屏幕变窄了，于是按照原有的尺寸，所有的布局空间发生压缩，导致页面挤压在一起。

同样的，在外屏打开小程序时获取到的尺寸数据是适合外屏的，再折叠到内屏状态时也无法及时更新到内屏的尺寸。

究其原因，在发生屏幕折叠时，小程序没有获取到最新的屏幕数据，无法更新屏幕缩放比，同时没有机制通知小程序进行重新渲染或加载。

无法重启问题：

小程序在Android端运行在独立的进程中，不同小程序运行在不同进程，小程序引擎具有自己独有的管理机制。在之前屏幕折叠后小程序被杀死进程，通过历史任务栈无法再次拉起该进程。

4.解决思路

监听屏幕折叠：

1.记录当前屏幕参数（宽、高、方向）

2.在onConfigurationChanged(Configuration newConfig)回调中获取最新屏幕配置

当屏幕发生折叠后，系统会将newConfig下发给应用程序，取出newConfig.orientation 、newConfig.screenWidthDp 和 newConfig.screenHeightDp ，与之前保存的屏幕参数进行对比。如果宽、高发生变化，通常认为屏幕发生折叠。

3.细节处理

a.由于视屏播放器全屏状态下通常会是横屏状态，当从全屏状态切回正常模式时往往会回到竖屏，这里屏幕的 orientation 会与之前的不同，不能当做折叠处理。

b.折叠屏手机屏幕往往底部还有一个最近应用的快捷导航条，如果是开启状态，因为需要重汇的缘故，在发生折叠后，系统会触发两次onConfigurationChanged(Configuration newConfig)回调，而且两次回调的参数中 newConfig.screenHeightDp 会前后不一致，这里需要做一下兼容处理，否则会误判为多次折叠。

图 13 折叠屏导航条

图 14 折叠屏导航条2

不同的底部导航条

元素尺寸问题：

要解决此问题，就要在识别到屏幕尺寸发生变化时，及时通知到业务，有两种方案：

1.局部刷新：通知业务自行刷新

这种方案可以在一定程度上保留用户操作流程的完整，但是也存在非当前页面无法刷新或者或退后再次刷新等问题，对用户来说体验一般，而且需要小程序业务的开发者来监听页面变化，增加了开发者的业务复杂度。

2.整体刷新：重启小程序

这种方案是客户端引擎监听到设备发生折叠时，关闭小程序，并进行重新打开。可以很好地保障页面的重新适配，重启行为会对用户操作流程完整性有一定的损伤，对小程序开发者来说没有工作量。

无法重启问题：

针对此问题，引擎侧需要避免杀死小程序所在进程，同时结合上面 2 个页面刷新方案，综合考虑，采用在当前进程整体刷新、重启小程序方案。一方面解决了历史任务栈无法重启问题，另一方面避免了创建新进程的开销，界面上给人的感官也更流程。

5.遇到的问题及解决方案

1.multiWindow、pictureInPicture问题

Android系统还有两个功能就是多窗口和画中画模式，activity可以缩放为一个小窗口，在屏幕中显示一小块区域，能够很灵活的拉伸缩放，对于此，小程序引擎忽略了窗口大小的变化，否则用户只要一缩放就会重启小程序，这是我们和用户都无法接受的。这种情况下，保持不变是契合多窗口的设计初衷的，读者在处理类似的适配方案时应当注意多窗口、画中画问题。

2.onConfigurationChanged多次回调问题

不同的厂商或者不同的用户配置，会在发生折叠时，因为状态栏或者系统底部的虚拟按键等设置，触发不同次数的onConfigurationChanged回调，回调下发的screenHeightDp数值不一致。上文已经提到，需要针对回调参数下发的newConfig数据做真正的折叠判断，忽略“伪配置变更”。

3.onNewIntent问题

不考虑折叠屏的情况下，京东小程序在多栈模式下返回时并不是真正的关闭小程序，而是压到后台，没有触发activity的finish。当用户再次打开时会触发onNewIntent事件，这里会进行小程序的重启。

但是遇到折叠屏，就会触发onConfigurationChanged 和 onNewIntent 都回调的情况，通过查阅源代码和打印日志方式，我们可以发现onConfigurationChanged的回调早于onNewIntent的。所以onConfigurationChanged一旦识别到发生屏幕折叠就会重启小程序，在onNewIntent这里应该避免再次重启小程序。

4.webview和js引擎获取屏幕宽高失真问题

在适配中我们遇到过在某些机器上“没问题”，在其他机器上“很容易复现”的窘境。在理论和实际上，客户端传递给逻辑层、视图层的尺寸数据都没问题，但是小程序表现上还是存在问题。经过细致的排查，发现js引擎上有些数据的是来自于window对象的宽高数据，此数据与折叠后的屏幕数据不一致，即webview和js引擎获取到的设备尺寸更新不及时，造成rpx计算失准。为此，我们替换了引擎中对window宽高的使用方式，替换为屏幕真正的数据。