android渲染优化与实战

Posted 2021-04-27 物联网技术交流平台

android渲染优化

在路尚项目中，以前做的首页功能在开发的时候，首页卡片较多的情况下导致了卡顿，阻塞的用户的点击UI交互，并且在路尚的门户首页，体验很不好，这次定位了问题并进行了一些优化，让APP使用更流畅。

优化前的体验如下图，进入主页面，加载大量卡片时视图会卡顿3s左右。

优化后的体验如下图，基本能瞬时加载完数据。

分析问题

什么原因导致的呢？先了解些需求，仿支付宝以前版本交互：

优化前版本实现方案与布局方式：

可能会问到，这样明显会出问题呀，为什么不使用listView或RecycleView添加Header去做呢？

这里还有其他的坑，地图原因：

• 地图作为头部添加到列表，在列表滑进滑出时会导致地图View的动态销毁和动态添加，导致地图显示异常

• 车辆运动时，会实时的去绘制轨迹和车辆坐标点，手势滑动列表，滑进划出地图绘制不受控制；

由于以上原因使用了这个折中方案。但这样做同样存在些问题，如果卡片较少，还无感知，如果卡片数据较多，200+就能明显感觉到卡顿，使用上不友好，归因为，用户ListView渲染数据问题导致，数据全部一次性渲染耗时较多，违反了listView的View渲染机制，View复用，动态加载；

解决方案

通过listview添加header，menu菜单和地图覆盖heaer，跟随listView滑动进行translate动画，listview复用view动态加载数据，具体如下图所示：

android的一些渲染优化点

Android系统每隔16ms就重新绘制一次Activity，也就是说，我们的应用必须在16ms内完成屏幕刷新的全部逻辑操作， 如果我们的应用没有在16ms内完成屏幕刷新的全部逻辑操作，就会发生卡顿。

渲染原理

渲染操作通常依赖于两个核心组件：CPU与GPU。CPU负责包括Measure，Layout，Record，Execute的计算操作，GPU 负责Rasterization(栅格化)操作。何为栅格化， 如下图。

所谓的栅格化就是绘制那些Button，Shape，Path，String，Bitmap等组件最基础的操作。它把这些组件拆分到不同的像素上进行显示，说的通俗一点，就是解决那些复杂的XML布局文件和标记语言，使之转化成用户能看懂的图像，但是这不是直接转换的，XML布局文件需要在CPU中首先转换为多边形或者纹理，然后再传递给GPU进行格栅化，对于栅格化，跟OpenGL有关，格栅化是一个特别费时的操作。

由以上可以看出，16毫秒的时间主要被两件事情所占用，第一件：CPU计算，将UI对象转换为一系列多边形和纹理；第二件：CPU传递处理数据到GPU。所以很明显，我们要尽可能的缩短这两步的耗时。 　　下图简单说明CPU和GPU的职责工作，以及可能发生的问题和解决方案：

在CPU方面，最常见的性能问题是布局内容在视图层次结构中进行测量、清除并重新创建，引发这种问题通常有两个原因：一是重建显示列表的次数太多，二是花费太多时间作废视图层次并进行不必要的重绘。

路尚首页加载卡顿问题原因就是列表项创建次数太多，导致视图多次Measure；

在GPU方面，最常见的问题是我们所说的过度绘制（overdraw），通常是在像素着色过程中，通过其他工具进行后期着色时浪费了GPU处理时间。

• CPU产生的问题：不必要的布局和失效

• GPU产生的问题：过度绘制（overdraw）

在开发过程中，我们应尽可能的减少布局层次，优化布局，特别是复杂功能页面，避免过度绘制；尽可能的复用VIew，尽可能的避免measure、Layout等计算操作，从而让应用更加流畅。

觉得本文有收获？请转发分享给更多人

关注「 物联网技术交流平台 」，了解更多知识