一、背景
- 复杂的项目:代码复杂度的增加，第三方库的引入，某个Activity or Fragment与其他相关联的类或是方法 或是子模块 。这时候针对某一个Activity进行查找Ui卡顿的问题，然后进行操作是十分困难的！
- 卡顿积累到一定程度造成Activity Not Response，只有在ANR现象下，才能获取到当前堆栈信息
BlockCanary
————Android 平台-非侵入式的性能监控组件
————针对轻微的UI卡顿及不流畅现象的检查工具
1.1、UI卡顿原理——性能优化的大问题之一
最优策略：
60fps——>16ms/帧(一幅图像)
16ms内是否能完成一次操作
准则：尽量保证每次在16ms内处理完单次的所有的CPU与GPU计算、绘制、渲染等操作，否则会造成丢帧卡顿问题
1.2、UI卡顿常见原因：
1、Ui线程中做轻微耗时操作
系统为App创建的ActivityThread的作用，将事件分发给合适的view 或是widget；同时是应用和Ui交互的主线程
子线程通知主线程Ui完成可以显示：
- handler
- Activity.runOnUiThread(Runnable)
- View.post(Runnable)
- View.postDelayed(Runnable,long)-延时post
2、布局Layout过于复杂，无法再16ms内完成渲染
3、View过度绘制-负载加剧cpu or gpu
4、View频繁的触发measure、layout事件，导致在绘制Ui的时候时间加巨，损耗加巨，造成View频繁渲染
5、内存频繁触发GC过多 ——在同一帧频繁的创建临时变量加剧内存的浪费和渲染的增加
ps：虚拟机在执行Gc垃圾回收的时候，会暂停所有的线程（包括ui线程）。只有当Gc垃圾回收器完成工作才能继续开启线程继续执行工作
- 尽量减少临时变量的创建———代码优化的小点之一
二、BlockCanary 使用
2.1、引入依赖：
implementation'com.github.markzhai:blockcanary-android:1.5.0'
2.2、在代码中注册blockCanary：
（1）、application代码中初始化：
@Override
public void onCreate() {
super.onCreate();
//第一个参数上下文，第二个参数是blockcanary创建的自己的上下文
（2）、BlockCanary.install(this, new AppBlockContenxt() ).start();
}
// （3）、blockContext 特有的上下文的创建
public class AppBlockContext extends BlockCanaryContext {
//实现各种上下文，包括应用标识符，用户uid ，网络类型，卡慢判断阀值，Log保存位置等内容
…...
//1000ms，事件处理时间的阀值，可以通过修改这个阀值来修改超时阀值
public int provideBlockThreshold() {
return 1000;
}
…...
}
三、BlockCanary 核心实现原理
BlockCanary 核心实现原理 ：离不开主线程 ActivityThread +handler+looper轮询器
androidxref.com 在线查看源码网站
每个App只有一个主线程就是ActivityThread线程。
3.1 ActivityThread源码：
在官方的ActivityThread的源码中，可以看到：
publicstaticvoidmain(String[] args) {
…
Looper.prepareMainLooper();
- //主线程下创建好MainLooper后，关联一个消息队列MessageQueue；
- MainLooper就会在生命周期内不断的进行轮询操作，通过Looper获取到MessageQueue中的message，然后通知主线程去更新Ui
...
}
在prepareMainLooper()中：
/**
*通过MyLooper()函数创建一个主线程的looper
- 不论一共有多少个子线程，主线程只会有这一个looper，同理不论创建多少个handler最后都会关联到这个looper上
*/
publicstaticvoidprepareMainLooper() {
prepare(false);
synchronized(Looper.class) {
if(sMainLooper!= null) {
thrownewIllegalStateException("The main Looper has already been prepared.");
}
sMainLooper= myLooper();
}
}
在Looper中是如何实现消息的分发的呢？
在Looper.class() 中
msg.target.dispatchMessage(msg);//分发message ;msg.target 实际上就是handler
...
}
/**
* Handle system messages here.
核心处理消息方法
*/
//if ：在这里这个callback 实际上就是runnable,所以handleCallback实际上就是执行了runnbale中的run()函数来执行子线程
if(msg.callback!= null) {
handleCallback(msg);
} else{
if(mCallback!= null) {
//else ：handler通过sendMessage()方式来投递message 到messageQueue中
if(mCallback.handleMessage(msg)) {
return;
}
}
//调用该方法来处理消息 ，不论如何最后的回调一定是发生在Ui线程上
handleMessage(msg);
}
}
ps：如果Ui卡顿很有可能是因为在dispatchMessage()这个函数里执行了卡顿的耗时操作
思考：blockCanary 是如何通过android中dispatchMessage()原理实现打印的呢？
final Printer logging= me.mLogging;
if (logging!= null) {
logging.println(">>>>> Dispatching to "+ msg.target+ " "+
msg.callback+ ": "+ msg.what);
}
…
msg.target.dispatchMessage(msg);
...
if (logging!= null) {
logging.println("<<<<< Finished to "+ msg.target+ " "+ msg.callback);
}
解析：blockCanary 利用了handler原理在dispatchMessage()的上下方分别打印方法执行的时间，然后根据上下两个时间差，来判断dispatchMessage()中是否产生了耗时的操作，也就是这个dispatchMessage():是否有Ui卡顿；如果有Ui卡顿上下两个值计算的阀值就是配置的阀值，如果超过这个阀值，就可以dump出Ui卡顿的信息。通过堆栈信息来定位卡顿问题
3.2 blockCanary 流程图
1、通过handler.postMessage（） 发送消息给主线程
2、sMainLooper.looper（） 通过轮询器不断的轮询MessageQueue中的消息队列
3、通过Queue.next() 获取需要的消息
4、计算出调用dispatchMessage()方法中前后的时间差值
5、通过T2-T1的时间差来判断是否超过设定好的时间差的阀值
6、如果T2-T1 时间差 > 阀值 ，就dump 出information来定位Ui卡顿
7、如果执行完dispatchMessage()后延迟了阀值的0.8倍的话，进行了延迟发送 也会dump出需要的信息（堆栈信息，cpu使用率、内存信息）
三、BlockCanary 源码
BlockCanary.install(this, new AppBlockContenxt()).start();
install（）：
public static BlockCanary install(Context context, BlockCanaryContext blockCanaryContext) {
//将context，blockCanaryContext 赋值给BlockCanaryContext
BlockCanaryContext.init(context, blockCanaryContext);
//是否开启或是关闭展示通知栏的界面
setEnabled(context, DisplayActivity.class, BlockCanaryContext.get().displayNotification());
return get();
}
//决定 通知栏 开启or 关闭 的策略：BlockCanaryContext.get().displayNotification()
ps：displayNotification在debug 和test版本都是返回true，只有在release版本才返回fasle，也就是说 displayNotification 是不会展示的
get（）：通过get()单例模式生成BlockCanary的实例
public static BlockCanary get() {
if (sInstance == null) {
synchronized (BlockCanary.class) {
if (sInstance == null) {
sInstance = new BlockCanary();
}
}
}
return sInstance;
}
BlockCanary（） 构造函数的实现： //BlockCanary（）内部类就是blockCanary核心的实现
private BlockCanary() {
BlockCanaryInternals.setContext(BlockCanaryContext.get());
mBlockCanaryCore = BlockCanaryInternals.getInstance();
//传入BlockCanaryContext.get()的上下文，只有开启通知栏的时候才会展开下面的BlockInterceptor拦截器
mBlockCanaryCore.addBlockInterceptor(BlockCanaryContext.get());
if (!BlockCanaryContext.get().displayNotification()) {
return;
}
//传入BlockCanary内部实现的，来展示DisplayService()
mBlockCanaryCore.addBlockInterceptor(new DisplayService());
}
BlockCanaryInternals（）：
public BlockCanaryInternals() {
//dump出线程的dump信息，传入参数主线程，looper.getMainLooper（）.getThread()
stackSampler= new StackSampler(
Looper.getMainLooper().getThread(),
sContext.provideDumpInterval());
//dump出cpu有关信息
cpuSampler= new CpuSampler(sContext.provideDumpInterval());
//内部创建一个LooperMonitor，在该方法中控制时间差
setMonitor(new LooperMonitor(new LooperMonitor.BlockListener() {
//在该方法内打印：主线程调用栈、cpu使用情况、内存情况
@Override
public void onBlockEvent(long realTimeStart, long realTimeEnd,
long threadTimeStart, long threadTimeEnd) {
// Get recent thread-stack entries and cpu usage
ArrayList<String> threadStackEntries = stackSampler
.getThreadStackEntries(realTimeStart, realTimeEnd);
if (!threadStackEntries.isEmpty()) {
BlockInfo blockInfo = BlockInfo.newInstance()
.setMainThreadTimeCost(realTimeStart, realTimeEnd, threadTimeStart, threadTimeEnd)
.setCpuBusyFlag(cpuSampler.isCpuBusy(realTimeStart, realTimeEnd))
.setRecentCpuRate(cpuSampler.getCpuRateInfo())
.setThreadStackEntries(threadStackEntries)
.flushString();
LogWriter.save(blockInfo.toString());
if (mInterceptorChain.size() != 0) {
for (BlockInterceptor interceptor : mInterceptorChain) {
interceptor.onBlock(getContext().provideContext(), blockInfo);
}
}
}
}
}, getContext().provideBlockThreshold(), getContext().stopWhenDebugging()));
//删除日志，默认情况下日志保存2天
LogWriter.cleanObsolete();
}
start（）：
public void start() {
if (!mMonitorStarted) {
mMonitorStarted = true;
//获取主线程looper；再调用主线程的setMessageLogging()进行时间打点
ps：mBlockCanaryCore.monitor 在BlockCanaryInternals（）中创建
Looper.getMainLooper().setMessageLogging(mBlockCanaryCore.monitor);
}
}
monitor()：
class LooperMonitor implements Printer {
//时间打点方法
@Override
public void println(String x) {
if (mStopWhenDebugging && Debug.isDebuggerConnected()) {
return;
}
if (!mPrintingStarted) {
//获取系统时间的时间戳 mStartTimestamp
mStartTimestamp = System.currentTimeMillis();
//获取当前线程运行的时间mStartThreadTimestamp，当前线程处于运行状态的总时间
ps：线程中的sleep、wait时间不会记录在这个总时间内
mStartThreadTimestamp = SystemClock.currentThreadTimeMillis();
mPrintingStarted = true;
startDump();//打印开始时间的堆栈信息
} else { //在dispatchMessage()之后进行如下操作
final long endTime = System.currentTimeMillis();
mPrintingStarted = false;
if (isBlock(endTime)) { //产生Ui卡顿现象
notifyBlockEvent(endTime);
}
stopDump();//打印结束时间的堆栈信息
}
}
//通过BlockCanaryInternals()方法分别打印stackSampler和cpuSampler
startDump（）：
private void startDump() {
if (null != BlockCanaryInternals.getInstance().stackSampler) {
BlockCanaryInternals.getInstance().stackSampler.start();
}
if (null != BlockCanaryInternals.getInstance().cpuSampler) {
BlockCanaryInternals.getInstance().cpuSampler.start();
}
}
.stackSampler.start()：
public void start() {
if (mShouldSample.get()) {
return;
}
mShouldSample.set(true);
HandlerThreadFactory.getTimerThreadHandler().removeCallbacks(mRunnable);
//调用handler的postDelayed方法传递一个runnable
HandlerThreadFactory.getTimerThreadHandler().postDelayed(mRunnable,
BlockCanaryInternals.getInstance().getSampleDelay());
}
该runnable 定义在AbstractSampler 抽象类中（cpuSampler、stackSampler）
private Runnable mRunnable= new Runnable() {
@Override
public void run() {
doSample();
if (mShouldSample.get()) {
HandlerThreadFactory.getTimerThreadHandler()
.postDelayed(mRunnable, mSampleInterval);
}
}
};
doSample(); 抽象方法，意味着stackSampler和 cpuSampler会有不同的实现
abstract void doSample();
stackSampler（）：
@Override
protected void doSample() {
StringBuilder stringBuilder = new StringBuilder()；
//获取到当前线程的调用栈信息
for (StackTraceElement stackTraceElement :mCurrentThread.getStackTrace() ) {
stringBuilder
.append(stackTraceElement.toString())
.append(BlockInfo.SEPARATOR);
}
synchronized (sStackMap) {
if (sStackMap.size() == mMaxEntryCount && mMaxEntryCount > 0) {
sStackMap.remove(sStackMap.keySet().iterator().next());
}
//在同步代码块中，以当前时间戳为key，put放入到StackMap这个HashMap中
sStackMap.put(System.currentTimeMillis(), stringBuilder.toString());
}
}
private static final LinkedHashMap<Long, String> sStackMap = new LinkedHashMap<>();
思考：sStackMap为什么被定义成LinkedHashMap？
LinkedHashMap 和HashMap最大的区别？
- LinkedHashMap能够记录entry的插入顺序！，插入的顺序是已知的
- HashMap不能记录顺序，未知的
cpuSampler（）：
@Override
protected void doSample() {
BufferedReader cpuReader = null;
BufferedReader pidReader = null;
try {
//通过bufferReader读取 /proc 下的cpu文件
cpuReader = new BufferedReader(new InputStreamReader(
new FileInputStream("/proc/stat")), BUFFER_SIZE);
...
if (mPid == 0) {
mPid = android.os.Process.myPid();
}
//通过bufferReader读取 /proc 下的内存文件
pidReader = new BufferedReader(new InputStreamReader(
new FileInputStream("/proc/" + mPid + "/stat")), BUFFER_SIZE);
String pidCpuRate = pidReader.readLine();
if (pidCpuRate == null) {
pidCpuRate = "";
}
parse(cpuRate, pidCpuRate);
...
}
//T2-T1 时间 是否 > 设定好的blockCanary 阀值时间的最大值
isBlock（）：
private boolean isBlock(long endTime) {
//如果大于该mBlockThresholdMillis 返回 true 说明存在卡顿情况，有可能产生阻塞现象
return endTime - mStartTimestamp > mBlockThresholdMillis;
}
notifyBlockEvent（）：
private void notifyBlockEvent(final long endTime) {
final long startTime = mStartTimestamp;
final long startThreadTime = mStartThreadTimestamp;
final long endThreadTime = SystemClock.currentThreadTimeMillis();
HandlerThreadFactory.getWriteLogThreadHandler().post(new Runnable() {
@Override
public void run() {
//调用监听事件，它的回调方法在BlockCanaryInternals().setMonitor（）回调方法中
mBlockListener.onBlockEvent(startTime, endTime, startThreadTime, endThreadTime);
}
});
}
四、BlockCanary补充知识
4.1 ANR 定义
ANR：Application Not responding 程序未响应
超过预定时间仍然未响应就会造成ANR
监控工具：
Activity Manager 和WindowManager 进行监控的
4.2 ANR 分类 ***
1、Service Timeout
服务如果在20秒内没有完成执行的话，就会造成ANR
2、BroadcastQueue Timeout
广播如果在10秒内没有完成执行的话，就会造成ANR
3、InputDispatching Timeout
输入事件如果超过了5秒钟就会造成ANR
广播如果在10秒内没有完成执行的话，就会造成ANR
3、InputDispatching Timeout
输入事件（触摸屏、点击事件）如果超过了5秒钟就会造成ANR
4.3 ANR造成原因 ***
1、主线程做了一些耗时操作，比如网络、数据库获取操作等
2、主线程被其他线程锁住
主线程所需要的资源在被其他线程所使用中，导致主线程无法获取到该资源而造成主线程的阻塞，进而造成ANR现象
3、cpu被其他进程占用
这个进程没有被分配到足够的cpu资源
4.4 ANR 解决措施 ***
1、主线程读取数据
主线程禁止从网络获取数据，但是可以从数据库获取数据，虽然未被禁止该操作，但是执行这类操作会造成掉帧现象
Tips ： sharePreference 的commit () /apply()
commit() :同步方法
apply()： 异步方法
所以主线程中尽量不要调用 commit()方法，调用同步方法会阻塞主线程，尽量通过apply()方法执行操作
2、不要在BroadCastReceiver 的onReceive()方法中执行耗时操作
onReceive（）：也是运行在主线程中的，后台操作。
通过IntentService()方法执行相关操作
3、Activity的生命周期函数中都不应该有太耗时的操作
该生命周期函数大多数执行于主线程中，及时是Service 服务或是 内容提供者ContentProvider也不要在onCreate()中执行耗时操作
4.5 ANR 第三方监控工具 watchdog 检测anr工具
watchdog ： https://github.com/SalomonBrys/ANR-WatchDog
在linux 内核下，当Watchdog 启动后，便设定了一个定时器，当出现故障时候，通过会让Android系统重启。由于这种机制的存在，经常会出现一些system_server 进程被watchdog杀掉而发生手机重启的问题。
4.5.1 watchdog 初始化
Android 的watchdog 是一个单例线程 ，在System server时候就会初始化watchdog 。在watchdog初始化化时候会构建很多 HandlerChecker
大致可以分为两类：
Monitor Checker，用于检查是Monitor对象可能发生的死锁, AMS, PKMS, WMS等核心的系统服务都是Monitor对象。
Looper Checker，用于检查线程的消息队列是否长时间处于工作状态。Watchdog自身的消息队列，Ui, Io, Display这些全局的消息队列都是被检查的对象。此外，一些重要的线程的消息队列，也会加入到Looper Checker中，譬如AMS, PKMS，这些是在对应的对象初始化时加入的。
private Watchdog(){
…
mMonitorChecker = new HandlerChecker(FgThread.getHandler(),
“foreground thread”,DEFAULT_TIMEOUT);
mHandlerCheckers.add(mMonitorChecker);
mHandlerCheckers.add(new HandlerChecker(new Handler(Looper.getMainLooper()),
“main thread”,DEFAULT_TIMEOUT));
mHandlerCheckers.add(new HandlerChecker(UiThread.getHandler(),
“ui thread”,DEFAULT_TIMEOUT));
mHandlerCheckers.add(new HandlerChecker(IOThread.getHandler(),
“i/o thread”,DEFAULT_TIMEOUT)):
mHandlerCheckers.add(new HandlerChecker(DisplayThread.getHandler(),
“display thread”,DEFAULT_TIMEOUT));
…
}
两类 HandlerChecker的侧重点不同，Monitor Checker预警我们不能长时间持有核心系统服务的对象锁，否则会阻塞很多函数的运行；Looper Checker 预警我妈不能长时间的霸占消息队列，否则其他消息将得不到处理。
这两类都会导致系统卡住 ANR
public class ANRWatchDog extends Thread 继承自Thread类 表明气势ANRWatchDog也是一个线程类
// 简单原理：1、创建一个ANR线程，不断的向Ui线程通过handler post一个runnable任务
@Override
public void run() {
setName("|ANR-WatchDog|");
int lastTick;
int lastIgnored = -1;
while (!isInterrupted()) {
lastTick =_tick; //保存_tick成员变量
_uiHandler.post(_ticker);
ps1：handler在构造方法中传入了一个Looper.getMainLooper()主线程looper
this._uiHandler = new Handler(Looper.getMainLooper()); 所以这个Ui looper 很显然
关联的主线程 ，所以可以看出通过这个_uiHandler会将任务发送给主线程！
ps2:_tick在构造方法中的runnable()函数中 的run方法里每次会给_tick 计数 +1 是
ANRWatchDog.this._tick = (ANRWatchDog.this._tick +1) %2147483647 ;
try {
//2、执行完上面的操作会让线程睡眠固定的时间，给线程执行操作留出时间
Thread.sleep(_timeoutInterval);
}
catch (InterruptedException e) {
_interruptionListener.onInterrupted(e);
return ;
}
//3、线程重新开始运行 检测之前的post的任务是在执行了 两个临时变量是否相等，不相等代表Ui线程没有阻塞
相等表示 Ui线程没有接收到Post runnable这个消息
//4、刚才保存的_tick变量是否等于 刚才开启子线程当中进行run()+1 是否不等于保存的变量。通过对比来查看post runnable 是否已经发送到了主线程，主线程是否已经执行了该消息，执行后_tick ！= lastTick
// If the main thread has not handled _ticker, it is blocked. ANR.
if (_tick == lastTick) {
if (!_ignoreDebugger && Debug.isDebuggerConnected()) {
if (_tick != lastIgnored)
Log.w("ANRWatchdog", "An ANR was detected but ignored because the debugger is connected (you can prevent this with setIgnoreDebugger(true))");
lastIgnored = _tick;
continue ;
}
//提升用户
ANRError error;
if (_namePrefix != null)
error = ANRError.New(_namePrefix, _logThreadsWithoutStackTrace);
else
error = ANRError.NewMainOnly();
_anrListener.onAppNotResponding(error);
return;
}
}
}
4.6 newThread
Android 系统中最简单开启一个线程操作的机制
public void test (){
new Thread(){
@Override
public void run(){
super.run():
}
}.start()://start()线程处于就绪状态,一旦调用start(),run方法里就会执行到底无法中途取消
区别：
start() ：启动线程，真正实现了多线程的运行，无需等待其中的run()方法执行完，可以直接执行下面的代码。就绪了一个线程并没有直接就开始运行，告诉cpu可以运行状态
run() ：表明将该方法作为普同方法使用，想要执行run()方法后面的方法一定要等待里面的方法体执行完才能进行。所以也就是表明调用run(）方法还不是多线程。
new Thread 在Android 开启线程的弊端
1、多个耗时任务时就会开多个新线程，开销是非常大的 ，造成很大的性能浪费
2、如果在线程中执行循环任务，只能通过一个人为的标识位Flag来控制它的停止
3、没有线程切换的接口
4、如果从UI线程启动一个子线程，则该线程优先级默认为Default，这样就和Ui线程级别相同了 体现不出开子线程的目的
通过方法设定线程的优先级,将子线程的优先级将低为后台线程： Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUD);
4.7 线程间通信
Android 多线程编程时的两大原则
1、不要阻塞Ui线程
2、不要在ui线程之外访问Ui控件
线程间通信的两类：
1、将任务从工作线程交还到主线程 --更新Ui组件，将结果交回给主线程
通过handlerMessage()方法将工作线程的结果抛出给主线程
//2、handler机制的looper 轮询 MessageQueue，获取到消息交给handleMessage()
private Handler handle = new Handler() {
@Override
public void handleMessage(Message msg) {
//3、主线程handleMessage(接收的消息)并执行
super.handleMessage(msg);
}
};
//1、开启一个线程，在run方法中sendMessage 发送消息。
public void handlerTest() {
new Thread() {
@Override
public void run() {
super.run();
handle.sendEmptyMessage(0);
}
}.start();
在子线程中创建一个handler
new Thread() {
@Override
public void run() {
Looper.prepare();
//在子线程中创建一个handler 必需要先调用Looper.prepare()，创建一个给这个Handler使用的looper。让这个handler和创建好的looper关联起来。这个handler就是处理子线程消息的。
Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
Looper.loop();
}
}.start();
（1）、final Runnable runnable = new Runnable() {
@Override
public void run() {
}
};
（2）、new Thread() {
@Override
public void run() {
super.run();
//在子线程中使用handle.post(runnable)并没有开启了一个新的线程！
ps：只是让run()方法中的代码抛到与handle相关的线程中去执行
handle.post(runnable);
}
}.start();
//更新Ui的代码创建在runnable当中，只有是若当前线程是Ui线程时才会被立即执行
（3）、 Activity.this.runOnUiThread(runnable);
}
（4）、AsyncTask 内部通过线程池管理线程，通过handler切换Ui 线程和子线程
缺陷：AsyncTask 会持有当前Activity的引用，在使用的时候要把AsyncTask声明为静态static，在AsyncTask内部持有外部Activity的弱引用，预防内存泄漏
class MyAsyncTask extends AsyncTask<Void,Void,Void>{
@Override
protected void doInBackground(Void ..params){
//进行耗时操作，因为优先级时background所以不会阻塞Ui线程
3.0以后默认api设置为串行的原因：
当一个进程中开启多个AsyncTask的时候，它会使用同一个线程池执行任务，所以又多个AsyncTask一起并行执行的话，而且要在DIBG中访问相同的资源，这时候就有可能出现数据不安全的情况。设计成串行就不会有多线程数据不安全的问题。
}
@Override
protected void onPostExecute(Void voida){
}
}
2、将任务从主线程分配到工作线程 —耗时操作 分配给工作线程
2.1 Thread /Runnable
缺陷： Runnable 作为匿名内部类会持有外部类的引用 ，线程执行完前这个引用就会一直持有着，导致该Activity无法被正常回收 ，进而造成内存泄漏。所以不建议使用这类方法开启子线程
2.2 HandlerThread
继承自Thread 类，适用于单线程或是异步队列场景，耗时不多不会产生较大阻塞的情况比如io流读写操作，并不适合于进行网络数据的获取！！！
优点：
- 有自己内部的Looper对象，
- 通过Looper().prepare()可以初始化looper对象
- 通过Looper().loop（）开启looper循环
- HandlerThread的looper对象传递给Handler对象，然后在handleMessage()方法中执行异步任务
ps：不论是Thread 还是handlerThread只有开启了start()才能表示这个线程是启动的
handlerThread源码：
根据需求设置线程的优先级：
public HandlerThread(String name(线程名称）, int priority(线程优先级）){
super(name);
mPriority = priority;
}
线程优先级：-20～19 优先级高的cpn资源获得更多，最高值是-20 ，正19是优先级最低的
//在run()中创建一个Looper对象；通过 Looper.prepare()和Looper.loop()构造一个循环的线程
@Override
public void run() {
mTid = Process.myTid();
//1、创建looper对象
Looper.prepare();
synchronized(this) {
//2、将looper对象赋值给了handleThread的内部变量mLooper获得当前线程的looper
mLooper = Looper.myLooper();
//3、唤醒等待线程，通知线程竞争锁（wait ：释放锁）
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();//线程初始化操作
//4、开启线程队列
Looper.loop();
mTid = -1;
}
//在Ui线程中调用getLooper（）
public Looper getLooper() {
if (!isAlive()) {
return null;
}
//同步代码块：获取当前子线程HandleThread所关联的这个looper对象的实例
// If the thread has been started, wait until the looper has been created.
synchronized (this) {
//该线程是否存活，没存活返回null
while (isAlive() && mLooper == null) {
try {
//进入到阻塞阶段，直到前面的同步代码块中looper对象创建成功，并调用notifyAll()唤醒该等待线程，然后才会返回mLooper这个对象
wait();
} catch (InterruptedException e) {
}
}
}
return mLooper;
}
ps：如果不使用wait() 和notifyAll()这套等待唤醒机制，就无法保证在Ui线程中调用的getLooper()方法，调用的时候这个looper有可能已经被创建了。有可能面临同步的问题。
思考：如何退出HandleThread的循环线程呢？
a、quit()
public boolean quit(){
Looper looper = getLooper();
if(looper !=null){
//清空所有MessageQueue的消息
looper.quit():
return true;
}
return false;
}
b、quitSafely()
public boolean quitSafely(){
Looper looper = getLooper();
//只会清空MessageQueue中所有的延迟消息，将所有的非延迟消息分发出去
if(looper!=null){
looper.quitSafely();
return true;
}
return false;
}
2.3 IntentService
- IntentService 是Service类的子类，拥有service所有的生命周期的方法
-
会单独开启一个线程HandlerThread 来处理所有的Intent请求所对应的任务
-
当IntentService处理完所有的任务后，它会在适当的时候自动结束服务
IntentService源码
内部实现是通过HandleThread 完成异步执行的
1、首先在onCreate()方法中：
//建立一个循环的工作线程
HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
//mServiceLooper、mServiceHandler进行数据的读取
mServiceLooper = thread.getLooper();
mServiceHandler = new ServiceHandler(mServiceLooper);
思考：为什么要用volatile 修饰 mServiceLooper 和mServiceHandler？
解析：保证每一次looper 和ServiceHandler它的读取都是从主存中读取，而不是从各个线程中的缓存去读取。保证了两个数据的安全性。
//handler接收到消息要回调的，onHandleIntent这个是在工作线程执行的
protected abstract void onHandleIntent(@Nullable Intent intent);
4.8 多进程的优点 与缺陷
4.8.1、多进程的优点：
1、解决OOM问题——将耗时的工作放在辅助进程中避免主进程出现OOM
2、合理利用内存，在适当的时候生成新的进程，在不需要的时候杀掉这个进程
3、单一进程崩溃不会影响整个app的使用
4、项目解耦、模块化开发有好处
4.8.2、多进程的缺陷：
1、每次新进程的创建都会创建一个Application，造成多次创建Application
解析：根据进程名区分不同的进程，然后进行不同的初始化。不要在Application中进行过度静态变量初始化
2、文件读写潜在的问题
解析：需要并发访问的文件、本地文件、数据库文件等；多利用接口而避免直接访问文件
文件锁是基于进程和虚拟机的级别，如果从不同的进程访问一个文件锁，这个锁是失效的！（sharePreference)
3、静态变量和单例模式完全失效
解析：在进程中间，我们的内存空间是相互独立的。虚拟方法区内的静态变量也是相互独立的，由于静态变量是基于进程的，所以单例模式会失效。在不同进程间访问同一个相同类的静态变量，他的值也不一定相同
尽量避免在多进程中频繁的使用静态变量
4、线程同步机制完全失效
解析：Java的同步机制也是由虚拟机进行调度的。两个进程会有两个不同的虚拟机。同步关键字都将没用意义
synchronized 和 voliate 的三大区别 ？
1、阻塞线程与否
解析：
voliate关键字本质上是告诉JVM虚拟机当前的变量在寄存器中的值是不确定的，需要从主存中去获取不会造成线程的阻塞
synchronized关键字指明的代码块只有当前线程可以访问它的临界区的资源，其他的线程就会被阻塞住
2、使用范围
voliate关键字 只是修饰变量的
synchronized关键字不仅可以修饰变量还可以修饰方法
3、原子性-操作不会再分（不会因为多线程造成操作顺序的改变）
voliate关键字不具备原子性
synchronized关键字可以保证变量的原子性
4.9 voliate关键字和单例写法
单例模式：饿汉、懒汉、线程安全的 分析其中的问题
饿汉 单例模式：构造函数是私有的
缺陷：消耗很多内存，不管是否已经实例化过instance;适合占用内存比较小的单例
public class Singleton{
private static Singleton instance = new Singleton();
//其他类不能通过构造函数实例化Singleton类
private Singleton(){}
//提供一个静态的公共的获取类的方法
public static Singleton getInstance(){
return instance;
}
}
ps：不管instance是否创建完成，在加载类的时候都回去创建这个对象。
占用内存大的时候就衍生出了，相比饿汉单例模式消耗的资源更少
缺陷：并没有考虑多线程安全的问题，多次调用带有同步锁的代码块累积的性能损害就越来越大
懒汉单例模式
public class SingletonLazy {
private static SingletonLazy instance;
private SingletonLazy(){}
public static SingletonLazy getInstance(){
//1、只有在instance是空的情况才会创建SingletonLazy对象
if(null == instance){
instance = new SingletonLazy();
}
return instance;
}
//2、加锁只有一个线程可以进入方法体进行对象的创建，实现了延迟加载不会每次加载类的时候都创建对象
public static synchronized SingletonLazy getInstance1(){
if(null == instance) {
instance = new SingletonLazy();
}
return instance;
}
}
ps：通过synchronized关键字修饰的对象虽然会线程安全，但是会消耗更多的资源。
双重效验锁单例模式：
优点：解决了并发问题
缺陷：指令冲排序优化问题，导致初始化的时候它instance获取的地址是不确定的
也就是说这个instance有可能从单个缓存中获取，每一个线程的缓存是不一样的，就会造成静态的这个
instance不一致 造成单例的失灵
//双重instance 判断
public class SingletonDouble{
private static SingletonDouble instance = null;
private SingletonDouble{}
public static SingletonDouble getInstance(){
if(instance == null){
//大部分情况下不需要进入同步代码块中
synchronized (SingletonDouble.class){
if(instance ==null){
instance = new SingletonDouble():
}
}
}
return instance;
}
}
ps：如果同时两个线程都走到 if(instance == null){的判断，那么它会认为单例对象没有被创建，然后两个线程会同时进入同步代码块中。如果这时候判断对象为空的话，两个线程会同时创建单例对象
voliate关键字的单例模式
为了解决第三个的问题 出现了voliate关键字的使用
public class SingletonVoliate{
//当单例对象被修饰成voliate后，每一次instance内存中的读取都会从主内存中获取，而不会从缓存中获取，这样就解决了双重效验锁单例模式的缺陷
private static volatile SingletonVoliate instance =null;
private SingletonVoliate(){}
public static SingletonVoliate getInstance(){
if(instance ==null){
synchronized(SingletonVoliate.class){
if(instance ==null){
instance = new SingletonVoliate():
}
}
}
return instance;
}
}