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、启动优化模拟面试
==========
最后
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。
因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
，自己不成体系的自学效果低效漫长且无助**。
因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-TYtUKc2C-1715420926943)]
[外链图片转存中…(img-kV34x6pB-1715420926944)]
[外链图片转存中…(img-2MVE7rp8-1715420926946)]
[外链图片转存中…(img-YHZqBIUi-1715420926947)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
1204
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
