临时记录

app的启动流程

（1）启动的起点发生在Launcher活动中，启动一个app说简单点就是启动一个Activity，那么我们说过所有组件的启动，切换，调度都由AMS来负责的，所以第一步就是Launcher响应了用户的点击事件，然后通知AMS

（2）AMS得到Launcher的通知，就需要响应这个通知，主要就是新建一个Task去准备启动Activity，并且告诉Launcher你可以休息了（Paused）；

（3）Launcher得到AMS让自己“休息”的消息，那么就直接挂起，并告诉AMS我已经Paused了；

（4）AMS知道了Launcher已经挂起之后，就可以放心的为新的Activity准备启动工作了，首先，APP肯定需要一个新的进程去进行运行，所以需要创建一个新进程，这个过程是需要Zygote参与的，AMS通过Socket去和Zygote协商，如果需要创建进程，那么就会fork自身，创建一个线程，新的进程会导入ActivityThread类，这就是每一个应用程序都有一个ActivityThread与之对应的原因；

（5）进程创建好了，通过调用上述的ActivityThread的main方法，这是应用程序的入口，在这里开启消息循环队列，这也是主线程默认绑定Looper的原因；

（6）这时候，App还没有启动完，要永远记住，四大组建的启动都需要AMS去启动，将上述的应用进程信息注册到AMS中，AMS再在堆栈顶部取得要启动的Activity，通过一系列链式调用去完成App启动；

View的加载

.通过Activity的setContentView方法间接调用Phonewindow的setContentView（），在PhoneWindow中通过getLayoutInflate（）得到LayoutInflate对象

2.通过LayoutInflate对象去加载View，主要步骤是

（1）通过xml的Pull方式去解析xml布局文件，获取xml信息，并保存缓存信息，因为这些数据是静态不变的

（2）根据xml的tag标签通过反射创建View逐层构建View

（3）递归构建其中的子View，并将子View添加到父ViewGroup中；

RecycleView和ListView

而不同的地方在于，两者的缓存层级不同，ListView只有两层，RecycleView有四级缓存。

    1. mActiveViews和mAttachedScrap功能相似，意义在于快速重用屏幕上可见的列表项ItemView，而不需要重新createView和bindView；

    2. mScrapView和mCachedViews + mReyclerViewPool功能相似，意义在于缓存离开屏幕的ItemView，目的是让即将进入屏幕的ItemView重用；

    3. RecyclerView的优势在于： a.mCacheViews的使用，可以做到屏幕外的列表项ItemView进入屏幕内时也无须bindView快速重用； b.mRecyclerPool可以供多个RecyclerView共同使用，在特定场景下，如viewpaper+多个列表页下有优势.客观来说，RecyclerView在特定场景下对ListView的缓存机制做了补强和完善。

    同时，两者的缓存不同，RecycleView缓存在ViewHolder，可以看作是：View + ViewHolder(避免每次createView时调用findViewById) + flag(标识状态)；

mRecycleView在获取缓存的时候，是通过匹配pos获得目标的位置的缓存，这么做可以不用重新bindView，所以RecycleVIew中通过pos获取的是viewholder，是pos–>（view，holder，flag），flag是判断view是否需要重新bindView。

类加载机制

类的生命周期包括：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)共 7 个阶段，

• 加载是类加载过程的一个阶段，这两个概念一定不要混淆。在加载阶段, 虚拟机需要完成以下三件事情:

（1）通过一个类的全限定名来获取定义此类的二进制字节流。

（2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

（3） 将类的class文件读入内存，并为之创建一个java.lang.Class对象，也就是说当程序中使用任何类时，系统都会为之建立一个java.lang.Class对象, 作为方法区这个类的各种数据的访问入口。

双亲委派

当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。那么有人就有下面这种疑问了？