性能优化处理

性能优化处理

---

图片的性能优化

• 一个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 可以很方便的找到
   当前的应用的包下存在哪些对象，对象的个数。