paulproteus
commented
4 years ago My preference here is that we do it the way I have it :) but if you want the changes you suggested, I'm happy to make them my time tomorrow, or have you make them before that and beat me to it. Just trying to pass the baton if possible in the interest of latency-reduction.
This speeds up the second time you start an app.
Before change app first start time: 2.9 sec
Before change app second start time: 2.9 sec
After change app first start time: 3.1 sec
After change app second start time: 1.9 sec
App first start time is the time between "onCreate() start" and "onCreate() complete" being logged when executing the app via
rm -rf android && briefcase update android -rd && briefcase build android && briefcase run android -d @beePhone.App second start time is the time between "onCreate() start" and "onCreate() complete" when I quit the app from the Android UI and then click the app icon from the launcher.
I have checked that "onCreate() start" is logged seemingly as soon as I click the app icon and that "onCreate() complete" is logged when the app shows its UI.
Note that even though it looks like this slows down the first launch, I think that was a fluke. The next time I tested it I got 2.8 seconds. This is pretty noisy, I'm afraid.
The use of
lastUpdateTimescared me at first -- I wanted to use some deterministic APK hash or something. It's the system time at time of APK installation. I think it's completely OK to use it this way. Note thatbriefcase runcurrently always reinstalls the APK, even if that's not necessary, which means that for people developing an app, they'll never get to experience the speedy start behavior unless they click on the app from their Android device's launcher.