Buffer低功耗优化

概述

在HarmonyOS中，Buffer是承载自绘制内容循环渲染的主要载体，有别于Vsync统一执行的思想，自绘制内容的生产不依赖于系统事件，而是由三方主导控制。Buffer在渲染过程中通过BufferQueue来进行轮转，采用了生产者与消费者的设计思想，应用将作为生产者将生产好的渲染内容准备好后，从BufferQueue中获取并Flush Buffer，而RS则作为消费者可以通过AcquireBuffer接口获取Buffer，让该Buffer作为自绘制Surface中的一帧在屏幕上显示，并将使用后的Buffer调用ReleaseBuffer释放进入轮转池。相关的流转逻辑可以参考下图：

开发者可以通过Profiler的Trace工具分析Buffer的流转过程，可按照下图所示的顺序将相关进程置顶排列。其中OS_IPC中包含了render_service的跨进程通信信息，开发者可参考下图虚线所示，根据binder找到对应的生产者进程，详细的Trace点含义如下：

1. “H:RequestBuffer name: xxx queueId: 6631429506443 queueSize: 5 reserveSlotNum: 0”：位于OS_IPC线程泳道，表明Producer申请使用了一帧Buffer，通过binder与生产者的对应进程连接，由生产者执行后续业务。
2. “H:FlushBuffer name: xxx queueId: 6631429506443 sequence: 97784886”：位于OS_IPC线程泳道，表明名称为xxx的Surface的Buffer在此时完成内容生产，已通过BufferQueue交给了消费者侧。其中queueId是Buffer序列的独立id，sequence是每个Buffer的独立id。与此同时，OS_IPC中还可以搜到H:rs_RequestNextVSync，表明下一帧Vsync中，rs会被拉起执行后续业务。
3. “H:AcquireBuffer with PresentTimestamp name: xxx queueId: 6631429506443”：位于render_service线程泳道，表明名为xxx的Surface此时在rs收集该帧的绘制诉求时，rs作为消费者请求了这个Buffer，用于后续的帧绘制。如果成功获取到了该Buffer，会在子Trace中额外打印“H:acquire buffer sequence: 97784886”。
4. “H:ReleaseBuffer name: xxx queueId: 6631429506443 seq: 97784892”：位于RSHardware或RSUniRenderThrea线程泳道，该信息通常出现在RSHardwareThread一帧中的最末尾，表明消费者已成功使用该Buffer，并释放该Buffer块，交还给BufferQueue。反之，如果ReleaseBuffer在RSUniRender中出现，则表明此时Buffer无需渲染在屏幕上，属于Buffer空跑问题。

分析思路

在定位问题时，开发者可以按照以下步骤来确定Buffer使用是否无误：

• 在RSHardwareThread泳道中搜索“H:ReleaseBuffer”：如图所示，在选定的时间段内RosenWeb和DisplayNode均释放了一定次数，开发者可以根据右侧的Occurrence统计其出现次数。由于BufferQueue具有循环复用的机制，同一seq会多次复用，如图中RosenWeb由5个Buffer循环复用而成。DisplayNode是应用进程下发绘制指令并经渲染后得到的统一绘制图层，大部分ArkUI组件的刷新也在DisplayNode中体现。

  

• 在RSUniRenderThre中搜索“H:ReleaseBuffer”：RSUniRenderThre中也会出现Buffer释放的流程，如下图所示，有一块RosenWeb的BufferQueue在框选时间内循环了174次，该Buffer并未实际造成显示效果，造成了Buffer空跑问题。

  

• 在render_service泳道中搜索“seq = [空跑Buffer id]”：发现一个空跑的BufferQueue时，可以从中找到一个Buffer id，例如100151309，并在render_service中进行搜索。搜索结果如下，在“H:RsDebug surfaceHandler(id:xxx)”中，开发者可以确认到该Buffer所对应的RS树node id。

  

开发者可使用HiSmartPerf工具，在“整机测试-RS树可视化展示”处展开RS树，通过id查找的方式找到此BufferQueue对应的rs节点位置，定位到导致空跑问题的自绘制内容。如下图，开发者在TabIndex为0的home页面抓取Trace发现了Buffer空跑问题，通过RsDebug找到问题node id后通过id搜索，在切换至yellow页面时，发现是此处的web buffer预渲染导致的空跑问题。

Web预渲染优化案例

问题现象

Web的预渲染是一种广泛使用的性能优化手段，让Web组件在挂载之前完成渲染可以有效减少Web初次加载时的时延表现，但处理不当也同样可能引起Buffer类空跑问题。在Web类应用中，对于预加载的离线Web节点，开发者需要确保这些后台的Web处于冻结状态，不会产生持续性的冗余Buffer影响正常场景的功能。下图展示了一个在非Web首页通过Tab预加载两个Web页面的Trace，分析Buffer的Release情况，发现Trace中RSUniRenderThre的帧率表现高于实际的显示帧率，表明空跑问题存在。进一步观察发现，RSUni中有两处ReleaseBuffer，来自两个不同的queueId，由此可以推断该页面可能存在两个离线的Web组件正在后台渲染，带来冗余负载。

开发者可以通过HiSmartPerf的RS树工具定位Buffer位置，除此之外，推荐开发者充分利用Web DevTools工具，参考使用DevTools工具调试前端页面，开发者可以通过端口投射的方式展示当前页面中所有的Web页面加载情况。如下图所示，端口投射成功后“1”处填写投射端口，“2”处将显示所有创建成功的web对象，点击其中的两个网页可查看其当前活跃状态，如“3”“4”则分别对应了处于冻结状态和活跃状态的页面，点击inspect观察表现情况。这种活跃/冻结状态可以调用WebController.onActive/onInactive来控制，原则上，并非在屏幕显示范围内的Web不应处于活跃状态，避免带来Buffer空跑问题。

优化思路

开发者可通过WebviewController的onActive()和onInactive()来控制Web的活跃与冻结，冻结态的Web处于后台不会生产Buffer，可保证功耗收益。当开发者使用离线Web组件或主动调用了preloaditems()等方法时，建议在Web容器中添加onFirstMeaningfulPaint()回调，确保Web离线加载时，在完成第一次页面渲染之后进入冻结状态，既能保证进入预渲染Web时能够快速打开第一帧内容，也能保证其后台不产生冗余Buffer。

@Component
struct MyWebComponent {
  private src: string = ""
  private controller1: webview.WebviewController = new webview.WebviewController();
  shouldDraw: boolean = true;
  build() {
    Web({ src: this.src, controller: this.controller1 })
      .onPageBegin(() => {
        console.log(this.src, "webpage is onActive")
        this.controller1.onActive();
      })

      .onFirstMeaningfulPaint(() => {
        if (!this.shouldDraw) {
          return;
        }
        console.log(this.src, "webpage is onInactive")
        this.controller1.onInactive()
        this.shouldDraw = false
      })
  }
}

自绘制组件空跑优化案例

问题现象

上图展示了一个位于可滑动列表中的Video组件从屏幕外滑动至屏幕内的应用场景。其中“1”处的信息代表页面滑动的时机，“2”处的信息表明，视频的硬解码进程一直持续着产生。观察“3”“4”两处的差异可以发现，当Video组件位于屏幕外时，由于Buffer的持续生产造成了RSUni持续ReleaseBuffer，引发空跑问题。原则上，开发者所使用的自绘制图层需要对其ArkUI载体（如Video、XComponent等）添加充分的事件监听，确保其不再需要显示时，从Buffer生产的源头上停止。

优化思路

@Component
export struct MyVideoComponent {
  @State videoSrc: Resource | string = $r('app.media.test_video');
  private controller: VideoController = new VideoController();


  build() {
    Column() {
      Video({
        src: this.videoSrc,
        controller: this.controller,

      })
        .width(300)
        .height(200)
        .onPrepared(() => {
          this.controller.start();
        })
        // 确保视频组件完全可见时播放，完全不可见时停止
        .onVisibleAreaChange([0.0], (isExpanding: boolean, currentRatio: number) => {
          if (isExpanding && currentRatio >= 1.0) {
            console.info('Component is completely visiable.');
            if (this.controller) {
              this.controller.start();
            }
          }
          if (!isExpanding && currentRatio <= 0.0) {
            console.info('Component is completely invisible.');
            if (this.controller) {
              this.controller.pause();
            }
          }
        })
    }
  }
}

如上代码所示，开发者可利用可见性监听，判断当前呈现自绘制内容的ArkUI组件是否位于显示范围，通过控制Video.controller，控制视频在可见时播放，不可见时停止。

自绘制图层GPU重绘问题低功耗建议

问题现象

问题定位

开发者可以搜索“DrawImage”判断有无GPU重绘问题产生，如上图，给一个纯净的适配播放图层设置了一个透明度，进而引发GPU重绘问题发生，开发者可根据以下几个Trace点定位问题：

1. H:AcquireBuffer name: Surface queueId: 6605659702100：对应自绘制图层Buffer获取时机
2. H:RSBaseRenderEngine::DrawImage(GPU) targetColorGamut=4：“DrawImage(GPU)”表明存在GPU重绘现象，targetColorGamut=4表明该Surface在合成时，有四个buffer的内容，其中固定存在的三个Buffer分别是Display和两个固定圆角图层，当该值大于3时，表明有其他来源的Buffer进行了重绘进入了DisplayNode
3. H:ReleaseBuffer name: Surface queueId: 6605659702100 seq: 100801225：Buffer在RSUni中释放，此时Buffer的内容已经在DisplayNode中，Buffer重新流入BufferQueue
4. H:ReleaseBuffer name: DisplayNode queueId: 6605659701285 seq: 100798111：DisplayNode在RSHardware中释放

优化思路

如上图，开发者可以使用HiSmartPerf的RS树工具查看可疑节点，在OtherModifier位置可以查看到来自pid进程58867，为该节点添加了一个0.4的Alpha透明度，结合该信息可进一步定位到对应的代码片段，如下图代码，注释掉透明度效果后问题不复现。

@Component
export struct MyVideoComponent_opacity {
  @State videoSrc: Resource | string = $r('app.media.test_video');
  private controller: VideoController = new VideoController();


  build() {
    Column() {
      Video({
        src: this.videoSrc,
        controller: this.controller,

      })
        .width(300)
        .height(200)
        // .opacity(0.4) 注释掉此段代码，可规避GPU重绘
        .onPrepared(() => {
          this.controller.start();
        })
    }
  }
}

修改好的Trace表现如下图所示，在直通情况下，自绘制图层在图中“1”处获取Buffer，“2”处释放Buffer，无需交由RSUniRender进行重绘计算，也没有DisplayNode的刷新显示，达到预期的低功耗效果。