性能优化处理
图片的性能优化
- 一个activity 空置时 只需要3M的空间(当然这里是包括Application所占用的空间的)
例子：本地添加一个比较大的图，900K ，在登录显示的时候 直接加载这张图(加载的方式 是直接获取本地的drawable 和 bitmap)，看内存消耗，80M。
直接加载drawable 消耗内存21M
-
直接加载bitmap(编码格式是ARGB8888 一个像素点占4个字节) 消耗内存21m(大图显示不全 有白边)
针对图片的做处理
-
针对Bitmap做编码格式的处理(ARGB565 一个像素点占2个字节) 消耗内存5M (效果和 ARGB8888差不多，且没有白边)针对当前情况 把图片放置在不同的drawable的密度下，看看加载的情况（加载时内存消耗一致 但是和 将图片放置在drawable中不一致 在drawable中会变大）
1)drawable-hdpi下 5.26M
1)drawable-xhdpi下 5.26M
1)drawable-xxhdpi下 5.26M
不同分辨率下的图片加载 耗费内存：
1)增加分辨率之后 耗费内存是 8.02M针对图片处理，建议1.在不太要求精度的情况下 ，尽量使用AGB565处理 2.图片进行分类，放置在drawable-hdpi drawable-xhdpi下 drawable-xxhdpi下
2 内存使用的优化
1)几个Context的认识:(上下文，就是能够获取到系统资源的类)
a)结构如下；
-Object
-Context
-MockContext
-ContextWrapper
-TintContextWrapper
-IsolatedContext
-MutableContextWrapper
-ContextThemeWrapper
-Activity -----------------------
-Service -----------------------
-Application-----------------------
-BackupAgent
上边的几个Context是经常使用到的Activity Service Application
b)生命周期：
Application 是在一个在app启动时就创建的context实例，并且application会一直存在，直到用户将其杀死。
Activity 正常情况下，一个activity的生命周期是随着启动时创建，在不再使用，应该退出activity栈时，就会被销毁
Service 正常情况下 service在启动时创建，在停止时终止。(service 和ntentService 的生命周期 有区别，service是可以自己stopSelf 也可以通过Intent停止服务，
但是IntentService是跟绑定的宿主生命周期关联，会随着宿主的生命周期的结束而结束自己的生命周期)
c)获取
在Activity中，直接使用Activity.this,getBaseContext(){因为Activity都是ContextWrapper的基类，所以这里的getBaseContext都是获取基类中的mBase参数},
看老罗的博客中 得到这样的一个结果：activity是一个context，activity的父类是ContextWrapperTheme,而ContextWrapperTheme的父类是ContextWrapper,ContextWrapper的父类是Context.
在ContextWrapper 中有一个方法也是获取Context的，叫getBaseContext() 返回的是类变量mBase,这个Context是在Activity创建是 系统创建的，与Activity是两个不同的Context。
通过分配的内存地址可以看出，两个不一样。
Activity的创建 不是通过new一个对象这么简单的创建，看代码是
public class Instrumentation {
......
public Activity newActivity(ClassLoader cl, String className,
Intent intent)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
return (Activity)cl.loadClass(className).newInstance();
}
......
} 是通过class.newInstance()来创建的。Activity是一个复杂的类，包含了很多东西。是在ActivityThread 中创建的，创建过程可以看看源码：
public final class ActivityThread {
......
Instrumentation mInstrumentation;
......
private final Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
......
ComponentName component = r.intent.getComponent();
......
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
......
} catch (Exception e) {
......
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
......
if (activity != null) {
ContextImpl appContext = new ContextImpl();
......
appContext.setOuterContext(activity);
......
Configuration config = new Configuration(mConfiguration);
......
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstance,
r.lastNonConfigurationChildInstances, config);
......
mInstrumentation.callActivityOnCreate(activity, r.state);
......
}
......
} catch (SuperNotCalledException e) {
......
} catch (Exception e) {
......
}
return activity;
}
} 这里创建了很多的东西，咱们的Context 和 getBasseContext 之所以不同，在这里就有体现。
同时这里还创建了一个Application 这样一个ApplicationContext，这样ApplicationContext 和 之前
所说的两个Activity 及getBaseContext分别是不一样的。
d)在Service中 获取的Context 和getBaseContext 也是不同的地址，所以不是指的同一个变量。在Activity中启动Service之后，
分别对Activity和Service获取Context 及 getBaseContext来比较，是个Context的地址都不一样。
启动Service的源码没有找到，但是看Service中存在的各变量和Activity中存在的各变量是类似，没有找到启动Service中 比较深层次的源码，
所以这里不能给出确切的认定，service和Activity启动一样(只不过Activity中有Window可以承载UI，但是Service就不能)。
e)因为存在Context的生命周期的说法，所以这里要说的是创建某个对象时 如果这个对象是全局的，就应该要使用全局的Context，如果对象是局部的
那么就应该要用局部的Context.
内存泄漏的实例是： 推送的manager 及统计的manager 在创建的时候 是在引导页。而传入的Context直接就是引导页的this.导致
推送的manager 统计的manager 因为是静态单例，所以就一直持有引导页的context，不被释放。导致内存泄漏。
查看工具：
AS中存在这样一个Dump java heap的工具，这个工具能抓取手机中正在运行的 所有应用的在内存中15秒的分配情况。通过class package 可以很方便的找到
当前的应用的包下存在哪些对象，对象的个数。