启动优化异步优化

1、

2、

Theme切换的原理是在用户打开应用界面之前，它会首先打开一张图片，这个图片可以是logo页面或者是闪屏页，当activity页面真正展示出来之后，再把theme改变回来。对于冷启动来说，有一步是创建出空白的window出来。这个地方就是利用了这个空白的window。

 

在清单文件中配置该them，这个theme并不是真真正正想在展示的theme，所以需要在真正的theme展示出来之前将它切换回来。时间点就是在super.onCreate()之前将它切换回来。

3、

4、

在启动阶段，最好不要做new Thread()的操作，因为这种方式，第一，它非常粗放，第二，它可能会导致内存泄露；第三，这种方式丝毫没有复用的概念。

线程池的线程数不能随意设置，因为cpu的核心数是一定的，如果创建了过多的线程，而且这些线程都用来做cpu密集性的任务，都需要消耗cpu，那cpu对每个线程其实是公平的，那就是大家来抢占时间片。为了保证公平，它可能采用的方式是每一个线程都执行。那比如80个线程都向cpu来申请时间片，这种情况下其实是加重了cpu的负担。所以，不能放置过多。参考AsyncTask获取线程的核心数。

    private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
    // We want at least 2 threads and at most 4 threads in the core pool,
    // preferring to have 1 less than the CPU count to avoid saturating
    // the CPU with background work
    private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));

创建完线程池后，分别将每个任务都submit一下。如果将所有的任务都统一submit的话，对线程池来说是一种浪费，因为是根据线程核心数来创建的多个线程，但是只使用了一个线程。

通过线程池来执行后，主线程运行速度是非常快的。

 

 

5、

但是，并不是所有的任务都可以放在线程池中去执行，比如在初始化过程中创建了一个handler，如果在主线程中创建是没有问题的，但是在子线程中创建就会出现问题。initStetho()方法放到了线程池中执行，是在子线程。这种场景非常常见，解决办法是，第一种是修改它使它可以进行异步操作，例如这里给它传入一个Looper就可以

 

这样，它就可以运行在异步线程中了。但是，真实场景中，有一部分代码是必须要求运行在主线程中的，针对这种情况就只能采取第二种方案。那就是，针对这部分代码，放弃异步优化的方案。必须让这部分代码存活在主线程当中。

6、

比如initWeex()方法，假如在Splash界面中要使用Weex()中的某个方法，但是initWeex()这个方法是在异步任务当中的，此时并不清楚该异步任务什么时候会结束，很有可能在splash界面中使用的时候，该initWeex()方法还没有结束。这种情况肯定会导致错误。也就是说，某些代码是必须在某个阶段完成的，也就是initWeex()必须在application的oncreate（）方法中结束掉，执行完成，这样才能保证splash界面完成打开之后用到weex，才可以正常运行。

 

解决办法就是，创建一个CountDownLatch,相当于是自己加了一个锁，

 

在onCreate()结束的时候调用await()方法，这个意思是，如果countdownlatch不被满足的话，会在这里一直等待。创建countdownlatch的时候传入的参数是1，也就是需要被满足1次。

 

 

也就是在initWeex()结束时执行countDown()方法被满足一次。就是说，在条件执行完之后，调用countDown()方法，当程序执行到countdownlach.await()方法的时候，会直接跳过去，此时application的onCreate()方法才会真正地执行结束。当走到splash界面，需要使用weex，此时已经保证weex初始化完成了。

7、

8、