您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

qq飞车刷喇叭技巧(抖音 Android 性能优化系列：抖音功耗优化实践)

功耗,电流,器件qq飞车刷喇叭技巧(抖音 Android 性能优化系列：抖音功耗优化实践)

发布时间：2016-12-08加入收藏来源：互联网点击：

30HZ 绘制和刷新。否则，如果视频30hz和动画30帧正好交错，最终形成的绘制/刷新频率还是60帧，没有达到最优。我们通过调节各种动画的绘制流程，将动画整体绘制对齐，整体帧率明显降低。
减少过度绘制

过度绘制（Overdraw）描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构里面，如果不可见的 UI 也在做绘制的操作，会导致某些像素区域被绘制了多次，同时也会浪费大量的 CPU 以及 GPU 资源。

可以通过如下来调试过度绘制：打开手机，设置 -> 开发者选项 -> 调试 GPU 过度绘制 -> 显示 GPU 过度绘制。过度绘制的存在会导致界面显示时浪费不必要的资源去渲染看不见的背景，或者对某些像素区域多次绘制，就会导致界面加载或者滑动时的不流畅、掉帧，对于用户体验来说就是 App 特别的卡顿。为了提升用户体验，提升应用的流畅性，优化过度绘制的工作还是很有必要做的。

抖音的 feed 页的过度绘制非常的严重，抖音存在 5 层过度绘制。下图左侧是优化前的过渡绘制情况，右侧是优化后的过度绘制情况，可以看出优化后明显改善。

使用 SurfaceView 视频播放

TextureView 和 SurfaceView 是两个最常用的播放视频控件。TextureView 控件位于主图层上，解码器将视频帧传递到 TextureView 对象还需要 GPU 做一次绘制才能在屏幕上显示，所以其功耗更高，消耗内存更大，CPU 占用率也更高。

控件位置差异如下，可以看出 SurfaceView 拥有独立的 Surface 位于单独的图层上，而 TextureView 位于主图层上。

BufferQueue 是 Android 图形架构的核心，其一侧是生产者，另一侧是消费者。从这方面看，SurfaceView 和 TextureView 的差异如下。容易看出，SurfaceView 流程更短，内存使用更少，也没有 GPU 绘制，功耗更省。

下面是一些 SurfaceView 替换 TextureView 后的收益数据：

CPU 数据上看，SurfaceView 要比 TextureView 优化 8%-13%功耗数据上看，SurfaceView 要比 TextureView 平均功耗低 20mA 左右。硬件绘制和软件绘制

硬件绘制是指通过 GPU 绘制，Android 从 3.0 开始支持硬件加速绘制，它在 UI 显示和绘制效率方面远高于软件绘制，但是 GPU 功耗相对较高。目前是系统默认的绘制方式。

软件绘制是指通过 CPU 实现绘制，Android 上面使用 Skia 图形库来进行绘制。两者差异参见下图。

目前默认是开硬件加速的，可以通过设置 Activity，Application，窗口，View 等方式来指定软件绘制。如果应用需要单独指定某些场景的软件绘制方式，需要对性能、功耗等做好评估。参考链接：https://developer.android.com/guide/topics/graphics/hardware-accel

复杂算法用 NPU 代替 GPU

现在的较新的 SoC 平台都带有专门进行 AI 运算的 NPU 芯片，使用 NPU 代替 GPU 运行一些复杂算法，可以有效的节省 GPU 功耗。如视频的超分算法，可以给用户带来很好的体验。但是超分开启对 GPU 的耗电影响很大，在某些平台测试整机功耗可以高出 100mA，选择用 NPU 替换 GPU 是一种优化方式。

CPU

CPU 的优化是功耗优化里最常见的，我们遇到的大部分的 CPU 异常都是出现了死循环。这里使用上面介绍过的功耗归因工具，都可以很容易的发现死循环问题。此外高频的耗时函数，效果和死循环类似，很容易让 CPU 大核跑到高频点，带来 CPU 功耗增加。另外一个典型的 CPU 问题，就是动画泄漏，泄漏动画大概能带来 20mA 的功耗增加。

由于 CPU 工作耗电很高，手机平台大多会增加各种低功耗的 DSP 来分担 CPU 的工作，减少耗电，如常见视频解码，使用硬解会有更好的功耗表现。

CPU 高负载优化

死循环治理

死循环是我们遇到的最明显的 CPU 异常，通常表现为某一个线程占满了一个大核。线程使用率达到了 100%，手机会很容易发热，卡顿。

这里举一个实际修复的死循环例子，在一段循环打包日志的代码逻辑里，所有 log打包完了，才会break跳出循环。当db query出现了异常，异常处理分支并没有做break，导致出现了死循环。

// 方法逻辑有裁剪，仅贴出主要逻辑private JSONArray packMiscLog() { do { ...... try { cursor = mDb.query(......); int n = cursor.getCount(); ...... if (start_id >= max_id) { break; } } catch (Exception e) { } finally { safeCloseCursor(cursor); } } while (true); return ret;}

对于死循环治理，我们通过实际解决的问题，总结了几种常见的死循环套路。

// 边界条件未满足，无法breakwhile (true) { ... if (shouldExit()) { break }}// 异常处理不妥当，导致死循环while (true) { try { do someting; break; } catch (e) { }}// 消息处理不当，导致Handler线程死循环void handleMessage(Message msg) { //do something handler.sendEmptyMessage(MSG)}

高频耗时函数治理

除了死循环问题，我们遇到的另外一种常见的就是高频的耗时函数。通过线上监控 CPU 异常，我们也找到很多可优化的点。如 md5 压缩算法的耗时，正则表达式的不合理使用，使用 cmd 执行系统命令的耗时等。这种就 case by case 的修复，就有很不错的收益。

后台资源规范使用

Alarm，Wakelock，JobScheduler 的规范使用

最常见的后台 CPU 耗电就是对后台资源的不合理使用。Alarm 的频繁唤醒，wakelock 的长时间不释放，JobScheduler 的频繁执行，都会使 CPU 保持唤醒状态，造成后台耗电。这种行为很容易让系统判断应用为后台异常耗电，通常会被系统清理，或者发出高耗电提醒。

我们可以通过 dumpsys alarm & dumpsys power & dumpsys jobscheduler 查看相关的统计信息，也可以通过 BH 的后台统计来分析自身的使用情况。

参考绿盟的功耗标准，灭屏 Alarm 触发小于过 12 次/h，即 5min 一次，5min 一次在数据业务下可以保证长链接存活，厂商的后台功耗优化也通常会强制对齐 Alarm 为 5min 触发一次。

后台的 Partial Wakelock 通常会被重点限制，非可感知的场景(音乐，导航，运动)等会被厂商强制释放 wakelock。按照绿盟的标准，灭屏下每小时累计持锁小于 5min，从实际经验上看，持 Partial 锁超过 1min 就会被标为 Long 的 wakelock，如果是应用在后台无可感知业务并且频繁持锁，导致系统无法休眠的，系统会触发 forcestop 清理。

某些定时任务可以使用 JobScheduler 来替代 Alarm，Job 的好处是可以组合多种触发条件，选择一个最恰当的时刻让系统调度自己的后台任务。这里建议使用充电 网络可用状态下处理自己的后台任务，对功耗体验是最好的。如果是非充电场景下，设置条件频繁触发 job，同样会带来耗电问题。值得一提的是 Job 执行完要及时结束。因为 JobScheduler 在执行时会持有一个*job/*开头的 wakelock，最长执行时间 10min，如果一直在执行状态不结束，就会导致系统无法休眠。

视频硬解替换软解

硬解通常是用手机平台自带的硬件解码器来做解码从而实现视频播放，基于专用芯片的硬解码速度快、功耗低；软解码方面，通常使用 FFMPEG 内置的 H.264 和 H.265 的软件解码库来做解码。

 4/6   首页 上一页 2 3 4 5 6 下一页 尾页