目录

使用应用过程中卡死，无法响应用户任何操作

问题现象

应用在使用过程中卡死无响应。

背景知识

问题定位

[h2]场景一

  1. 从设备的data->log->memory_leak目录下查看文件名为memleak-kernel-[module]-0-sample.txt的采样文件，从采样文件中可以看到内存类型，内存门限和应用ION内存峰值。从下面的表中可以查看应用ION内存随时间上涨情况。
    memoryName:ion
softThreshold:3000(MB)
hardThreshold:4500(MB)
topMemory:7015044(KB)

time(s) kernelMemory(KB)realtime
0               209             105868          2024/12/04 22:03:21
1               429             113868          2024/12/04 22:07:01
2               649             436416          2024/12/04 22:10:41
3               869             448168          2024/12/04 22:14:21
4               1089            448168          2024/12/04 22:18:01
5               1309            448168          2024/12/04 22:21:41
6               1529            457352          2024/12/04 22:25:21
7               1749            457352          2024/12/04 22:29:01
8               1969            677156          2024/12/04 22:32:41
9               2189            461448          2024/12/04 22:36:21
10              2409            452264          2024/12/04 22:40:01
11              2629            452264          2024/12/04 22:43:41
12              2849            850260          2024/12/04 22:47:21
13              3069            914380          2024/12/04 22:51:01
14              3289            957984          2024/12/04 22:54:41
15              3509            478868          2024/12/04 22:59:22
16              3729            608372          2024/12/04 23:03:02
17              3949            7015044         2024/12/04 23:15:17
  2. 打开内存映射文件memleak-kernel-[module]-0-[timestamp].txt，并筛选出包含"Total dmabuf size of"的行，可以看到应用进程占用的ION内存的情况。
    Total dmabuf size of hiaiserver: 12582912 bytes
Total dmabuf size of CameraDaemon: 4194304 bytes
Total dmabuf size of composer_host: 68116480 bytes
Total dmabuf size of render_service: 5513801728 bytes
  3. 目前因为采用了统一渲染机制，大部分ION内存都是在render_service进程分配使用的，如果发现应用使用ION超标了，那么按照历史经验，高概率怀疑是PixelMap C++对象泄漏。需要排查是否存在PixelMap C++对象泄漏，参考文档ION泄漏。

[h2]场景二

  1. 从memory_leak目录下查看文件名为memleak-native-[process_name]-[pid]-smaps.txt的内存映射文件，搜索关键字LOGGER_MEMCHECK_SMAPS_INFO，查看该进程的smaps汇总信息。
    LOGGER_MEMCHECK_SMAPS_INFO
get info realtime:	2025/04/09 10:58:12

-------------------------------[memory]-------------------------------

Size        Rss         Pss         Clean       Dirty       Clean       Dirty       Swap        SwapPss     Counts                        Name
// ...
160880      18360       13580       9560        0           8800        0           7364        7364        5                             /data/storage/el1/bundle/arkwebcore/libs/arm64/libarkweb_engine.so
34844       2984        2936        48          0           2936        0           968         689         21                            [anon:native_heap:jemalloc meta]                                         
2663248     2655276     2654156     0           2240        0           2653036     0           0           1765                          anon_inode:dev/ashmem/EXTRawData          
128         8           4           0           8           0           0           0           0           2                             anon_inode:dev/ashmem/shared_memory/149B66719F7D3586B4F043474A5845FC
// ...
46069784    2969996     2942807     126900      2860        186740      2653496     113136      81977       6437                          Summary
  2. 从内存映射文件中可以看到，anon_inode:dev/ashmem/EXTRawData(图片共享内存)占用的Pss内存最大，应用出现ashmem内存泄漏，根据EXTRawData关键字基本可以断定是PixelMap对象泄漏，排查方法参考ashmem泄漏。

分析结论

[h2]场景一

应用进程存在ION内存泄漏。

[h2]场景二

应用存在ashmem图片共享内存资源泄漏。

修改建议

[h2]场景一

使用完成后及时释放PixelMap C++对象，可参考API文档release和OH_PixelmapNative_Destroy()，推荐在页面切换、应用退后台等场景下手动释放老页面PixelMap。

[h2]场景二

减少加载图片资源的数量，使用完成后及时释放PixelMap C++对象，可参考API文档release和OH_PixelmapNative_Destroy()。