App is very very slow when testing on device

Bug Reports
1

Hey,

I started testing on a device after some time of only testing on PC, and it’s very very slow, to the point of the app not responding at all.

This is what I got:

Installing APK on 1 device(s)
Launching activity 'WorkoutAppV2'
Running logcat on 'TA92903TCS'
I/ActivityManager(  870): Start proc Fuse.Preview for activity Fuse.Preview/.WorkoutAppV2: pid=16145 uid=10133 gids={50133, 9997, 3003, 1028, 1015} abi=armeabi-v7a
I/art     (16145): Late-enabling -Xcheck:jni
D/WorkoutAppV2(16145): SUT: false  CML: false  SDK: 21
I/Adreno-EGL(16145): <qeglDrvAPI_eglInitialize:410>: EGL 1.4 QUALCOMM build: AU_LINUX_ANDROID_LA.BF.1.1.04.04.02.162.107_msm8226_LA.BF.1.1__release_AU ()
I/Adreno-EGL(16145): OpenGL ES Shader Compiler Version: E031.25.01.03
I/Adreno-EGL(16145): Build Date: 10/28/14 Tue
I/Adreno-EGL(16145): Local Branch: 
I/Adreno-EGL(16145): Remote Branch: quic/l_LNX.LA.3.6
I/Adreno-EGL(16145): Local Patches: NONE
I/Adreno-EGL(16145): Reconstruct Branch: AU_LINUX_ANDROID_LA.BF.1.1.04.04.02.162.107 + cb93e16 + f50fe49 + d7c18e6 + 5b9a565 + 0f3a25d + 607156e + 75511aa + e4d16c0 + 686f3eb + 211a271 + dd281ee +  NOTHING
E/libEGL  (16145): eglSwapBuffers:1056 error 300d (EGL_BAD_SURFACE)
D/OpenGLRenderer(16145): Render dirty regions requested: true
D/Atlas   (16145): Validating map...
E/libEGL  (16145): eglSwapBuffers:1056 error 300d (EGL_BAD_SURFACE)
I/OpenGLRenderer(16145): Initialized EGL, version 1.4
D/OpenGLRenderer(16145): Enabling debug mode 0
E/libEGL  (16145): eglSwapBuffers:1056 error 300d (EGL_BAD_SURFACE)
E/libEGL  (16145): eglSwapBuffers:1056 error 300d (EGL_BAD_SURFACE)
E/libEGL  (16145): eglSwapBuffers:1056 error 300d (EGL_BAD_SURFACE)
E/libEGL  (16145): eglSwapBuffers:1056 error 300d (EGL_BAD_SURFACE)
I/Choreographer(16145): Skipped 1494 frames!  The application may be doing too much work on its main thread.
I/Choreographer(16145): Skipped 1144 frames!  The application may be doing too much work on its main thread.

Moto G Fuse 20.3 Preview

2

Hi, does this happen in fuse preview, fuse build --run, or both?

Which version of Fuse do you have?

What is the full make and model of your device?

Have you tried it on any other devices?

3

Hey,

This happens on preview The device is Moto G and is the only device I have to test with.

I’ve uploaded the project to Dropbox as WorkoutAppV2_Fahad.zip

If you open it and tap the little plus icon that comes up on the first page you see you can really see the lag.

4

Thanks for the upload! We’ll have a look at it. Which version of the Moto G are you using?

You say it happens in preview, does this mean you have confirmed it to not happen in build -tandroid --run, or does it mean you have not tested build -tandroid --run? If you haven’t, please do that and let us know.

5

Hey,

The version is XT1032.

I have tested the build, while it is slightly faster, the animation (specifically the add weight button on the first page that comes up) is just too slow, especially when compared to the PC preview (which is how I want it to look).

Thanks a lot for your help, I also want to say that the version I sent to you only works on Fuse 0.20.3, it needs updating due to the camera updates. So this might be the problem.

Cheers

6

Hi!

This is probably caused by something in your UX markup. For example, animated DropShadows are known to be quite expensive, in particular if they are large or there are a lot of them. Try removing all the dropshadows from your app and see if that helps.

7

Hi, sorry to reply late, I haven’t had a chance to test.

I have removed ALL of the DropShadows but there has been no change.

Some of the animations in the app are very smooth while others are not despite being very similar.

Do you need me to upload the updated version of the app?

8

Can you try to make out what animations are slow, and try to isolate those or show their code?

9

Hi, here’s some more details:

The problem I have is mainly the “adding weight” animation, this is the first thing you see when you open up the app, to trigger it, tap the “+” button on the bottom right corner of the weight section. It’s a ripple effect. The code for this can be found:

  • Lines 840 - 896 in MainView.ux for the components
  • Lines 899 - 926 in MainView.ux for the animation

There is also some JS work that happens, but it is irrelevant to the animation. It’s also worth noting, a very similar animation occurs, you can see it by:

Workouts Page (dumbbell tab) -> Add new routine ("+" button top right corner) -> Tap on new routine -> Add new workout day ("+") -> Add just any exercise -> Tap “Finish” -> Open workout you just made -> Tap on an exercise -> Tap the green circle on the top right hand corner of any panel to get a very similar “ripple” effect

Code: MainView.ux 325 - 411

There is also an Object is undefined sort of error that randomly appears, it shouldn’t be too hard to reproduce, just run the app, if it doesn’t appear the first time it will the second.

Another slow animation is one that is triggered by going to the workouts page (dumbbell tab), adding a new routine ("+" button at the top right) then giving it a name/days. After, tap the “…” button in the top right corner, you’ll find that there is a weird lag as the properties box opens, this same code is repeated several times and lags everytime, see:

  • Lines 1135 - 1185 in MainView.ux for the components
  • Lines 1187 - 1198 in MainView.ux for the animation.

I have only pointed out 2 animations that are slow, the reason for this is because the app was actually a lot slower before the recent update, but these 2 animations remained slow.

If there’s anything else please tell me, I may have missed something

10

Hi,

The issue seems to be that you are doing a lot of animation of layout properties such as Width and Height. Animating those can be very expensive, as they force layout recalculation each frame.

To fix it, rewrite all occuruences of:

<Change something.Height="100" Duration="0.3" Easing="CubicOut" />

To:

<Change something.Height="100" />

And on whatever is ux:Name="something", use a LayoutAnimation instead.

<LayoutAnimation>
    <Resize RelativeTo="SizeChange" X="1" Y="1" Duration="0.3" Easing="CubicOut" />
</LayoutAnimation>

LayoutAnimations are much much faster than animating the properties directly, as they only recalculate layout for the contents of the element, isntead of the entire app.

Try this out for one of the slow anims first to see if it helps.

11

Hi,

I have changed the code and there are some problems, I added what you said on line 933:

<Circle ux:Name="bgCircle" Fill="#00E676" Width="0%" Height="0%" X="100%" Y="100%" Anchor="50%, 50%" TransformOrigin="Anchor" >
    <LayoutAnimation>
        <Resize RelativeTo="SizeChange" X="1" Y="1" Duration="0.5" Easing="CircularOut" />
        <Move RelativeTo="PositionChange" Vector="1" Duration="0.5" Easing="CircularOut" />
    </LayoutAnimation>
</Circle>
<WhileTrue ux:Name="AddingNewWeight">
    <Change bgCircle.Width="250%" />
    <Change bgCircle.Height="250%" />

And updated the <Change> animation, but now there is a very weird delay before the animation is triggered, and when it is, it’s a very jarring animation, not as smooth as you’d expect CircularOut to be, this is actually very clear in local preview

12

Hi,

I’m sorry to hear you are still facing problems. It is however very hard to give feedback on how to move forward with just this loose information.

In order for us to be able to help, we need complete test cases with clear descriptions of steps to reproduce the issues.

The previous test case you uploaded is one large monolithic UX file, with a lot of deviations from best practices which makes it very hard to isloate and pin down problems.

I reccommend starting to break your app down into isolated components and using Router/Navigator for navigation. This, among many other benefits, makes it easy to pull out only the components in question to create small, easy test cases when you report problems.

13

Hi,

I’m sorry if you feel the information isn’t specific, I’ve tried to point it out carefully. However, if this wasn’t my code I would be confused too, so I understand. The issue I mentioned above is now fixed, I did that by flipping the Easing from CircularOut to CircularIn

The problem with isolating parts of the app is, most of these components were actually created in isolation first then copy/pasted into the app, in isolation, most will work fine. The problem comes when the app grows, and becomes large, and some components become dependent on data structures that would be difficult to replicate. This is espescially difficult because I have very little programming background.

As for the navigation, I agree that it seems a mess, this is because I started the app with the very very first version of fuse right after it was released to public beta. A lot of what is available now just wasn’t (or best practices just weren’t there) when I started on this, the 0.20 update specifically. It’s also important to know, I’ve become a much better, as a programmer and designer, this app would be different if I was to make it now, it would certainly be more organised.

That being said, what is your advice to me - knowing my position - moving forward? Do I need to switch to Router navigation? Please keep in mind I am pushing for release ASAP as I have been working on it for a while now, and have a potential userbase waiting (in terms of users who signed up for a notification on release, beta users etc). I really really need to release (at least to beta, a useable version that I can trust to convey the function of my app). So your input is really important to me, I hope you understand my circumstances.

14

Hi,

I understand how the code came to be what it is now, but just because there are good reasons for the code being this way, that doens’t automatically make it better.

I already gave you my advice on how to move forward in my previous post:

I reccommend starting to break your app down into isolated components and using Router/Navigator for navigation. This, among many other benefits, makes it easy to pull out only the components in question to create small, easy test cases when you report problems.

If - as you say, your app was built as components and then patched together, this shouldn’t be too hard to do. Break things into seapreate ux:Class files, and assemble them in a main .ux file. That will already help a lot in terms of making the code easier to understand for third parties.

Next up you need to provide an as small test case as possible, with very precise steps for how to reproduce the problem.

15

Hi,

The app is now separated over many files, 1 file for each page, and it’s fairly organised. The code is split up into different parts.

This didn’t make it any faster, though it did highlight some problems with my code that fixed some unrelated bugs, plus it’s much easier moving forward now.

That being said the main issue of the app being slow is still there, and after reading this:
https://www.fusetools.com/community/forums/general/ui_not_smooth_on_android_601_moto_g_3gen

I’m starting to think that this is a problem with this specific phone, the only other device I have for testing is the iPhone 6, which is a significantly better phone, and everything does infact run smoother. The device I’m using is:

Moto G 1st Gen. XT1032

Any advice? How do I move forward from here? Is it the device?

UPDATE: to confirm, the app runs on the iPhone 6 incredibly well, it’s nothing short of perfectly smooth, there is no lag whatsoever - it’s a great show of how well fuse has been built. Is it just that Moto G that’s causing problems?

16

the app runs on the iPhone 6 incredibly well, it’s nothing short of perfectly smooth, there is no lag whatsoever - it’s a great show of how well fuse has been built. Is it just that Moto G that’s causing problems?

Great to hear that your app is smooth on iPhone now :slight_smile:

If your code is now better organized, it is perhaps time for us to take a look and see if we can identify some bottlenecks holding you back on the Moto G1. Can you provide an up to date test project?

That said, the Moto G1 is a motoriously (pun intended) weak device. Some animations may not simply be possible to pull off smoothly on that one, but we’ll take a look and see.

Thanks for helping us debug!