❶ 为什么每次运行android虚拟机后C盘内存就减少好几G
C盘下有个.android文件专门做虚拟机相关的东西，虚拟机的内存 sd卡一类什么的全都映射到这里了，所以会减少
❷ 如何检查 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如何快速将一个大文件从一个文件夹移至另外一个文件夹
资料很多啊，就java的新IO，你随便网络一下都有很详细的博文，新IO里面有讲解到内存映射的，对大文件操作效率很高，。
❹ android手机GPU显存有必要么
实际上，现在android中用的是统一内存架构，GPU和CPU共享一个物理内存，通常我们有“显存”和“内存”两种叫法，可以认为是这块物理内存的所有者不同，但这段映射到cpu，就是通常意义上的内存；当映射到gpu，就是通常意义上的显存。并且同一时刻只会映射到一个device。
一个简单的纹理创建，首先我们需要先把纹理数据加载到一段内存中A中，然后调用glTexImage2D来上传纹理的时候，会调用gles驱动的内存分配接口来分配一段内存B（最终是调用gralloc分配），并且映射到cpu。然后会调用一个定制的memcpy来把A的数据拷贝到B。这里，虽然都是在同一块物理内存中，但是OpenGL的spec如此，还是需要一次拷贝。渲染的时候，B会被映射到GPU上，让GPU可以读取。
而GPU渲染内容从APP到SF，是不会有搬运，至少Mali和sgx PowerVR不会。厂家的opengl实现，是调用BufferQueue这个类来获取内存来渲染的，gpu渲染完毕再丢回BuffferQueue （Queue/Dequeue）。而surfaceFlinger会去请求有没有可以已经渲染好的东西，以及会把显示完的一帧丢回这个queue（Aquire/Release）。只要进程还活着，还可见，这个queue中往往有3块格式相同的buffer会循环使用。
这个类是实现在SurfaceFlinger模块下，如上提供了两组接口给生产者（Gpu）和消费者（SF/display），所有帧 buffer的传递显然都是直接传递指针，也就是不会有拷贝。这部分是android公共的实现。
❺ 安卓ROM zipling优化是什么意思啊 有详细的解释吗
zipalign，即zip align，是专门优化apk的
和“4K对齐”有一些意思上的相似。
在Android中，每个应用程序中储存的数据文件都会被多个进程访问：安装程序会读取应用程序的manifest文件来处理与之相关的权限问题；Home应用程序会读取资源文件来获取应用程序的名和图标；系统服务会因为很多种原因读取资源（例如，显示应用程序的Notification）；此外，就是应用程序自身用到资源文件。
在Android中，当资源文件通过内存映射对齐到4字节边界时，访问资源文件的代码才是有效率的。但是，如果资源本身没有进行对齐处理（未使用过zipalign工具），它就必须回到老路上，显式地读取它们——这个过程将会比较缓慢且会花费额外的内存。
对于应用程序开发者来说，这种显式读取方式是相当便利的。它允许使用一些不同的开发方法，包括正常流程中不包含对齐的资源，因此，这种读取方式具有很大的便利性。
遗憾的是，对于用户来说，这个情况恰恰是相反的——从未对齐的apk中读取资源比较慢且花费较多内存。最好的情况是，Home程序和未对齐的程序启动得比对齐后的慢（这也是唯一可见的效果）。最坏的情况是，安装一些未对齐资源的应用程序会增加内存压力，并因此造成系统反复地启动和杀死进程。最终，用户放弃使用如此慢又耗电的设备。
zipalign提高了优化后的Applications与Android系统的 交互效率。
zipalign就好比为Applications与Android系统之间搭建了一条高速公路
简单优化：zipalign
Android SDK中包含一个“zipalign”的工具，它能够对打包的应用程序进行优化。在你的应用程序上运行zipalign，使得在运行时Android与应用程序间的交互更加有效率。因此，这种方式能够让应用程序和整个系统运行得更快。我们强烈推荐在新的和已经发布的程序上使用zipalign工具来得到优化后的版本——即使你的程序是在老版本的Android平台下开发的。这篇文章将描述zipalign如何有助于性能改善以及如何使用它来优化你的app。
在Android中，每个应用程序中储存的数据文件都会被多个进程访问：安装程序会读取应用程序的manifest文件来处理与之相关的权限问题；Home应用程序会读取资源文件来获取应用程序的名和图标；系统服务会因为很多种原因读取资源（例如，显示应用程序的Notification）；此外，就是应用程序自身用到资源文件。
使用ADT：
如果你使用导出向导的话，Eclipse中的ADT插件，就能自动对齐Release程序包。使用向导，右击工程属性，选择“Android Tools” > “Export Signed Application Package…”。当然，你还可以通过AndroidManifest.xml编辑器的第一页做到。
使用Ant：
Ant编译脚本（从Android 1.6开始）可以对齐程序包。老平台的版本不能通过Ant编译脚本进行对齐，必须手动对齐。
从Android 1.6开始，Debug模式下编译时，Ant自动对齐和签名程序包。
Release模式下，如果有足够的信息签名程序包的话，Ant才会执行对齐操作，因为对齐处理发生在签名之后。为了能够签名程序包，进而执行对齐操作，Ant必须知道keystore的位置以及build.properties中key的名字。相应的属性名为key.store和key.alias。如果这些属性为空，签名工具会在编译过程中提示输入store/key的密码，然后脚本会执行签名及apk文件的对齐。如果这些属性都没有，Release程序包不会进行签名，自然也就不会进行对齐了。
手动：
为了能够手动对齐程序包，Android 1.6及以后的SDK的tools/文件夹下都有zipalign工具。你可以使用它来对齐任何版本下的程序包。你必须在签名apk文件后进行，使用以下命令：zipalign -v 4 source.apk destination.apk
验证对齐：
以下的命令用于检查程序包是否进行了对齐：zipalign -c -v 4 application.apk
极力推荐手动zipalign你的应用程序，并确保将最新对齐后的版本提供给用户。此外，别忘了还有的新应用程序也需要这么做！
简单优化：zipalign
Android SDK中包含一个“zipalign”的工具，它能够对打包的应用程序进行优化。在你的应用程序上运行zipalign，使得在运行时Android与应用程序间的交互更加有效率。因此，这种方式能够让应用程序和整个系统运行得更快。我们强烈推荐在新的和已经发布的程序上使用zipalign工具来得到优化后的版本——即使你的程序是在老版本的Android平台下开发的。这篇文章将描述zipalign如何有助于性能改善以及如何使用它来优化你的app。
在Android中，每个应用程序中储存的数据文件都会被多个进程访问：安装程序会读取应用程序的manifest文件来处理与之相关的权限问题；Home应用程序会读取资源文件来获取应用程序的名和图标；系统服务会因为很多种原因读取资源（例如，显示应用程序的Notification）；此外，就是应用程序自身用到资源文件。
总而言之zipalign，是专门优化apk的
参考资料： 安卓网《[ROM 制作/修改 教程] 【大熊熊资源】Zipalign优化！让你的手机运行更加流畅！！！ 》、网络文
❻ 安卓怎么把制定目录映射到EXT分区内
用Android超级终端，操作和data2sd一样，data2sd的指令是 rm -r /data/dalvik-cache （删除dalvik-cache 目录）
ln -s /data/sdext2/dalvik-cache /data/dalvik-cache（建立映射关系） 你把/data/dalvik-cache更换成/osh，/data/sdext2/dalvik-cache更换成你的EXT分区路径，/data/dalvik-cache更换成/osh，不过如果你的EXT分区没有/osh这个路径，那就创建osh文件夹，最后再输入reboot system即可，但能不能成功，我就不知道了，指令应该是没有错的。
❼ unity3d怎么调用android查看运行消耗的内存
查看内存使用的方式有很多种，但是各个方式查看到的结果可能会有微略不同。
方式一，Running services
通过手机上Running services的Activity查看，可以通过Setting->Applications->Running services进。
关于Running services的详细内容请参考《Android中使用"running services"查看service进程内存》
方式二，使用ActivityManager的getMemoryInfo(ActivityManager.MemoryInfo outInfo)
ActivityManager.getMemoryInfo()主要是用于得到当前系统剩余内存的及判断是否处于低内存运行。
实例1：
private void displayBriefMemory() {
final ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo();
activityManager.getMemoryInfo(info);
Log.i(tag,"系统剩余内存:"+(info.availMem >> 10)+"k");
Log.i(tag,"系统是否处于低内存运行："+info.lowMemory);
Log.i(tag,"当系统剩余内存低于"+info.threshold+"时就看成低内存运行");
}
ActivityManager.getMemoryInfo()是用ActivityManager.MemoryInfo返回结果，而不是Debug.MemoryInfo，他们不一样的。
ActivityManager.MemoryInfo只有三个Field:
availMem:表示系统剩余内存
lowMemory：它是boolean值，表示系统是否处于低内存运行
hreshold：它表示当系统剩余内存低于好多时就看成低内存运行
方式三，在代码中使用Debug的getMemoryInfo(Debug.MemoryInfo memoryInfo)或ActivityManager的MemoryInfo[] getProcessMemoryInfo(int[] pids)
该方式得到的MemoryInfo所描述的内存使用情况比较详细.数据的单位是KB.
MemoryInfo的Field如下
dalvikPrivateDirty： The private dirty pages used by dalvik。
dalvikPss ：The proportional set size for dalvik.
dalvikSharedDirty ：The shared dirty pages used by dalvik.
nativePrivateDirty ：The private dirty pages used by the native heap.
nativePss ：The proportional set size for the native heap.
nativeSharedDirty ：The shared dirty pages used by the native heap.
otherPrivateDirty ：The private dirty pages used by everything else.
otherPss ：The proportional set size for everything else.
otherSharedDirty ：The shared dirty pages used by everything else.
Android和Linux一样有大量内存在进程之间进程共享。某个进程准确的使用好多内存实际上是很难统计的。
因为有paging out to disk（换页），所以如果你把所有映射到进程的内存相加，它可能大于你的内存的实际物理大小。
dalvik：是指dalvik所使用的内存。
native：是被native堆使用的内存。应该指使用C\C++在堆上分配的内存。
other:是指除dalvik和native使用的内存。但是具体是指什么呢？至少包括在C\C++分配的非堆内存，比如分配在栈上的内存。puzlle!
private:是指私有的。非共享的。
share:是指共享的内存。
PSS：实际使用的物理内存（比例分配共享库占用的内存）
Pss：它是把共享内存根据一定比例分摊到共享它的各个进程来计算所得到进程使用内存。网上又说是比例分配共享库占用的内存，那么至于这里的共享是否只是库的共享，还是不清楚。
PrivateDirty：它是指非共享的，又不能换页出去（can not be paged to disk ）的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象，即使你的进程结束，该内存也不会释放掉，它只是又重新回到缓冲中而已。
SharedDirty:参照PrivateDirty我认为它应该是指共享的，又不能换页出去（can not be paged to disk ）的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象，即使所有共享它的进程结束，该内存也不会释放掉，它只是又重新回到缓冲中而已。
具体代码请参考实例1
注意1：MemoryInfo所描述的内存使用情况都可以通过命令adb shell "mpsys meminfo %curProcessName%" 得到。
注意2：如果想在代码中同时得到多个进程的内存使用或非本进程的内存使用情况请使用ActivityManager的MemoryInfo[] getProcessMemoryInfo(int[] pids)，
否则Debug的getMemoryInfo(Debug.MemoryInfo memoryInfo)就可以了。
注意3：可以通过ActivityManager的List<ActivityManager.RunningAppProcessInfo> getRunningAppProcesses()得到当前所有运行的进程信息。
ActivityManager.RunningAppProcessInfo中就有进程的id，名字以及该进程包括的所有apk包名列表等。
注意4：数据的单位是KB.
方式4、使用Debug的getNativeHeapSize ()，getNativeHeapAllocatedSize ()，getNativeHeapFreeSize ()方法。
该方式只能得到Native堆的内存大概情况，数据单位为字节。
static long getNativeHeapAllocatedSize()
Returns the amount of allocated memory in the native heap.
返回的是当前进程navtive堆中已使用的内存大小
static long getNativeHeapFreeSize()
Returns the amount of free memory in the native heap.
返回的是当前进程navtive堆中已经剩余的内存大小
static long getNativeHeapSize()
Returns the size of the native heap.
返回的是当前进程navtive堆本身总的内存大小
示例代码：
Log.i(tag,"NativeHeapSizeTotal:"+(Debug.getNativeHeapSize()>>10));
Log.i(tag,"NativeAllocatedHeapSize:"+(Debug.getNativeHeapAllocatedSize()>>10));
Log.i(tag,"NativeAllocatedFree:"+(Debug.getNativeHeapFreeSize()>>10));
注意：DEBUG中居然没有与上面相对应的关于dalvik的函数。
方式五、使用mpsys meminfo命令。
我们可以在adb shell 中运行mpsys meminfo命令来得到进程的内存信息。在该命令的后面要加上进程的名字，以确定是哪个进程。
比如"adb shell mpsys meminfo com.teleca.robin.test" 将得到com.teleca.robin.test进程使用的内存的信息:
Applications Memory Usage (kB):
Uptime: 12101826 Realtime: 270857936
** MEMINFO in pid 3407 [com.teleca.robin.test] **
native dalvik other total
size: 3456 3139 N/A 6595
allocated: 3432 2823 N/A 6255
free: 23 316 N/A 339
(Pss): 724 1101 1070 2895
(shared dirty): 1584 4540 1668 7792
(priv dirty): 644 608 688 1940
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 3 AssetManagers: 3
Local Binders: 5 Proxy Binders: 11
Death Recipients: 0
OpenSSL Sockets: 0
SQL
heap: 0 memoryUsed: 0
pageCacheOverflo: 0 largestMemAlloc: 0
Asset Allocations
zip:/data/app/com.teleca.robin.test-1.apk:/resources.arsc: 1K
"size" 表示的是总内存大小（kb）。, "allocated" 表示的是已使用了的内存大小（kb），, "free"表示的是剩余的内存大小（kb）, 更多的可以参照方式三和方式四中的描述
现在已经有了自动提取汇总mpsys meminfo信息的工具，具体请参照《Android内存泄露利器（内存统计篇）》及其系列文章。
方式六、使用 "adb shell procrank"命令
如果你想查看所有进程的内存使用情况，可以使用"adb shell procrank"命令。命令返回将如下：
PID Vss Rss Pss Uss cmdline
188 75832K 51628K 24824K 19028K system_server
308 50676K 26476K 9839K 6844K system_server
2834 35896K 31892K 9201K 6740K com.sec.android.app.twlauncher
265 28536K 28532K 7985K 5824K com.android.phone
100 29052K 29048K 7299K 4984K zygote
258 27128K 27124K 7067K 5248K com.swype.android.inputmethod
270 25820K 25816K 6752K 5420K com.android.kineto
1253 27004K 27000K 6489K 4880K com.google.android.voicesearch
2898 26620K 26616K 6204K 3408K com.google.android.apps.maps:FriendService
297 26180K 26176K 5886K 4548K com.google.process.gapps
3157 24140K 24136K 5191K 4272K android.process.acore
2854 23304K 23300K 4067K 2788K com.android.vending
3604 22844K 22840K 4036K 3060K com.wssyncmldm
592 23372K 23368K 3987K 2812K com.google.android.googlequicksearchbox
3000 22768K 22764K 3844K 2724K com.tmobile.selfhelp
101 8128K 8124K 3649K 2996K /system/bin/mediaserver
3473 21792K 21784K 3103K 2164K com.android.providers.calendar
3407 22092K 22088K 2982K 1980K com.teleca.robin.test
2840 21380K 21376K 2953K 1996K com.sec.android.app.controlpanel
......................................................................................................................
关于VSS,RSS,PSS,USS的意义请参考《Android内存之VSS/RSS/PSS/USS》
注意1：这里的PSS和方式四PSS的total并不一致，有细微的差别。为什么呢？这是因为procrank 命令和meminfo命令使用的内核机制不太一样，所以结果会有细微差别
注意2：这里的Uss 和方式四的Priv Dirtyd的total几乎相等.他们似乎表示的是同一个意义。但是现在得到的关于它们的意义的解释却不太相同。难道这里Private的都是dirty(这里指不能换页)? Puzzle!
方式七、使用"adb shell cat /proc/meminfo" 命令。
该方式只能得出系统整个内存的大概使用情况。
MemTotal: 395144 kB
MemFree: 184936 kB
Buffers: 880 kB
Cached: 84104 kB
SwapCached: 0 kB
................................................................................................
MemTotal ：可供系统和用户使用的总内存大小 (它比实际的物理内存要小，因为还有些内存要用于radio, DMA buffers, 等).
MemFree：剩余的可用内存大小。这里该值比较大，实际上一般Android system 的该值通常都很小，因为我们尽量让进程都保持运行，这样会耗掉大量内存。
Cached: 这个是系统用于文件缓冲等的内存. 通常systems需要20MB 以避免bad paging states;。当内存紧张时，the Android out of memory killer将杀死一些background进程，以避免他们消耗过多的cached RAM ，当然如果下次再用到他们，就需要paging. 那么是说background进程的内存包含在该项中吗？
方式八，使用“adb shell ps -x”命令
该方式主要得到的是内存信息是VSIZE 和RSS。
USER PID PPID VSIZE RSS WCHAN PC NAME
.........................省略.................................
app_70 3407 100 267104 22056 ffffffff afd0eb18 S com.teleca.robin.test (u:55, s:12)
app_7 3473 100 268780 21784 ffffffff afd0eb18 S com.android.providers.calendar (u:16, s:8)
radio 3487 100 267980 21140 ffffffff afd0eb18 S com.osp.app.signin (u:11, s:12)
system 3511 100 273232 22024 ffffffff afd0eb18 S com.android.settings (u:11, s:4)
app_15 3546 100 267900 20300 ffffffff afd0eb18 S com.sec.android.providers.drm (u:15, s:6)
app_59 3604 100 272028 22856 ffffffff afd0eb18 S com.wssyncmldm (u:231, s:54)
root 4528 2 0 0 c0141e4c 00000000 S flush-138:13 (u:0, s:0)
root 4701 152 676 336 c00a68c8 afd0e7cc S /system/bin/sh (u:0, s:0)
root 4702 4701 820 340 00000000 afd0d8bc R ps (u:0, s:5)
VSZIE:意义暂时不明。
VSS：请参考《Android内存之VSS/RSS/PSS/USS》
注意1：由于RSS的价值不是很大，所以一般不用。
注意2：通过该命令提取RSS，已经有了工具，具体参照《Android内存泄露利器（RSS内存统计篇）》及其系列。
❽ android arraymap与hashmap相比真的占用内存小么
HashMap简介 综述：HashMap 是一个散列表，它存储的内容是键值对(key-value)映射。 1.HashMap 继承于AbstractMap，实现了Map、Cloneable、java.io.Serializable接口。 2.HashMap 的实现不是同步的，这意味着它不是线程安全的。它的key、value都可以为null。此外，HashMap中的映射不是有序的。 3.HashMap 的实例有两个参数影响其性能：“初始容量” 和 “加载因子”。容量 是哈希表中桶的数量，初始容量 只是哈希表在创建时的容量。加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行 rehash 操作（即重建内部数据结构），从而哈希表将具有大约两倍的桶数。 通常，默认加载因子是 0.75, 这是在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查询成本（在大多数 HashMap 类的操作中，包括 get 和 put 操作，都反映了这一点）。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地减少 rehash 操作次数。如果初始容量大于最大条目数除以加载因子，则不会发生 rehash 操作。
❾ android源码下 怎么修改内存阀值
android源码下 修改内存阀值的方法为：
第一步:首先建立一个XXX.txt文件，输入以下代码:
#!/system/bin/sh
echo "1536,2048,4096,6144,8192,12288" > /sys/mole/lowmemorykiller/parameters/minfree ;
这个代码是基于MFM配置3对应的数值，用了几天这个数值了没发现问题，所以暂时以这个数值为例。
然后保存，将保存好的XXX.txt文件修改为67-Jasonfix
将这个67-Jasonfix文件用RE管理器放入system/etc/init.d下(这个文件夹里面都是开机脚本设定。
然后将权限改为：全部打钩。
第二步:修改install-recovery.sh(在system/etc目录下)
(1).找到这些脚本所在行
sh /system/etc/init.d/XXXXX
对应加入
sh /system/etc/init.d/67-Jason
(2).然后找到
echo A,B,C,D,E,F /sys/mole/lowmemorykiller/parameters/minfree
删除这行并保存即可。
❿ 安卓如何高效把GPU数据给网卡
这里我们参考OpenGL中的像素缓冲区对象(PBO) ,在unreal中实现了ping-pong PBO的高效像素数据拷贝方案，利用空间换时间，成功的将数据拷贝的时间从30ms降低到了10ms左右，下面将分两部分介绍， 首先绍下
OpenGL中的PBO技术，然后结合代码详细介绍下ping-pong PBO的方案实现。
OpenGL像素缓冲区对象PBO
关于PBO的介绍，这篇博客介绍的非常棒,这里我简单的总结下相关的点:
PBO主要有两大优点:
●可以通过DMA(Direct Memory Access)快速的在显卡上传递像素数据，而不影响CPU的时钟
周期
●它提供了一种内存映射机制，可以映射OpenGL控制的缓冲区对象到客户端的内存地址空间中,
户端可以使用glMapBufferARB0, glIUnmapBufferARB0函数修改全部或部分缓冲区对象,注
如果GPU仍使用此缓冲区对象，glMapBufferARB(不会返回， 直到GPU完成了对相应缓冲区
对象的操作
我们主要利用这两个优势来实现快速的拷贝数据。