【华为 Hicar 音频卡顿】gc 导致音频卡顿问题分析

2023-11-01 16:50
文章标签 分析 音频 问题 华为 导致 gc 卡顿 hicar

本文主要是介绍【华为 Hicar 音频卡顿】gc 导致音频卡顿问题分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、问题描述：

180S MCE 车机，有线音频卡顿的问题分析如下:
可以看出，车机从手机接收数据时是正常接收的，并未出来延时。
卡顿出现在往StreamBuffer写第36257帧数据时，触发了GC Alloc，该回收内存动作耗时40.910ms，
接着在 GC 动作结束后，重新写第36257帧数据，
导致播放第36257帧数据时出现卡顿。

log 分析如下;（附件中 logcat.log.04 ）

// 从手机接收到第 36257 帧数据
07-31 10:27:18.803  4449  1742 D DMSDP_TRANSPORT_DATASESSION: RTPDataReceiver MSG_TYPE_ACCESSUNIT session=5*******6,timeUs=3737145700,len=335,seqnum=36257,usage=1,nowUs=1598464592// 从手机接收到第 36258 帧数据
07-31 10:27:18.825  4449  1742 D DMSDP_TRANSPORT_DATASESSION: RTPDataReceiver MSG_TYPE_ACCESSUNIT session=5*******6,timeUs=3737166755,len=366,seqnum=36258,usage=1,nowUs=1598487090// 从手机接收到第 36259 帧数据
07-31 10:27:18.849  4449  1742 D DMSDP_TRANSPORT_DATASESSION: RTPDataReceiver MSG_TYPE_ACCESSUNIT session=5*******6,timeUs=3737188088,len=344,seqnum=36259,usage=1,nowUs=1598510692
07-31 10:27:18.864  4449  1742 D DMSDP_TRANSPORT_DATASESSION: RTPDataReceiver MSG_TYPE_ACCESSUNIT session=5*******6,timeUs=3737209633,len=350,seqnum=36260,usage=1,nowUs=1598526215// 播放音乐，写入streamBuffer，开始写第 36257 帧数据 ，触发 GC Alloc  《======================
07-31 10:27:19.063  4449  2106 D DMSDP_TRANSPORT_DATASESSION: AudioPlay audioSdk session=5*******6,type=3,Length=4096,timeUs=3737145700,usage=1   // 《====写第 36257 帧数据=======
07-31 10:27:19.063  4449  2106 D VirtualAudio: WriteStreamBuffer:start WriteStreamBuffer07-31 10:27:19.064  4449  2106 I zygote  : Starting a blocking GC Alloc
07-31 10:27:19.064  4449  2106 I zygote  : Starting a blocking GC Alloc
07-31 10:27:19.070  4449  1734 I zygote  : Waiting for a blocking GC Alloc// 从手机接收到第 36270 帧数据
07-31 10:27:19.075  4449  1742 D DMSDP_TRANSPORT_DATASESSION: RTPDataReceiver MSG_TYPE_ACCESSUNIT session=5*******6,timeUs=3737421944,len=360,seqnum=36270,usage=1,nowUs=1598737115// 从手机接收到第 36271 帧数据
07-31 10:27:19.097  4449  1742 D DMSDP_TRANSPORT_DATASESSION: RTPDataReceiver MSG_TYPE_ACCESSUNIT session=5*******6,timeUs=3737444166,len=337,seqnum=36271,usage=1,nowUs=1598758453// 写第 36257 帧数据时 ，触发的 GC Alloc 动作如下，耗时 40.910ms 
07-31 10:27:19.105  4449  2106 I zygote  : Alloc concurrent copying GC freed 36392(15MB) AllocSpace objects, 0(0B) LOS objects, 93% free, 1274KB/19MB, paused 152us total 40.910ms
07-31 10:27:19.105  4449  1734 I zygote  : WaitForGcToComplete blocked Alloc on HeapTrim for 35.768ms
07-31 10:27:19.105  4449  1734 I zygote  : Starting a blocking GC Alloc
07-31 10:27:19.106  4449  2106 D DMSDP   : VirtualAudioProxy:write cost:0,play positon is:37116928
07-31 10:27:19.106  4449  2106 D DMSDP   : VirtualAudioProxy:writeAvSyncData cost:1,Acts is:3737145700,Apts is:1598767000   //《====重写第 36257 帧数据=======07-31 10:27:19.106  4449  2106 I VirtualAudioJni: WriteStreamToJni:size is:4096
07-31 10:27:19.107  4449  2106 I VirtualAudioJni: WriteStreamBuffer:byteSize is:4096// 播放音乐，写入streamBuffer，开始写第 36258 帧数据 ，正常播放 《======================
07-31 10:27:19.108  4449  2106 D DMSDP_TRANSPORT_DATASESSION: AudioPlay audioSdk session=5*******6,type=3,Length=4096,timeUs=3737166755,usage=1
07-31 10:27:19.108  4449  2106 I VirtualAudio: GetInstance:GetInstance
07-31 10:27:19.108  4449  2106 D VirtualAudio: WriteStreamBuffer:start WriteStreamBuffer
07-31 10:27:19.109  4449  2106 D DMSDP   : VirtualAudioProxy:write cost:0,play positon is:37117120
07-31 10:27:19.110  4449  2106 D DMSDP   : VirtualAudioProxy:writeAvSyncData cost:1,Acts is:3737166755,Apts is:1598770000
07-31 10:27:19.110  4449  2106 I VirtualAudioJni: WriteStreamToJni:size is:4096
07-31 10:27:19.110  4449  2106 I VirtualAudioJni: WriteStreamBuffer:byteSize is:4096// 播放音乐，写入streamBuffer，开始写第 36259 帧数据 ，正常播放 《======================
07-31 10:27:19.111  4449  2106 D DMSDP_TRANSPORT_DATASESSION: AudioPlay audioSdk session=5*******6,type=3,Length=4096,timeUs=3737188088,usage=1
07-31 10:27:19.112  4449  2106 I VirtualAudio: GetInstance:GetInstance
07-31 10:27:19.112  4449  2106 D VirtualAudio: WriteStreamBuffer:start WriteStreamBuffer// 从手机接收到第 36272 帧数据
07-31 10:27:19.119  4449  1742 D DMSDP_TRANSPORT_DATASESSION: RTPDataReceiver MSG_TYPE_ACCESSUNIT session=5*******6,timeUs=3737464844,len=353,seqnum=36272,usage=1,nowUs=1598781401

从问题分析看起来是，HEAP 内存分配失败，但系统明明还有19MB内存，但就是分配不了。

二、分析过程

刚开始疑会不会是内存泄漏，经过分析和内存泄漏无关，
这里记录下使用过的命令：

  1. 查看系统单个进程内存上限：
C:\Users\ciellee>adb shell
msm8937_32go:/ # getprop|grep heapgrowthlimit
[dalvik.vm.heapgrowthlimit]: [128m]
msm8937_32go:/ #
  1. top 命令查看当前系统进程信息
Tasks: 481 total,   7 running, 470 sleeping,   0 stopped,   0 zombie
Mem:   1928552k total,  1723024k used,   205528k free,    32672k buffers
Swap:        0k total,        0k used,        0k free,   663028k cached
800%cpu  85%user  21%nice  69%sys 615%idle   0%iow   0%irq   9%sirq   0%hostPID USER         PR  NI VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS2820 system       10 -10 1.0G  70M  30M S 33.3   3.7  10:19.02 com.huawei.dmsdpdevice388 logd         30  10  22M 7.9M 1.3M S 30.6   0.4   3:29.10 logd2886 u0_a12       10 -10 1.1G  52M  24M S 17.0   2.7   1:03.82 com.huawei.hisight2347 system       20   0 1.1G  79M  30M S 15.3   4.1  39:07.83 com.qinggan.speechservice597 system       20   0  44M  12M 6.3M S  9.0   0.6   4:08.99 hal-server2081 root         30  10 5.1M 1.6M 1.2M S  8.0   0.0   1:08.82 logcat -b main -b system -b crash -b radio -f /private/+
  1. 查看 com.huawei.dmsdpdevice 进程的内存信息
msm8937_32go:/ # dumpsys meminfo com.huawei.dmsdpdevice
Applications Memory Usage (in Kilobytes):
Uptime: 16231918 Realtime: 16231918** MEMINFO in pid 2820 [com.huawei.dmsdpdevice] **Pss  Private  Private  SwapPss     Heap     Heap     HeapTotal    Dirty    Clean    Dirty     Size    Alloc     Free------   ------   ------   ------   ------   ------   ------Native Heap     4177     4156        0        0    12160    10166     1993Dalvik Heap      702      684        0        0    19750     1318    18432Dalvik Other      585      584        0        0Stack      296      296        0        0Ashmem       10        0        0        0Other dev        5        0        4        0.so mmap      484      112       32        0.jar mmap       20       20        0        0.apk mmap     2702      112     2492        0.dex mmap     2996        4     2668        0.oat mmap      241        0       56        0.art mmap     1009      628      184        0Other mmap      132        4       72        0Unknown      353      352        0        0TOTAL    13712     6952     5508        0    31910    11484    20425App SummaryPss(KB)------Java Heap:     1496Native Heap:     4156Code:     5496Stack:      296Graphics:        0Private Other:     1016System:     1252TOTAL:    13712       TOTAL SWAP PSS:        0ObjectsViews:        0         ViewRootImpl:        0AppContexts:        3           Activities:        0Assets:        2        AssetManagers:        2Local Binders:       40        Proxy Binders:       25Parcel memory:        8         Parcel count:       34Death Recipients:        9      OpenSSL Sockets:        0WebViews:        0SQLMEMORY_USED:        0PAGECACHE_OVERFLOW:        0          MALLOC_SIZE:        0msm8937_32go:/ #
  1. 抓取 hprof 文件
C:\Users\ciellee>adb shell am dumpheap 2820 /data/2820_on.hprof
C:\Users\ciellee>adb shell am dumpheap 2820 /data/2820_off.hprof
C:\Users\ciellee>adb shell
msm8937_32go:/ # ls -al data/2820*
-rwxrwx--- 1 root root 27170341 2020-08-03 14:22 data/2820_off.hprof		// 停止放歌时
-rwxrwx--- 1 root root 23286925 2020-08-03 14:22 data/2820_on.hprof			// 正在放歌时
msm8937_32go:/ #//转换 hprof 文件，这样 MemoryAnalyzer 才能打开
C:\Users\ciellee\Desktop\hprof>hprof-conv  2820_off.hprof  2820_off_1.hprof
C:\Users\ciellee\Desktop\hprof>hprof-conv  2820_on.hprof  2820_on_1.hprof

内存分析工具下载地址: http://ftp.yz.yamagata-u.ac.jp/pub/eclipse/mat/1.10.0/rcp/MemoryAnalyzer-1.10.0.20200225-win32.win32.x86_64.zip

需要JDK 环境，下载地址：https://www.oracle.com/java/technologies/javase-jdk14-downloads.html


三、解决方法

经过上面一系列的分析，看起来都没有问题，APK也没有内存泄漏的问题，
问题就是 heap 明明有内存，但就是不让分配。

因为我们车机同时做 8937 和 8950平台，了解到 8950 上没有这样的问题，
最终通过 adb shell getprop > prop.txt 分别获取到 8937 和 8950 平台的 prop 属性。

对比属性发现了如下差异：（左8950, 右8937）
在这里插入图片描述
可以看出，8937 的堆内存配置256M， 这个是按 1 G RAM 的配置来走的，
而 8950平台 的512M 才是按 2G RAM 来配置的。

我们8937的车机Flash 是 16+2 的，需要按 2G RAM 来配置，修改如下：
在这里插入图片描述

导入修改，编译版本后，复测没有GC问题了，也没有卡顿的问题了。



有关heap 的知识我也不怎么懂，有兴趣可以参考下面两篇文章，写得很好

参考：
《关于build.prop原始Dalvik虚拟机设定与调整》
《虚拟内存修改方案dalvik.vm.heapsize 》

这篇关于【华为 Hicar 音频卡顿】gc 导致音频卡顿问题分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/324410。

相关文章

python panda库从基础到高级操作分析

python panda库从基础到高级操作分析

《pythonpanda库从基础到高级操作分析》本文介绍了Pandas库的核心功能,包括处理结构化数据的Series和DataFrame数据结构,数据读取、清洗、分组聚合、合并、时间序列分析及大数据... 目录1. Pandas 概述2. 基本操作：数据读取与查看3. 索引操作：精准定位数据4. Group
阅读更多...
MySQL中EXISTS与IN用法使用与对比分析

MySQL中EXISTS与IN用法使用与对比分析

《MySQL中EXISTS与IN用法使用与对比分析》在MySQL中,EXISTS和IN都用于子查询中根据另一个查询的结果来过滤主查询的记录,本文将基于工作原理、效率和应用场景进行全面对比... 目录一、基本用法详解1. IN 运算符2. EXISTS 运算符二、EXISTS 与 IN 的选择策略三、性能对比
阅读更多...
MySQL 内存使用率常用分析语句

MySQL 内存使用率常用分析语句

《MySQL内存使用率常用分析语句》用户整理了MySQL内存占用过高的分析方法,涵盖操作系统层确认及数据库层bufferpool、内存模块差值、线程状态、performance_schema性能数据... 目录一、 OS层二、 DB层1. 全局情况2. 内存占js用详情最近连续遇到mysql内存占用过高导致
阅读更多...
解决pandas无法读取csv文件数据的问题

解决pandas无法读取csv文件数据的问题

《解决pandas无法读取csv文件数据的问题》本文讲述作者用Pandas读取CSV文件时因参数设置不当导致数据错位,通过调整delimiter和on_bad_lines参数最终解决问题,并强调正确参... 目录一、前言二、问题复现1. 问题2. 通过 on_bad_lines=‘warn’ 跳过异常数据3
阅读更多...
解决RocketMQ的幂等性问题

解决RocketMQ的幂等性问题

《解决RocketMQ的幂等性问题》重复消费因调用链路长、消息发送超时或消费者故障导致,通过生产者消息查询、Redis缓存及消费者唯一主键可以确保幂等性,避免重复处理,本文主要介绍了解决RocketM... 目录造成重复消费的原因解决方法生产者端消费者端代码实现造成重复消费的原因当系统的调用链路比较长的时
阅读更多...
深度解析Nginx日志分析与499状态码问题解决

深度解析Nginx日志分析与499状态码问题解决

《深度解析Nginx日志分析与499状态码问题解决》在Web服务器运维和性能优化过程中,Nginx日志是排查问题的重要依据,本文将围绕Nginx日志分析、499状态码的成因、排查方法及解决方案展开讨论... 目录前言1. Nginx日志基础1.1 Nginx日志存放位置1.2 Nginx日志格式2. 499
阅读更多...
kkFileView启动报错:报错2003端口占用的问题及解决

kkFileView启动报错:报错2003端口占用的问题及解决

《kkFileView启动报错:报错2003端口占用的问题及解决》kkFileView启动报错因office组件2003端口未关闭,解决：查杀占用端口的进程,终止Java进程,使用shutdown.s... 目录原因解决总结kkFileViewjavascript启动报错启动office组件失败，请检查of
阅读更多...
SpringBoot 异常处理/自定义格式校验的问题实例详解

SpringBoot 异常处理/自定义格式校验的问题实例详解

《SpringBoot异常处理/自定义格式校验的问题实例详解》文章探讨SpringBoot中自定义注解校验问题,区分参数级与类级约束触发的异常类型,建议通过@RestControllerAdvice... 目录1. 问题简要描述2. 异常触发1) 参数级别约束2) 类级别约束3. 异常处理1) 字段级别约束
阅读更多...
Olingo分析和实践之EDM 辅助序列化器详解(最佳实践)

Olingo分析和实践之EDM 辅助序列化器详解(最佳实践)

《Olingo分析和实践之EDM辅助序列化器详解(最佳实践)》EDM辅助序列化器是ApacheOlingoOData框架中无需完整EDM模型的智能序列化工具,通过运行时类型推断实现灵活数据转换,适用... 目录概念与定义什么是 EDM 辅助序列化器？核心概念设计目标核心特点1. EDM 信息可选2. 智能类
阅读更多...
Olingo分析和实践之OData框架核心组件初始化(关键步骤)

Olingo分析和实践之OData框架核心组件初始化(关键步骤)

《Olingo分析和实践之OData框架核心组件初始化(关键步骤)》ODataSpringBootService通过初始化OData实例和服务元数据,构建框架核心能力与数据模型结构,实现序列化、URI... 目录概述第一步：OData实例创建1.1 OData.newInstance() 详细分析1.1.1
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2