精华内容
下载资源
问答
  • 整理下Android内存优化常用的几种工具,top命令、adb shell dumpsys meminfo、Memory Profiler、LeakCanary、MAT 1. top top命令是Linux下常用的性能分析工具,能够实时显示系统中各个进程的资源占用状况。 查看top...

    整理下Android内存优化常用的几种工具,top命令、adb shell dumpsys meminfo、Memory Profiler、LeakCanary、MAT

    1. top

    top命令是Linux下常用的性能分析工具,能够实时显示系统中各个进程的资源占用状况。

    查看top命令的用法

    $ adb shell top --help
    usage: top [-Hbq] [-k FIELD,] [-o FIELD,] [-s SORT] [-n NUMBER] [-m LINES] [-d SECONDS] [-p PID,] [-u USER,]
    
    Show process activity in real time.
    
    -H	Show threads
    -k	Fallback sort FIELDS (default -S,-%CPU,-ETIME,-PID)
    -o	Show FIELDS (def PID,USER,PR,NI,VIRT,RES,SHR,S,%CPU,%MEM,TIME+,CMDLINE)
    -O	Add FIELDS (replacing PR,NI,VIRT,RES,SHR,S from default)
    -s	Sort by field number (1-X, default 9)
    -b	Batch mode (no tty)
    -d	Delay SECONDS between each cycle (default 3)
    -m	Maximum number of tasks to show
    -n	Exit after NUMBER iterations
    -p	Show these PIDs
    -u	Show these USERs
    -q	Quiet (no header lines)
    
    Cursor LEFT/RIGHT to change sort, UP/DOWN move list, space to force
    update, R to reverse sort, Q to exit.
    复制代码
    

    使用top命令显示一次进程信息,以便讲解进程信息中各字段的含义

    ^[[41;173RTasks: 754 total,   1 running, 753 sleeping,   0 stopped,   0 zombie
      Mem:      5.5G total,      5.4G used,      165M free,       76M buffers
     Swap:      2.5G total,      789M used,      1.7G free,      2.4G cached
    800%cpu 100%user   3%nice  54%sys 641%idle   0%iow   3%irq   0%sirq   0%host
      PID USER         PR  NI VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS
    15962 u0_a894      10 -10 6.6G 187M  76M S 75.6   3.2   8:16.55 asia.bluepay.cl+
      785 system       -2  -8 325M  13M 7.6M S 29.7   0.2  84:03.91 surfaceflinger
    25255 shell        20   0  35M 2.7M 1.6M R 21.6   0.0   0:00.16 top -n 1
      739 system       -3  -8 177M 3.6M 2.2M S 10.8   0.0  16:00.36 android.hardwar+
    16154 u0_i9086     10 -10 1.3G  40M  19M S  5.4   0.6   0:46.18 com.google.andr+
    13912 u0_a87       20   0  17G 197M  86M S  5.4   3.4  23:56.88 com.tencent.mm
    24789 root         RT  -2    0    0    0 D  2.7   0.0   0:01.36 [mdss_fb0]
    24704 root         20   0    0    0    0 S  2.7   0.0   0:01.20 [kworker/u16:12]
    20096 u0_a94       30  10 6.1G 137M  53M S  2.7   2.3   0:31.45 com.xiaomi.mark+
     2272 system       18  -2 8.7G 407M 267M S  2.7   7.1 191:11.32 system_server
      744 system       RT   0 1.3G 1.6M 1.4M S  2.7   0.0  72:22.41 android.hardwar+
      442 root         RT   0    0    0    0 S  2.7   0.0   5:59.68 [cfinteractive]
      291 root         -3   0    0    0    0 S  2.7   0.0   5:00.17 [kgsl_worker_th+
       10 root         20   0    0    0    0 S  2.7   0.0   1:55.84 [rcuop/0]
        7 root         20   0    0    0    0 S  2.7   0.0   2:46.82 [rcu_preempt]
    25186 shell        20   0  34M 1.9M 1.4M S  0.0   0.0   0:00.71 logcat -v long +
    25181 root         20   0    0    0    0 S  0.0   0.0   0:00.00 [kworker/2:3]
    25137 root         20   0    0    0    0 S  0.0   0.0   0:00.00 [kworker/1:3]
    25118 system       20   0 5.2G  83M  54M S  0.0   1.4   0:01.05 com.android.set+
    24946 u0_a57       20   0 5.1G  60M  37M S  0.0   1.0   0:00.82 com.xiaomi.acco+
    复制代码
    
    第 1 行:进程信息
    • 总共(total):754个
    • 运行中(running)状态:1个
    • 休眠(sleeping)状态:753个
    • 停止(stopped)状态:0个
    • 僵尸(zombie)状态:0个
    第 2 行:内存信息
    • 5.5G total:物理内存总量
    • 5.4G used:使用中的内存量
    • 165M free:空闲内存量
    • 76M buffers: 缓存的内存量
    第 3 行:Swap分区信息
    • 2.5G total:交换区总量
    • 789M used:使用的交换区大小
    • 1.7G free:空闲交换区大小
    • 2.4G cached:缓冲的交换区大小

    内存监控时,可以监控swap交换分区的used,如果这个数值在不断的变化,说明内核在不断进行内存和swap的数据交换,这是内存不够用了。

    第 4 行:CPU信息
    • 800%cpu:8核cpu
    • 100%user:用户进程使用CPU占比
    • 3%nice:优先值为负的进程占比
    • 54%sys:内核进程使用CPU占比
    • 641%idle:除IO等待时间以外的其它等待时间占比
    • 0%iow:IO等待时间占比
    • 3%irq:硬中断时间占比
    • 0%sirq:软中断时间占比
    第 5 行及以下:各进程的状态监控
    • PID:进程id
    • USER:进程所属用户
    • PR:进程优先级
    • NI:nice值,负值表示高优先级,正值表示低优先级
    • VIRT:进程使用的虚拟内存总量,VIRT=SWAP+RES
    • RES:进程使用的、未被换出的物理内存大小,RES=CODE+DATA
    • SHR:共享内存大小
    • S:进程状态
    • %CPU:上次更新到现在的CPU占用时间比
    • %MEM:使用物理内存占比
    • TIME+:进程时间的CPU时间总计,单位1/100秒
    • ARGS:进程名

    2. dumpsys meminfo

    首先了解下Android中最重要的四大内存指标的概念

    指标全称含义等价
    USSUnique Set Size独占物理内存进程独占的内存
    PSSProportional Set Size实际使用物理内存PSS = USS + 按比例包含共享库内存
    RSSResident Set Size实际使用物理内存RSS = USS + 包含共享库内存
    VSSVirtual Set Size虚拟耗用内存VSS = 进程占用内存(包括虚拟耗用) + 共享库(包括比例分配部分)

    我们主要使用USS和PSS来衡量进程的内存使用情况

    dumpsys meminfo命令展示的是系统整体内存情况,内存项按进程进行分类

    $ adb shell dumpsys meminfo
    Applications Memory Usage (in Kilobytes):
    Uptime: 168829244 Realtime: 1465769995
    
    // 根据进程PSS占用值从大到小排序
    Total PSS by process:
        272,029K: system (pid 2272)
        234,043K: com.tencent.mm (pid 13912 / activities)
        185,914K: com.android.systemui (pid 13606)
        107,294K: com.tencent.mm:appbrand0 (pid 5563)
        101,526K: com.tencent.mm:toolsmp (pid 9287)
         96,645K: com.miui.home (pid 15116 / activities)
        ...
    
    // 以oom来划分,会详细列举所有的类别的进程
    Total PSS by OOM adjustment:
        411,619K: Native
             62,553K: android.hardware.camera.provider@2.4-service (pid 730)
             21,630K: logd (pid 579)
             16,179K: surfaceflinger (pid 785)
             ...
        272,029K: System
            272,029K: system (pid 2272)
        361,942K: Persistent
            185,914K: com.android.systemui (pid 13606)
             37,917K: com.android.phone (pid 2836)
             23,510K: com.miui.contentcatcher (pid 3717)
             ...
         36,142K: Persistent Service
             36,142K: com.android.bluetooth (pid 26472)
        101,198K: Foreground
             72,743K: com.miui.securitycenter.remote (pid 4125)
             28,455K: com.android.settings (pid 30919 / activities)
        338,088K: Visible
             96,645K: com.miui.home (pid 15116 / activities)
             46,939K: com.miui.personalassistant (pid 31043)
             36,491K: com.xiaomi.xmsf (pid 4197)
             ...
         47,703K: Perceptible
             17,826K: com.xiaomi.metoknlp (pid 4477)
             10,748K: com.lbe.security.miui (pid 5097)
             10,528K: com.xiaomi.location.fused (pid 4563)
              8,601K: com.miui.mishare.connectivity (pid 4227)
         13,088K: Perceptible Low
             13,088K: com.miui.analytics (pid 19306)
        234,043K: Backup
            234,043K: com.tencent.mm (pid 13912 / activities)
         22,028K: A Services
             22,028K: com.miui.powerkeeper (pid 29762)
        198,787K: Previous
             33,375K: com.android.quicksearchbox (pid 31023)
             23,278K: com.google.android.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:0 (pid 16154)
        171,434K: B Services
             45,962K: com.tencent.mm:push (pid 14095)
             31,514K: com.tencent.mobileqq:MSF (pid 12051)
             22,691K: com.xiaomi.mi_connect_service (pid 22821)
             ...
        538,062K: Cached
            107,294K: com.tencent.mm:appbrand0 (pid 5563)
            101,526K: com.tencent.mm:toolsmp (pid 9287)
             72,112K: com.tencent.mm:tools (pid 9187)
            ...
    
    // 按内存的类别来进行划分
    Total PSS by category:
        692,040K: Native
        328,722K: Dalvik
        199,826K: .art mmap
        129,981K: .oat mmap
        126,624K: .dex mmap
        124,509K: Unknown
         92,666K: .so mmap
         68,189K: Dalvik Other
         53,491K: .apk mmap
         44,104K: Gfx dev
         28,099K: Other mmap
         24,960K: .jar mmap
          7,956K: Ashmem
          3,700K: Stack
          3,368K: Other dev
            450K: .ttf mmap
              4K: Cursor
              0K: EGL mtrack
              0K: GL mtrack
              0K: Other mtrack
    
    // 手机整体内存使用情况
    Total RAM: 5,862,068K (status normal)
     Free RAM: 3,794,646K (  538,062K cached pss + 3,189,244K cached kernel +         0K cached ion +    67,340K free)
     Used RAM: 2,657,473K (2,208,101K used pss +   449,372K kernel)
     Lost RAM:   487,987K
         ZRAM:   219,996K physical used for   826,852K in swap (2,621,436K total swap)
       Tuning: 256 (large 512), oom   322,560K, restore limit   107,520K (high-end-gfx)
    复制代码
    

    查看单个进程的内存信息,命令如下

    adb shell dumpsys meminfo [pid | packageName]
    复制代码
    

    我们查看下微信的内存信息

    $ adb shell dumpsys meminfo com.tencent.mm
    Applications Memory Usage (in Kilobytes):
    Uptime: 169473031 Realtime: 1466413783
    
    ** MEMINFO in pid 13912 [com.tencent.mm] **
                       Pss  Private  Private  SwapPss     Heap     Heap     Heap
                     Total    Dirty    Clean    Dirty     Size    Alloc     Free
                    ------   ------   ------   ------   ------   ------   ------
      Native Heap    51987    51924        0    61931   159044   139335    19708
      Dalvik Heap    74302    74272        8     2633   209170   184594    24576
     Dalvik Other    10136    10136        0      290
            Stack       84       84        0        8
           Ashmem        2        0        0        0
          Gfx dev     8808     8808        0        0
        Other dev      156        0      156        0
         .so mmap     9984      984     7436     8493
        .jar mmap     1428        0      560        0
        .apk mmap     2942        0     1008        0
        .ttf mmap     1221        0     1064        0
        .dex mmap    31302       44    30004      528
        .oat mmap     2688        0      232        0
        .art mmap     2792     2352       40     3334
       Other mmap     6932     2752      632        0
          Unknown     4247     4232        4     7493
            TOTAL   293721   155588    41144    84710   368214   323929    44284
    
     App Summary
                           Pss(KB)
                            ------
               Java Heap:    76664
             Native Heap:    51924
                    Code:    41332
                   Stack:       84
                Graphics:     8808
           Private Other:    17920
                  System:    96989
    
                   TOTAL:   293721       TOTAL SWAP PSS:    84710
    
     Objects
                   Views:      623         ViewRootImpl:        1
             AppContexts:        9           Activities:        1
                  Assets:       12        AssetManagers:        0
           Local Binders:      198        Proxy Binders:      183
           Parcel memory:       46         Parcel count:      185
        Death Recipients:      125      OpenSSL Sockets:        1
                WebViews:        0
    
     SQL
             MEMORY_USED:      156
      PAGECACHE_OVERFLOW:       13          MALLOC_SIZE:      117
    
     DATABASES
          pgsz     dbsz   Lookaside(b)          cache  Dbname
             4       28             46       721/26/4  /data/user/0/com.tencent.mm/databases/Scheduler.db
    
     Asset Allocations
        : 409K
        : 12K
        : 1031K
    复制代码
    
    1. App Summary各项指标解读如下,通常我们需要重点关注Java Heap和Native Heap的大小,如果持续上升,有可能存在内存泄露。
    属性内存组成
    Java HeapDalvik Heap的Private Dirty + .art mmap的Private Dirty&Private Clean
    Native HeapNative Heap的Private Dirty
    Code.so mmap + .jar mmap + .apk mmap + .ttf.mmap + .dex.mmap + .oat mmap的Private Dirty&Private Clean
    StackStack的Private Dirty
    GraphicsGfx dev + EGL mtrack + GL mtrack的Private Dirty&Private Clean
    1. Objects中Views、Activities、AppContexts的异常可以判断有内存泄露,比如刚退出应用,查看Activites是否为0,如果不为0,则有Activity没有销毁。

    3. Memory Profiler

    Memory Profiler是 Android Profiler 中的一个组件,实时图表展示应用内存使用量,识别内存泄露和抖动,提供捕获堆转储,强制GC以及跟踪内存分配的能力。

    Android Profiler官方文档

    4. Leak Canary

    非常好用的内存泄露检测工具,对于Activity/Fragment的内存泄露检测非常方便。

    Square公司开源 官网地址,原理后面单独分析。

    5. MAT

    MAT是Memory Analyzer tool的缩写,是一个非常全面的分析工具,使用相对复杂点。 关于安装和配置有很多很好的文章结束,这里就不单独讲了,后面分析具体案例。

    Android 内存优化篇 - 使用profile 和 MAT 工具进行内存泄漏检测

    使用Android Studio和MAT进行内存泄漏分析

    内存问题高效分析方法

    1. 接入LeakCanary,监控所有Activity和Fragment的释放,App所有功能跑一遍,观察是否有抓到内存泄露的地方,分析引用链找到并解决问题,如此反复,直到LeakCanary检查不到内存泄露。
    2. adb shell dumpsys meminfo命令查看退出界面后Objects的Views和Activities数目,特别是退出App后数目为否为0。
    3. 打开Android Studio Memory Profiler,反复打开关闭页面多次,点击GC,如果内存没有恢复到之前的数值,则可能发生了内存泄露。再点击Profiler的垃圾桶图标旁的heap dump按钮查看当面内存堆栈情况,按包名找到当前测试的Activity,如果存在多份实例,则很可能发生了内存泄露。
    4. 对于可疑的页面dump出内存快照文件,转换后用MAT打开,针对性的分析。
    5. 观察Memory Profiler每个页面打开时的内存波峰和抖动情况,针对性分析。
    6. 开发者选项中打开“不保留后台活动”,App运行一段时间后退到后台,触发GC,dump内存快照。MAT分析静态内容是否有可以优化的地方,比如图片缓存、单例、内存缓存等。
    展开全文
  • Android 内存管理详解

    2021-02-20 18:29:04
    和你一起终身学习,这里是程序员Android经典好文推荐,通过阅读本文,您将收获以下知识点:一、Android 垃圾回收机制(GC)二、共享内存三、内存的申请与回收四、内存限制五、不同Ap...

    和你一起终身学习,这里是程序员Android

    经典好文推荐,通过阅读本文,您将收获以下知识点:

    一、Android 垃圾回收机制(GC)
    二、共享内存
    三、内存的申请与回收
    四、内存限制
    五、不同App切换时的内存管理

    Android Runtime(ART)Dalvik虚拟机使用 分页 和 内存映射 来管理内存。这意味着应用程序修改的任何内存(无论是通过分配新对象通过映射页面)都将保留在RAM中,并且不能被分页。
    应用程序释放内存的唯一方法是释放应用程序持有的对象引用,即使垃圾收集器回收(GC)回收内存 。
    比如:如果系统想要在其他地方使用该内存,则可以将任何未经修改的映射到mmap中文件(例如代码)分页出RAM

    本页面介绍了Android如何管理应用程序进程和内存分配。有关如何在应用程序中更高效地管理内存的更多信息,请参阅管理您的应用程序的内存。

    一、Android 垃圾回收机制(GC)

    ART 或 Dalvik虚拟机的托管内存环境会跟踪每个内存分配情况。一旦它确定一段内存不再被程序使用,它将它释放回堆(Heap)中,并且不需要程序员的任何干预。回收托管内存环境中未使用内存的机制称为垃圾回收(GC)

    1.垃圾回收机制的目的

    垃圾回收机制的目的:
    1.在程序中查找将来不再使用的数据对象(Object)
    2.回收这些对象所占用的内存资源。

    Android 内存是一个典型的堆内存(Heap),这意味着系统会根据被分配的对象的预期寿命和大小有不同的分配桶。
    例如,最近分配的对象属于年轻一代。当一个对象保持足够的活动时间时,它可以被提升到一个老一代,然后是一个永久的时代。

    每个堆的生成都有自己占用内存的上限。任何时候一旦内存即将被填满,系统就会执行一个垃圾回收事件去试图释放内存。垃圾收集的持续时间取决于它正在回收的那个对象以及回收多少个正在活跃的对象。

    尽管垃圾器回收的速度相当快,但它仍然可能会影响应用程序的性能。并且你一般不会控制垃圾器回收你代码事件的时间。
    系统垃圾回收机制具有一定运行中的标准,这个标准主要用于确定何时执行垃圾收集。当条件满足时,系统停止执行进程并开始垃圾收集。

    如果垃圾回收发生在密集的处理循环(如动画)或音乐播放期间,可能会增加处理时间。这种增长可能会推动您的应用程序执行代码超过推荐的16ms阈值,以实现高效流畅的帧渲染。

    此外,您的代码流可能会执行各种强制垃圾收集事件的工作,或使其持续时间超过正常。例如,如果在alpha混合动画的每个帧期间在for循环的最内部分配了多个对象,则可能会占用大量的内存堆,并使用大量对象。在这种情况下,垃圾收集器将执行多个垃圾收集事件,并可能降低应用程序的性能。

    有关垃圾收集的更多一般信息,请参阅垃圾收集。

    二、共享内存

    为了适应不同的RAM需求,Android 尝试在不同进程之间共享内存,共享内存的方法如下:

    1. APP共享Framework框架代码以及资源

    每个APP的进程都是从Zygote进程中分离出来的。
    Zygote 进程:
    Zygote进程是在系统启动并加载Framwork框架代码和资源(如Activity Theme)时开始。要启动一个新的应用程序进程,系统会从Zygote进程fork分离出来,然后在新进程中加载并运行应用程序的代码。这种方法允许大部分分配给Framework框架代码和资源的RAM页面与所有应用程序进程之间共享。

    2. 大多数静态数据可以跨进程共享

    大多数静态数据被映射到一个进程。这种技术允许数据在进程之间共享,并允许在需要时将其分页。示例静态数据包括:Dalvik代码(通过将其放置在用于直接映射的预链接.odex文件中),应用程序资源(通过将资源表设计为可以被映射的结构以及通过对齐APK的zip条目) 以及.so文件中的本地代码等传统项目元素。

    3. Android使用显式分配的共享内存区域(使用ashmem或gralloc)共享同一个动态RAM。

    例如,窗口表面使用应用程序和屏幕合成器之间的共享内存,游标缓冲区使用内容提供者和客户端之间的共享内存。

    由于共享内存的广泛使用,确定您的应用使用多少内存需要谨慎。在调查您的RAM使用情况中讨论了正确确定应用程序内存使用情况的技巧。如需获取更多内容,请看RAM使用情况分析详解。

    三、APP内存的申请与回收

    Dalvik 虚拟机会限制每个应用程序进程的虚拟内存范围。它定义了逻辑堆的大小,并且可以根据需要增长,但只能达到系统为每个应用程序定义的限制。

    堆的逻辑大小与堆使用的物理内存量不同。在检查应用程序的堆时,Android 会计算一个名为“比例集合大小** Proportion Set Size ”(PSS)** 的值,该值与其他进程共享的脏页面(Page)和干净页面(Page),并且数量与多少应用程序共享该RAM成正比。(PSS)总数是系统认为是您的物理内存的足迹。有关PSS的更多信息,请参阅RAM使用情况指南

    Dalvik堆不压缩堆的逻辑大小,这意味着 Android不会整理堆以关闭空间。当堆的末尾有未使用的空间时,Android只能缩小逻辑堆的大小。然而,系统仍然可以减少堆使用的物理内存。在垃圾收集之后,Dalvik遍历堆并找到未使用的页面,然后使用madvise将这些页面返回给内核。
    因此,成对的大块分配和释放应该会导致所有(或几乎全部)所使用的物理内存的回收。但是,从小分配中回收内存的效率可能会低得多,因为用于小分配的页面仍可能与尚未释放的其他内容共享。

    四、APP内存限制

    为了维护一个主要的多功能环境,Android 对每个应用程序的堆大小设定了一个硬限制。确切的堆大小限制根据设备有多少RAM可用而有所不同。如果您的应用程序已达到堆容量并尝试分配更多内存,则可能会收到OutOfMemoryError

    在某些情况下,您可能需要查询系统以确定在当前设备上有多少堆空间可用 。
    例如,确定有多少数据可以安全地保留在缓存中。你可以通过调用getMemoryClass()来查询这个数字。此方法返回一个整数,指示可用于应用程序堆的兆字节数。

    五、不同App切换时的内存管理

    当用户在应用程序之间进行切换时,Android会保留不在前台的应用程序(即对用户不可见,或者在最近最少使用(LRU)缓存中运行诸如音乐播放之类的前台服务)。例如,当用户第一次启动应用程序时,会为其创建一个进程; 但是当用户离开应用程序时,该过程不会退出。系统保持进程缓存。如果用户稍后返回到应用程序,系统将重新使用该进程,从而使应用程序切换更快。

    如果您的应用程序具有缓存的进程,并且保留了当前不需要的内存,那么您的应用程序(即使用户不使用它)也会影响系统的整体性能。由于系统内存不足,它会以最近使用最少的进程开始,终止LRU缓存中的进程。系统也考虑到保存最多内存的进程,并可以终止它们以释放RAM

    注意:当系统开始在LRU缓存中查杀进程时,它主要是自下而上的。系统也考虑哪些进程消耗更多的内存,从而为系统提供更多的内存增益。在整个LRU列表中消耗的内存越少,留在列表中的机会就越好,并能够快速恢复。

    友情推荐:

    Android 开发干货集锦

    至此,本篇已结束。转载网络的文章,小编觉得很优秀,欢迎点击阅读原文,支持原创作者,如有侵权,恳请联系小编删除,欢迎您的建议与指正。同时期待您的关注,感谢您的阅读,谢谢!

    点个在看,方便您使用时快速查找!

    展开全文
  • Android内存裁剪

    2021-06-10 12:42:33
    底层内存裁剪的一些思路:主要思路是针对功能需求,裁剪冗余或无用的功能项,可以从以下几个方面下手:1、kernel config的逐个排查,去掉冗余的项结合功能需求去掉无用的功能模块,非必要的调试选项,比如安全/加密...

    底层内存裁剪的一些思路:

    主要思路是针对功能需求,裁剪冗余或无用的功能项,可以从以下几个方面下手:

    1、kernel config的逐个排查,去掉冗余的项

    结合功能需求去掉无用的功能模块,非必要的调试选项,比如安全/加密部分,USB的多余外设支持,FS的多余支持

    2、缩减reserved的内存占用

    从dts中声明 reserved 或代码中申请reserved的部分下手

    3、缩减未进入内存管理的内存占用

    找出 物理内存 - MemTotal(/proc/meminfo中第一行) 被哪些地方使用, 看能否裁剪一些

    4、从占用较大的内存块下手,找到谁在使用, 看能否裁剪一些

    /proc/vmallocinfo 中较大的部分

    /proc/slabinfo 中较大的部分

    5.从多余的native进程下手

    从adb shell ps -A中排查非必要的进程和服务,进行裁剪

    如何查看kernel占用的内存:

    1、未进入内存管理的内存

    即是 物理内存 - MemTotal(/proc/meminfo中第一行) 的部分。

    2、kernel reserved内存

    kernel reserved的内存,即是kernel log中Memory:的 reserved部分的大小

    举例如下:

    //代码占用 = kernel code + rwdata + rodata + init + bss

    //reserved = reserved + cma-reserved

    //关系:reserved_pages(63776K) = physpages(2045952K) - totalram_pages(1982176K) - totalcma_pages(0K)

    [ 0.000000] -(0)[0:swapper]Memory: 1982176K/2045952K available (12924K kernel code, 1384K rwdata, 4392K rodata, 960K init, 5936K bss, 63776K reserved, 0K cma-reserved)

    3、kernel运行中分配的内存

    对应dumpsys meminfo 中 Used RAM: 中 kernel部分的大小

    这里kernel的占用是从 /proc/meminfo 和 /proc/vmallocinfo 中统计而来,具体上:

    kernel used = Shmem + SUnreclaim + VmallocUsed + PageTables + KernelStack

    Shmem,SUnreclaim,PageTables,KernelStack对应 /proc/meminfo 中的具体字段

    VmallocUsed 是统计/proc/vmallocinfo中除ioremap,map_lowmem,vm_map_ram之外的和

    举例如下:

    Total RAM: 1,983,136K (status critical)

    Free RAM: 1,116,972K ( 0K cached pss + 203,672K cached kernel + 913,300K free)

    Used RAM: 873,491K ( 629,723K used pss + 243,768K kernel)

    Lost RAM: -7,331K

    ZRAM: 4K physical used for 0K in swap (1,048,572K total swap)

    Tuning: 128 (large 256), oom 322,560K, restore limit 107,520K (high-end-gfx)

    展开全文
  • Android内存抖动分析

    2021-06-09 01:08:12
    1.为什么会内存抖动简单说就是在短时间内有大量的gc操作2.举个例子public class MainActivity extends AppCompatActivity {private String result = "";@Overrideprotected void onCreate(Bundle savedInstanceState...

    1.为什么会内存抖动

    简单说就是在短时间内有大量的gc操作

    2.举个例子

    public class MainActivity extends AppCompatActivity {

    private String result = "";

    @Override

    protected void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

    Button bt = (Button) findViewById(R.id.bt);

    //点击按钮进行字符串拼接操作

    bt.setOnClickListener(new View.OnClickListener() {

    @Override

    public void onClick(View view) {

    for (int i = 0; i < 1000000; i++) {

    result = result +i;

    }

    }

    });

    }

    }

    点击按钮进行字符串的拼接

    我们知道String 类型的变量是不变的

    比如

    String value1 = "a";//创建一个对象指向value1

    value1 = value1 + "b";//再次创建一个对象指向value1

    上面的例子循环了1000000次,就会创建1000000个对象,这么多对象创建出来又被回收势必会引起内存抖动,我们通过日志或者monitors可以分析出来

    com.dgtech.myapplication I/art: Background sticky concurrent mark sweep GC freed 26(864B) AllocSpace objects, 35(19MB) LOS objects, 18% free, 12MB/15MB, paused 5.530ms total 23.313ms

    com.dgtech.myapplication I/art: Background sticky concurrent mark sweep GC freed 31(1040B) AllocSpace objects, 41(23MB) LOS objects, 0% free, 76MB/76MB, paused 5.250ms total 40.184ms

    com.dgtech.myapplication I/art: Background partial concurrent mark sweep GC freed 114(3KB) AllocSpace objects, 159(104MB) LOS objects, 7% free, 50MB/54MB, paused 1.995ms total 107.696ms

    com.dgtech.myapplication I/art: Background partial concurrent mark sweep GC freed 36(1048B) AllocSpace objects, 42(29MB) LOS objects, 6% free, 59MB/63MB, paused 13.771ms total 57.703ms

    com.dgtech.myapplication I/art: Background sticky concurrent mark sweep GC freed 14(480B) AllocSpace objects, 17(12MB) LOS objects, 1% free, 15MB/15MB, paused 5.508ms total 12.141ms

    com.dgtech.myapplication I/art: Background sticky concurrent mark sweep GC freed 20(672B) AllocSpace objects, 27(19MB) LOS objects, 0% free, 16MB/16MB, paused 5.435ms total 19.526ms

    当有大量日志连续打印以上类似内容时,说明内存有抖动,我们需要检查代码,或者使用更直观的方式来看:

    acd82503a9e5

    Monitors

    从Monitors的监控来看,内存一开始是平稳的,当点击拼接字符串的按钮后变开始抖动

    注:有的时候我们无法选择要调试的程序,就像这样:

    acd82503a9e5

    异常情况

    这个时候我们需要选择tools - Android - Enable ADB Integration

    展开全文
  • APP测试中难免会有各种显式或者隐式的内存泄漏(Memory Leak)问题,如果不及时发现处理,可能会因为内存泄漏导致各种奇怪的问题(如,卡顿和闪退),甚至可能出现因内存不足(Out of Memory,简称OOM)而导致APP崩溃。...
  • Android内存分析

    2021-05-27 04:23:56
    名词解释VSS – Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)RSS – Resident Set Size 实际使用物理内存(包含共享库占用的内存)PSS – Proportional Set Size 实际使用的物理内存(按比例分配共享库占用的...
  • 内存泄漏是引起Android应用崩溃常见的原因,每个Android开发人员都应该明白怎么避免发送。常用的分析内存的工具有 Android Profiler 和 LeakCanary。Android Profiler 和 LeakCanary。Android Profiler 是Android ...
  • 如果使用DDMS确实发现了我们的程序中存在内存泄漏,那又如何定位到具体出现问题的代码片段,最终找到问题所在呢?如果从头到尾的分析代码逻辑,那肯定 会把人逼疯,特别是在维护别人写的代码的时候。这里介绍一个极...
  • 1,java内存使用划分堆内存(Heap Memory): 存放Java对象 非堆内存(Non-Heap Memory): 存放类加载信息和其它meta-data 其它(Other): 存放JVM 自身代码等。内存回收(GC)主要处理的是堆内存。2,堆内存模型堆内存...
  • android里,activity后台运行是可以被系统关闭的,当空间不够时,所以计算可用空间包括...思路:可用空间 = 闲置空间 + 缓存 + 所有后台非service进程代码://通过读/proc/meminfo得到内存总大小memInfoReader = new...
  • 首先了解什么是内存泄露htmlhttp://liuwangshu.cn/application/performance/ram-3-memory-leak.htmlandroid1Leakcancary的优点LeakCanary是一个可视化的内存泄露分析工具,他具有如下优点app·简单:只需设置一段...
  • android内存泄漏定位与优化(java篇)内存泄漏:我们的应用内存不在GC可以掌控之内1 垃圾回收机制(GC)对象引用为空的时候,会被GC回收;总结:java的内存回收机制,莫对象没有任何引用的时候,就会被回收;2 GC回收...
  • 1.打开AndroidStudio的Profile1.在菜单栏依次点击 View > Tool Windows > Profiler2.在Profile窗口点击左上角的"+"图标,添加要分析的进程3.点击MEMORY进入内存详情界面如下图所示一个应用的内存包括:java,...
  • 堆是由垃圾回收来负责的,堆的优势是可以动态地分配内存大小,生存期也不必事先告诉编译器,因为它是在运行时动态分配内存的,Java的垃圾收集器会自动收走这些不再使用的数据。但缺点是,由于要在运行时动态分配内存...
  • 前言在日常的Android开发中,每个开发者或多或少都会遇到过OutOfMemoryError这样崩溃信息。如果工程稍微大一些,在monkey测试的崩溃日志也是比较常见的一种。如下是比较常见的一些报错信息:Android:java.lang....
  • 从工具条中选“Update heap”按钮,给这个程序设置上“heap Updates”,然后在Heap视图中点击Cause GC就可以实时显示这个程序的一些内存和cpu的使用情况了。image说明: a) 点击“Cause GC”按钮相当于向虚拟机请求...
  • Android内存分析总结

    2021-02-27 08:50:12
    前一段时间陆陆续续写了一下Android内存Debug的一些手段,现在整理一下,在这边提供一个链接,也做一下简单的总结。1.一般来说,分析系统的内存情况可以用adb shell dumpsys meminfo查看当时的系统内存状况。接着...
  • 1. Android 内存现状 Facebook 有一个叫 device-year-class 的开源库,它会用年份来区分设备的性能 2. Android 内存空间会引发的问题 PSS : Proportional Set Size 实际使用的物理内存(比例分配共享库占用的...
  • Android内存优化是APP稳定运行的重要一环,开发过程中如果代码写的过于随意,很容易造成内存泄漏,多次累积之后,便会产生OOM,进而造成app崩溃。本文介绍了内存泄漏的相关知识和检测工具LeakCanary的实现原理,同时...
  • Android系统会根据不同等级的内存使用情况,调用这个函数,并传入对应的等级. 当你的应用程序UI不可见的时候,清除部分缓存以减少内存的使用.减少进程被杀几率. public class TestActivity extends Activity{ ...
  • Android内存优化的5R法则 胡凯 Androidhukai.me 腾讯内存管理基础 – 共享内存 K Linear I Zygote Alloc V L Alloc A Space Space new ArrayList D Space Non Main Large T Zygote Image R Moving Alloc Obj A Space...
  • 本篇文章已授权微信公众号 guolin_blog (郭霖)独家发布前言先通俗理解下内存泄漏,内存溢出,OOM,GC回收这几个概念。把app的堆内存空间想成了一个杯子,内存就是里面的水。当你的app启动后,系统会分配给app一个堆...
  • 监控android内存被dump实现

    千次阅读 2021-08-06 10:58:47
    监控原理 通常加固会在程序运行前完成对text...一旦发生触发了事件就结束进程来阻止android内存被dump。 代码实现 //监控内存是否被修改事件 void thread_watchIntifyDump() { char dirName[NAME_MAX]={0}; //用于监
  • android内存碎片问题优化梳理

    千次阅读 2021-04-20 10:19:44
    内存碎片对相机性能的影响 这里说的碎片是物理内存碎片,而且是外部碎片问题。先说下为什么要关注内存碎片,因为手机系统的内存碎片严重会对相机性能带来了如下不好的影响: 1: 首先是相机的内存分配性能会受影响...
  • 先总结一下,再说OnClickListener是匿名内部类为什么不导致android内存泄漏的问题。MemoryLeak原因就是,生命周期长的类实例(A)所引用的生命周期短的类(B)实例,在B已经结束生命周期了需要释放时没有释放还被A引用着...
  • 内存溢出的主要导致原因有如下几类:应用代码存在内存泄露,长时间积累无法释放导致OOM;应用的某些逻辑操作疯狂的消耗掉大量内存(譬如加载一张不经过处理的超大超高清图片等)导致超过阈值OOM;可以发现,无论哪种...
  • 可以检测这些问题:使用已经释放的内存(野指针)、堆内存越界(读写)、栈内存越界读写、全局变量越界(读写)、函数返回局部变量、内存泄漏。 Asan工具主要由两部分组成分别是编译时插桩模块和运行时库 运行时库会...
  • iOS与Android内存机制有哪些不同,说到这就不得不聊聊iOS和Android系统内存管理机制上的区别。首先要澄清,系统缓慢与卡顿并不是因为占用内存太多了,而是因为系统占用不到内存了,所以在内存和外存数据交换时就会...
  • 傻大方提要:【「Android」UE手游研发中,如何做好Android内存优化?】编者按在大年夜多半人的印象里,用UE引擎制造出来的游戏实际占用内存会比较高。腾讯游戏学院专家Leonn,将和大年夜家分享基于UE的手游开辟中,...
  • 即便现在的Glide提供了不错的内存回收能力,但是依然存在了App使用内存越来越大的问题。 方案: 检测App切换到后台后,目前先只清除图片相关内存。 实践: 查看当前App使用内存大小 adb shell dumpsys meminfo...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 355,281
精华内容 142,112
关键字:

android内存

友情链接: zmqb.rar