mPass框架使用的目的是想达到高内聚低耦合，项目可以像插座与插头一样实现组合。我理解的是一个插头就是一个独立的业务，这个独立的业务可以看成一个独立的项目，也就是一个独立的模块。mPass就是这个插座，通过mPass这个插座上提供的插孔，把各个独立的业务组合起来。这就像模块化开发么。
初步感觉跟之前用过的组件式思想上有相通的地方。
mPass的iOS的框架，来自于支付宝的iOS客户端。在支付宝上，为了解决上千个工程之间的低耦合和相关依赖调用，mPass直接接管了App的生命周期，负责整个App的启动托管，App的生命周期管理，处理与分发UIApplication的代理事件。
mPass 提供了容器化得环境，业务开发人员在这个容器化得环境中，通过使用服务和微应用来进行具体的业务需求开发。
服务和微应用
- 服务和微应用
我目前的简单理解就是微应用是带UI元素的，在iOS 中我觉得就是View层这部分。服务是不包含UI元素的那部分，是对业务逻辑的抽象。 - 服务，微应用这套架构和mvvm或者VIPER这些设计模式的比较
这个地方需要深入了解使用mPass这个框架之后，才能更好的去深入比较。现在初步看来，我感觉这个服务和微应用的作用就是更好的去对代码分层，把不同功能不同职责的代码，放到更合理的地方，这个和mvvm中强调的页面布局逻辑和数据处理逻辑，业务逻辑分离，目前感觉思想上是类似的。
下面是一张示意图
蚂蚁金服文档里面对服务和微应用给出的定义是：
主要是用来进行业务模块间的划分，按照是否有 UI 界面作为标准，mPaaS 框架将不同的业务模块划分为 微应用 和 服务。微应用 是 APP 运行期间带有用户界面的业务模块；服务 是 App 运行期由业务提供的轻量级抽象服务。在 mPaaS 框架中，通过 框架上下文Context 进行 微应用 与 服务 的生命周期管理。
目前推测，框架上下文context这个中间层，能够接收到UIApplicationDelegate的各种回调，然后在这个中间层里面，可以把这些回调的信息转发出去。
为什么要加这个中间层呢？
我觉得是为了起到一个高内聚的作用，上层的服务或者应用，如果要用到UIApplicationDelegate的回调函数，如果不集中管理，在业务中会写的非常散，不容易管理，通过上下文Context来管理的话，使用起来应该比较统一。
更重要的目的应该是：context是整个框架的控制中心，统一管理各个微应用和服务之间的交互与跳转。
主要负责：
- 提供启动微应用的接口，可通过名字快速查找，关闭，管理微应用的跳转等。
- 提供启动服务的接口，管理服务的注册，发现和反注册。
应用生命周期的管理
整个应用程序的生命周期，由mPass框架进行管理。
1. 为什么APP的生命周期，由mPass框架管理呢？
我目前的感觉是，mPass这个框架就像vue等提供的脚手架，相当于APP是最低成，在上面多了一层是mPass，mPass相当于是对APP上的一层抽象，我们开发的时候，相当于是面向mPass去开发，如果要是仍然要考虑APP的生命周期，那么就是跨层通信了，这个违反了组件化中的不跨层通信的原则。
所以mPass就通过修改main.m的函数实现，mPaaS 框架使用自己的 ClientDelegate 类接管了UIApplicationDelegate 中各种 App 生命周期。ClientDelegate 就代替了mPass中的AppDelegate角色，从而实现了，整个APP的生命周期由框架进行管理。
int main(int argc, char * argv[]) {
@autoreleasepool {
// Now use mPaaS framework
return UIApplicationMain(argc, argv, @"Application", @"ClientDelegate");
}
}
2. ClientDelegate 这个类是怎么具体实现的？
这个问题还不太清楚答案，我觉得不太可能是通过继承，或者监听这种方案，真个跟RunLoop，Runtime结合到一起感觉很复杂。可以后续仔细讨论讨论，研究一下。
3. main函数的这种修改的内部实现逻辑是什么样？
这个地方也不是很确定，感觉就是把两个文件替换了。具体实现细节，也没有想太清楚。
为了方便用户获取App生命周期的开发自定义功能（就是需要在回调的方法里，写具体的业务，比如推送等等业务），PaaS 框架提供了 DTFrameworkInterface 类里面实现了 UIApplicationDelegate 中所有代理方法的等价接入方式，只需要在 DTFrameworkInterface 的 Category 中覆盖对应的方法即可。
疑问：这个DTFrameworkInterface 是怎么实现了UIApplicationDelegate的等价接入方式，还没有想到合适的方案，去实现。而且通过DTFrameworkInterface 的Category覆盖对应的方法这个做法也不太好。
我目前感觉这个解决方法不太好，还没有看源码，也许是我想的思路不对。
由于 mPaaS 框架有一些自己的初始化逻辑需要实现，在 DTFrameworkInterface 中额外提供了 beforeDidFinishLaunchingWithOptions 和 afterDidFinishLaunchingWithOptions 方法，方便用户在 App 启动时确定的时间执行自己的初始化代码。
DTFrameworkInterface 在 afterDidFinishLaunchingWithOptions 之前会启动 BootLoader，执行 mPaaS 框架的初始化逻辑。在嵌入式操作系统中，BootLoader 的作用是初始化硬件设备，以便为最终调用操作系统内核准备好正确的环境。类似的在 mPaaS 框架中，BootLoader用来初始化整个 mPaaS 框架环境，默认实现为依次执行下面的流程：
- 创建window
- 创建主NavigationController
- 运行那些只运行一次就可以，并且需要率先启动的服务
- 启动其它所有非lazyload的服务
- 启动在ServicesMap的"[AUTOSTART]"数组中指定需要自动启动的服务分组
- 显示主Window
- 启动 Launcher 微应用，显示出首页
（未完待续）
