I'm analyzing my approach with Gmail's android developer's team approach in order to optimize drawing times and generally create more efficient apps.
My approach:
Below is the hierarchy inside a listview. It's quite straightforward. ExpandableListContentItem extends a Relative layout which has 3 Views:
Gmail app:
The following screenshot is how the listview in Gmail app works (SwipableListView). It's interesting to see that there is only one View (I guess aY extends ConvertationItemView) which in reality is quite more complicated than mine (I see 3 texts, 1 photo, 1 icon/button).
Question:
I would assume that this is a more lightweight approach to get rendered, is it so? Even if it takes me more time to code an optimal single customview per listview item it is worth the performance that it offers?
Finally the only way I know so far is to inflate an existing view inside another which is basically the first approach. I guess now my challenge would be to combine that relativeLayout with the 3 nested views into one. Is that correct?
PS:examples, open source code are welcome.
I would assume that this is a more lightweight approach to get rendered, is it so?
Yes it is. When you consider hierarchy, every parent measures their dimensions and passes it to child views from top to bottom. Reducing layers and having more flat view will save time.
Even if it takes me more time to code an optimal single customview per listview item it is worth the performance that it offers?
Depends on application you are developing. Depends on number of items in a list and how you get them. When you scroll through the list, if you think it is slow you might want to try that approach. I tried it on my previous applications and I could see the difference.
I guess now my challenge would be to combine that relativeLayout with the 3 nested views into one.
I don't know what you mean by combining them but the way Gmail does it that they have their Custom View. You can create your custom view.
Besides that, another thing to consider is overdraw. It is as important as having flat views. If you activate GPU Overdraw from developer tools and look at Gmail app row, you will see 0 overdraw. Make sure your code has no overdraw.
For further reading I would recommend you to check these blogs :
Performance Tuning On Android
Android Performance Case Study
Related
I'm in the need of an Excel like grid in an attempt to convert an "application" written in Google Calc to a real application. I've got one implementation using Vaadin, but it (also) suffers from a long page construction. The screenshot below uses a CSS flex grid with individual divs, and given 6 weeks, there are over 5000 individual divs.
Constructing this page takes over 20 seconds, not something users will be happy about. I'm working on a version based on a table, but it does not seem to improve much. In the end the same amount of cells need to be constructed, whether they are DIVs or TDs does not seem to matter much.
Is there a way to construct such a grid in a more speedy way? I'm more than happy to solve "where did the user click?" on the server side. To be aware of: besides the number of cells themselves, each also has specific content, so just getting a grid shown is not enough.
Each component (div, or something else) is managed by the server. So when you have 5000 of them it's quite slow. You need to reduce the number of components managed by the server.
I can't give you a better answer since I don't know the requirements. But the idea is to try to combine some elements.
You have an example of a table generated ( instead of each element one by one) here: https://cookbook.vaadin.com/grid-details-table.
You can also create or own component. There is also a paid add-on: spreadsheet which seems to fit your needs. It's still in preview: https://vaadin.com/roadmap
The problem here is the complexity of the UI itself. Rendering 5000+ cells will be slow what ever method you use and what ever framework you use. There will be big amount of elements in the DOM and you need to load also lot of data upfront. And as you see the result is huge, and it wont fit most screens. So I would recommend further design of the UI. Is it really necessary to show all the weeks at once? Your UI's complexity will already reduce a lot if you show only one week at the time and add buttons to browse the weeks forwards and backwards. But even with that optimization you will have lot of columns. I would consider adding another browsing direction by day. Further knowledge of the actual purpose of the UI will naturally give more insight how to develop it further.
I have a lot of FlexLayout element in my template and it is so slow on iOS devices.
i replaced that with StackLayout and now it became little fast than before.
I'd like to know which Layout Container is fastest layout in Nativescript.
There is never one right solution for all various needs, which is why we always have options and that applies to layouts in {N} too.
Learn more about layouts interactively at nslayouts.com and choose the one that suits your use case.
If you show use what exactly you are trying to achieve, we may able to give you some suggestion. There are some general guidelines you may have to follow for better performance,
Avoid nested layouts
Use GridLayout when you need known number of partitions in your UI, the less the number of partitions are, the better the performance would be. Use FlexboxLayout otherwise.
If you just want to stack items in vertical or horizontal order, StackLayout may be a good option. Use FlexboxLayout only when you want to use flex box specific features, like when items has to be wrapped to next line, change order of items etc.,
Try to not use StackLayouts just for the shake of borders around, since you can add border to the component itself.
If you have really complicated heavy UI components, you may load it once the page has completed navigation, that may be faster.
Prefer ListView over Repeater / for loop as much as possible.
By following the above at least I can confirm, I don't hit performance issues in my apps where I have 100s of elements and 10s of partitions on screen. If you still face issues, try creating a Playground example where we can see the issue.
I noticed this same thing with FlexboxLayouts on IOS where I was doing animations with the layouts. It worked great on Android, but was very slow on IOS. I switched it to a GridLayout, and things worked a lot better.
I have an app which has quite a lot of activities, and all of the activities' layout have lots of views (TextViews, to display different kind of data in different styles, ImageViews etc).
When the activities load, they take too much time to load the layout/UI (more than a second).
Ques: Is there a way to reduce the time it takes to load the activity, because the activity takes too long to load the UI?
A short description of what I have:
All the layouts have at least 30-35 views
I am using Relative Layout
I am not nesting layouts, most of the views are parallel to each other, and the overdraw is at max 2x
All of the text views are custom, setting a custom font for them
The UI is being loaded in onCreate() of the activity
I am thinking of doing either of the following things:
Converting the app into Fragments in a way there are less number of activities, and more number of fragments. For example, there is one Home Activity which loads the first fragment, and further interactions with the app keep loading/switching between fragments for different purposes via Fragment Transactions. I would spawn a new activity only when I am hitting a limitation of Fragments.
Will it help improve the speed?
Disintegrate the UI in a way were the most basic UI is loaded in the view once the activity starts, and all the other UI elements are inflated in a background thread (AsyncTask) and are then added to the root of the current view.
In different opinions, which approach would be better?
Is there a better or standard way of solving this problem?
Appreciating all the inputs. Thanks in advance!
Here are some more suggestions to what you've already going to do.
If you inject views in onCreate() method, make sure you use design-time injection frameworks (Bufferknife or AndroidAnnotations) and not runtime ones (Guice, RoboGuice). Runtime frameworks definitely slow startup time down.
If you have views, which are not visible to the user initially, you can use ViewStub and load them on demand.
I'm pretty new to programming and want some advice on the basic app structure so forgive me if this is pretty obvious.
The main part of the app is a series of 20 pairs of views which the users moves through sequentially (1a,1b,2a,2b,3a etc). Each a view and b view have the same layout as other a/b's but have different image, audio and text.
I could set out all 40 views in storyboard in one long line but that seems like I'm duplicating a lot of work (as well as creating a larger size app) although it would be conceptually very simple (and more stable?)
Alternatively I could just have two views (a and b) with all the content and some sort of counter so that Xcode would know which content to serve up depending on where the user is in the sequence. What would be the easiest way to implement this? I'm afraid however that this could also get unwieldy and perhaps keeping it simple really is the way to go.
Any advice gratefully received.
Many thanks
Design is totally dependent on complexity of screens not on the number of screen. If Screen won't have much variation then you can go for second approach having only 2 views and conditionally loading the data.
Alternatively if you want to go with approach first you won't need to duplicate all the steps. You can programatically create two super class which contains all the functionalities, and the part which varries for that you can create separate class(Inheritance concept). This will make the thing easier, you can reuse the code as well as increase the maintainability of app.
I'm developing my first Android game and I'm having a bit of difficulty making the UI as smooth as I would like. I've spent a couple of hours googling around with no luck, I'm probably just searching for the wrong thing.
I have two different XML layout resources where each layout contains just one SurfaceView subclass. When I call activity.setContentView(R.layout.second_layout) to transition from the first layout to the second layout there is a noticeable period of time where a black screen (with a small white bar along the top) is displayed in between the two views.
I've tried various things such as; constructing the second view manually at runtime (i.e not using a layout XML file), calling activity.overridePendingTransition(android.R.anim.fade_in, android.R.anim.fade_out) after activity.setContentView(R.layout.second_layout) and attempting to render to the canvas before the view has loaded (turns out the canvas is unavailable).
I don't see other games (or apps) having this issue so I presume there is a reasonably simple solution.
If you need some more information about my particular situation in order to help out then please let me know what information is missing. Any help would be largely appreciated.
Update: My answer below was written in 2010. Since then Fragments have become the norm, particularly since Fragment nesting was made possible and the support library allows this functionality to be used in a backwards compatible fashion. As such, instead of transitioning to a new Activity to perform a new "user task", you can use the one Activity and push and pop fragments within that Activity's view hierarchy. Animations can also be performed as a part of a fragment transaction (e.g. Fragment transaction animation: slide in and slide out).
This became pretty apparent not long after posting this question, however I thought I should come back here and make it clear to everyone else.
Activities are positively the way to go when developing for Android. Don't be put off by the fact that a transition may seem too minor for a separate Activity, the very foundation of Android is built around the idea of an Activity.