iOS组件化之路(一)

写在最前

从开始学写代码，胡乱的看书，不懂如何写第一个程序，到开始写出第一个程序，这段道路有些漫长。慢慢开始自己独立的去分析给出的需求，到如何实现，最初的想法只是仅仅实现，到后来懂得如何利用自己技术和经验去解耦合。自从踏上移动端iOS开发的道路，就开始用过往的技术和经验去解耦合的道路，也看过各个论坛大牛的各种得意之作。总想着自己造个轮子，虽然不及前人优秀，总会从实践中提升自身的技术素养，也算是提高自身水平的一次次尝试吧。

初尝试

　　任何软件开发都需要一系列的入口(通常应该是main函数吧)，而以往开发，会随着业务需求的增加使入口不断的膨胀，而且各个业务之间耦合的极其严重，到最后不得不去重构甚至重写代码。

iOS App经过系统创建进程以及一些列动作后，会交给UIApplicatonDelegate代理，而很多情况下，在代理中大量的冗余臃肿的代码使维护用来越难以梳理。我要解决的痛点是避免UIApplicatioinDelegate实现类的臃肿与冗余，各个模块视图之间实现松散的耦合，内部可以实现强聚合。

我的想法使构建一个封闭的UIApplicationDelegate代理对象(私有实现)，通过两个配置文件和一个中心对象(EZAppEngine)来接管App控制权，在一个配置文件中基于JSON格式来生产根控制器以及根UIWindow对象，另一个配置文件(plist,以后的打算自己生产一个格式)来配置实现了给定接口(这里使OC的协议)的类。然后将UIApplicationDelegate得不同方法拆分成不同协议，这样子解决了UIApplicationDelegate本身的臃肿和冗余问题。接下来还有一个问题，就是各个页面(视图控制器和模态视图)之间解耦合，最初我使用一个封装的对象，通过传入类名和初始化方法以及参数，来创建页面，最终使用视图控制器来确定如何显示，这个方法虽然减少依赖，但是还是不够完善。路由思想本身来自Web端的工程，不同的路径请求被Web服务器分发到各个执行的类中，iOS也可以利用这种思想实现解耦合，并可以跟好解决了WebView和Navtive交互的问题。CocoaPods的出现通过依赖管理以及模块的路由机制，很好的解决解耦合、模块复用的问题，通过自动化CI，可以很容易的将各个不同的模块构建一个新的App.

模块化+POD私有库/公有库+CI总体结构

模块化结构

我定义了抽象的工具(EZToolUtilites), 网络封装(EZServiceUtilites), 核心(EZAppUtitlies)私有库，EZAppEngine中包含了接口协议定义以及对配置文件的解析，默认会使用当前{Target}.json和{Target}.plist，来完成启动工作，另外还定义了项目中经常使用的视图、视图控制器的类库。

接下来会通过合适的粒度对业务模块进行模块拆分，这个需要一定经验，对于产品可能不停的迭代和完善的过程。

胡乱写这么多，接下来继续完善自己的思路。:P

--

学无止境，逆水行舟不进则退，给自己加油！！！！！