【移动应用开发技术】如何进行iOS 容器化框架的基本思路分析

【移动应用开发技术】如何进行iOS容器化框架的基本思路分析

这期内容当中在下将会给大家带来有关如何进行iOS容器化框架的基本思路分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。前言由本章节开始，我们将从支付宝客户端的架构设计方案入手，细分拆解客户端在“容器化框架设计”、“网络优化”、“性能启动优化”、“自动化日志收集”、“RPC组件设计”、“移动应用监控、诊断、定位”等具体实现，带领大家进一步了解支付宝在客户端架构上的迭代与优化历程。下面将介绍支付宝iOS容器化框架设计的基本思路。容器化实现概览在mPaaS开篇介绍中已经和大家分享过《模块化与解耦式开发在蚂蚁金服mPaaS中的实践》：通过容器化开发框架将业务隔离成相对独立的模块，并着力追求模块与模块之间高内聚、低耦合，因此我们实现了灵活的插件式开发，并得以将业务划分为上千个独立工程。mPaaSiOS框架源自于支付宝客户端，为了实现这种上千个工程之间的低耦合和相关依赖调用，mPaaS框架直接接管了App的生命周期，负责整个App启动托管、App生命周期管理、处理与分发UIApplication的代理事件。mPaaS框架提供了容器化环境，业务开发人员在这个容器化环境中使用微应用和服务进行具体的业务需求开发。微应用和服务是mPaaS框架内定义的概念，主要是用来进行业务模块间的划分。按照是否有UI界面作为标准，mPaaS框架将不同的业务模块划分为微应用和服务。微应用是APP运行期间带有用户界面的业务模块；服务是APP运行期由业务提供的轻量级抽象服务。在mPaaS框架中，通过框架上下文Context进行微应用与服务的生命周期管理。应用生命周期管理通过修改main.m函数的实现，mPaaS框架使用ClientDelegate类接管了UIApplicationDelegate中各种APP生命周期。mPaaS框架接入之后，ClientDelegate完全替代了一般工程中的AppDelegate的角色，从而实现了整个应用的生命周期都是由框架进行管理。为了方便用户获取APP生命周期来开发自定义功能，mPaaS框架提供了DTFrameworkInterface类里面实现了UIApplicationDelegate中所有代理方法的等价接入方式。只需要在DTFrameworkInterface的Category中覆盖对应的方法即可。例如下面常见的UIApplicationDelegate代理方法：在DTFrameworkInterface中都提供了对应的方法：由于mPaaS框架有一些自己的初始化逻辑需要实现，在DTFrameworkInterface中额外提供了beforeDidFinishLaunchingWithOptions和afterDidFinishLaunchingWithOptions方法，方便用户在APP启动时确定的时间执行自己的初始化代码。DTFrameworkInterface在afterDidFinisLaunchingWithOptions之前会启动BootLoader，执行mPaaS框架的初始化逻辑。在嵌入式操作系统中，BootLoader的作用是初始化硬件设备，以便为最终调用操作系统内核准备好正确的环境。类似的在mPaaS框架中，BootLoader用来初始化整个mPaaS框架环境，默认实现为依次执行下面的流程：创建window创建主NavigationController运行那些只运行一次就可以，并且需要率先启动的服务启动其它所有非lazyload的服务启动在ServicesMap的"[AUTOSTART]"数组中指定需要自动启动的服务分组显示主Window启动Launcher微应用，显示出首页这样就完成了mPaaS框架的初始化和首页的显示。后面将详细介绍其中关键的3个概念：微应用、服务、框架上下文Context。微应用微应用就是带UI界面的独立业务模块，其中最特殊的一个微应用是Launcher微应用，Launcher作为APP启动之后第一个打开的微应用，一般用来创建App首页。在mPaaS框架中，各个微应用之间是高度独立、不相互依赖的。微应用通过plist配置来进行注册。配置微应用时需要指定delegate对应的类名、微应用的描述description以及打开微应用时使用的name。这样框架上下文Context通过微应用的name就可以打开指定的微应用。为了方便业务开发，每个微应用也存在生命周期。微应用的生命周期，是模仿iOSAPP的生命周期来做的。每个微应用需要实现自己的DTMicroApplicationDelegate代理，这个类似于iOSApp中实现的Appdelege类。对于具体业务开发而言微应用的开发和一个完整的APP一样，每个微应用负责控制自己应用内的页面堆栈，并根据微应用的生命周期执行相应的操作。在mPaaS框架中，所有的微应用都是运行在mPaaS框架提供的容器中，其不需要关注APP的生命周期。对于一些特殊的业务场景，mPaaS支持创建微应用的多个实例。服务服务与微应用不同地方在于其没有UI界面，是在后台执行。一旦服务启动后，其在整个客户端的生命周期中一直存在，因此服务一般用于给微应用提供通用服务，比如执行某个功能或者获取数据等。一个常见的服务是用户登陆状态服务，每个微应用可以通过这个服务来获取到用户的登录状态和用户信息。服务也是通过plist配置来进行注册。服务注册时需要提供服务的唯一标识name和对应的实现类class类名。框架在创建服务时会利用Objective-C语言的运行时机制创建服务实现类的实例。lazyLoading用来控制是否延迟加载该类。如果是延迟加载，在框架启动时该服务并不会实例化，只有在用到该服务时才会实例化并启动。如果是非延迟加载，则在框架启动时会启动该服务。由于服务的特殊性，在mPaaS中同时提供了ServicesMap来批量注册类，ServicesMap中的[AUTOSTART]用来说明哪些组的服务需要在App启动的时候最先启动。这种分级启动服务的特点可以有效控制APP的启动时间，从而提供很好的用户体验。每个服务都需要实现服务接口:在增加了服务之后，整个App的结构如下图所示。后台的服务成为各个微应用之间沟通的桥梁。框架上下文Context通过前面的介绍，大家已经对微应用和服务有了深入的了解。在mPaaS框架中，框架上下文Context承担了一个调度员的角色，负责各个微应用和服务的调度、通信管理，这样就实现了每个微应用的打开、页面推栈以及关闭不影响APP的其他微应用模块。通过mPaaS框架提供的D