Thanks for the feedback. Keep in mind, these are not requirements. These are tips to help solve issues you might run into after identifying you have a performance problem. We do provide lint checks wherever we can and continue to add more.
I believe it's a clear indicator of significant design deficiencies when individuals must be instructed in numerous performance optimization techniques just to make basic use cases such as a rendering a bunch of list items function efficiently on today's hardware.
am I the only one who thinks that all of this is very difficult to remember? I have more than 5 years working with Android and everyday there's something new to improve
This is not something to remember, this is something that you want to understand in a fundamental level. Checkout the thinking in compose doc and it all makes sense. You don't need to memorize all these, it's a paradigm.
i know this is almost a year old, but could you please add timestamps? this is quite a lot to digest so we need it to go back and fort to rewatch specific topics.. thanks
Lambda modifiers aren't always more performant, they just can be in certain situations. If you don't have frequent changing state, a standard modifier will be more performant.
I had a doubt that will if i have two composable nesting from a parent composable, and there is a mutable list passed to the first child but no change occurs to second child but it still recomposes. But if the parent is itself part of a list than will all the instances also recompose runtime or only the particular list item affected ?
@@litpen8056 ok, got it! Actually I asked this, seeing a nested composable in one of my apps is incredibly slow on a fast fling scroll. And I cannot use the lazy column as it doesn't support nesting.
Compose is looking for minimal possible scope that needs to be recomposed. scope is function where State is read. if State is read inside "Parent" than "Parent" becomes scope, if it's read inside "Child" than "Child" becomes scope. but when State is read inside of lambda and that lambda becomes the scope and only it and it's children are/might be recomposed. here it has no children so only it, lambda, is recomposed, Compose doesn't have to look up the tree for the scope anymore.
day by day, they are discovering how compose is complex and it is not easy to maintain 😂😂 thanks, but i will continue to work with activities and fragment happily 🎉
@@estebanhiguitaduarte1318 if your project is small go ahead you can play with compose, but in a big scale project, i definitely not recommend to migrate. Just example from this video they suggest to use ImmutableList instead of List. And they say it is just a fix. So, in the future they may ask you to use Immutable Int or Immutable String to just make a performance fixes 😂. In my opinion compose has a very long way to take fragment xmls places.
Man, stop disgracing yourself leaving these comments. Did you ever try to optimize RecyclerView with various item types? Do you think parsing XML file is a way to go to layout user interface? Do you like View's lifecycle?
![[Part 1] รักมาไม่ทันตั้งตัว❤ หนุ่มสาวโสดถูกจับมาแต่งงานกันกะทันหัน แถมเธอยังเป็นหัวหน้าของเขา?!](http://i.ytimg.com/vi/y2pOOMkuFI0/mqdefault.jpg)
That's a lot to remember and check. Please move as many checks into Android Studio warnings as possible!
Thanks for the feedback. Keep in mind, these are not requirements. These are tips to help solve issues you might run into after identifying you have a performance problem. We do provide lint checks wherever we can and continue to add more.
@@bentrengrove8024 True 🙂
I believe it's a clear indicator of significant design deficiencies when individuals must be instructed in numerous performance optimization techniques just to make basic use cases such as a rendering a bunch of list items function efficiently on today's hardware.
dear god. I need to cry a bit
great presentation. I like "tools over rules" approach and frequent disclaimers
am I the only one who thinks that all of this is very difficult to remember? I have more than 5 years working with Android and everyday there's something new to improve
then later on, after mastering this library, a new library is introduced.
This is not something to remember, this is something that you want to understand in a fundamental level. Checkout the thinking in compose doc and it all makes sense. You don't need to memorize all these, it's a paradigm.
amazing, understanding compose day by day
Jetpack compose es una gran herramienta de trabajo
should we use remember in the latest version for derivedStateOf?
Thank you for this video! Performance tips are always helpful. 🙏🏻
i know this is almost a year old, but could you please add timestamps? this is quite a lot to digest so we need it to go back and fort to rewatch specific topics.. thanks
Very thanks
It was very interesting, thank you so much )
That's lot to remember
Then why even have non-lambda modifiers, if they are most of the time less performant??
Lambda modifiers aren't always more performant, they just can be in certain situations. If you don't have frequent changing state, a standard modifier will be more performant.
I had a doubt that will if i have two composable nesting from a parent composable, and there is a mutable list passed to the first child but no change occurs to second child but it still recomposes. But if the parent is itself part of a list than will all the instances also recompose runtime or only the particular list item affected ?
cannot skip if parameter is unstable or mutable state parameter changes. that is it. from understanding.
@@litpen8056 ok, got it! Actually I asked this, seeing a nested composable in one of my apps is incredibly slow on a fast fling scroll. And I cannot use the lazy column as it doesn't support nesting.
does anyone know where to find -composables.txt file?
Very informative 👍
Awesome!
is interfaces are stable?
Hello everyone. Could you explain me, why using lambda in 6:04 is more perofrmant ? I dont understand why and how it works. Thanks!
Compose is looking for minimal possible scope that needs to be recomposed.
scope is function where State is read.
if State is read inside "Parent" than "Parent" becomes scope, if it's read inside "Child" than "Child" becomes scope. but when State is read inside of lambda and that lambda becomes the scope and only it and it's children are/might be recomposed. here it has no children so only it, lambda, is recomposed, Compose doesn't have to look up the tree for the scope anymore.
@@markonovakovic3838 in summary from understanding,
lambda creates a child scope, making sure the parent scope is not touched/recomposes.
How Google devs sleep 😴 after creating another "best practice more performance industry standard" code to remember every 6 months.
day by day, they are discovering how compose is complex and it is not easy to maintain 😂😂
thanks, but i will continue to work with activities and fragment happily 🎉
@@estebanhiguitaduarte1318 if your project is small go ahead you can play with compose, but in a big scale project, i definitely not recommend to migrate. Just example from this video they suggest to use ImmutableList instead of List. And they say it is just a fix. So, in the future they may ask you to use Immutable Int or Immutable String to just make a performance fixes 😂. In my opinion compose has a very long way to take fragment xmls places.
and the perfect title can be honeymoon is over let's face with realities
Man, stop disgracing yourself leaving these comments. Did you ever try to optimize RecyclerView with various item types? Do you think parsing XML file is a way to go to layout user interface? Do you like View's lifecycle?
TopAppBar scrollBehavior still janking so much . Like exitUntilCollapsed Behavior() - > with nested connection to lazyColumn . So much janking fix it
Beta tester od roku 2016 oceňujem,,