According to Facebook's documentation,
ListView - A core component designed for efficient display of
vertically scrolling lists of changing data.
FlatList - A performant interface for rendering simple, flat lists.
It seems both are efficient. What should we consider when choosing one from the other?
FlatList - More performant compared to ListView. ListView rendering can get slow once the number of items grows larger. FlatList significantly improves memory usage and efficiency (especially for large or complex lists) while also significantly simplifying the props — no more dataSource necessary!
Features
Flatlist is packed with new components full of features to handle the majority of use cases out of the box:
Scroll loading (onEndReached).
Pull to refresh (onRefresh / refreshing).
Configurable viewability (VPV) callbacks (onViewableItemsChanged / viewabilityConfig).
Horizontal mode (horizontal).
Intelligent item and section separators.
Multi-column support (numColumns)
scrollToEnd, scrollToIndex, and scrollToItem
Better Flow typing.
FlatList is still missing some features, like sticky headers, but it's evolving fast. ListView is going to get deprecated.
ListView is deprecated now and Sticky Headers in Flat list working now
Better options out there
I was getting performance issues while rendering 5000+ items in flat-list. Looked for other alternatives and found recyclerlistview - High performance list-view for React Native and web. Much better scrollTo performance and better rendering optimisations compared to flat-list.
Related
I have a ListView with different complex ListViewItem containers consisting of images, shadow effects, blur effects.. etc. Rendering these containers in large amounts heavily reduces performance, especially since i'm using a blur overlay frame on top of the ListView. Which is why in this case i'm setting CacheMode to BitmapCache (improves performance by up to 15x the fps).
<Border.CacheMode>
<BitmapCache />
</Border.CacheMode>
The problem is that i use a WrapPanel and a ValueConverter to dynamically resize and fit these containers into the WrapPanel so that they completely fill the space in either horizontal or tile views. Apparently, that doesn't work well with caching and it produces severe lags/stalls (frame drops to 0).
Currently my 3 options are:
Disable caching (and live with almost 15fps)
Disable resizing (looks unacceptable)
Disable caching and resizing only when resizing window (still performs bad but it's the best option i have)
My questions:
Why do i get these huge drops in performance while resizing with caching vs without caching?
Am i misusing caching or doing it wrong?
Is there a better way of fixing this mess without compromises?
Ok. After a lot of reading and experimenting, i figured two things:
First, Caching should not be used on elements that resize frequently, especially if they're too many (couldn't find out why). So, i basically cached fixed size child elements instead.
And that reminded me of Virtualization which was exactly what i was missing but didn't know was supported in WPF Lists.
With some more optimizations, now, i can resize the window buttery smooth.
React DnD doesn't appear to scale well.
I have a list of five hundred drop targets and it take several seconds to pick up an element.
Is there anyway of speeding this up?
The list scrolls perfectly smoothly.
I'm using react-virtual to reduce the number of DOM elements in existence, although unfortunately the drawing performance is well behind native rendering.
Also, a helpful thread...
https://github.com/react-dnd/react-dnd/issues/421
While technically you can stretch React DnD performance to ~3000
items, there’s no way for it to not lag after a certain point without
changing the API (and making it less useful). If you have thousands of
rows, I think you should be using virtualized lists anyway.
"Use the new FlatList or SectionList component instead. Besides simplifying the API, the new list components also have significant performance enhancements, the main one being nearly constant memory usage for any number of rows."
This is stated on React Native's official docs. However, no matter how hard I try, FlatList memory uses just keeps sky rocketing when scrolling down. Compared to ListView component which uses way less memory.
TLDR
Create a PureComponent to use in renderItem:
class ListItem extends React.PureComponent
Then you need to be sure you implement shouldComponentUpdate
Also I seem to have performance issues when I have a FlatList inside of a ScrollView
So I have been messing this this all day trying to figure out why the FlatList was blowing out my RAM usage and sucking my battery dry with my list of several thousand. What I was seeing was renderItem was called for each item multiple times. If I had a 100 items, renderItem would be called once for items 1-10, then again for items 1-10 and once for items 10-20, then again for items 1-20 and once for items 20-30 and so on. This baffled me as to why this was happening. But what I realized was that without any optimization that meant that it was reconstructing every item in that list and growing exponentially. To solve this problem here is what you need to do:
Create a PureComponent like they suggest in the docs for optimizations:
class ListItem extends React.PureComponent
Then you need to be sure you implement shouldComponentUpdate
Once I did those two things my JS FPS and RAM usage remain level until I scroll where there is a little dip and spike respectively but the important part was they came back to a nice level. This is compared to before where I was seeing 1 FPS from JS and over a gig of RAM usage.
It seems like FlatList renders as many items as it can and the further away it gets from the items that are visible the lower the priority it gives rendering of the items. It keeps the items that are not on the screen stored virtually so that they can be pushed to the screen right away when the user scrolls. This can lead to runaway memory usage with large lists if you do not optimize the component rendering method.
I am experiencing some delay in rendering part as my page contains lots of components like (inputs and labels etc). I have placed them in panelgridlayout.
I also used audit method in jdev there also found lots of time is taken by rendering.
So, I want to know which component will be the best or suitable for this. I also implemented panelGroupLayout (with horizontal and vertical) and panelfromlayout but has same slow rendering problem.
Please help me on this.
You need to check how many layout managers you have inside of others. Too many layout managers inside one another can affect render speed.
PanelGroup Layout is for taking a "small" island of content and making its contents horiz, vertical - like buttons or fields or even groups of other islands of content - or add scroll bars if needed, like for a table.
PanelGrid layout is designed to layout a "larger" area and give the layout a grid and allow you to place items almost exactly where you want it.
Some layout managers are designed to layout "the whole page" - like PanelStretch, PanelSlider and PanelGrid, while others are for specialized tasks or group of content, like PanelGroup, FormLayout, Tab, Accordion.
So, depending on the layout, using PanelGrid may mean you do not need the others, and can simply free position all the item which may speed up rendering.
That said, there are many variables that affect rendering speed, and the complexity of the items on the ADF Faces page is not the first thing we look at - The ADF Model layer, how that is implemented and how the data source is tuned (or not) can be a bigger source of impact on rendering.
You did not specify version, that would help as well.
Before PanelGrid we tended to use PanelStretch or PanelSlider as the main window layouts that laid out the main sections of the page - and put the other ones - panel group and formlayout inside it. With the advent of PanelGrid, some of this practice is no longer needed.
This, this and this may help as well.
I'm working on a form that shows many our company's products in a FlowLayout, but on some categories that hold many products, performance in scrolling is noticeably affected. I switched to a List so I could leverage the performance benefits of using a renderer, but now I'm not happy with the layout since there's a lot of wasted space, especially if the device is in landscape mode.
My next thought was to use a Table, which I believe also uses renderers to optimize the display of its data; but to mimic a FlowLayout, I'd need to get the preferred width of some placeholder component, then divide the container's width by that to get the number of columns, and then fill the model with that number of columns in mind. I'd also need to change all that if the device changes orientation.
Before I go down that rabbit hole, I'm wondering if I'm making things unnecessarily complicated for myself and if there's already something that I can use to achieve that goal. So to summarize, what would be the most efficient way to display data (that would be shown as buttons) sequentially from left to right, and top to bottom?
I wouldn't use FlowLayout for anything serious although I doubt its the reason for your performance issues, those probably relate to something else. There is a performance how do I video which is a bit old but mostly still relevant: http://www.codenameone.com/how-do-i---improve-application-performance-or-track-down-performance-issues.html
In design terms flow layout is hugely problematic since the elements are not aligned properly thus producing a UI that doesn't look good when spanning multiple rows. I suggest using a grid layout which has a mode called auto fit. By using setAutoFit(true) on a grid of even 1x1 all the elements will take up all available space uniformly based on screen size and adapt with orientation changes.