I've created a very big layout (approx 2000 lines) that contains a large number of views and sub-layouts, often with weighted measures. The tree is pretty complex and goes down to 8 or more levels of nesting.
To create different "perspectives", the app programmatically sets some of the views' visibility to View.GONE, expecially those one that are at the head of a tree of views that I don't want to be displayed, in different moments of the app life cycle, and sometimes changes the weights to resize views; hence, the final layout that is displayed to the user contains at every time not more than 1/3 of the views and view-trees that are in the main layout.
I don't care about the performance at "switch" time, so when the user switches from one perspective to the other, I've got plenty of time to switch on and off the visibility and that's not a problem.
Instead, does having so many view and view trees set to View.GONE affect performance at runtime? What is the effect of GONE views on CPU and Memory performance, in contrast to a smaller layout (maybe programmatically inflated) where all views are displayed?
Actually while creating complex layout have to use constraint layout.
ConstraintLayout allows you to create large and complex layouts with a flat view hierarchy (no nested view groups). It's similar to RelativeLayout in that all views are laid out according to relationships between sibling views and the parent layout, but it's more flexible than RelativeLayout and easier to use with Android Studio's Layout Editor.
Please find the doc from url :
https://developer.android.com/training/constraint-layout/index.html
Related
Can one relative layout / linear layout can have multiple constraint layouts? Do they affect on the performance of application while inflating?
Also, can one constraint Layout can have multiple constraint layouts?
If you are talking about nesting view groups(relative layout/linear layout/constraint layout) inside another view group, yes it is possible. But the issue with nesting view groups is each of the view group has to perform calculations to constrain its children. This is usually done in a depth-first search manner. So it will affect the inflation speed and thus the overall performance of the layout.
It is always better to keep the hierarchy as flat as possible. Which means maximum avoid the nesting of view groups wherever possible.
Nested view hierarchies should be avoided because it takes more time in rendering. To overcome from box-model logic (in HTML), ConstraintLayout has been introduced. It is clearly mentioned in the documentation.
I am trying to create a linearlayout with different relativeview layouts (containing text, image, google map, fragments. Mixed depending on the need) inside it. the views inside linearlayout will vary between 30 to 40 views. It will be mixed type of views.
I found there are two options:
Using recycler view with getItemViewType().
Directly creating views using layoutinflator.
Which option is good with respect to:
a) it should be fast.
Use a RecyclerView for performance gains. We have exact same use case #NY Times and had dramatic improvement in scroll performance when we switched from a linear layout with 30 children to instead be a linear layout with 30 rows (of about ten different view types)
Its a bit more work to setup but you'll thank yourself later.
I'm writing an app with a custom theme and layout (some CI) for API 18+, so I need to align a lot of elements.
I read several times, that one should avoid nested layouts as good as possible, but also that some layout types are less efficient than others (RelativeLayout).
should I still avoid nested views these days?
if yes, what is more efficient
flat RelativeLayout
nested LinearLayout (2 levels)
what about TableLayout with TableRows
Currently I already have this layout hierarchy:
Drawer (for sidemenu)
Relative (because of header and footer)
Frame (Content goes below here, just used for easy replacing of fragments)
Your current layout hierarchy is very sample and under normal circumstances it should not be slow at all. Of course the FrameLayout is not needed as you are using a relative layout because your can align the center content below and above the header and footer of the relative layout children.
For this level of nesting the view there is absolutely no problem as for performance.
Both RealtiveLayout and LinearLayout extend FrameLayout with relative being a little heavier as it handles what else the relationships between the views.
If you need to align many element (like editexts and textview) in a form-type layout the best option is TableLayout.
General speaking layout inflation from XML is expensive, but nesting a view inside another makes no difference in real life. The problem would be if you had a thousand views in a TableView with TableRows having nested layout inside.
My boss refuses to let me use RelativeLayout. Everything is done using LinearLayout and minimal use of RelativeLayout, such that the layout that I could run with two levels of nesting with RelativeLayout, I now have to do with four using LinearLayout. Any comments on this? What links can share?
In my opinion it would be better to combine these two elements to get the perfect layout.
It depends on the level of nesting indeed. Android suggests to use a minimum Layouts in Layouts as possible, and if you can achieve with one layout, what you want to do with 3, why not?
The app will run faster for it, though with 2-3 nestings you wont see it.
I for example, create a bunch of included layouts, which i reuse in other layouts.
And the level of nesting could get very deep with that
With the LinearLayout we get the clear separation of view or we can say that each layout is separate. With the Linearlayout each UI element us independent of the other. You get the maximum flexibility. It enables to give the vertical and horizontal orientation.
Linearlayout you can control look more and make it almost similar even
on the device change. And also, using LinearLayout is simpler though
starting phase can be quite confusing
From the Docs
A Layout that arranges its children in a single column or a single
row. The direction of the row can be set by calling setOrientation().
You can also specify gravity, which specifies the alignment of all the
child elements by calling setGravity() or specify that specific
children grow to fill up any remaining space in the layout by setting
the weight member of LinearLayout.LayoutParams.
LinearLayout is a view group that aligns all children in a single
direction, vertically or horizontally. You can specify the layout
direction with the android:orientation attribute.
Again it depends upon your need..I also agree with #Lena Bru answer.
What Is A Relative Layout?
After linear layouts, which display controls in a single row or column, relative layouts are one of the more common types of layouts used by Android user interface designers. Much like other layouts, relative layouts can be defined within XML layout resources or programmatically in the application's Java code. The relative layout works much as its name implies: it organizes controls relative to one another, or to the parent control itself.
Get to love the RelativeLayout. It will make your life much easier, when designing for multiple resolutions/densities. If you have an old SDK, update your eclipse plugin. It has graphical snap-lines for RelativeLayouts similar to designing a form in Visual Studio, so you can see what is anchored where. It's really quite good.
google says:
Layouts are a key part of Android applications that directly affect the user experience. If implemented poorly, your layout can lead to a memory hungry application with slow UIs. The Android SDK includes tools to help you identify problems in your layout performance, which when combined the lessons here, you will be able to implement smooth scrolling interfaces with a minimum memory footprint.
I got two views which are equally distributed on my main layout.But my two views in tern have nested childs which are again equally spaced.I am using nested layout weight's which is working fine. Whether nested weights effects the performance.What is the work around for this?
Every view — or worse, every layout manager — that you add to your
application comes at a cost: initialization, layout and drawing become
slower. The layout pass can be especially expensive when you nest
several LinearLayout that use the weight parameter, which requires the
child to be measured twice.
Refer: http://developer.android.com/resources/articles/layout-tricks-efficiency.html
You can use a RelativeLayout in most cases to avoid such expensive measurements. In a RelativeLayout, views are aligned with their parent, with the RelativeLayout itself, or with other views.
To clearly understand how the views are positioned with respect to each other, a wireframe of the layout can be captured by using HierarchyViewer perspective of Android SDK.