troystribling
commented
9 years ago Thanks, I think you have a point. I have noticed that the scanner application freezes when there are a large number number of discovered peripherals. I thought the problem was because the application was trying to connect to peripherals that were no longer accessible which would cause congestion on the Central queue. Currently a strong reference is held by the BlueCap Peripheral to CBPeripheral ,as will as the other CoreBluetooth objects, preventing them from bring released. This could be the problem. I have been working on a refactor of the framework on the refactor branch and just merged it to master. This was motivated because of testing problems and I need to rewrite the unit tests. Making all of the CoreBluetooth references weak is a good idea but I do not know what all the implications will be. If you want to give it a try go ahead. I first want to get the unit tests working again. After that I would be interested in following up on anything you start. I want to put effort in robustness and this would be a good start.
I haven't taken an in depth look into where the exact problem is, but it looks like the Peripheral objects that are being generated aren't being deallocated. I assume there is a strong reference cycle being created somewhere preventing them from deallocating (unless there is some buffer that stores all discovered peripherals that I'm unaware of). I created a deinit method inside both the Peripheral and Peripheral wrapper objects and neither are ever called.
I've talked with an Apple engineer about this and it's a big problem when CBPeripheral objects are never released (and Peripheral holds a strong reference to the CBPeripheral). To simplify the issue, if I just took an array and added every peripheral I discover to it, CoreBluetooth would eventually crash after discovering so many devices. I'm unsure of exactly why CoreBluetooth needs the memory released, but I've actually seen this happen in my tests.
Let me know if there's anything I can do to help.