I have a very simple app which runs great on the PC, but runs 'acceptably' –not by much though- on my tablet (Samsung Galaxy Tab 3, SM-T210). It’s a very simple app so I thought that it would have ran great from day one, but it didn’t. I’ve seen some really resourceful applications –mine cannot even compare to them- running very fast and smoothly on a tablet. So I’ve been wondering how to accomplish that.
I’ve heard that you can accelerate your flex application using Stage3D, Starling or Feathers. I think with most frameworks I would have to rewrite part of my app because I would have to use the framework’s components to make the app run faster. I don’t know if I’m correct by this though. Is this correct?
Is there a way to accelerate my Flex Mobile app using one of those frameworks without having to rewrite a substantial part of my code? If so, can you tell me how?
Thanks in advance for your help.
Regards,
Sebastián
NEEDED FOR SOLUTION
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
In my Flex-Mobile app, I haven't tried using any frameworks. In order to optimize my application, I am doing the following tips:
write item renderers on AS
subclass LabelItemRenderer or IconItemRenderer
avoid complex bindings
set autoDrawbackground to off
Use BitmapImage over Spark Image
use PNGs over JPEG or GIF. it takes less image decoding and rendering time
Text - Use StyleableTextfield (can be use only in AS)
write skins in AS (extend MobileSkin)
write custom component in AS3 not in MXML
setElementSize is cheaper than setting width and height
setElementPosition is cheaper than setting x and y properties
use light-weight components (i.e. Label)
use cacheAsBitmap property
components that are not changing frequently but are redrawn often
can be cached as Bitmap to optimize rendering time
don't use BorderContainer, use Group + Rect
reduce number of nested Groups
use Scroller.viewport instead of Scroller.verticalScrollbar
Do you have Lists in your app? You could rewrite ItemRenderers etc.
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
Related
I am looking for some practices to follow for making my startup's app performant.
Please share the tips/tricks and practices that you follow for making Flutter apps smoother. I have shared some practices that I currently follow. Thank you!
Flutter apps are very performant if some of the performance optimisations are kept in mind while developing the apps. No doubt, apps can become laggy and janky.
1: Use smaller image files:
No doubt, images are essential for any mobile application. And this is the area where performance gets the hit by a good margin, if not managed correctly. I started my journey as an Android Developer and I soon experienced lot of lag and poor performance in my apps. Later, I found that I was using the images which were of several MBs each. The resolution of image assets was much higher than required.
This took lot of time for device to load the assets and draw pixels, increasing CPU & GPU’s work. Sometimes, images even failed to load, making app completely unresponsive.
Here are some tips to follow to avoid performance issues related to image assets.
Try reducing size of you images from tinypng.
Lower the resolution of image here. Make sure the resolution is not more than any higher end device’s resolution.
2: Avoid Unnecessary Animations
Animation is a foe of performance, using animations may cause your device resources to constantly work (since the animation values are generated again & again). CPU constantly needs to generate values & GPU has to redraw widgets.
3: Remove Redundant Widgets
Personally, I used lot of redundant widgets like useless containers & other widgets which did not contribute to overall UI feel of the app. Gradually, I realised that this was becoming my habit. Although this can be subjective. Make sure to use only those widgets which are necessary.
4: Proper State Management
A proper state management solution can make your app very efficient & avoid computational overhead. A typical Flutter app may contain hundreds of widgets. Updating these widgets & redrawing them again & again may cause your device to work more. The proper state management allows only necessary widgets to update their state or redraw. Let’s assume that you are using Provider as your state management tool for the app, Provider will only notify its listeners i.e consumer widgets. Only widgets listening to that Change Notifier Provider will update.
Image description
5: Use Dart Dev Tools (Flutter Dev Tools)
Dart Dev Tools is a combination of some useful profiling tools which can help to determine which widget or functionality is taking much processing power and cause lag or jank. Dev Tools illustrate a clear picture of things happening at main & UI thread.
Image description
6: Use Const Widgets Wherever Possible
It is good practice to use the keyword const for constants that we can initialise at compile time. Let's also not forget to use const as much as possible for our widgets, this allows us to catch and reuse widgets to avoid unnecessary rebuilds that are caused by their ancestors.
7: Avoid Functional Components
Flutter is all about widgets, creating a custom widget can be done in two popular ways. Either create a function returning respective widget (functional approach) or create a whole new widget. It is highly recommended to create either Stateless or Stateful widget rather than creating a function.
How can I control life cycle of QML forms (I mean windows)? I am talking about onCreate, onResume, onPause etc. methods on Android or life cycle of views on iOS. And Can I work this life cycle of QML forms on Android, iOS, Windows 10 Mobile, desktop etc.?
Design of Qt Quick (QML) applications is different from Android ones. There is no difference between views and objects like Button, Text, etc. Every QML object with graphical representation inherits Item and it is possible to define Component.onCompleted and Component.onDestruction functions. They will be executed once object is created and destroyed. If you also need a pause signal I suggest creating functions pause() and resume() in every view you create and create an object that will manage the views - create, destroy, pause and resume them.
Please notice that you need to take care of transitions between views and states yourself. Also as you can create your own QML objects it is worth considering creating a template of a view and then only inherit it.
This will work with every system you deploy the app on.
If you have more questions, need example etc. consider editing the question or leaving a comment.
I want to thank BaCaRoZzo once again for useful tips. I added them to this answer.
I have created an example project that tries to mimic Android app life cycle. This will work with every OS. This is just an example but I think that similar approach may be used in release source. However, first you need to understand the nature of the QML. This is high level language that is already being managed by some other process. It is far different from Java. For example take a look at the fragment of the docs about a state used by background processes:
A Qt Quick application should not usually handle this state at the QML
level. Instead, you should unload the entire UI and reload the QML
files whenever the application becomes active again.
So if I were you I would only save sensitive data when I detect application is going to background. No need to try and unlod views etc. It would be needless uphill struggle becuase QML is not designed for this. Instead let your app be killed if OS needs more memory.
You can find the example project here. You can use it if you want. It contains comments to let you better understand what is going on.
Making an application for android i noticed that the layout view on eclipse is different from the application layout view on my phone when i run my application on the phone. Talking about the position of widgets including buttons, image view, custom views. The placement is different in the application layout view on eclipse from that on phone. I was thinking that this means it would variate on different models of the android phones on which the application would be run. How can i make my view generic in order to cater this issue so that the position of the widgets be same no matter where the application is being run? Is it possible to cater this issue?
As Henry suggested in the comment, this Android dev article should be able to make all your dreams come true.
http://developer.android.com/guide/practices/screens_support.html
Literary everything you could ever need to know about formating for different size screens is in that.
I did this to generate UI elements which fit on any phone and have abstraction what elements I want to show and how they will look like:
SimpleUi ( https://github.com/bitstars/SimpleUi )
The generated UI (code below):
The complete code to create this Android UI:
I use it in real applications, not only for fast prototyping or dialogs and its well tested over the years. The concept is based on the model view control principle and for most common scenarios there are ready to use components which automatically look correct on any device. I don't say it should be used for any UI (e.g. listviews should be done by hand) but for most usecases this should be quite handy ;) Oh and feel free to fork it and improve it further if you want
Yesterday, I spent 12 hours becoming a student of Traceview. I didn't even know it existed (hangs head in shame) previous to this.
Now that I've overcome the absolute shock of the data it produces, I find Traceview can be boiled down into a couple simple concepts:
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation.
Look at the frequency of calls and the cpu time/real time per call. Obviously higher calls should be looked into. In most of my experience, if you sort by #1 above, methods which are called too much and take too much time will also be at the top of the list (makes sense as they are also using the most CPU).
Anyway, doing these two steps above I find 3-4 methods which are always using 90% of my CPU and taking up most of the real time delays in my app. The only problem is, none of these methods are methods I wrote, they are system methods such as:
BitmapFactory methods
WebKit methods
And other system methods
This being said, is it a correct to assume that if the top resource hogs are system methods, then it must have something to do with my design of my layouts? I am at a loss as to how BitmapFactory could be so high, my layouts aren't extremely complicated, though in one Activity BitmapFactory is taking 95% of resources itself.
TL;DR - If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue? Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Thank you very much,
Ryan
I find Traceview can be boiled down into a couple simple concepts:
Those concepts are not the best, IMHO.
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation
In particular, this concept is fairly lousy IMHO. Yes, this is useful data. However, you then need to work back up the call stack to try to figure out what is triggering this. Sometimes, it will directly be your code. Sometimes, it will be something else that you recognize that is part of the framework (e.g., onDraw() of a View). Just knowing that some random method is taking up a bunch of time does you no good until you identify what is triggering that method to be invoked in the first place.
If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue?
No.
Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Work your way up the call stack to figure out who is calling these methods so frequently, or at inopportune times.
For example, in the BitmapFactory example, you will probably find that you (or a library that you are using) is calling BitmapFactory, and perhaps is doing so on the main application thread.
To work your way up the call stack, click the triangle on the left edge of the row representing some method of interest. You will then see two branches beneath that: "Parents" and "Children". The "Parents" represent the next level up the call stack from the method, and you can continue working your way up the chain of parents until you find something that you recognize.
That's why, IMHO, you are better served sorting by inclusive time, as your code (where it directly is the culprit) will tend to bubble towards the top.
Well, I found the problem and it's bitter sweet. It's sweet because it wasn't my code nor layout causing the problem, it was the admob AdView using the loadAdOnCreate="true" to create ads. It's bitter, because I now may have to switch sources of revenue if I can't remove the loading delay created by the AdView! That was a tough one to find, I should have anticipated this though!
(disclaimer: all my life I've been incredibly far from UIs of any
type, shape or form - backend and algorithms were my things, and UX,
unfortunately, wasn't. But there's always a moment when you want to
give it a go...)
I've been fiddling with an idea of a toy project for myself, and as a part of it, I want to implement something similar to Schedule/Day view in Android calendar. Probably best this is explained by this UI mock (admittedly I'm not the best UI designer, but hopefully this would be enough to illustrate my point)
Currently I'm thinking of using RelativeLayout to layout the schedule blocks and redraw background with the grid (hour lines). I fiddled a little bit with RelativeLayout and arguably this might do the trick, but I'm very unsure about the background. Do you think this approach would work? Is there some better way of doing it?
Many thanks in advance!
I was looking for the same thing, and could find no good options, so I created the yadview project (https://code.google.com/p/yadview). yadview is a fork of the DayView schedule in the AOSP Calendar app, but has been reworked significantly to allow for integration into your application.
Sample screenshot of this View in an Activity:
I'm working on a project very similar to this! The idea is to have a sense of priority to the items. That way, the user can collapse the views into a single executable list of tasks, not worrying about the things that are lower priority until they need to cancel the higher priority events, at which point, the lesser priority events seamlessly fill in the blank space. Feel free to message me directly, as I'm sure there aren't many who would find our conversations helpful.