Liquid Fire performance on mobile

I am currently looking into Liquid Fire, and implemented it into my medium-sized ember-cli app. Integration was easy, and it works well in desktop browsers. However, on Android it seems to have a major hit on performance, and transitioning between pages feels terribly laggy. I am using the built-in fade transitions.

Is this known, or is there anything to improve performance on mobile devices? As it is, this performance issue prevents me from using Liquid Fire in production.

To my understanding Liquid Fire is using Velocity.js which is again partly using CSS animations. Often times CSS animations are by far the best performant though regular JS animations (setting incremental new values to ex. the top attribute) in some cases are performing better.

What I am saying is that I believe that Velocity.js is mostly handling this as well as it is capable. What most likely is the issue is stuff like too many elements… or if something is position: fixed. I reckon you should check with regular CSS animation optimization guides-

@francesconovy

App or Browser? App, there are fixes that get you to Chrome for Android Web Browser abilities (Crosswalk, various other optimizations). Browser, you may be SOL if you don’t have time to do a lot of optimization.

If you aren’t getting good performance in Android Browser, it’s likely because you need to optimize a lot of things (in general) to get Android performance to work well, even on a flagship device, and definitely anything more than 1-2 years old regardless of how good it was when it came out.

You also have to be careful you aren’t GPU accelerating anything liquid-fire isn’t doing for you, because if you overload the GPU you slow down hard, worse than just CPU animation.

Finally, if you need to ship and can’t spend a few weeks on optimization, it’s actually trivial to swap out liquid-fire behavior for normal behavior only on Android if needed.

Example from our Cordova app, you’d need a different test for browser.

application/view.js

import Ember from "ember";

export default Ember.View.extend({

  classNames : ['application-view'],

  templateName : 'application',

  platform : 'browser',

  init : function () {

    if (window.cordova) {
      var platform = window.device.platform.toLowerCase();
      this.set('platform', platform);
      if (platform === "android") {
        this.set('templateName', 'application-android');
      }
    }
    this.get('classNames').push(this.get('platform'));
    this._super();

  }

});

application/template.hbs

{{liquid-outlet "main"}}

application/template-android.hbs

<div class="outlet-wrapper android">
    <div class="container-fluid">
        {{outlet "main"}}
    </div>
</div>
2 Likes

I agree with the other comments here. I’ve had a lot of experience with this particular issue. Android specifically suffers since it is running multiple applications in the background. You can observe a huge performance difference on the same device if the device has recently been formatted. With the bare minimum 3rd party apps running in the background, Android performance can be acceptable. With a device that has a bunch of apps running, the performance will be far from acceptable. Obviously, I’m not advocating that you instruct your users to format their devices :smile:.

You need to focus on optimizations if you want your app’s experience to be acceptable on most android devices.

  • liquid-fire using velocity has been a huge help for my app’s performance on mobile. I’d advocate to continue using liquid-fire.
    • If your animations are not smooth, debug using Chrome’s rendering debugger and enable “show paint rectangles” The goal of this is to identify dom elements that are being repainted frequently and minimize the repainting.
  • I’d also suggest to cache data records locally with Mozilla’s localforage. You can use ember-sync to achieve this, or possibly ember-orbit.
    • Mobile network performance is anything but dependable so caching data responses from a REST API helps greatly for the end-user’s experience.
  • Rendering performance usually sucks, so be careful about how many items are rendered. If you need to render a list, use ember-cloaking or ember-list-view.
  • Packaging a 3rd party browser like Crosswalk in your Cordova app can be very helpful.

Lots of great feedback here already. The only thing I’ll add is that, strictly speaking, liquid-fire isn’t an animation library. It’s fairly agnostic to how animations are implemented, and it doesn’t have much to do with animation performance.

If you can find an animation implementation that works better for your environment, you can absolutely use it with liquid-fire. We just use velocity to provide sane defaults.

Making it more obvious how to plug in any arbitrary animation is one of my major goals for the upcoming liquid-fire 1.0 release.

3 Likes

Is there any documentation or examples of how you might swap out Velocity with GSAP using Liquid Fire? I’m not finding any mention of using alt animation libraries in the Liquid Fire docs.

In this talk I demoed an example of how to reimplement one of liquid-fire’s built in transitions using the web animation API instead of velocity. The same principles would apply to GSAP.

2 Likes