1.耗电场景测试:复杂运算、视频播放
2.传感器相关: 使用时长、耗电量、发热
3.后台静默测试

https://github.com/google/battery-historian
安装Docker
docker -- run -p <port>:9999 gcr.io/android-batterynistorian/stable:3.0 --port 9999

adb shell dumpsys batterystats --reset
adb shell dumpsys batterystats --enable full-wakehistory
adb bugreport bugreport.zip

1.请求时机及次数控制
2.数据压缩，减少时间
3.禁止使用轮询功能

1.根据场景谨慎选择定位模式
2.考虑网络定位代替GPS
3.使用后务必及时关闭，减少更新频率

1.离开界面后停止相关活动
2.耗电操作判断前后台

1.注意成对出现:acquire与release
2.使用带参数的acquire
3.finally确保一定会被释放

1.在符合某些条件时创建执行在后台的任务
2.把不紧急的任务放到更合适的时机批量处理

1.网络相关
2.传感器相关
3.WakeLock与JobScheduler

1.网络优化的纬度:多维
2.仅仅重视流量不够
3.网络流量的消耗量:精确
4.整体均值掩盖单点问题
5.网络相关监控:全面
6.粗粒度监控不能帮助我们发现、解决深层次问题

流量消耗
  - 一段时间流量消耗的精准度量，网络类型、前后台
  - 监控相关:用户流量消耗均值、异常率( 消耗多、次数多)
  - 完整链路全部监控(Request、Response)，主动上报
网络请求质量
  - 用户体验:请求速度、成功率
  - 监控相关: 请求时长、业务成功率、失败率、T失败接口
其它
  - 公司成本:带宽、服务器数、CDN
  - 耗电

1.com.facebook.stetho:stetho-okhttp3:1.5.0
2.Stetho.initializeWithDefaults(this):
3.addNetworkInterceptor
4.Chrome浏览器:chrome://inspect(需翻墙)

数据:Api、资源包(升级包、H5、RN)、配置信息
图片:下载、上传
监控:APM相关、单点问题相关

package com.optimize.performance.net;

import com.optimize.performance.PerformanceApp;
import com.optimize.performance.utils.Utils;
import java.io.IOException;
import okhttp3.CacheControl;
import okhttp3.Interceptor;
import okhttp3.Request;
import okhttp3.Response;

public class NoNetInterceptor implements Interceptor {
    @Override
    public Response intercept(Chain chain) throws IOException {
        Request request = chain.request();
        Request.Builder builder = request.newBuilder();
        if(!Utils.isNetworkConnected(PerformanceApp.getApplication())){
            builder.cacheControl(CacheControl.FORCE_CACHE);
        }
        return chain.proceed(builder.build());
    }
}

package com.optimize.performance.net;
import com.optimize.performance.PerformanceApp;
import okhttp3.Cache;
import okhttp3.OkHttpClient;
import okhttp3.logging.HttpLoggingInterceptor;
import retrofit2.Retrofit;
import retrofit2.converter.fastjson.FastJsonConverterFactory;
public class RetrofitNewsUtils {
    private static final APIService API_SERVICE;

    public static APIService getApiService() {
        return API_SERVICE;
    }

    public static final String HTTP_SPORTSNBA_QQ_COM = "http://sportsnba.qq.com/";

    static {
        OkHttpClient.Builder client = new OkHttpClient.Builder();
        HttpLoggingInterceptor logging = new HttpLoggingInterceptor();
        logging.setLevel(HttpLoggingInterceptor.Level.BODY);
        Cache cache = new Cache(PerformanceApp.getApplication().getCacheDir(),10*1024*1024);
        client.
                eventListenerFactory(OkHttpEventListener.FACTORY).
                dns(OkHttpDNS.getIns(PerformanceApp.getApplication())).
                addInterceptor(new NoNetInterceptor()).
                addInterceptor(logging);

        final Retrofit RETROFIT = new Retrofit.Builder()
                .baseUrl(HTTP_SPORTSNBA_QQ_COM)
                .addConverterFactory(FastJsonConverterFactory.create())
                .client(client.build())
                .build();
        API_SERVICE = RETROFIT.create(APIService.class);
    }
}

1.任意时刻，只有一个线程占用CPU，处于运行状态
2.多线程并发:轮流获取CPU使用权
3.JVM负责线程调度:按照特定机制分配CPU使用权

1.nice值
  - Process中定义
  - 值越小，优先级越高
  - 默认是THREAD_PRIORITY_DEFAULT，0
2.cgroup
  - 更严格的群组调度策略(前台/后台)
  - 保证前台线程可以获取到更多的CPU

1.线程过多会导致CPU频繁切换，降低线程运行效率
2.正确认识任务重要性决定哪种优先级(工作量越低，优先级应该越低)
3.优先级具有继承性（A线程中启动线程B，则B基础A的优先级）

最简单、常见的异步方式
  - 不易复用，频繁创建及销毁开销大
  - 复杂场景不易使用

//ThreadPoolUtils工具类
package com.optimize.performance.async;


import android.os.Process;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingDeque;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public class ThreadPoolUtils {

    private int CPUCOUNT = Runtime.getRuntime().availableProcessors();

    private ThreadPoolExecutor cpuExecutor = new ThreadPoolExecutor(CPUCOUNT, CPUCOUNT,
            30, TimeUnit.SECONDS, new LinkedBlockingDeque<Runnable>(), sThreadFactory);

    private ThreadPoolExecutor iOExecutor = new ThreadPoolExecutor(64, 64,
            30, TimeUnit.SECONDS, new LinkedBlockingDeque<Runnable>(), sThreadFactory);

    private static final ThreadFactory sThreadFactory = new ThreadFactory() {
        private final AtomicInteger mCount = new AtomicInteger(1);

        public Thread newThread(Runnable r) {
            return new Thread(r, "ThreadPoolUtils #" + mCount.getAndIncrement());
        }
    };

    public static ExecutorService getService() {
        return sService;
    }

    private static ExecutorService sService = Executors.newFixedThreadPool(5, new ThreadFactory() {
        @Override
        public Thread newThread(Runnable r) {
            Thread thread = new Thread(r, "ThreadPoolUtils");
            Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
            return thread;
        }
    });
}

//使用示例
 ThreadPoolUtils.getService().execute(new Runnable() {
            @Override
            public void run() {
                Process.setThreadPriority(Process.THREAD_PRIORITY_DEFAULT);
                String oldName = Thread.currentThread().getName();
                Thread.currentThread().setName("new Name");
                LogUtils.i("");
                Thread.currentThread().setName(oldName);
            }
        });

1.项目变大之后收敛线程
2.项目源码、三方库、aar中都有线程的创建
3.避免恶化的一种监控预防手段

1.分析
  - 创建线程的位置获取堆栈
  - 所有的异步方式，都会走到new Thread
2.特别适合Hook手段
3.找Hook点:构造函数或者特定方法
4.Thread的构造函数

DexposedBridge.hookAllConstructors(Thread.class, new XC_MethodHook() {
         @Override
         protected void afterHookedMethod(MethodHookParam param) throws Throwable {
             super.afterHookedMethod(param);
             Thread thread = (Thread) param.thisObject;
             LogUtils.i(thread.getName()+" stack "+Log.getStackTraceString(new Throwable()));
         }
     });

1.根据线程创建堆栈考量合理性，使用统一线程库
2.各业务线下掉自己的线程库

1.区分任务类型:IO、CPU密集型
2.IO密集型任务不消耗CPU，核心池可以很大
3.CPU密集型任务:核心池大小和CPU核心数相关

package com.optimize.performance.async;
import android.os.Process;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingDeque;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public class ThreadPoolUtils {

    private int CPUCOUNT = Runtime.getRuntime().availableProcessors();

    private ThreadPoolExecutor cpuExecutor = new ThreadPoolExecutor(CPUCOUNT, CPUCOUNT,
            30, TimeUnit.SECONDS, new LinkedBlockingDeque<Runnable>(), sThreadFactory);

    private ThreadPoolExecutor iOExecutor = new ThreadPoolExecutor(64, 64,
            30, TimeUnit.SECONDS, new LinkedBlockingDeque<Runnable>(), sThreadFactory);

    private static final ThreadFactory sThreadFactory = new ThreadFactory() {
        private final AtomicInteger mCount = new AtomicInteger(1);

        public Thread newThread(Runnable r) {
            return new Thread(r, "ThreadPoolUtils #" + mCount.getAndIncrement());
        }
    };

    public static ExecutorService getService() {
        return sService;
    }

    private static ExecutorService sService = Executors.newFixedThreadPool(5, new ThreadFactory() {
        @Override
        public Thread newThread(Runnable r) {
            Thread thread = new Thread(r, "ThreadPoolUtils");
            Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
            return thread;
        }
    });
}

1.项目发展阶段
2.问题原因及表现形式

1.线程收敛
2.统一线程池:任务区分
3.其他细节

1.很多性能问题不易被发现，但是卡顿很容易被直观感受
2.卡顿问题难以定位

1.图形的形式展示执行时间、调用栈等
2.信息全面，包含所有线程
3.运行时开销严重，整体都会变慢
4.使用方式
  - Debug.startMethodTracing(");
  - Debug.stopMethodTracing();
  - 生成文件在sd卡:Android/data/packagename/files

1.监控和跟踪Api调用、线程运行情况，生成Html报告
2.API18以上使用，推荐TraceCompat
3.使用方式
  python systrace.py -t 10 [other-options] [categories]
  文档：https://developer.android.com/studio/command-line/systrace#command options
4.优点
  1.轻量级，开销小
  2.直观反映CPU利用率
  3.给出建议

1.严苛模式，Android提供的一种运行时检测机制
2.方便强大，容易被忽视
3.包含: 线程策略和虚拟机策略检测
4.线程策略
  自定义的耗时调用，detectCustomSlowCalls()
  磁盘读取操作，detectDiskReads
  网络操作，detectNetwork
5.虚拟机策略
  Activity泄露，detectActivityLeaks()
  Sqlite对象泄露，detectLeakedSqlLiteObjects
  检测实例数量，setClassInstanceLimit()

//使用示例：
private void initStrictMode() {
    if (DEV_MODE) {
        StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                .detectCustomSlowCalls() //API等级11，使用StrictMode.noteSlowCode
                .detectDiskReads()
                .detectDiskWrites()
                .detectNetwork()// or .detectAll() for all detectable problems
                .penaltyLog() //在Logcat 中打印违规异常信息
                .build());
        StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                .detectLeakedSqlLiteObjects()
                .setClassInstanceLimit(NewsItem.class, 1)
                .detectLeakedClosableObjects() //API等级11
                .penaltyLog()
                .build());
    }
}

1.系统工具适合线下针对性分析
2.线上及测试环节需要自动化检测方案

1.消息处理机制，一个线程只有一个Looper
2.mLogging对象在每个message处理前后被调用
3.主线程发生卡顿，是在dispatchMessage执行耗时操作

1.Looper.getMainLooper().setMessageLogging();
2.匹配>>>>>Dispatching,闽值时间后执行任务(获取堆栈)
3.匹配<<<<<Finished,任务启动之前取消掉

非侵入式的性能监控组件，通知形式弹出卡顿信息
  - com.github.markzhai:blockcanary-android
  - https://github.com/markzhai/AndroidPerformanceMonitor
使用：
implementation 'com.github.markzhai:blockcanary-android:1.5.0'
//application中执行初始化
BlockCanary.install(this, new AppBlockCanaryContext()).start();
//mainActivity演示Msg导致的主线程卡顿
        new Handler().post(new Runnable() {
            @Override
            public void run() {
                LogUtils.i("Msg 执行");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });

//自定义类
package com.optimize.performance.block;

import android.content.Context;
import android.util.Log;

import com.github.moduth.blockcanary.BlockCanaryContext;
import com.github.moduth.blockcanary.internal.BlockInfo;

import java.io.File;
import java.util.LinkedList;
import java.util.List;

/**
 * BlockCanary配置的各种信息
 */
public class AppBlockCanaryContext extends BlockCanaryContext {

    /**
     * Implement in your project.
     *
     * @return Qualifier which can specify this installation, like version + flavor.
     */
    public String provideQualifier() {
        return "unknown";
    }

    /**
     * Implement in your project.
     *
     * @return user id
     */
    public String provideUid() {
        return "uid";
    }

    /**
     * Network type
     *
     * @return {@link String} like 2G, 3G, 4G, wifi, etc.
     */
    public String provideNetworkType() {
        return "unknown";
    }

    /**
     * Config monitor duration, after this time BlockCanary will stop, use
     * with {@code BlockCanary}'s isMonitorDurationEnd
     *
     * @return monitor last duration (in hour)
     */
    public int provideMonitorDuration() {
        return -1;
    }

    /**
     * Config block threshold (in millis), dispatch over this duration is regarded as a BLOCK. You may set it
     * from performance of device.
     *
     * @return threshold in mills
     */
    public int provideBlockThreshold() {
        return 500;
    }

    /**
     * Thread stack dump interval, use when block happens, BlockCanary will dump on main thread
     * stack according to current sample cycle.
     * <p>
     * Because the implementation mechanism of Looper, real dump interval would be longer than
     * the period specified here (especially when cpu is busier).
     * </p>
     *
     * @return dump interval (in millis)
     */
    public int provideDumpInterval() {
        return provideBlockThreshold();
    }

    /**
     * Path to save log, like "/blockcanary/", will save to sdcard if can.
     *
     * @return path of log files
     */
    public String providePath() {
        return "/blockcanary/";
    }

    /**
     * If need notification to notice block.
     *
     * @return true if need, else if not need.
     */
    public boolean displayNotification() {
        return true;
    }

    /**
     * Implement in your project, bundle files into a zip file.
     *
     * @param src  files before compress
     * @param dest files compressed
     * @return true if compression is successful
     */
    public boolean zip(File[] src, File dest) {
        return false;
    }

    /**
     * Implement in your project, bundled log files.
     *
     * @param zippedFile zipped file
     */
    public void upload(File zippedFile) {
        throw new UnsupportedOperationException();
    }


    /**
     * Packages that developer concern, by default it uses process name,
     * put high priority one in pre-order.
     *
     * @return null if simply concern only package with process name.
     */
    public List<String> concernPackages() {
        return null;
    }

    /**
     * Filter stack without any in concern package, used with @{code concernPackages}.
     *
     * @return true if filter, false it not.
     */
    public boolean filterNonConcernStack() {
        return false;
    }

    /**
     * Provide white list, entry in white list will not be shown in ui list.
     *
     * @return return null if you don't need white-list filter.
     */
    public List<String> provideWhiteList() {
        LinkedList<String> whiteList = new LinkedList<>();
        whiteList.add("org.chromium");
        return whiteList;
    }

    /**
     * Whether to delete files whose stack is in white list, used with white-list.
     *
     * @return true if delete, false it not.
     */
    public boolean deleteFilesInWhiteList() {
        return true;
    }

    /**
     * Block interceptor, developer may provide their own actions.
     */
    public void onBlock(Context context, BlockInfo blockInfo) {
        Log.i("lz","blockInfo "+blockInfo.toString());
    }
}

1.非侵入式
2.方便精准，定位到代码某一行
缺点：
1.确实卡顿了，但卡顿堆栈可能不准确
2.和OOM一样，最后的堆栈只是表象，不是真正问题

获取监控周期内的多个堆栈，而不仅是最后一个
startMonitor->高频采集堆栈->endMonitor->记录多个堆栈->上报

高频卡顿上报量太大，服务端有压力
分析:一个卡顿下多个堆栈大概率有重复
解决:对一个卡顿下堆栈进行hash排重，找出重复的堆栈
效果:极大的减少展示量同时更高效找到卡顿堆栈

KeyDispatchTimeout，5s
BroadcastTimeout，前台10s，后台60s
ServiceTimeout，前台20s，后台200s

发生ANR
进程接收异常终止信号，开始写入进程ANR信息
弹出ANR提示框(Rom表现不一,有的手机可能不弹)

adb pull data/anr/traces.txt 存储路径(发送anr系统会保存自动保存信息到该文件)
详细分析:CPU、IO、锁

 @Override
    protected void onCreate(Bundle savedInstanceState) {
    ...
  new Thread(){	
    @Override
      public void run() {
        super.run();
          synchronized (MainActivity.this){
            try {	
              Thread.sleep( millis: 20000);
            } catch (InterruptedException e) {
              e.printStackTrace();
            }.start();
    ...	
    synchronized (MainActivity.this){
      LogUtils.i( msg:");
    }
    ...
}

通过FileOberver监控文件变化，高版本权限问题(高版本上权限问题导致无法监控到文件变化)

非侵入式的ANR监控组件
  - com.github.anrwatchdog:anrwatchdog:1.3.0
  - https://github.com/SalomonBrys/ANRWatchDog
使用：
	new ANRWatchDog().start();（Application中）
ANR-WatchDog原理：
	start->post消息改值->sleep->检测是否修改->判断ANR发生->抛出异常（线下调试方便，自动定位到异常代码位置）
	//可以复写他的异常处理代码，改为上传到自己服务器上而不跑出异常
优点：
	- 非侵入式
	- 弥补高版本无权限问题

1.AndroidPerformanceMonitor:监控Msg
2.ANR-WatchDog :看最终结果
3.前者适合监控卡顿，后者适合补充ANR监控

1.自动卡顿监测方案并不够（有卡顿但是不到阈值）
2.体系化解决方案务必尽早暴露问题
3.单点问题:主线程IPC、DB

监测指标
  - IPC调用类型
  - 调用耗时、次数
  - 调用堆栈、发生线程
常规方案
  - IPC前后加埋点
  - 不优雅、容易忘记
  - 维护成本大
IPC问题监测技巧
  - adb 命令
    - adb shell am trace-ipc start
    - adb shell am trace-ipc stop -dump-file/data/local/tmp/ipc-trace.txt
    - adb pull /data/local/tmp/ipc-trace.txt
IPC问题监测
  - 优雅方案
    - ARTHook 还是AspectJ ?
    - ARTHook:可以Hook系统方法
    - AspectJ:非系统方法

示例：
try {
            DexposedBridge.findAndHookMethod(Class.forName("android.os.BinderProxy"), "transact",
                    int.class, Parcel.class, Parcel.class, int.class, new XC_MethodHook() {
                        @Override
                        protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
                            LogUtils.i( "BinderProxy beforeHookedMethod " + param.thisObject.getClass().getSimpleName()
                                    + "\n" + Log.getStackTraceString(new Throwable()));
                            super.beforeHookedMethod(param);
                        }
                    });
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }

1.IPC
2.IO、DB
3.View绘制

1.onCreate到onWindowFocusChanged
2.特定接口

轻量级Android AOP框架
  - 编译速度快，支持增量编译
  - API简单，没有任何多余代码插入 apk
  - https://github.com/eleme/lancet
使用介绍
	- @Proxyi通常用与对系统API调用的Hook
	- @Insert 常用于操作App与library的类

package com.optimize.performance.aop;

import android.content.Context;
import android.os.Bundle;
import android.os.Handler;
import android.util.Log;

import com.optimize.performance.utils.LogUtils;
import com.optimize.performance.wakelock.WakeLockUtils;

import me.ele.lancet.base.Origin;
import me.ele.lancet.base.Scope;
import me.ele.lancet.base.annotations.Insert;
import me.ele.lancet.base.annotations.Proxy;
import me.ele.lancet.base.annotations.TargetClass;

public class ActivityHooker {

    public static ActivityRecord sActivityRecord;

    static {
        sActivityRecord = new ActivityRecord();
    }

    public static String trace;

    @Insert(value = "onCreate",mayCreateSuper = true)
    @TargetClass(value = "android.support.v7.app.AppCompatActivity",scope = Scope.ALL)
    protected void onCreate(Bundle savedInstanceState) {
        sActivityRecord.mOnCreateTime = System.currentTimeMillis();
        Origin.callVoid();
    }

    @Insert(value = "onWindowFocusChanged",mayCreateSuper = true)
    @TargetClass(value = "android.support.v7.app.AppCompatActivity",scope = Scope.ALL)
    public void onWindowFocusChanged(boolean hasFocus) {
        sActivityRecord.mOnWindowsFocusChangedTime = System.currentTimeMillis();
        LogUtils.i("onWindowFocusChanged cost "+(sActivityRecord.mOnWindowsFocusChangedTime - sActivityRecord.mOnCreateTime));
        Origin.callVoid();
    }


    public static long sStartTime = 0;

    @Insert(value = "acquire")
    @TargetClass(value = "com.optimize.performance.wakelock.WakeLockUtils",scope = Scope.SELF)
    public static void acquire(Context context){
        trace = Log.getStackTraceString(new Throwable());
        sStartTime = System.currentTimeMillis();
        Origin.callVoid();
        new Handler().postDelayed(new Runnable() {
            @Override
            public void run() {
                WakeLockUtils.release();
            }
        },1000);
    }

    @Insert(value = "release")
    @TargetClass(value = "com.optimize.performance.wakelock.WakeLockUtils",scope = Scope.SELF)
    public static void release(){
        LogUtils.i("PowerManager "+(System.currentTimeMillis() - sStartTime)+"/n"+trace);
        Origin.callVoid();
    }


    public static long runTime = 0;

    @Insert(value = "run")
    @TargetClass(value = "java.lang.Runnable",scope = Scope.ALL)
    public void run(){
        runTime = System.currentTimeMillis();
        Origin.callVoid();
        LogUtils.i("runTime "+(System.currentTimeMillis() - runTime));
    }

    @Proxy("i")
    @TargetClass("android.util.Log")
    public static int i(String tag, String msg) {
        msg = msg + "";
        return (int) Origin.call();
    }
}


package com.optimize.performance.aop;
public class ActivityRecord {
    public long mOnCreateTime;
    public long mOnWindowsFocusChangedTime;
}

1.总体耗时
2.生命周期耗时
3.生命周期间隔耗时

1.只知道盲区时间，不清楚具体在做什么
2.线上盲区无从追查

package com.optimize.performance.handler;

import android.os.Handler;
import android.os.Looper;
import android.os.Message;
import android.util.Log;

import com.optimize.performance.utils.LogUtils;

import org.json.JSONObject;

public class SuperHandler extends Handler {

    private long mStartTime = System.currentTimeMillis();

    public SuperHandler() {
        super(Looper.myLooper(), null);
    }

    public SuperHandler(Callback callback) {
        super(Looper.myLooper(), callback);
    }

    public SuperHandler(Looper looper, Callback callback) {
        super(looper, callback);
    }

    public SuperHandler(Looper looper) {
        super(looper);
    }

    @Override
    public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
        boolean send = super.sendMessageAtTime(msg, uptimeMillis);
        if (send) {
            GetDetailHandlerHelper.getMsgDetail().put(msg, Log.getStackTraceString(new Throwable()).replace("java.lang.Throwable", ""));
        }
        return send;
    }

    @Override
    public void dispatchMessage(Message msg) {
        mStartTime = System.currentTimeMillis();
        super.dispatchMessage(msg);

        if (GetDetailHandlerHelper.getMsgDetail().containsKey(msg)
                && Looper.myLooper() == Looper.getMainLooper()) {
            JSONObject jsonObject = new JSONObject();
            try {
                jsonObject.put("Msg_Cost", System.currentTimeMillis() - mStartTime);
                jsonObject.put("MsgTrace", msg.getTarget() + " " + GetDetailHandlerHelper.getMsgDetail().get(msg));

                LogUtils.i("MsgDetail " + jsonObject.toString());
                GetDetailHandlerHelper.getMsgDetail().remove(msg);
            } catch (Exception e) {
            }
        }
    }

}

1.卡顿监控重要的一环，全面性保障
2.TraceView适合线下，可以监控系统Msg
3.动态替换适合线上，只有应用自身的Msg

耗时操作:异步、延迟
布局优化:异步Inflate、X2C、重绘解决
内存:降低内存占用，减少GC时间

系统工具认识、使用
  - SysTrace
  - TraceView
  - StrictMode
自动化监控及优化
  - AndroidPerformanceMonitor、ANR-WatchDog
  - 高频采集，找出重复率高的堆栈
卡顿监控工具
  - 单点问题:AOP、Hook
  - 盲区监控: gradle编译期替换
卡顿监控指标
  - 卡顿率、ANR率、界面秒开率
  - 交互时间、生命周期时间
  - 上报环境、场景信息

1.你是怎么做卡顿优化的
  - 第一阶段:系统工具定位、解决
  - 第二阶段:自动化卡顿方案及优化
  - 第三阶段:线上监控及线下监测工具建设
2.怎么自动化的获取卡顿信息
  - mLogging.println
  - 高频采集，找出重复堆栈
3.卡顿的一整套解决方案是怎么做的
  - 线下、线上工具相结合
  - 特定难题突破:单点问题、盲区监控
  - 线上监控建设

//布局优化
1. 绘制时长检测：
  	1.AOP（面向切面编程,在指定的地方执行特定的代码）的方式获取每个界面的绘制耗时;
  	1.Systrace查看整体绘制情况，查看是否存在绘制耗时等情况；
  	2.as自带的布局检测工具Inspector，查看视图层次结构；
2.如存在io加载布局文件慢
  	1.使用AsyncLayoutInflater/X2C异步加载布局
3. 布局层级:减少布局层级，减少过度绘制
    1.减少View树层级
    2.宽而浅，避免窄而深
   	3.尽量使用 ConstraintLayout布局控件
 2.gpu过度绘制//开发者选项-调试gpu过度绘制打开设置
    1.一个像素最好只被绘制一次
    2.调试GPU过度绘制
    3.蓝色可接受
   
 3. 卡顿的原因就是CPU数据处理不过来，比如层级过深，CPU太忙，GC，之类的，可以通过systrace 工具进行检测，
		然后通过编舞者监测帧率定位时间，再然后可以通过looper的日志功能定位到卡顿点。网上也有库blockcanary
 		
 3.在Systrace 报告中，你可以查看应用程序布局绘制的相关事件，包括布局计算、绘制命令的发送、GPU 图形呈现等阶段所花费的时间

1.CPU负责计算显示内容
2.GPU负责栅格化(UI元素绘制到屏幕上)
3.16ms发出VSync信号触发UI渲染
4.大多数的Android设备屏幕刷新频率:60Hz

Systrace
  - 关注Frames
  - 正常:绿色圆点，丢 :黄色或红色
  - Alerts栏

1.AndroidStudio自带工具
2.查看视图层次结构
androidStudio顶部tools-Layout Inspector-选择对应进程-生成当前界面的检测信息

获取FPS，线上使用，具备实时性
  - Api 16之后
  - Choreographer.getInstance().postFrameCallback
使用示例：

@TargetApi(Build.VERSION_CODES.JELLY_BEAN)
    private void getFPS() {
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN) {
            return;
        }
        Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
            @Override
            public void doFrame(long frameTimeNanos) {
                if (mStartFrameTime == 0) {
                    mStartFrameTime = frameTimeNanos;
                }
                long interval = frameTimeNanos - mStartFrameTime;
                if (interval > MONITOR_INTERVAL_NANOS) {
                    double fps = (((double) (mFrameCount * 1000L * 1000L)) / interval) * MAX_INTERVAL;
                    mFrameCount = 0;
                    mStartFrameTime = 0;
                } else {
                    ++mFrameCount;
                }
                Choreographer.getInstance().postFrameCallback(this);
            }
        });
    }

背景:获取每个界面加载耗时
实现:覆写方法、手动埋点

package com.optimize.performance.aop;
import com.optimize.performance.utils.LogUtils;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.Signature;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
	
  @Aspect
public class PerformanceAop {
  @Around("execution(* android.app.Activity.setContentView(..))")
      public void getSetContentViewTime(ProceedingJoinPoint joinPoint) {
          Signature signature = joinPoint.getSignature();
          String name = signature.toShortString();
          long time = System.currentTimeMillis();
          try {
              joinPoint.proceed();
          } catch (Throwable throwable) {
              throwable.printStackTrace();
          }
          LogUtils.i(name + " cost " + (System.currentTimeMillis() - time));
      }
    }

@Override
 protected void onCreate(Bundle savedInstanceState) {
   LayoutInflaterCompat.setFactory2(getLayoutInflater(), new LayoutInflater.Factory2() {
           @Override
           public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
               if (TextUtils.equals(name, "TextView")) {
                   // 生成自定义TextView
               }
               long time = System.currentTimeMillis();
               View view = getDelegate().createView(parent, name, context, attrs);
               LogUtils.i(name + " cost " + (System.currentTimeMillis() - time));
               return view;
           }
           @Override
           public View onCreateView(String name, Context context, AttributeSet attrs) {
               return null;
           }
       });
	 ...//需要在下面2句代码之前执行否则无效
       setTheme(R.style.AppTheme);
       super.onCreate(savedInstanceState);
       ...
  }

1.布局文件读取慢:IO过程
2.创建View慢:反射(比new慢3倍)

简称异步Inflate
	- WorkThread加载布局
	- 回调主线程
	- 节约主线程时间

com.android.support:asynclayoutinflater

 @Override
    protected void onCreate(Bundle savedInstanceState) {
     new AsyncLayoutInflater(MainActivity.this).inflate(R.layout.activity_main, null, new AsyncLayoutInflater.OnInflateFinishedListener() {
                @Override
                public void onInflateFinished(@NonNull View view, int i, @Nullable ViewGroup viewGroup) {
                    setContentView(view);
                    mRecyclerView = findViewById(R.id.recycler_view);
                    mRecyclerView.setLayoutManager(new LinearLayoutManager(MainActivity.this));
                    mRecyclerView.setAdapter(mNewsAdapter);
                    mNewsAdapter.setOnFeedShowCallBack(MainActivity.this);
                }
            });
        setTheme(R.style.AppTheme);
        super.onCreate(savedInstanceState);
        ...
    }

测量:确定大小（自顶向下遍历确定每个布局的大小）
布局:确定位置（根据测量大小确定控件位置）
绘制:绘制视图

1.每个阶段耗时
2.自顶而下的遍历
3.触发多次

准则
  1.减少View树层级
  2.宽而浅，避免窄而深

1.实现几乎完全扁平化布局
2.构建复杂布局性能更高
3.具有RelativeLayout和LinearLayout特性

1.不嵌套使用RelativeLayout
2.不在嵌套LinearLayout中使用weight
3.merge标签:减少一个层级，只能用于根View

//过度绘制-开发者选项-调试gpu过度绘制打开设置
1.一个像素最好只被绘制一次
2.调试GPU过度绘制
3.蓝色可接受

1.去掉多余背景色，减少复杂shape使用
2.避免层级叠加
3.自定义View使用clipRect屏蔽被遮盖View绘制

1.Viewstub:高效占位符、延迟初始化
2.onDraw中避免:创建大对象、耗时操作
3.TextView优化

你在做布局优化过程中用到了哪些工具
  - Choreographer
  - AOP、Hook
  - Systrace、Layout Inspector	
布局为什么会导致卡顿，你又是怎么优化的 ?
  - IO、反射、遍历、重绘
  - 异步Inflate、X2C、减少层级、重绘
做完布局优化有哪些成果产出
  - 体系化监控手段:线下+线上
  - 指标:FPS、加载时间、布局层级
  - 核心路径保障

1.内存是大问题但缺乏关注
2.压死骆驼的最后一根稻草