Since all of our data observations are asynchronous, we initially started with a single content manager to act as an abstraction between presentation and data layer. This is especially critical for our app, which is highly data-intensive. Our next focus was optimizing data flows. We also uncovered a number of small technical debt issues in our codebase: blocking object instantiation on an md5 calculation, blocking in constructors and generally doing too much work up front.Īfter these tweaks were implemented, we cut our startup time to about 3.2 seconds - half of what it had been and faster We made some changes to how they were being instantiated and worked with vendors to help improve large Some third-party analytics clients we have incorporated into our app had some blocking calls during app startup. Thankfully, a fix was issued in the next release. Next, we found some slowdowns within RxJava which were costing us about a second. We’reĬurrently exploring other options but enhancements in IDE support for viewing anonymous classes in Java have made it less of a priority. We reverted back to plain old Java 7 syntax and stripped our codebase of Groovy. Since we didn’t use any other constructs of the language, we decided to move away from it. We primarily used Groovy for closures improvements in code folding within Android Studio The first major slowdown we found was related to the large number of classes, memory-intensive runtime and expensive calls to loading Jar resources required by Groovy, something previously identified as a problem in Which also offered a simple way to identify bottleneck issues, making it easier to compare performance across traces. We eventually switched to using NimbleDroid, We then collected the resulting trace files for analysis by loading the trace into DDMS and finding the largest performance offender. We measured from the Application Class constructor to the end of the progress indicator appearing on screen (see the How We Did Itįirst, we captured our app’s startup time with Android’s method tracing feature. After addressing these and fixing other smaller things, we’ve reduced our current startup time to 1.6 seconds. We found that most of the slowdown was caused by issues with reflection. This motivated us to put some effort into improving This was longer than our goal: 2 seconds or less. When we initially released our new app, which we nicknamed Phoenix, startup time was a modest 5.6 seconds on a Nexus 5. The rewrite offered improvements in maintenance, code modernization and modularizationīenefits, but required some adjustments to optimize. Our team recently rewrote our news app to take advantage of modern patterns such as dependency injection and reactive programming. Users expect their native apps to be faster still. As device manufacturers continue to offer faster and more fluid experiences, Improving application startup and load time has been a priority for The New York Times Android development team, and we’re not alone.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |