Closed parrots closed 8 years ago
Just added in some pre-caching of pokemon images, instead of opening the HD file every time we need a new annotation view. Should help a lot with CPU and memory.
I started doing some profiling to track down the high CPU usage this app has had. One thing I noticed was that it was particularly bad with the timer labels on. If I change them from attributed strings to just normal strings (removing the outline), there is a ~50%+ CPU reduction. (from an average of 8 - 11% -> 2 - 3%)!
The white outline doesn't help that much, and it adds a lot of CPU overhead when they keep getting updated, so I'd keep them as regular strings.
OK, so iOS is pretty smart with image caching when you use UIImage imageNamed
, so it's best to use that were ever we can vs doing any loading ourselves manually. To that end, the sprite generation wasn't buying us anything, and was adding 10megs to the memory usage at startup!
I kept the original sprites file in there, but I removed it from the target so it isn't shipped into the app when you run. Instead I generated sprites into the asset catalog so they can be accessed via the normal UIImage methods.
These asset catalog sprites are also generated at the proper scales (1x, 2x, 3x) ahead of time.
If you ever need to regenerate the sprites I included a class in this checkin, SpriteSplitter
, that'll output a bunch of sprites into the Documents folder to grab later.
Added logic to hide the timer / distance labels when you zoom out far enough. A) saves computation of updating all those timers when you have a lot on screen and B) the labels aren't readable when it gets to be that many clusters of icons anyway.
Moved a lot of the images to the asset catalog to make it easier to support retina assets on the remaining images. I'd suggest updating things like logo_app in the asset catalog to have 2x and 3x variants.
Pokemon once found never change, so saving processing time in the fetcher by only creating new ones and not trying to update old ones.
Also updated your preference checking logic for notification settings. You shouldn't hard-code the values in the code for defaults - use
registerDefaults
in AppDelegate and it will make sure to never return nil if the user hasn't set it yet.Also turned off normal notifications by default. I think it's a bad UX for new users to get a ton of dings / vibrations / etc the first time they add a server. Should be opt-in and off by default.