iPhone应用程序中的异步与同步与线程

我正处于一个应用程序的设计阶段,该应用程序将使用REST Web服务,并且就使用异步vs同步与线程而言有点两难.这是场景.

假设您有三个选项可供深入研究,每个选项都有自己的基于REST的资源.我可以通过同步请求懒洋洋地加载每个请求,但这会阻止UI并阻止用户在检索数据时点击后退导航按钮.这种情况几乎适用于除应用程序需要登录屏幕之外的任何地方.由于这个原因,我看不出有任何理由使用同步HTTP请求与异步.唯一有意义的是让工作线程发出同步请求,并在请求完成时通知主线程.这样可以防止阻塞.接下来的问题是基准标记您的代码并查看哪些代码具有更多开销,线程同步请求或异步请求.

异步请求的问题是您需要设置智能通知或委派系统,因为您可以在任何给定时间对多个资源发出多个请求.它们的另一个问题是,如果我有一个类,比如一个处理我所有数据的单例,我就不能在getter方法中使用异步请求.意思是以下不会:

 - (NSArray *)users {
     if(users == nil)
        users = do_async_request // NO GOOD

     return users;
 }

而以下内容:

 - (NSArray *)users {
    if(users == nil)
      users == do_sync_request // OK.

    return users;
 }

你也可能有优先权.我的意思是优先考虑的是,如果你在iPhone上查看Apple的Mail应用程序,你会发现他们首先吸取你的整个POP/IMAP树,然后再发出第二个请求来检索你的消息的前两行(默认).

我想我的专家问题是这个问题.您何时使用异步,同步,线程 - 何时在线程中使用异步/同步？您设置了什么样的委派系统来了解异步请求完成时要执行的操作？您是否优先考虑异步请求？

对于这个太常见的问题,有一系列解决方案.破解一些东西很简单.问题是,我不想破解,我希望拥有一些简单易用的东西.

我不打算对异步委托调用进行折扣,但我通常最终使用带有同步请求的线程工作类.我发现从长远来看,拥有一个定义良好的线程API更容易,而不是用管理异步方法之间状态的代码来填充控制器.您甚至可以在工作线程中进行异步操作,尽管通常使用同步方法更容易,除非它们不支持您需要使用的功能.当然,所有这些都取决于具体情况,我可以想到很多情况,简单地使用异步方法将是最好的路线.

如果你走这条路线,一定要考虑NSOperationQueue; 它极大地简化了创建多个工作线程的过程,并且还支持操作之间的优先级和依赖性.目前在10.5上有一些问题,但我还没有听说过iPhone的任何问题.

官方的回应是你应该几乎总是异步并且同步是坏的.我发现ASIHTTPRequest使异步请求变得容易.

我不认为有一个"正确"的答案.您似乎了解所涉及的妥协,您只需要围绕这些做出设计.

一些额外的随机点:有时您的应用程序强制采用特定方法.例如,许多便利(即同步)方法将不允许进行身份验证.对我而言,这意味着我做出了决定.

对于Yummy,我最终没有使用线程.我使所有的网络调用异步,我使用默认的XML解析器(使用回调工作).由于它是所有事件驱动的并且每个单元都很小,因此它允许GUI非常流畅,而不具有线程的复杂性.

我使用状态机来弄清楚为什么我得到一个特定的响应和一个队列,这样我只需要在任何给定的时间"在飞行中"进行一次操作.大多数请求都有不同的顺序,因此我不需要优先级系统.

网络代码在我的应用程序中是最复杂的,并且需要很长时间才能使工作变得不那么健壮!