苹果APNs’ device token特性和过期更新

APNs全名是Apple Push Notification Service。用iPhone的应该都习惯了,每次安装完一个新应用启动后,几乎都会弹出个警告框,“XXX应用”想要给您发送推送通知。这个警告框的权限申请就是为了APNs推送,用户授权后,应用提供商就可以通过APNs给用户推送消息。
APNs的工作机制简单来说可以分为两步,第一步是注册推送服务从APNs获取device token来告知应用提供商服务端,第二步是应用提供商服务端通过APNs给设备推送消息,device token是作为设备的唯一标示。

上图就是device token生成的一个过程。我们以第一次安装启动360儿童卫士应用为例,首先应用会弹出个警告框,请求用户允许发送推送通知,用户允许后–>儿童卫士会向系统注册推送服务,系统接到注册请求后就会自动连接APNs服务器请求获取设备令牌(即device token)–>APNs服务器生成包含device id的device token并下发给设备–>儿童卫士接受到device token,保存在本地同时发送给儿童卫士服务器,到此第一步就完成了。

上图就是推送消息的示图了,设备通过device token和APNs服务器保持连接状态。还以360儿童卫士为例,当孩子到家了,儿童卫士服务器就需要发到达提醒给家长。这时儿童卫士服务器就会通过device token作为目的设备标示来推送加密的到达提醒消息给APNs,APNs解密后再根据device token推送给指定设备。这样,一次推送就完成了。
了解了APNs工作机制,很明显能够看到device token在其中起了至关重要的串联指向作用。如果device token错误或缺失,推送就无法送达目标设备了。所以测试也罢开发也好,都很有必要了解一下device token的一些特性:

  1. 每个device token都是唯一的,只会对应一台设备。
  2. device token与设备系统相关(注意不是和设备绑定的!详解见后文),同一设备系统上不同应用获取的token是同一个。
  3. 应用卸载重新安装,获取到的device token不会变化,而且不会再弹出推送权限申请的弹窗,会自动继承前一次安装的设置信息。这个特性容易引发一些安全问题,用户卸载重新安装一个应用后,还没有登录应用,就可能接到上次登录帐号的推送消息了。我使用iPhone QQ和Skype都碰到过这种情况。客户端没有办法处理这个问题,因为被卸载时客户端是没法做出反应来通知服务器的。苹果有一个feedback的机制可以解决这个问题,苹果为每个应用程序维护了一个不断更新的推送失败的设备列表。服务端可以去定期检查并更新推送设备列表,这样能解决大部分问题,也能减少不必要的报文开销。
  4. 第三点客户端不能处理,但退出登录通知服务器就是客户端的工作了。用户退出登录客户端时,客户端应该告知服务器,停止对这个设备继续推送用户退出登录帐号的消息了。这点应该不算device token的特性了,是一个标准处理方法。 相信很多人都有这样一个疑问,作为一个设备推送的唯一标示,device token是否会变化或者过期呢?苹果在这点上有些含糊其辞,只是在官方文档上建议开发者在每次启动应用时应该都向APNs获取device token并上传给服务器。从这句话来看,device token是会变化的,不然不用每次启动都去获取。

因为苹果官方没有给出明确的device token变化的情况,所以以下列举的都是一些前人总结的经验,主要援引了stackoverflow上关于这个问题一个回答,回答者称是和苹果的一个工程师交流及自己实验得出的结果。

  1. 升级系统device token有可能变化,确认的是升级到iOS5会变化,猜测是升级大的系统版本后device token会变化。
  2. 抹掉所有内容和设置,reset设备后,device token会变化。
  3. 恢复一个非本机的备份后,device token会变化。
  4. device token会过期,这个众说纷纭,有说是半年的,有说一年,有说两年的,不过会过期应该是确凿的。
  5. 备份或者恢复本机的备份,device token不会变化。 所以保险起见,按照苹果的每次启动应用时检查device token并发送到服务器是比较稳妥的做法。
2016/6/7 posted in  苹果开发

HTTP 常用 Header 讲解

1、HTTP请求协议名://主机名:端口号/资源URI

*******************************
GET /index.html HTTP/1.1
Host: localhost:8088
connection: Keep-Alive

******************************/

2、request headerHost, 请求头,标名请求主机器名,可为IP也可为域名,http1.1后强制使用,用此请求信息,可在服务端做WEB虚拟机,实现一机多WEB服务
Content-Length,请求、响应体的数据字节大小
Accept-Encoding,请求头,可接受的文本压缩算法,如: gzip, deflate
Accept-Language,请求头,支持语言,客户端浏览器的设置,如:zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
User-Agent,请求头,浏览器信息,如:Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0,细心会注册到IE也会用Mozilla,这是一个历史问题,早期WEB服务器貌似有问题,只支持Mozilla,微软IE做为后起之秀只能伪装成Mozilla
Cookie,请求头,服务器或客户端在上次设置的COOKIE,包括作用域名(.360buy.com),过期时间,键与值。大部分WEB服务器都会在第一次访问时在响应头上加Set-Cookie,如:BAIDUID=49415814CDBBB4CE65EC50EE4BB65E9A:FG=1; expires=Wed, 07-Nov-42 07:03:34 GMT; path=/; domain=.baidu.com
Referer,从一个连接打开一个新页面,新页面的请求一般会加此信息,标名是从哪里跳过来的,所有的页面的打开历史链就可被挖掘出来,有利于分析用户行为与CPS分成
3、reponse headerContent-Type, 响应的数据类型:text/html;charset=gbk
Content-Length,响应的数据体大小
Content-Encoding, 如果为文本、HTML信息,则使用的编码方式
Date, 当前服务器日期
Server, 服务器名
Set-Cookie,第一次访问或服务设置COOKIE时,响应头里会有此信息,如,BAIDUID=49415814CDBBB4CE65EC50EE4BB65E9A:FG=1; expires=Wed, 07-Nov-42 07:03:34 GMT; path=/; domain=.baidu.com
4、 Cache-Control , Expires控制缓存的两个响应头,如果都出现在响应头里,按Cache-Controler计算
Cache-Control,为响应头信息,取值为:
Public,当前系统任何登录的用户都可使用
Private,当前系统登录的此用户进行缓存
no-cache,不做缓存
max-age,缓存指定秒数,如Cache-control: max-age=5,表示当访问此网页后的5秒内再次访问不会去服务器
Expires,为响应头,Http1.1以上版本,与Max-Age一样,用来控制缓存
5、 Last-Modified, If-Modified-Since
Last-Modified, 为响应头,标名本资料上一次的修改时间
If-Modified-Since,为请求头,把上一次请求的Last-Modified日期信息为值进行请求,如果服务器判断Last-Modified时间与服务器一致则直接返回304,浏览器使用本地缓存进行显示。一般用来节省带宽,加速请求与显示。
6、ETag + If-Match同样是缓存策略,做为以上的补充
ETag,为响应头,在 http1.1中规定为一个字串,具体格式未定义,用来校验客户端缓存
If-Match,为请求头信息,把上一次请求响应的Etag带上进行请求,服务端的处理方法比较灵活,做为Cache-Control,Expires,Last-Modified的补充,可不以时间为参考的缓存策略。
Apache默认对html的Etag取值为INode+Mtime+Size
如:Etag”2e681a-6-5d044840″1
用途:
• a,仅仅改变的修改时间,但内容未做修改
• b,修改非常频繁,一秒内修改千次,但Cache-Control与Last-Modified,只能控制在秒级,这是对控制力度的进一步提升
• c,某些服务器不能精确的得到文件的最后修改时间,个例,我们使用的服务器都已支持,所以所用不多。
7、Connection Keep-AliveHTTP协议采用TCP协议,每次页面资源请求都被规定为一次连接,而每次连接的TCP三次握手关闭时的四次通信与端口滞留等待防止数据包未传送,
而每个TCP都是一个打开文件IO句柄数,Unix/Linux又对这个做了严格的限制。
一个网页,大量资源文件(html\css\javascript\image)需要加载量时需要大数据量的TCP连接,为了减少socket连接数提供了KeepAlive,使一个tcp连接可重复使用。
事实也证明用Keep-Alive速度也更快(但移动客户端接口开发会关掉此属性)。
8、Range: 10-100取信息的一部分,断点下载时常用
9、返回状态码
200,返回成功
501,服务器内容错误
304,使用本地缓firebug
404,资源没有找到
10、http 协议监察工具:
Firebox:httpfox、live http header,firebug
IE:httpwatch、iehttpheader

2016/5/23 posted in  苹果开发

Block在Objective-C中的声明

From:How Do I Declare A Block in Objective-C?

简单翻译一下:

作为本地变量的声明方法:

returnType (^blockName)(parameterTypes) = ^returnType(parameters) {...};

属性的声明:

@property (nonatomic, copy, nullability) returnType (^blockName)(parameterTypes);

作为方法的参数声明:

- (void)someMethodThatTakesABlock:(returnType (^nullability)(parameterTypes))blockName;

作为参数被方法调用的声明:

[someObject someMethodThatTakesABlock:^returnType (parameters) {...}];

作为结构体的声明方法:

typedef returnType (^TypeName)(parameterTypes);
TypeName blockName = ^returnType(parameters) {...};

参考:Apple官方的Block编程指南

2016/5/4 posted in  苹果开发

NSDecimalNumber的用法

加减乘除 解决字符串转float类型不准确 结尾无法去0处理 用于货币处理

    //货币算法 使用NSDecimalNumber 来进行精准计算
    //float  double  在计算时会产生误差
     
    //加法
     
    //声明两个  NSDecimalNumber
    NSDecimalNumber *jiafa1 = [NSDecimalNumber decimalNumberWithString:@"55.55555"];
     
    NSDecimalNumber *jiafa2 = [NSDecimalNumber decimalNumberWithString:@"0.11111"];
     
     
    //加法运算函数  decimalNumberByAdding
    NSDecimalNumber *jiafa = [jiafa1 decimalNumberByAdding:jiafa2];
     
    NSLog(@"加法 %@", jiafa);
     
     
    //减法
     
    //声明两个  NSDecimalNumber
    NSDecimalNumber *jianfa1 = [NSDecimalNumber decimalNumberWithString:@"55.55555"];
     
    NSDecimalNumber *jianfa2 = [NSDecimalNumber decimalNumberWithString:@"0.11111"];
     
     
    //减法运算函数  decimalNumberByAdding
    NSDecimalNumber *jianfa = [jianfa1 decimalNumberBySubtracting:jianfa2];
     
    NSLog(@"减法 %@", jianfa);
     
     
    //乘法
     
    //声明两个  NSDecimalNumber
    NSDecimalNumber *chengfa1 = [NSDecimalNumber decimalNumberWithString:@"55.55555"];
     
    NSDecimalNumber *chengfa2 = [NSDecimalNumber decimalNumberWithString:@"0.11111"];
     
     
    //乘法运算函数  decimalNumberByAdding
    NSDecimalNumber *chengfa = [chengfa1 decimalNumberByMultiplyingBy:chengfa2];
     
    NSLog(@"乘法 %@", chengfa);
     
     
    //除法
     
    //声明两个  NSDecimalNumber
    NSDecimalNumber *chufa1 = [NSDecimalNumber decimalNumberWithString:@"55"];
     
    NSDecimalNumber *chufa2 = [NSDecimalNumber decimalNumberWithString:@"3"];
     
     
    //除法运算函数  decimalNumberByAdding
    NSDecimalNumber *chufa = [chufa1 decimalNumberByDividingBy:chufa2];

2016/4/1 posted in  苹果开发

详解键值观察(KVO)及其实现机理

From:https://mikeash.com/pyblog/friday-qa-2009-01-23.html

一,前言

Objective-C 中的键(key)-值(value)观察(KVO)并不是什么新鲜事物,它来源于设计模式中的观察者模式,其基本思想就是:

一个目标对象管理所有依赖于它的观察者对象,并在它自身的状态改变时主动通知观察者对象。这个主动通知通常是通过调用各观察者对象所提供的接口方法来实现的。观察者模式较完美地将目标对象与观察者对象解耦。

在 Objective-C 中有两种使用键值观察的方式:手动或自动,此外还支持注册依赖键(即一个键依赖于其他键,其他键的变化也会作用到该键)。下面将一一讲述这些,并会深入 Objective-C 内部一窥键值观察是如何实现的。

本文源码下载:点此下载

二,运用键值观察

1,注册与解除注册

如果我们已经有了包含可供键值观察属性的类,那么就可以通过在该类的对象(被观察对象)上调用名为 NSKeyValueObserverRegistration 的 category 方法将观察者对象与被观察者对象注册与解除注册:

- (void)addObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options context:(void *)context;
- (void)removeObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath;

这两个方法的定义在 Foundation/NSKeyValueObserving.h 中,NSObject,NSArray,NSSet均实现了以上方法,因此我们不仅可以观察普通对象,还可以观察数组或结合类对象。在该头文件中,我们还可以看到 NSObject 还实现了 NSKeyValueObserverNotification 的 category 方法(更多类似方法,请查看该头文件):

- (void)willChangeValueForKey:(NSString *)key;
- (void)didChangeValueForKey:(NSString *)key;

这两个方法在手动实现键值观察时会用到,暂且不提。

值得注意的是:不要忘记解除注册,否则会导致资源泄露。

2,设置属性

将观察者与被观察者注册好之后,就可以对观察者对象的属性进行操作,这些变更操作就会被通知给观察者对象。注意,只有遵循 KVO 方式来设置属性,观察者对象才会获取通知,也就是说遵循使用属性的 setter 方法,或通过 key-path 来设置:

[target setAge:30]; 
[target setValue:[NSNumber numberWithInt:30] forKey:@"age"];

3,处理变更通知

观察者需要实现名为 NSKeyValueObserving 的 category 方法来处理收到的变更通知:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context;

在这里,change 这个字典保存了变更信息,具体是哪些信息取决于注册时的 NSKeyValueObservingOptions。

4,下面来看看一个完整的使用示例:

观察者类:

// Observer.h
@interface Observer : NSObject
@end

// Observer.m
#import "Observer.h"
#import <objc/runtime.h>
#import "Target.h"

@implementation Observer

- (void) observeValueForKeyPath:(NSString *)keyPath
                       ofObject:(id)object 
                         change:(NSDictionary *)change
                        context:(void *)context
{
    if ([keyPath isEqualToString:@"age"])
    {
        Class classInfo = (Class)context;
        NSString * className = [NSString stringWithCString:object_getClassName(classInfo)
                                                  encoding:NSUTF8StringEncoding];
        NSLog(@" >> class: %@, Age changed", className);

        NSLog(@" old age is %@", [change objectForKey:@"old"]);
        NSLog(@" new age is %@", [change objectForKey:@"new"]);
    }
    else
    {
        [super observeValueForKeyPath:keyPath
                             ofObject:object
                               change:change
                              context:context];
    }
}

@end

注意:在实现处理变更通知方法 observeValueForKeyPath 时,要将不能处理的 key 转发给 super 的 observeValueForKeyPath 来处理。

使用示例:

Observer * observer = [[[Observer alloc] init] autorelease];

Target * target = [[[Target alloc] init] autorelease];
[target addObserver:observer
         forKeyPath:@"age"
            options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
            context:[Target class]];

[target setAge:30];
//[target setValue:[NSNumber numberWithInt:30] forKey:@"age"];

[target removeObserver:observer forKeyPath:@"age"];

在这里 observer 观察 target 的 age 属性变化,运行结果如下:

  >> class: Target, Age changed

  old age is 10

  new age is 30

三,手动实现键值观察

上面的 Target 应该怎么实现呢?首先来看手动实现。

@interface Target : NSObject
{
    int age;
}

// for manual KVO - age
- (int) age;
- (void) setAge:(int)theAge;

@end

@implementation Target

- (id) init
{
    self = [super init];
    if (nil != self)
    {
        age = 10;
    }
    
    return self;
}

// for manual KVO - age
- (int) age
{
    return age;
}

- (void) setAge:(int)theAge
{
    [self willChangeValueForKey:@"age"];
    age = theAge;
    [self didChangeValueForKey:@"age"];
}

+ (BOOL) automaticallyNotifiesObserversForKey:(NSString *)key {
    if ([key isEqualToString:@"age"]) {
        return NO;
    }

    return [super automaticallyNotifiesObserversForKey:key];
}

@end

首先,需要手动实现属性的 setter 方法,并在设置操作的前后分别调用 willChangeValueForKey: 和 didChangeValueForKey方法,这两个方法用于通知系统该 key 的属性值即将和已经变更了;

其次,要实现类方法 automaticallyNotifiesObserversForKey,并在其中设置对该 key 不自动发送通知(返回 NO 即可)。这里要注意,对其它非手动实现的 key,要转交给 super 来处理。

四,自动实现键值观察

自动实现键值观察就非常简单了,只要使用了属性即可。

@interface Target : NSObject// for automatic KVO - age
@property (nonatomic, readwrite) int age;
@end

@implementation Target
@synthesize age; // for automatic KVO - age

- (id) init
{
    self = [super init];
    if (nil != self)
    {
        age = 10;
    }
    
    return self;
}

@end
 

五,键值观察依赖键

有时候一个属性的值依赖于另一对象中的一个或多个属性,如果这些属性中任一属性的值发生变更,被依赖的属性值也应当为其变更进行标记。因此,object 引入了依赖键。

1,观察依赖键

观察依赖键的方式与前面描述的一样,下面先在 Observer 的 observeValueForKeyPath:ofObject:change:context: 中添加处理变更通知的代码:

#import "TargetWrapper.h"

- (void) observeValueForKeyPath:(NSString *)keyPath
                       ofObject:(id)object 
                         change:(NSDictionary *)change
                        context:(void *)context
{
    if ([keyPath isEqualToString:@"age"])
    {
        Class classInfo = (Class)context;
        NSString * className = [NSString stringWithCString:object_getClassName(classInfo)
                                                  encoding:NSUTF8StringEncoding];
        NSLog(@" >> class: %@, Age changed", className);

        NSLog(@" old age is %@", [change objectForKey:@"old"]);
        NSLog(@" new age is %@", [change objectForKey:@"new"]);
    }
    else if ([keyPath isEqualToString:@"information"])
    {
        Class classInfo = (Class)context;
        NSString * className = [NSString stringWithCString:object_getClassName(classInfo)
                                                  encoding:NSUTF8StringEncoding];
        NSLog(@" >> class: %@, Information changed", className);
        NSLog(@" old information is %@", [change objectForKey:@"old"]);
        NSLog(@" new information is %@", [change objectForKey:@"new"]);
    }
    else
    {
        [super observeValueForKeyPath:keyPath
                             ofObject:object
                               change:change
                              context:context];
    }
}

2,实现依赖键

在这里,观察的是 TargetWrapper 类的 information 属性,该属性是依赖于 Target 类的 age 和 grade 属性。为此,我在 Target 中添加了 grade 属性:

@interface Target : NSObject
@property (nonatomic, readwrite) int grade;
@property (nonatomic, readwrite) int age;
@end

@implementation Target
@synthesize age; // for automatic KVO - age
@synthesize grade;
@end
下面来看看 TragetWrapper 中的依赖键属性是如何实现的。

@class Target;

@interface TargetWrapper : NSObject
{
@private
    Target * _target;
}

@property(nonatomic, assign) NSString * information;
@property(nonatomic, retain) Target * target;

-(id) init:(Target *)aTarget;

@end

#import "TargetWrapper.h"
#import "Target.h"

@implementation TargetWrapper

@synthesize target = _target;

-(id) init:(Target *)aTarget
{
    self = [super init];
    if (nil != self) {
        _target = [aTarget retain];
    }
    
    return self;
}

-(void) dealloc
{
    self.target = nil;
    [super dealloc];
}

- (NSString *)information
{
    return [[[NSString alloc] initWithFormat:@"%d#%d", [_target grade], [_target age]] autorelease];
}

- (void)setInformation:(NSString *)theInformation
{
    NSArray * array = [theInformation componentsSeparatedByString:@"#"];
    [_target setGrade:[[array objectAtIndex:0] intValue]];
    [_target setAge:[[array objectAtIndex:1] intValue]];
}

+ (NSSet *)keyPathsForValuesAffectingInformation
{
    NSSet * keyPaths = [NSSet setWithObjects:@"target.age", @"target.grade", nil];
    return keyPaths;
}

//+ (NSSet *)keyPathsForValuesAffectingValueForKey:(NSString *)key
//{
//    NSSet * keyPaths = [super keyPathsForValuesAffectingValueForKey:key];
//    NSArray * moreKeyPaths = nil;
//    
//    if ([key isEqualToString:@"information"])
//    {
//        moreKeyPaths = [NSArray arrayWithObjects:@"target.age", @"target.grade", nil];
//    }
//    
//    if (moreKeyPaths)
//    {
//        keyPaths = [keyPaths setByAddingObjectsFromArray:moreKeyPaths];
//    }
//    
//    return keyPaths;
//}

@end

首先,要手动实现属性 information 的 setter/getter 方法,在其中使用 Target 的属性来完成其 setter 和 getter。

其次,要实现 keyPathsForValuesAffectingInformation 或 keyPathsForValuesAffectingValueForKey: 方法来告诉系统 information 属性依赖于哪些其他属性,这两个方法都返回一个key-path 的集合。在这里要多说几句,如果选择实现 keyPathsForValuesAffectingValueForKey,要先获取 super 返回的结果 set,然后判断 key 是不是目标 key,如果是就将依赖属性的 key-path 结合追加到 super 返回的结果 set 中,否则直接返回 super的结果。

在这里,information 属性依赖于 target 的 age 和 grade 属性,target 的 age/grade 属性任一发生变化,information 的观察者都会得到通知。

3,使用示例:

Observer * observer = [[[Observer alloc] init] autorelease];
Target * target = [[[Target alloc] init] autorelease];

TargetWrapper * wrapper = [[[TargetWrapper alloc] init:target] autorelease];
[wrapper addObserver:observer
          forKeyPath:@"information"
             options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
             context:[TargetWrapper class]];

[target setAge:30];
[target setGrade:1];
[wrapper removeObserver:observer forKeyPath:@"information"];

输出结果:

 >> class: TargetWrapper, Information changed

  old information is 0#10

  new information is 0#30

  >> class: TargetWrapper, Information changed

  old information is 0#30

  new information is 1#30

 

六,键值观察是如何实现的

1,实现机理

键值观察用处很多,Core Binding 背后的实现就有它的身影,那键值观察背后的实现又如何呢?想一想在上面的自动实现方式中,我们并不需要在被观察对象 Target 中添加额外的代码,就能获得键值观察的功能,这很好很强大,这是怎么做到的呢?答案就是 Objective C 强大的 runtime 动态能力,下面我们一起来窥探下其内部实现过程。

当某个类的对象第一次被观察时,系统就会在运行期动态地创建该类的一个派生类,在这个派生类中重写基类中任何被观察属性的 setter 方法。

派生类在被重写的 setter 方法实现真正的通知机制,就如前面手动实现键值观察那样。这么做是基于设置属性会调用 setter 方法,而通过重写就获得了 KVO 需要的通知机制。当然前提是要通过遵循 KVO 的属性设置方式来变更属性值,如果仅是直接修改属性对应的成员变量,是无法实现 KVO 的。

同时派生类还重写了 class 方法以“欺骗”外部调用者它就是起初的那个类。然后系统将这个对象的 isa 指针指向这个新诞生的派生类,因此这个对象就成为该派生类的对象了,因而在该对象上对 setter 的调用就会调用重写的 setter,从而激活键值通知机制。此外,派生类还重写了 dealloc 方法来释放资源。

如果你对类和对象的关系不太明白,请阅读《深入浅出Cocoa之类与对象》;如果你对如何动态创建类不太明白,请阅读《深入浅出Cocoa 之动态创建类》。

苹果官方文档说得很简洁:

Key-Value Observing Implementation Details

Automatic key-value observing is implemented using a technique called isa-swizzling.

The isa pointer, as the name suggests, points to the object's class which maintains a dispatch table. This dispatch table essentially contains pointers to the methods the class implements, among other data.

When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class. As a result the value of the isa pointer does not necessarily reflect the actual class of the instance.

You should never rely on the isa pointer to determine class membership. Instead, you should use the class method to determine the class of an object instance.

2,代码分析

由于派生类中被重写的 class 对我们撒谎(它说它就是起初的基类),我们只有通过调用 runtime 函数才能揭开派生类的真面目。 下面来看 Mike Ash 的代码:

首先是带有 x, y, z 三个属性的观察目标 Foo:

@interface Foo : NSObject
{
    int x;
    int y;
    int z;
}

@property int x;
@property int y;
@property int z;

@end

@implementation Foo
@synthesize x, y, z;
@end

下面是检验代码:

#import <objc/runtime.h>

static NSArray * ClassMethodNames(Class c)
{
    NSMutableArray * array = [NSMutableArray array];
    
    unsigned int methodCount = 0;
    Method * methodList = class_copyMethodList(c, &methodCount);
    unsigned int i;
    for(i = 0; i < methodCount; i++) {
        [array addObject: NSStringFromSelector(method_getName(methodList[i]))];
    }

    free(methodList);
    
    return array;
}

static void PrintDescription(NSString * name, id obj)
{
    NSString * str = [NSString stringWithFormat:
                      @"\n\t%@: %@\n\tNSObject class %s\n\tlibobjc class %s\n\timplements methods <%@>",
                      name,
                      obj,
                      class_getName([obj class]),
                      class_getName(obj->isa),
                      [ClassMethodNames(obj->isa) componentsJoinedByString:@", "]];
    NSLog(@"%@", str);
}

int main (int argc, const char * argv[])
{
    @autoreleasepool {
        // Deep into KVO: kesalin@gmail.com
        //
        Foo * anything = [[Foo alloc] init];
        Foo * x = [[Foo alloc] init];
        Foo * y = [[Foo alloc] init];
        Foo * xy = [[Foo alloc] init];
        Foo * control = [[Foo alloc] init];
        
        [x addObserver:anything forKeyPath:@"x" options:0 context:NULL];
        [y addObserver:anything forKeyPath:@"y" options:0 context:NULL];
        
        [xy addObserver:anything forKeyPath:@"x" options:0 context:NULL];
        [xy addObserver:anything forKeyPath:@"y" options:0 context:NULL];
        
        PrintDescription(@"control", control);
        PrintDescription(@"x", x);
        PrintDescription(@"y", y);
        PrintDescription(@"xy", xy);
        
        NSLog(@"\n\tUsing NSObject methods, normal setX: is %p, overridden setX: is %p\n",
               [control methodForSelector:@selector(setX:)],
               [x methodForSelector:@selector(setX:)]);
        NSLog(@"\n\tUsing libobjc functions, normal setX: is %p, overridden setX: is %p\n",
               method_getImplementation(class_getInstanceMethod(object_getClass(control),
                                                                @selector(setX:))),
               method_getImplementation(class_getInstanceMethod(object_getClass(x),
                                                                @selector(setX:))));
    }

    return 0;
}

在上面的代码中,辅助函数 ClassMethodNames 使用 runtime 函数来获取类的方法列表,PrintDescription 打印对象的信息,包括通过 -class 获取的类名, isa 指针指向的类的名字以及其中方法列表。

在这里,我创建了四个对象,x 对象的 x 属性被观察,y 对象的 y 属性被观察,xy 对象的 x 和 y 属性均被观察,参照对象 control 没有属性被观察。在代码的最后部分,分别通过两种方式(对象方法和 runtime 方法)打印出参数对象 control 和被观察对象 x 对象的 setX 方面的实现地址,来对比显示正常情况下 setter 实现以及派生类中重写的 setter 实现。

编译运行,输出如下:

control: <Foo: 0x10010c980>

NSObject class Foo

libobjc class Foo

implements methods <x, setX:, y, setY:, z, setZ:>

x: <Foo: 0x10010c920>

NSObject class Foo

libobjc class NSKVONotifying_Foo

implements methods <setY:, setX:, class, dealloc, _isKVOA>

y: <Foo: 0x10010c940>

NSObject class Foo

libobjc class NSKVONotifying_Foo

implements methods <setY:, setX:, class, dealloc, _isKVOA>

xy: <Foo: 0x10010c960>

NSObject class Foo

libobjc class NSKVONotifying_Foo

implements methods <setY:, setX:, class, dealloc, _isKVOA>

Using NSObject methods, normal setX: is 0x100001df0, overridden setX: is 0x100001df0

Using libobjc functions, normal setX: is 0x100001df0, overridden setX: is 0x7fff8458e025

从上面的输出可以看到,如果使用对象的 -class 方面输出类名始终为:Foo,这是因为新诞生的派生类重写了 -class 方法声称它就是起初的基类,只有使用 runtime 函数 object_getClass 才能一睹芳容:NSKVONotifying_Foo。注意看:x,y 以及 xy 三个被观察对象真正的类型都是 NSKVONotifying_Foo,而且该类实现了:setY:, setX:, class, dealloc, _isKVOA 这些方法。其中 setX:, setY:, class 和 dealloc 前面已经讲到过,私有方法 isKVOA 估计是用来标示该类是一个 KVO 机制声称的类。在这里 Objective C 做了一些优化,它对所有被观察对象只生成一个派生类,该派生类实现所有被观察对象的 setter 方法,这样就减少了派生类的数量,提供了效率。所有 NSKVONotifyingFoo 这个派生类重写了 setX,setY方法(留意:没有必要重写 setZ 方法)。

接着来看最后两行输出,地址 0x100001df0 是 Foo 类中的实现,而地址是 0x7fff8458e025 是派生类 NSKVONotifying_Foo 类中的实现。那后面那个地址到底是什么呢?可以通过 GDB 的 info 命令加 symbol 参数来查看该地址的信息:

 (gdb) info symbol 0x7fff8458e025

_NSSetIntValueAndNotify in section LC_SEGMENT.__TEXT.__text of /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation

看起来它是 Foundation 框架提供的私有函数:_NSSetIntValueAndNotify。更进一步,我们来看看 Foundation 到底提供了哪些用于 KVO 的辅助函数。打开 terminal,使用 nm -a 命令查看 Foundation 中的信息:

nm -a /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation

其中查找到我们关注的函数:

00000000000233e7 t __NSSetDoubleValueAndNotify
00000000000f32ba t __NSSetFloatValueAndNotify
0000000000025025 t __NSSetIntValueAndNotify
000000000007fbb5 t __NSSetLongLongValueAndNotify
00000000000f33e8 t __NSSetLongValueAndNotify
000000000002d36c t __NSSetObjectValueAndNotify
0000000000024dc5 t __NSSetPointValueAndNotify
00000000000f39ba t __NSSetRangeValueAndNotify
00000000000f3aeb t __NSSetRectValueAndNotify
00000000000f3512 t __NSSetShortValueAndNotify
00000000000f3c2f t __NSSetSizeValueAndNotify
00000000000f363b t __NSSetUnsignedCharValueAndNotify
000000000006e91f t __NSSetUnsignedIntValueAndNotify
0000000000034b5b t __NSSetUnsignedLongLongValueAndNotify
00000000000f3766 t __NSSetUnsignedLongValueAndNotify
00000000000f3890 t __NSSetUnsignedShortValueAndNotify
00000000000f3060 t __NSSetValueAndNotifyForKeyInIvar
00000000000f30d7 t __NSSetValueAndNotifyForUndefinedKey

Foundation 提供了大部分基础数据类型的辅助函数(Objective C中的 Boolean 只是 unsigned char 的 typedef,所以包括了,但没有 C++中的 bool),此外还包括一些常见的 Cocoa 结构体如 Point, Range, Rect, Size,这表明这些结构体也可以用于自动键值观察,但要注意除此之外的结构体就不能用于自动键值观察了。对于所有 Objective C 对象对应的是 __NSSetObjectValueAndNotify 方法。

七,总结

KVO 并不是什么新事物,换汤不换药,它只是观察者模式在 Objective C 中的一种运用,这是 KVO 的指导思想所在。其他语言实现中也有“KVO”,如 WPF 中的 binding。而在 Objective C 中又是通过强大的 runtime 来实现自动键值观察的。至此,对 KVO 的使用以及注意事项,内部实现都介绍完毕,对 KVO 的理解又深入一层了。Objective 中的 KVO 虽然可以用,但却非完美,有兴趣的了解朋友请查看《KVO 的缺陷》 以及改良实现 MAKVONotificationCenter

八,引用

Key-value observing:官方文档

Key-Value Observing Done Right : 官方 KVO 实现的缺陷

MAKVONotificationCenter : 一个改良的 Notification 实现,托管在 GitHub 上

2016/2/29 posted in  苹果开发

美味不用等4.0版本数据管理类设计简介

Controller-->Manager: Request
Note left of Manager: 多个管理类进行数据处理
Manager->Controller:

Note right of Manager: HTTP,Cache,数据处理
Manager->Controller: Model
Controller->View: Data

一直想总结一下自己对一个项目工程架构的经验,在我看来无论是MVC,还是MVVM,其实都是为了将业务数据与具体的UI分离开,这个UI 不单单是具体的View也是UIController,要达到数据的低耦合,降低各模块的依赖,必须要使用一个中间层来管理和数据处理,一直以来我一直使用MVC的基础设计结构,但是我所理解的与之稍有出入。

MVC的概念指的是模型-控制器-视图,而在我看来,如果单一的使用控制器来管理诸多业务,类似网络请求,缓存,通知等,会造成控制器的臃肿和请求的散乱不便于管理,所以我对M的理解更倾向于Manager,当然在某种程度上也可以理解成为管理类和模型类的结合。管理类负责各工具类的业务调用和对结果数据的封装整理,存储,和下发给控制器,这里工具类是最基础的框架封装,比如工程中的对AFNetworking网络框架的的二次封装NWOperationManager,

Manager管理类

数据请求管理结构

  1. 封装网络请求工具类|NWOperationManager 这里我使用的是AFNetworking作为网络请求框架,继承它进行一些数据的基础封装。

Screen Shot 2016-02-16 at 15.28.45

注:目前该框架使用的是2.6.3,所以依然继承的是AFHTTPRequestOperationManager

其中回调的block为:

//Block
typedef void (^OperationCompleteBlock)(AFHTTPRequestOperation *operation, NWResult *result);

NWResult是针对服务器返回的数据结构的一个最基础的封装:

Screen Shot 2016-02-16 at 15.31.30

  1. 缓存工具类|NWCache NWOperationManager是一个网络请求基础工具类,它实现了网络请求的GET,POST等请求功能,同时也实现了缓存管理,当然如果和服务器进行配合可以较好的实现缓存详情参考:iOS网络缓存扫盲篇,但是目前服务器还未有该功能设计,而且由于该工程在最初的版本的时候是没有缓存设计的,是后来功能需求增加,所以需要一个缓存工具来实现,NWCache缓存设计的初步思想如下:
st=>start: 发起数据请求
e=>end: 数据
op=>operation: 本地缓存
op1=>operation: 发起网络请求
op2=>operation: 存储数据
cond=>condition: 缓存有效?

st->op->cond
cond(yes)->e(left)

cond(no)->op1->e
op1->op2(left)->e

NWCache类包含缓存的存储有效时间,和存储路径等作为最底层的工具封装。在网络模块中缓存的实现是请求工具类中处理的,管理类中只负责具体请求的缓存要求,
在请求工具类中其中一个基础接口是:

- (AFHTTPRequestOperation *)requestURL:(NSString *)URLString
                               inQueue:(dispatch_queue_t)queue
                               inGroup:(dispatch_group_t)group
                            HttpMethod:(HttpMethod)method
                            parameters:(NSDictionary *)parameters
                    cacheBodyWithBlock:(void (^)(id<NWCacheArgumentProtocol> cacheArgumentProtocol))block
                operationCompleteBlock:(OperationCompleteBlock)completeBlock;

NWCacheArgumentProtocol 是一个缓存的配置协议:

@protocol NWCacheArgumentProtocol <NSObject>
- (void)cacheResponseWithIgnoreCache:(BOOL)ignoreCache
                      supportOffLine:(BOOL)supportOffLine
                  cacheTimeInSeconds:(NSInteger)cacheTimeInSeconds;
@end
@interface NWCacheArgument : NSObject<NWCacheArgumentProtocol>
@property (nonatomic, strong, readonly) NSString *key;
/** 忽略缓存直接请求*/
@property (nonatomic, assign) BOOL ignoreCache;
/** 是否支持离线缓存,默认不支持*/
@property (nonatomic, assign) BOOL supportOffLine;
@property (nonatomic, assign) NSInteger cacheTimeInSeconds;

- (id)initWithKey:(NSString *)key;
@end

数据管理类中某一个请求是这样的:

- (void)fetchReferencesShopsWithNextCursor:(NSInteger)nextCursor
                                  useCache:(BOOL)useCache
                               expiredTime:(NSInteger)expiredTime
                             completeBlock:(CompleteBlock)completeBlock

可以看到该方法中有两个参数是有关缓存的,是否缓存和过期时间,在具体实现的时候有一个方法来处理这两个参数

#pragma mark private base method
- (void)httpRequestMethod:(HttpMethod)method
                      url:(NSString *)url
               parameters:(NSDictionary *)parameters
                 useCache:(BOOL)useCache
              expiredTime:(NSInteger)expiredTime
     requestCompleteBlock:(RequestCompleteBlock)requestCompleteBlock{
    AFHTTPRequestOperation *opreration = nil;
    NSMutableDictionary *param = [self commonArgumentWithUserParameters:parameters];
    DDLogInfo(@"%@:%@",url,param);
    opreration = [[NWOperationManager sharedClient] requestURL:url
                                                       inQueue:self.httpRequest_queue_t
                                                       inGroup:self.httpRequest_group_t
                                                    HttpMethod:method
                                                    parameters:param
                                            cacheBodyWithBlock:^(id<NWCacheArgumentProtocol> cacheArgumentProtocol) {
                                                [cacheArgumentProtocol cacheResponseWithIgnoreCache:!useCache supportOffLine:YES cacheTimeInSeconds:expiredTime];
                                            } operationCompleteBlock:^(AFHTTPRequestOperation *operation, NWResult *result) {
                                                [self requestURI:url operationCompleteBlock:requestCompleteBlock result:result];
                                                DDLogInfo(@"%@:%@",url,result.response);
                                            }];
}

cacheBodyWithBlock该Block就是配置该请求的缓存设置的,

该设计在没有大改早先控制器方法调用的基础上只是修改了 管理类的请求工具调用和增加缓存工具类就实现了自定义的网络请求缓存,目前还能够满足需求。

当然在具体实现中遇到的一些问题是要避免的,首先在缓存数据的时候是有一个Key是很关键的,该key由接口和识别参数,是该参数是需要注意分页中的页码和诸如经纬度等,避免出错。

总之数据管理类的功能是管理和处理数据请求的,解放控制器,让控制器不再进行数据逻辑处理,控制器只负责简单的数据请求,它只要数据不必管这个数据是来自缓存还是来此云端。数据管请求工具返回的数据是简单封装的原始数据(NWResult),然后数据管理进行数据的再封装转为model返回给控制器,当要进行UI展示的时候将数据传输给视图View,这里的数据不建议是model传输,因为要保证解耦,不能让视图与model过多的联系,所以建议以原始数据的形式进行传输。

2016/2/16 posted in  苹果开发

HTTP状态码汇总

一:1️⃣❌❌ 🔴🔴🔴

1xx消息这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送1xx响应。 这些状态码代表的响应都是信息性的,标示客户应该采取的其他行动。

100 | Continue

客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。

101 | Switching Protocols

服务器已经理解了客户端的请求,并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在Upgrade消息头中定义的那些协议。: 只有在切换新的协议更有好处的时候才应该采取类似措施。例如,切换到新的HTTP版本比旧版本更有优势,或者切换到一个实时且同步的协议以传送利用此类特性的资源。

102 | Processing

由WebDAV(RFC 2518)扩展的状态码,代表处理将被继续执行。

二:2️⃣❌❌ | 🔴🔴🔴

2xx成功 这一类型的状态码,代表请求已成功被服务器接收、理解、并接受。

200 | OK

请求已成功,请求所希望的响应头或数据体将随此响应返回。

201 | Created

请求已经被实现,而且有一个新的资源已经依据请求的需要而创建,且其URI已经随Location头信息返回。假如需要的资源无法及时创建的话,应当返回'202 Accepted'。

202 | Accepted

服务器已接受请求,但尚未处理。正如它可能被拒绝一样,最终该请求可能会也可能不会被执行。在异步操作的场合下,没有比发送这个状态码更方便的做法了。:返回202状态码的响应的目的是允许服务器接受其他过程的请求(例如某个每天只执行一次的基于批处理的操作),而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息,以及指向处理状态监视器或状态预测的指针,以便用户能够估计操作是否已经完成。

203 | Non-Authoritative Information

服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合,而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如,包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的,而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。

204 | No Content

服务器成功处理了请求,但不需要返回任何实体内容,并且希望返回更新了的元信息。响可能通过实体头部的形式,返回新的或更新后的元信息。如果存在这些头部信息,则应当与所请求的变量相呼应。如果客户端是浏览器的话,那么用户浏览器应保留发送了该请求的页面,而不产生任何文档视图上的变化,即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。由于204响应被禁止包含任何消息体,因此它始终以消息头后的第一个空行结尾。

205 | Reset Content

服务器成功处理了请求,且没有返回任何内容。但是与204响应不同,返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后,立即重置表单,以便用户能够轻松地开始另一次输入。与204响应一样,该响应也被禁止包含任何消息体,且以消息头后的第一个空行结束。

206 | Partial Content

服务器已经成功处理了部分GET请求。类似于FlashGet或者迅雷这类的HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。该请求必须包含Range头信息来指示客户端希望得到的内容范围,并且可能包含If-Range来作为请求条件。
响应必须包含如下的头部域:Content-Range用以指示本次响应中返回的内容的范围;如果是Content-Typemultipart/byteranges的多段下载,则每一multipart段中都应包含Content-Range域用以指示本段的内容范围。假如响应中包含Content-Length,那么它的数值必须匹配它返回的内容范围的真实字节数。
Date ETagContent-Location,假如同样的请求本应该返回200响应。
Expires, Cache-Control,和Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话。假如本响应请求使用了If-Range强缓存验证,那么本次响应不应该包含其他实体头;假如本响应的请求使用了If-Range弱缓存验证,那么本次响应禁止包含其他实体头;这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则,本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。假如ETag或Last-Modified头部不能精确匹配的话,则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。任何不支持Range以及Content-Range头的缓存都禁止缓存206响应返回的内容。

207 | Multi-Status

由WebDAV(RFC 2518)扩展的状态码,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。

三:3️⃣❌❌ | 🔴🔴🔴

3xx重定向 这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的Location域中指明。当且仅当后续的请求所使用的方法是GET或者HEAD时,用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向(例如:A→B→C→……→A或A→A),因为这会导致服务器和客户端大量不必要的资源消耗。按照HTTP/1.0版规范的建议,浏览器不应自动访问超过5次的重定向。

300 | Multiple Choices

被请求的资源有一系列可供选择的回馈信息,每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。除非这是一个HEAD请求,否则该响应应当包括一个资源特性及地址的列表的实体,以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由Content-Type定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力,自动作出最合适的选择。当然,RFC 2616规范并没有规定这样的自动选择该如何进行。如果服务器本身已经有了首选的回馈选择,那么在Location中应当指明这个回馈的URI;浏览器可能会将这个Location值作为自动重定向的地址。此外,除非额外指定,否则这个响应也是可缓存的。

301 | Moved Permanently

被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。如果这不是一个GET或者HEAD请求,因此浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。注意:对于某些使用HTTP/1.0协议的浏览器,当它们发送的POST请求得到了一个301响应的话,接下来的重定向请求将会变成GET方式。

302 | Found

请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。如果这不是一个GET或者HEAD请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。注意:虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法,但是很多现存的浏览器将302响应视作为303响应,并且使用GET方式访问在Location中规定的URI,而无视原先请求的方法。状态码303和307被添加了进来,用以明确服务器期待客户端进行何种反应。

303 | See Other

对应当前请求的响应可以在另一个URI上被找到,而且客户端应当采用GET的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时,303响应禁止被缓存。当然,第二个请求(重定向)可能被缓存。新的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。注意:许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动,302状态码应该可以胜任,因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。

304 | Not Modified

如果客户端发送了一个带条件的GET请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个状态码。304响应禁止包含消息体,因此始终以消息头后的第一个空行结尾。 该响应必须包含以下的头信息:Date,除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则,那么代理服务器以及客户端可以自行将Date字段添加到接收到的响应头中去(正如RFC 2068中规定的一样),缓存机制将会正常工作。ETag和/或Content-Location,假如同样的请求本应返回200响应。Expires, Cache-Control,和Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话。假如本响应请求使用了强缓存验证,那么本次响应不应该包含其他实体头;否则(例如,某个带条件的GET请求使用了弱缓存验证),本次响应禁止包含其他实体头;这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。假如某个304响应指明了当前某个实体没有缓存,那么缓存系统必须忽视这个响应,并且重复发送不包含限制条件的请求。假如接收到一个要求更新某个缓存条目的304响应,那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。

305 | Use Proxy

被请求的资源必须通过指定的代理才能被访问。Location域中将给出指定的代理所在的URI信息,接收者需要重复发送一个单独的请求,通过这个代理才能访问相应资源。只有原始服务器才能创建305响应。注意:RFC 2068中没有明确305响应是为了重定向一个单独的请求,而且只能被原始服务器创建。忽视这些限制可能导致严重的安全后果。

306 | Switch Proxy

在最新版的规范中,306状态码已经不再被使用。

307 | Temporary Redirect

请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。因为部分浏览器不能识别307响应,因此需要添加上述必要信息以便用户能够理解并向新的URI发出访问请求。如果这不是一个GET或者HEAD请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。

四:4️⃣❌❌ | 🔴🔴🔴

4xx客户端错误这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。除非响应的是一个HEAD请求,否则服务器就应该返回一个解释当前错误状况的实体,以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。如果错误发生时客户端正在传送数据,那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前,客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据,服务器的TCP栈将向客户端发送一个重置数据包,以清除该客户端所有还未识别的输入缓冲,以免这些数据被服务器上的应用程序读取并干扰后者。

400 | Bad Request

由于包含语法错误,当前请求无法被服务器理解。除非进行修改,否则客户端不应该重复提交这个请求。

401 | Unauthorized

当前请求需要用户验证。该响应必须包含一个适用于被请求资源的WWW-Authenticate信息头用以询问用户信息。客户端可以重复提交一个包含恰当的Authorization头信息的请求。如果当前请求已经包含了Authorization证书,那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。

402 | Payment Required

该状态码是为了将来可能的需求而预留的。

403 | Forbidden

服务器已经理解请求,但是拒绝执行它。与401响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个HEAD请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应,假如它不希望让客户端获得任何信息。

404 | Not Found

请求失败,请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话,应当使用410状态码来告知旧资源因为某些内部的配置机制问题,已经永久的不可用,而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。

405 | Method Not Allowed

请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow头信息用以表示出当前资源能够接受的请求方法的列表。鉴于PUT,DELETE方法会对服务器上的资源进行写操作,因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法,对于此类请求均会返回405错误。

406 | Not Acceptable

请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体。除非这是一个HEAD请求,否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由Content-Type头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是,规范中并没有定义任何作出此类自动选择的标准。

407 | Proxy Authentication Required

与401响应类似,只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个Proxy-Authenticate用以进行身份询问。客户端可以返回一个Proxy-Authorization信息头用以验证。参见RFC 2617。

408 | Request Timeout

请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。

409 | Conflict

由于和被请求的资源的当前状态之间存在冲突,请求无法完成。这个代码只允许用在这样的情况下才能被使用:用户被认为能够解决冲突,并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。冲突通常发生于对PUT请求的处理中。例如,在采用版本检查的环境下,某次PUT提交的对特定资源的修改请求所附带的版本信息与之前的某个(第三方)请求向冲突,那么此时服务器就应该返回一个409错误,告知用户请求无法完成。此时,响应实体中很可能会包含两个冲突版本之间的差异比较,以便用户重新提交归并以后的新版本。

410 | Gone

被请求的资源在服务器上已经不再可用,而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能,拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的,那么就应该使用404状态码。除非额外说明,否则这个响应是可缓存的。410响应的目的主要是帮助网站管理员维护网站,通知用户该资源已经不再可用,并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样,410响应也被用于通知客户端在当前服务器站点上,原本属于某个个人的资源已经不再可用。当然,是否需要把所有永久不可用的资源标记为'410 Gone',以及是否需要保持此标记多长时间,完全取决于服务器拥有者。

411 | Length Required

服务器拒绝在没有定义Content-Length头的情况下接受请求。在添加了表明请求消息体长度的有效Content-Length头之后,客户端可以再次提交该请求。

412 | Precondition Failed

服务器在验证在请求的头字段中给出先决条件时,没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息(请求头字段数据)中设置先决条件,以此避免该请求方法被应用到其希望的内容以外的资源上。

413 | Request Entity Too Large

服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下,服务器可以关闭连接以免客户端继续发送此请求。如果这个状况是临时的,服务器应当返回一个Retry-After的响应头,以告知客户端可以在多少时间以后重新尝试。

414 | Request-URI Too Long

请求的URI长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务。这比较少见,通常的情况包括:本应使用POST方法的表单提交变成了GET方法,导致查询字符串(Query String)过长。重定向URI“黑洞”,例如每次重定向把旧的URI作为新的URI的一部分,导致在若干次重定向后URI超长。客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的URI,当GET后的参数超过某个数值后,可能会产生缓冲区溢出,导致任意代码被执行[1]。没有此类漏洞的服务器,应当返回414状态码。

415 | Unsupported Media Type

对于当前请求的方法和所请求的资源,请求中提交的实体并不是服务器中所支持的格式,因此请求被拒绝。

416 | Requested Range Not Satisfiable

如果请求中包含了Range请求头,并且Range中指定的任何数据范围都与当前资源的可用范围不重合,同时请求中又没有定义If-Range请求头,那么服务器就应当返回416状态码。假如Range使用的是字节范围,那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时,包含一个Content-Range实体头,用以指明当前资源的长度。这个响应也被禁止使用multipart/byteranges作为其Content-Type

417 | Expectation Failed

在请求头Expect中指定的预期内容无法被服务器满足,或者这个服务器是一个代理服务器,它有明显的证据证明在当前路由的下一个节点上,Expect的内容无法被满足。

418 | I'm a teapot

本操作码是在1998年作为IETF的传统愚人节笑话, 在RFC 2324 超文本咖啡壶控制协议中定义的,并不需要在真实的HTTP服务器中定义。

421 | There are too many connections from your internet address

从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常,这里的IP地址指的是从服务器上看到的客户端地址(比如用户的网关或者代理服务器地址)。在这种情况下,连接数的计算可能涉及到不止一个终端用户。

422 | Unprocessable Entity

请求格式正确,但是由于含有语义错误,无法响应。(RFC 4918 WebDAV)

423 | Locked

当前资源被锁定。(RFC 4918 WebDAV)

424 | Failed Dependency

由于之前的某个请求发生的错误,导致当前请求失败,例如PROPPATCH。(RFC 4918 WebDAV)

425 | Unordered Collection

在WebDav Advanced Collections草案中定义,但是未出现在《WebDAV顺序集协议》(RFC 3658)中。

426 | Upgrade Required

客户端应当切换到TLS/1.0。(RFC 2817)

449 | Retry With

由微软扩展,代表请求应当在执行完适当的操作后进行重试。

五:5️⃣❌❌ | 🔴🔴🔴

5xx服务器错误 这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求,否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。这些状态码适用于任何响应方法。

500 | Internal Server Error

服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。一般来说,这个问题都会在服务器的程序码出错时出现。

501 | Not Implemented

服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。

502 | Bad Gateway

作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。

503 | Service Unavailable

由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个Retry-After头用以标明这个延迟时间。如果没有给出这个Retry-After信息,那么客户端应当以处理500响应的方式处理它。

504 | Gateway Timeout

作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。 注意:某些代理服务器在DNS查询超时时会返回400或者500错误

505 | HTTP Version Not Supported

服务器不支持,或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

506 | Variant Also Negotiates

由《透明内容协商协议》(RFC 2295)扩展,代表服务器存在内部配置错误:被请求的协商变元资源被配置为在透明内容协商中使用自己,因此在一个协商处理中不是一个合适的重点。

507 | Insufficient Storage

服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV(RFC 4918)

509 | Bandwidth Limit Exceeded

服务器达到带宽限制。这不是一个官方的状态码,但是仍被广泛使用。

510 | Not Extended

获取资源所需要的策略并没有没满足。

2016/2/1 posted in  苹果开发

iOS网络缓存扫盲篇

FROM:iOS网络缓存扫盲篇

由于微信、QQ、微博、这类的应用使用缓存很“重”,使一般的用户也对缓存也非常习惯。缓存已然成为必备。

“缓存的目的的以空间换时间”

这句话在动辄就是 300M、600M 的大应用上,得到了很好的诠释。但能有缓存意识的公司,还在少数。

“只有你真正感受到痛的时候,你才会考虑使用缓存。”

这个痛可能是:

服务器压力、客户端网络优化、用户体验等等。

当我们在谈论缓存的时候,我们在谈论什么?

我们今天将站在小白用户的角度,给缓存这个概念进行重新的定义。

缓存有不同的分类方法:

这里所指的缓存,是一个宽泛的概念。

我们这里主要按照功能进行划分:

- 第一种 第二种
目的 优化型缓存 功能型缓存
具体描述 出于优化考虑:服务器压力、用户体验、为用户剩流量等等。同时优化型缓存也有内存缓存和磁盘缓存之分。 App离线也能查看,出于功能考虑,
常见概念 GET网络请求缓存、WEB缓存 离线存储
典型应用 微信首页的会话列表、微信头像、朋友圈、网易新闻新闻列表、 微信聊天记录、
Parse对应的类 PFCachedQueryController PFOfflineStore

重度使用缓存的App: 微信、微博、网易新闻、携程、去哪儿等等。

GET网络请求缓存

概述

首先要知道,POST请求不能被缓存,只有 GET 请求能被缓存。因为从数学的角度来讲,GET 的结果是 幂等 的,就好像字典里的 key 与 value 就是幂等的,而 POST 不 幂等 。缓存的思路就是将查询的参数组成的值作为 key ,对应结果作为value。从这个意义上说,一个文件的资源链接,也叫 GET 请求,下文也会这样看待。

对于POST请求不能缓存只是在特定的诸如上传接口等,大部分类似FETCH请求其实是可以缓存的,不过需要自定义而已。

80%的缓存需求:两行代码就可满足

设置缓存只需要三个步骤:

第一个步骤:请使用 GET 请求。

第二个步骤:

如果你已经使用 了 GET 请求,iOS 系统 SDK 已经帮你做好了缓存。你需要的仅仅是设置下内存缓存大小、磁盘缓存大小、以及缓存路径。甚至这两行代码不设置也是可以的,会有一个默认值。代码如下:

NSURLCache *urlCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024 diskCapacity:20 * 1024 * 1024 diskPath:nil];
[NSURLCache setSharedURLCache:urlCache];

第三个步骤:没有第三步!

你只要设置了这两行代码,基本就可满足80%的缓存需求。AFNetworking 的作者 Mattt曾经说过:

“无数开发者尝试自己做一个简陋而脆弱的系统来实现网络缓存的功能,殊不知 NSURLCache 只要两行代码就能搞定且好上 100 倍。”

(AFN 是不是在暗讽 SDWebImage 复杂又蹩脚的缓存机制??)

要注意

  • iOS 5.0开始,支持磁盘缓存,但仅支持 HTTP。
  • iOS 6.0开始,支持 HTTPS 缓存。

控制缓存的有效性

我们知道:

只要是缓存,总会过期。
那么缓存的过期时间如何控制?

上文中的两行代码,已经给出了一个方法,指定超时时间。但这并也许不能满足我们的需求,如果我们对数据的一致性,时效性要求很高,即使1秒钟后数据更改了,客户端也必须展示更改后的数据。这种情况如何处理?

下面我们将对这种需求,进行解决方案的介绍。顺序是这样的:先从文件类型的缓存入手,引入两个概念。然后再谈下,一般数据类型比如 JSON 返回值的缓存处理。

文件缓存:借助ETag或Last-Modified判断文件缓存是否有效。

Last-Modified

服务器的文件存贮,大多采用资源变动后就重新生成一个链接的做法。而且如果你的文件存储采用的是第三方的服务,比如七牛、青云等服务,则一定是如此。

这种做法虽然是推荐做法,但同时也不排除不同文件使用同一个链接。那么如果服务端的file更改了,本地已经有了缓存。如何更新缓存?

这种情况下需要借助 ETagLast-Modified 判断图片缓存是否有效。

Last-Modified 顾名思义,是资源最后修改的时间戳,往往与缓存时间进行对比来判断缓存是否过期。

在浏览器第一次请求某一个URL时,服务器端的返回状态会是200,内容是你请求的资源,同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间,格式类似这样:

Last-Modified: Fri, 12 May 2006 18:53:33 GMT

客户端第二次请求此URL时,根据 HTTP 协议的规定,浏览器会向服务器传送 If-Modified-Since 报头,询问该时间之后文件是否有被修改过:

If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT

总结下来它的结构如下:

-- --
请求 HeaderValue 响应 HeaderValue
Last-Modified If-Modified-Since

如果服务器端的资源没有变化,则自动返回 HTTP 304 (Not Changed.)状态码,内容为空,这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时,则重新发出资源,返回和第一次请求时类似。从而保证不向客户端重复发出资源,也保证当服务器有变化时,客户端能够得到最新的资源。

判断方法用伪代码表示:

if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
   GetFromServer
else
   GetFromCache
LastModifiedFromServer != LastModifiedOnClient

而非使用:

LastModifiedFromServer > LastModifiedOnClient

原因是考虑到可能出现类似下面的情况:服务端可能对资源文件,废除其新版,回滚启用旧版本,此时的情况是:

LastModifiedFromServer <= LastModifiedOnClient

但我们依然要更新本地缓存。

参考链接:What takes precedence: the ETag or Last-Modified HTTP header?

Demo10和 Demo11 给出了一个完整的校验步骤:

并给出了 NSURLConnection 和 NSURLSession 两个版本:

/*!
 @brief 如果本地缓存资源为最新,则使用使用本地缓存。如果服务器已经更新或本地无缓存则从服务器请求资源。
  
 @details
 步骤:
 1. 请求是可变的,缓存策略要每次都从服务器加载
 2. 每次得到响应后,需要记录住 LastModified
 3. 下次发送请求的同时,将LastModified一起发送给服务器(由服务器比较内容是否发生变化)
  
 @return 图片资源
 */
- (void)getData:(GetDataCompletion)completion {
    NSURL *url = [NSURL URLWithString:kLastModifiedImageURL];
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:15.0];
     
    //    // 发送 etag
    //    if (self.etag.length > 0) {
    //        [request setValue:self.etag forHTTPHeaderField:@"If-None-Match"];
    //    }
    // 发送 LastModified
    if (self.localLastModified.length > 0) {
        [request setValue:self.localLastModified forHTTPHeaderField:@"If-Modified-Since"];
    }
     
    [[[NSURLSession sharedSession] dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
     
        // NSLog(@"%@ %tu", response, data.length);
        // 类型转换(如果将父类设置给子类,需要强制转换)
        NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *)response;
        NSLog(@"statusCode == %@", @(httpResponse.statusCode));
        // 判断响应的状态码是否是 304 Not Modified (更多状态码含义解释: https://github.com/ChenYilong/iOSDevelopmentTips)
        if (httpResponse.statusCode == 304) {
            NSLog(@"加载本地缓存图片");
            // 如果是,使用本地缓存
            // 根据请求获取到`被缓存的响应`!
            NSCachedURLResponse *cacheResponse =  [[NSURLCache sharedURLCache] cachedResponseForRequest:request];
            // 拿到缓存的数据
            data = cacheResponse.data;
        }
         
        // 获取并且纪录 etag,区分大小写
        //        self.etag = httpResponse.allHeaderFields[@"Etag"];
        // 获取并且纪录 LastModified
        self.localLastModified = httpResponse.allHeaderFields[@"Last-Modified"];
        //        NSLog(@"%@", self.etag);
        NSLog(@"%@", self.localLastModified);
        dispatch_async(dispatch_get_main_queue(), ^{
            !completion ?: completion(data);
        });
    }] resume];
}

更多响应码

ETag

ETag 是什么?

HTTP 协议规格说明定义ETag为“被请求变量的实体值” (参见 —— 章节 14.19)。 另一种说法是,ETag是一个可以与Web资源关联的记号(token)。它是一个 hash 值,用作 Request 缓存请求头,每一个资源文件都对应一个唯一的 ETag 值, 服务器单独负责判断记号是什么及其含义,并在HTTP响应头中将其传送到客户端,以下是服务器端返回的格式:

ETag: "50b1c1d4f775c61:df3"

客户端的查询更新格式是这样的:

If-None-Match: W/"50b1c1d4f775c61:df3"

其中:

If-None-Match - 与响应头的 Etag 相对应,可以判断本地缓存数据是否发生变化
如果ETag没改变,则返回状态304然后不返回,这也和Last-Modified一样。

总结下来它的结构如下:

- -
请求 HeaderValue 响应 HeaderValue
ETag If-None-Match

ETag 是的功能与 Last-Modified 类似:服务端不会每次都会返回文件资源。客户端每次向服务端发送上次服务器返回的ETag 值,服务器会根据客户端与服务端的 ETag 值是否相等,来决定是否返回 data,同时总是返回对应的 HTTP 状态码。客户端通过 HTTP 状态码来决定是否使用缓存。比如:服务端与客户端的 ETag 值相等,则 HTTP 状态码为 304,不返回 data。服务端文件一旦修改,服务端与客户端的 ETag 值不等,并且状态值会变为200,同时返回 data。

因为修改资源文件后该值会立即变更。这也决定了 ETag 在断点下载时非常有用。 比如 AFNetworking 在进行断点下载时,就是借助它来检验数据的。详见在 AFHTTPRequestOperation 类中的用法:

    //下载暂停时提供断点续传功能,修改请求的HTTP头,记录当前下载的文件位置,下次可以从这个位置开始下载。
- (void)pause {
    unsigned long long offset = 0;
    if ([self.outputStream propertyForKey:NSStreamFileCurrentOffsetKey]) {
        offset = [[self.outputStream propertyForKey:NSStreamFileCurrentOffsetKey] unsignedLongLongValue];
    } else {
        offset = [[self.outputStream propertyForKey:NSStreamDataWrittenToMemoryStreamKey] length];
    }
     
    NSMutableURLRequest *mutableURLRequest = [self.request mutableCopy];
    if ([self.response respondsToSelector:@selector(allHeaderFields)] && [[self.response allHeaderFields] valueForKey:@"ETag"]) {
    //若请求返回的头部有ETag,则续传时要带上这个ETag,
    //ETag用于放置文件的唯一标识,比如文件MD5值
    //续传时带上ETag服务端可以校验相对上次请求,文件有没有变化,
    //若有变化则返回200,回应新文件的全数据,若无变化则返回206续传。
        [mutableURLRequest setValue:[[self.response allHeaderFields] valueForKey:@"ETag"] forHTTPHeaderField:@"If-Range"];
    }
    //给当前request加Range头部,下次请求带上头部,可以从offset位置继续下载
    [mutableURLRequest setValue:[NSString stringWithFormat:@"bytes=%llu-", offset] forHTTPHeaderField:@"Range"];
    self.request = mutableURLRequest;
     
    [super pause];
}

七牛等第三方文件存储商现在都已经支持ETag,Demo8和9 中给出的演示图片就是使用的七牛的服务,见:

static NSString *const kETagImageURL = @"http://ac-g3rossf7.clouddn.com/xc8hxXBbXexA8LpZEHbPQVB.jpg";

下面使用一个 Demo 来进行演示用法,

NSURLConnection 搭配 ETag 为例,步骤如下:

请求的缓存策略使用 NSURLRequestReloadIgnoringCacheData,忽略本地缓存
服务器响应结束后,要记录 Etag,服务器内容和本地缓存对比是否变化的重要依据
在发送请求时,设置 If-None-Match,并且传入 Etag
连接结束后,要判断响应头的状态码,如果是 304,说明本地缓存内容没有发生变化
以下代码详见 Demo08 :

/*!
 @brief 如果本地缓存资源为最新,则使用使用本地缓存。如果服务器已经更新或本地无缓存则从服务器请求资源。
  
 @details
  
 步骤:
 1. 请求是可变的,缓存策略要每次都从服务器加载
 2. 每次得到响应后,需要记录住 etag
 3. 下次发送请求的同时,将etag一起发送给服务器(由服务器比较内容是否发生变化)
  
 @return 图片资源
 */
- (void)getData:(GetDataCompletion)completion {
    NSURL *url = [NSURL URLWithString:kETagImageURL];
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:15.0];
    // 发送 etag
    if (self.etag.length > 0) {
        [request setValue:self.etag forHTTPHeaderField:@"If-None-Match"];
    }
     
    [NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
     
        // NSLog(@"%@ %tu", response, data.length);dd
        // 类型转换(如果将父类设置给子类,需要强制转换)
        NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *)response;
        NSLog(@"statusCode == %@", @(httpResponse.statusCode));
        // 判断响应的状态码是否是 304 Not Modified (更多状态码含义解释: https://github.com/ChenYilong/iOSDevelopmentTips)
        if (httpResponse.statusCode == 304) {
            NSLog(@"加载本地缓存图片");
            // 如果是,使用本地缓存
            // 根据请求获取到`被缓存的响应`!
            NSCachedURLResponse *cacheResponse =  [[NSURLCache sharedURLCache] cachedResponseForRequest:request];
            // 拿到缓存的数据
            data = cacheResponse.data;
        }
         
        // 获取并且纪录 etag,区分大小写
        self.etag = httpResponse.allHeaderFields[@"Etag"];
        NSLog(@"etag值%@", self.etag);
        !completion ?: completion(data);
    }];
}

相应的 NSURLSession 搭配 ETag 的版本见 Demo09:

/*!
 @brief 如果本地缓存资源为最新,则使用使用本地缓存。如果服务器已经更新或本地无缓存则从服务器请求资源。
  
 @details
  
 步骤:
 1. 请求是可变的,缓存策略要每次都从服务器加载
 2. 每次得到响应后,需要记录住 etag
 3. 下次发送请求的同时,将etag一起发送给服务器(由服务器比较内容是否发生变化)
  
 @return 图片资源
 */
- (void)getData:(GetDataCompletion)completion {
    NSURL *url = [NSURL URLWithString:kETagImageURL];
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:15.0];
     
    // 发送 etag
    if (self.etag.length > 0) {
        [request setValue:self.etag forHTTPHeaderField:@"If-None-Match"];
    }
     
    [[[NSURLSession sharedSession] dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
     
        // NSLog(@"%@ %tu", response, data.length);
        // 类型转换(如果将父类设置给子类,需要强制转换)
        NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *)response;
        NSLog(@"statusCode == %@", @(httpResponse.statusCode));
        // 判断响应的状态码是否是 304 Not Modified (更多状态码含义解释: https://github.com/ChenYilong/iOSDevelopmentTips)
        if (httpResponse.statusCode == 304) {
            NSLog(@"加载本地缓存图片");
            // 如果是,使用本地缓存
            // 根据请求获取到`被缓存的响应`!
            NSCachedURLResponse *cacheResponse =  [[NSURLCache sharedURLCache] cachedResponseForRequest:request];
            // 拿到缓存的数据
            data = cacheResponse.data;
        }
         
        // 获取并且纪录 etag,区分大小写
        self.etag = httpResponse.allHeaderFields[@"Etag"];
         
        NSLog(@"%@", self.etag);
        dispatch_async(dispatch_get_main_queue(), ^{
            !completion ?: completion(data);
        });
    }] resume];
}

运行效果:

687474703a2f2f6936382e74696e797069632e636f6d2f33796868782e6a7067

总结

在官方给出的文档中提出 ETag 是首选的方式,优于 Last-Modified 方式。因为 ETag 是基于 hash ,hash 的规则可以自己设置,而且是基于一致性,是“强校验”。 Last-Modified 是基于时间,是弱校验,弱在哪里?比如说:如果服务端的资源回滚客户端的 Last-Modified 反而会比服务端还要新。

虽然 ETag 优于 Last-Modified,但并非所有服务端都会支持,而 Last-Modified 则一般都会有该字段。 大多数情况下需要与服务端进行协调支持 ETag,如果协商无果就只能退而求其次。

Demo 也给出了一个不支持 ETag 的链接,基本随便找一张图片都行:

static NSString *const kLastModifiedImageURL = @"http://image17-c.poco.cn/mypoco/myphoto/20151211/16/17338872420151211164742047.png";

作为通用型的网络请求工具 AFNetworking 对该现状的处理方式是,判断服务端是否包含 ETag ,然后再进行相应处理。可见AFHTTPRequestOperation 类中的用法,也就是上文中已经给出的断点下载的代码。

在回顾下思路:

为资源分派 hash 值,然后对比服务端与本地缓存是否一致来决定是否需要更新缓存。
这种思路,在开发中经常使用,比如:处于安全考虑,登陆操作一般不会传输账号密码,而是传输对应的 hash 值-- token ,这里的 token 就可以看做一个 file 资源,如果想让一个用户登陆超时时间是三天,只需要在服务端每隔三天更改下 token 值,客户端与服务端值不一致,然后服务端返回 token 过期的提示。

值得注意的一点是:

如果借助了 Last-Modified 和 ETag,那么缓存策略则必须使用 NSURLRequestReloadIgnoringCacheData 策略,忽略缓存,每次都要向服务端进行校验。
如果 GET 中包含有版本号信息

众多的应用都会在 GET 请求后加上版本号:

http://abc.com?my_current_version=v1.0.0

这种情况下, ?v1.0?v2.0 两个不同版本,请求到的 Last-Modified 和 ETag 会如预期吗?

这完全取决于公司服务端同事的实现, Last-Modified 和 ETag 仅仅是一个协议,并没有统一的实现方法,而服务端的处理逻辑完全取决于需求。

你完全可以要求服务端同事,仅仅判断资源的异同,而忽略掉 ?v1.0 和 ?v2.0 两个版本的区别。

参考链接:if-modified-since vs if-none-match

一般数据类型借助 Last-Modified 与 ETag 进行缓存

以上的讨论是基于文件资源,那么对一般的网络请求是否也能应用?

控制缓存过期时间,无非两种:设置一个过期时间;校验缓存与服务端一致性,只在不一致时才更新。

一般情况下是不会对 api 层面做这种校验,只在有业务需求时才会考虑做,比如:

  1. 数据更新频率较低,“万不得已不会更新”---只在服务器有更新时才更新,以此来保证2G 等恶略网络环境下,有较好的体验。比如网易新闻栏目,但相反微博列表、新闻列表就不适合。
  2. 业务数据一致性要求高,数据更新后需要服务端立刻展示给用户。客户端显示的数据必须是服务端最新的数据。
  3. 有离线展示需求,必须实现缓存策略,保证弱网情况下的数据展示的速度。但不考虑使用缓存过期时间来控制缓存的有效性。
  4. 尽量减少数据传输,节省用户流量。

一些建议:

  1. 如果是 file 文件类型,用 Last-Modified 就够了。即使 ETag 是首选,但此时两者效果一致。九成以上的需求,效果都一致。
  2. 如果是一般的数据类型--基于查询的 get 请求,比如返回值是 data 或 string 类型的 json 返回值。那么 Last-Modified 服务端支持起来就会困难一点。因为比如 你做了一个博客浏览 app ,查询最近的10条博客, 基于此时的业务考虑 Last-Modified 指的是10条中任意一个博客的更改。那么服务端需要在你发出请求后,遍历下10条数据,得到“10条中是否至少一个被修改了”。而且要保证每一条博客表数据都有一个类似于记录 Last-Modified 的字段,这显然不太现实。
  3. 如果更新频率较高,比如最近微博列表、最近新闻列表,这些请求就不适合,更多的处理方式是添加一个接口,客户端将本地缓存的最后一条数据的的时间戳或 id 传给服务端,然后服务端会将新增的数据条数返回,没有新增则返回 nil 或 304。

参考链接:《(慕课网)imooc iPhone3.3 接口数据缓存》

剩下20%的网络缓存需求

真的有NSURLCache 不能满足的需求?

有人可能要问:

NSURLCache 不是帮我们做了硬盘缓存么?那我们为什么要自己用数据库做本地缓存啊。为啥不直接用NSURLCache 不是更方便?

系统帮我们做的缓存,好处是自动,无需我们进行复杂的设置。坏处也恰恰是这个:不够灵活,不能自定义。只能指定一个缓存的总文件夹,不能分别指定每一个文件缓存的位置,更不能为每个文件创建一个文件夹,也不能指定文件夹的名称。缓存的对象也是固定的:只能是 GET请求的返回值。

2016/2/1 posted in  苹果开发

Launch Screen在iOS7/8中的实现

转载:Launch Screen在iOS7/8中的实现

目前项目中需要解决的问题是:

  • 兼容iOS7和iOS8,之前的版本不需要支持了
  • 实现兼容3.5、4、4.7和5.5寸屏幕,竖屏的Lauch Screen

创建所需的PNG图片

有关iPhone6/6+相关尺寸见这里:iPhone 6 Screens Demystified
需要如下尺寸图片:

  • 用于iPhone6+的1242x2208,或者1080x1920,也就是Retina HD 5.5
  • 用于iPhone6的750x1334,也就是Retina HD 4.7
  • 用于4寸屏(iPhone5/5s)的640x1136,就是Retina 4
  • 用于3.5寸(iPhone4/4s)的640x960,就是2x

使用LaunchImage

使用LaunchImage,可以兼容iOS7和iOS8。
因为iOS8也会调用LaunchScreen.xib,所以我的做法是直接删除它。就是这个文件:

然后,在Images.xcassets中创建一个LaunchImage

需要在项目属性里,launch Images Source里设置为LaunchImage

测试了一下:

  • iPhone6+使用的是Retina HD 5.5
  • iPhone6使用的是Retina HD 4.7
  • iPhone5s使用的是Retina 4
  • iPhone4s使用的是2x

使用LauchScreen.xib

这是Xcode6/iOS8的新功能,也就是说,这个步骤,是为了支持iOS8的,而不支持iOS7。其实在目前的项目用不上,不过做了技术准备,就写下来吧。
看到这个方形的xib文件,怪怪的,这是为了支持横屏和竖屏的,因为这个项目只需要竖屏,也可以这样:

不改也没关系。在Images.xcassets里创建backgroundImage

给LaunchScreen.xib中加一个图片,用刚刚创建的backgroundImage。

测试一下,iOS8下面的Launch Screen都没有问题了:

  • iPhone6+用的是3x
  • iPhone5s用的是Retina 4 2x
  • iPhone6和iPhone4s都是用的2x

因此我没有添加1x的图片,基本没用。


结论

  • 目前比较好的方式是使用Launch Image的方式创建各种设备的图片文件,兼容iOS7/8
  • 使用LaunchScreen.xib,功能更强大,但是仅支持iOS8,可能再过几年可以成为主流方法

源代码见这里:GitHub,是使用LaunchImage的方式。

2015/12/1 posted in  苹果开发

iOS开发之如何跳到系统设置里的WiFi界面

2015/12/1 posted in  苹果开发