POC - Combining BW Clock and Desktop Launcher to spend less time "Loading..."

I too would prefer @Gordon s resources to be spend on improving system wide performance. There are lots more people doing experimentation on the JS side of things than on firmware level.

My daily driver bangle install currently needs 1.6s of time between the first line of .boot and the first line of the default launched clock after reboot. Switching from clock to launcher currently needs 3.83 seconds for me, which feels like a LOT. It is actually the most remarked on thing if I show the bangle to other people. Fastloading reduces this to basically nothing in case of apps without significant own loading times. Worst offender beeing imageclock adding at least a few hundred ms to those nearly four seconds ;)

I created my fair share of memory leaking boot code, so the problem generally is not a new one :)

The problem for fastloading can be split in a few parts. Some are not as critical for memory leaks.

Clock <-> Launcher: Should be relatively easy to check for memory leaks during development and is one of the most done transitions. This works well on current firmware with setUI-remove and the eval style of loading the clock.

Launcher -> App: The only point that should not be leaking memory is the launcher, since it needs to remove itself to free up memory for the app. The app should not see any difference to beeing loaded after the normal boot code then.

App -> Launcher/Clock: Technically the same as launcher to app, but a lot more apps to check and validate. Modification of all apps and keeping them clean in regard of memory use is not really feasible. Current state of affairs is a reboot of the system if no remove-method is implemented. This also mitigates smaller leaks by rebooting every few app launches. This waiting time is not really a problem, since closing an app often means stopping use of the watch anyway. At least for me the delay after using an app is a lot less impactful than the waiting for an app to open.

Widgets: This one is currently not that easy to solve. I have experimented with tracking which listeners and timeouts etc. a widget registers, but trying to clean that up later opens a whole can of worms that probably better stays closed (think reused timeout numbers).

I think some change in handling the widgets would be nice, maybe returning the widget as an object from the wid.js with some conventions on how to structure them could work well (a bit like the recorder modules are loaded and added). This would also allow to return a stub object that loads the widgets code from a file on first call to keep the memory use minimal in case an app does not loadWidgets. This would solve some things like the widget name not matching the file name or widget JS loading no or more than one widget on some condition (not easily recoverable from if widgets are not filterable for this behaviour).

My current experiments include a fastload-app, which modifies the Bangle object to add some handling for unloading widgets and additionally widgets need to implement a remove method to properly work (at least those that use timeouts/listeners etc.). An optional update method is used for notifying widgets of changes like Bangle.CLOCK.
This seems to work well for apps with and without widgets. Could be more efficient, since it effectively hard unloads and later reloads all widgets if an app does not call loadWidgets immediately. There is of course the problem of not (yet) modified widgets, but this could be handled by disabling fastload in this style if one of those is loaded. I'm sure there are still lots of edge case that I have not yet triggered.
Main magic hides here: fastload.boot.js

Current state of experimentation in my apploader:
Firmware: at least 2v15.20
Clock: Anton
Fastload enabler:
fastload
Modifed for fastloading:
iconlaunch
gpstrek
widclk
widbat
widlock
widbars
widcloselaunch

Not really needed for fast loading but very nice effect:
@Sir_Indy s slightly modified widhide for swiping the widget bar from the top on clocks.

But all of this might well be a case of: