You don't really have to use an explicit autorelease pool every time. It is more relevant for scenarios where you do a lot of concurrent transactions and could easily run into the risk of tracking to many immediate versions. Or when you want to make sure that you close the Realm file in the lifetime of your app by releasing all open accessors to it.
The docs are at this point more to understand as a making aware of technical limitations and a hint how to resolve that once you hit an issue like that than a general best practice. Sure, you could always do that and it wouldn't necessarily hurt you (à la "If you have a hammer, everything looks like a nail."), but you wouldn't necessarily have to do it.
The extra complication of what this exactly means is not required for everyone. Understanding explicit autorelease pools needs a deeper understanding of ARC that is not a general requirement. If you have ideas, how that could be resolved in a better way, your feedback is more than welcome.
The section Using a Realm Across Threads gives an example for that, inserting a million objects in a background queue:
dispatch_async(queue) {
autoreleasepool {
// Get realm and table instances for this thread
let realm = try! Realm()
// Break up the writing blocks into smaller portions
// by starting a new transaction
for idx1 in 0..<1000 {
realm.beginWrite()
// Add row via dictionary. Property order is ignored.
for idx2 in 0..<1000 {
realm.create(Person.self, value: [
"name": "(idx1)",
"birthdate": NSDate(timeIntervalSince1970: NSTimeInterval(idx2))
])
}
// Commit the write transaction
// to make this data available to other threads
try! realm.commitWrite()
}
}
}
It generally makes sense to have object creations in a number like that in a separate autoreleasepool as you can't really predict with ARC when the object releases will happen and so you have an explicit point in time, when they will happen latest, which makes your program more deterministically to understand for you and other humans.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…