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

--

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

猜你喜欢

转载自www.cnblogs.com/chengsh/p/9760286.html