最近一直在看 @casatwy 的 iOS应用架构谈 网络层设计方案，于是就把手边的两个开源 App 的网络层分析了一遍。

Artsy/eigen

源代码：Artsy/eigen

语言：Objective-C

底层网络库：AFNetworking ~> 2.5

基本结构：

1.png

1，ARNetworkConstants 存放的是 Network 必需的一些常量，比如 baseURL 和 apiURL，

NSString *const ARBaseApiURL = @"https://api.artsy.net";
...
NSString *const ARNewArtworksURL = @"/api/v1/artworks/new";
...

2，ARRouter 是整个网络层的核心，它是一个单例，有一千多行代码，管理着一个 AFHTTPSessionManager，这个 manager 主要用于生成所有 api 的 NSURLRequest，还有开启网络状态监听和 OAuth 认证等功能。

+ (NSURLRequest *)newArtworkInfoRequestForArtworkID:(NSString *)artworkID
{
    NSString *address = [NSString stringWithFormat:ARNewArtworkInfoURLFormat, artworkID];
    return [self requestWithMethod:@"GET" path:address parameters:nil];
}

3，ArtsyAPI 由 ArstyAPI 类和一些 Category 组成，

2.png

它也是一个单例，主要用于将 NSURLRequest 进一步转化为 AFHTTPRequestOperation，发起请求，设置返回回调，并有直接将 JSON 解析为 Model 的逻辑。

// ArtsyAPI.m
- (AFHTTPRequestOperation *)getRequest:(NSURLRequest *)request parseIntoAnArrayOfClass:(Class)klass fromDictionaryWithKey:(NSString *)key success:(void (^)(NSArray *))success failure:(void (^)(NSError *error))failure;
{
  ...
}

// Artist+Artworks.m
+ (void)getArtworkInfo:(NSString *)artworkID success:(void (^)(Artwork *artwork))success failure:(void (^)(NSError *error))failure
{
    NSURLRequest *request = [ARRouter newArtworkInfoRequestForArtworkID:artworkID];
    [self getRequest:request parseIntoAClass:Artwork.class success:success failure:failure];
}

4，最后是 NetWork_Models，

3.png

这一部分不太好理解，字面意思是用于网络的模型，点进一些文件里观察到这些类是对 ArtsyAPI 部分 API 的再封装，主要是为了应对部分发送网络请求时需要调用者自己维护一些变量的情况，如分页 API 的 page 等。

@interface ARWorksForYouNetworkModel ()
@property (readwrite, nonatomic, assign) BOOL allDownloaded;
@property (readwrite, nonatomic, assign) BOOL networkingDidFail;
@property (readwrite, nonatomic, assign) NSInteger currentPage;
@property (atomic, weak) AFHTTPRequestOperation *currentRequest;
@property (readwrite, nonatomic, strong) NSMutableArray *downloadedArtworkIDs;

#ifndef NS_BLOCK_ASSERTIONS
@property (readwrite, nonatomic, strong) NSMutableDictionary *downloadInformation;
#endif

@end

这样一来，Controller 只要持有 network_model 发送请求就行了，不需要去关心具体的逻辑。

5，当然，Mantle_Extensions 自不必说，是对 Mantle 的封装。

总结：

综上所述，Artsy 的网络层应该属于集约型API调用方式，回调是 block，用 model 交付数据。

ello/ello-ios

源代码：ello-ios

语言：Swift

底层网络库： Alamofire ~> 3.0 Moya ~> 6.0.0

基本结构：（因为原代码并没有分 group，截图中的 group 是我后来分类的）

4.png

了解过 Moya 应该知道，它是对 Alamofire 的进一步封装，通过 Swift 的 enum 新特性，对 API 进行统一管理，在实现 TargetType 协议后，就可以通过 Moya 的 Provider 进行网络请求，并且，Moya 还支持还可以快速集成 ReactiveCocoa 和 RxSwift。

了解完这些后，我们来看一下基本结构：

1，API group 包含刚刚说过的实现 TargetType 协议的 ElloAPI 类和一些辅助类，截取其中的部分代码：

extension ElloAPI: Moya.TargetType {
    public var baseURL: NSURL { return NSURL(string: ElloURI.baseURL)! }
    public var method: Moya.Method {
        switch self {
            case .AnonymousCredentials,
                 .Auth,
                 .Availability,
                 .CreateComment,
    ...
    }
    public var path: String {
        switch self {
        case .AmazonCredentials:
            return "/api/\(ElloAPI.apiVersion)/assets/credentials"
        ...
    }
    public var parameters: [String: AnyObject]? {
        switch self {
        case .AnonymousCredentials:
            return [
                "client_id": APIKeys.sharedKeys.key,
                "client_secret": APIKeys.sharedKeys.secret,
                "grant_type": "client_credentials"
            ]
    ...
    }
}

2，Provider 是对 Moya Provider 的封装，定义了 OAuth 认证、返回回调、JSON mapping 以及分页处理等内容。

3，Service 是利用 Provider 进行发送请求的封装，

5.png

比如 PostService 里面，有 loadPost、loadComment 和 loadReplyAll 等方法，把同一类的 API 请求放到一起。在 Controller 中，持有相应的 Service 来发起请求就行了。

4，其他部分都是辅助，这里不再分析。

总结：

通过第三层 Service，可以说 Ello 的网络层是离散型API调用方式，回调同样是 block，然后用 model 交付数据。

结语

可以看到，两个 App 都是采用 block + model 的方式处理数据，而一个是集约型，另一个是离散型，但是 Artsy 的 network_model 又有一些离散型的意思。具体这两种方式的优劣，建议大家去看 casa 的文章，这里只做一些初步的分析。如果以后还看到一些有意思的 App，会继续分析更新。