Unfortunately, Apple's documentation is lacking on the subject of thread safety. Thankfully, with iOS4, Apple made most drawing methods and classes like UIColor and UIFont usable on background threads. If you already wrote apps back in the dark ages of iOS3.2 and before, you surely experienced random crashes when using NSString's drawInRect:withFont: while preparing background images. However, even calls that are not about configuration shared internal state and thus weren't thread-safe. And if you consider that most calls to UIKit classes are about configuration, it's even more pointless to make them thread-safe. For this, Apple would have to expose a method much like CoreData's performBlock: and performBlockAndWait: to synchronize changes. Usually you want to change several properties at once, and only then see the changed result. Changing non-atomic to atomic properties would only be a tiny part of the changes required.
All you have to do is make sure that calls into UIKit are always made on the main thread.Įnsuring thread safety for a big framework like UIKit would be a major undertaking and would come at a great cost. And the fact that UIKit is tied to the main thread makes it very easy to write concurrent programs and use UIKit. Making it thread-safe wouldn't buy you much in terms of performance it would in fact make many things slower. It's a conscious design decision from Apple's side to not have UIKit be thread-safe. Although this trick does not use private API, we don't recommend using this in production apps - it's great during development though. Since these two methods are called for a lot of UIKit setters (including image), this will catch many thread-related mistakes.
#Swift share array between threads Patch
The UIKit Main Thread Guard is a small source file that will patch any calls to UIView's setNeedsLayout and setNeedsDisplay and check for being executed on the main thread before forwarding the call. There are no official tools to find such errors, but there are some tricks that will do the job just fine.
Since this is timing dependent, it usually will crash when used by your customers and not during development. But if two threads set the image at the same time, it's likely that your app will simply crash, because the currently set image could be released twice. In the case of an image, a common symptom is that your change is picked up with a delay.
#Swift share array between threads code
Apple's code is performance-optimized and will not warn you if you change properties from different threads. It's very easy to make the mistake of setting properties like image from a background thread, because their content is being requested from the network in the background anyway. One of the most common mistakes even experienced iOS/Mac developers make is accessing parts of UIKit/AppKit on background threads. For some this is expected for others it's quite interesting. In general, unless declared otherwise, most classes are not thread-safe by default. This article will focus on practical tips, design patterns, and anti-patterns with regard to writing thread-safe classes and using Grand Central Dispatch (GCD).įirst, let's have a look at Apple's frameworks.
0 kommentar(er)
