Application具体解释 _Application

犀渠玉剑良家子，白马金羁侠少年。这篇文章主要讲述Application具体解释相关的知识，希望能为你提供帮助。
1:Application是什么？
Application和Activity,Service一样,是android框架的一个系统组件。当android程序启动时系统会创建一个 application对象。用来存储系统的一些信息。
通常我们是不须要指定一个Application的，这时系统会自己主动帮我们创建，假设须要创建自己的Application，也非常easy创建一个类继承 Application并在manifest的application标签中进行注冊(仅仅须要给Application标签添加个name属性把自己的 Application的名字定入就可以)。

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

2:通过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中取出这个对象了。
仅仅要再向下转个型。就实现了对象的传递。

3:Application数据缓存
【Application具体解释】我通常会习惯在application中建立两个HashMap一个用于数据的传递，一个用于缓存一些数据。比方有一个Activity须要从站点获取一些数据，获取完之后我们就能够把这个数据cache到Application 其中。当页面设置到其他Activity再回来的时候，就能够直接使用缓存好的数据了。但假设须要cache一些大量的数据。最好是cache一些 (软引用)SoftReference ，并把这些数据cache到本地rom上或者sd卡上。假设在application中的缓存不存在。从本地缓存查找，假设本地缓存的数据也不存在再从网络上获取。

4：PitFalls(汉语：易犯的错误)
使用Application假设保存了一些不该保存的对象非常easy导致内存泄漏。假设在Application的oncreate中执行比較耗时的操作，将直接影响的程序的启动时间。
不些清理工作不能依靠onTerminate完毕。由于android会尽量让你的程序一直执行，所以非常有可能 onTerminate不会被调用。

5：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到本地文件。
以免内存使用量超标。

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

6：生命周期：
onCreate 在创建应用程序时创建

onTerminate 当终止应用程序对象时调用，不保证一定被调用，当程序是被内核终止以便为其它应用程序释放资源，那
么将不会提醒，而且不调用应用程序的对象的onTerminate方法而直接终止进程

onLowMemory 当后台程序已经终止资源还匮乏时会调用这种方法。好的应用程序通常会在这种方法里面释放一些不必
要的资源来应付当后台程序已经终止。前台应用程序内存还不够时的情况。

onConfigurationChanged 配置改变时触发这种方法
备注:application 被杀死的情况分析：
为了决定在内存较低的时候杀掉哪个进程, Android会依据执行在这些进程内的组件及他们的状态把进程划分成一个”重要程度层次”. 其重要的程度按下面规则排序:

1：前端进程能够是一个持有执行在屏幕最前端并与用户交互的Activity的进程(onResume方法被调用时)，也能够是持有一个正在执行的IntentReceiver(也就是说他正在执行自己的onReceiveIntent方法)的进程. 在系统中, 仅仅会有少数这种进程, 而且除非内存已经低到不够这些进程执行, 否则系统不会主动杀掉这些进程. 这时, 设备通常已经达到了须要内存整理的状态, 所以杀掉这些进程是为了不让用户界面停止响应.

2：可视进程是持有一个被用户可见, 但没有显示在最前端 (onPause方法被调用时) 的Activity的进程. 举例来说, 这样的进程通常出如今一个前端Activity以一个对话框出现并保持前一个Activity可见时. 这样的进程被系统觉得是极其重要的, 而且通常不会被杀掉, 除非为了保持全部前端进程正常执行不得不杀掉这些可见进程.
3：服务进程是持有一个Service的进程, 该Service是由startService()方法启动的, 虽然这些进程用户不能直接看到, 可是通常他们做的工作用户是十分关注的(比如, 在后台播放mp3或是在后台下载上传文件), 所以, 除非为了保持全部的前端进程和可视进程正常执行外, 系统是不会杀掉服务进程的.

4：后台进程是持有一个不再被用户可见的Activity(onStop()方法被调用时)的进程. 这些进程不会直接影响用户体验. 增加这些进程已经完整的,正确的完毕了自己的生命周期(訪问Activity查看很多其它细节), 系统会在为前三种进程释放内存时随时杀掉这些后台进程. 一般会有非常多的后台进程在执行, 所以这些进程被存放在一个LRU列表中, 以保证在低内存的时候, 近期一个被用户看到的进程会被最后杀掉.

5：空进程是没有持有不论什么活动应用组件的进程. 保留这样的进程的唯一理由是为了提供一种缓存机制, 缩短他的应用下次执行时的启动时间. 就其本身而言, 系统杀掉这些进程的目的是为了在这些空进程和底层的核心缓存之间平衡整个系统的资源.

当须要给一个进程分类的时候, 系统会在该进程中处于活动状态的全部组件里掉选一个重要等级最高作为分类根据. 查看Activity, Service,和IntentReceiver的文档, 了解每个组件在进程整个生命周期中的贡献. 每个classes的文档具体描写叙述他们在各自应用的生命周期中所起得作用.

7：application 的context
1、它描写叙述的是一个应用程序环境的信息，即上下文。
2、该类是一个抽象(abstract class)类。Android提供了该抽象类的详细实现类(后面我们会讲到是ContextIml类)。
3、通过它我们能够获取应用程序的资源和类，也包含一些应用级别操作，比如：启动一个Activity，发送广播，接受Intent
信息等。
。

使用方法具体解释：
MyApp.java

package com.android.test;
import android.app.Application;
public class MyApp extends Application{
private String mylabel ;
public String getLabel(){
return mylabel;
}
public void setLabel(String s){
this.mylabel = s;
}
@Override
public void onCreate() {
// TODO Auto-generated method stub
super.onCreate();
setLabel(" Welcome!" ); //初始化全局变量
}
}

复制代码
MainActivity.java

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
public class MainActivity extends Activity {
private MyApp myApp;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
myApp = (MyApp) getApplication(); //获得自己定义的应用程序MyApp
Log.i(" guoll" , " InitLabel:" + myApp.getLabel()); //将我们放到进程中的全局变量拿出来，看是不是我们以前设置的值
myApp.setLabel(" Changing!" ); //改动一下
Log.i(" guoll" , " ChangeLabel:" + myApp.getLabel()); //看下，这个值改变了没有
Intent intent = new Intent(); //再看一下在还有一个Activity中是取到初始化的值，还是取到改动后的值
intent.setClass(this, otherActivity.class);
startActivity(intent);
}
}

复制代码
OtherActivity.java:

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
public class OtherActivity extends Activity{
private MyApp myApp;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
myApp = (MyApp) getApplication(); //获得自己定义的应用程序MyApp
Log.i(" guoll" , " OhterActivity receive the Label:" + myApp.getLabel()); //查看变量值是否改动了
}
}