Snow Leopard 和 Leopard 的一个代码库
背景
我是一名开发人员，正在为 Mac 构建应用程序而苦苦挣扎。我马上就要拿到雪豹了。到目前为止，我一直在 Leopard 上进行构建。我只进行了大约一年的 Cocoa 开发，并不是很投入。
我读过很多关于 Snow Leopard 和 Grand Central Dispatch 的文章。我知道它使用块，但我还没有深入了解块如何工作或 Grand Central Dispatch 如何工作的细节。
我的问题
如何最好地为 Snow Leopard 和 Leopard 开发一个代码库，同时最大程度地利用 Snow Leopard 中的新多线程功能？
NSOperationQueue
我的直觉是不要直接在我的代码中处理 GCD，但是当需要将东西放入队列时，请使用 NSOperationQueue，因为我在 Snow Leopard 中从 Mike Ashes 的 Q&A 会话中读到， NSOperationQueue 充分利用了 GCD，他在 Leopard 中发现的崩溃现已修复。
手动线程管理
但是，当涉及到管理特定后台线程时，有没有什么方法可以利用 Snow Leopard 中更易于使用的线程管理功能，而不破坏 Leopard 中的内容？或者人们会建议我为每个操作系统设置不同的目标，每个操作系统都有不同的类？对我来说，这似乎是一场即将发生的维护噩梦。
或者也许我应该忍受我的应用程序没有针对 Snow Leopard 进行完全优化，并坚持使用 +(void)detachNewThreadSelector:toTarget:withObject: 或类似的东西。
人们怎么看？
Background
I'm a developer who's in the throes of building an application for the Mac. I'm about to get my hands on Snow Leopard. Until now I've been building on Leopard. I've only been doing Cocoa development for about a year not very intensely.
I've read a lot about Snow Leopard and Grand Central Dispatch in particular. I'm aware that it uses blocks, but I've not got into the nitty gritty of how blocks work or how Grand Central Dispatch works.
My Question
How do I best develop one code base for both Snow Leopard and Leopard, whilst taking advantage to the most degree possible of the new multi threading stuff in Snow Leopard?
NSOperationQueue
My instinct is not to deal with GCD directly in my code, but when things need putting on a Queue, use NSOperationQueue, since I've read from Mike Ashes Q&A sessions that in Snow Leopard, NSOperationQueue takes full advantage of GCD and the crasher he discovered in Leopard has now been fixed.
Manual Thread Management
However, when it comes to managing specific background threads, is there any way to take advantage of the easier to use thread management stuff in Snow Leopard without breaking things in Leopard? Or would people recommend I have different targets for each OS with some different classes in each? This to me would seem like a maintenance nightmare just waiting to happen.
Or maybe I should just live with not having my app optimised fully for Snow Leopard and stick with +(void)detachNewThreadSelector:toTarget:withObject: or something similar.
What do people think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您对 GCD 的直觉印象是正确的。事实上，任何使用块的 API 都已经过时了，除非您将该代码限制为仅在 Snow Leopard 上运行。如果代码要支持仅在 Snow Leopard 上可用的功能，那么这是有意义的，但如果您也将在 Leopard 上支持该功能，那么您不妨在所有情况下都使用 Leopard 代码路径，添加 Snow Leopard 特定的不向用户提供任何明显改进的路径只会使您的代码变得复杂并增加您的测试开销。
这尤其适用于线程管理或 GCD 之类的事情。那里的变化需要重大的重新架构，但这并不简单：
一般来说，如果变化很简单，Apple 会在类内部处理它们，而无需更改 API。换句话说，问题不在于您是否可以在 Snow Leopard 中使用更简单的线程管理代码，而在于当您无论如何都需要为 Leopard 执行硬版本时为什么要这样做。额外的代码路径就是额外的代码路径，直到您可以在 Snow Leopard 上使用明显不同的 API 来放弃 Leopard 支持（即使它们比 Leopard 更容易使用）都只是额外的工作。
我会考虑一下你是否真的想针对Leopard。 Snow Leopard 的采用率相当不错，Snow Leopard 是一种廉价的升级，而且由于 API 的变化，仅使用 Snow Leopard 应用程序的小型开发人员会给用户带来很大的前向压力。唯一会长期留在 Leopard 上的用户是那些不懂技术的人（他们不太可能安装太多第 3 方软件），以及那些仍在使用 PPC Mac 的人（他们还没有购买新的 Mac） 3 年内，所以可能不会购买太多软件）。如果您认为该应用程序将在 3-9 个月内发布，我认为仅使用 Snow Leopard 可能是一个合理的选择，并且将大大减轻您的开发和测试负担。
Your gut impression on GCD is correct. In fact, any API that uses blocks is out, unless you conditionalize that code to run on only on Snow Leopard. That makes sense if the code is to support features that are only available on Snow Leopard, but if it is a feature you also going to support on Leopard you might as well just use the Leopard code path in all cases, adding a Snow Leopard specific path that does not provide any visible improvement to the user is just going to complicate your code and increase your testing overhead.
This goes especially for things like thread management or GCD. Changes there require significant re architecture, it isn't simply:
In general if the changes are that simple Apple handles them inside the class without changing the API. In other words, the question isn't whether you can use the easier thread management code in Snow Leopard, it is why should you when you are going to need to do the hard version for Leopard anyway. An extra code path is an extra code path, and until you can drop Leopard support using significantly different APIs on Snow Leopard (even if they are easier to use than Leopard's) are just extra work.
I would think about whether you really want to target Leopard. Snow Leopard adoption has been fairly, Snow Leopard is a cheap upgrade, and because of the API changes there will be a lot of forward pressure on users from small developers doing Snow Leopard only apps. The only group of users that are going to stay on Leopard for a long time are those who are not technically savvy (who are unlikely to install much 3rd party software), and those still using PPC Macs (who haven't bought a new Mac in 3 years, so probably aren't buying much software). If it is an app you think is going to ship in 3-9 months I would argue that going Snow Leopard only is probably a reasonable option and will greatly cut down on your development and testing burden.
一种方法是了解 Snow Leopard 中修改了 Leopard 中的哪些 API 以使用 GCD。例如，Leopard 中的 NSOperation 和 NSOperationQueue 像往常一样工作。然而在 Snow Leopard 中，它们被重写以利用底层的 GCD。瞧。为您的 10.6 用户即时升级。
另一种选择是使用 PLBlocks 之类的东西并自己将 GCD 编译到您的代码中。我不知道这是否有效，但可能值得一试。 =)
One way would be to understand what APIs in Leopard have been modified in Snow Leopard to use GCD. For example, NSOperation and NSOperationQueue in Leopard work as they always have. However in Snow Leopard, they've been rewritten to take advantage of GCD underneath. Voilá. Instant upgrade for your 10.6 users.
Another option would be to use something like PLBlocks and compile GCD into your code yourself. I have no idea if that'll work, but it might be worth a shot. =)