Fennec UI can be shown much faster

RESOLVED FIXED in Firefox 13

Status

()

Firefox for Android
General
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: sriram, Assigned: sriram)

Tracking

unspecified
Firefox 13
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
Currently a lot of initializations are happening on the UI thread during startup. From my initial trails, we could save around 1.3 seconds on warm startup and about 200-500ms on cold startup. Also, the speed of app startup is more based on when the UI is visible to the user. We can always show a UI first and add contents to it.

From my preliminary investigation, the chunks of code causing startup to be late are:
* (ICS) Action Bar:
  We load the action bar through Java code and not through XML. (My initial attempts to load it via XML had issues). But while optimizing tabs-tray I found that hiding Action Bar through XML is faster than in java. Similarly, specifying the custom layout in XML gives performance over getting drawables and assigning them in Java.

* about:home
  Currently about:home is started (if there is no session to restore). However, since this is done on onCreate(), the UI stalls until about:home is completely inflated and ready to be shown. This takes around 2.7seconds on my Nexus S. If we remove the optimization to look into session restore in onCreate() and show about:home when Gecko loads (or, if needed using a postDelayed()), we can show the basic UI of URL bar much faster (in my tests, around 700ms to 1 second win just by this change).

* One color highlight:
  It has been proposed by UX team to use one color (orange) and not be device specific. This is actually a win, as to inflate BrowserToolbar, we try to find the highlight color and use it. Also, this highlight color has to be applied by peeking into the LayerListDrawable and applying a filter. If it is going to be a single color, the android can load this faster. Accessing resources using TypedArrays are always slower. (Bug 715223).

* DoorHangerPopup:
  It is highly unlikely for a user to encounter DoorHangerPopup right when the Fennec is launched. However, during every onCreate() we inflate DoorHangerPopup and keep it ready to show any DoorHangers. This involves calling the LayoutInflator and inflating an empty layout and hiding it. Since this is not hit every time, we can lazy inflate the view when the first DoorHangerPopup is shown. (Bug 725930)

* Initializing in onStart():
  As a general practise it it better to do initilizations in onStart(). This is because, by then the UI will be visible to the user after being inflated in onCreate(). We do everything in onCreate() and onStart() is empty. If we can move things to onStart(), the basic UI will be visible to the user faster. (Couldn't find enough proof, but all my basic tests ran after I moved the code to onStart()).
(Assignee)

Updated

6 years ago
Depends on: 725930, 715223
(Assignee)

Updated

6 years ago
Assignee: nobody → sriram
(Assignee)

Comment 1

6 years ago
Loading ActionBar in XML is tracked by bug 711746.
Depends on: 711746
(Assignee)

Comment 2

6 years ago
Further analysis using Traceview:
* ActionBar loading takes 261ms:
  This will almost be the same even if we dont use an action bar. The list of things that takes quite sometime in initializing here are:
  1. AnimationDrawable initialization for the throbber - 65ms
  2. StateListDrawable for the URL bar takes around 40ms

* AutoComplete initialization takes 72ms:
  This is not needed until we actually start showing a popup on a text box. However, this is initialized and inflated on startup.
  1. The listView takes around 30ms in this.
  2. The animation for it takes around 32ms.

We should probably think of reducing the time here.
(Assignee)

Comment 3

6 years ago
Created attachment 596766 [details] [diff] [review]
Patch

This patch uses handler messages to signal loading of UI to the main handler in GeckoApp.
The advantages of this approach:
1. Basic UI comes up faster -- esp when opening links from other apps.
2. about:home is moved to be loaded after basic UI is shown.
   The about:home doesnt wait for Gecko here. It just waits for the basic UI to be shown the user. In most cases, the delay is barely noticeable. Only if Fennec is busy with something else, about:home takes about 1-1.5 seconds to show after the URL bar is shown. (this matches chrome beta)
3. about:home is not loaded when Fennec starts afresh following a link opened from another app.
4. BrowserToolbar's animation based code and other initializations doesn't block main UI thread. They happen after the basic UI is shown to the user (and when Gecko is loading parallely).

Using handler messages seems to be nice approach than using | .post(new Runnable()) | This will make our code more readable if we plan changing the posts we have with handler messages.
e.g. mMainHandler.sendMessage(HANDLER_MSG, HANDLER_MSG_AUTOCOMPLETE_SHOW);
Attachment #596766 - Flags: review?(mark.finkle)
Comment on attachment 596766 [details] [diff] [review]
Patch

diff --git a/mobile/android/base/GeckoApp.java b/mobile/android/base/GeckoApp.java

>+    private boolean mFennecInitiated = false;

mFennecInitiated -> mInitialized

>+
>+    private static final String HANDLER_MSG = "type";

HANDLER_MSG -> HANDLER_MSG_TYPE

>+    private static final int HANDLER_MSG_INIT_FENNEC = 1;

HANDLER_MSG_INIT_FENNEC -> HANDLER_MSG_TYPE_INITIALIZE

and use 100 as a base number

>+                AboutHomeContent tempHome = mAboutHomeContent == null ? (AboutHomeContent) findViewById(R.id.abouthome_content) : mAboutHomeContent;
>+                tempHome.setVisibility(View.GONE);

Simpler:
findViewById(R.id.abouthome_content).setVisibility(View.GONE);


>+    private void initFennec() {

initFennec -> initialize

> 
>+        if (mFennecInitiated == false) {
>+            Bundle bundle = new Bundle();
>+            bundle.putInt(HANDLER_MSG, HANDLER_MSG_INIT_FENNEC);

Add a comment above the if block to let us know why we are sending a message


Also getting Brad to take a sanity look too
Attachment #596766 - Flags: review?(mark.finkle)
Attachment #596766 - Flags: review+
Attachment #596766 - Flags: review+ → review?(blassey.bugs)
Comment on attachment 596766 [details] [diff] [review]
Patch

Review of attachment 596766 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/AboutHomeContent.java
@@ +108,5 @@
>      }
>  
>      private Cursor mCursor;
>      UriLoadCallback mUriLoadCallback = null;
> +    private Context mContext;

shouldn't be needed, just use getContext()

@@ +125,5 @@
>      }
>  
>      public AboutHomeContent(Context context) {
>          super(context);
> +        mContext = context;

not needed

@@ +130,5 @@
> +    }
> +
> +    public AboutHomeContent(Context context, AttributeSet attrs) {
> +        super(context, attrs);
> +        mContext = context;

not needed

::: mobile/android/base/GeckoApp.java
@@ +1147,5 @@
> +            
> +                mAboutHomeContent.setVisibility(View.VISIBLE);
> +            } else {
> +                AboutHomeContent tempHome = mAboutHomeContent == null ? (AboutHomeContent) findViewById(R.id.abouthome_content) : mAboutHomeContent;
> +                tempHome.setVisibility(View.GONE);

why do we need to set GONE if it hasn't been constructed?

@@ +2711,5 @@
> +
> +            int type = bundle.getInt(HANDLER_MSG);
> +
> +            switch (type) {
> +                case HANDLER_MSG_INIT_FENNEC:

this is good stuff, can you file a follow up bug to move more of our runnables to messages?

::: mobile/android/base/resources/layout-v11/gecko_app.xml
@@ +23,5 @@
>  
> +        <org.mozilla.gecko.AboutHomeContent android:id="@+id/abouthome_content"
> +                                            android:layout_width="fill_parent"
> +                                            android:layout_height="fill_parent"
> +                                            android:background="@drawable/abouthome_bg_repeat"/>

if you default this to GONE, you shouldn't need to set GONE when it isn't constructed

::: mobile/android/base/resources/layout/gecko_app.xml
@@ +25,5 @@
>  
> +        <org.mozilla.gecko.AboutHomeContent android:id="@+id/abouthome_content"
> +                                            android:layout_width="fill_parent"
> +                                            android:layout_height="fill_parent"
> +                                            android:background="@drawable/abouthome_bg_repeat"/>

again, default to gone
Attachment #596766 - Flags: review?(blassey.bugs) → review+
(Assignee)

Comment 6

6 years ago
@@ +25,5 @@
>  
> +        <org.mozilla.gecko.AboutHomeContent android:id="@+id/abouthome_content"
> +                                            android:layout_width="fill_parent"
> +                                            android:layout_height="fill_parent"
> +                                            android:background="@drawable/abouthome_bg_repeat"/>

again, default to gone

The idea here is to how a blue layout before loading about:home. So, this cannot be made default to GONE. Making it GONE causes showing a black layer and then a checkerboarded layer from SurfaceView layer. I would like to have this visible on top during startup.
(Assignee)

Comment 7

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/0a3987cfa79f
https://hg.mozilla.org/mozilla-central/rev/0a3987cfa79f
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 13
You need to log in before you can comment on or make changes to this bug.