作为一款VR实时操作游戏App，我们需要根据重力感应系统，实时监控手机的角度，并渲染出相应位置的VR图像，因此在不同Android设备之间，由于使用的芯片组和不同架构的GPU，游戏性能会因此受到影响。举例来说：游戏在GalaxyS20+上可能以60fps的速度渲染，但它在HUAWEIP50Pro上的表现可能与前者大相径庭。由于新版本的手机具有良好的配置，而游戏需要考虑基于底层硬件的运行情况。

如果玩家遇到帧速率下降或加载时间变慢，他们很快就会对游戏失去兴趣。如果游戏耗尽电池电量或设备过热，我们也会流失处于长途旅行中的游戏玩家。如果提前预渲染不必要的游戏素材，会大大增加游戏的启动时间，导致玩家失去耐心。如果帧率和手机不能适配，在运行时会由于手机自我保护机制造成闪退，带来极差的游戏体验。

基于此，我们需要对代码进行优化以适配市场上不同手机的不同帧率运行。

所遇到的挑战

首先我们使用Streamline获取在Android设备上运行的游戏的配置文件，在运行测试场景时将CPU和GPU性能计数器活动可视化，以准确了解设备处理CPU和GPU工作负载，从而去定位帧速率下降的主要问题。

以下的帧率分析图表显示了应用程序如何随时间运行。

在下面的图中，我们可以看到执行引擎周期与FPS下降之间的相关性。显然GPU正忙于算术运算，并且着色器可能过于复杂。

为了测试在不同设备中的帧率情况，使用友盟+U-APM测试不同机型上的卡顿状况，发现在onSurfaceCreated函数中进行渲染时出现卡顿，应证了前文的分析，可以确定GPU是在算数运算过程中发生了卡顿：

因为不同设备有不同的性能预期，所以需要为每个设备设置自己的性能预算。例如，已知设备中GPU的最高频率，并且提供目标帧速率，则可以计算每帧GPU成本的绝对限制。

数学公式:$每帧GPU成本=GPU最高频率/目标帧率$

CPU到GPU的调度存在一定的约束，由于调度上存在限制所以我们无法达到目标帧率。另外，由于CPU-GPU接口上的工作负载序列化，渲染过程是异步进行的。CPU将新的渲染工作放入队列，稍后由GPU处理。

数据资源问题

CPU控制渲染过程并且实时提供最新的数据，例如每一帧的变换和灯光位置。然而，GPU处理是异步的。这意味着数据资源会被排队的命令引用，并在命令流中停留一段时间。而程序中的OpenGLES需要渲染以反映进行绘制调用时资源的状态，因此在引用它们的GPU工作负载完成之前无法修改资源。

调试过程

我们曾做出尝试，对引用资源进行代码上的编辑优化，然而当我们尝试修改这部分内容时，会触发该部分的新副本的创建。这将能够一定程度上实现我们的目标，但是会产生大量的CPU开销。

于是我们使用Streamline查明高CPU负载的实例。在图形驱动程序内部libGLES_Mali.so路径函数,视图中看到极高的占用时间。

由于我们希望在不同手机上适配不同帧率运行，所以需要查明libGLES_Mali.so是否在不同机型的设备上都产生了极高的占用时间，此处采用了友盟+U-APM来检测用户在不同机型上的函数占用比例。

经友盟+U-APM自定义异常测试，下列机型会产生高libGLES_Mali.so占用的问题，因此我们需要基于底层硬件的运行情况来解决流畅性问题，同时由于存在问题的机型不止一种，我们需要从内存层面着手，考虑如何调用较少的内存缓存区并及时释放内存。

解决方案及优化

基于前文的分析，我们首先尝试从缓冲区入手进行优化。单缓冲区方案使用glMapBufferRange和GL_MAP_UNSYNCHRONIZED.然后使用单个缓冲区内的子区域构建旋转。这避免了对多个缓冲区的需求，但是这一方案仍然存在一些问题，我们仍需要处理管理子区域依赖项，这一部分的代码给我们带来了额外的工作量。多缓冲区方案我们尝试在系统中创建多个缓冲区，并以循环方式使用缓冲区。通过计算我们得到了适合的缓冲区的数目，在之后的帧中，代码可以去重新使用这些循环缓冲区。由于我们使用了大量的循环缓冲区，那么大量的日志记录和数据库写入是非常有必要的。但是有几个因素会导致此处的性能不佳：１.产生了额外的内存使用和GC压力２.Android操作系统实际上是将日志消息写入日志而并非文件，这需要额外的时间。３.如果只有一次调用，那么这里的性能消耗微乎其微。但是由于使用了循环缓冲区，所以这里需要用到多次调用。我们会在基于c#中的Mono分析器中启用内存分配跟踪函数用于定位问题：

$adbshellsetpropdebug.mono.profilelog:calls,alloc

我们可以看到该方法在每次调用时都花费时间：

MethodcallsummaryTotal(ms)Self(ms)CallsMethodnameMyApp.MainActivity:Log(string,object[])Android.Util.Log:Debug(string,string,object[])Android.Util.Log:Debug(string,string)

在这里定位到我们的日志记录花费了大量时间，我们的下一步方向可能需要改进单个调用，或者寻求全新的解决方案。

log:alloc还让我们看到内存分配；日志调用直接导致了大量的不合理内存分配：

AllocationsummaryBytesCountAverageTypenameSystem.StringSystem.Object[]

硬件加速

最后尝试引入硬件加速，获得了一个新的绘图模型来将应用程序渲染到屏幕上。它引入了DisplayList结构并且记录视图的绘图命令以加快渲染速度。

同时，可以将View渲染到屏幕外缓冲区并随心所欲地修改它而不用担心被引用的问题。此功能主要适用于动画，非常适合解决我们的帧率问题,可以更快地为复杂的视图设置动画。

如果没有图层，在更改动画属性后，动画视图将使其无效。对于复杂的视图，这种失效会传播到所有的子视图，它们反过来会重绘自己。

在使用由硬件支持的视图层后，GPU会为视图创建纹理。因此我们可以在我们的屏幕上为复杂的视图设置动画，并且使动画更加流畅。

代码示例：

//UsingtheObjectanimatorview.setLayerType(View.LAYER_TYPE_HARDWARE,null);ObjectAnimatorobjectAnimator=ObjectAnimator.ofFloat(view,View.TRANSLATION_X,20f);objectAnimator.addListener(newAnimatorListenerAdapter(){

另外还有几点在使用硬件层中仍需注意：

（1）在使用之后进行清理:

硬件层会占用GPU上的空间。在上面的ObjectAnimator代码中，侦听器会在动画结束时移除图层。在Propertyanimator示例中，withLayers()方法会在开始时自动创建图层并在动画结束时将其删除。

（2）需要将硬件层更新可视化：

使用开发人员选项，可以启用“显示硬件层更新”。如果在应用硬件层后更改视图，它将使硬件层无效并将视图重新渲染到该屏幕外缓冲区。

硬件加速优化

但是由此带来了一个问题是，在不需要快速渲染的界面，比如滚动栏,硬件层也会更快地渲染它们。当将ViewPager滚动到两侧时，它的页面在整个滚动阶段会以绿色突出显示。

因此当我滚动ViewPager时，我使用DDMS运行TraceView，按名称对方法调用进行排序，搜索“android/view/View.setLayerType”，然后跟踪它的引用:

ViewPager#enableLayers():privatevoidenableLayers(booleanenable){finalintchildCount=getChildCount();for(inti=0;ichildCount;i++){finalintlayerType=enable?ViewCompat.LAYER_TYPE_HARDWARE:ViewCompat.LAYER_TYPE_NONE;ViewCompat.setLayerType(getChildAt(i),layerType,null);}}

该方法负责为ViewPager的孩子启用/禁用硬件层。它从ViewPaper#setScrollState()调用一次：

privatevoidsetScrollState(intnewState){if(mScrollState==newState){return;}mScrollState=newState;if(mPageTransformer!=null){enableLayers(newState!=SCROLL_STATE_IDLE);}if(mOnPageChangeListener!=null){mOnPageChangeListener.onPageScrollStateChanged(newState);}}

正如代码中所示，当滚动状态为IDLE时硬件被禁用，否则在DRAGGING或SETTLING时启用。PageTransformer旨在“使用动画属性将自定义转换应用于页面视图”（Source）。

基于我们的需求，只在渲染动画的时候启用硬件层，所以我想覆盖ViewPager方法，但由于它们是私有的，我们无法修改这个方法。

所以我采取了另外的解决方案：在ViewPage#setScrollState()上，在调用enableLayers()之后，我们还会调用OnPageChangeListener#onPageScrollStateChanged()。所以我设置了一个监听器，当ViewPager的滚动状态不同于IDLE时，它将所有ViewPager的孩子的图层类型重置为NONE：

OverridepublicvoidonPageScrollStateChanged(intscrollState){//AsmallhacktoremovetheHWlayerthattheviewpageraddtoeachpagewhenscrolling.if(scrollState!=ViewPager.SCROLL_STATE_IDLE){finalintchildCount=your_viewpager.getChildCount();for(inti=0;ichildCount;i++)your_viewpager.getChildAt(i).setLayerType(View.LAYER_TYPE_NONE,null);}}

这样，在ViewPager#setScrollState()为页面设置了一个硬件层之后——我将它们重新设置为NONE，这将禁用硬件层，因此而导致的帧率区别主要显示在Nexus上。