Proposal: System Modulization Plan

by Alive Kuo - - posted in b2g, gaia, javascript | Comments

Source

https://github.com/mozilla-b2g/gaia/tree/master/apps/system

Issues with Modulization-less

  1. Some modules directly invokes others.
  2. ‘LockScreen is undefined.’ message appears oftenly right after device boots up.
  3. Memory concern – Most of the modules are not always needed. Most of the UI view doesn’t need to live in the DOM tree at first.
  4. Performance concern – device bootup time is getting longer and longer.

Proposal: Core modules and side modules

We could figure out what’s definitely necessary in an operating system and what’s not. For example, Window Management relevant modules should be a core module but Captive Portal shouldn’t be.

The main idea is the same as any other app performanace tuning: Lazy load anything on demand.

The key to this idea would be to establish the following rules: * Any side module would have a main event by interest. * An event dispatcher as a core module to gather all main events of side modules and then lazy load them. For example, lazy load the Captive Portal:

1
2
3
4
5
6
7

window.addEventListener('mozChromeEvent', function(e) {
  if (e.detail.type == 'captive-portal-login' && typeof(CaptivePortal) == 'undefined') {
    lazy-load('captive-portal', function onReadyCallback() {   // lazy load captive portal and its HTML part.
      CaptivePortal.handleEvent(e);  // Pass the event
    });
  }  // If we have already load the CaptivePortal, the event listener inside CP would catch the event by itself.
});

So another rule would be: * expose handleEvent in any side module for Event Dispatcher to invoke when they are firt time loaded by Event Dispatcher.

With this, we could even lazy load lockscreen, because if lockscreen is disabled by the user, we don’t need to load it when the device boots.

IMO there’re only few core modules now:

  • Window Management
    • App Window
    • Browser Frame
  • Utility-tray
  • Statusbar
  • Init Logo Handler (But this is useless after device boot finishes.)
  • Screen Management (Exactly, it’s indeed Wake Lock Management)
  • Applications (API Wrapper for mozApp)

The following are API wrappers which I believe is also important enough to be a core module.

  • Hardware Button Management (Many other modules’ execution route is started here.)
  • Battery Management (UI-less but more like an API wrapper for mozBattery so I would put this into core module.)
  • Airplane Mode (API Wrapper of mozSettings: radio.enabled)
  • Bluetooth (API Wrapper for mozBluetooth)
  • Cost Control (It already lives inside an iframe.)
  • Ftu Launcher (Necessary only for one time when device is first time booted.)
  • Keyboard Management
  • mouse2touch
  • Notifications
  • Orientation observer (API Wrapper for deviceorientation event)
  • Sound manager (There are too many events involed here.)
  • Update Management
Chanllenge

If we want to “unload” the module and its view using iframe, we need a way for modules inside iframe to communicate. The first thing come to my mind is window.parent.postMessage

Second, we need to consider dependency problems if it’s too complex.

Comments