1. Gluon Mobile 音量控制的挑战
在开发 Gluon Mobile 应用程序时，开发者通常会使用 com.gluonhq.attach.audio.Audio 接口来处理音频播放。该接口提供了设置音量的功能，然而，在 Android 等移动平台上，应用程序通常会使用设备的“媒体音量”或“通知音量”通道。一个常见的问题是，在 Gluon Mobile 应用中，即使音频正在播放，按下设备的硬件音量键也可能没有任何响应，这与用户在其他原生应用中的体验大相径庭。用户期望应用程序播放的音频能够与设备的系统音量设置联动，并允许通过硬件音量键进行实时调整。
2. 探索 VideoService 的潜力与局限
为了解决上述问题，我们转向探索 com.gluonhq.attach.video.VideoService。尽管其名称暗示了主要用于视频播放，但 VideoService 在音频/视频播放期间，确实能够影响设备的系统音量。这意味着，当 VideoService 处于活动播放状态时，用户通过硬件音量键进行的调整将直接作用于应用程序正在播放的音频。
然而，VideoService 并非没有局限性：
- 音量控制的时效性： 设备音量的联动调整仅在 VideoService 正在播放音频或视频时才有效。对于非常短促的提示音，用户可能没有足够的时间来通过硬件键进行音量调整。
- 播放列表设计： VideoService 的设计初衷是处理播放列表，而不是直接播放单个独立的音频文件。这意味着，如果需要播放单个音频片段，我们不能简单地调用一个“播放单文件”的方法。
3. 解决方案：动态管理 VideoService 播放列表
鉴于 VideoService 的特性，一个可行的解决方案是巧妙地利用其播放列表机制。核心思路是：当需要播放某个短音频片段时，动态地将该音频片段设置为 VideoService 播放列表中的唯一项，然后触发播放。这样，VideoService 就被激活并开始播放该音频，从而允许设备的系统音量控制生效。
4. 示例代码：MobileNotifier 实现
以下是一个名为 MobileNotifier 的示例类，它演示了如何利用 VideoService 来播放不同的提示音，并实现与设备系统音量的联动：
import com.gluonhq.attach.video.VideoService;
import com.gluonhq.attach.video.VideoService.Status;
public class MobileNotifier {
private static final String SMALL_BEEP_PATH = "/sounds/SmallBeep.wav";
private static final String BIG_BEEP_PATH = "/sounds/BigBEEP.wav";
private final VideoService service; // 使用 final 确保单例或注入
// 假设 Alert 是一个枚举类型，用于区分不同类型的提示音
public enum Alert {
SMALL, BIG
}
// 构造函数，注入 VideoService 实例
public MobileNotifier(VideoService service) {
this.service = service;
// 初始化播放列表，加入一个默认的音频路径
// 这样可以确保 service.getPlaylist().get(0) 在 play 方法中不会抛出 IndexOutOfBoundsException
service.getPlaylist().add(SMALL_BEEP_PATH);
}
/**
* 根据指定的警报类型播放相应的音频。
* 该方法会确保 VideoService 播放的是目标音频，并使其处于播放状态。
* @param alert 要播放的警报类型
*/
public void play(Alert alert) {
switch (alert) {
case SMALL -> {
// 检查当前是否正在播放，或者播放的不是 SMALL_BEEP_PATH
if (service.statusProperty().get() != Status.PLAYING || !SMALL_BEEP_PATH.equals(service.getPlaylist().get(0))) {
service.stop(); // 停止当前播放
service.getPlaylist().set(0, SMALL_BEEP_PATH); // 将播放列表的第一个项设置为 SMALL_BEEP_PATH
service.play(); // 开始播放
}
}
case BIG -> {
// 检查当前是否正在播放，或者播放的不是 BIG_BEEP_PATH
if (service.statusProperty().get() != Status.PLAYING || !BIG_BEEP_PATH.equals(service.getPlaylist().get(0))) {
service.stop(); // 停止当前播放
service.getPlaylist().set(0, BIG_BEEP_PATH); // 将播放列表的第一个项设置为 BIG_BEEP_PATH
service.play(); // 开始播放
}
}
}
}
}代码解析：
- 依赖注入 VideoService： MobileNotifier 类通过构造函数接收一个 VideoService 实例。在实际应用中，这通常通过 Gluon 的依赖注入框架（如 Charm）来完成。
- 音频路径定义： SMALL_BEEP_PATH 和 BIG_BEEP_PATH 定义了不同提示音的资源路径。这些音频文件应放置在应用程序的资源目录中。
-
播放逻辑 (play 方法)：
- 该方法根据传入的 Alert 枚举值决定播放哪个音频。
-
条件判断： 在播放之前，代码会检查两个条件：
- service.statusProperty().get() != Status.PLAYING: 当前 VideoService 是否处于非播放状态。
- !TARGET_PATH.equals(service.getPlaylist().get(0)): VideoService 播放列表的第一个（也是当前唯一）项是否与目标音频路径不符。
-
动态切换： 如果上述任一条件为真（即当前没有播放，或者正在播放的不是我们想要的音频），则执行以下操作：
- service.stop(): 停止当前可能正在进行的播放。
- service.getPlaylist().set(0, TARGET_PATH): 这是关键一步。它将播放列表的第一个元素（通常也是唯一一个）设置为我们想要播放的音频路径。由于 VideoService 倾向于播放列表，通过这种方式可以强制它加载并播放指定的单个文件。
- service.play(): 启动 VideoService 的播放，此时，它将播放我们刚刚设置的音频，并激活与设备系统音量的联动。
5. 注意事项与局限性
- 音量控制窗口期： 如前所述，设备音量调整仅在 VideoService 处于播放状态时有效。对于极短的提示音（例如毫秒级的蜂鸣声），用户可能没有足够的时间通过硬件音量键进行调整。在这种情况下，此方案主要提供的是系统音量联动而非即时调节能力。
- 资源开销： 频繁地停止、设置播放列表和重新播放可能会带来轻微的性能开销。对于大多数通知场景，这种开销通常可以忽略不计，但如果需要播放大量短音频，可能需要更精细的优化。
- 播放列表的单文件策略： 此方案的核心是利用播放列表的第一个位置来承载要播放的单个音频。确保在任何时候播放列表都只包含一个或几个可控的项，以避免意外行为。
- 用户体验提示： 如果应用场景允许，可以在播放音频时，在 UI 上给予用户一些提示，例如显示一个短暂的音量条，引导用户知道此时可以通过硬件键调整音量。
- 兼容性： 尽管此方法在 Android 8 和 12 上经过测试，但不同 Android 版本或设备制造商对音频服务和硬件音量键的实现可能存在细微差异。建议在目标设备上进行充分测试。
6. 总结
通过巧妙地利用 VideoService 并动态管理其播放列表，我们可以在 Gluon Mobile 应用程序中实现与设备系统音量的联动，并允许用户通过硬件音量键调整应用程序的音频播放音量。尽管这不是一个直接的“播放单文件并控制系统音量”的 API，但它提供了一个有效的变通方案，解决了 Audio 接口在这方面的局限性。开发者应根据具体应用场景和音频播放需求，权衡此方案的优缺点，并进行必要的测试和优化。
