五十五、application用法

一、关于application

Android使用Google Dalvik VM，相对于传统Java VM而言有着很大的不同。每个Android程序都包含着一个Application实例且仅一个，也就是说Application可以说是单例 (singleton)模式的一个类，且application对象的生命周期是整个程序中最长的，它的生命周期就等于这个程序的生命周期。因为它是全局的 、单例的，所以在不同的Activity,Service中获得的对象都是同一个对象。所以通过Application来进行一些，数据传递，数据共享等数据缓存等操作。一个Application实例中有多个Activity、 Service、ContentProvider或Broadcast Receiver。因为大部分的应用都包含Activity，所以说很多网友认为 是Activity的onCreate，但是你没有发现你的工程中有多个Activity或者没有Activity吗？

其实在android.app.Application这个包的onCreate（）方法才是真正的Android入口点，只不过一般情况下无需重写该类，他的继承关系如下图:

java.lang.Object
? android.content.Context
? android.content.ContextWrapper
? android.app.Application

android.app.Application类包含了4个公开的方法

void  onConfigurationChanged(Configuration newConfig)
void  onCreate()  //这里才是真正的入口点。
void  onLowMemory()
void  onTerminate()

所以希望大家，记住真正的Android入口点是application的main，你可以看下androidmanifest.xml的包含关系就清楚了，并不是每个应用都有Activity的。

二、使用步骤

step1：写一个全局的单例模式的MyApplication继承自Application 覆盖onCreate ，在这个方法里面实例化Application

step2：配置全局的Context，在配置文件中

 <application android:name="com.appstore.service.MyApplication" ></application>

step3：使用的时候用的时候根据类的名称访问Context

三、application定义全局变量

打开manifest文件，会看到有一个application配置标签，这就是有关application的使用了。那究竟application有什么用处呢?来看看SDK中是如何描述的：

Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's < application> tag, which will cause that class to be instantiated for you when the process for your application/package is created.

就是说application是用来保存全局变量的，并且是在package创建的时候就跟着存在了。所以当我们需要创建全局变量的时候，不需要再 像 j2se那样需要创建public权限的static变量，而直接在application中去实现。只需要调用Context 的 getApplicationContext或者Activity的getApplication方法来获得一个application对象，再做出相应的处理。

四、application进行数据传递

        假如有一个Activity A, 跳转到 Activity B ,并需要推荐一些数据，通常的作法是Intent.putExtra() 让Intent携带，或者有一个Bundle把信息加入Bundle让Intent推荐Bundle对象，实现传递。但这样作有一个问题在 于，Intent和Bundle所能携带的数据类型都是一些基本的数据类型，如果想实现复杂的数据传递就比较麻烦了，通常需要实现 Serializable或者Parcellable接口。这其实是Android的一种IPC数据传递的方法。如果我们的两个Activity在同一个 进程当中为什么还要这么麻烦呢，只要把需要传递的对象的引用传递过去就可以了。
       基本思路是这样的。在Application中创建一个HashMap ，以字符串为索引，Object为value这样我们的HashMap就可以存储任何类型的对象了。在Activity A中把需要传递的对象放入这个HashMap，然后通过Intent或者其它途经再把这人索引的字符串传递给Activity B ,Activity B 就可以根据这个字符串在HashMap中取出这个对象了。只要再向下转个型 ，就实现了对象的传递。

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

五、application进行数据的缓存

比如有一个Activity需要从网站获取一些数据，获取完之后我们就可以把这个数据cache到Application 当中，当页面跳转到其它Activity再回来的时候，就可以直接使用缓存好的数据了。但如果需要cache大量的数据，则最好是cache一些软引用（SoftReference） ，并把这些数据cache到本地rom上或者sd卡上。如果在application中的缓存不存在，从本地缓存查找，如果本地缓存的数据也不存在再从网 络上获取。

 

六、导致内存泄漏的一些原因

 

 

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

下面看张图 (Google IO 2011 ppt中抄得)

 

 

导致内存泄露的一些原因如下：

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的作用域。