企业官网建设流程全解析

最近在适配一台折叠屏设备时碰到一个问题：设备合上盖子，外屏壁纸显示正常；展开之后，内屏反而变成了系统默认的纯色背景。一开始以为是主题资源配色的问题，查了一整天，最后把思路拉回到安卓系统里Wallpaper与多屏显示器的关系上，才算找到方向。正好这段时间又把Google官方文档里与Wallpaper相关的部分重新梳理了一遍，这里把关于安卓Wallpaper壁纸对多屏支持的机制、关键API和实机表现整理出来，既给自己留个索引，也方便正在做折叠屏适配、多显示器外接或Android系统定制开发的同行参考。

1. 壁纸服务到底管的是哪块屏：displayId是理解多屏壁纸的钥匙

1.1 WallpaperManager默认绑定的是主显示器

很多开发者第一次接触壁纸接口时，做的事情基本是同一套：

WallpaperManager wm = WallpaperManager.getInstance(context); wm.setBitmap(bitmap, null, true, WallpaperManager.FLAG_SYSTEM);

这段代码在普通单屏设备上没有任何问题，但放到多屏设备上就很容易产生认知偏差：getInstance(Context)返回的WallpaperManager实例，默认关联的是Display.DEFAULT_DISPLAY，也就是系统主显示器。你写入的FLAG_SYSTEM壁纸，最终落地的位置是主显示器对应的壁纸数据，而不是你想象中的"全局壁纸"。

Android系统里的壁纸，在框架层从来不是一份全局数据。从DisplayManagerService往下看，每一个Display都有唯一的displayId，主屏固定是0，外接屏、虚拟屏、折叠屏的内外屏都可能有独立的displayId。壁纸服务本身也是以displayId为维度去管理数据包的，这一点在WallpaperManagerService的源码里体现得非常明显——每个displayId都有自己的一份壁纸状态记录，包含裁剪区域、缩放参数、所属用户，以及后续版本里加入的颜色提取结果。

所以"多屏支持"并不是一个模糊的产品概念，它在系统底层的表现是：框架有能力按照displayId分别维护壁纸，但默认只把主屏的壁纸数据初始化好。其他屏幕要不要显示壁纸、显示哪份壁纸，完全取决于系统的显示策略配置。

1.2 AIDL接口里的displayId说明了什么

想确认这套模型，最直接的办法是翻AOSP源码里IWallpaperManager.aidl。这份AIDL是WallpaperManagerService的门面，我建议所有做壁纸相关定制的人都仔细看一遍。里面设置壁纸数据、设置动态壁纸组件、查询壁纸信息等方法，普遍带有一个displayId参数。

这说明底层确实支持把壁纸往特定显示器上写。说得直白一点：系统完全可以让内屏用风景壁纸、外屏用纯色壁纸，只是大多数OEM默认配置里没有把每个display都用壁纸窗口初始化起来。于是用户看到的效果就是"所有屏幕好像都用同一个壁纸，或者某些屏幕干脆没有壁纸"。

这里有一个容易被忽略的点：官方公开API里，普通的WallpaperManager并没有直接暴露"给指定displayId设置壁纸"的入口，多屏相关的参数大部分停留在框架层和系统接口内部。也就是说，普通应用开发者能做的事情，基本还是围绕主屏壁纸通道展开；真正能按display维度精细控制壁纸的，通常是SystemUI或系统级定制场景。这一点在官方文档中其实没有集中说明，需要靠源码去反推，也是我建议后来者直接看AIDL而不是只看Javadoc的原因。

2. 官方文档里的多屏壁纸模型：从通道参数到动态壁纸绑定

2.1 which参数：系统壁纸与锁屏壁纸是两条独立通道

官方文档里WallpaperManager的FLAG_SYSTEM和FLAG_LOCK这两个常量，是所有做壁纸开发的人应该先吃透的东西。它们代表两条互不干扰的壁纸通道：FLAG_SYSTEM是桌面壁纸，也就是Launcher背后那一层；FLAG_LOCK是锁屏壁纸，出现在Keyguard界面底部。

从Android 9开始，锁屏壁纸才支持真正独立于系统壁纸设置。在这之前，锁屏界面展示的基本是系统壁纸的副本，厂商如果想做锁屏单独换壁纸，只能靠ROM层自己扩展接口。而现在通过公开API就可以做到：

WallpaperManager wm = WallpaperManager.getInstance(context); wm.setBitmap(bitmap, null, true, WallpaperManager.FLAG_LOCK);

这条通道隔离的意义在于：两条通道对应的是不同显示场景，而不是不同显示屏幕。锁屏壁纸在多屏设备上通常只会出现在锁屏界面所在的显示器上，而系统壁纸则作用于主屏桌面。如果你在做多屏适配，需要先明确自己到底要改哪条通道，再考虑哪个屏幕的问题。

2.2 Google文档对多屏壁纸的真实交代

说实话，Google官方文档里并不存在一篇标题叫"多屏壁纸支持指南"的文章。相关能力是散落在几处的：WallpaperManager的API说明、DisplayManager的多显示指南、Android版本特性文档，以及AOSP源码。把它们拼在一起，才能真正还原出多屏壁纸的全貌。

我梳理下来的核心知识点可以归纳为四层：

• 壁纸服务以displayId为粒度，不同显示器可以配置不同壁纸，这是框架能力层面的结论。
• FLAG_SYSTEM通道默认作用于主显示器，FLAG_LOCK通道与锁屏界面所在显示器相关。
• 动态壁纸（WallpaperService）通过Engine机制和启动它的display上下文绑定。
• 较新的Android版本中，WallpaperManager开始提供与壁纸displayId集合相关的查询能力，用于让调用方了解当前系统哪些屏幕拥有独立壁纸数据。

这四层信息在文档里都不是放在同一页的，甚至有些细节只体现在API的版本注释或源码注释里。官方文档对多屏壁纸的态度更像是"能力预留"，而不是"开箱即用的完整功能"。这也就解释了为什么很多开发者翻完文档仍然搞不清楚多屏壁纸到底怎么表现——因为文档本身就不是按"教程"来写的。

2.3 WallpaperColors是跟着displayId走的

多屏壁纸还有一个容易被忽略的连带机制：WallpaperColors。官方文档里对它的定义非常明确——从壁纸中提取主题颜色，供SystemUI用于状态栏、导航栏、锁屏界面的明暗色调适配。

由于颜色提取结果是从壁纸数据中计算出来的，而壁纸数据又挂在displayId维度下，所以WallpaperColors天然也是"跟着屏幕走"的。这意味着如果系统为某个外部显示器单独配置了壁纸，那么那个屏幕上的SystemUI色调也应该基于那份壁纸重新计算。反过来，如果外部屏幕没有独立壁纸，颜色提取逻辑一般会回退到主屏壁纸，甚至返回一个默认的浅色/深色配色。

实际开发中，我见过不少人直接调用WallpaperManager.getInstance(context).getWallpaperColors(FLAG_SYSTEM)就以为拿到了当前屏幕的颜色值，其实在多屏场景下这个结果只代表主屏壁纸的颜色。如果你的应用在副屏上显示界面并想跟随壁纸色调做适配，需要走DisplayListener关注屏幕的变化，再结合具体displayId去判断应该使用哪一份颜色数据。

3. 折叠屏、投屏、虚拟屏：三类多屏场景下的真实壁纸行为

3.1 折叠屏：展开与合上的壁纸切换

折叠屏是目前最典型的多屏设备形态。以我测试的这台设备为例，内屏和外屏在系统层面对应的displayId并不一致，展开和折叠时还会触发结构的重新配置。

问题就出在这里：部分设备的默认策略会把内屏设为默认显示器（displayId 0），壁纸跟着内屏走。当你合上盖子切到外屏，外屏作为一个独立display，并没有自己的壁纸数据。于是系统要么用一段纯色背景兜底，要么走厂商自定义的逻辑去复制内屏壁纸。我遇到的那种"展开后内屏壁纸变纯色"的情况，本质上就是壁纸窗口没有在内屏对应的display上正确初始化，或者初始化时机晚于壁纸渲染时机。

处理这类问题，要意识到折叠屏的屏幕切换不只是尺寸变化，它很可能是一次完整的Display层级变化。对你而言，最重要的验证手段是：在展开和折叠两个状态下分别执行DisplayManager.getDisplays()，把每个屏幕的displayId和状态打印出来，看看到底哪些显示器的壁纸层还活着。很多从UI层面看起来是壁纸"丢失"的问题，其实都是display切换过程中的初始化时序问题。

3.2 外接显示器和投屏：为什么那边总是纯色或黑底

HDMI外接显示器、DP扩展屏在Android设备上并不罕见，但绝大多数情况下你会发现外接屏根本没有壁纸。这不是bug，而是AOSP的默认行为：SystemUI的壁纸RootView通常只挂载在主显示器的DisplayContent上，其他display没有对应的壁纸窗口token，默认就显示纯色背景或者黑底。

如果你希望能让外接屏也显示壁纸，在常规应用层是没有办法的，只能在系统定制层给对应display创建壁纸窗口，或者让该显示器的WindowManager配置里包含壁纸层。部分会议平板、商显方案的ROM会做类似的事情，但普通手机外接屏基本都不会。

投屏场景则略有不同。无线投屏或者有线投屏如果走的是镜像模式，投出去的是主屏幕完整的UI内容，壁纸自然也跟着投出去。但如果走的是扩展模式或者远程桌面方案，目标设备上的画面往往由接收端自己绘制，壁纸是否显示完全取决于接收端的实现。这也是为什么同样一台手机，投到电视上和投到电脑采集卡上，背景表现完全不一样。

3.3 VirtualDisplay：录屏和远程桌面里的壁纸逻辑

VirtualDisplay是Android里非常特殊的屏幕形态，它不是物理屏幕，而是由系统或应用创建的虚拟目标，常用于录屏、远程控制、投屏录制等场景。

在VirtualDisplay上，壁纸的行为取决于它呈现的内容来源。用MediaProjection录屏时，抓取的是已经渲染好的主屏幕内容，主屏有壁纸，录出来的画面就有壁纸，这个没有悬念。但如果应用自己创建一个独立的VirtualDisplay，并且在上面展示独立的UI内容，那个VirtualDisplay默认是不带壁纸层的。也就是说，虚拟屏并不会自动继承主屏壁纸，它更像一张"空白画布"，你想让它有什么背景，就得自己画。

这一点在做远程协助类应用时特别关键。我见过有团队在虚拟屏上复刻桌面UI时，发现背景和主屏不一致，于是去猜测系统壁纸的读取逻辑，费了很大劲。其实最简单可靠的做法是：直接读取主屏壁纸的Bitmap，把它作为虚拟屏根布局的backgroundDrawable，再监听壁纸变化事件去同步。这样虽然是"复制"而不是"系统级挂载"，但在应用层反而是最可控的方案。

4. 代码实操：把壁纸正确设置到目标显示器相关场景

4.1 用DisplayManager建立屏幕清单

不管你要实现什么多屏壁纸逻辑，第一步都是先把当前设备上所有显示器枚举出来。建议在Application启动或者主要Activity创建时做一次全量扫描：

DisplayManager dm = (DisplayManager) getSystemService(Context.DISPLAY_SERVICE); Display[] displays = dm.getDisplays(); for (Display display : displays) { int displayId = display.getDisplayId(); String name = display.getName(); Point size = new Point(); display.getRealSize(size); Log.d(TAG, "displayId=" + displayId + ", name=" + name + ", size=" + size.x + "x" + size.y + ", flags=" + display.getFlags()); }

注意要区分getCurrentSizeRange和getRealSize：在壁纸适配场景里，我们要的是物理分辨率而不是可用区域，因为壁纸最终要覆盖整个屏幕，不能用减去状态栏和导航栏之后的区域去计算。getRealSize拿到的才是完整的显示区域尺寸。

4.2 设置壁纸的基础姿势与权限

应用层设置壁纸，标准流程还是走WallpaperManager。以静态位图为例：

WallpaperManager wm = WallpaperManager.getInstance(context); // 支持裁剪区域的版本，null表示使用默认裁剪策略 boolean success = wm.setBitmap(bitmap, null, true, WallpaperManager.FLAG_SYSTEM | WallpaperManager.FLAG_LOCK); if (success) { Log.d(TAG, "wallpaper updated, sdk=" + Build.VERSION.SDK_INT); }

这里有三个关键点：

• 权限只需要android.permission.SET_WALLPAPER，它是normal级别权限，安装时自动授予，不需要动态申请。
• boolean allowBackup参数表示壁纸数据是否允许在设备迁移或系统备份时保留。一般传false即可，因为壁纸往往是用户的临时趣味选择，默认不需要做云备份。
• FLAG_SYSTEM | FLAG_LOCK这种写法在Android 9之后的设备上表示同时写入两条通道。在Android 8及以下设备上，FLAG_LOCK通道不存在，设置时会自动忽略。

如果你是系统应用或者有特权，想设置动态壁纸组件，那需要WallpaperManager.setWallpaperComponent(ComponentName)，这个操作要求SET_WALLPAPER_COMPONENT签名级权限，普通应用拿不到，只能在系统定制或ADB场景下使用。

4.3 监听屏幕变化并响应刷新

多屏壁纸适配中最怕的就是屏幕动态出现和消失。外接显示器随时可能插拔，折叠屏随时可能展开，这些事件不会自动通知壁纸系统去刷新，需要你自己监听：

DisplayManager dm = (DisplayManager) getSystemService(Context.DISPLAY_SERVICE); dm.registerDisplayListener(new DisplayManager.DisplayListener() { @Override public void onDisplayAdded(int displayId) { // 新显示器出现，可能需要初始化壁纸数据 Log.d(TAG, "display added: " + displayId); } @Override public void onDisplayRemoved(int displayId) { // 显示器移除，需要清理相关壁纸引用 Log.d(TAG, "display removed: " + displayId); } @Override public void onDisplayChanged(int displayId) { // 显示器属性变化：分辨率、密度、状态等 Log.d(TAG, "display changed: " + displayId); } }, new Handler(Looper.getMainLooper()));

在这个回调里做事情要克制。onDisplayChanged在分辨率切换、方向变化、折叠展开时都会触发，频率很高。不要在回调里直接重新设置壁纸，而是先做一个去抖（debounce）处理，比如记录最后一次变更时间，间隔超过一定阈值才执行真正的刷新逻辑，避免在屏幕参数频繁变化时反复写壁纸数据，增加磁盘和渲染压力。

4.4 壁纸图片尺寸在多屏环境下的处理

单屏设备上，壁纸尺寸通常直接参考屏幕分辨率就好。多屏设备上就要考虑多个屏幕的尺寸了。系统提供了一个参考接口WallpaperManager.suggestWallpaperDimension()，它返回一个建议的壁纸最小尺寸：

WallpaperManager wm = WallpaperManager.getInstance(context); Point dimension = wm.suggestWallpaperDimension(); int targetWidth = dimension.x; int targetHeight = dimension.y;

这个建议值在系统内部往往已经考虑了主屏的宽高比、壁纸偏移和滚动效果。但多屏设备上，建议值可能只覆盖主屏，不会主动把你外接屏的分辨率也包进来。

更稳妥的做法是自己遍历所有display并取最大尺寸：

DisplayManager dm = (DisplayManager) context.getSystemService(Context.DISPLAY_SERVICE); int maxWidth = 0; int maxHeight = 0; for (Display display : dm.getDisplays()) { Point size = new Point(); display.getRealSize(size); maxWidth = Math.max(maxWidth, size.x); maxHeight = Math.max(maxHeight, size.y); } // 再和系统建议值对比，取较大者作为最终壁纸Bitmap尺寸

这样生成的壁纸无论哪个屏幕展示，都不会因为分辨率不足而出现明显拉伸模糊。代价是内存占用更大，一张覆盖折叠屏内屏和外屏最大尺寸的壁纸Bitmap可能高达几十MB。所以在生成位图时要注意用BitmapFactory.Options的inSampleSize控制采样，或者在服务端就按目标尺寸压缩好再下发，不要直接加载一张原始大图到内存里。

5. 实践当中踩过的坑与兼容性补充

5.1 第三方桌面并不总是跟着系统走

多屏壁纸适配中，最让人头疼的不是系统原生逻辑，而是各种第三方桌面。很多Launcher在设置壁纸时会绕过系统标准的设置流程，直接用自己的方式去处理壁纸资源，尤其是当它的壁纸不是通过WallpaperManager写入，而是自己持有Bitmap并在桌面根布局中绘制时。

这种实现会带来一个问题：桌面自绘的壁纸只覆盖它自己所在的display，一旦用户切到另一个屏幕或者系统切换到另一个桌面场景，壁纸就神秘消失了。而且因为数据根本没写入系统壁纸通道，系统其他模块（比如WallpaperColors）也能正常工作的前提就全都不存在了。

所以遇到多屏壁纸表现不一致的问题，第一个要确认的就是壁纸到底是通过系统通道设置，还是被某个应用自己截胡了。用adb shell dumpsys wallpaper可以快速查看当前系统壁纸通道里存的是什么；如果这里显示的信息和桌面上展示的不一致，那大概率是桌面应用自己画的壁纸，跟系统没关系。

5.2 WallpaperColors刷新不及时导致的UI异常

WallpaperColors的刷新是一个异步过程。系统提取壁纸颜色后，会通过WallpaperManager.OnColorsChangedListener通知关心颜色的模块。多屏设备上，这个通知的准确性完全取决于壁纸数据是否按displayId正确更新。

我们实际遇到过的场景是：折叠屏展开后，SystemUI读到了新的displayId对应的壁纸数据，但颜色提取结果还是旧屏的缓存，导致状态栏文字颜色在整个展开过程中一直保持低对比度状态，直到下一次壁纸刷新才恢复正常。排查这类问题，可以在代码里主动调用WallpaperManager.getInstance(context).getWallpaperColors(FLAG_SYSTEM)并打印出getPrimaryColor()值，对比展开前后的变化；如果前后一致但界面表现不同，那问题多半不在颜色提取上，而是SystemUI侧没有监听对应display的颜色变更事件。

5.3 ROM定制场景下怎么正确扩展多屏壁纸

如果是在做系统级定制，想让每个显示器都拥有独立的壁纸，切入点的核心还是在WallpaperManagerService和SystemUI的壁纸窗口管理上。常规做法是在WallpaperManagerService里为每个displayId初始化对应的WallpaperData，并在显示策略中允许对应DisplayContent挂载壁纸窗口token。

这里面最需要注意的兼容性问题是用户切换和多用户机制。壁纸数据是按userId隔离的，再加一个displayId维度之后，数据匹配逻辑会成倍复杂。建议新增的接口在命名上就显式带上displayId和userHandle两个参数，避免后续维护时搞混。另一个点是对动态壁纸的约束：动态壁纸通过Engine和启动时的display上下文绑定，跨显示器运行动态壁纸在Android原生机上限制很多，定制时如果不做限制，容易出现多个屏幕同时运行同一动态壁纸、内存和GPU资源翻倍的情况。

我的建议是：ROM定制层面优先支持"静态壁纸按displayId差异化"，动态壁纸仍然以主屏为主。这样既能覆盖绝大多数用户的需求，又不会把系统的性能瓶颈引入到壁纸这种低价值的资源点上。

壁纸支持这件事，官方文档和源码给出的是一条非常明确的分界线：框架层有能力，但默认策略不启用。真正决定多屏壁纸体验的，是OEM如何配置DisplayContent和WallpaperData之间的映射关系。如果你正在做相关适配，我的建议很直接——先看AOSP源码里IWallpaperManager.aidl和WallpaperManagerService，再回来看官方文档就会觉得豁然开朗。文档负责告诉你接口长什么样，源码负责告诉你画面到底是怎么画出来的。