chenyilong / parsesourcecodestudy Goto Github PK

We have a difficult announcement to make. Beginning today we’re winding down the Parse service, and Parse will be fully retired after a year-long period ending on January 28, 2017.

在GCD 扫盲篇中提到：
异步：1）因为必定会开启新的线程，线程的申请是由异步负责，起到开分支的作用；
2）串行队列 ：会新建线程，只开一条线程 一条线程就够了；

但是，如果在主队列中执行异步操作的话，是不会开启新线程的。

由于不指定路径的话，cache默认是自动清除缓存的，那么第二次发起请求的时候，服务端返回数据没有更新，返回的是304，那么通过 NSCachedURLResponse *cacheResponse = [[NSURLCache sharedURLCache]cachedResponseForRequest:request];去取NSCachedURLResponse，不应该是为nil吗，这样的情况，怎么处理

下一篇什么时候更新啊

AFN 能用ETag 吗

思考下NSLog的打印顺序为什么会是这样？答：dispatch_suspend的作用！

这个Log和打印顺序和suspend没有任何关系。和async有关。

我测试的情况来看 [Demo_03_对DispatchQueue实现取消恢复操作_简单版] 中就算没有 dispatch_suspend 的暂停其实也会先于 dispatch_async 的 Log，这是为什么呢？

所以这个例子是不是有点不太恰当呢

• (void)viewDidLoad {
  [super viewDidLoad];
  //因为用到了dispatch_barrier_async，该函数只能搭配自定义并行队列dispatch_queue_t使用。所以不能使用：dispatch_get_global_queue
  dispatch_queue_t queue = dispatch_queue_create("com.ioschengxuyuan.gcd.ForBarrier", DISPATCH_QUEUE_CONCURRENT);
  /*
  *
  *生成Dispatch Semaphore
  Dispatch Semaphore 的计数初始值设定为“1”
  (该初始值的1与下文中两个函数dispatch_semaphore_wait与dispatch_semaphore_signal进行的减1、加1里的1没有必然联系。

  就算初始值是100，两个函数dispatch_semaphore_wait与dispatch_semaphore_signal还是会减“1”、加“1”)。
  保证可访问 NSMutableArray 类对象的线程
  同时只能有1个
  *
  */
  dispatch_semaphore_t semaphore = dispatch_semaphore_create(1) ;
  NSMutableArray array = [[NSMutableArray alloc] init];
  for(int i = 0; i< 100000; ++i) {
  dispatch_async(queue, ^{
  /
  *
  *等待Dispatch Semaphore
  *一直等待，直到Dispatch Semaphore的计数值达到大于等于1
  /
  dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) ;
  /
  *由于Dispatch Semaphore的计数值达到大于等于1
  *所以将Dispatch Semaphore的计数值减去1
  *dispatch_semaphore_wait 函数执行返回。
  *即执行到此时的
  *Dispatch Semaphore 的计数值恒为0
  *
  *由于可访问NSMutaleArray类对象的线程
  *只有一个
  *因此可安全地进行更新
  *
  /
  NSLog(@"🔴%@",[NSThread currentThread]);
  [array addObject:[NSNumber numberWithInt:i]];
  /
  *
  *排他控制处理结束，
  *所以通过dispatch_semaphore_signal函数
  *将Dispatch Semaphore的计数值加1
  *如果有通过dispatch_semaphore_wait函数
  *等待Dispatch Semaphore的计数值增加的线程，
  ★就由最先等待的线程执行。
  /
  dispatch_semaphore_signal(semaphore);
  });
  }
  /
  *
  等为数组遍历添加元素后，检查下数组的成员个数是否正确
  *
  */
  dispatch_barrier_async(queue, ^{
  NSLog(@"🔴类名与方法名：%s（在第%d行），描述：%@", PRETTY_FUNCTION, LINE, @([array count]));
  });
  }

上面是文中的代码，实际运行后发现，不会运行dispatch_barrier_async方法里面的代码，做如下更改才可以：

把原文中的代码：
for(int i = 0; i< 100000; ++i) {
dispatch_async(queue, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) ;

改成：
for(int i = 0; i< 100000; ++i) {
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER) ;
dispatch_async(queue, ^{

才可以，楼主验证下看是不是这样

dispatch queue本来就可以挂起和恢复，为什么说要借助dispatch source呢?

GET 请求缓存的确方便啊 可是项目用的是POST,GET请求不太适合啊

POST请求不能被缓存，只有 GET 请求能被缓存. 意思是post不能缓存,还是不建议缓存? 那么QQ缓存的聊天数据是get请求下来的?

在void dispatch_async_limit(dispatch_queue_t queue,NSUInteger limitSemaphoreCount, dispatch_block_t block) 这个方法里,如果将limitSemaphoreCount改为大于1，是否程序就可能崩溃?要是只能置为1，是否就跟同步队列来做是一样的(比如在运行效率),如果不一样，那各有什么优缺点呢!

在第7篇讲述信号量的文章中说通过dispatch_once 来保证避免线程的竞争，哪里有竞争的地方啊，没有看到同时操作代码块的地方也没有读取同一块数据的地方，大神请解释一下

    NSURL *url = [NSURL URLWithString:@"http://ac-g3rossf7.clouddn.com/xc8hxXBbXexA8LpZEHbPQVB.jpg"];
//    NSURLRequest *request = [NSURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:15.0f];
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:15.0f];
    [request setHTTPMethod:@"POST"];
    NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration]];
    NSURLSessionDataTask *task = [session dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {

        NSDictionary *dic = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableContainers error:nil];
        NSLog(@"%@",dic);
        NSLog(@"%@",[NSThread currentThread]);
    }];
    [task resume];

请求后沙盒中同样缓存了图片。

串行队列能确保顺序执行任务，他们两个的唯一区别在于dispatch_sync只会在 block 完全执行完之后返回，dispatch_sync不能确保会在 block 完全执行完之后返回，唯一能确定的是会在被添加到queue 队列后返回。

第二个应该是dispatch_async吧

由于没有设置路径的话，默认cache会自定清除缓存，假设第二次发起情况的时候，服务端返回的是304，但是此时本地对应的request的cache被清除，那么 通过 NSCachedURLResponse *cacheResponse = [[NSURLCache sharedURLCache] cachedResponseForRequest:request];取的NSCachedURLResponse不是就是为nil了吗，那这样的情况该怎么处理

1 请求时先判断是否有缓存
2 如果有缓存 先用缓存渲染页面
3 然后接着发送请求最新的数据
4 当数据回来时在用新的数据渲染页面，同时更新缓存
5 如果2没有缓存，就直接发请求渲染