6. APP页面启动的流程
App启动主要分为六个阶段：
- 用户点击app之后，Launcher通过Binder进程间通信机制通知ActivityManagerService，它要启动一个Activity；
- ActivityManagerService通过Binder进程间通信机制通知Launcher进入Paused状态；
- Launcher通过Binder进程间通信机制通知ActivityManagerService，它已经进入Paused状态，于是ActivityManagerService就创建一个新的进程，用来启动一个ActivityThread实例，即将要启动的Activity就是在这个ActivityThread实例中运行；
- ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给ActivityManagerService，以便以后ActivityManagerService能够通过这个Binder对象和它进行通信；
- ActivityManagerService通过Binder进程间通信机制通知ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。
- 四大组建的启动都需要AMS去启动，将上述的应用进程信息注册到AMS中，AMS再在堆栈顶部取得要启动的Activity，通过一系列链式调用去完成App启动。
7. 常用数据储存方式
1. 文件储存
例如：ACache缓存类
默认存储路径：/data/data/<PackageName>/files
文件操作模式：MODE_PRIVATE（默认）：覆盖、MODE_APPEND：追加
2. SharedPreferences
默认存储路径：/data/data/<PackageName>/shared_prefs
操作模式：MODE_PRIVATE（默认）：只有当前的应用程序才能对文件进行读写、MODE_MULTI_PROCESS：用于多个进程对同一个SharedPreferences进行读写。
存储数据格式：键值对
3. SQLite数据库存储
4. ContentProvider
5. 网络存储
8. 设计模式
1.单例设计模式
分为懒汉式和饿汉式。
饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了。
多线程安全。缺点是类加载时就初始化，浪费内存。
而懒汉比较懒，只有当调用getInstance的时候，才会去初始化这个单例。
多线程不安全。
注意事项：getInstance() 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成instance 被多次实例化。
2.建造者模式（Builder 模式）
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
Android中大量地方运用到了Builder模式，比如常见的对话框创建。我们也可以利用Builder模式来创建不同属性的实体类，省去复写不同构造方法。
3.观察者模式
Subject被观察者。是一个接口或者是抽象类，定义被观察者必须实现的职责，它必须能动态地增加、取消观察者，管理观察者并通知观察者。
Observer观察者。观察者接收到消息后，即进行update更新操作，对接收到的信息进行处理。
ConcreteSubject具体的被观察者。定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。
ConcreteObserver具体观察者。每个观察者在接收到信息后处理的方式不同，各个观察者有自己的处理逻辑。
Button的点击事件，广播机制，本质上都是观察者模式。还有EventBus。
4.策略模式
在Android里面策略模式的其中一个典型应用就是Adapter，在我们平时使用的时候，一般情况下我们可能继承BaseAdapter，然后实现不同的View返回，GetView里面实现不同的算法。外部使用的时候也可以根据不同的数据源，切换不同的Adapter。
5.工厂模式
工厂模式是创建型模式，使我们常用/常见的模式之一。多用于需要生成复杂对象的地方。
在Android中创建Bitmap对象的时候，例如通过资源id获取Bitmap对象。
9.应用架构
1. MVC
MVC (Model-View-Controller, 模型-视图-控制器)，标准的MVC是这个样子的：
- 模型层 (Model)：业务逻辑对应的数据模型，无View无关，而与业务相关；
- 视图层 (View)：一般使用XML或者Java对界面进行描述；
- 控制层 (Controllor)：在Android中通常指Activity和Fragment，或者由其控制的业务类。
Activity并非标准的Controller，它一方面用来控制了布局，另一方面还要在Activity中写业务代码，造成了Activity既像View又像Controller。因此这种开发方式不太适合Android开发。
2. MVP
MVP (Model-View-Presenter) 是MVC的演化版本，几个主要部分如下：
- 模型层 (Model)：主要提供数据存取功能。网络请求数据。
- 视图层 (View)：处理用户事件和视图。在Android中，可能是指Activity、Fragment或者View。
- 展示层 (Presenter)：负责通过Model存取书数据，连接View和Model，从Model中取出数据交给View。
这里的Model是用来存取数据的，也就是用来从指定的数据源中获取数据，不要将其理解成MVC中的Model。在MVC中Model是数据模型，在MVP中，我们用Bean来表示数据模型。
Model和View不会直接发生关系，它们需要通过Presenter来进行交互。在实际的开发中，我们可以用接口来定义一些规范，然后让我们的View和Model实现它们，并借助Presenter进行交互即可。
3. MVC 和 MVP 的区别
- MVC 中是允许 Model 和 View 进行交互的，而MVP中，Model 与 View 之间的交互由Presenter完成；
- MVP 模式就是将 P 定义成一个接口，然后在每个触发的事件中调用接口的方法来处理，也就是将逻辑放进了 P 中，需要执行某些操作的时候调用 P 的方法就行了。
优点：
- 降低耦合度，实现了 Model 和 View 真正的完全分离，可以修改 View 而不影响 Modle；
- 模块职责划分明显，层次清晰；
- 隐藏数据；
- Presenter 可以复用，一个 Presenter 可以用于多个 View，而不需要更改 Presenter 的逻辑；
- 利于测试驱动开发，以前的Android开发是难以进行单元测试的；
- View 可以进行组件化，在MVP当中，View 不依赖 Model。
缺点：
- Presenter 中除了应用逻辑以外，还有大量的 View->Model，Model->View 的手动同步逻辑，造成 Presenter 比较笨重，维护起来会比较困难；
- 由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁；
- 如果 Presenter 过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密，一旦视图需要变更，那么Presenter也需要变更了。
4. MVVM
MVVM 是 Model-View-ViewModel 的简写。它本质上就是 MVC 的改进版。MVVM 就是将其中的 View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。
- 模型层 (Model)：负责从各种数据源中获取数据；
- 视图层 (View)：在 Android 中对应于 Activity 和 Fragment，用于展示给用户和处理用户交互，会驱动 ViewModel 从 Model 中获取数据；
- ViewModel 层：用于将 Model 和 View 进行关联，我们可以在 View 中通过 ViewModel 从 Model 中获取数据；当获取到了数据之后，通过 DataBinding与视图绑定，来将结果自动刷新到界面上。
DataBinding方便实现MVVM的工具，实现视图和数据双向绑定。
5. MVVM 的优点和缺点
MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model），有几大优点：
- 低耦合：视图（View）可以独立于Model变化和修改，一个 ViewModel 可以绑定到不同的 View 上，当 View 变化的时候 Model 可以不变，当 Model 变化的时候 View 也可以不变。
- 可重用性：你可以把一些视图逻辑放在一个 ViewModel 里面，让很多 view 重用这段视图逻辑。
- 独立开发：开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计。
- 可测试：界面素来是比较难于测试的，而现在测试可以针对 ViewModel 来写。
6.组件化
正常一个App中可以有多个module，但是一般只会有一个module是设置为application的，其他均设置为library，组件化开发就是要每个module都可以运行起来，因此在开发期间每个module均设置为application，发布时再进行合并。
10. 常用框架
1. Lifecycle
Lifecycle是一个类，它持有关于组件（如 Activity 或 Fragment）生命周期状态的信息，并且允许其他对象观察此状态。
2. Livedata
LiveData 是一种可观察的数据存储器类。与常规的可观察类不同，LiveData 具有生命周期感知能力，它遵循其他应用组件（如 Activity、Fragment 或 Service）的生命周期。这种感知能力可确保 LiveData 仅更新处于活跃生命周期状态的应用组件观察者。
两个方法的区别：
postValue方法会运行在主线程
setValue方法会运行在当前线程简单而言，使用postValue方法，调用的mObserver.onChanged()方法会运行在主线程；而setValue方法，调用的mObserver.onChanged()方法则可能会运行在主线程也可能运行在非主线程是当前线程而定。
postValue方法切换线程后最终会调用setValue方法。实例化 - 注册observer - 传值
3. ViewModel
ViewModel的生命周期是从Activity start到finish，中间不管因为配置变更Activity销毁重启多少次，ViewModel都是不会重启的。（所以不能在ViewModel里持有Activity的Context）
4. Retrofit
它是适用于Android和Java的类型安全的HTTP客户端。底层的网络请求默认使用的Okhttp，本身只是简化了用户网络请求的参数配置等，还能与Rxjava相结合，使用起来更加简洁方便。
5. okHttp
创建网络请求实体client->构建真正的网络请求-> 将网络请求方案与真正的网络请求实体结合构成一个请求Call->执行网络请求->处理返回数据->处理Android 平台的线程问题
通过对比我们可以发现：
- OkHttp创建的是OkhttpClient，然而retrofit创建的是Retrofit实例
- 构建蓝色的Requet的方案，retrofit是通过注解来进行的适配
- 配置Call的过程中，retrofit是利用Adapter适配的Okhttp的Call
- 相对okhttp，retrofit会对responseBody进行自动Gson解析
- 相对okhttp，retrofit会自动的完成线程的切换。
6. RxJava
Rxjava是一个用来实现异步的、基于事件的第三方库。
RxJava 有四个基本概念：Observable (可观察者，即被观察者)、 Observer (观察者)、 subscribe (订阅)、事件。Observable 和 Observer 通过 subscribe() 方法实现订阅关系，从而 Observable 可以在需要的时候发出事件来通知 Observer。
7. RxJava+Retrofit+OkHttp
- Retrofit主要负责应用层面的封装，比如：具体的请求、线程切换、数据转换。主要面向开发者，方便使用，比如请求参数，响应数据的处理，错误处理等；
- OkHttp负责请求的过程；
- RxJava负责异步，各种线程之间的切换
