iOS 组件化实现的一些思路总结

2020-02-21  本文已影响0人  _皮皮_

1.遵循原则

高层依赖底层,下层不能对上层有依赖的关系
这点是基本的设计原则,可以通过依赖倒置来设计。

同层级的模块不依赖或者尽量少依赖
这点同时也是基本的设计原则,可以通过控制反转来设计,典型的就是使用观察者模式来实现同一个层级模块的解耦。

最小知识原则和自完备性
一个独立的模块尽量减少对其他低层模块的依赖,比如一个模块只是依赖低层模块的某个类的方法,不妨把这个方法拷贝到此模块中,如此一来这个模块就具有了更好的自完备性。

2.分层结构

58同城组件化设计和实现的思路

Ⅰ. 基础底层组件
稳定的、和业务无关的组件,这一层就是传说中的技术组件,这些组件在每个应用中基本都会存在,包含了:

底层组件-基础网络库

根据输入输出的思想进行封装,封装变化

不封装的不变的部分:

输入变化的部分包含:

输出变化的部分包含了:

其中输入输出部分有的是可选的,除了定义一个全能的外部接口,需要提供若干个简便外部接口提供个客户端使用:

客户端使用的是简单的请求,只需要调用简单外部接口传递 url参数 而不需要传递 数据类型其他参数数据类型其他参数 这两个参数使用默认值即可。

客户端关系返回数据的错误码或者错误信息,定义一个只包含错误码,错误信息回调的简单接口即可,而不传递JSON数据。

提供给上层的网络请求接口是不变的,用户无需关心网络底层的具体逻辑实现,网络请求底层可以使用系统的URL加载系统,或者使用第三方的封装不会到客户端造成影响。

底层组件-工具类和常用宏

宏定义的分类

字符串处理相关

对象处理相关

设备信息宏:

DEBUG宏

颜色宏定义

宏定义处理注意点

宏定义避免和具体的类有互相依赖的关系
eg.
UtilMacro -> UIUtil -> UtilMacro

宏定义有间接的依赖
eg.
ProductParameter -> UtilMacro -> UIUtil

常用的Category

底层组件-数据库模块

数据库的使用在应用中很常见,主要需要实现以下功能:

具体可以参考iOS 数据库升级数据迁移解决方案

底层组件-基础UI组件

基础的UI组件适用于所有的业务场景的并且支持扩展的UI组件,业务的变化,基础UI组件不能有改动但是可以进行扩展和定制,常用的主要有以下:

底层组件-缓存管理模块

缓存管理有很多的应用场景,比如缓存页面列表、详情页的数据,提高加载数据以达到优化用户体验,需要关注以下几个方面:

Ⅱ. 基础业务层组件
相对稳定的数据提供层,数据提供包含了业务接口或者有包含了缓存读写的服务,这一层就是传说中的业务服务层组件,包含了:

业务组件-接口的封装

接口的封装提供给上层(一般是表现层)提供数据,中心化的网络接口设计,提供的是一个模型对象给上层
更详细的网络层设计可参考:iOS应用架构谈 网络层设计方案

业务组件-第三方分享、登录、支付组件

提供第三方分享、登录、支付的服务,可以扩展自定义的第三方组件,提供以下功能

业务组件-推送通知组件

推送通知在很多业务场景中都有用到,一般滴你的产品有运营管理,推送通知是必须的功能。一个推送管理组件一般包含以下功能:

业务组件-统计打点组件

统计打点也是在很多app(基本所有)中有使用到的,如果没有和业务相关的打点统计、页面统计,最基本的用户新增、流程、日活等基本的数据都依赖于统计打点组件。此外一般的统计打点组件都有crash收集系统,所以这同时是一个很好的BUG反馈工具。统计打点组件一般的有以下功能:

集成方法

集成方法可以选择主流的cocoapods,cocoapods提供的包管理功能十分强大,在开发阶段,可以选择开发库,即把podfile中的某个pod指向为本地podspec文件,这样方便修改。如果库完善的很好了,可以考虑把库做成私有库提交到自己的git系统以供其他项目和其他成员使用,因为篇幅限制,后续会写一篇使用cocoapods做开发库和私有库集成的文章。

使用cocoapods集成实战演练可以看我的这篇文章: iOS 组件化-使用cocoapods集成实战演练

上一篇下一篇

猜你喜欢

热点阅读