[kevingadd]

It's my understanding that this counter-intuitive performance problem with Dalvik is what crippled the original UI for Android Firefox - they were using their native C++ UI stack (the one used on Windows, Mac and Linux) to implement the whole browser UI, but they found that in practice a UI stack written in Java running on Dalvik performed better because it wasn't subject to all the weird performance penalties from interacting with android frameworks.

[acemarke]

I don't think that's entirely correct (yes, XKCD #386 applies):

First, I'd hesitate to use the phrase "native C++ UI stack". Mozilla's UI framework is XUL, which is a mixture of JS and XML. Presumably there's C++ underneath, but based on my reading it's a mixture of web-based technologies.

Second, because the original Firefox for Android UI was written in XUL, they had to load the entire Gecko architecture in order to render any UI. That was ultimately the performance issue, not "interacting with android frameworks".

Because of that, the goal of the rewrite was to be able to show the UI immediately, while loading the Gecko stack in the background.

There's some good info on this at http://starkravingfinkle.org/blog/2011/11/firefox-for-androi... and http://www.mozilla.jp/static/docs/events/vision/2012/04-mark... .

[fidotron]

This is intriguing - I had no idea that the Mozilla experience so closely mirrored my own.

The fun thing about Android is you can often spot when apps load the native code library since it generally leads to mysterious black screens during the loading of activities for exactly the kind of reasons mentioned there.

[lstamour]

I would point out to all the above commenters, that Chrome is still largely native code, with simple wrappers on iOS and Android. http://www.chromium.org/developers/design-documents/android-...

[fidotron]

Yes, but this also goes some way to explaining my assertion that such apps are disproportionately large and slow to start - Chrome exhibits exactly that behaviour.

When they get closer to having the OS WebView actually updated via Chrome channels then it's conceivable that the apparent startup time will come down, and it wouldn't surprise me if this is one of the main reasons for it.

If you see this recent thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink...

They even say this: "The web is quite far behind in mobile, which is why we're applying a greater amount of focus to solving the problems we have on mobile, even at the expense of nice-to-have features."

This is quite an admission, and at odds with a lot of their noise. It's also telling about their problems because Chrome suffers from a sort of death by a thousand cuts. On mobile to get the user experience people demand (they aren't wrong to be after 60fps performance as studies have shown mobile users are even pickier than desktop net users) you simply can't afford things like that anywhere, let alone right as the app starts up.

[corresation]

You seem to think that each of these posts is supporting what you claim, when it's doing nothing of the sort.

Firefox was slow because it had a very expensive abstraction layer that, while tolerable on a high power desktop, was just too much for what could be a low power mobile device. They didn't switch from C++ to Dalvik, they changed their GUI layers and how they initialize. This does nothing, at all, to support your claim about native apps being either slow to start or being large.

Nor does the Chrome bit. It's a large, full-featured browser. Further, on what is it slow to start?