【问题标题】:Streaming video playback performance issues with background tasks on AndroidAndroid 上后台任务的流式视频播放性能问题
【发布时间】:2010-03-02 08:33:17
【问题描述】:

我开发了一个小应用程序,它可以通过 VideoView 小部件(我也尝试过 Mplayer+SurfaceView 方法)从 rstp 流服务器(在本例中为 darwin,但这不相关)播放视频。我为此使用 Wifi 连接。

视频是唯一的任务时,视频播放流畅。小型应用程序应该同时执行其他任务,例如不断发现蓝牙设备并调用远程 Web 服务(我为此使用了 Ksoap2)。当这些背景 taks 与视频播放同时运行时,性能会令人难以置信地下降(图像和声音有时会停止并且图像会失真,显示出相当大的方块而不是正确的帧)。

即使是低质量视频(3gp at 50 kbps)也会发生这种情况。对于蓝牙发现,我使用了两种可用的方法,但彼此之间没有性能增强:

  • 使用 SDK 5 提供的发现方式,注册每一个发现的蓝牙设备。
  • 使用对利用 Bluez API 提供的 hci_inquiry() 函数的自写 scan() 方法的本机调用。

对 WS 的调用需要已发现设备的蓝牙地址。发现完成后调用。

我尝试使用 GLSurfaceView 代替 SurfaceView,但由于我对 Android 平台比较陌生,并且没有 3D 图形编程里程,我无法使其工作,因为我找不到任何使用 OpenGL 的示例ES 可以正确播放视频,并且仍然能够让 Android API 控制其他与 UI 相关的内容(对话框/菜单/Toast)。另一方面,我不知道这是否确实可以改善播放效果。

任何线索或提示我可以采取的方式?

编辑:我忘了说我正在开发摩托罗拉里程碑

编辑 2:按照 CommonsWare 和 snctln 的建议,我尝试在不完全忽略 SOAP WS 调用的同时尽量减少应用程序的内存占用。

现在我尝试缓存尽可能多的对象,并且只在找到新的 BT 设备时才执行调用(WS 需要发现的 BT 设备作为输入)以最小化 GC 调用。只有在蓝牙发现活动(根本没有 WS 调用)的情况下,视频仍然播放得很糟糕。

编辑 3:解决方案:我修改了我的应用程序以在扫描蓝牙设备时使用 UMTS (3G) 数据连接而不是 Wifi。虽然设备访问公共互联网 (m.youtube.com),但它通过 3G(来自公共互联网服务器)播放流视频比通过本地 Wifi(来自本地流媒体服务器)更流畅。本地流媒体服务器性能不是问题,因为流媒体到台式电脑运行良好。我还将设备固件升级到 2.0.1,本地 Wifi 连接也有所改善,但 3G 播放性能仍然优于 Wifi。

我的结论是,此设备在同时使用 Wifi/蓝牙通信时一定存在一些冲突的硬件(可能是相同的芯片组)或软件问题。

【问题讨论】:

    标签: android performance web-services bluetooth video-streaming


    【解决方案1】:

    请理解,摩托罗拉 Milestone 拥有大约 12 到 15 年前 PC 的 CPU 速度和 RAM。

    任何线索或提示我可以的方式 拿吗?

    转储 SOAP 并使用轻量级 Web 服务协议(例如 JSON over REST)。降低执行此工作的线程的优先级,这样它们就不会过多地干扰处理视频播放的线程。在您的蓝牙扫描中添加尽可能多的“呼吸时间”,而不是不断执行代码来尝试发现设备。

    假设不能解决问题,请使用 traceview 和类似工具尝试优化您的后台线程(可能没有视频运行)。

    【讨论】:

    • 我已经为主线程(我认为是 UI 线程)赋予了最大优先级,为执行 BT 扫描(使用本机方式时)和调用 WS 和 videoplayback 而创建的线程赋予了最低优先级没有得到足够的性能改进。也许真正影响视频播放的是系统调用(发现 BT 设备和网络套接字上的 I/O),但不确定。难道不能使用 GPU 硬件加速,所以 CPU 开销就没有那么重要了吗?
    • 它已经使用了GPU硬件加速。但是,如果我不得不猜测,您的问题更多在于流方面 - 读取数据并对其进行解码。
    • 另外,不要乱用你没有创建的线程的优先级(根据你的“给主线程(我想是 UI 一个)的最大优先级”评论)。
    【解决方案2】:

    您可以做的一件事是查看您的内存分配。大约一年前,我在玩游戏时遇到了显示性能问题,每 2 秒左右就会出现大量“延迟”。我发布到 android-develoeprs Google 小组,并从一位 android 工程师那里得到了一些跟踪问题的指示。他后来整理了this blog post,详细说明了跟踪内存分配的过程,这对跟踪很重要,因为我看到的滞后是直接由于垃圾收集造成的。现在我将分配量保持在最低限度,这种延迟发生的频率要低得多。

    我也同意 Mark(CommonsWare) 的观点,如果您可以为轻量级协议倾倒肥皂,您可能会看到性能有所提高。

    【讨论】:

    • 我试图按照你的建议去做,但没有运气。蓝牙发现过程(位于 Android SDK 中)似乎与视频一起工作很繁重。也许这可能是硬件问题(BT 和 WIFI 的芯片组相同)?
    猜你喜欢
    • 1970-01-01
    • 2019-05-25
    • 1970-01-01
    • 2015-09-02
    • 1970-01-01
    • 1970-01-01
    • 2012-09-02
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多