首先在本地修改代码
再执行如下命令：

git add ./

git commit –amend

repo upload ./ –replace

仔细查看下，就会找到dispatchWapPdu_MMS()这个函数

注意别混了， mSmsDispatcher.dispatch的第二个参数不是action的意思，而是权限，实际这个intent的action就是Intents.WAP_PUSH_RECEIVED_ACTION

然后，mms包（com.android.mms.transaction）下的onReceive会得到这个intent，进行处理
在这个onReceive里，会调用内部类去执行：

在这个内部类的doInBackground方法里，则会再继续根据pdu类型，来判断如何处理

在TransactionService里，实际上会最终调用NotificationTransaction

在NotificationTransaction里，则会完成Notification事务

到这里（sendNotifyRespInd），这个事务应该算结束了。

答案是有小窍门，可以把你的“汉字”的应用名排到前面去，那就是修改app_name的值

先看看如何做吧，以应用汇为例
在values/string.xml里有如下代码

怎么样，一下子就明白了吧，app_name前面应该是有个空格，这样可以保证这个程序甚至可以排到a开头的程序的前面

掌上应用汇做的比较巧妙

感觉很是巧妙
在操作函数中（updateMessageOnIccEf），发送消息之后调用mLock.wait(),而在handler里处理消息结果的时候notifyAll()，感觉很是巧妙。

大家不一定能在实际中有什么用处，但是可以参考下

只需要如下命令即可：
$ adb shell
# cat /dev/graphics/fb0 > /sdcard/frame.raw

然后用FFMPEG转换为png
$ IMAGE_RES=320×480
$ RAW_IMAGE=frame.raw
$ OUT_IMAGE=frame-%d.png
$ #Download the raw data
$ adb pull /sdcard/$RAW_IMAGE .
$ ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb565 -s $IMAGE_RES \
-i $RAW_IMAGE -f image2 -vcodec png $OUT_IMAGE

可以参考http://my.opera.com/otaku_2r/blog/grab-a-frame-in-android-frame-buffer

看看下面代码，如何？

有什么问题吗？

对，这段代码生成了一个thread的对象，竟然调用了run方法，这引起了内存泄露。
必须改为start才行。

而run方法，只是调用了Runnable的run方法而已：
// Thread.class

而start方法则不同

低版本的java有这个问题，不知道为什么Android2.2还有这个问题：
http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=5869e03fee226ffffffffc40d4fa881a86e3:WuuT?bug_id=4533087

按上面说法，生产一个Thread对象，会在构造器调用init方法，这个方法会把线程加入到一个group里，而从group里删除实在exit方法里做的，如果只调用run，这个exit方法则不会被调用。

结论就是如果用Thread，尽量都用start()
myThread = new Thread(myRunnable);
myThread.start();

如果是Runnable，可以用run
myRunnable.run()

它们主要有如下不同：

1. 如何决定所属task
“standard”和”singleTop”的activity的目标task，和收到的Intent的发送者在同一个task内，除非intent包括参数FLAG_ACTIVITY_NEW_TASK。
如果提供了FLAG_ACTIVITY_NEW_TASK参数，会启动到别的task里。
“singleTask”和”singleInstance”总是把activity作为一个task的根元素，他们不会被启动到一个其他task里。

2. 是否允许多个实例
“standard”和”singleTop”可以被实例化多次，并且存在于不同的task中，且一个task可以包括一个activity的多个实例；
“singleTask”和”singleInstance”则限制只生成一个实例，并且是task的根元素。
singleTop要求如果创建intent的时候栈顶已经有要创建 的Activity的实例，则将intent发送给该实例，而不发送给新的实例。

3. 是否允许其它activity存在于本task内
“singleInstance”独占一个task，其它activity不能存在那个task里；如果它启动了一个新的activity，不管新的activity的launch mode 如何，新的activity都将会到别的task里运行（如同加了FLAG_ACTIVITY_NEW_TASK参数）。
而另外三种模式，则可以和其它activity共存。

4. 是否每次都生成新实例
“standard”对于没一个启动Intent都会生成一个activity的新实例；
“singleTop”的activity如果在task的栈顶的话，则不生成新的该activity的实例，直接使用栈顶的实例，否则，生成该activity的实例。
比如现在task栈元素为A-B-C-D（D在栈顶），这时候给D发一个启动intent，如果D是 “standard”的，则生成D的一个新实例，栈变为A－B－C－D－D。
如果D是singleTop的话，则不会生产D的新实例，栈状态仍为A-B-C-D
如果这时候给B发Intent的话，不管B的launchmode是”standard” 还是 “singleTop” ，都会生成B的新实例，栈状态变为A-B-C-D-B。

“singleInstance”是其所在栈的唯一activity，它会每次都被重用。

“singleTask”如果在栈顶，则接受intent，否则，该intent会被丢弃，但是该task仍会回到前台。

当已经存在的activity实例处理新的intent时候，会调用onNewIntent()方法
如果收到intent生成一个activity实例，那么用户可以通过back键回到上一个状态；如果是已经存在的一个activity来处理这个intent的话，用户不能通过按back键返回到这之前的状态。

首先先检查下你有没有犯这些错误（内存泄露的主要原因）：
生命周期过长的对象（static），尤其是集合对象（List/Map等）作为cache等使用，如果没有将某个对象主动的从中清除的话，这个集合就会占用越来越多的内存，可以用WeakReference，如WeakHashMap，使得它持有的对象不增加对象的引用数。
Scope定义不对，方法的局部变量定义成类的变量，类的静态变量等。尽量使得变量作用域别太大。
异常时没有加finally{}来释放某些资源，比如Cursor。
Listener没有显式remove；内部类持有外部对象的隐式引用，不论是什么，如果有add方法，一定要想想是否需要remove方法。
图像对象是否在不用的时候释放了（((BitmapDrawable) d).getBitmap().recycle();）

以下是正文

1. 获取hprof信息

1.1. 使用脚本get_hprof.sh

./get_hprof.sh
－－脚本内容见附录

运行此脚本之前，需要根据你的实际情况修改脚本，设置一下几个变量：
# where is you sdk
SDKPATH=.
这个是需要制定sdk/tools目录的位置，需要执行其下的adb和hprof-conv命令

# where will you want to save the log file
TARGET_LOG_DIR=./hproflog
log的保存位置

# which process will you want to generate log
# etc,mms or com.android.mms for the full process name
# we will grep the NAME field of `ps` command
# to identify the process id
PKG=mms
需要取得的进程名或者一部分，比如mms可以取得com.android.mms的进程信息

# eclipse project path to show the hprof report
ECLIPSE_PROJECT_PATH=/home/liubin/workspace_old/hprof/
取得.hprof文件会被自动拷贝到eclipse工程下，用mat进行分析
1.2. MAT的安装

eclipse 3.5的话，直接在install new software 菜单里安装：

其它版本的安装请参考eclipse的官方网站。

2. 使用MAT

如果安装成功MAT，就可以查看hprof报告了，在项目里双击生成的.hprof文件，即可查看。双击之后会弹出一个选择框，询问我们会干什么，选在第一个生成可疑报告就行了（不选也可以）：
当然，如果不想每次都显示这个窗口，可以去掉界面中唯一一个可以打勾的地方。

如果在上面的界面里选择取消，则先显示主界面如下：

Overview里面的下方，有3栏菜单，第一个柱状图用来显示各个对象的情况，DominatorTree则显示占用heap比较多的对象，类似的，Top Consumers等，看说明都能知道是干什么的。

这里只说两个方面的，一个是Reports栏的Leak Suspects,生成可以报告，和DominatorTree，查找比较占用内存的对象。

2.1. Leak Suspects

单击Overview页面的［LeakSuspects］链接，即可生产可以报告，如图所示。对于可疑的对象，会罗列出来，比如problem suspect1，problem suspect2等，并且以饼状图形显示出来。

并且，会在下面接着列出来主要的（值得怀疑的）对象：

点击了”Details”链接之后，除了在上一页看到的描述外，还有Shortest Paths To the Accumulation Point和Accumulated Objects部分，这里说明了从GC root到聚集点的最短路径，以及完整的reference chain。
每个带链接的东西都是可以点的。
接着往下看，来到了Accumulated Objects by Class区域，顾名思义，这里能找到被聚集的对象实例的类名

2.2. Dominator tree 视图
打开这个视图，会看到顶层的对象及占用heap的大小和百分比。单击对象前的三角形，可以查看对象间的（持有）关系。（注意，不一定是引用关系）
按百分比或者Retained Heap倒序排序，即可发现有问题的对象
shallow heap 是一个对象消耗掉的内存
retained heap 是这个对象如果被回收的话，总共会释放多少内存
比如对象a保有b和c两个对象，如果a被回收，则b和c的内存也会连带被回收。

注意：ClassName栏的第一行可以输入filter，比如mms等，
其它界面也可以进行对结果的过滤。

展开某一对象（如上图的第一条），即可查看其持有heap详细：
注意，某一对象的Retained Heap等数值是其子子节点的和，孙子不能重复计算。

想知道是谁引用了占有大量heap空间的对象而导致其不能被释放的原因，可以在选中的对象上点击右键，选择“Path to GC Roots”-> “exclude weak/ soft references”，即可显示引用关系，见下图所示。从图中，可以看到，问题应该出现在mListeners这个变量上了。

附录1
推荐几个网址：

http://www.eclipse.org/mat/

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/7680

http://blog.csdn.net/xtyyumi301/archive/2008/10/04/3015493.aspx