1: APP是什么？ 123 Application和Activity，Service一样，都是android框架的系统组件，当android程序启动时，用于存储系统部分信息的application对象通常，不需要指定APP应用程序。 在这种情况下，系统会自动创建。 如果需要创建自己的APP应用程序，请轻松创建继承APP应用程序的类，并将其注册到manifest的APP应用程序标签中(在android系统中，每次运行程序时只创建一个APP应用程序类对象) 此外，APP应用程序对象的生命周期是整个程序中最长的，其生命周期与程序的生命周期相同。 因为这是全局的单个实例，所以在不同的活动和服务中检索的所有对象都是相同的对象。 所以通过APP进行一些数据的传递、数据的共享等数据的缓存等操作。
如果存在通过2:application传递数据的1234567activitya，则必须跳到Activity B并推荐一些数据。 通常，Intent.putExtra (是让Intent携带的，或者Bundle向Bundle添加信息并让Intent携带，但Intent和Bundle可以携带的数据类型是基本的数据类型，也是复杂的数据类型这其实是安卓的IPC数据传输的方法。 要说我们的两个Activity在同一个过程中为什么这么麻烦，你只需要传递要传递的对象的引用就可以了。 基本的想法是这样的。 在APP中创建一个以字符串为索引的HashMap，以便Object可以存储任何类型的对象，就像value一样。 如果要在Activity A中传递的对象放入此HashMap中，然后通过Intent或其他途径将此索引的字符串传递给Activity B，则Activity B可以基于此字符串从HashMap中检索此对象再向下转动模具，即可实现对象的传达。 3:应用程序数据缓存我通常习惯在应用程序中建立两个HashMap，一个用于数据传递，另一个用于缓存一些数据。 例如，一个Activity需要从网站获取一些数据。 获取后，我们可以将此数据缓存到APP中，当页面设置为其他活动并返回时，可以直接使用缓存的数据。 但是，如果cache需要大量数据，最好在cache中包含软件参考，然后将这些数据缓存到本地rom或sd卡中。 如果APP中不存在缓存，则从本地缓存中进行搜索；如果本地缓存中也不存在数据，则从网络中检索。
使用4:PitFalls (中文：容易犯的错误) APP，如果保存了不应该保存的对象，则容易导致内存泄漏。 在APP oncreate中执行耗时的操作会直接影响程序的启动时间。 有些清理工作不能依靠终端自动化。 因为android会尽可能一直运行你的程序，所以很可能不会调用onTerminate。
5 )5:内存leak在Java中的内存泄漏，一个(部分)对象已经不使用，应该被gc回收，但一个对象有对该对象的引用，并且不会回收该对象例如，我们通常这样创建viewtextviewtv=new textview (this )。 这里的this通常是活动的。 所以这个TextView有这个Activity的引用。 查看下图(用谷歌io 2011 PPT拍摄) )
通常，当用户转动手机时，android会调用OnCreate ()方法生成新的Activity，原始Activity应该会被GC回收。 但是，如果某个对象，例如View的范围超过了该活动，例如有静态对象，或者我们将该视图的引用放入应用程序中，则原始活动不会被GC回收
123备注：内存泄漏核心原因： keeping along-livedreferencetoacontext .有上下文对象，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掉，以免发生内存的泄漏
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：空进程是没有持有任何活动应用组件的进程. 保留这种进程的唯一理由是为了提供一种缓存机制, 缩短他的应用下次运行时的启动时间. 就其本身而言, 系统杀掉这些进程的目的是为了在这些空进程和底层的核心缓存之间平衡整个系统的资源. www.2cto.com
当需要给一个进程分类的时候, 系统会在该进程中处于活动状态的所有组件里掉选一个重要等级最高作为分类依据. 查看Activity, Service,和IntentReceiver的文档, 了解每个组件在进程整个生命周期中的贡献.
每一个classes的文档详细描述他们在各自应用的生命周期中所起得作用.
7：application 的context： 1、它描述的是一个应用程序环境的信息，即上下文。
2、该类是一个抽象(abstract class)类，Android提供了该抽象类的具体实现类(后面我们会讲到是ContextIml类)。
3、通过它我们可以获取应用程序的资源和类，也包括一些应用级别操作，例如：启动一个Activity，发送广播，接受Intent
信息 等。。