Closed dmarkow closed 9 years ago
Thanks Dylan, we weren't aware of this; ack! Let me poke around a bit. But yeah, making it weak makes sense.
I verified this is true. I thought we tested this in the past.
Removing events will also fix this: rmq.all.off
before you close the controller.
Automatically making the block weak has issues, I'm currently working on this.
Thanks again Dylan. Your solution worked. I was able to create a test that showed if failing, then I fixed it exactly as you suggested. The fix is in [master] now, and will be in the next release.
Awesome, thank you!
Event callbacks were contributing to major memory issues in our app because the callback blocks were being retained after the view controller was removed.
In our app, we have a controller that deals with raw AVCaptureSession output resulting in approximately 30MB per image capture sitting in memory. Once the user saves the image, the view controller pops back to the list of photos. In the example below,
@thing
should automatically be released by ARC when the view is unloaded. However, because the.on()
event handler is retaining the block, the instance ofFooScreen
is never removed from memory (theNSLog
line underdealloc
never executes). So after the user takes around 15-20 photos, a low memory warning is triggered and soon after the app crashes. Instruments confirms the app's memory usage growing by approximately 30mb each time the view appears.If I change the callback to be
.weak!
instead, everything deallocates properly (myNSLog
statement executes) and the memory stays relatively flat. For now, I changed all of my callbacks as follows:Should we consider just making callback blocks weak whenever possible? Sugarcube's events library (which adds similar
.on() { ... }
functionality) does something similar: