一文高端Android性能优化-总结篇
以下从几个方面来总结一下Android的性能优化：
1：界面卡顿优化
2：内存优化
3：App启动优化
界面卡顿优化
Android的界面为每秒60帧，即必须在16ms内完成1帧的绘制，如果某个方法耗时过程，导致16ms内无法完成绘制，会导致丢帧，丢帧的多了，直观上感受就是界面卡顿。
60帧是人眼观看动画比较合适的频率，如果每秒的帧数过少，即频繁的出现丢帧，就会感觉界面的卡顿。
1：通过Traceview找出卡主主线程的地方
卡住主线程说明函数在主线程被调用的时长比较长，包括：
1）单个函数调用的时长长
2）函数被调用的次数比较多
2：使用方法：
1）Terminal打开DDMS，输入指令：Monitor
2）点击start method profiling
3）操作APP可能有问题的界面
4）再次点击stop method profiling，生成表格：
3：具体案例分析：recyclerView的onBindViewHolder，当复用屏幕外的数据是，是脏数据，会进行重新绑定，调用onBindViewHolder
@Override
publicvoid onBindViewHolder(RecyclerView.ViewHolder holder, int position)
{
Log.d(TAG, "onBindViewHolder--->" + position);
。。。。。。
。。。。。。。
SystemClock.sleep(7);
}
SystemClock.sleep(10)模拟RecyclerView滚动过程中的耗时操作，操作Recyclerview，得到以下表格：
Real Time/Call表示一个函数被调用的时长, Calls+Recursion + call totals表示一个函数被调用和被递归调用的次数
内存优化：
1：Memory Monitor：
Memory Monitor只能看个大概，可以查看内存抖动，或者内存增长的趋势，具体的小的泄漏，还得通过Heap Viewer查看
内存抖动：短时间内发生了多次内存的涨跌，意味着很有可能发生率内存抖动。
内存抖动带来的问题：短时间内的内存飙升，系统需要频繁的进行GC，而GC是需要主线程停下来，并且占用CPU资源的，会导致界面卡顿。
例子1：
publicvoid click(View view) {
for (int i = 0; i < 100; i++) {
byte[] b = newbyte[2000];
}
}
例子2：
privateint nums[][] = newint[250][250];
//内存抖动案例：
//短时间内创建大量的临时变量privatevoid init() {
Random random = new Random();
for (int i = 0; i < nums.length; i++) {
for(int j=0; j
nums[i][j] = random.nextInt(1000);
}
}
}
privatevoid printNums(){
String totalNums = "";
for (int i = 0; i < nums.length; i++) {
for(int j=0; j//优化：
private void printNums2(){
StringBuffer totalNums = new StringBuffer();
for (int i = 0; i < nums.length; i++) {
for(int j=0; j使用Monitor监控：
避免内存抖动的方法：
1）尽量避免在循环体内创建对象，应该把对象创建移到循环体外
2）自定义view的onDraw会被频繁调用，避免在这个函数里面new一个新的对象
2：Heap Viewer：
监控：能够实时观测内存的变动（短时间内通过Memory Monitor是看不出来的，曲线坡度太小，内存变动值很小,定位不到具体的代码）
Heap Viewer具体定位到哪个位置内存泄漏。
内存泄漏例子：
protectedvoid onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//test1(); init();
handler.sendEmptyMessageDelayed(0, 100000);
}
//模拟当MainActivity跳转到MainActivity2的时候，
// 延迟发送消息导致的内存泄漏问题private Handler handler = new Handler(){
@Override
publicvoid handleMessage(@NonNull Message msg) {
super.handleMessage(msg);
}
};
publicvoid click(){
Intent intent = new Intent(this, MainActivity2.class);
startActivity(intent);
finish();
}
首先运行应用，处在MainActivity，点击Dump Java Heap,获取当前内存的快照：
得到以下表格：
修改为根据包名查看更方便快速定位到我们自己的代码:
Leaks为0说明当前没有发生内存泄漏
MainActivity的depth为3，说明MainActivity有被引用
点击MainActivity的click，跳转到MainActivity2，MainActivity.finish(),模拟MainActivty发生内存泄漏的场景（Handler引用MainActivity导致内存泄漏），然后点击GC，再截取内存快照
Dump Java Heap：
黄色的Leaks为2说明发生了内存泄漏，点击Leaks,通过以下References可以找到MainActivity被引用的路径。
3：LeakCanary
在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存
在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存
在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存
在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存
分为两个步骤：
1）通过虚引用的ReferenceQueue,判断一个对象是否被回收：
虚引用：对于对象来说，是无感的，如果只存在虚引用，GC的时候会直接被回收。虚引用的目的是为了追踪一个对象被回收的时机。如果一个定义了虚引用的对象GC之后被回收了，这个对象会被放入RefereceQueue中，LeakCanary就是在GC之后去检测该队列中是否有该对象判断该对象是否已经被回收。
2）初步判定有内存泄漏之后，通过开源库Haha分析dump之后的heap内存，从而定位到具体的内存泄露的对象的引用链条。
APP应用启动优化
1：冷启动和热启动
1）冷启动：app没有启动过或者进程被杀死，系统不存在该app进程，此时启动为冷启动。冷启动流程就是app启动流程全过程，包括创建app进程、加载资源、启动MainThread、初始化SplashActivity并加载布局等。
2）热启动：app暂时退到了后台，热启动将它从后台重新带到前台，展示给客户。
我们要做的优化就是针对热启动
3）：冷启动的函数调用过程：
Zygote Fork Proccess
-> Application:attachBaseContext()
-> Application:onCreate()
-> MainActiviity:onCreate()
2：用TraceView获取App的启动耗时，查找具体的耗时的函数进行优化：
publicclass MyApplication extends Application {
@Override
publicvoid onCreate() {
Debug.startMethodTracing("startApp");
super.onCreate();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Debug.stopMethodTracing();
}
}
在/sdcard/目录下得到一个startApp.trace文件
通过DDMS打开该文件：可以看到Application里面的onCreate里的哪些代码进行了耗时操作：
3：解决方案：
1）将启动页主题背景设置成闪屏页图片
这么做的目的主要是为了消除启动时的黑白屏，给用户一种秒响应的感觉，但是并不会真正减少用户启动时间，仅属于视觉优化。
2）第三方工具的初始化一般都在Application的onCreate里面执行，会造成大量的耗时，解决方案：
a:放在子线程中加载不影响业务的情况，则优先选择放在子线程中加载
b:第三方工具的懒加载初始化，即用到的时候再进行初始化