Cordova optimization for Android release

[paulshapiro]

I've observed things such as…

• big lag on adding wallet - when dismissing login scr and when showing wallet details while adding wallet - probably related to the request itself, and the parsing that's done

• big lag on adding contact - the 'resolving' OA network request?

• big lag on typing into addr field on create contact - some bg thing? parsing of txs? (keyimgs)

• slow transitions

• degrading performance over time

Web Workers

All the stuff that's put on the background thread under Electron is on the main thread in Cordova, because Web Workers haven't been implemented yet.

I actually started working on it but discovered some serious and varied issues that made me put it on the back-burner and get the code ready to publish.

However I expect this to give a huge boost to performance.

A model for how to perform background tasks and associate the asynchronous replies with the original requests is demonstrated in local_modules/electron_background. This is used throughout the Electron app.

I suggest a Cordova analogue of this be created and then used to create the appropriate 'background' adaptations of various currently-main-thread tasks, such as APIResponseParser.cordova.js.

At least everything which is being done on the background under Electron should be done similarly in Cordova, but I expect that also backgrounding the network requests in the API client – under Cordova specifically, not Electron – will yield a performance boost. (Note that in Electron the request is very intentionally done in the renderer process and should not be moved.)

However, in order to facilitate backgrounding the network request itself, a little bit of architecture work may need to be done. The main blocker to me doing all this architecture work and coding work to put these objects in the background is simply how crazy it turned out to be to get Web Workers working under Cordova in both iOS and Android in the first place! So if anyone wants to figure that out, it would be a huge help. (Edit I am currently looking into this)

Various rendering tricks?

• try -webkit-transform: translateZ(0) - potential issue - see http://stackoverflow.com/questions/10814178/css-performance-relative-to-translatez0 and http://stackoverflow.com/questions/10014461/why-does-enabling-hardware-acceleration-in-css3-slow-down-performance/10114994#10114994

• try -webkit-backface-visibility: hidden; and perspective:1000, esp on Android, but just for > And 2.3, if even necessary - http://stackoverflow.com/questions/10014461/why-does-enabling-hardware-acceleration-in-css3-slow-down-performance/10114994#10114994

• however it's quite possible these are partially or wholly redundant these days and not the biggest source of issues , see http://ilee.co.uk/css-translate3d-performance-hack/

Navigation animation optimizations

• look at translate3d for StackNavigation and modal animations, instead of top/left so they don't jitter so badly (if it does make a difference on Cordova, this is likely to benefit on Electron too)

DOM element count and special effects reduction

• possibly look into simplifying/flattening/reducing el count in the DOM in the same way the wallet icon component was, or looking at what remaining places still use box-shadows

Memory usage growth?

I instrumented memory usage growth and it looked good. But I may only have instrumented a limited set of functionality and this should be further examined. (This would obviously benefit the Electron/desktop app as well).

[paulshapiro]

Update about Web Workers. A few hours ago I went back and started testing web workers in Cordova under Chrome (browser), iOS, Android. I discovered that iOS was crashing not because of some lack of support for Web Workers in iOS webviews, but actually because of the Safari Web Inspector. It being open triggered the crash, at the app's WKWebView's call to WebCore::WorkerMessagingProxy::postMessageToPageInspector. A ticket/radar should be filed about this. I proceeded to implement BackgroundTaskExecutor.cordova.js and ipc.worker.js and used them to successfully place APIResponseParser.cordova.main.js in the background on all three Cordova platforms (5acfb71). Will proceed to implement whatever remaining concurrency wins I can.

[paulshapiro]

More updates.
I placed the Cordova DocumentCryptor in the background, which improved UI responsiveness, with the apparent tradeoff of slightly longer load times (316529e).
It may yet be a win to put the network requests in the background but that has not been attempted yet.
Since the UI can update while loading is occurring, there's the new issue that the empty screen often shows, after the app is unlocked from having gone idle, while the records are loading. It would be good to enhance the app to show a loader while that is occurring, but detecting the exact state without stomping on other similar states will be slightly tricky.

I proceeded to get the app deploying to and installing on Android device. Since Android doesn't support ES6 well (with keywords such as const), I investigated using babel-loader to transpile but that didn't pan out. No transpilation took place and debugging yielded nothing. So I switched the Android build to use the Crosswalk project instead, which not only got the app working, but came with what I figure are probable performance improvements, given the nature of the Crosswalk project (6aa3b9e). This has made the app performant enough on Android (from my basic testing) that I'm going to remove the labels indicating this issue is blocking Android launch. Of course, further optimization will be very useful, but I would like more testing to take place before that is embarked upon, given how much of a black hole Cordova app optimization can be.