android_基础_Application对象的使用-数据传递以及内存泄漏问题

最新推荐文章于 2024-05-08 18:54:16 发布

写bug的蚊子

最新推荐文章于 2024-05-08 18:54:16 发布

阅读量534

点赞数

分类专栏： android 基础文章标签： android

原文链接：https://www.cnblogs.com/bill-joy/archive/2012/04/11/2442574.html

版权

android 同时被 2 个专栏收录

142 篇文章 6 订阅

订阅专栏

基础

121 篇文章 1 订阅

订阅专栏

转载于:https://www.cnblogs.com/bill-joy/archive/2012/04/11/2442574.html

Application的使用

What is Application

Application和Actovotu,Service一样是android框架的一个系统组件，当android程序启动时系统会创建一个 application对象，用来存储系统的一些信息。通常我们是不需要指定一个Application的，这时系统会自动帮我们创建，如果需要创建自己的Application，也很简单创建一个类继承 Application并在manifest的application标签中进行注册(只需要给Application标签增加个name属性把自己的 Application的名字定入即可)。

android系统会为每个程序运行时创建一个Application类的对象且仅创建一个，所以Application可以说是单例 (singleton)模式的一个类.且application对象的生命周期是整个程序中最长的，它的生命周期就等于这个程序的生命周期。因为它是全局的单例的，所以在不同的Activity,Service中获得的对象都是同一个对象。所以通过Application来进行一些，数据传递，数据共享等,数据缓存等操作。

Data passing between components using Application

假如有一个Activity A, 跳转到 Activity B ,并需要推荐一些数据，通常的作法是Intent.putExtra() 让Intent携带，或者有一个Bundle把信息加入Bundle让Intent推荐Bundle对象，实现传递。但这样作有一个问题在于，Intent和Bundle所能携带的数据类型都是一些基本的数据类型，如果想实现复杂的数据传递就比较麻烦了，通常需要实现 Serializable或者Parcellable接口。这其实是Android的一种IPC数据传递的方法。如果我们的两个Activity在同一个进程当中为什么还要这么麻烦呢，只要把需要传递的对象的引用传递过去就可以了。

基本思路是这样的。在Application中创建一个HashMap<String,Object> ，以字符串为索引，Object为value这样我们的HashMap就可以存储任何类型的对象了。在Activity A中把需要传递的对象放入这个HashMap，然后通过Intent或者其它途经再把这人索引的字符串传递给Activity B ,Activity B 就可以根据这个字符串在HashMap中取出这个对象了。只要再向下转个型，就实现了对象的传递。

Data caching in Application

我一般会习惯在application中建立两个HashMap<String,Object>一个用于数据的传递，一个用于缓存一些数据。比如有一个Activity需要从网站获取一些数据，获取完之后我们就可以把这个数据cache到Application 当中，当页面设置到其它Activity再回来的时候，就可以直接使用缓存好的数据了。但如果需要cache一些大量的数据，最好是cache一些 (软引用)SoftReference ，并把这些数据cache到本地rom上或者sd卡上。如果在application中的缓存不存在，从本地缓存查找，如果本地缓存的数据也不存在再从网络上获取。

PitFalls

使用Application如果保存了一些不该保存的对象很容易导致内存泄漏。如果在Application的oncreate中执行比较耗时的操作，将直接影响的程序的启动时间。不些清理工作不能依靠onTerminate完成，因为android会尽量让你的程序一直运行，所以很有可能 onTerminate不会被调用。

MemoryLeak

在Java中内存泄漏是只，某个(某些)对象已经不在被使用应该被gc所回收，但有一个对象持有这个对象的引用而阻止这个对象被回收。比如我们通常会这样创建一个View TextView tv = new TextView(this);这里的this通常都是Activity。所以这个TextView就持有着这个Activity的引用。下面看张图 (Google IO 2011 ppt中抄得)

通常情况下，当用户转动手机的时候，android会重新调用OnCreate()方法生成一个新的Activity，原来的 Activity应该被GC所回收。但如果有个对象比如一个View的作用域超过了这个Activity(比如有一个static对象或者我们把这个 View的引用放到了Application当中)，这时候原来的Activity将不能被GC所回收，Activity本身又持有很多对象的引用，所以整个Activity的内存被泄漏了。

经常导致内存泄漏的一些原因：

keeping a long-lived reference to a Context.持有一个context的对象，从而gc不能回收。

1，一个View，的作用域超出了所在的Activity的作用域，比如一个static的View或者把一个View cache到了application当中 etc

2,某些与View关联的Drawable的作用域超出了Activity的作用域。

3，Runnable对象：比如在一个Activity中启用了一个新线程去执行一个任务，在这期间这个Activity被系统回收了，但Runnalbe的任务还没有执行完毕并持有Activity的引用而泄漏，但这种泄漏一般来泄漏一段时间，只有Runnalbe的线程执行完闭，这个 Activity又可以被正常回收了。

4，内存类的对象作用域超出Activity的范围：比如定义了一个内存类来存储数据，又把这个内存类的对象传给了其它Activity 或者Service等。因为内部类的对象会持有当前类的引用，所以也就持有了Context的引用。解决方法是如果不需要当前的引用把内部类写成 static或者，把内部类抽取出来变成一个单独的类，或者把避免内部对象作用域超出Activity的作用域。

out Of Memery Error 在android中每一个程序所分到的内存大小是有限的，如果超过了这个数就会报Out Of Memory Error。android给程序分配的内存大小与手机硬件有关，以下是一些手机的数据：

G1:16M Droid:24 Nexus One:32M Xoom:48Ms

所以尽量把程序中的一些大的数据cache到本地文件。以免内存使用量超标。

Snippets

1,通过Application在两个Activity间传递数据

记得数据传递完成之后，把存放在application的HashMap中的数据remove掉，以免发生内存的泄漏。

范例：

MyApplication.java

package com.chonwhite.snippets.application; import java.util.HashMap; import android.app.Application; public class MyApplication extends Application { public HashMap<String,Object> dataHolder = new HashMap<String,Object>();

    @Override public void onCreate() { super.onCreate(); //! don't do any time consuming operation here;
 }
}

package com.chonwhite.snippets.application; import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; import android.widget.EditText; import android.widget.ImageView; import android.widget.RadioGroup; import android.widget.RadioGroup.OnCheckedChangeListener; import com.chonwhite.snippets.bean.UserInfo; public class SetDataActivity extends Activity {
    MyApplication mApplication; private Button submitButton; private EditText nameEdit; private EditText ageEdit; private EditText phoneEdit; private RadioGroup radioGroup; private ImageView avatarImage;

    @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
        mApplication = (MyApplication) this.getApplication();
        initUI();
    } private void initUI(){ this.setContentView(R.layout.set_data);
        nameEdit = (EditText) findViewById(R.id.nameEdit);
        ageEdit = (EditText) findViewById(R.id.ageEdit);
        phoneEdit = (EditText) findViewById(R.id.phoneEdit);
        submitButton = (Button)findViewById(R.id.submitButton);
        submitButton.setOnClickListener(new SubmitButtonListener());
        
        avatarImage =(ImageView)findViewById(R.id.avatarImage);
        radioGroup = (RadioGroup) findViewById(R.id.avatarRadioGroup);
        radioGroup.setOnCheckedChangeListener(new AvatarRadioCheckChangeListener());
    } class AvatarRadioCheckChangeListener implements OnCheckedChangeListener{
        
        @Override public void onCheckedChanged(RadioGroup group, int checkedId) { switch(checkedId){ case R.id.radioButton1:
                avatarImage.setImageResource(R.drawable.sample1); break; case R.id.radioButton2:
                avatarImage.setImageResource(R.drawable.sample2); break; case R.id.radioButton3:
                avatarImage.setImageResource(R.drawable.sample3); break;
            }
        }
    } class SubmitButtonListener implements OnClickListener{

        @Override public void onClick(View v) {
            UserInfo userInfo = new UserInfo();
            userInfo.name = nameEdit.getText().toString(); try{
                userInfo.age = Integer.parseInt(ageEdit.getText().toString());
            }catch(Exception e){
                userInfo.age = 0;
            }
            userInfo.phone = phoneEdit.getText().toString();
            userInfo.avatar = avatarImage.getDrawable(); //put the data into hashMap
            mApplication.dataHolder.put("userInfo", userInfo);
            
            Intent intent = new Intent(SetDataActivity.this,ReceiveDataActivity.class);
            intent.putExtra("dataKey", "userInfo");
            startActivity(intent);
        }
    }
}

package com.chonwhite.snippets.application; import com.chonwhite.snippets.bean.UserInfo; import android.app.Activity; import android.os.Bundle; import android.widget.ImageView; import android.widget.TextView; public class ReceiveDataActivity extends Activity {
    MyApplication mApplication;
    TextView displayText;
    ImageView avatarImage;
    @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
        mApplication = (MyApplication) this.getApplication();
        initUI();
        loadResources();
    } private void initUI(){
        setContentView(R.layout.receive_data);
        displayText = (TextView) findViewById(R.id.displayText);
        avatarImage = (ImageView) findViewById(R.id.avatarImage);
    }; private void loadResources(){
        String dataKey = this.getIntent().getStringExtra("dataKey");
        UserInfo userInfo = (UserInfo) mApplication.dataHolder.get(dataKey); //!!don't forget to remove data from application,when the data is no longer useful;
 mApplication.dataHolder.remove(dataKey); if(userInfo != null){
            String text = "";
            text += "name:" + userInfo.name + "\\n"
            \+ "age:" + userInfo.age + "\\n"
            \+ "phone:" + userInfo.phone;
            
            displayText.setText(text);
            avatarImage.setImageDrawable(userInfo.avatar);
        }else{
            displayText.setText("userInfo null!");
        }
    };

}

什么是内存泄漏？

简单点说，就是指一个对象不再使用，本应该被回收，但由于某些原因导致对象无法回收，仍然占用着内存，这就是内存泄漏。

为什么会产生内存泄漏，内存泄漏会导致什么问题？

相比C++需要手动去管理对象的创建和回收，Java有着自己的一套垃圾回收机制，它能够自动回收内存，但它往往会因为某些原因变得“不靠谱”

在Android开发中，一些不好的编码习惯就很可能会造成内存泄漏，

而这些内存泄漏会导致应用内存越占越大，使得应用变得卡顿，甚至造成OOM（Out Of Memory）内存溢出问题，同时也使应用变得极其不稳定，因为当内存不足的时候，系统会优先回收那些“内存占比”大的应用。

Java的内存分配机制

首先我们先来了解下Java的内存分配机制，Java 程序运行时的内存分配策略有三种,分别是静态分配,栈式分配,和堆式分配，对应的，三种存储策略使用的内存空间主要分别是静态存储区（也称方法区）、栈区和堆区。

静态存储区（方法区）：主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好，并且在程序整个运行期间都存在。

栈区：当方法被执行时，方法体内的局部变量（其中包括基础数据类型、对象的引用）都在栈上创建，并在方法执行结束时这些局部变量所持有的内存将会自动被释放。因为栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。

堆区：又称动态内存分配，通常就是指在程序运行时直接 new 出来的内存，也就是对象的实例。这部分内存在不使用时将会由 Java 垃圾回收器来负责回收。

常见的内存泄漏和解决方案

1、单例模式引起的内存泄漏

由于单例的静态特性导致它的生命周期和整个应用的生命周期一样长，如果有对象已经不再使用了，但又却被单例持有引用，那么就会导致这个对象就没办法被回收，从而导致内存泄漏。

// 使用了单例模式
public class AppManager {
    private static AppManager instance;
    private Context context;
    private AppManager(Context context) {
        this.context = context;
    }
    public static AppManager getInstance(Context context) {
        if (instance != null) {
            instance = new AppManager(context);
        }
        return instance;
    }
}

问题所在：
从上面的代码我们可以看出，在创建单例对象的时候，引入了一个Context上下文对象，如果我们把Activity注入进来，会导致这个Activity一直被单例对象持有引用，当这个Activity销毁的时候，对象也是没有办法被回收的。

解决方案:
在这里我们只需要让这个上下文对象指向应用的上下文即可，因为应用的上下文对象的生命周期和整个应用的一样长

// 使用了单例模式
public class AppManager {
    private static AppManager instance;
    private Context context;
    private AppManager(Context context) {
        this.context = context.getApplicationContext();  //解决方案
    }
    public static AppManager getInstance(Context context) {
        if (instance != null) {
            instance = new AppManager(context);
        }
        return instance;
    }
}

2、非静态内部类创建静态视力引起的内存泄漏

由于非静态内部类会默认持有外部类的引用，如果我们在外部类中去创建这个内部类对象，当频繁打开关闭Activity，会导致重复创建对象，造成资源的浪费，为了避免这个问题我们一般会把这个实例设置为静态，这样虽然解决了重复创建实例，但是会引发出另一个问题，就是静态成员变量它的生命周期是和应用的生命周期一样长的，然而这个静态成员变量又持有该Activity的引用，所以导致这个Activity销毁的时候，对象也是无法被回收的。

public class MainActivity extends AppCompatActivity {
 
    private static TestResource mResource = null;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        if(mResource == null){
            mResource = new TestResource();
        }
        //...
    }
   
    class TestResource {
    //...
    }
}

问题所在：其实这个和上面单例对象的内容泄漏问题是一样的，由于静态对象持有Activity的引用，导致Activity没办法被回收。

解决方案：在这里我们只需要把非静态内部类改成静态内部类即可

public class MainActivity extends AppCompatActivity {
 
    private static TestResource mResource = null;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        if(mResource == null){
            mResource = new TestResource();
        }
        //...
    }
   
    //解决方案
    static class TestResource {
    //...
    }
}

3、Handler使用引起的内存泄漏

记得我们刚学习Handler的时候，网上资料甚至学校教材“教科书”式的写法都是这样的

    Handler mHandler=new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            //to do something..
            switch (msg.what){
                case 0:
                    //to do something..
                    break;
            }    
        }
    };
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        new Thread(new Runnable() {
            @Override
            public void run() {
                //to do something..
                mHandler.sendEmptyMessage(0);
            }
        }).start();
    }

问题所在：
别看上面短短几行代码，其实涉及到了很多问题，首先我们知道程序启动时在主线程中会创建一个Looper对象，这个Looper里维护着一个MessageQueue消息队列，这个消息队列里会按时间顺序存放着Message，

然后上面的Handler是通过内部类来创建的，内部类会持有外部类的引用，也就是Handler持有Activity的引用，而消息队列中的消息target是指向Handler的，也就等同消息持有Handler的引用，也就是说当消息队列中的消息如果还没有处理完，这些未处理的消息（也可以理解成延迟操作）是持有Activity的引用的，此时如果关闭Activity，是没办法回收的，从而就会导致内存泄露。

解决方案：
和上文一样，我们需要先把非静态内部类改成静态内部类（如果是Runnable类也需要改成静态），然后在Activity的onDestroy中移除对应的消息，再来需要在Handler内部用弱引用持有Activity，因为让内部类不再持有外部类的引用时，程序也就不允许Handler操作Activity对象了。

   MyHandler myHandler = new MyHandler(this);
 
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
         new Thread(new Runnable() {
            @Override
            public void run() {
                myHandler.sendMessage(Message.obtain());
            }
        }).start();
    }
 
    @Override
    protected void onDestroy() {
        super.onDestroy();
        //移除对应的Runnable或者是Message
        //mHandler.removeCallbacks(runnable);
        //mHandler.removeMessages(what);
        mHandler.removeCallbacksAndMessages(null);
    }
 
 
    //把非静态内部类改成静态内部类
    private static class MyHandler extends Handler {
 
        private WeakReference<Activity> mActivity;
 
        public MyHandler(Activity activity) {
            mActivity = new WeakReference<Activity>(activity);
        }
 
        @Override
        public void handleMessage(Message msg) {
            if (mActivity.get() == null) {
                return;
            }
             //to do something..
 
        }
    };

4、WebView引起的内存泄漏

关于WebView的内存泄漏，这是个绝对的大大大大大坑！不同版本都存在着不同版本的问题，这里我只能给出我平时的处理方法，可能不同机型上存在的差异，只能靠积累了。
方法一：
首先不要在xml去定义，定义一个ViewGroup就行，然后动态在代码中new WebView(Context context)（传入的Context采取弱引用），再通过addView添加到ViewGroup中，最后在页面销毁执行onDestroy()的时候把WebView移除。
方法二：
简单粗暴，直接为WebView新开辟一个进程，在结束操作的时候直接System.exit(0)结束掉进程，这里需要注意进程间的通讯，可以采取Aidl，Messager，Content Provider，Broadcast等方式。

5、Asynctask引起的内存泄漏

这部分和Handler比较像，其实也是因为内部类持有外部类引用，一样的改成静态内部类，然后在onDestory方法中取消任务即可。

6、资源对象未关闭引起的内存泄漏

这块就比较简单了，比如我们经常使用的广播接收者，数据库的游标，多媒体，文档，套接字等。

7、其他

还有一些需要注意的，比如注册了EventBus没注销，添加Activity到栈中，销毁的时候没移除等。

这里提供一个可以检查内存泄露的工具LeakCanary，只需要几行代码就可以轻松在应用内集成内存监控功能了。

写bug的蚊子

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
android_基础_Application对象的使用-数据传递以及内存泄漏问题

转载于:https://www.cnblogs.com/bill-joy/archive/2012/04/11/2442574.htmlApplication的使用What is ApplicationApplication和Actovotu,Service一样是android框架的一个系统组件，当android程序启动时系统会创建一个 application对象，用来存储系统的一些信息。通常我们是不需要指定一个Application的，这时系统会自动帮我们创建，如果需要创建自己的Applica.
复制链接

扫一扫

专栏目录