1.2、异步优化
核心思想:子线程分担主线程任务,并行减少时间
比如说一个线程耗时1500ms,我们可以用三个并行的线程,每个耗时500ms。
/**
-
异步优化,使用线程池的方式,用多个并行线程来完成初始化,从而减少启动时间
-
此处的nThreads的数量不能写死,因为不同的手机我们可用的CPU数量不一样,有的我们可以用4个
-
核,有的可以用8个核,此处可以参考AsyncTask中的设置方法
*/
Executors.newFixedThreadPool(?);
AsyncTask.java
public abstract class AsyncTask<Params, Progress, Result> {
private static final String LOG_TAG = “AsyncTask”;
//获取到的设备的CPU数量
private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
//线程池的核心池数量
//如果 CPU_COUNT = 8, 那么最后取值为4 八核设备
//如果 CPU_COUNT = 4, 那么最后取值为3 四核设备
//如果 CPU_COUNT = 2, 那么最后取值为2 双核设备
private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 1;
private static final int KEEP_ALIVE_SECONDS = 30;
}
1.2.1、实战:
public class App extends Application {
private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));
@Override
public void onCreate() {
super.onCreate();
/**
-
异步优化,使用线程池的方式,用多个并行线程来完成初始化,从而减少启动时间
-
此处的nThreads的数量不能写死,因为不同的手机我们可用的CPU数量不一样,有的我们可以用4个
-
核,有的可以用8个核,此处可以参考AsyncTask中的设置方法
*/
ExecutorService service = Executors.newFixedThreadPool(CORE_POOL_SIZE);
service.submit(new Runnable() {
@Override
public void run() {
initBugly();
}
});
service.submit(new Runnable() {
@Override
public void run() {
initAMap();
}
});
…//如上,可以把多个方法按照如上方式都加入到runnable中
}
}
1.2.2、问题一:
例如,如果在某个异步执行的方法中有Handler
private void initBugly() {
//这个Handler由于在子线程中,就会报出异常
Handler handler = new Handler();
CrashReport.initCrashReport(getApplicationContext(), “注册时申请的APPID”, false);
}
通过以上例子,我们就知道在实际开发中,会有一些不满足异步执行的需求,此时有两种解决方案:一、把它修改成可以进行异步执行,如上例子,可以改为:
private void initBugly() {
Handler handler = new Handler(Looper.getMainLooper());
CrashReport.initCrashReport(getApplicationContext(), “注册时申请的APPID”, false);
}
二,实际开发中,有些操作是必须要放在子线程中执行的,那么针对这些操作,我们就放弃异步执行。
1.2.3、问题二:
举例,加入对于initBugly()方法,我们需要在SplashActivity界面需要用到Bugly中的某个方法,但是由于initBugly()方法是在子线程中异步执行的,我们不知道它有没有初始化完毕,如果没有初始化完毕我们就使用是会出错的。此处我们提供了一个解决方案:CountDownLatch,它相当于加个锁,如果不执行完毕就不解锁,具体我们看代码:
//1、 传入1 表示 mCountDownLatch 需要被满足一次
private CountDownLatch mCountDownLatch = new CountDownLatch(1);
@Override
public void onCreate() {
super.onCreate();
ExecutorService service = Executors.newFixedThreadPool(CORE_POOL_SIZE);
service.submit(new Runnable() {
@Override
public void run() {
initBugly();
//3、mCountDownLatch 被满足一次
mCountDownLatch.countDown();
}
});
//2、如果mCountDownLatch不被满足的话,它会一直等待
try {
mCountDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
1.2.4、异步优化注意:
-
不符合异步要求
-
需要在某阶段完成
-
区分CPU密集型和IO密集型任务
1.3、异步优化方案最优解
1.3.1、常规异步优化痛点
-
代码不优雅
-
场景不好处理(依赖关系)
-
维护成本高
1.3.2、启动器介绍
核心思想:充分利用CPU多核,自动梳理任务顺序
启动器流程:
-
代码Task化,启动逻辑抽象为Task
-
根据所有任务依赖关系排序生成一个有向无环图
-
多线程按照排序后的优先级依次执行
2、更优秀的延迟初始化方案
=============
2.1、常规初始化痛点
-
时机不便控制
-
导致Feed卡顿
2.2、更优方案
核心思想:对延迟任务进行分批初始化
利用IdleHandler特性,空闲执行
public class DelayInitDispatcher {
private Queue mDelayTasks = new LinkedList<>();
/**
- IdleHandler:在系统空闲时执行
*/
private MessageQueue.IdleHandler mIdleHandler = new MessageQueue.IdleHandler() {
@Override
public boolean queueIdle() {
if (mDelayTasks.size() > 0) {
Task task = mDelayTasks.poll();
new DispatchRunnable(task).run();
}
return !mDelayTasks.isEmpty();
}
};
/**
-
将返回值设置为当前的类:DelayInitDispatcher 就可以进行链式调用,因为addTask可能要调用很多次
-
@param task task
-
@return DelayInitDispatcher
*/
public DelayInitDispatcher addTask(Task task) {
mDelayTasks.add(task);
return this;
}
/**
- 开启 DelayInitDispatcher 的方法
*/
public void start() {
Looper.myQueue().addIdleHandler(mIdleHandler);
}
}
DelayInitDispatcher delayInitDispatcher = new DelayInitDispatcher();
delayInitDispatcher.addTask(new DelayInitTaskA())
.addTask(new DelayInitTaskB())
.start();
特点:
-
执行时机明确
-
缓解Feed卡顿
3、启动优化其他方案
==========
3.1、优化总方针
-
异步、延迟、懒加载
-
技术、业务相结合
-
注意事项:wall time和cpu time,cpu time才是优化方向,按照systrace及cpu time跑满cpu
-
监控的完善:线上监控多阶段时间(App, Activity, 生命周期间隔时间)、处理聚合看趋势
-
收敛启动代码修改权限:结合Ci修改启动代码需要Review或通知
-
提前加载 SharedPreferences :对SharedPreferences的操作是IO操作,如果有很多文件需要操作它,因为使用的是同一把锁,就有可能造成耗时,因此我们可以在 Multidex之前加载,利用此阶段CPU(此阶段CPU并没有被充分利用),如果是其他操作放在Multidex之前有可能会报错(4.x版本),但是SharedPreferences是系统类,调用起来不会出错。这是少有的我们可以在Multidex之前调用的利用CPU的操作。覆写getApplicationContext()返回this。
-
启动阶段不启动子进程:子进程会共享CPU资源,导致主进程CPU资源紧张;注意启动顺序:App onCreate之前是ContentProvider
-
类加载优化:提前异步类加载。Class.forName()只加载类本身及其静态变量的引用类;new类实例 可以额外加载类成员变量的引用类
-
启动阶段抑制GC
-
CPU锁频:系统分配给我们的核是固定的,例如四个或八个,但是这几个核的使用率可能不高,例如只有50%,或者说分配给我们的时间不多,例如只有1秒,但是如果我们的APP启动时间大于1秒,这时候如果采用锁频技术(提高CPU的使用频率),就可以拉伸这个时间,比如延长到3秒或5秒,让我们更快启动APP。
3.2、启动优化方案总结
3.2.1、获取方法耗时
-
常规方案:耦合度高
-
AOP:耦合度低
-
wall time与cpu time区别
3.2.2、异步、延迟初始化
异步初始化
-
常规异步方案:new Thread或者使用线程池来分担主线程压力,但是这种方案有缺点:一不太好控制,例如不太好控制依赖关系(A需要依赖B C D E,这种依赖关系使用线程不太好处理 );
-
升级:启动器方案。使用Task(分为不同的任务:推送功能、地图功能、IO操作都可以抽象成不同的Task,在Task中我们就可以对其进行排序,也就是生成一个有向无环图)
-
注意痛点以及启动器优势的理解
延迟初始化
-
常规方案:使用Handler的postDelayed() 缺点:有可能导致卡顿
-
升级:结合IdleHandler,它会利用空闲时间来执行(当MessageQueue中没有Message的时候)
其他
-
提前加载SharedPreferences
-
启动阶段不启动子线程
-
提前异步 类加载
3.2.3、其他方案
4、启动优化模拟面试
==========
最后:学习总结——Android框架体系架构知识脑图(纯手绘xmind文档)
学完之后,若是想验收效果如何,其实最好的方法就是可自己去总结一下。比如我就会在学习完一个东西之后自己去手绘一份xmind文件的知识梳理大纲脑图,这样也可方便后续的复习,且都是自己的理解,相信随便瞟几眼就能迅速过完整个知识,脑补回来。
下方即为我手绘的Android框架体系架构知识脑图,由于是xmind文件,不好上传,所以小编将其以图片形式导出来传在此处,细节方面不是特别清晰。但可给感兴趣的朋友提供完整的Android框架体系架构知识脑图原件(包括上方的面试解析xmind文档)
除此之外,前文所提及的Alibaba珍藏版 Android框架体系架构 手写文档以及一本 《大话数据结构》 书籍等等相关的学习笔记文档,也皆可分享给认可的朋友!
——感谢大家伙的认可支持,请注意:点赞+点赞+点赞!!!
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!
最后:学习总结——Android框架体系架构知识脑图(纯手绘xmind文档)
学完之后,若是想验收效果如何,其实最好的方法就是可自己去总结一下。比如我就会在学习完一个东西之后自己去手绘一份xmind文件的知识梳理大纲脑图,这样也可方便后续的复习,且都是自己的理解,相信随便瞟几眼就能迅速过完整个知识,脑补回来。
下方即为我手绘的Android框架体系架构知识脑图,由于是xmind文件,不好上传,所以小编将其以图片形式导出来传在此处,细节方面不是特别清晰。但可给感兴趣的朋友提供完整的Android框架体系架构知识脑图原件(包括上方的面试解析xmind文档)
[外链图片转存中…(img-PG1olxKi-1714800563271)]
除此之外,前文所提及的Alibaba珍藏版 Android框架体系架构 手写文档以及一本 《大话数据结构》 书籍等等相关的学习笔记文档,也皆可分享给认可的朋友!
——感谢大家伙的认可支持,请注意:点赞+点赞+点赞!!!
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!