androidmemory
Ⅰ android为什么要内存优化
android为什么要内存优化是为了防止Android的内存溢出
Android的内存溢出是如何发生的?
Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此所能利用的内存空间是有限的。如果内存占用超过了一定的水平就会出现OutOfMemory的错误。
为什么会出现内存不够用的情况呢？原因主要有两个：由于程序的失误，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。
保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。
在android的开发中，要时刻主要内存的分配和垃圾回收，因为系统为每一个dalvik虚拟机分配的内存是有限的，在google的G1中，分配的最大堆大小只有16M，后来的机器一般都为24M，实在是少的可怜。这样就需要在开发过程中要时刻注意。不要因为自己的代码问题而造成OOM错误。
Android的优化方式
Android的程序由java语言编写，所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的。C／C++中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。
那么GC怎么能够确认某一个对象是不是已经被废弃了呢？Java采用了有向图的原理。Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么认为这个(这些)对象不再被引用，可以被GC回收
Ⅱ android log里的memory info怎么看
以文本的形式打开，就可以看内容了。
Ⅲ android 应用程序 lowmemorykiller 怎么解决
1、固件、刷固件
固件是指固化的软件，英文为firmware，它是把某个系统程序写入到特定的硬件系统中的flashROM。手机固件相当于手机的系统，刷新固件就相当于刷系统。不同的手机对应不同的固件，在刷固件前应该充分了解当前固件和所刷固件的优点缺点和兼容性， 并做好充分的准备。
2、ROM（包）智能手机配置中的ROM指的是EEProm(电擦除可写只读存储器)类似于计算机的硬盘，手机里能存多少东西就看他的容量了。底包+更新包统称为一个ROM包。
3、固件版本
固件版本是指官方发布的固件的版本号！里面包含了应用部分的更新和基带部分的更新，官方新固件的推出的主要目的是为了修复已往固件中存在的BUG以及优化相关性能。
4、Recovery
笼统的说，就是一个刷机的工程界面。如果你装过系统，你可能知道dos界面或者winPE，安装了Recovery相当于给系统安了一个dos界面。在recovery界面可以选择安装系统，清空数据，ghost备份系统，恢复系统等等。刷recovery与刷rom不冲突。
5、Root
Root权限跟我们在Windows系统下的Administrator权限可以理解成一个概念 。Root是Android系统中的超级管理员用户帐户,该帐户拥有整个系统至高无上的权利,所有对象他都可以操作。只有拥有了这个权限我们才可以将原版系统刷新为改版的各种系统，比如简体中文系统。
6、后台
Android程序对于RAM的消耗很厉害，这是因为Android实际上是基于Java的，每个打开的应用程序都带有一个Java虚拟机，因此相比其他系统会消耗更多的RAM，但这样做有很大好处——单一的程序崩溃并不会影响到系统的稳定性，算是一个有益的Android特性。Android平台在保证多任务的同时兼具了兼顾了稳定性和速度，但正是由于其他平台给用户带来的思维定势，让很多Android用户认为后台只要开多了自然会变慢，自然会缩短续航时间，但其实用户大可不必在这方面费脑筋。
7、回收机制
Android系统在这方面的处理同样是自动化的——内存回收机制，这个机制是由linux内核中的LowMemory Killer完成的。具体来讲就是，Android系统有一个按重要性从高到低排列的表格，所有应用程序按照重要度高低对号入座（分为FOREGROUD_APP，VISIBLE_APP，SECONDARY_SERVER，HOME_APPHIDDEN_APP，CONTENT_PROVIDER，EMPTY_APP等），位于这个排行榜末尾的程序自然就是Android下手的主要对象。例如六个程序分别属于这六个类型，从高到底排为1，2，3，4，5，6，对应的内存阀值分别为8MB，12MB，20MB，32MB，48MB，60MB（假设），当空闲RAM小于48MB的时候，系统会杀掉5和6；当空闲RAM小于20MB的时候，系统会杀掉3到6的程序，此处笔者简化了此机制，实际上是所有程序类型和内存阀值一一对应，严密执行的。因此，用户在使用一般应用程序或待机的时候，完全可以把内存管理的工作交由Android系统来完成。当然，在需要开启大型游戏的时候，杀进程还是有用的，更多空余的RAM能够提高游戏启动速度。
8、Flash和跑分
ndroid2.2并不是支持Flash的充要条件——除了Android2.2，一个支持Armv7指令集的CPU是必须的，这也是很多Android2.2机型不支持Flash的原因，所以，不要被某些参数给忽悠了。跑分软件实际上并不够客观，优化的好坏、固件的版本等因素会很大程度左右测试结果，因此建议大家客观看待这些跑分结果。（LZ注：再次重申跑分软件只用来做横向对比，并不能说明实际问题，推荐跑分软件：安兔兔）
9、耗电和自启动
后台进程，例如微信（需要推送）或者音乐播放（需要后台运行）等应用，这些应用再被切换到后台时会自动开启一个Service服务，这些附带Service服务的应用才会消耗CPU资源以及电力。没有Service的一般应用基本是不消耗CPU资源和电力的。Android手机最费电还是屏幕，尽可能减少屏幕开启时间和调低屏幕亮度，是延长待机时间最有效直接的方式。关于应用程序自启动，可以确定的是，这些自动启动的服务都是插件必须、同步需要，或后台正在运行的Service对应的应用程序，有些时候后台程序并不是真的启动，而是保持了暂停状态，以便用户最快速进入，这是上面提到的Android系统的一个优点，只要启动的程序没有Service项，它们实际上都只是出于暂停状态，并不会消耗CPU资源或者电力，和这些程序较劲其实是没有任何意义的。
10、App2SD和程序卸载
关于App2SD，使用PC的经验告诉用户，系统盘空间越小PC速度会越慢，因此很多人开始尝试开启App2SD，甚至对存储卡分区，希望将程序转移到SD卡上面，为Android手机省出一定的空间，希望提高手机运行的速度，但这样做也有很大的弊端，第一是会导致耗电的增加，第二是部分插件失效，第三是程序运行效率下降，此外对SD卡也提出了较高的要求。关于程序卸载，有些厂商或运营商会将修改版的固件刷入手机，固件中的程序已经属于系统级，自然很难删除，用户只有将自己的手机Root，然后才能进行系统级别的修改。
Ⅳ Android studio怎么监控内存
参考如下内容:
AndroidStudio 中Memory控件台（显示器）提供了一个内存监视器。我们可以通过它方便地查看应用程序的性能和内存使用情况，从而也就可以找到需要释放对象，查找内存泄漏等。
熟悉Memory界面
打开日志控制台,有一个标签Memory ,我们可以在这个界面分析当前程序使用的内存情况。
运行要监控的程序（APP）后，打开Android Monitor控制台窗口，可以看到Memory控制台。 点击Memory控制台上Enable按钮，Memory控制台开始显示正在运行时程序的Memory使用情况。如上图中显示：
AndroidStudio Memory的功能：
启动与关闭Memory监测按钮
手动触发GC按钮
mp java heap 按钮,点击Android Studio就开始干活了，成功后会自动打开 hprof文件。
start(stop) allocation tracking按钮先点击一次，然后会看到Memory
Recorder开始转动，然后自己开始在APP上面做相应的操作。在合适的时间再点一次，结束记录。
Ⅳ android studio中的memory怎么用
memory可以查看内存的使用情况，来调试软件界面的影响速度的地方
Ⅵ 如何突破24M内存的限制，为Android程序分配到更多内存
一个Android的应用最多使用16M的内存,如果要突破这个限制,则要使用c/c++编写JNI,即直接调用底层的函数来处理.linux也是用c/c++来编写的,因此有非常非常多的函数库可以调用.
Ⅶ android studio memory怎么看
启动与关闭Memory监测按钮
手动触发GC按钮
mp java heap 按钮,点击Android Studio就开始干活了，成功后会自动打开 hprof文件。
start(stop) allocation tracking按钮先点击一次，然后会看到Memory Recorder开始转动，然后自己开始在APP上面做相应的操作。在合适的时间再点一次，结束记录。
最后这个问号按钮，点击后进入官方介绍文档。
Ⅷ 如何检查 Android 应用的内存使用情况
解析日志信息
最简单的调查应用内存使用情况的地方就是Dalvik日志信息。可以在logcat（输出信息可以在Device Monitor或者IDE中查看到，例如Eclipse和Android Studio）中找到这些日志信息。每次有垃圾回收发生，logcat会打印出带有下面信息的日志消息：
Java
1
D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>
GC原因
触发垃圾回收执行的原因和垃圾回收的类型。原因主要包括：
GC_CONCURRENT
并发垃圾回收，当堆开始填满时触发来释放内存。
GC_FOR_MALLOC
堆已经满了时应用再去尝试分配内存触发的垃圾回收，这时系统必须暂停应用运行来回收内存。
GC_HPROF_DUMP_HEAP
创建HPROF文件来分析应用时触发的垃圾回收。
GC_EXPLICIT
显式垃圾回收，例如当调用 gc()（应该避免手动调用而是要让垃圾回收器在需要时主动调用）时会触发。
GC_EXTERNAL_ALLOC
这种只会在API 10和更低的版本（新版本内存都只在Dalvik堆中分配）中会有。回收外部分配的内存（例如存储在本地内存或NIO字节缓冲区的像素数据）。
释放数量
执行垃圾回收后内存释放的数量。
堆状态
空闲的百分比和（活动对象的数量）/（总的堆大小）。
外部内存状态
API 10和更低版本中的外部分配的内存（分配的内存大小）/（回收发生时的限制值）。
暂停时间
越大的堆的暂停时间就越长。并发回收暂停时间分为两部分：一部分在回收开始时，另一部分在回收将近结束时。
例如：
Java
1
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/K, paused 2ms+2ms
随着这些日志消息的增多，注意堆状态（上面例子中的3571K/9991K）的变化。如果值一直增大并且不会减小下来，那么就可能有内存泄露了。
查看堆的更新
为了得到应用内存的使用类型和时间，可以在Device Monitor中实时查看应用堆的更新：
1.打开Device Monitor。
从<sdk>/tools/路径下加载monitor工具。
2.在Debug Monitor窗口，从左边的进程列表中选择要查看的应用进程。
3.点击进程列表上面的Update Heap。
4.在右侧面板中选择Heap标签页。
Heap视图显示了堆内存使用的基本状况，每次垃圾回收后会更新。要看更新后的状态，点击Gause GC按钮。
图1.Device Monitor工具显示[1] Update Heap和 [2] Cause GC按钮。右边的Heap标签页显示堆的情况。
跟踪内存分配
当要减少内存问题时，应该使用Allocation Tracker来更好的了解内存消耗大户在哪分配。Allocation Tracker不仅在查看内存的具体使用上很有用，也可以分析应用中的关键代码路径，例如滑动。
例如，在应用中滑动列表时跟踪内存分配，可以看到内存分配的动作，包括在哪些线程上分配和哪里进行的分配。这对优化代码路径来减轻工作量和改善UI流畅性都极其有用。
使用Allocation Tracker：
1.打开Device Monitor 。
从<sdk>/tools/路径下加载monitor工具。
2.在DDMS窗口，从左侧面板选择应用进程。
3.在右侧面板中选择Allocation Tracker标签页。
4.点击Start Tracking。
5.执行应用到需要分析的代码路径处。
6.点击Get Allocations来更新分配列表。
列表显示了所有的当前分配和512大小限制的环形缓冲区的情况。点击行可以查看分配的堆栈跟踪信息。堆栈不只显示了分配的对象类型，还显示了属于哪个线程哪个类哪个文件和哪一行。
图2. Device Monitor工具显示了在Allocation Tracker中当前应用的内存分配和堆栈跟踪的情况。
注意：总会有一些分配是来自与 DdmVmInternal 和 allocation tracker本身。
尽管移除掉所有严重影响性能的代码是不必要的（也是不可能的），但是allocation tracker还是可以帮助定位代码中的严重问题。例如，应用可能在每个draw操作上创建新的Paint对象。把对象改成全局变量就是一个很简单的改善性能的修改。
查看总体内存分配
为了进一步的分析，查看应用内存中不同内存类型的分配情况，可以使用下面的 adb 命令：
Java
1
adb shell mpsys meminfo <package_name>
应用当前的内存分配输出列表，单位是千字节。
当查看这些信息时，应当熟悉下面的分配类型：
私有(Clean and Dirty) 内存
进程独占的内存。也就是应用进程销毁时系统可以直接回收的内存容量。通常来说，“private dirty”内存是其最重要的部分，因为只被自己的进程使用。它只在内存中存储，因此不能做分页存储到外存（Android不支持swap）。所有分配的Dalvik堆和本地堆都是“private dirty”内存；Dalvik堆和本地堆中和Zygote进程共享的部分是共享dirty内存。
实际使用内存 (PSS)
这是另一种应用内存使用的计算方式，把跨进程的共享页也计算在内。任何独占的内存页直接计算它的PSS值，而和其它进程共享的页则按照共享的比例计算PSS值。例如，在两个进程间共享的页，计算进每个进程PPS的值是它的一半大小。
PSS计算方式的一个好处是：把所有进程的PSS值加起来就可以确定所有进程总共占用的内存。这意味着用PSS来计算进程的实际内存使用、进程间对比内存使用和总共剩余内存大小是很好的方式。
例如，下面是平板设备中Gmail进程的输出信息。它显示了很多信息，但是具体要讲解的是下面列出的一些关键信息。
注意：实际看到的信息可能和这里的稍有不同，输出的详细信息可能会根据平台版本的不同而不同。
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
** MEMINFO in pid 9953 [com.google.android.gm] **
Pss Pss Shared Private Shared Private Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 0 0 7800 7637(6) 126
Dalvik Heap 5110(3) 0 4136 4988(3) 0 0 9168 8958(6) 210
Dalvik Other 2850 0 2684 2772 0 0
Stack 36 0 8 36 0 0
Cursor 136 0 0 136 0 0
Ashmem 12 0 28 0 0 0
Other dev 380 0 24 376 0 4
.so mmap 5443(5) 1996 2584 2664(5) 5788 1996(5)
.apk mmap 235 32 0 0 1252 32
.ttf mmap 36 12 0 0 88 12
.dex mmap 3019(5) 2148 0 0 8936 2148(5)
Other mmap 107 0 8 8 324 68
Unknown 6994(4) 0 252 6992(4) 0 0
TOTAL 24358(1) 4188 9724 17972(2)16388 4260(2)16968 16595 336
Objects
Views: 426 ViewRootImpl: 3(8)
AppContexts: 6(7) Activities: 2(7)
Assets: 2 AssetManagers: 2
Local Binders: 64 Proxy Binders: 34
Death Recipients: 0
OpenSSL Sockets: 1
SQL
MEMORY_USED: 1739
PAGECACHE_OVERFLOW: 1164 MALLOC_SIZE: 62
通常来说，只需关心Pss Total列和Private Dirty列就可以了。在一些情况下，Private Clean列和Heap Alloc列也会提供很有用的信息。下面是一些应该查看的内存分配类型(行中列出的类型)：
Dalvik Heap
应用中Dalvik分配使用的内存。Pss Total包含所有的Zygote分配（如上面PSS定义所描述的，共享跨进程的加权）。Private Dirty是应用堆独占的内存大小，包含了独自分配的部分和应用进程从Zygote复制分裂时被修改的Zygote分配的内存页。
注意：新平台版本有Dalvik Other这一项。Dalvik Heap中的Pss Total和Private Dirty不包括Dalvik的开销，例如即时编译（JIT）和垃圾回收（GC），然而老版本都包含在Dalvik的开销里面。
Heap Alloc是应用中Dalvik堆和本地堆已经分配使用的大小。它的值比Pss Total和Private Dirty大，因为进程是从Zygote中复制分裂出来的，包含了进程共享的分配部分。
.so mmap和.dex mmap
mmap映射的.so(本地) 和.dex(Dalvik)代码使用的内存。Pss Total 包含了跨应用共享的平台代码；Private Clean是应用独享的代码。通常来说，实际映射的内存大小要大一点——这里显示的内存大小是执行了当前操作后应用使用的内存大小。然而，.so mmap 的private dirty比较大，这是由于在加载到最终地址时已经为本地代码分配好了内存空间。
Unknown
无法归类到其它项的内存页。目前，这主要包含大部分的本地分配，就是那些在工具收集数据时由于地址空间布局随机化(Address Space Layout Randomization ，ASLR)不能被计算在内的部分。和Dalvik堆一样， Unknown中的Pss Total把和Zygote共享的部分计算在内，Unknown中的Private Dirty只计算应用独自使用的内存。
TOTAL
进程总使用的实际使用内存(PSS)，是上面所有PSS项的总和。它表明了进程总的内存使用量，可以直接用来和其它进程或总的可以内存进行比较。
Private Dirty和Private Clean是进程独自占用的总内存，不会和其它进程共享。当进程销毁时，它们（特别是Private Dirty）占用的内存会重新释放回系统。Dirty内存是已经被修改的内存页，因此必须常驻内存（因为没有swap）；Clean内存是已经映射持久文件使用的内存页（例如正在被执行的代码），因此一段时间不使用的话就可以置换出去。
ViewRootImpl
进程中活动的根视图的数量。每个根视图与一个窗口关联，因此可以帮助确定涉及对话框和窗口的内存泄露。
AppContexts和Activities
当前驻留在进程中的Context和Activity对象的数量。可以很快的确认常见的由于静态引用而不能被垃圾回收的泄露的 Activity对象。这些对象通常有很多其它相关联的分配，因此这是追查大的内存泄露的很好办法。
注意：View 和 Drawable 对象也持有所在Activity的引用，因此，持有View 或 Drawable 对象也可能会导致应用Activity泄露。
获取堆转储
堆转储是应用堆中所有对象的快照，以二进制文件HPROF的形式存储。应用堆转储提供了应用堆的整体状态，因此在查看堆更新的同时，可以跟踪可能已经确认的问题。
检索堆转储：
1.打开Device Monitor。
从<sdk>/tools/路径下加载monitor工具。
2.在DDMS窗口，从左侧面板选择应用进程。
3.点击Dump HPROF file，显示见图3。
4.在弹出的窗口中，命名HPROF文件，选择存放位置，然后点击Save。
图3.Device Monitor工具显示了[1] Dump HPROF file按钮。
如果需要能更精确定位问题的堆转储，可以在应用代码中调用mpHprofData()来生成堆转储。
堆转储的格式基本相同，但与Java HPROF文件不完全相同。Android堆转储的主要不同是由于很多的内存分配是在Zygote进程中。但是由于Zygote的内存分配是所有应用进程共享的，这些对分析应用堆没什么关系。
为了分析堆转储，你需要像jhat或Eclipse内存分析工具(MAT)一样的标准工具。当然，第一步需要做的是把HPROF文件从Android的文件格式转换成J2SE HRPOF的文件格式。可以使用<sdk>/platform-tools/路径下的hprof-conv工具来转换。hprof-conv的使用很简单，只要带上两个参数就可以：原始的HPROF文件和转换后的HPROF文件的存放位置。例如：
Java
1
hprof-conv heap-original.hprof heap-converted.hprof
注意：如果使用的是集成在Eclipse中的DDMS，那么就不需要再执行HPROF转换操作——默认已经转换过了。
现在就可以在MAT中加载转换过的HPROF文件了，或者是在可以解析J2SE HPROF格式的其它堆分析工具中加载。
分析应用堆时，应该查找由下导致的内存泄露：
对Activity、Context、View、Drawable的长期引用，以及其它可能持有Activity或Context容器引用的对象
非静态内部类（例如持有Activity实例的Runnable）
不必要的长期持有对象的缓存
使用Eclipse内存分析工具
Eclipse内存分析工具（MAT）是一个可以分析堆转储的工具。它是一个功能相当强大的工具，功能远远超过这篇文档的介绍，这里只是一些入门的介绍。
在MAT中打开类型转换过的HPROF文件，在总览界面会看到一张饼状图，它展示了占用堆的最大对象。在图表下面是几个功能的链接：
Histogram view显示所有类的列表和每个类有多少实例。
正常来说类的实例的数量应该是确定的，可以用这个视图找到额外的类的实例。例如，一个常见的源码泄露就是Activity类有额外的实例，而正确的是在同一时间应该只有一个实例。要找到特定类的实例，在列表顶部的<Regex>域中输入类名查找。
当一个类有太多的实例时，右击选择List objects>with incoming references。在显示的列表中，通过右击选择Path To GC Roots> exclude weak references来确定保留的实例。
Dominator tree是按照保留堆大小来显示的对象列表。
应该注意的是那些保留的部分堆大小粗略等于通过GC logs、heap updates或allocation tracker观察到的泄露大小的对象。
当看到可疑项时，右击选择Path To GC Roots>exclude weak references。打开新的标签页，标签页中列出了可疑泄露的对象的引用。
注意：在靠近饼状图中大块堆的顶部，大部分应用会显示Resources的实例，但这通常只是因为在应用使用了很多res/路径下的资源。
图4.MAT显示了Histogram view和搜索”MainActivity”的结果。
想要获得更多关于MAT的信息，请观看2011年Google I/O大会的演讲–《Android 应用内存管理》（Memory management for Android apps），在大约21:10 的时候有关于MAT的实战演讲。也可以参考文档《Eclipse 内存分析文档》（Eclipse Memory Analyzer documentation）。
对比堆转储
为了查看内存分配的变化，比较不同时间点应用的堆状态是很有用的方法。对比两个堆转储可以使用MAT：
1.按照上面描述得到两个HPROF文件，具体查看获取堆转储章节。
2.在MAT中打开第一个HPROF文件（File>Open Heap Dump）。
3.在Navigation History视图（如果不可见，选择Window>Navigation History），右击Histogram，选择Add to Comp are Basket。
4.打开第二个HRPOF文件，重复步骤2和3。
5.切换到Compare Basket视图，点击Compare the Results（在视图右上角的红色“！”图标）。
触发内存泄露
使用上述描述工具的同时，还应该对应用代码做压力测试来尝试复现内存泄露。一个检查应用潜在内存泄露的方法，就是在检查堆之前先运行一会。泄露会慢慢达到分配堆的大小的上限值。当然，泄露越小，就要运行应用越长的时间来复现。
也可以使用下面的方法来触发内存泄露：
1.在不同Activity状态时，重复做横竖屏切换操作。旋转屏幕可能导致应用泄露 Activity、Context 或 View对象，因为系统会重新创建 Activity，如果应用在其它地方持有这些对象的引用，那么系统就不能回收它们。
2.在不同Activity状态时，做切换应用操作（切换到主屏幕，然后回到应用中）。
提示：也可以使用monkey测试来执行上述步骤。想要获得更多运行 monkey 测试的信息，请查阅 monkeyrunner 文档。
Ⅸ android布局中outofmemoryerror 怎么处理
安卓开发中经常出现内存溢出的情况，没有防备的开发者可能一天会不经意间写好几个内存溢出的漏洞。你可能不会发现这些漏洞，甚至都不知道它们存在，直到你看到这种异常：
java.lang.OutOfMemoryError: Failed to allocate a 4308492 byte allocation with 467872 free bytes and 456KB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:609)
at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:444)
at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:988)
at android.content.res.Resources.loadDrawableForCookie(Resources.java:2580)
at android.content.res.Resources.loadDrawable(Resources.java:2487)
at android.content.res.Resources.getDrawable(Resources.java:814)
at android.content.res.Resources.getDrawable(Resources.java:767)
at com.nostra13.universalimageloader.core.DisplayImageOptions.getImageOnLoading(DisplayImageOptions.java:134)
这是啥意思呢？难道我的Bitmap太大了？
这种异常信息可能会让你产生误解。当你看到OutOfMemoryError的时候，十有八九是内存泄露。
Ⅹ android studio memory monitor 在哪
方法/步骤
1
启动Android Studio
2
DDMS即可以在菜单中打开，也可以通过工具条打开。下面介绍这两种方式。
END
在菜单栏中打开DDMS
1
点击"Tools"菜单，
2
再选择"Android"-"Android Device Monitor"
3
在弹出的对话框就可以看到DDMS了。
END
在工具栏中打开DDMS
找到"Android Device Monitor"的工具按钮，
点击该按钮就可以打开Android Device Monitor了，在该对话框中就可以看到DDMS了。
http://jingyan..com/article/456c463b42335e0a583144e1.html