有人定位过android 覆盖布局的内存覆盖问题吗?

有人定位过Android的内存覆盖问题吗?_百度知道
有人定位过Android的内存覆盖问题吗?
这时要先确定是哪个模块出现问题,大致定位问题所在就个人查疑难BUG的经验来看,第二步就对比前后代码,第一步先确定这个问题的版本。确定版本后,不要想从网络上找到答案。以上查找过程请使用二分。如第一版本就出现问题,因为定位疑难问题是要从详细的上下文才能初步判断哪个模块出问题,然后逐步细分,缩小范围,这里简单说下定位这种问题的一般方法。
如果是某个版本才出现的问题
安卓教程|PHP教程|HTML5教程
主营:程序员培训专注php、Android、UI设计、云计算、iOS、HTML5培训
其他类似问题
为您推荐:
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁& & 接着《》继续分析。
5. AsyncTask对象
& & 我N年前去盛大面过一次试,当时面试官极力推荐我使用AsyncTask等系统自带类去做事情,当然无可厚非。
& & 但是AsyncTask确实需要额外注意一下。它的泄露原理和前面Handler,Thread泄露的原理差不多,它的生命周期和Activity不一定一致。
& & 解决方案是:在activity退出的时候,终止AsyncTask中的后台任务。
& & 但是,问题是如何终止?
& & AsyncTask提供了对应的API:public final boolean cancel (boolean mayInterruptIfRunning)。
& & 它的说明有这么一句话:
// Attempts to cancel execution of this task. This attempt will fail if the task has already completed, already been cancelled, or could not be cancelled for some other reason.
// If successful, and this task has not started when cancel is called, this task should never run. If the task has already started, then the mayInterruptIfRunning parameter determines whether the thread executing this task should be interrupted in an attempt to stop the task.
& & cancel是不一定成功的,如果正在运行,它可能会中断后台任务。怎么感觉这话说的这么不靠谱呢?
& & 是的,就是不靠谱。
& & 那么,怎么才能靠谱点呢?我们看看官方的示例:
private class DownloadFilesTask extends AsyncTask&URL, Integer, Long& {
protected Long doInBackground(URL... urls) {
int count = urls.
long totalSize = 0;
for (int i = 0; i & i++) {
totalSize += Downloader.downloadFile(urls[i]);
publishProgress((int) ((i / (float) count) * 100));
// Escape early if cancel() is called
// 注意下面这行,如果检测到cancel,则及时退出
if (isCancelled())
return totalS
protected void onProgressUpdate(Integer... progress) {
setProgressPercent(progress[0]);
protected void onPostExecute(Long result) {
showDialog("Downloaded " + result + " bytes");
  官方的例子是很好的,在后台循环中时刻监听cancel状态,防止没有及时退出。
& & & 为了提醒大家,google特意在AsyncTask的说明中撂下了一大段英文:
// AsyncTask is designed to be a helper class around Thread and Handler and does not constitute a generic threading framework. AsyncTasks should ideally be used for short operations (a few seconds at the most.) If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent pacakge such as Executor, ThreadPoolExecutor and FutureTask.
& & 可怜我神州大陆幅员辽阔,地大物博,什么都不缺,就是缺对英语阅读的敏感。
& &&AsyncTask适用于短耗时操作,最多几秒钟。如果你想长时间耗时操作,请使用其他java.util.concurrent包下的API,比如Executor, ThreadPoolExecutor 和 FutureTask.
& & 学好英语,避免踩坑!
6. BroadcastReceiver对象
& & ...&has leaked IntentReceiver ...&Are you missing a call to unregisterReceiver()?
& & 这个直接说了,种种原因没有调用到unregister()方法。
& & 解决方法很简单,就是确保调用到unregister()方法。
& & 顺带说一下,我在工作中碰到一种相反的情况,receiver对象没有registerReceiver()成功(没有调用到),于是unregister的时候提示出错:
// java.lang.IllegalArgumentException: Receiver not registered ...
& & 有两种解决方案:
& & 方案一:在registerReceiver()后设置一个FLAG,根据FLAG判断是否unregister()。网上搜到的文章几乎都这么写,我以前碰到这种bug,也是一直都这么解。但是不可否认,这种代码看上去确实有点丑陋。
& & 方案二:我后来无意中听到某大牛提醒,在Android源码中看到一种更通用的写法:
// just sample, 可以写入工具类
// 第一眼我看到这段代码,靠,太粗暴了,但是回头一想,要的就是这么简单粗暴,不要把一些简单的东西搞的那么复杂。
private void unregisterReceiverSafe(BroadcastReceiver receiver) {
getContext().unregisterReceiver(receiver);
} catch (IllegalArgumentException e) {
7. TimerTask对象
& & TimerTask对象在和Timer的schedule()方法配合使用的时候极容易造成内存泄露。
private void startTimer(){
if (mTimer == null) {
mTimer = new Timer();
if (mTimerTask == null) {
mTimerTask = new TimerTask() {
public void run() {
if(mTimer != null && mTimerTask != null )
mTimer.schedule(mTimerTask, );
  泄露的点是,忘记cancel掉Timer和TimerTask实例。cancel的时机同cursor篇说的,在合适的时候cancel。
private void cancelTimer(){
if (mTimer != null) {
mTimer.cancel();
if (mTimerTask != null) {
mTimerTask.cancel();
mTimerTask =
8.&Observer对象。
& & Observer对象的泄露,也是一种常见、易发现、易解决的泄露类型。
& & 先看一段正常的代码:
// 其实也非常简单,只不过ContentObserver是系统的例子,有必要单独拿出来提示一下大家,不可掉以轻心
private final ContentObserver mSettingsObserver = new ContentObserver(new Handler()) {
public void onChange(boolean selfChange, Uri uri) {
public void onStart() {
super.onStart();
// register the observer
getContentResolver().registerContentObserver(Settings.Global.getUriFor(
xxx), false, mSettingsObserver);
public void onStop() {
super.onStop();
// unregister it when stoping
getContentResolver().unregisterContentObserver(mSettingsObserver);
  看完示例,我们来看看病例:
private final class SettingsObserver implements Observer {
public void update(Observable o, Object arg) {
// todo ...
mContentQueryMap = new ContentQueryMap(mCursor, Settings.System.XXX, true, null);
mContentQueryMap.addObserver(new SettingsObserver());
& & 靠,谁这么偷懒,把SettingObserver搞个匿名对象传进去,这可如何是好?
& & 所以,有些懒是不能偷的,有些语法糖是不能吃的。
& & 解决方案就是,&在不需要或退出的时候delete这个Observer。
private Observer mSettingsO
public void onResume() {
super.onResume();
if (mSettingsObserver == null) {
mSettingsObserver = new SettingsObserver();
mContentQueryMap.addObserver(mSettingsObserver);
public void onStop() {
super.onStop();
if (mSettingsObserver != null) {
mContentQueryMap.deleteObserver(mSettingsObserver);
mContentQueryMap.close();
  注意一点,不同的注册方法,不同的反注册方法。
// 只是参考,不必死板
addCallback
removeCallback
registerReceiver
unregisterReceiver
addObserver
deleteObserver
registerContentObserver &==&
unregisterContentObserver
9. Dialog对象
& & android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@438afa60 is your activity running?
& & 一般发生于Handler的MESSAGE在排队,Activity已退出,然后Handler才开始处理Dialog相关事情。
& & 关键点就是,怎么判断Activity是退出了,有人说,在onDestroy中设置一个FLAG。我很遗憾的告诉你,这个错误很有可能还会出来。
& & 解决方案是:使用isFinishing()判断Activity是否退出。
Handler handler = new Handler() {
public void handleMessage(Message msg) {
switch (msg.what) {
case MESSAGE_1:
// isFinishing == true, 则不处理,尽快结束
if (!isFinishing()) {
// removeDialog()
// showDialog()
super.handleMessage(msg);
  早完早释放!
10. 其它对象
& & 以Listener对象为主,"把自己搭进去了,切记一定要及时把自己放出来"。
& & &结合本文Context篇和前面Cursor篇,我们枚举了大量的泄露实例,大部分根本原因都是相似的。
& & &通过分析这些例子后,我们应该能理解APP层90%的内存泄露情况了。
& & &至于怎么发现和定位内存泄露,这是另外一个有意思的话题,现在只能说,有方法有工具。
阅读(...) 评论()

我要回帖

更多关于 android view 覆盖 的文章

 

随机推荐