tasty-imitation-keyboard
tasty-imitation-keyboard copied to clipboard
archagon
Memory leak
While debugging in Xcode i noticed that every time when i change keyboard to my custom keyboard the memory keeps increasing. It starts with 25MB which is fine as Apple mentions in their App Extension Programming Guide https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html that memory limits for app extensions are significantly lower than limits imposed on foreground apps. Later when i keep changing keyboards every time it keeps increasing so i reached 60MB with just couple of keyboard changes. I think that is the main reason why keyboard crashes sometimes or does not disappear at all.
Really curious about this issue. Will be glad if all you guys would share your experience. I think it is one of most important issues needs to be solved. Keyboard is really cool but this freezing things that sometimes happens annoying a bit.
Previous discussion here. I am lead to believe that this is a bug in the development tools. When you switch keyboards, your current keyboard is supposed to be unloaded; in fact, you can see it in the logs. Furthermore, I tried to get the keyboard to crash by cycling keyboards until it hit a memory limit, but I could not to it; it went all the way past 200MB, which should not be possible for a normal app, let alone an extension. So I think it's just misreporting.
As for the crashes, I think it might be a performance issue, but I'm not sure. The crash logs aren't really helpful. Still looking into it. Hope that the performance improvements in the next release will fix it.
Thanks for an answer. Yes, crash log is really not helpful at all. When are you planning to commit updates?
Just forgot to mention that, when i am testing another keyboard examples they does not have same issue with memory. I mean memory does not keep increasing when i keep changing keyboards. That is why i am bit confused either it is developer tools bug or not.
I just fixed a bunch of retain cycles in key-reuse, hope that fixes the problem.
Tested with simulator and real device. Now looks better. Will continue testing and let you know.
Everything works good as far as i tested. Just on iPad when you typing very fast using more than one fingers keyboard lagging a little bit. When you remove your fingers it keeps highlighting keys and typing letters.
Also, on iPad first appears background of the keyboard then the keys are visible. There are few milliseconds between them.
"Just on iPad when you typing very fast using more than one fingers keyboard lagging a little bit."
Do you get this on the default keyboard? On my iPad 3, which is pretty slow these days, I see it in the default keyboard as well.
Just a note, when in debug mode the memory watchdog may not happen, which is why you wouldn't get an out of memory crash when debugging. There may be a setting for this, not sure. But it sort of makes sense as debugging itself takes some memory.
Thanks, that's good to know. In any case, I think I've fixed the biggest memory leaks, though there still seems to be some minor increase when switching keyboards quickly, possibly capped at a certain point.
Memory problem still exists if BannerView is ON. it keeps increasing memory when you change keyboards. When BannerView is off, no reasonable memory problem exists.
will really appreciate if you will fix that. Because there is still really serious memory leak if BannerView is On.
I'm curious what the cause could be. I see it, too. Even a separate keyboard that I built myself exhibits this same issue...I'm thinking it might be constraints, but I'm not sure yet. If I can get Instruments to symbolicate, I'll hunt it down.
Still couldn't get Instruments to work for me to know the exact cause, but I do have a workaround--at least this worked for me on my own keyboards. I'm guessing it's outlets etc. that are not being released properly, then recreated by the system. Could be an iOS bug, could be a misunderstanding of how outlets work. What reduced it for me significantly was to set outlets and other variables manually to nil on viewWillDisappear (viewDidDisappear didn't get called for the extension in my experience).
This, coupled with lazy loading of everything, should keep things tidy.
If that doesn't work for you, here's an idea that's crazy enough to work--just raise an exception on viewWillDisappear, crashing the app silently, thus gaining back memory. This loses any caching and will make it slower to load, but keeping the memory footprint low will keep it from crashing while in use, and probably speed up its interaction overall.
Hope this helps!
That's a great point. I unfortunately don't have the time to investigate right now, but I'm sure I forgot to do something to release the IBOutlets. A cursory SO search shows that they might need to be set to nil at some point. So that's probably the correct solution.
Not sure why it would be happening with the banner though, since my implementation does not use a nib for that and I don't see any obvious retain cycles.
viewWillDisappear is called in my case. i put self.bannerView = nil, self.forwardingView = nil there but next time when i switch to keyboard it gives BAD_ACCESS error in different places.
Memory leak more observable in spotlight keyboard when bannerview is on. Also, keyboard delays for for half second while switching from symbol keyboard to letter keyboard when you click space button on specialkey (symbol) layout. would really appreciate if you will find couple hours to investigate memory leak problem. This is very cool keyboard but currently it is problem to add more functions into it because of this problems.
Just a reminder for you if you may be forgot to read this tread. Please improve a bit more. This is very useful work.
@pirrate now you're being annoying. Have respect for this person and what they've offered up to you, for free. No one is beholden to you. If it's so important, figure it out yourself.
@alariccole i don`t really want to annoy someone. i just want to make it even better. From the beginning i was testing and reporting, helping for improvements here. @archagon as an author knows better his code and logic. He can easily/faster improve things here than someone else. I know we all are busy with real works daily and he is too. It is possible that we forgot to read something. This was just a kind reminder for this case. I have respect to him and to all open source community so no need to judge me man. If i do annoy him, he will tell to me and i will excuse and wont to that.
Sorry guys, I have a big project I'm working on right now and I need to focus on it pretty much exclusively. I hope to come back and fix all these issues eventually but I can't offer any timelines or guarantees. My main metric for stability is reviews from the keyboards I've put up on the App Store, and nobody's complained about performance or crashes for the past few months, so I think that part is relatively good for the time being — at least for newer devices. (I know there are still issues, but they are not nearly as bad as they were a few months ago!)
If you've identified any glaring roadblocks to performance or stability, please submit a pull request and I'll be happy to look into it.
Who has found a solution to this problem?
Each time the keyboard is displayed, the memory is being filled and eventually stops working
People will not be used if every X times the keyboard no longer appears
