Android开发内存泄漏及检查工具使用培训资料

Android 开发内存泄漏及检查工具使用培

训资料

目录

1内存泄露 (3)

1.1 内存泄露的概念 (3)

1.2 开发人员注意事项 (4)

1.3 Android（java）中常见的引起内存泄露的代码示例 (4)

1.3.1查询数据库没有关闭游标 (6)

1.3.2 构造Adapter时，没有使用缓存的convertView (6)

1.3.3 Bitmap对象不在使用时调用recycle()释放内存 (7)

1.3.4 释放对象的引用 (8)

1.3.5 其他 (9)

2内存泄露的分析工具 (9)

2.1 内存监测工具DDMS --> Heap (9)

2.2 内存分析工具MAT (Memory Analyzer Tool) (10)

2.2.1 生成.hprof文件 (10)

2.2.2 使用MA T导入.hprof文件 (11)

2.2.3 使用MA T的视图工具分析内存 (12)

1内存泄露

Android 应用程序开发以Java语言为主，而Java编程中一个非常重要但却经常被忽视的问题就是内存使用的问题。Java的垃圾回收机制(Garbage Collection 以下简称GC)使得很多开发者并不关心内存使用的生命周期，只顾着申请内存，却不手动释放废弃的内存，而造成内存泄露，引起很多问题，甚至程序崩溃。Android的虚拟机Dalvik VM和java虚拟机JVM没有什么太大的区别，只是在字节码上稍做优化，所以Android应用开发中同样会出现内存泄露的问题。而且由于Android智能平台主要用于嵌入式产品开发，可用的内存资源更加稀少，所以对于我们Android应用开发人员来说，就更该了解Android程序的内存管理机制，避免内存泄露的发生。

1.1 内存泄露的概念

在计算机科学中，内存泄漏(memory leak)指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。内存泄漏与许多其他问题有着相似的症状，并且通常情况下只能由那些可以获得程序源代码的程序员才可以分析出来。然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，严格意义上来说这是不准确的。

一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显式释放的内存。应用程序一般使用malloc，calloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。

这里我们只简单的理解，在java程序中，如果已经不再使用一个对象，但是仍然有引用指向它，GC就无法收回它，当然该对象占用的内存就无法再被使用，这就造成内存泄露。可能一个实例对象的内存泄露很小，并不会引起很大的问题。但是如果程序反复做此操作或者长期运行，造成内存不断泄露，终究会使程序无内存可用，只好被系统kill掉。在以下情况，内存泄漏导致较严重的后果：

* 程序运行后置之不理，并且随着时间的流失消耗越来越多的内存（比如服务器上的后台任务，尤其是嵌入式系统中的后台任务，这些任务可能被运行后很多年内都置之不理）；

* 新的内存被频繁地分配，比如当显示电脑游戏或动画视频画面时；

* 程序能够请求未被释放的内存（比如共享内存），甚至是在程序终止的时候；

* 泄漏在操作系统内部发生；

* 泄漏在系统关键驱动中发生；

* 内存非常有限，比如在嵌入式系统或便携设备中；

* 当运行于一个终止时内存并不自动释放的操作系统（比如AmigaOS）之上，而且一旦丢失只能通过重启来恢复。

1.2 开发人员注意事项

对于开发者，对待内存泄露应该以防为主，以治为辅，因为一旦造成内存泄露，追查原因并不容易，虽然有工具可以利用，但是还是会耗费不必要的时间和精力来分析内存使用报告和反复搜查代码。为了开发高性能和高质量的软件，防止出现豆腐渣工程的出现，我们要知道什么时候用gc什么时候用recycle以及到底用不用finalization，因为Java 对内存的分配只需要new开发者不需要显示的释放内存，但是这样造成的内存泄露问题的几率反而更高。我们还需要：

1.了解Java 的四种引用方式，比如强引用，软引用，弱引用以及虚引用。一些复杂些的程序在长期运行很可能出现类似OutOfMemoryError 的异常。

2.并不要过多的指望gc，不用的对象可以显示的设置为空，比如obj=null，这里提示大家，java的gc使用的是一个有向图，判断一个对象是否有效看的是其他的对象能到达这个对象的顶点，有向图的相对于链表、二叉树来说开销是可想而知。

3.Android 为每个程序分配的对内存可以通过Runtime类的totalMemory() freeM emory() 两个方法获取VM的一些内存信息，对于系统heap内存获取，可以通过Da lvik.VMRuntime 类的getMinimumHeapSize()方法获取最小可用堆内存，同时显示释放软引用可以调用该类的gcSoftReferences()方法，获取更多的运行内存。

4.对于多线程的处理，如果并发的线程很多，同时有频繁的创建和释放，可以通过concurrent类的线程池解决线程创建的效率瓶颈。

5.不要在循环中创建过多的本地变量。

Java中的引用简介：

在Java中内存管理，引用分为四大类，强引用HardReference、弱引用WeakReference、软引用SoftReference 和虚引用PhantomReference。它们的区别也很明显，HardReference 对象是即使虚拟机内存吃紧抛出OOM 也不会导致这一引用的对象被回收，而WeakReference等更适合于一些数量不多，但体积稍微庞大的对象，在这四个引用中，它是最容易被垃圾回收的，而我们对于显示类似Android Market 中每个应用的AppIcon时可以考虑使用SoftReference来解决内存不至于快速回收，同时当内存短缺面临JavaVM崩溃抛出OOM前时，软引用将会强制回收内存，最后的虚引用一般没有实际意义，仅仅观察GC 的活动状态，对于测试比较实用同时必须和ReferenceQueue一起使用。对于一组数据，我们可以通过HashMap的方式来添加一组SoftReference对象来临时保留一些数据，同时对于需要反复通过网络获取的不经常改变的内容，可以通过本地的文件系统或数据库来存储缓存。

1.3 Android（java）中常见的引起内存泄露的代码示例

Android 主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android 的每个应用程序都会使用一个专有的Dalvik 虚拟机实例来运行，它是由Zygote 服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被kill 掉，而不会影响其他进程（如果是system_process 等系统进程出问

题的话，则会引起系统重启）。另一方面Android 为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill 掉。Android 为应用进程分配的内存上限如下所示：

位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本

# Define the oom_adj values for the classes of processes that can be

# killed by the kernel. These are used in ActivityManagerService.

setprop ro.FOREGROUND_APP_ADJ 0

setprop ro.VISIBLE_APP_ADJ 1

setprop ro.SECONDARY_SERVER_ADJ 2

setprop ro.BACKUP_APP_ADJ 2

setprop ro.HOME_APP_ADJ 4

setprop ro.HIDDEN_APP_MIN_ADJ 7

setprop ro.CONTENT_PROVIDER_ADJ 14

setprop ro.EMPTY_APP_ADJ 15

# Define the memory thresholds at which the above process classes will

# be killed. These numbers are in pages (4k).

setprop ro.FOREGROUND_APP_MEM 1536

setprop ro.VISIBLE_APP_MEM 2048

setprop ro.SECONDARY_SERVER_MEM 4096

setprop ro.BACKUP_APP_MEM 4096

setprop ro.HOME_APP_MEM 4096

setprop ro.HIDDEN_APP_MEM 5120

setprop ro.CONTENT_PROVIDER_MEM 5632

setprop ro.EMPTY_APP_MEM 6144

# Write value must be consistent with the above properties.

# Note that the driver only supports 6 slots, so we have HOME_APP at the

# same memory level as services.

write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15

write /proc/sys/vm/overcommit_memory 1

write /proc/sys/vm/min_free_order_shift 4

write /sys/module/lowmemorykiller/parameters/minfree

1536,2048,4096,5120,5632,6144

# Set init its forked children's oom_adj.

write /proc/1/oom_adj -16

正因为我们的应用程序能够使用的内存有限，所以在编写代码的时候需要特别注意内存

使用问题。如下是一些常见的内存使用不当的情况。

1.3.1查询数据库没有关闭游标

描述：

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor 后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的

情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

示例代码：

Cursor cursor = getContentResolver().query(uri ...);

if (cursor.moveToNext()) {

... ...

}

修正示例代码：

Cursor cursor = null;

try {

cursor = getContentResolver().query(uri ...);

if (cursor != null && cursor.moveToNext()) {

... ...

}

} finally {

if (cursor != null) {

try {

cursor.close();

} catch (Exception e) {

//ignore this

}

}

}

1.3.2 构造Adapter时，没有使用缓存的convertView

描述：

以构造ListView 的BaseAdapter 为例，在BaseAdapter 中提高了方法：

public View getView(int position, View convertView, ViewGroup parent)来向ListView 提供每一个item 所需要的view 对象。初始时ListView 会从BaseAdapter 中根据当前的屏幕布局实例化一定数量的view 对象，同时ListView 会将这些view 对象缓存起来。当向上滚动ListView 时，原先位于最上面的list item 的view 对象会被回收，然后被用来构

造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView 就是被缓存起来的list item 的view 对象(初始化时缓存中没有view对象则convertView 是null)。

由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View 对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView 回收listitem 的view 对象的过程可以查看:

android.widget.AbsListView.java --> void addScrapView(View scrap) 方法。

示例代码：

public View getView(int position, View convertView, ViewGroup parent) {

View view = new Xxx(...);

... ...

return view;

}

修正示例代码：

public View getView(int position, View convertView, ViewGroup parent) {

View view = null;

if (convertView != null) {

view = convertView;

populate(view, getItem(position));

...

} else {

view = new Xxx(...);

...

}

return view;

}

1.3.3 Bitmap对象不在使用时调用recycle()释放内存

描述：

有时我们会手工的操作Bitmap 对象，如果一个Bitmap 对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：

/**

* Free up the memory associated with this bitmap's pixels, and mark the

* bitmap as "dead", meaning it will throw an exception if getPixels() or

* setPixels() is called, and will draw nothing. This operation cannot be

* reversed, so it should only be called if you are sure there are no

* further uses for the bitmap. This is an advanced call, and normally need

* not be called, since the normal GC process will free up this memory when

* there are no more references to this bitmap.

*/

1.3.4 释放对象的引用

描述：

这种情况描述起来比较麻烦，举两个例子进行说明。

示例A：

假设有如下操作

public class DemoActivity extends Activity {

... ...

private Handler mHandler = ...

private Object obj;

public void operation() {

obj = initObj();

...

[Mark]

mHandler.post(new Runnable() {

public void run() {

useObj(obj);

}

});

}

}

我们有一个成员变量obj，在operation()中我们希望能够将处理obj 实例的操作post 到某个线程的MessageQueue 中。在以上的代码中，即便是mHandler 所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj 还保有这个对象的引用。所以如果在DemoActivity 中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：

... ...

public void operation() {

obj = initObj();

...

final Object o = obj;

obj = null;

mHandler.post(new Runnable() {

public void run() {

useObj(o);

}

}

}

... ...

示例B:

假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen 中定义一个PhoneStateListener 的对象，同时将它注册到TelephonyManager 服务中。对于LockScreen 对象，当需要显示锁屏界面的时候就会创建一个LockScreen 对象，而当锁屏界面消失的时候LockScreen 对象就会被释放掉。

但是如果在释放LockScreen 对象的时候忘记取消我们之前注册的PhoneStateListener 对象，则会导致LockScreen 无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen 对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。

总之当一个生命周期较短的对象A，被一个生命周期较长的对象B 保有其引用的情况下，在A 的生命周期结束时，要在B 中清除掉对A 的引用。

1.3.5 其他

Android 应用程序中最典型的需要注意释放资源的情况是在Activity 的生命周期中，在onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity 生命周期的介绍，以明确何时应该释放哪些资源。

2内存泄露的分析工具

2.1 内存监测工具DDMS --> Heap

无论怎么小心，想完全避免bad code也很困难，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse 的ADT 插件，并以真机为例，在模拟器中的情况类似)。用Heap监测应用进程使用内存情况的步骤如下：

1. 启动eclipse后，切换到DDMS 视图，并确认Devices 视图、Heap 视图都是打开的；

2. 将设备通过USB 链接至电脑，链接时需要确认手机是处于“USB 调试”模式，而不是作为“Mass Storage”；

3. 链接成功后，在DDMS 的Devices 视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；

4. 点击选中想要监测的进程，比如system_process 进程；

5. 点击选中Devices 视图界面中最上方一排图标中的“Update Heap”图标；

6. 点击Heap 视图中的“Cause GC”按钮；

7. 此时在Heap 视图中就会看到当前选中的进程的内存使用量的详细情况［如图所示］。说明：

a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc 操作；

b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap 视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；

c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。

如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap 视图中部有一个Type 叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。点击“Data Object”这一行，会产生Allocation count per size的统计图。在data object 一行中有一列是“Total Size”，其值就是当前进程中所有Java 数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：

a) 不断的操作当前应用，同时注意观察data object 的Total Size 值；

b) 正常情况下Total Size 值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC 的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；

c) 反之如果代码中存在没有释放对象引用的情况，则data object 的Total Size 值在每次GC后不会有明显的回落，随着操作次数的增多Total Size 的值会越来越大，直到到达一个上限后导致进程被kill 掉。

d) 此处已system_process 进程为例，在我的测试环境中system_process 进程所占用的内存的data object 的Total Size 正常情况下会稳定在2.2~2.8 之间，而当其值超过3.55 后进程就会被kill。

总之，使用DDMS 的Heap 视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。

2.2 内存分析工具MAT (Memory Analyzer Tool)

如果使用DDMS 确实发现了我们的程序中存在内存泄漏，那又如何定位到具体出现问题的代码片段，最终找到问题所在呢？如果从头到尾的分析代码逻辑，那肯定会把人逼疯，特别是在维护别人写的代码的时候。这里介绍一个极好的内存分析工具-- Memory Analyzer Tool(MAT)。

MAT 是一个Eclipse 插件，同时也有单独的RCP 客户端。官方下载地址、MAT 介绍和详细的使用教程请参见：https://www.sodocs.net/doc/0310726375.html,/mat，在此不进行说明了。另外在MAT 安装后的帮助文档里也有完备的使用教程。在此仅举例说明其使用方法。我自己使用的是MAT 的eclipse 插件，使用插件要比RCP 稍微方便一些。

插件安装地址：https://www.sodocs.net/doc/0310726375.html,/mat/1.1/update-site，请在

eclipse->Help->Install new software中安装

使用MAT 进行内存分析需要几个步骤，包括：生成.hprof 文件、打开MAT 并导

入.hprof文件、使用MAT 的视图工具分析内存。以下详细介绍。

2.2.1 生成.hprof文件

1. 打开eclipse 并切换到DDMS 视图，同时确认Devices、Heap 和logcat 视图已经打开了；

2. 将设备链接到电脑，并确保使用“USB 调试”模式链接；

3. 链接成功后在Devices 视图中就会看到设备的序列号，和设备中正在运行的部分进程；

4. 点击选中想要分析的应用的进程，在Devices 视图上方的一行图标按钮中，同时选中“Update Heap”和“Dump HPROF file”两个按钮；

5. 这是DDMS 工具将会自动生成当前选中进程的.hprof 文件，并将其进行转换后存放在sdcard 当中，如果你已经安装了MAT 插件，那么此时MAT 将会自动被启用，并开始

对.hprof

文件进行分析；

注意：第4 步和第5 步能够正常使用前提是我们需要有sdcard，并且当前进程有向sdcard 中写入的权限(WRITE_EXTERNAL_STORAGE)，否则.hprof 文件不会被生成，在logcat 中会显示诸如

ERROR/dalvikvm(8574): hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied.的信息。

如果我们没有sdcard，或者当前进程没有向sdcard 写入的权限（如system_process），那我们可以这样做：

6. 在当前程序中，例如framework 中某些代码中，可以使用android.os.Debug 中的：public static void dumpHprofData(String fileName) throws IOException

方法，手动的指定.hprof 文件的生成位置。例如：

xxxButton.setOnClickListener(new View.OnClickListener() {

public void onClick(View view) {

android.os.Debug.dumpHprofData("/data/temp/myapp.hprof");

... ...

}

}

上述代码意图是希望在xxxButton 被点击的时候开始抓取内存使用信息，并保存在我们指定的位置：/data/temp/myapp.hprof，这样就没有权限的限制了，而且也无须用sdcard。但要保证/data/temp 目录是存在的。这个路径可以自己定义，当然也可以写成sdcard 当中的某个路径。

2.2.2 使用MAT导入.hprof文件

1. 如果是eclipse 自动生成的.hprof 文件，可以使用MAT 插件直接打开（可能是比较新的ADT才支持）；

2. 如果eclipse 自动生成的.hprof 文件不能被MAT 直接打开，或者是使用

android.os.Debug.dumpHprofData()方法手动生成的.hprof 文件，则需要将.hprof 文件进行转换，转换的方法：

例如我将.hprof 文件拷贝到PC 上的/ANDROID_SDK/tools 目录下，并输入命令hprofconv xxx.hprof yyy.hprof，其中xxx.hprof 为原始文件，yyy.hprof 为转换过后的文件。转换过后的文件自动放在/ANDROID_SDK/tools 目录下。OK，到此为止，.hprof 文件处理完毕，可以用来分析内存泄露情况了。

3. 在Eclipse 中点击Windows->Open Perspective->Other->Memory Analyzer，或者打Memory Analyzer Tool 的RCP。在MAT 中点击File->Open File，浏览并导入刚刚转换而得到的.hprof文件。

2.2.3 使用MAT的视图工具分析内存

导入.hprof 文件以后，MAT 会自动解析并生成报告，点击Dominator Tree，并按Package分组，选择自己所定义的Package 类点右键，在弹出菜单中选择List

objects->With incoming

references。这时会列出所有可疑类，右键点击某一项，并选择Path to GC Roots -> exclude weak/soft references，会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪到代码中的某一个产生泄露的类。

以下是MAT使用时的两个个简单示例：

例子1：将packages/app/Browser中的BrowserHistoryPage.java 中为ListView配置的Adapter是HistoryAdapter，在HistoryAdapter的getGroupView 和getChildView中不再使用缓存中存在的convertView，每次new 一个View。由此产生内存泄漏

分析过程：

用MA T打开.hprof文件，选择“Leak Suspect Report”，从Leak Suspect可以看到占用内存从多到少排列，列出的可疑的类。

由于heap dump 的时机不同，对于占用内存最多的类的分析结果不一样。Leak Suspects 会列出android.content.res.Resources为占用内存最多的类。三次heap dump的结果，有两次是分析android.app.FragmentManagerImpl占用内存次之，有一次分析出android.widget.ListView占用内存仅次于android.content.res.Resources。

下面分析的基础是推断android.widget.ListView是主要造成内存泄漏的类：

打开“object Histogram”从Class Name 的第一行筛选出 ListView

选择android.widget.ListView，由于它是一个基础类，点击左键->List Object->with outgoing reference(查看谁引用了它)，如下图：

其中shallow Heap是方此类本身的对象的内存大小，Retained Heap是加上被当前class 引用的所有对象占用的内存和。由于不知道申请哪个类造成的内存泄漏，通常先选择Retained Heap最大的类来跟踪。

列出的引用类中有CombinedBookmarkHistoryView中的mHistory，结合代码知道是BrowserHistoryPage类,所以选择https://www.sodocs.net/doc/0310726375.html,binedBookmarkHistoryView，点击左键->list Object->with incoming referances（查看它引用了哪些对象）：

发生在这个变量上的shallow Heap 和Retained Heap差值较大，说明被当前class（ListView

）所引用的连带对象占用的内存比本身这个类占用的内存多。结合代码查看mChildList如何占用这些内存。实际上之后通过为mChildList配置的Adapter（mAdapter）为整个ListView 提供每个view（通过getView函数）才能找到申请内存而没有释放的函数(这个例子是getGroupView 和getChildView)。

例子2：Leak Suspects 会列出LeakMemory为占用内存最多的类，

打开“object Histogram”从Class Name 的第一行筛选出LeakMemory，

察看此类中如何产生的泄漏，

Test.LeakMemory.dump.Leakmemory$Pilot为内部类，所以

点击左键->List Object->with outgoing reference（查看谁引用）, Patch to GC Root-> exclude weak/soft references(去掉弱引用/软引用)

上图中marray为HashMap类型，说明通过类Pilot泄漏的内存主要在marray 中申请的。

总之使用MAT 分析内存查找内存泄漏的根本思路，就是找到哪个类的对象的引用没有被释放，找到没有被释放的原因，从而能比较快速地定位代码中的哪些片段的逻辑有问题了。

其实上面的范例对于MAT这个专业分析工具来说实在不算什么，它还有很多高级的应用，本文只是抛砖引玉，介绍初步的使用方法，MAT的各个视图的作用请参照

https://www.sodocs.net/doc/0310726375.html,/mat/about/screenshots.php，MAT的高级使用方法请自行查阅MAT 的官方网站和客户端的帮助文档。

MAT虽然功能强大但使用起来相对复杂，需要开发者对代码和内存使用非常熟悉，并且最好是可疑程序的开发者来分析。即便如此，MAT还是不能自动定位出出现内存泄露的代码位置，还是需要人员去一点点分析报告和排查代码，并且有很多时候由于生成的报告并不完全准确，开发人员分析时也可能走向误区。所以再次重申希望开发人员尽量在代码编写阶段就避免使用不规范的代码，将内存泄露的隐患消除，不能单纯依赖内存分析检查工具，以免带来不必要的麻烦。

android避免内存泄露

1、数据库的cursor没有关闭 2、构造adapter没有使用缓存contentview 衍生的listview优化问题：减少创建View的对象，充分使用contentview，可以使用静态类来处理优化getView的过程 3、Bitmap对象不使用时采用recycle()释放内存 4、Activity中的对象生命周期大于Activity 调式方法：DDMS->HEAPSIZE->adtaobject->total size Android应用程序被限制在16MB的堆上运行，至少在T-Mobile G1上是这样。对于手机来说，这是很大的内存了；但对于一些开发人员来说，这算是较小的了。即使你不打算使用掉所有的内存，但是，你也应该尽可能少地使用内存，来确保其它应用程序得以运行。Android在内存中保留更多的应用程序，对于用户来说，程序间切换就能更快。作为我（英文作者）工作的一部分，我调查了Android应用程序的内存泄露问题，并发现这些内存泄露大多数都是由于相同的错误导致的，即：对Context拥有较长时间的引用。 在Android上，Context常用于许多操作，更多的时候是加载和访问资源。这就是为什么所有的Widget在它们的构造函数里接受一个Context的参数。在一个正常的Android应用程序里，你会看到两种Context类型，Activity和Application。而一般在需要一个Context的类和方法里，往往传入的是第一种： Java代码 @Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText("Leaks are bad");

Android 应用程序内存泄漏的分析

Android 应用程序内存泄漏的分析以前在学校里学习Java的时候，总是看到说，java是由垃圾收集器（GC）来管理内存回收的，所以当时形成的观念是Java不会产生内存泄漏，我们可以只管去申请内存，不需要关注内存回收，GC会帮我们完成。呵呵，很幼稚的想法，GC没那么聪明啊，理论及事实证明，我们的Java程序也是会有内存泄漏的。 （一）Java内存泄漏从何而来 一般来说内存泄漏有两种情况。一种情况如在C/C++语言中的，在堆中的分配的内存，没有将其释放，或者是在没有将其释放掉的时候，就将所有能访问这块内存的方式都删掉（如指针重新赋值）；另一种情况则是在内存对象明明已经不需要的时候，还仍然保留着这块内存和它的访问方式（引用）。第一种情况，在Java中已经由于垃圾回收机制的引入，得到了很好的解决。所以，Java中的内存泄漏，主要指的是第二种情况。 （二）需要的工具 1.DDMS—Update heap Gause GC Heap 是DDMS自带的一个很不错的内存监控工具，下图红色框中最左边的图标就是该 工具的启动按钮，它能在Heap视图中显示选中进程的当前内存使用的详细情况。下图 框中最右边的是GC工具，很多时候我们使用Heap监控内存的时候要借助GC工具，点 击一次GC按钮就相当于向VM请求了一次GC操作。中间的按钮是Dump HPROF file，它 的功能相当于给内存拍一张照，然后将这些内存信息保存到hprof文件里面，在使用我 们的第二个工具MAT的时候会使用到这个功能。 2.MAT(Memory Analyzer Tool) Heap工具能给我们一个感性的认识，告诉我们程序当前的内存使用情况和是否存在内存 泄漏的肯能性。但是，如果我们想更详细，更深入的了解内存消耗的情况，找到问题所 在，那么我们还需要一个工具，就是MAT。这个工具是需要我们自己去下载的，可以下 载独立的MAT RCP 客户端，也可以以插件的形式安装到Eclipse里面，方便起见，推荐 后者。 安装方法： A．登录官网https://www.sodocs.net/doc/0310726375.html,/mat/downloads.php B．下载MAT Eclipse插件安装包（红框所示，当然你也可是选择Update Site在线安装，个人觉得比较慢）

Android开发规范参考文档

Android开发参考文档 一、Android编码规范 1. java代码中不出现中文，最多注释中可以出现中文.xml代码中注释 2. 成员变量，局部变量、静态成员变量命名、常量(宏)命名 1). 成员变量: activity中的成员变量以m开头，后面的单词首字母大写（如Button mBackButton; String mName）；实体类和自定义View的成员变量可以不以m开头（如ImageView imageView，String name）， 2）. 局部变量命名：只能包含字母，组合变量单词首字母出第一个外，都为大写，其他字母都为小写 3）. 常量(宏)命名: 只能包含字母和_，字母全部大写，单词之间用_隔开UMENG_APP_KEY 3. Application命名 项目名称+App，如SlimApp,里面可以存放全局变量，但是杜绝存放过大的实体对象4. activity和其中的view变量命名 activity命名模式为：逻辑名称+Activity view命名模式为：逻辑名称+View 建议：如果layout文件很复杂，建议将layout分成多个模块，每个模块定义一个moduleViewHolder，其成员变量包含所属view 5. layout及其id命名规则 layout命名模式：activity_逻辑名称，或者把对应的activity的名字用“_”把单词分开。

命名模式为：view缩写_模块名称_view的逻辑名称, 用单词首字母进行缩写 view的缩写详情如下 LayoutView：lv RelativeView:rv TextView:tv ImageView:iv ImageButton:ib Button:btn 6. strings.xml中的 1）. id命名模式： activity名称_功能模块名称_逻辑名称/activity名称_逻辑名称/common_逻辑名称，strings.xml中，使用activity名称注释，将文件内容区分开来 2). strings.xml中使用%1$s实现字符串的通配,合起来写 7. drawable中的图片命名 命名模式：activity名称_逻辑名称/common_逻辑名称/ic_逻辑名称 (逻辑名称: 这是一个什么样的图片，展示功能是什么) 8. styles.xml 将layout中不断重现的style提炼出通用的style通用组件，放到styles.xml中； 9. 使用layer-list和selector，主要是View onCclick onTouch等事件界面反映

超强Android系统SD卡分区教程,加速你的Android系统

强烈分享分区软件 Acronis Disk Director Suite 10 通过读卡器给SD卡分三区的方法 Acronis Disk Director Suite 10 中文免注册版 68MB 下载地址： https://www.sodocs.net/doc/0310726375.html,/groups/@g165358/259136.topic 第一步、安装 Acronis Disk Director Suite 10 中文免注册版 第二步、将SD卡插入读卡器，读卡器再插进电脑USB接口 第三步、打开我的电脑，选择SD卡盘符鼠标右键选择格式化（FAT32）不要选择快速格式化 第四步、打开电脑里面的控制面板选择管理工具选择计算机管理 现在看左边，选择储存 -> 磁盘管理 现在看右边，看到你的 SD卡分区没？ 鼠标放在你的 SD卡那个分区上，鼠标右键呼出菜单，选择删除磁盘分区，OK 第五步、打开 Acronis Disk Director Suite 10 你现在实际应该选择的分区顺序和大小是： 分第一个分区“FAT32”格式大小选择，你的卡的总容

量 xxxxMB 减 580MB，得出来的就都是FAT32的空间容量 分第二个分区“EXT3”格式大小选择，580MB-96MB（EXT3这个分区，300-499MB都可以，但注意不要超过499MB）一般来说这个分区大小在四百多MB，这个分区分的时候需要注意，这个区分完后剩余的空间大小不能超过96MB，推荐剩余94.13M，留给最后的一个分区就行了 分第三个分区“Linux交换”格式大小嘛，最后的都是它的咯，推荐94.13M 以上分区的时候，你之前划拨的空间与出来以后显示大小，肯定数字上有出入，这个正常，不去管它，你只要确认你分出来以后的大小就行了！ 下面的第18步之前，你要确认你分的区是上面说的三个区，且 ETX3格式分区没有超过499MB、Linux交换格式分区没有超过96MB(或者说94.13MB)， 1.点选已删除分区的SD卡，创建新的分区

Android开发内存泄漏及检查工具使用培训资料

Android 开发内存泄漏及检查工具使用培 训资料

目录 1内存泄露 (3) 1.1 内存泄露的概念 (3) 1.2 开发人员注意事项 (4) 1.3 Android（java）中常见的引起内存泄露的代码示例 (4) 1.3.1查询数据库没有关闭游标 (6) 1.3.2 构造Adapter时，没有使用缓存的convertView (6) 1.3.3 Bitmap对象不在使用时调用recycle()释放内存 (7) 1.3.4 释放对象的引用 (8) 1.3.5 其他 (9) 2内存泄露的分析工具 (9) 2.1 内存监测工具DDMS --> Heap (9) 2.2 内存分析工具MAT (Memory Analyzer Tool) (10) 2.2.1 生成.hprof文件 (10) 2.2.2 使用MA T导入.hprof文件 (11) 2.2.3 使用MA T的视图工具分析内存 (12)

1内存泄露 Android 应用程序开发以Java语言为主，而Java编程中一个非常重要但却经常被忽视的问题就是内存使用的问题。Java的垃圾回收机制(Garbage Collection 以下简称GC)使得很多开发者并不关心内存使用的生命周期，只顾着申请内存，却不手动释放废弃的内存，而造成内存泄露，引起很多问题，甚至程序崩溃。Android的虚拟机Dalvik VM和java虚拟机JVM没有什么太大的区别，只是在字节码上稍做优化，所以Android应用开发中同样会出现内存泄露的问题。而且由于Android智能平台主要用于嵌入式产品开发，可用的内存资源更加稀少，所以对于我们Android应用开发人员来说，就更该了解Android程序的内存管理机制，避免内存泄露的发生。 1.1 内存泄露的概念 在计算机科学中，内存泄漏(memory leak)指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。内存泄漏与许多其他问题有着相似的症状，并且通常情况下只能由那些可以获得程序源代码的程序员才可以分析出来。然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，严格意义上来说这是不准确的。 一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显式释放的内存。应用程序一般使用malloc，calloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。 这里我们只简单的理解，在java程序中，如果已经不再使用一个对象，但是仍然有引用指向它，GC就无法收回它，当然该对象占用的内存就无法再被使用，这就造成内存泄露。可能一个实例对象的内存泄露很小，并不会引起很大的问题。但是如果程序反复做此操作或者长期运行，造成内存不断泄露，终究会使程序无内存可用，只好被系统kill掉。在以下情况，内存泄漏导致较严重的后果： * 程序运行后置之不理，并且随着时间的流失消耗越来越多的内存（比如服务器上的后台任务，尤其是嵌入式系统中的后台任务，这些任务可能被运行后很多年内都置之不理）； * 新的内存被频繁地分配，比如当显示电脑游戏或动画视频画面时； * 程序能够请求未被释放的内存（比如共享内存），甚至是在程序终止的时候； * 泄漏在操作系统内部发生； * 泄漏在系统关键驱动中发生； * 内存非常有限，比如在嵌入式系统或便携设备中； * 当运行于一个终止时内存并不自动释放的操作系统（比如AmigaOS）之上，而且一旦丢失只能通过重启来恢复。

android如何查看cpu的占用率和内存泄漏

android如何查看cpu的占用率和内存泄漏 在分析内存优化的过程中，其中一个最重要的是我们如何查看cpu的占用率和内存的占用率呢，这在一定程度上很重要，经过查询资料，研究了一下，暂时了解到大概有以下几种方式，如果哪位高手有更好的办法，或者文中描述有错误，还望高手在下面留言，非常感谢！ 一、通过eclipse，ADT开发工具的DDMS来查看(Heap) 在“Devices”窗口中选择模拟器中的一个需要查看的程序，从工具条中选“Update heap”按钮，给这个程序设置上“heap Updates”，然后在Heap视图中点击Cause GC就可以实时显示这个程序的一些内存和cpu的使用情况了。

然后就会出现如下界面： 说明： a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作； b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定

时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化； c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。 大致解析如下： 这个就是当前应用的内存占用，allocated 是已经分配的内存free是空闲内存， heap size 是虚拟机分配的不是固定值 heap size 的最大值跟手机相关的 有网友说， 一般看1byte的大部分就是图片占用的 如何判断应用是否有内存泄漏的可能性呢？ 如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断： a) 不断的操作当前应用，同时注意观察data object的Total Size值； b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平； c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC 后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大， 直到到达一个上限后导致进程被kill掉。

android vold学习总结

vold学习总结 V old(volume daemon):源码路径android/system/vold，部分引用代码位于android/system/core/libsysutils/src，android/system/core/include/sysutils/下。 它用于管理和控制android平台的外部设备，包括u盘、sd卡等的插入，拔出和格式化等。V old为守护进程，由init进程启动，V old的框架如下图所示： Linux kernel与vold进程通过netlink机制进行跨进程通信，vold中的NetlinkManager 接收来自linux kernel上报的uevent事件，然后将其转换成一个NetlinkEvent类型，并调用V olumeManager类的相应方法进行处理，V olumeManager会将处理的结果发送给MountService，VolumeManager与MountService之间通过CommandListener机制进行通信，本质是通过socket进行跨进程通信，MountService运行在SystemServer进程中。 Uevent事件内容就是一个字符串，linux kernel在下列两种情况下会上报uevent事件： 1.外设状态发生变化触发，当有U盘、sd卡等外设的插拔动作时，都会引起linux kernel 上报uevent事件，如果vold在外设状态发生变化之前已经建立了netlink连接，就能收到相应的uevent事件。 2.在/sys目录下会有一个叫做uevent的文件，往该文件中写入特定的数据，也会触发kernel发送和该设备相关的uevent事件，这个由应用层触发，例如vold启动时，会往uevent 文件中写入数据，它就会触发linux kernel发送uevent事件，这样vold就能获取设备的当前信息。 在etc/目录下有个vold.fstab文件（实际上该文件是在system/etc目录下，它在system/core/rootdir/init.rc中有配置：symlink /system/etc /etc，通过软链接而链接到etc目录下），该文件是android系统与硬件平台交互的接口，用户可以手动配置该文件，在 android\system\core\rootdir\etc\下有个vold.fstab文件，它描述了vold.fstab文件配置挂载设备的模板， dev_mount

android内存管理-MAT与防范手段

内存管理与防范手段 目录 内存管理与防范手段 (1) 一．内存分配跟踪工具DDMS–>Allocation tracker 使用 (2) 二．内存监测工具DDMS-->Heap (2) 三．内存分析工具MAT(MemoryAnalyzerTool) (3) 1.生成.hprof文件 (4) 2.使用MAT导入.hprof文件 (5) 3.使用MAT的视图工具分析内存 (5) 四．MAT使用实例 (5) 1.生成heap dump (7) 2.用MAT分析heap dumps (9) 3.使用MAT比较heap dumps (11) 五．防范不良代码 (11) 1．查询数据库没有关闭游标 (11) 2．缓存convertView (12) 3．Bitmap对象释放内存 (13) 4．释放对象的引用 (13) 5．Context的使用 (14) 6．线程 (17) 7．其他 (20) 六．优化代码 (20) 1.使用自身方法（Use Native Methods） (20) 2.使用虚拟优于使用接口 (20) 3.使用静态优于使用虚拟 (20) 4.尽可能避免使用内在的Get、Set方法 (20) 5.缓冲属性调用Cache Field Lookups (21) 6.声明Final常量 (21) 7.慎重使用增强型For循环语句 (22) 8.避免列举类型Avoid Enums (23) 9.通过内联类使用包空间 (23) 10.避免浮点类型的使用 (24) 11.一些标准操作的时间比较 (24) 12.为响应灵敏性设计 (25)

一．内存分配跟踪工具DDMS–>Allocation tracker 使用 运行DDMS，只需简单的选择应用进程并单击Allocation tracker标签，就会打开一个新的窗口，单击“Start Tracing”按钮；然后，让应用运行你想分析的代码。运行完毕后，单击“Get Allocations”按钮，一个已分配对象的列表就会出现第一个表格中。单击第一个表格中的任何一项，在表格二中就会出现导致该内存分配的栈跟踪信息。通过allocation tracker，不仅知道分配了哪类对象，还可以知道在哪个线程、哪个类、哪个文件的哪一行。 尽管在性能关键的代码路径上移除所有的内存分配操作不是必须的，甚至有时候是不可能的，但allocation tracker可以帮你识别代码中的一些重要问题。举例来说，许多应用中发现的一个普遍错误：每次进行绘制都创建一个新的Paint对象。将Paint的创建移到一个实例区域里，是一个能极大提高程序性能的简单举措。 二．内存监测工具DDMS-->Heap 无论怎么小心，想完全避免badcode是不可能的，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Androidtools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使eclipse的ADT插件，并以真机为例，在模拟器中的情况类似)。用Heap 监测应用进程使用内存情况的步骤如下： 1.启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的； 2.将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“MassStorage”； 3.链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息； 4.点击选中想要监测的进程，比如system_process进程； 5.点击选中Devices视图界面中最上方一排图标中的“UpdateHeap”图标； 6.点击Heap视图中的“CauseGC”按钮； 7.此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况 a)点击“CauseGC”按钮相当于向虚拟机请求了一次gc操作；

安卓性能优化方案

随着技术的发展，智能手机硬件配置越来越高，可是它和现在的PC相比，其运算能力，续航能力，存储空间等都还是受到很大的限制，同时用户对手机的体验要求远远高于PC的桌面应用程序。以上理由，足以需要开发人员更加专心去实现和优化你的代码了。选择合适的算法和数据结构永远是开发人员最先应该考虑的事情。同时，我们应该时刻牢记，写出高效代码的两条基本的原则：（1）不要做不必要的事；（2）不要分配不必要的内存。 我从去年开始接触Android开发，以下结合自己的一点项目经验，同时参考了Google的优化文档和网上的诸多技术大牛给出的意见，整理出这份文档。 1. 内存优化 Android系统对每个软件所能使用的RAM空间进行了限制(如：Nexus o ne 对每个软件的内存限制是24M)，同时Java语言本身比较消耗内存，d alvik虚拟机也要占用一定的内存空间，所以合理使用内存，彰显出一个程序员的素质和技能。 1) 了解JIT 即时编译（Just-in-time Compilation，JIT），又称动态转译（Dynamic Translation），是一种通过在运行时将字节码翻译为机器码，从而改善字节码编译语言性能的技术。即时编译前期的两个运行时理论是字节码编译和动态编译。Android原来Dalvik虚拟机是作为一种解释器实现，新版

（Android2.2+）将换成JIT编译器实现。性能测试显示，在多项测试中新版本比旧版本提升了大约6倍。 详细请参考https://www.sodocs.net/doc/0310726375.html,/cool_parkour/blog/item/2802b01586e22cd8a6ef3f6b. html 2) 避免创建不必要的对象 就像世界上没有免费的午餐，世界上也没有免费的对象。虽然gc为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则： 当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个Stri ngBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。 一个更极端的例子是，把多维数组分成多个一维数组： int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多。同理，这试用于所有基本类型的组合。如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[]

Android实训心得

Android实训心得 刚开始接触Android感觉到它很有意思，在界面开发上和web也可以形成了相通 的架构，更加方便，视觉上也是非常的酷，在前期我通过的大量的Android SDK开发 范例大全中的例子以及Android提供的APIDEMOS进行学习，尽管例子之间的连接比 较零散，不过通过这些例子的学习我可以学习到了很多和以前java上相通的思想。 我在为期半个月的实习中学到了很多在课堂上根本就学不到的知识，收益非浅．现在我对这半个月的实习做一个工作小结。 通过半个月的android实习，基本掌握了Android应用程序开发的一般流程。对常用控件基本掌握其用法，对其事件的监听方法也基本掌握。学习Android不仅是对前 沿开发技术的了解，也是对编程知识的一次提升。 通过学习Android的控件、布局、Activity、Service等一系列基础知识，对整个Android的开发有了大致的了解。例如要的布局(或者控件) ,在学习界面中，我发现Android为我们提供了很好的类似反射机制，通过Layout文件夹下的配置文件，可以 快速的形成界面，在配置文件可以设置属性或者样式都是很快捷方便。对比较特殊的 界面也可以通过处理嵌入到指定的界面，同样你可以通过java代码直接创建View进 行添加，不过这种方式比较复杂。对一些点击、选中、按键等处理的事件，界面之间 的跳转Intent管理，通过Bundle对数据在界面之间进行传输。 在手机交互式通信服务中，学习了Android手机之间进行短信发送、广播、对广 播的监听、服务等，在Service类中没有context，可以通过Handler来每秒反复运行，自动送出系统广播信息，同时在这里我们也知道可以设计一个常用的变量类，设计一 个当前的CurrentActivity这个变量进行控制，进行处理。 在Android编程过程中巩固熟悉了Java的编程。由于Android应用程序的开发离 不开Java的支持，所以基础的Java知识是必须的。Android系统是基于Linux的手机操作系统平台，要深入系统的学习Android，不仅仅是有Java和Android应用开发， 必须要具备Linux，CC++高级编程才能深入的涉及Android Framework和Android内 核开发。成为Android开发的高素质人才。所以，在后续对Android的学习中可能会看一些较底层的书籍。

改变Android手机软件安装位置的解决办法(精)

改变 Android 手机软件安装位置的解决办法 谷歌 Android 系统手机默认只能把软件安装在手机内存里,使本来就不大的手机内存显得捉襟见肘。如果你也是个手机软件狂人,喜欢尝试各种各样新奇有趣的软件,面对越来越少的手机内存空间,不得不对已经安装的软件痛下 **。你是否还在安装与卸载之间纠结? Follow Me!我们一起来给 Android 系统扩扩容,让“ 机器人” 也可以“ 大肚能容” ,免去存储空间不足的后顾之忧。 Tips :存储器分为随机存储器(RAM 和只读存储器(ROM 两种。手机 ROM 相当于 PC 上的硬盘, 用于存储手机操作系统和软件, 也叫 FLASH ROM, 决定手机存储空间的大小。手机 RAM 相当于 PC 的内存,其大小决定手机的运行速度。 要把大象装冰箱里总共分三步, 而 Android 系统中把软件安装到 SD 卡上, 比这还简单, 两步就够了: 一、存储卡分区 首先我们需要对手机 SD 卡进行分区, 分一个 FAT32分区和一个 Ext3分区, FAT32分区用于正常存储图片、音乐、视频等资料,而 Linux 格式的 Ext3分区就是用于扩容安装软件的分区。以笔者的 2G SD卡为例, FAT32分区 1.35GB , Ext3分区 494MB 。下载并安装 Acronis Disk Director Suite 软件。将手机 SD 卡装入读卡器并连接电脑,然后运行 Acronis Disk Director Suite软件。 1.FAT32分区。找到代表 SD 卡的磁盘分区,点击右键,选择“ 删除” 命令,删除已有分区。当成为“ 未分配” 分区时,点击右键,选择“ 创建分区” ,在弹出的对话框中,文件系统选择: FAT32,创建为“ 主分区” ,设置好分区大小 1.35GB ,点击确定按钮。 2. Ext3分区。在剩余的 494MB 分区上,点击右键,选择“ 创建分区” ,在弹出的对话框中, 文件系统选择:Ext3,创建为“ 主分区” ,设置好分区大小 494MB ,点击确定按钮。

中科院计算所Android开发技术培训大纲

高级Android开发技术 一、培训对象： 1、有Android开发基础，希望进一步提升者； 2、目前从事JAVA开发相关工作者或拥有良好JAVA语言基础的工程师、程序员，以及相关行业的工程技术人员，Android应用开发的移动终端开发的爱好者。 二、师资： 杨老师：主要研究网络信息分析以及Android相关技术，长期从事通信网管系统、网络信息处理、商务智能(BI)以及电信决策支持系统的研究开发工作，主持和参与了多个国家和省部级基金项目，具有丰富的工程实践及软件研发经验。 三、课程设计思路： 本课程的授课方式是采用比较法，充分利用学员已有的工作经验，通过与Java原有程序体系的比较分析，不但能够迅速掌握Android开源代码结构，理解中间件下层的库，能够进行Android的高级编程，而且使学员具备可持续发展的能力。 四、培训内容 第一天 第1章phonegap框架 1.1 手机操作系统 1.2 开放手机联盟 1.3 phonegap介绍 1.4 phonegap框架 1.5 接口和所需工具 1.6 phonegap和android 第2章Html5 api和Event事件 2.1 Html5特性 2.2 下载、构建以及使用xui 2.3 Event事件 2.4 使用phonegap 2.5 媒体事件和属性 2.6 html5性能改进 第3讲 Android生命周期 3.1 程序生命周期 3.2 Android组件

3.3 Activity生命周期 3.4 程序调试 3.4.1 LogCat 3.4.2 DevTools 第4讲 Android用户界面 4.1 用户界面基础 4.2 界面控件 4.3 界面布局 4.3.1 线性布局 4.4 菜单 4.4.1 菜单资源 4.4.2 选项菜单 4.4.3 子菜单 4.4.4 快捷菜单 4.5 操作栏与Fragment 4.5.1 操作栏 4.5.2 Fragment 4.5.3 Tab导航栏 4.6 界面事件 4.6.1 按键事件 4.6.2 触摸事件 第5讲组件通信与广播消息 5.1 Intent简介 5.1.1 启动Activity 5.1.2 获取Activity返回值 5.2 Intent过滤器 5.3 广播消息 第二天 第6讲后台服务 6.1 Service简介 6.2 本地服务 6.2.1 服务管理 6.2.2 使用线程 6.2.3 服务绑定

Android App内存泄露测试方法总结

Android App内存泄露测试方法总结 1、内存泄露 Android系统为每一个运行的程序都指定了一个最大运行内存，超过这个值则会触发OOM机制，反应在界面就是闪退、Crash现象，导致OOM发生的原因比如内存泄露或者是代码不考虑后果使用大量的资源，都有可能导致OOM出现的。OOM的临界值可以通过adb shell getprop | findstr “heap”查看到： 2、Android的GC机制 Android GC机制沿用了java的GC机制，当需要新内存去分配对象的时候而剩余不够的时候，会触发GC，把无用的对象回收掉，其中一个重要的算法便是分代式算法，这个算法把虚拟机分为年轻代、老年代和持久代，对象先分配到年轻代，然后GC多次后还存活的将会移动到老年代，老年代就不会频繁触发GC机制，一般触发频繁的都是年轻代的对象。 3、为什么会内存泄露 上面我们知道了GC机制，那么如果GC过后程序还是没有内存，那么会发生OOM，导致GC后还是没有足够内存分配新对象的主要原因就是内存泄露了。首先要知道内存泄露也就是GC不掉的根源是生命周期长的对象持有生命周期短的对象，导致无用的对象一直无法回收。以下是几个典型的分类： 1）**静态类相关的泄露：**static对象的生命周期伴随着整个程序的生命周期，所以这块要注意不要把一些对象引用添加到static对象里面去，会造成与之关联的对象无法回收。

2）各种资源的释放：包括cursor的关闭，IO流的关闭，bitmap的回收等，进行一些带有缓存的资源一定要关闭或者释放。 3）Handler的泄露：调用handler的delay的时候，会被认为对象是有用的，导致无法回收，还有handler开启线程去下载东西没有下载完成的时候，也会因为线程导致无法回收activity；或者使用handlerThread的时候，有延迟的方法，都会导致无法回收。其主要原因在于handler是持有activity的引用，主线程不是自带一个Looper然后给handler用，导致有关联关系。 4）各种注册引用方法：比如一个常驻的后台线程处理某些时间，把当前对象注册，因为一直持有对象引用，导致这个activity一直保留，所以不用的时候需要反注册。 5）把对象缓存进容器内却忘记remove掉：有时候为了加快页面响应，结果缓存一些对象到容器内，结果越加越多，然后挂掉。 4、系统级别的内存管理 1）LMK机制和oom_adj的值 Android内核有个专用的驱动low-memory-kill，当系统级别的内存不够的时候会根据oom_adj的值以及内存分配状况去kill掉某个进程，oom_adj可以在 /proc/[pid]/oom_adj看到，并且这个值会随着进程的状态改变而改变，比如系统进程一般是-16，越大越容易被干掉。 2）5个进程的优先级 前台进程：当前运行的，基本不死； 可见进程：界面可以见到，比如被遮挡； 服务进程：进程带后台服务的，比如播放器； 后台进程：点击home键，但不退出，就是后台进程了，有比较大几率会被杀；

Android内存优化小建议 以及活用(SoftReference 和 WeakReference )

android因其系统的特殊性,安装的软件默认都安装到内存中,所以随着 用户安装的软件越来越多,可供运行的程序使用的内存越来越小,这就要求我们在开发android程序时,尽可能的少占用内存。根据我个人的开发经验总结了如下几点优化内存的方法: 1创建或其他方式获得的对象如不再使用,则主动将其置为null。 2尽量在程序中少使用对图片的放大或缩小或翻转.在对图片进行操作时占用的内存可能比图片本身要大一些。 3调用图片操作的后，及时的清空，调用recycle()提醒经行垃圾回收。 4尽可能的将一些静态的对象(尤其是集合对象),放于SQLite数据库中。并且对这些数据的搜索匹配尽可能使用sql语句进行。 5一些连接资源在不使用使应该释放,如数据库连接文件输入输出流等。应该避免在特殊的情况下不释放(如异常或其他情况) 6一些长周期的对像引用了短周期的对象,但是这些短周期的对象可能只在很小的范围内使用。所以在查内存中也应该清除这一隐患。如果你想写一个Java程序，观察某对象什么时候会被垃圾收集的执行绪清除，你必须要用一个reference记住此对象，以便随时观察，但是却因此造成此对象的reference数目一直无法为零，使得对象无法被清除。 https://www.sodocs.net/doc/0310726375.html,ng.ref.WeakReference 不过，现在有了Weak Reference之后，这就可以迎刃而解了。如果你希望能随时取得某对象的信息，但又不想影响此对象的垃圾收集，那

么你应该用Weak Reference来记住此对象，而不是用一般的reference。 A obj=new A(); WeakReference wr=new WeakReference(obj); obj=null; //等待一段时间，obj对象就会被垃圾回收 … if(wr.get()==null){ System.out.println(“obj已经被清除了“); }else{ System.out.println(“obj尚未被清除，其信息是 “+obj.toString()); } … 在此例中，透过get()可以取得此Reference的所指到的对象，如果传出值为null的话，代表此对象已经被清除。 这类的技巧，在设计Optimizer或Debugger这类的程序时常会用到，因为这类程序需要取得某对象的信息，但是不可以影响此对象的垃圾收集。 https://www.sodocs.net/doc/0310726375.html,ng.ref.SoftReference Soft Reference虽然和Weak Reference很类似，但是用途却不同。被Soft Reference指到的对象，即使没有任何Direct Reference，也不会被清除。一直要到JVM内存不足时且没有Direct Reference

android手机micro sd卡的EXT2,EXT3分区教程

下面就介绍利用 分区软件Acronis Disk Director Suite 10 通过读卡器给SD卡分三区的方法 （注意，这个方法只能用读卡器，手机U盘模式不行） Acronis Disk Director Suite 10 中文免注册版68MB 下载地址： https://www.sodocs.net/doc/0310726375.html,/groups/@g165358/259136.topic 第一步、安装Acronis Disk Director Suite 10 中文免注册版 第二步、将SD卡插入读卡器，读卡器再插进电脑USB接口 第三步、打开我的电脑，选择SD卡盘符鼠标右键选择格式化（FAT32）不要选择快速格式化 第四步、打开电脑里面的控制面板选择管理工具选择计算机管理 现在看左边，选择储存-> 磁盘管理 现在看右边，看到你的SD卡分区没？ 鼠标放在你的SD卡那个分区上，鼠标右键呼出菜单，选择删除磁盘分区，OK 第五步、打开Acronis Disk Director Suite 10 （这一步照抄啊兴的咸湿教程） 但是要强调的是 1，啊兴的这个只做了FAT32和EXT2两个分区，你现在要做的是分别选择FAT32、EXT3、Linux交换三个分区，而不是下面教程里面的两个。这个要注意了！ 2, 这个看来要强调一下了，根据经验来看分区先后顺序有的机子没什么要求，而有的机子必须按照先FAT32 再EXT3 最后Linux交换的顺序来分区！如果你没什么经验，还是保守的按照这个顺序来吧！ 3，啊兴的这个是256MB 的卡，下面的分区大小不要跟着学 你现在实际应该选择的分区顺序和大小是： 分第一个分区“FAT32”格式大小选择，你的卡的总容量xxxxMB 减580MB，得出来的就都是FAT32的空间容量 分第二个分区“EXT3”格式大小选择，580MB-96MB（EXT3这个分区，300-499MB都可以，但注意不要超过499MB）一般来说这个分区大小在四百多MB，这个分区分的时候需要注意，这个区分完后剩余的空间大小不能超过96MB，推荐剩余94.13M，留给最后的一个分区就行了 分第三个分区“Linux交换”格式大小嘛，最后的都是它的咯，推荐94.13M

低端android机内存管理优化

大家好,今天我主要来和大家交流下低端ａndrｏid手机内存优化的问题。 一、问题的引出 前天,我在论坛发了一个帖子，想请教大家关于联想A68e内存优化的问题,但是回复者寥寥无几,课件也很少有机油对这方面有较深入的 学习了解。我今天中午，查了有关资料,也用了自己的手机进行了测试,觉得可能对A６８ｅ（其实是广大低端Ａndroｉｄ手机)用户有点帮助,所以特地来分享以下。（说明:本人用的是Sumsumg I9１03,我媳妇用的是电信套餐的联想Ａ68e，这几天我没拿到她的手机来测试，所以只能自己的手机进行测试，但是我觉得还是具有一定的参考价值的）。二、ROＭ和RAM 首先，我先解释一下ROM和RＡM的区别。 ＲOＭ是Read Onlｙ Memory,即只读存储器；RAM是Aｃｃｅss Random Meｍorｙ,即随即读写存储器。 ＲＯＭ是存储程序和数据的,类别电脑的硬盘，可以存放安装的程序、文件、数据等。而论坛中有开AｐpEXT２的方法(我没试过),那个只是节省出更多的ＲOＭ空间,这样可以使程序运行得更为流畅，但是不能解决“同时运行程序的数量最大值太小”的问题。以Ａ６8e为例,如果开一个QQ、音乐播放器，再开个UC浏览器估计机子就崩溃而导致程序退出。 RAM才是程序运行时所占用的物理空间。RAM的价格比ROM贵很多，所以RＡM的大小一半程度上决定了机子的价位（另一半就是CＰＵ）。

我的Suｍsuｎg是1G RAM，同时开QQ、QQ游戏、ＱQ音乐、浏览器、微信等七、八个程序也毫无压力。所以RAM太小是影响A６8ｅ（包括很多Android手机)用户体验的原因。如果你是个游戏玩家、手机达人,那么这类机子一定不适合你。如果你希望能像有高端机那样的用户体验,我建议你还是多话点银子购买配置高的Aｎdroiｄ手机。 关于官方宣传256的RＡＭ实际上只有１70，那是有一部分被Anｄroid系统占用。我的手机1ＧRAＭ,实际上也只有724M。 三、Ａnｄroｉｄ系统内存管理机制及进程调度机制 下面开始具体的分析了。 首先Andrｏiｄ系统是基于Ｌinux 内核开发的开源操作系统，li ｎuｘ系统的内存管理有其独特的动态存储管理机制。Anｄroid采取了一种有别于Linux的进程管理策略，Liｎuｘ系统在进程活动停止后就结束该进程,而Andrｏid把这些进程都保留在内存中,直到系统需要更多内存为止。这些保留在内存中的进程通常情况下不会影响整体系统的运行速度，并且当用户再次激活这些进程时,提升了进程的启动速度。 Androｉｄ系统这样的设计不仅非常适合移动终端(手机、平板）的需要,而且减少了系统崩溃的可能,确保了系统的稳定性。老想着清理内存的同学完全是因为被塞班或者Ｗiｎｄoｗs毒害太深,事实上,经常用Taskilleｒ之类的软件关闭后台所有进程,很容易造成系统的不稳定。很多时候出现问题了，只要重启就能解决的原因也在于此。 广大机油一定会发现,关闭了QQ、微信等程序后，其实并没有完全关闭这些程序。这些程序在后台占用了一定的内存,但是并没有运行时