@DavidOrtinau it's now March, can we get a concrete update on the status of perf improvements for Android? I keep checking github and the nightly builds but I still haven't seen any checkins related to perf. Why is that?
@TonyD said: @DavidOrtinau it's now March, can we get a concrete update on the status of perf improvements for Android? I keep checking github and the nightly builds but I still haven't seen any checkins related to perf. Why is that?
It tends to be in different branches, they've just committed some android fast renderers code (for button, image and label views) which eliminates the ViewGroup container around views and implements IVisualElementRenderer directly, so hopefully for complex layouts should give a boost to general smoothness & reduced inflate time.
@TonyD said: @DavidOrtinau it's now March, can we get a concrete update on the status of perf improvements for Android? I keep checking github and the nightly builds but I still haven't seen any checkins related to perf. Why is that?
I'd like to know that too.
What is the concrete \ actual roadmap of the Xamarin Forms product?
Does the Xamarin Forms team has a concrete\clear roadmap? Can we, devs using Xamarin Forms, see it please?
This page is just a discussion page on the upcoming features, but what is the actual \ concrete roadmap which the team uses ? Or is it a secret?
From my point of view, Xamarin Forms development continues on same blurry line.. A lot of promises, teams remains small, nothing changes... I guess it is what it is..
Evolution Forum also obviously has some discussion of other features that are being considered.
As it relates specifically to Xamarin.Forms and where it doesn't breach confidentiality with other parties, I think it's fair to say I'm not keeping any secrets.
As mentioned above, Fast Renderers work is in a branch. We did some work on layout compression as well, but need to address how it's implemented so as not to break other APIs.
You can pull and run anything on GitHub to check performance. Make sure to do a release build and not debug. When I have some results of our own to share, I will do so.
this is something actually on the concrete roadmap for Q2 2017 !? CSS Flexbox?
Yes, that's on the roadmap. It's slightly different now per the Evolution discussion. I'll update the description on the roadmap.
A word of caution as you continue to use the word "concrete". I want to make sure I'm setting the proper expectation for you. Please read the disclaimer on the roadmap post.
Is this a native app?
How would you the performance rate?
Caught it in Profiler
No escape from a slow UI inflate.
Open your App
Lookup the code and see
There is a breakpoint, but it's not being hit
Because the Viewgroup can come, the Viewgroup won't go
Memory high, Quality low
Any way the build goes doesn't really matter to me. to me.
Xamarin just checked in code
Put the method in a thread
Didn't try catch now it's dead
Xamarin, the exception had just begun
But now you've gone and thrown it all again
Scrum master, oo oo oo oo ohhhh
Didn't mean to make you cry
If the schedule is not back on time tomorrow
Carry on, carry on, as if this project never really happened
Too late, the meeting has come
Sends shivers down my spine
Boss is yelling all the time
Come on everybody, we"ve got to go
Gotta checkin everything and face the review
Xamarin, oooo ooohhhh
I don't wanna debug
I sometimes wish I never started coding at all.
I see a little little monkey making code,
Xamarin! Xamarin!
Will you compile to Android?
Code reviews and APIs
Bosses will not be happy!
DE ICAZA! (de icaza)
DE ICAZA! (de icaza)
De Icaza Help me please!
RuimarihnOOOooooo...
I'm just a poor dev, nobody loves me
HE'S JUST A POOR DEV, FROM A POOR COMPANY,
SPARE HIM HIS CODE FROM CODE REVIEWS PLEASE!
Nugets come, nugets go,
Will you let me code?
BCLBuild! No, we will not let you code!
XamlC! No, we will not let you code!
InitializeComponent! No, we will not let you code
We'll not let you code
We'll not let you code
No, No, No, No
Xamarin, Xamarin, (Xamarin, let me code)
GitHub has a branch that is put aside for speed, for speed, for speeeeeeeeeeeeeeeeeeeeeeeeeeeeeed
So you think you can make it build in a short time?
So you think you can expect us to meet the deadliiine?
Oooooh, Ortinau, can't do this to me Ortinau,
Just gotta write songs, write silly lyrics about all this
(ooooh, yeah, ooooh yeah)
UAT never happens, anyone can see,
My app won't happen,
Appstore won't accept meeeee
@LGMaestrelli@Irreal I have a lot of respect for developers, so after all this inexplicably wasted time, I'm beginning to think the XF team is intentionally botching and delaying Android perf because Google is a competitor to Microsoft.
I think is safe to say that most of us, developers, are disappointed with XF
Dude if you are disappointed with XF go to XF's github and make it better! Its open source!
I've been working with XF since 1.3.0 and I must say things are getting better since then, a lot better, its a great technology, but also complex.
Some errors are not from XF, are from VS integration for example. Indeed I'd like to see components to be more polished but I know its just a matter of time for that to happen. Meanwhile, relax, try to sing the Xamarin Rhapsody and make your C# skills do the rest.
I'm glad most people "got" it, but I do wish to clarify anyways that my intention was to have some light hearted fun at the expense of the state of Xamarin.Forms development.
I would never spend the time if I didn't actually love the framework and the community.
It is because I love it so, that I care and would like to see it become even better.
One of the problems is that we expected big resourced and hugely faster development with the Microsoft buyout and that just isn't there. At least not in a big enough way.
But we just have to deal with it and continue being a part of this awesome community.
Our company is really looking for one stop shopping of FORMS on all the major platforms. It's great to see MacOS on the roadmap, unfortunately since over 70% of PC users are still on Windows 7. Supporting MacOS won't be enough for us to move whole hog!!! How soon until we see support of Forms on Windows7. Or is Forms going to stop at UWP?
@Irreal said:
I'm glad most people "got" it, but I do wish to clarify anyways that my intention was to have some light hearted fun at the expense of the state of Xamarin.Forms development.
I would never spend the time if I didn't actually love the framework and the community.
It is because I love it so, that I care and would like to see it become even better.
One of the problems is that we expected big resourced and hugely faster development with the Microsoft buyout and that just isn't there. At least not in a big enough way.
But we just have to deal with it and continue being a part of this awesome community.
It IS an awesome community! Your post got a lot of love in the office.
I feel for those who experience frustration and pain, and real business impact. For my part, I cannot afford to stop and dwell there. Instead, I'm working to get you unstuck and moving in a positive direction by all means at my disposal.
A lot of you are having amazing success with Forms. I hope everyone has a chance to see the Visual Studio 2017 keynote yesterday and the fantastic Xamarin.Forms work that is featured. For anyone that has concerns about investment in the platform, I think that speaks volumes.
Where we as a team and community can point to any best practices or guidance to avoid pitfalls, let's do that. And where we can influence improvements in performance, stability, and closing feature gaps let's continue doing that.
All along the way I'm trying to improve communication and transparency. We won't always agree. But we certainly do agree we have a fantastic community, one we owe ourselves to encourage to achieve very best.
Total bugs are down. New bugs are getting swifter first look and responses. We are eating into the backlog of issues. Communication is up on Bugzilla, to make it more clear what we have reviewed and reporting on status. It's not perfect, and we're iterating. My reports are showing progress I'm very pleased with, especially moving issues from the New status forward (25% improvement weekly). All this results in the engineering team being better equipped to address issues and maximize their time. I believe we'll be seeing better fruits here in coming weeks and months.
We have several builds in the queue this week for updates to the pre-release regressions, as well as some individual web previews for performance and features. More to come.
Thanks for indulging me to share a bit. Now back to it.
For 2.4.0 - Est Q2 2017 there is 'Deprecation of iOS 6', but the release notes for 2.3.4.184-pre1 say this: '[iOS] Deprecate versions of iOS older than 8 (PR)'
Yes it is frustrating all these worries including performance with android, carouselview and more but I do not think either harass the team is beneficial. I think they are already putting pressure to themselves, especially if you want a quality result. I expect a lot like you from this update.
@RayTrask When Xamarin.Forms started, it featured Windows 8 Phone as a red-headed stepchild of a platform. UWP seems to be getting more support, but I wouldn't expect them to start targeting older, end-of-life platforms.
@RayTrask - WPF on Xamarin Forms is in the works (as speculated from tweets by Miguel), hence Windows 7 desktop support might be possible. We might see a beta of it later this year.
Also Windows 7 is 22.5% global, its less than 50% if you just look at Windows. Its slowly going down.
Can we get an update to the roadmap? What things have been completed, which things have moved up or down the priority list? is everything still on track? Nearing the end of Q1 now
Can someone please tell me what FlexBox gives us that we cant get from XAML with maybe just a few additions? I am a WPF dev as well and there really wasn't any layout we couldn't achievement in XAML with some code-behind.
@void I think @AdamHill's comment pretty clearly demonstrates it's not for "everyone".
In the same way that the existing XAML layout system is powerful and productive for some, others find the way a FlexBox-like system flows and adapts makes more sense. You can review it on the dev branch now. We'll be putting out a preview package shortly and will encourage anyone interested to give it a look.
@JamesHancock.1360 while I am a big fan of the CSHTML5/JSIL team what you are suggesting would actually be counterproductive to and for .NET. CSHTML5 and JSIL do not offer the capability of PCL or shared code between server and client. While this does make all the code more ".NET", you ultimately still end up with two incompatible codebases between client and server, and are left with the management/maintenance pains as such.
Xamarin is really the best thing that has happened to .NET since Silverlight. They really know their stuff. I myself would prefer to see XF become more of a Noesis-based client model whereby you have the ultimate freedom to create your controls/UX the way you would like without being constrained by platform expectations/constraints. Also, having to create a custom renderer for each custom control for each and every platform seems like a significant hurdle and a lot unnecessary work, especially when such concern is easily handled by theming/templates. You know, much like how the web operates.
Speaking of which @GiorgosPapadakis, Mono is currently being ported to WebAssembly so that will enable everything you know that runs on Mono to run on the Web. I myself am looking forward to checking out Noesis in full once this happens. ... or XF if it can adapt as well, accordingly .
@DavidOrtinau it's now April, what is the status of perf improvements on Android? I haven't seen any new check-ins in the android fast renderer branch for the last 4 weeks. When can we finally see some perf gains?
I have asked (regarding the performance) in the pre6 thread (in the hope for a feedback from some developers): https://forums.xamarin.com/discussion/87970/xamarin-forms-2-3-4-221-pre6#latest
Unfortunately - no feedback (I don't hope, this is bad sign...?)
I fully support the proposal of @rogihee: It really would be nice, if Xamarin would create a "performance benchmark app" (containing, specific pages with a lot of labels, a lot of images and a huge listview), would do tests with the benchmark app (at least with new "stable" versions) and let us know the results (startup time and specific pages)...
So we all could compare the platforms (iOS vs Android vs Windows) but especially the (hopefully) approved performance for each platform
This would especially make sense, as the performance further should be boosted for Android in the further releases this year.
2.3.4 is estimated for:
2.3.4 - Est Q1 2017
>
Q1 is over now... maybe an update of the roadmap would make sense...?
Thanks
@rogihee said: @TonyD@DavidOrtinau It would be nice to have some performance benchmarks as well between versions.
Cold startup time and layout performance. Is there a reference test app such as the gallery app that could be used as benchmark?
Good timing to discuss this! We are in the process of building out a gallery of common UIs specifically for measuring and tracking performance.
Would anyone be open to contributing some of your common UI from existing apps?
While we have a list and our own apps to guide what we will include in the tests, it would be most helpful to have a good selection from others in the community. I'm not looking for "best practices" or cleaned up code, but rather just what you are using. And just the layout, so hopefully that's an easy request rather than providing full production apps.
If anyone would be up for that, I'll perhaps organize another thread to discuss how we do that. We'll also want to get our solution up on GitHub for everyone to contribute to. We have a foundation begun, but to make it easy for everyone to contribute UIs we need to do more and I think seeing some of the UIs we will be testing would be very helpful.
Re: fast renderers, we have been reviewing and testing them. They will soon be in the nightly builds (I believe there's a merge PR in the works or awaiting review) and then our next pre-release. We have also scheduled to work on the other renderers, and then iOS. The commits on that branch aren't the whole story.
We have had some design discussions the past few weeks about Android performance specifically and are exploring additional areas of improvement.
Expect some announcements on release status and more this week.
Posts
@NMackay
Take a look at this: https://bugzilla.xamarin.com/show_bug.cgi?id=52760
@DavidOrtinau it's now March, can we get a concrete update on the status of perf improvements for Android? I keep checking github and the nightly builds but I still haven't seen any checkins related to perf. Why is that?
It tends to be in different branches, they've just committed some android fast renderers code (for button, image and label views) which eliminates the ViewGroup container around views and implements IVisualElementRenderer directly, so hopefully for complex layouts should give a boost to general smoothness & reduced inflate time.
@LGMaestrelli
I'm well aware of this issue, hence why we're stuck on cycle8 but at least we can debug.
I'd like to know that too.
What is the concrete \ actual roadmap of the Xamarin Forms product?
Does the Xamarin Forms team has a concrete\clear roadmap? Can we, devs using Xamarin Forms, see it please?
This page is just a discussion page on the upcoming features, but what is the actual \ concrete roadmap which the team uses ? Or is it a secret?
From my point of view, Xamarin Forms development continues on same blurry line.. A lot of promises, teams remains small, nothing changes... I guess it is what it is..
@DonBox this is the roadmap - https://forums.xamarin.com/discussion/85747/xamarin-forms-feature-roadmap/p1
Evolution Forum also obviously has some discussion of other features that are being considered.
As it relates specifically to Xamarin.Forms and where it doesn't breach confidentiality with other parties, I think it's fair to say I'm not keeping any secrets.
As mentioned above, Fast Renderers work is in a branch. We did some work on layout compression as well, but need to address how it's implemented so as not to break other APIs.
You can pull and run anything on GitHub to check performance. Make sure to do a release build and not debug. When I have some results of our own to share, I will do so.
@DavidOrtinau So you're saying that for example:
CSS with FlexBox Support - Feature, Enhancement
this is something actually on the concrete roadmap for Q2 2017 !? CSS Flexbox?
Yes, that's on the roadmap. It's slightly different now per the Evolution discussion. I'll update the description on the roadmap.
A word of caution as you continue to use the word "concrete". I want to make sure I'm setting the proper expectation for you. Please read the disclaimer on the roadmap post.
@DavidDunscombe @DavidOrtinau can you point me to this branch where those perf fixes are. I checked the main suspects on github and don't see anything.
@TonyD
https://github.com/xamarin/Xamarin.Forms/tree/android-fastrenderers
This is my current view of things in song format.
Xamarin Rhapsody
Is this a native app?
How would you the performance rate?
Caught it in Profiler
No escape from a slow UI inflate.
Open your App
Lookup the code and see
There is a breakpoint, but it's not being hit
Because the Viewgroup can come, the Viewgroup won't go
Memory high, Quality low
Any way the build goes doesn't really matter to me. to me.
Xamarin just checked in code
Put the method in a thread
Didn't try catch now it's dead
Xamarin, the exception had just begun
But now you've gone and thrown it all again
Scrum master, oo oo oo oo ohhhh
Didn't mean to make you cry
If the schedule is not back on time tomorrow
Carry on, carry on, as if this project never really happened
Too late, the meeting has come
Sends shivers down my spine
Boss is yelling all the time
Come on everybody, we"ve got to go
Gotta checkin everything and face the review
Xamarin, oooo ooohhhh
I don't wanna debug
I sometimes wish I never started coding at all.
I see a little little monkey making code,
Xamarin! Xamarin!
Will you compile to Android?
Code reviews and APIs
Bosses will not be happy!
DE ICAZA! (de icaza)
DE ICAZA! (de icaza)
De Icaza Help me please!
RuimarihnOOOooooo...
I'm just a poor dev, nobody loves me
HE'S JUST A POOR DEV, FROM A POOR COMPANY,
SPARE HIM HIS CODE FROM CODE REVIEWS PLEASE!
Nugets come, nugets go,
Will you let me code?
BCLBuild! No, we will not let you code!
XamlC! No, we will not let you code!
InitializeComponent! No, we will not let you code
We'll not let you code
We'll not let you code
No, No, No, No
Xamarin, Xamarin, (Xamarin, let me code)
GitHub has a branch that is put aside for speed, for speed, for speeeeeeeeeeeeeeeeeeeeeeeeeeeeeed
So you think you can make it build in a short time?
So you think you can expect us to meet the deadliiine?
Oooooh, Ortinau, can't do this to me Ortinau,
Just gotta write songs, write silly lyrics about all this
(ooooh, yeah, ooooh yeah)
UAT never happens, anyone can see,
My app won't happen,
Appstore won't accept meeeee
@Irreal I love it, this is great
@Irreal Can I get it on Spotify??
I think is safe to say that most of us, developers, are disappointed with XF
@LGMaestrelli @Irreal I have a lot of respect for developers, so after all this inexplicably wasted time, I'm beginning to think the XF team is intentionally botching and delaying Android perf because Google is a competitor to Microsoft.
Dude if you are disappointed with XF go to XF's github and make it better! Its open source!
I've been working with XF since 1.3.0 and I must say things are getting better since then, a lot better, its a great technology, but also complex.
Some errors are not from XF, are from VS integration for example. Indeed I'd like to see components to be more polished but I know its just a matter of time for that to happen. Meanwhile, relax, try to sing the Xamarin Rhapsody and make your C# skills do the rest.
I would never spend the time if I didn't actually love the framework and the community.
It is because I love it so, that I care and would like to see it become even better.
One of the problems is that we expected big resourced and hugely faster development with the Microsoft buyout and that just isn't there. At least not in a big enough way.
But we just have to deal with it and continue being a part of this awesome community.
Our company is really looking for one stop shopping of FORMS on all the major platforms. It's great to see MacOS on the roadmap, unfortunately since over 70% of PC users are still on Windows 7. Supporting MacOS won't be enough for us to move whole hog!!! How soon until we see support of Forms on Windows7. Or is Forms going to stop at UWP?
Thanks for the great work so far!
https://github.com/xamarin/Xamarin.Forms/pull/756
It IS an awesome community! Your post got a lot of love in the office.
I feel for those who experience frustration and pain, and real business impact. For my part, I cannot afford to stop and dwell there. Instead, I'm working to get you unstuck and moving in a positive direction by all means at my disposal.
A lot of you are having amazing success with Forms. I hope everyone has a chance to see the Visual Studio 2017 keynote yesterday and the fantastic Xamarin.Forms work that is featured. For anyone that has concerns about investment in the platform, I think that speaks volumes.
Where we as a team and community can point to any best practices or guidance to avoid pitfalls, let's do that. And where we can influence improvements in performance, stability, and closing feature gaps let's continue doing that.
All along the way I'm trying to improve communication and transparency. We won't always agree. But we certainly do agree we have a fantastic community, one we owe ourselves to encourage to achieve very best.
Total bugs are down. New bugs are getting swifter first look and responses. We are eating into the backlog of issues. Communication is up on Bugzilla, to make it more clear what we have reviewed and reporting on status. It's not perfect, and we're iterating. My reports are showing progress I'm very pleased with, especially moving issues from the New status forward (25% improvement weekly). All this results in the engineering team being better equipped to address issues and maximize their time. I believe we'll be seeing better fruits here in coming weeks and months.
We have several builds in the queue this week for updates to the pre-release regressions, as well as some individual web previews for performance and features. More to come.
Thanks for indulging me to share a bit. Now back to it.
@DavidOrtinau
i think there is a little error in the roadmap.
For 2.4.0 - Est Q2 2017 there is 'Deprecation of iOS 6', but the release notes for 2.3.4.184-pre1 say this: '[iOS] Deprecate versions of iOS older than 8 (PR)'
Yes it is frustrating all these worries including performance with android, carouselview and more but I do not think either harass the team is beneficial. I think they are already putting pressure to themselves, especially if you want a quality result. I expect a lot like you from this update.
@DavidOrtinau Have fun
@RayTrask When Xamarin.Forms started, it featured Windows 8 Phone as a red-headed stepchild of a platform. UWP seems to be getting more support, but I wouldn't expect them to start targeting older, end-of-life platforms.
@RayTrask - WPF on Xamarin Forms is in the works (as speculated from tweets by Miguel), hence Windows 7 desktop support might be possible. We might see a beta of it later this year.
Also Windows 7 is 22.5% global, its less than 50% if you just look at Windows. Its slowly going down.
@AdamP where did he say something related to wpf on forms?
@TobiasSchulz.9796
@TobiasSchulz.9796 While I know its a bit of shameless plug, I do keep a track of these things and mention them in my monthly newsletter (http://us13.campaign-archive2.com/home/?u=9bc39dc111f08d2a130409419&id=68a7cafa60) You can look at past issues to what they are like. It has 450+ subscribers and I rarely get an unsubscribe, so I hope that means I am doing something right
like this!!!
Thanks @AdamP
You're truly the Xamarin helper
Can we get an update to the roadmap? What things have been completed, which things have moved up or down the priority list? is everything still on track? Nearing the end of Q1 now
Now that almost every browser supports webassambly why not build something in XF and produce a web app!!!!
@GiorgosPapadakis Here here! And standardizes XF on UWP XAML too and compile to webassembly.
MS should just buy this: http://www.cshtml5.com/index.aspx
And integrate it tightly with shared .netstandard libraries and android/ios/uwp. One place to rule them all.
Since the CSS / FB discussion is closed.
Can someone please tell me what FlexBox gives us that we cant get from XAML with maybe just a few additions? I am a WPF dev as well and there really wasn't any layout we couldn't achievement in XAML with some code-behind.
So why FlexBox?
@AdamHill
Theres no good answer for that specific question.
But if you ask "why was FlexBox added" I believe the answer is "because we had already made it, and we thought everyone would love it".
@void I think @AdamHill's comment pretty clearly demonstrates it's not for "everyone".
In the same way that the existing XAML layout system is powerful and productive for some, others find the way a FlexBox-like system flows and adapts makes more sense. You can review it on the dev branch now. We'll be putting out a preview package shortly and will encourage anyone interested to give it a look.
@JamesHancock.1360 while I am a big fan of the CSHTML5/JSIL team what you are suggesting would actually be counterproductive to and for .NET. CSHTML5 and JSIL do not offer the capability of PCL or shared code between server and client. While this does make all the code more ".NET", you ultimately still end up with two incompatible codebases between client and server, and are left with the management/maintenance pains as such.
Xamarin is really the best thing that has happened to .NET since Silverlight. They really know their stuff. I myself would prefer to see XF become more of a Noesis-based client model whereby you have the ultimate freedom to create your controls/UX the way you would like without being constrained by platform expectations/constraints. Also, having to create a custom renderer for each custom control for each and every platform seems like a significant hurdle and a lot unnecessary work, especially when such concern is easily handled by theming/templates. You know, much like how the web operates.
Speaking of which @GiorgosPapadakis, Mono is currently being ported to WebAssembly so that will enable everything you know that runs on Mono to run on the Web. I myself am looking forward to checking out Noesis in full once this happens. ... or XF if it can adapt as well, accordingly
.
@DavidOrtinau it's now April, what is the status of perf improvements on Android? I haven't seen any new check-ins in the android fast renderer branch for the last 4 weeks. When can we finally see some perf gains?
@TonyD @DavidOrtinau It would be nice to have some performance benchmarks as well between versions.
Cold startup time and layout performance. Is there a reference test app such as the gallery app that could be used as benchmark?
I have asked (regarding the performance) in the pre6 thread (in the hope for a feedback from some developers):
https://forums.xamarin.com/discussion/87970/xamarin-forms-2-3-4-221-pre6#latest
Unfortunately - no feedback (I don't hope, this is bad sign...?)
I fully support the proposal of @rogihee:
It really would be nice, if Xamarin would create a "performance benchmark app" (containing, specific pages with a lot of labels, a lot of images and a huge listview), would do tests with the benchmark app (at least with new "stable" versions) and let us know the results (startup time and specific pages)...
So we all could compare the platforms (iOS vs Android vs Windows) but especially the (hopefully) approved performance for each platform
This would especially make sense, as the performance further should be boosted for Android in the further releases this year.
2.3.4 is estimated for:
>
Q1 is over now... maybe an update of the roadmap would make sense...?
Thanks
Good timing to discuss this! We are in the process of building out a gallery of common UIs specifically for measuring and tracking performance.
Would anyone be open to contributing some of your common UI from existing apps?
While we have a list and our own apps to guide what we will include in the tests, it would be most helpful to have a good selection from others in the community. I'm not looking for "best practices" or cleaned up code, but rather just what you are using. And just the layout, so hopefully that's an easy request rather than providing full production apps.
If anyone would be up for that, I'll perhaps organize another thread to discuss how we do that. We'll also want to get our solution up on GitHub for everyone to contribute to. We have a foundation begun, but to make it easy for everyone to contribute UIs we need to do more and I think seeing some of the UIs we will be testing would be very helpful.
Re: fast renderers, we have been reviewing and testing them. They will soon be in the nightly builds (I believe there's a merge PR in the works or awaiting review) and then our next pre-release. We have also scheduled to work on the other renderers, and then iOS. The commits on that branch aren't the whole story.
We have had some design discussions the past few weeks about Android performance specifically and are exploring additional areas of improvement.
Expect some announcements on release status and more this week.