【 不用静态变量存储数据 】
1、静态变量等数据由于进程已经被杀死而被初始化。
2、使用其他暑假传输方式：文件 / sp / contentProvider。
【 有关sp的安全问题 】
不能跨进程同步；存储SP的文件过大问题；
尽量不要去做跨进程的东西，这非常会影响数据的安全问题。
【 Context的种类及注意事项 】
Application:Android应用中默认单例类，在Activity或Service中通过getApplication()可以获取到这个单例，通过context.getApplicationContext()可以获取到应用全局唯一的Context实例。
Activity/Service：都是ContextWrapper的子类，在这两个类中可以通过getBaseContext()获取到它们的Context实例，不同的Activity或Service实例，它们的Context都是独立的，不会复用。
BroadcastReceiver：本身不是Context的子类，而是在回掉函数onReceive()中由Android框架传入一个Context的实例。系统传入的这个Context实例是经过功能裁剪的，它不能调用registerReceiver()以及bindService()这两个函数。
ContentProvider：也不是Context的子类，但在创建时系统会传入一个Context实例，这样在CP中可以通过调用getContext()函数获取，如果CP和调用者处于相同的应用进程中，那么getContext()将返回应用全局唯一的Context实例。如果是其他进程调用的CP，那么CP将持有自身所在的进程的Context实例。
getApplicationContext()：Application的Context, 生命周期贯穿整个App。 getContext() / this：组件的Context，与组件生命周期同步。 getBaseContext()：(Google Android 工程师Dianne Hackborn 不建议使用，具体原因没详述)。
【 使用建议 】
数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。
数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）。
【 注意Context引用的持有，防止内存泄漏 】
建议一：不要长时间持有 组件的Context，(持有的情况可能有 workThread, static 变量，non-static inner Class)。
建议二：对于不受控的非静态内部类，建议修改成静态内部类，同时采用弱引用的方式 引用 Activity/Service 的Context。
建议三：其他可以使用Application Context 的地方，就用Application Context。
【 java四种引用方式 】
