2016-04-22 18:14 UTC Flutter: Performance and testing
Over the past few weeks the Flutter team has been mostly focused on performance and testing.
For performance, the first step of course is measurement. To this end, Yegor has started doing continuous automated testing on actual devices, so that we have a clear baseline against which to measure our progress. Of course to make that useful we have to have performance tests, so Viktor wrote a test with some complicated layouts. This immediately uncovered that my MixedViewport class was terrible, so Adam rewrote that as LazyBlock. And on it goes.
LazyBlock is pretty neat. Instead of just giving it a list of children, you give it a delegate that produces children on demand, and LazyBlock only asks it for the children that it needs. As you scroll, it throws away the earlier children, and asks for the next ones. If you go back up, it does the same thing backwards. Eventually we'll even make it guess the right child number if you jump scroll, so that you can jump around a huge list of children without ever having to pay the cost of drawing any children other than the ones on the screen.
One widget we don't yet have is a LazyTable. That's something I plan to add soon. I did implement DataTable recently, you can see the demo in our gallery app which exactly matches the sample in the Material Design specification. The next step though is a paginated version and a scrolling version, reusing the same delegate approach that Adam used for LazyBlock. (Tables are tricky because you have to figure out what size to make the columns; for DataTable, it actually measures every cell before laying out any rows, which is quite expensive. For LazyTable, we'll have to use either fixed width columns or flex-style sizing.)
Lots of other work on performance has been going on too. Eric and Devon hooked things up so that from the Atom editor you can now with one checkbox turn on and off our PerformanceOverlay widget and our "repaint rainbow" feature, live while your app is running. Hans has been working on improving the performance of our gallery app. Seth has been running lots of our demo apps tracking down any where we miss frames and filing bugs on them. We even had the help of a nine year old yesterday, who found a bunch of bugs for us!
You can see a screenshot of the checkbox on the PR: https://github.com/dart-atom/dartlang/pull/960
The other big push recently has been on testing. As we like to say, "write test find bug". The problem is that writing tests for Flutter has been a bit difficult so far, because you can't see what you're testing.
Yegor has been working on a way to test on-device, using "flutter drive", and as part of that he redesigned our API for testing in a way that makes a lot more sense. (Flutter drive is what he used to do the continuous performance testing I mentioned earlier.) I've now picked that up and I'm taking it to its logical conclusion: make it so that even for our unit tests, you can actually see what's going on if you run them on a device. The hope is that this will really simplify writing tests for Flutter, which will mean we write more tests (and hopefully will mean people writing apps for Flutter can write more tests, since we use the same testing strategy for people writing Flutter apps as we do on Flutter itself), which will mean finding more bugs!