Is there a limit in rows in listview, or rows and columns in the case of gridview, that could slow down the app?
I'm looking at, a maximum nearly 5,000 individual datas with at least 3 table attributes to be displayed in each row of the listview.
It depends of how much information you are putting in each cell (if your cell contains images, for example, it obviously will take more memory). It also depends if the phone has more or less memory (the application heap is variable).
And most important, it depends if you are recycling views (see How ListView's recycling mechanism works)
Related
There is a canvas and As a beginner, I have learned about viewGroup in android and how to add a view or multiple views in a viewGroup using either xml or programmatically using addView. We can add as many view we want to add and we can also increase the height of the view dynamically using layoutParams. While we can use addView or setLayoutParams to increase the height of the canvas as we add more pages, why should we use recyclerView?
From the UI perspective, everything seems equal here whether we say increasing height or adding view or list of items. Even though when we are increasing the height, there is a separator between each addition. However, the separator is not a major concern here. Basically, based on numbers of pages or items or data, we are increasing the height of the canvas view so that we can include and show all the data. These numbers of pages has been set to 14 currently but it can be increased without any limit and each canvas board can contain an unpredictable amount of data - may be hundreds of dots, a combination of lines, shapes, text, images and so on - which is fair. We are not limiting user to draw only certain amount of things on individual canvas board.
While we can use addView or setLayoutParams to increase the height of
the canvas as we add more pages, why should we use recyclerView?
Because RecyclerView is more efficient for large sets of data.
From the UI perspective, everything seems equal here whether we say
increasing height or adding view or list of items.
No, it's not. If you add a 1000 items to a ViewGroup it will try to draw 1000 items, dragging your app to a crawl at best, or crashing at worst.
If you add 1000 items to a RecyclerView it will draw however many will fit on screen.
These numbers of pages has been set to 14 currently but it can be increased without any limit
Untrue. There is always a limit. It maybe large, but there are always limits. In this case, the limits are on RAM (how much data can the device hold in memory before it craps out).
RecyclerView is a powerful tool to efficiently display large sets of data with so many abilities such as caching and show items with animation.
Using RecylcedrThere is nothing to compare between RecyclerView and addView() cause their usage is different.
However i recommend you to read this article about how does RecyclerView Works.
How Does RecyclerView Works
A performance question here. I have a recyclerView (in a fragment) that I'm populating from a database that's going to eventually hold around 16,000 items in a single table, 18 columns per record, nothing trickier than ints, decimals and varchars and the records are categorized so I don't expect to ever need loading more than, say, 300 at a time. Should I consider limiting the selects or implementing some sort of paging? I'd prefer to keep the recyclerView simple and seamlessly scrolling.
I'm also wondering about the recyclerView itself. The rows are rather complex and have two states: the default collapsed state shows 6 views including a single imageView, and upon clicking a row we get expanded state (a container goes from GONE to VISIBLE) with a total of 21 views including 2 imageViews. I care about the quality of imageViews so I'm testing it with a resolution limited at 512px for a small image (50% screen width) and 1024px for a large image (100% screen width), everything in JPGs. And because I need to track the state of rows, I have used
holder.setIsRecyclable(false);
in my onBindViewHolder in the recyclerViewAdapter, because without it expanding one row results in some of the following, recycled rows being expanded too. And I obviously want to have every row collapsed until explicitly expanded by user. So the thing is, the recyclerView doesn't scroll so smoothly, there is a noticeable scrolling lag as new rows enter the screen and the old rows leave it, or vice versa. When tested on a reasonably powerful device (LG G7 Fit) the experience is, frankly, quite jumpy. What can I do to optimize the performance (yes, I'm using 6 various sizes of images for various resolutions already). Is there perhaps a better alternative to the recyclerView that wouldn't need turning everything upside down?
FYI after an extensive testing I found that the most drastic improvement to the smoothness of scrolling is gained by reducing resolution of the images in the first (always visible) imageView.
When displaying a screen with various sections ordered vertically, where each section looks different than the other (so maybe recycling items wouldn't use an actual recycle but a recreation), would be any true benefit to use a recycling view group, taking into consideration that no large bitmaps will be displayed, instead of an plain ScrollView?
I suspect there is a performance impact when using ListView for example, that might affect scrolling, and an slight increased memory usage, maybe a delay (only when layout is measured - not that often) when using ScrollView, but are these that significant for 7 sections, for example, where 3 of them are visible at a time?
Thank you!
This is mostly speculation, but I would consider it relatively well-informed speculation.
Let's assume you have 1000 sections, each of them different from the other. My understanding is that both ScrollView and ListView will have "problems" here, though the sort of problems they'll each have will be different.
ScrollView will measure and lay out all of its children up front (which will probably be quite expensive and will probably cause quite a delay in your UI). And it will have all of those views inflated and hanging around in memory (which might cause your process to crash with an OutOfMemoryError). But if the delay were acceptable and if you had enough memory for everything, at this point your app should run perfectly smoothly (i.e. no frames dropped when scrolling/flinging).
ListView, on the other hand, will only measure and lay out those children that are currently on-screen, as well as a few extras that are immediately off-screen. So initial performance should be quite fast and memory consumption should be quite low. But you mention that each section is "different", so view recycling won't "work". In practice, this would mean ignoring the convertView parameter of getView() and inflating a new view each time. If your sections are complicated, this could easily cause frame skips during scrolling/flinging.
But you mention that your app will have only 7 sections, or about 2.5 screen's worth of UI. For such a small number, I think worrying about performance before simply trying something out is silly; I suspect that a ScrollView holding a LinearLayout holding all seven sections would work perfectly well on all modern devices.
I want to figure out the main effectivity issues of the Android layouts and views. I'm doing a research now but maybe somebody has answers already.
I have a RelativeLayout that is populated with views dynamically. Basically, the application loads a forum thread in XML and then renders the discussion tree so each message is displayed in its own group of views. I've decided not to use WebView because I want to implement some client-side functions that should be easier to do on custom views than on HTML page.
However this approach has a major flaw: it's heavy.
The first problem (which I've solved) was nesting of views. This is not an issue now, my layout is almost flat so the maximum depth is 10-12 (counting from the very top PhoneWindow$DecorView, the actual depth depends on data).
Now I've reached the next limit that is somehow connected to (or caused by) resource consumption of the views. After loading the data, the application hangs for a while to build the layout (creates the views and populates them with the data), and the hang time seems to grow linear with the data size; and if the data is large enough, the view will never appear (eventually the system suggests closing the application because it isn't responding).
Now the questions:
Does memory consumption depend significantly on the view class? In other words, is there any major difference between a Button and a TextView, or an ImageView? I can attach a click handler to any view so they don't differ much in usage.
Do background images affect the performance? If the same image is set in N views, will it make the layout N times heavier? (I understand that this question may look silly but anyway.)
Are nine-patch images significantly heavier than regular ones? What is better: to create N views where each has some background images, or to make one view that is N times wider and has a repeating background?
Given some layouts, what should be optimized first: overall number of views, nesting levels, or something else?
The most interesting. Is that possible to measure or at least estimate the resources consumed by the activity and its views? If I make some change, how could I see that I'm going the right way?
UPDATE
Thanks to User117, some questions that I asked above are now answered. I've used the Hierarchy Viewer and optimized my layout: compared to what I had before, the overall number of views is now reduced almost twice, and the nesting is also reduced.
However the application still hangs on a large forum thread.
UPDATE 2
I've connected the debugger to my device and found that the application gets out of memory.
But what is very unexpected for me is that the error occurs after I populate the layout. The sequence is as follows:
All my views are added. I can see a slight slow down as they are being added.
Almost nothing happens for a couple of seconds. During that time, a few info messages are spawned in the log, they are identical: [global] Loaded time zone names for en_US in XXXXms, the only difference is number of milliseconds.
The out of memory error message is spawned: [dalvikvm-heap] Out of memory on a N-byte allocation (the actual size varies). The long error reporting starts.
What does this mean? Looks like the rendering have its own demands that may be considerable.
UPDATE 3
At last I've found the core issue. Here is a screenshot from my application, see an explanation below the image.
Each message consists of a round button that shows or hides the replies and a red content frame to the right of the button. This is very simple and requires only 6 views including the layouts.
The problem is the indentation with these connection lines that show which message is related to which.
In my current implementation, the indentation is built of small ImageView's, each containing a square image that shows either empty space, or a vertical line, or a T-like connector, or a L-like corner. All these views are aligned to each other within the large RelativeLayout that holds the whole discussion tree.
This works fine for small and medium trees (up to few hundreds of messages), but when I try to load a large tree (2K+ messages), I get the result explained in UPDATE 2 above.
Obviously, I have two problems here. I spawn large number of views that all consume memory, and these views are ImageView's that require more memory for rendering because they render a bitmap and therefore create graphics caches (according to explanation given by User117 in the comments).
I tried disabling loading the images into the indentation views but got no effect. It seems like adding that huge number of views is quite enough to eat all available memory.
My other idea was to create an indentation image for each message that would contain all pipes and corners, so each message would have the only indentation view instead of 10 or 20. But this is even more consuming: I've got out of memory in the middle of populating the layout. (I cached the images in a map so two bitmaps with identical sequence of images weren't created, that didn't help.)
So I'm coming to conclusion that I'm in a dead end. Is it ever possible to draw all these lines at once?
Different View's are different kinds of Object. Some only draw() light weight stuff, some can hold large Bitmap Objects, and handler Objects and so on. So, yes different View's will consume different amount of RAM.
If same Bitmap object is shared among views, There's only one Object in RAM, each View will have a reference variable pointing to that object. But, not so when View draws: Drawing same Bitmap n times at n places on screen will consume n times CPU and generate n different bitmap_cache for each View.
Each side of a 9-patch image is actually bigger by 2 pixels from the original image. They are not much different as a file. When they are drawn, both can be scaled and will take almost equal space. The only difference is that 9-Patch are scaled differently.
Setting the background of the larger, parent view is better when the child views are transparent, and background will show through.
You can save a small image and set a tiled background so that it can fill a large area.
Nesting is to be optimized first, because all of the views might not be visible at a given time, let's say only a few views are visible in scrolling layout. Then you can cut down on total number of views used. Take cues from ListView: Given that user will be only seeing a sub set of total data at a time, it re-cycles the views. and saves a lot of resources.
SDK provides Hierarchy Viewer tool for this purpose. It shows a full tree structure of a running Layout, also places red flags for the sluggish parts of the layout.
A good layout is that which:
Easy to be measured (avoid complex weighted widths, heights and alignments). For
example instead of doing layout_gravity="left" for each each child, parent can have gravity="left".
Has less depth, each overlapping view adds another layer to be composited while screen is drawn. Each nested View Structure, asks for a chained layout call.
Is smart and re-cycles Views rather than create all of them.
Reuses its parts: tags like <merge> and <include>.
Update:
Answers to this question, show many approaches for a tree view in android.
I am building an application for Android (1.5) that, after quering a webservice, shows to the user a big amount of data that should be displayed in a "grid" or "table" style.
I must show a result of about 7 columns and 50 rows (for example a customer list with names, addresses, telephone number, sales amount last year and so).
Obviously, the 7 columns will not fix in the screen and I would like the user would be able to scroll up/down and LEFT/RIGHT (important because of the number of columns) to explore the grid results.
Cell selection level is NOT necessary, as much I would need row selection level.
What is the best approach to get this interface element? Listview / GridView / TableLayout?
I would suggest a grid with rows that are 'expandable' to show the child row containing a subset of the data that you could maybe consider as details. That way the user can look at data for the rows they are interested in, but ignore the rest.
By the objects you mention it looks like you're talking about .NET. In that case GridView will get your data displaying quickly (least programming) and in the most flexible fashion.
All you have to do is assign your contacts data to the grid view's DataSource member and you're done.
I don't know much about Android GUI programming, but the best approach for me would be using landscape orientation, few rows per page (like 5-10) and paging so that GUI will not get slow.
Check out the SlowAdapter, List13 example in the samples folder.
That might answer your questions.
On my PC the path is
"sdk folder"->android-2.1->samples->ApiDemos->src->com->example->android->apis->view
This 2 dimensional scrollview might be what you're looking for: http://androiddevblog.blogspot.com/2009/12/creating-two-dimensions-scroll-view.html
It is using a TableLayout so for reallly large datasets it might not be optimal because the views won't get re-used on scrolling. But 7x50 does'