What
is Application
Application和Activity,Service一样是android框架的一个系统组件，当android程序启动时系统会创建一个 application对象。用来存储系统的一些信息。通常我们是不须要指定一个Application的，这时系统会自己主动帮我们创建，假设须要创建自己 的Application，也非常easy创建一个类继承 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假设保存了一些不该保存的对象非常easy导致内存泄漏。假设在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掉。以免发生内存的泄漏。
事实上我们开发的每一个android应用程序就是一个Appliction，定义这个类往往是在AndroidManifes.xml中用到。
比如：
<application android:icon="@drawable/icon"
|
android:label="@string/app_name"
|
android:name=".MyApplication">
|
public class MyApplication extends Application
|
}
|
MyApplication类的作用是为了放要使用的类变量和一些全局和一些上下文的方法。
版权声明：本文博客原创文章。博客，未经同意，不得转载。