Swift使用SnapKit模仿Kingfisher第三方扩展优化.docxVIP

第

Swift使用SnapKit模仿Kingfisher第三方扩展优化

目录正文SnapKit扩展方式简要思考Kingfisher扩展方式简要思考自行模仿尝试最后

正文

我们平时用swift写第三方扩展(OC中的分类)时，可能会直接就往扩展里面写方法，简单又方便，然而当我们看一些常用你的三方（例如：Kingfisher、SnapKit）等，都会用一个简单的参数引出（例如：kf、snp），下面来探索一下怎么用的，然后在总结其优缺点

SnapKit扩展方式简要思考

以SnapKit为例，使用如下，发现引入了snp

variv=UIImageView();

iv.snp.makeConstraints{makein

中间变量snp如下所示，ConstraintView是统一不同平台的重命名(别名)

publicextensionConstraintView{

varsnp:ConstraintViewDSL{

returnConstraintViewDSL(view:self)

其以前版本也是直接将left等加上前缀snp_，直接调用，而加入前缀我想大家一眼就看出来目的了，没错避免与其他扩展重名，现在也已经改成了引入snp的方式，来间接调用，实际逻辑都通过snp来调用，个人猜测也是借鉴了主流的应用来更新的，调用时，至少分类API整洁了

优缺点：

1、引入中间变量snp之后，首先感觉到的就是，我们的分类在调用的时候，明显没有那么多杂乱的方法了(这种方式OC其实也可以借鉴)2、另外也可以取消了前缀，减少了代码量，并且当与其他类出现重名的时候，只需要替换snp的变量名字即可，不需要替换全部方法，减少了命名阻碍3、不同三方之间通过引入该参数，让我们的调用模块标识更明显，功能模块也更清晰，可维护性更强

Kingfisher扩展方式简要思考

以Kingfisher为例，使用如下，发现引入了kf

variv=UIImageView();

iv.kf.setImage(with:URL(string:))

另外其在使用过程中，通过充分利用swift特性，比SnapKit使用上更优雅高效一些

//声明一个基础协议，必须为AnyObject类型，可用于后续给基础类添加协议

publicprotocolKingfisherCompatible:AnyObject{}

//扩展实现该基础协议，以便于方便让我们的组件能够直接通过.kf直接调用里面的方法

//此kf和snap类似，只不过添加了一个泛型，用于不同类之间进行扩展限制

extensionKingfisherCompatible{

publicvarkf:KingfisherWrapperSelf{

get{returnKingfisherWrapper(self)}

set{}

//通过泛型顶一个一个基础类，通过该基础类可以获取我们被扩展的组件

//且通过该基础类的泛型，可以分别给不同类型添加不同扩展方法

publicstructKingfisherWrapperBase{

publicletbase:Base

publicinit(_base:Base){

self.base=base

//当遵循协议的类为UIImage的时候，为其扩展方法

extensionKingfisherWrapperwhereBase:KFCrossPlatformImage{

//当遵循协议的类为KFCrossPlatformImageView的时候，为其扩展方法

extensionKingfisherWrapperwhereBase:KFCrossPlatformImageView{

//上面仅仅是定义了一个扩展后可以使用的协议，并未应用到我们的基础组件中

//因此只需要给基础组件添加扩展，遵循我们的协议即可

extensionKFCrossPlatformImageView:KingfisherCompatible{}

没见到名字的View是为了不同平台统一名字起的别名，如下所示（打消疑虑专用）

#ifos(iOS)||os(tvOS)

publictypealiasConstraintView=UIView

#else

publictypealiasConstraintView=NSView

#endif

优缺点:

1、引入中间变量