Technology Android

[dilla]

Who the shit still makes CDMA-only phones? At least make it a world/global phone. I'm talking about a lot of the phones on VZW.

 

[ARon]

Messing around with an ICS build. Its in beta but a lot works. Except for wifi which sucks or id probably use it for a couple days. One thing i just noticed is when i use my trackpad in the browser a mouse pointer pops up, cool. ICS is fucking pretty lol. Cant wait til stable builds are out

The ok and cancel buttons have switched places, fucking annoying.

 

[Casey]

I saw a video uploaded yesterday of someone running an alpha build of ICS on the SGS2. Even as an alpha, it was smooth as fuck!!! CM9 is gonna fly on it!!! I'm hype for it.

 

[dilla]

Smooth is one thing. Everything being functional is another.

Bring ICS or HC to the TP!!

 

[Pittsey]

 

[Casey]

Smooth is one thing. Everything being functional is another.

Yes, hence why I'm waiting before I flash a ROM. I was just saying it's incredibly promising so far.

 

[masta247]

https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS

This actually fixes Dianne's explanation on UI smoothness and hardware acceleration. A great read, really. I didn't know a lot of things here.

Especially this explains why Android isn't as smooth as iOS and Windows Phone 7:

It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.

This is a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari. Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around. All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is intercepting all events and rendering the UI at real-time priority.

If you repeat this exercise on Android, you’ll notice that the browser will attempt to both animate the page and render the HTML, and do an ‘ok’ job at both. On Android, this a case where an efficient dual core processor really helps, which is why the Galaxy S II is famous for its smoothness.

On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished. Android tries to do both at the same priority, so the frame rate suffers. Once you notice this happening, you’ll see it everywhere on an Android phone. Why is scrolling in the Movies app slow? Because movie cover thumbnails are dynamically added to the movie list as you scroll down, while on iOS they are lazily added after all scrolling stops.

I take back everything that I said about it being cooler that iOS feels smoother than Android.
I mean - the issue should certainly get fixed - with multicore processors they could just dedicate a core for UI rendering, which is impossible with the way it currently works. But now I understand why it happens.

 

[dilla]

ICS theme on the TouchPad. Looks pretty neat.

 

[Casey]

Yeah, I saw that post. It's true that it's an issue of the past now. There's never any lag on my S2, because the Exynos is the best processor out there.

 

[masta247]

I also barely see any lag on my Arc but there's some lag on tablets, compared to the Ipad 2 they aren't as smooth. At least with Honeycomb.

 

[ARon]

Thanks for that masta. The one obvious question i have about that is how will ios do with multiple cores. It seems they'll have that issue until were at a processing power that can render everything instantly lol. I'm going to have to try that stuff on an iphone

 

[ARon]

Oh yeah. Who are some good people to follow friend whatever on g+. I hardly ever sign on but i want to start using it more.

 

[dilla]

http://feedproxy.google.com/~r/TheBoyGeniusReport/~3/vtuI98qY_yc/

 

[S O F I]

I take back everything that I said about it being cooler that iOS feels smoother than Android.
I mean - the issue should certainly get fixed - with multicore processors they could just dedicate a core for UI rendering, which is impossible with the way it currently works. But now I understand why it happens.

Did we read the same G+ post? I have more respect for iOS after reading this. Did you read the edited version of the post?

EDIT:[Several people (+Chi-Ho Kwok and +Brent Royal-Gordon especially) have taken the time to explain some mistakes I made in my description of iOS. The fundamental distinction between Android and iOS rendering I identified still stands, but I made some over simpliifcations in my description of iOS because I wasn't familar enough with the workings. I'll let +Brent Royal-Gordon explain:

"The iOS description here isn't quite accurate. There are several things at work:

1. Compositing and previously set-up animations—all the stuff that involves the Core Animation rendering layer tree—do indeed happen on a background thread.

2. Drawing new content into Core Animation layers and setting up their animations happens on the main thread. This is the same thread that user interface actions occur on.

3. In naively written code, all developer-written code would occur on the main thread. However, Apple provides very easy APIs (Grand Central Dispatch and NSOperation) to move things into system-managed background threads. In iOS 5, you can even declare that a Core Data (object-relational database) context cannot be used directly on the main thread.

All that stuff you noticed—the way images aren't drawn into lists while you're scrolling, the way WebKit rendering stops when the system is tracking a touch—isn't inherently built-in by a mechanism that pauses the world when a finger is on the screen.* It's deliberate behavior painstakingly implemented by the developer of each individual app.

This is not a technical difference; it's a cultural difference. Good iOS developers don't ship software until it runs at something near 60 fps while scrolling and tracks touches almost perfectly; good Android developers do.

and

Going Forward

Android UI will never be completely smooth because of the design constraints I discussed at the beginning:

- UI rendering occurs on the main thread of an app
- UI rendering has normal priority

Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone. So why did the Android team design the rendering framework like this?

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.

This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and started from scratch. Android is the only mobile OS left that existed pre-iPhone.

So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.”

Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:

- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed

It seems to me like the Android folk are a bit stuck in their ways and stubborn to change. While Casey always liked to mention that Android was in development before the iPhone, it's quite obvious that Android was built for non-touch screen devices and it shifted its strategy because of iPhone's release.

 

[masta247]

Yeah, I saw that all. The point is that it would be problematic to change it now.

The main difference here is that smoothness on Android directly reflects if the hardware is being challenged a lot as UI slows down along with everything else. An app makes your CPU go 100% and thus slow down - you will feel it because UI will slow down by as much. Usually both the UI and other processes will run though, just with some lags and slowdown.
On another hand iOS slows down everything just to run UI smoothly. You sacrifice the speed of things that really put a strain on your hardware just to pretend that it doesn't happen. So it might choke and struggle to work but it will keep the UI smooth just to give you an impression that there's no problem and your device is super fast.
So with Android they want you to go the "brute force" way and keep the UI system as it is by ensuring that the hardware is fast enough to handle everything you throw at it - that way nothing you do will slow down, and if nothing slows down the UI will be smooth too.

Basically the Android UI smoothness is tied directly to the overall performance of your phone. If it's lower for whatever reason the UI lags will directly reflect that. While at the same time the iOS UI will be smooth but at overall performance's expense.

A perfect solution would be a separate thread for UI so you could for example have one core dedicated to that and other X cores doing everything else beneath the UI layer at the same time, without freezing anything.
It would require a total reorganization of the way it's handled, which is a lot of work and trouble.

 

[S O F I]

Understood. I'm merely pointing out that I don't see how one way is better than another.

 

[masta247]

I'm not saying that the Android way is better. Both aren't what they should be.
It's just that I gave props to Apple and their Ipads for running smooth compared to Android on tablets, but it's not really the OS performance that is higher there - it's the UI that is smoother because of that little trick.
I still think that for an average human being the Ipad way will look way more appealing. But reality is that the Android UI lags because it does shit at the same time. So it sacrifices on both equally. While iOS sacrifices everything for UI performance.
Perfectly it should sacrifice only enough performance to be able to keep the UI smooth while still running other things in the background - without freezing anything but without sacrificing on UI performance because it's more important than a few percent faster process completion.
Also perfectly if you have a 4 (5) core CPU if one core is enough to handle "the UI process" you could make it do only that, while other 3 cores would do everything else. The problem is that only Apple could do that. With Android they can't do that because they have various types of devices with different CPU architectures and different amounts of cores so they have to make a different, more universal solution that would do at least okay on all devices.
The current solution seems to be good enough and universal, despite not being perfect. If you have a fast enough processor you will rarely encounter any problems.

I think that the Android way is pretty outdated and that's also what that guy pointed out. It's just hard to change.

 

[S O F I]

Also, there's this: http://jstn.cc/post/13829720580

I have no idea who's right but:

I can’t speak to the Android part, but I don’t think Andrew Munn is very familiar with iOS. UI rendering doesn’t happen on a background thread dedicated or otherwise, it happens on the main thread, and it doesn’t have anything to do with being “real-time” (unless you take that to mean “scheduled on a run loop”, which I don’t.) This is a big part of why Apple is constantly reminding developers to push anything they can into the background and leave the main thread free to draw and respond to user input. I would *love* for Apple to provide better support for drawing on background threads and/or in parallel, the only way to do it right now is using something called CATiledLayer but it’s very limited in scope and quite buggy.
Even though most of the iOS stuff in the post is wrong, Mr. Munn does a good job illustrating that the reasons behind Android’s perceived sluggishness are more complicated than a lack of hardware acceleration. All the hardware acceleration in the world won’t help a poorly written app on either platform, and UI responsiveness is a battle that has to be fought continuously using whatever tools are available.

 

[Casey]

It seems to me like the Android folk are a bit stuck in their ways and stubborn to change. While Casey always liked to mention that Android was in development before the iPhone, it's quite obvious that Android was built for non-touch screen devices and it shifted its strategy because of iPhone's release.

No. That post is mostly complete and utter bollocks and actually a lot of Goog employees are laughing at how wrong he is.

Number 1) The guy is a fucking intern. If you want, I'll talk to my cousin, a REAL software engineer on the Android team to clear it up.

Number 2) The guy is about to work for Microsoft on WP7 - trash the competition to try and get a full time job at MS perhaps? Laughably transparent.

Number 3) I have Z.E.R.O lag on my Samsung Galaxy S2 because it has a fucking badass Exynos processor in it. Believe, I've TRIED to make it lag. I've updated over 50 apps at once with about 20 background processes running. It doesn't fucking break a sweat. And I haven't even clocked it above 1.2GhZ.

Is it more of a challenge to make Android run without lag? Of course, it's open-source software designed to run on any and as much hardware as possible. Believe it or not, that's a MUCH tougher challenge than designing a dedicated OS for ONE fucking piece of hardware.

Number 4) Everybody likes to throw this picture around:

and say "ooooooh android was supposed to be blackberry style, when iphone came out they had to change it".

THOSE PEOPLE ARE FUCKING DUMB AND WRONG.

Yes, that's a prototype Android device from early 2007.

But guess what?

So is this:

Hmmmm what's that? Oh yeah - a touch screen.

Conclusion - pwned

 

[S O F I]

well, yeah, I mean, ask your cousin, point him to the article, and let us know specifically where the guy is wrong.