Lately, I’ve been doing some tests on my iOS app of PopToo project to optimize its performance.
The main situation I wanted to solve was when the PopToo is restoring to be Active from being in Background, it freezes for at least a second before starting to respond to user interaction.
I’ve examined a few areas and these three areas came to my attention: saving transformable objects in Core Data model, delayed selector callings for dismissing certain views while in background, and activating different accuracies for Core Location service. I tested them by eliminating each one.
Initially, I thought saving transformable objects in Core Data was the main cause. As recommended by many, I changed it to store numerical data types. Though it could save some storage space, which may positively affect migrating to new database scheme in the future, it didn’t solve the problem of experiencing freezing.
Next, delayed selector callings for dismissing certain views were dealt by simply excluding them to be used simpler without delay. Which had started for dismissing keyboards when PopToo iOS App goes background, gradually became too complicated, and currently requiring to be refactored anyway.
For saving device power, PopToo changes Core Location service accuracies to be Best if it’s Active, or ThreeKilometers if it’s in Background. And this is the spot where PopToo’s performance is significantly lagged. Core Location seemed to do a lot of critical jobs, that are important enough to cause freezing for a while, when it’s activating stronger accuracy.
Though a cause of performance lagging was found, I couldn’t develop ways around it yet. Since it’s very important and useful way to save device power while using PopToo’s Auto Check-in features, this accuracy changing can’t be removed.
Also, PopToo’s lagging interval seemed to get longer as it’s kept running until being terminated. This means there can be other reasons too, in different areas. I’m guessing it’s related to memory management.
Guess my search is to be continued.
