Latest 0.1.3
Homepage https://github.com/erduoniba/HDNetworking
License MIT
Platforms ios 8.0
Dependencies AFNetworking, PINCache
Authors

HDDNetworking

基于AFNetworking的v3.1.0进行网络请求,基于PINCache的v3.0.1进行网络数据缓存,支持清除指定url缓存、url及参数组合缓存,通过AFNetworkActivityLogger进行网络log打印。该代码使用灵活的请求方式,不包含任何业务代码,上层支持集中式、分布式网络接口管理方式,在请求前可以对请求进行配置,也支持对网络请求后返回的数据进行统一处理。

一、目的

HDDNetworking是为了实现网络请求而设计,作为整个网络请求中的中间层,底层调用目前主流的 AFNetworking ,当然也可以是 BFNetworking,但是无论是那种,对于上层业务层提供的接口,一直是可靠的、稳定的、方便的、带有缓存的接口,而无需各个业务端用N倍的时间处理底层网络的变更。

二、实现功能

1、多环境切换功能:

支持不同环境,快速切换对应环境的地址,也支持特殊的接口使用特殊环境的地址:

// 业务层代码
self.requestConvertManager = [HDRequestConvertManager sharedInstance];
// 不同环境设置不同的baseURL
self.requestConvertManager.configuration.baseURL = baseURL;

// 特殊的接口需要设置特殊的baseURL
[self.requestConvertManager requestMethod:HDRequestMethodPost
                                    URLString:SHOWAPI_LAUGHTER
                                   parameters:@{@"page" : @(pageIndex), @"maxResult" : @(pageSize)}
                         configurationHandler:^(HDRequestManagerConfig * _Nullable configuration) {
                             configuration.baseURL = otherBaseURL;
                         } cache:^(id  _Nullable responseObject) {
                             NSLog(@"缓存数据");
                             cache(responseObject);
                         } success:^(NSURLSessionTask * _Nullable dataTask, id  _Nullable responseObject) {
                             success(dataTask, responseObject);
                         } failure:^(NSURLSessionTask * _Nullable dataTask, HDError * _Nullable error) {
                             failure(dataTask, error);
                         }];

2、处理多个接口中的通用配置:

通用配置如 请求的头部通用配置请求体的通用配置接口的网络超时时长 等等。

// 业务层代码
self.requestConvertManager = [HDRequestConvertManager sharedInstance];

//通过configuration来设置请求头
NSMutableDictionary *builtinHeaders = [NSMutableDictionary dictionary];
builtinHeaders[@"showapi_appid"] = SHOWAPI_APPID;
builtinHeaders[@"showapi_sign"] = SHOWAPI_SIGN;
self.requestConvertManager.configuration.builtinHeaders = builtinHeaders;

//通过configuration来设置通用的请求体
NSMutableDictionary *builtinBodys = [NSMutableDictionary dictionary];
builtinBodys[@"showapi_appid"] = SHOWAPI_APPID;
builtinBodys[@"showapi_sign"] = SHOWAPI_SIGN;
self.requestConvertManager.configuration.builtinBodys = builtinBodys;

3、处理不同接口,存在的差异性:

这里的差异性比如 接口的网络超时时长数据缓存时长数据缓存协议 等等,其实这里的几个地方,都有默认值,支持差异化请求。

// 业务层代码
self.requestConvertManager = [HDRequestConvertManager sharedInstance];

// 特殊的接口需要设置特殊的baseURL
[self.requestConvertManager requestMethod:HDRequestMethodPost
                                    URLString:SHOWAPI_LAUGHTER
                                   parameters:@{@"page" : @(pageIndex), @"maxResult" : @(pageSize)}
                         configurationHandler:^(HDRequestManagerConfig * _Nullable configuration) {
                           //设置缓存时长为100000秒
                            configuration.resultCacheDuration = 100000;    
                           //优先取缓存数据,不在请求网络数据
                            configuration.requestCachePolicy = HDRequestReturnLoadToCache;    
                         } cache:^(id  _Nullable responseObject) {
                             NSLog(@"缓存数据");
                             cache(responseObject);
                         } success:^(NSURLSessionTask * _Nullable dataTask, id  _Nullable responseObject) {
                             success(dataTask, responseObject);
                         } failure:^(NSURLSessionTask * _Nullable dataTask, HDError * _Nullable error) {
                             failure(dataTask, error);
                         }];

4、对网络请求返回的数据做一层拦截:

这里举例说明一下,就是一些app中,登录态只是持续一段时间的,但是一些接口必须要登录态有效才能访问的,这个时候一般姿势可能是,对这些需要判断登录态的接口的返回数据进行筛选判断,然后再做下一步处理,随着这样的接口满满的变多,就导致搞不清到底这一套判断写在哪里了。可能有遇到过这种情况的老司机选择了在自己封装的网络请求 AFNetworking 那段代码返回的时候统一的加上这层逻辑,这的确是一种省时省力的方式,但是问题就在于老司机做的这层 组件 也被业务代码给玷污了。😂

我的思路其实也是如此,这层拦截的代码也是加在网络请求 AFNetworking 那段代码返回的地方,但是我使用了block,把原始数据回调给业务层本身,也就意味了业务层自己处理自己的拦截。

// 业务层代码
self.requestConvertManager = [HDRequestConvertManager sharedInstance];

//通过configuration来统一处理输出的数据,比如对token失效处理、对需要重新登录拦截
self.requestConvertManager.configuration.resposeHandle = ^id (NSURLSessionTask *dataTask, id responseObject) {
    responseObject = [responseObject doSomething];
    return responseObject;
};

//HDRequestConvertManager.m
self.requestManager = [AFHTTPSessionManager manager];
[self.requestManager dataTaskWithRequest:request
completionHandler:^(NSURLResponse * _Nonnull response, id  _Nullable responseObject, NSError * _Nullable error) {
    __strong typeof(self) strong_self = weak_self;
    if (error) {

    }
    else {
        //如果业务层需要拦截,则先将返回的数据抛给业务层先处理
        if (configuration.resposeHandle) {
            responseObject = configuration.resposeHandle(dataTask, responseObject);
        }
        success(dataTask, responseObject);
    }
}];

5、网络数据缓存策略

HDDNetworking

缓存这块使用的是 PINCache ,策略分了四种方式,具体可以看上图。

6、log日志的完善机制:

这块使用的是 AFNetworkActivityLogger 这个类来实现,它也是可以根据开发者选择的log等级来打印对应级别的log,支持打印请求的 HTTPMethodURLabsluteString 、网络请求响应的statusCode 、本次请求耗时等等信息,它是利用 AFNetworking 请求发出的通知来实现的,具体看源码。

7、error层的自定义统一管理:

组件中已经包含一个比较基础的 HDError 类,业务层继承这个然后重载如下的两个类方法即可:

+ (HDError *)hdErrorNetNotReachable;
+ (HDError *)hdErrorHttpError:(NSError *)error;

8、网络状态的判断:

这个没有好说的,还是 AFNetworking 那一套:

//HDRequestConvertManager.m
[[AFNetworkReachabilityManager sharedManager] setReachabilityStatusChangeBlock:^(AFNetworkReachabilityStatus status) {
    NSLog(@"Reachability: %@", AFStringFromNetworkReachabilityStatus(status));
    self.networkStatus = status;
}];

9、取消网络请求:

在调用组件中的网络接口时,本身是返回请求的对象 NSURLSessionTask 的,如果需要取消,只需要拿到这个对象,执行 cannel 即可,当然,所有的请求都在 AFNetworking 排好队的,组件也提供接口来取消队列中的所有请求:

//HDRequestConvertManager.m
- (void)cancelAllRequest {
    [self.requestManager invalidateSessionCancelingTasks:YES];
}

三、业务层实现的一些思路

关于采用何种方式,iOS届大神早已分析的很透彻了,比如这里: iOS网络层架构设计分享iOS应用架构谈 网络层设计方案 ,我结合自己的一些经验总结一下

1、集约性Api调用方式:demo中的 HDRequestManager

这个是我一直使用好几年的一种方式了,因为它好用,好管理,看上去很整洁等等,当然在看过上面大神博客才知道它有一个响亮的名字:集约型Api调用方式。因为开发过程中接口相对而言比较少,没有很大的发现,而且每次新的接口中都很方便的看到接口的记录:

#pragma mark - 1.0版本接口 by dlb 2016.05.07 - 2016.05.18
// 首页接口
- (void)homePageSRequest...;
// 广告区接口
- (void)bannerListRequest...;

#pragma mark - 1.1版本接口 2016.05.20 - 2016.06.08
// 图书列表接口
- (void)bookListRequest...;

对于它的缺点,比如当接口很多的时候,或者多人维护时代码提交老是冲突的缺陷,我想说,是有办法解决的,比如使用 Category,😁

HDRequestManager+Home.h
HDRequestManager+Me.h
HDRequestManager+Order.h

2、离散性Api调用方式:demo中的 HDBaseViewModel

这种方式是 casa大神 推荐的一种,它能解决集约型Api请求方式的一些缺陷,比如:针对某个api请求进行AOP时,需要对api进行判断然后AOP;比如api请求还未结束,业务层已经被用户返回释放掉,容易造成的crash等等。

使用 离散性Api调用方式 则能很好的解决这些问题,而且现在随着 MVP、MVVM 等架构的兴起,需要更加独立的model层来进行单元测试,这很合 离散性Api调用方式 的胃口。如何采用 离散性Api调用方式 呢?demo中也有一个简单的例子,看上去是很棒,用起来也很随性。

如果项目中有好几百个api,按照接口有一定的相似度来分析,3个接口对应一个viewModel,无意中变多上上百个类,怎么管理?要分散到各个业务模块吗?

3、如何选择?

按照我的意愿,还是会选择 集约型Api调用方式。原因就是无论viewModel是分散在各个业务模块,还是统一在一块,我都感觉维护起来是一个问题。至于它的缺陷,我想总是有办法解决的 😄 大神轻喷 😄。

四、如何添加到项目中?

先已加入 CocoaPods 套餐,欢迎使用,欢迎大神教育。

Build Status

Version

pod "HDDNetworking"

项目源码地址 欢迎 star

Latest podspec

{
    "name": "HDDNetworking",
    "version": "0.1.3",
    "summary": "u57fau4e8eAFNetworkingu8fdbu884cu7f51u7edcu8bf7u6c42uff0cu57fau4e8ePINCacheu8fdbu884cu7f51u7edcu6570u636eu7f13u5b58u7684u7f51u7edcu8bf7u6c42u7ec4u4ef6",
    "description": "u57fau4e8eAFNetworkingu8fdbu884cu7f51u7edcu8bf7u6c42uff0cu57fau4e8ePINCacheu8fdbu884cu7f51u7edcu6570u636eu7f13u5b58uff0cu652fu6301u6e05u9664u6307u5b9aurlu7f13u5b58u3001urlu53cau53c2u6570u7ec4u5408u7f13u5b58uff0cu901au8fc7AFNetworkActivityLoggeru8fdbu884cu7f51u7edclogu6253u5370u3002u8be5u4ee3u7801u4f7fu7528u7075u6d3bu7684u8bf7u6c42u65b9u5f0fuff0cu4e0du5305u542bu4efbu4f55u4e1au52a1u4ee3u7801uff0cu4e0au5c42u652fu6301u96c6u4e2du5f0fu3001u5206u5e03u5f0fu7f51u7edcu63a5u53e3u7ba1u7406u65b9u5f0fuff0cu5728u8bf7u6c42u524du53efu4ee5u5bf9u8bf7u6c42u8fdbu884cu914du7f6euff0cu4e5fu652fu6301u5bf9u7f51u7edcu8bf7u6c42u540eu8fd4u56deu7684u6570u636eu8fdbu884cu7edfu4e00u5904u7406",
    "homepage": "https://github.com/erduoniba/HDNetworking",
    "license": {
        "type": "MIT",
        "file": "LICENSE"
    },
    "authors": {
        "denglibing": "[email protected]"
    },
    "source": {
        "git": "https://github.com/erduoniba/HDNetworking.git",
        "tag": "0.1.3"
    },
    "social_media_url": "http://blog.csdn.net/u012390519",
    "platforms": {
        "ios": "8.0"
    },
    "public_header_files": "HDNetworking/*.h",
    "source_files": "HDNetworking/*.{h,m}",
    "dependencies": {
        "AFNetworking": [],
        "PINCache": []
    }
}

Pin It on Pinterest

Share This