Jump to content

Android - will it ever go native? And why isn't it native today?


Recommended Posts

The newest Android phones have insane - 2GB - amounts of RAM and 4 cores and most people - hopefully not the ones here - say "WOW! Android phones are SOOO much better than iPhones and Windows Phones cause they have WAYYY more memory and 4 cores! I'm buying an Android cause it's gonna be so much faster"

 

But the reason why they have so much memory and cores is because apps are written in Java which needs a Virtual Machine which needs memory and more processing power compared to a native app. I'm sure there's caveats to above statement but that's the gist of it.

 

And the sad part is that all the extra processing power still doesn't make up Java. Just compare the fluidity of Ookla's Speedtest app. The needle doesn't even stutter in Android; it updates at .2 frames/sec while in iOS it behaves like a needle, though this may be due to lazy use of the Android API.

 

So given its inherent limitation and ESPECIALLY on a mobile platform, WTF did Google use Java as their framework?

It's not as if people don't also know C++.

If you want automatic memory management in C++ like Java, use boost's smart pointer.

Done. [Chirp Chirp]

 

If Apple and Microsoft can make a native SDK, why can't Google?

  • Like 1
Link to comment
Share on other sites

Google doesn't use Java in Android.  It just uses the Java syntax to tap into the developer base that already knows Java.  I'm sure Android could do the Speedtest app like the iPhone if the developers wanted to.

 

The extra ram helps because Android's multitasking is more extensive than the other 2 platforms.

  • Like 1
Link to comment
Share on other sites

2GB of ram and quad/octo cores can make it so you can run awesome ass games that once had to be played on computers. you can now play on your phone and even plug in controllers to play them. It's also for multi-tasking and having split screens AND so apps can run in the background without lag. I had the First Android phone from Sprint and i have the gs3 now, It's amazing.

Link to comment
Share on other sites

Google doesn't use Java in Android.  It just uses the Java syntax to tap into the developer base that already knows Java.  

 

The extra ram helps because Android's multitasking is more extensive than the other 2 platforms.

 

Instead Java classes are compiled into Dalvik executables and run on Dalvik, a specialized virtual machine (VM) designed specifically for Android

 

http://en.wikipedia.org/wiki/Comparison_of_Java_and_Android_API

 

It's not just Java syntax but the use of a virtual machine that it calls Dalvik which is the same concept as the Java virtual machine and it's what makes Java SLOOOOOW. Are you familiar with garbage collection vs smart pointers?

 

Here's a nice history

 

http://news.cnet.com/8301-1001_3-57417144-92/android-java-and-the-tech-behind-oracle-v-google-faq/

 

It just uses the Java syntax to tap into the developer base that already knows Java.  

 

 

The developer base also knew C++ or would've easily transitioned to C++ from Java.

 

  I'm sure Android could do the Speedtest app like the iPhone if the developers wanted to.

 

 

You're sure? Did you ask Ookla developers?

Link to comment
Share on other sites

2GB of ram and quad/octo cores can make it so you can run awesome ass games that once had to be played on computers. you can now play on your phone and even plug in controllers to play them. It's also for multi-tasking and having split screens AND so apps can run in the background without lag. I had the First Android phone from Sprint and i have the gs3 now, It's amazing.

 

My point is that with native code, you wouldn't need so much RAM and quad cores.

 

Right now, Android is only usable and fluid on the latest hardware.

 

Regarding the octo-core thing: you'll only use 4 cores at a time no matter what.

Link to comment
Share on other sites

Instead Java classes are compiled into Dalvik executables and run on Dalvik, a specialized virtual machine (VM) designed specifically for Android

 

http://en.wikipedia.org/wiki/Comparison_of_Java_and_Android_API

 

It's not just Java syntax but the use of a virtual machine that it calls Dalvik which is the same concept as the Java virtual machine.

 

Here's a nice history

 

http://news.cnet.com/8301-1001_3-57417144-92/android-java-and-the-tech-behind-oracle-v-google-faq/

 

Yes Android uses Dalvik, NOT Java.  Ask Oracle if Dalvik is Java.

 

You brought up one app as an example, but do you really think Android is not capable of running the Speedtest app like the IOS version?  Or is it more plausible that not as much development went into the Android version?  The graphics are slightly different as well; do you think that's Dalvik's fault?

 

Other apps such as the browser and 3d games are much more demanding on system resources than the Speedtest app, and those usually run quite well.  The iPhone for the most part has the best gpu on the market, so that helps with 3d games, but 3d games that are optimized for high end Android phones also run quite well even with Dalvik.

Link to comment
Share on other sites

Yes Android uses Dalvik, NOT Java.  Ask Oracle if Dalvik is Java.

 

 

And Dalvik takes up system resources, right? Like memory and CPU time.

So why wouldn't Google go with the most efficient architecture? It's not a PC where you can throw in 8GB RAM for $50.

Link to comment
Share on other sites

And Dalvik takes up system resources, right? Like memory and CPU time.

So why wouldn't Google go with the most efficient architecture? It's not a PC where you can throw in 8GB RAM for $50.

 

Which architecture would that be that can run as many hardware variants as there are on Android phones?  There's not one Android phone like there is one iPhone, and if you look at the Windows phones there's not much variety here.

Link to comment
Share on other sites

Which architecture would that be that can run as many hardware variants as there are on Android phones?  There's not one Android phone like there is one iPhone, and if you look at the Windows phones there's not much variety here.

 

Why does "how many phones there are" imply that you have to use Java?

They all use ARM, MIPS or x86 so you compile your app three times and submit it to the app store.

Link to comment
Share on other sites

Why does "how many phones there are" imply that you have to use Java?

They all use ARM, MIPS or x86 so you compile your app three times and submit it to the app store.

 

Again - it does NOT use Java, it uses Dalvik.  And again - what architecture do you propose they use?  Do you expect low level machine language to get maximum performance out of every single app?  Dalvik is higher level to make it easier for compatibility across multiple hardware combinations.  Apple doesn't use low level machine language either - apps are developed using objective C.  It's easier to get max performance when you only have to focus on one hardware spec.  Same way consoles can match 3d game performance out of higher specced computers.

Edited by avb
Link to comment
Share on other sites

Again - it does NOT use Java, it uses Dalvik.  And again - what architecture do you propose they use?  Do you expect low level machine language to get maximum performance out of every single app?  Dalvik is higher level to make it easier for compatibility across multiple hardware combinations.  Apple doesn't use low level machine language either - apps are developed using objective C.  It's easier to get max performance when you only have to focus on one hardware spec.  Same way consoles can match 3d game performance out of higher specced computers.

 

 

And again, I know that but it's the same concept: they use a virtual machine. Do you understand what a virtual machine is?

 

No, I don't expect assembly language and I never said that; I said C++ several times.

C++ is also higher level and Android would still provide a framework like on windows: Qt, MFC, WPF, etc.

But a framework is different from a VM - assuming the framework is native code - and a framework doesn't introduce anywhere near the overhead that a VM does.

 

 It's easier to get max performance when you only have to focus on one hardware spec.  Same way consoles can match 3d game performance out of higher specced computers.

 

Yes I agree. But if Android apps were native vs VM-based, they'd be way faster . . . because of the Dalvik virtual machine.

Link to comment
Share on other sites

And again, I know that but it's the same concept: they use a virtual machine. Do you understand what a virtual machine is?

 

No, I don't expect assembly language and I never said that; I said C++ several times.

C++ is also higher level and Android would still provide a framework like on windows: Qt, MFC, WPF, etc.

But a framework is different from a VM - assuming the framework is native code - and a framework doesn't introduce anywhere near the overhead that a VM does.

 

 

Yes I agree. But if Android apps were native vs VM-based, they'd be way faster . . . because of the Dalvik virtual machine.

Which android apps are too slow?  I said earlier you only gave one example - the speedtest app.  And no I didn't ask the Ookla developers anything about the app.  I mentioned they use different backgrounds/graphics as well - do I need to ask them if that's because of Dalvik?

 

Is the Android browser too slow?  It performs just as well as IOS.  Same as 3d games.  The extra ram and processing power is because the Android OS has a lot more going on with the multitasking.  Dalvik is used to run apps, but I don't see apps suffering because of performance issues.

Link to comment
Share on other sites

C++? Really? Ewwww. While I'll agree that Android does occasionally suffer performance issues, I hardly think a move to C++ is the right way to go. That's just... no. Please. I'd rather something like this (CLR-based):

http://blog.xamarin.com/android-in-c-sharp/

Sure, you're still running a virtual machine, but the performance of dotnet-like languages is much closer to "native" code than Dalvik (although, it's a similar idea), without many other headaches that might be involved.

 

Anyways, part of Project Butter in Jelly Bean was Triple Buffering 60 FPS across the board. There's nothing special about user interface transitions that can't be used anywhere else (oversimplification but go with it).

 

The likely reason that the Android and iOS versions of Speedtest look different is that you have two different teams (you know, writing two different codebases), and iOS apps tend to have more development time and money sunk in to them, as well as tend to have more experienced devs. Dalvik/Java has absolutely nothing to go with graphics performance of a needle.

 

Really, the problem is the expectation of low-power embedded devices giving us similar performance to something like power-eating x86. If you think performance issues are an Android-only problem...

  • Like 1
Link to comment
Share on other sites

What's wrong with C++?

 

http://lmgtfy.com/?q=What%27s+wrong+with+C%2B%2B%3F+&l=1

 

If you want to code in C++ on a tiny embedded device, more power to you. I'd rather not have to code around my language of choice, and just code. Call me crazy, but I can't help but feel we're in 2013, not 1993...

 

And? What about the rest of my post?

Link to comment
Share on other sites

Well Intel is joining the mobile market with x86 processors and seems to be running away with the benchmarks so far even with dual cores up against ARMs quad core soc's. Sometimes it does depend on the Architecture. Imagine a quad core clovertrail with ddr3 64 bit up against ARM 32 bit processors. Who do you think would have a advantage? Don't forget, 32 bit can only address up to 4gb of memory space while 64 bit has no such limitation.

 

Link to comment
Share on other sites

Well Intel is joining the mobile market with x86 processors and seems to be running away with the benchmarks so far even with dual cores up against ARMs quad core soc's. Sometimes it does depend on the Architecture. Imagine a quad core clovertrail with ddr3 64 bit up against ARM 32 bit processors. Who do you think would have a advantage? Don't forget, 32 bit can only address up to 4gb of memory space while 64 bit has no such limitation.

 

This post has nothing to do with this thread.

Link to comment
Share on other sites

http://lmgtfy.com/?q=What%27s+wrong+with+C%2B%2B%3F+&l=1

 

If you want to code in C++ on a tiny embedded device, more power to you. I'd rather not have to code around my language of choice, and just code. Call me crazy, but I can't help but feel we're in 2013, not 1993...

 

And? What about the rest of my post?

 

Phone processors are tiny embedded devices.

 

What does a virtual machine give you that C++ and smart pointers can't?

Link to comment
Share on other sites

C++? Really? Ewwww. While I'll agree that Android does occasionally suffer performance issues, I hardly think a move to C++ is the right way to go. That's just... no. Please. I'd rather something like this (CLR-based):

http://blog.xamarin.com/android-in-c-sharp/

Sure, you're still running a virtual machine, but the performance of dotnet-like languages is much closer to "native" code than Dalvik (although, it's a similar idea), without many other headaches that might be involved.

 

Anyways, part of Project Butter in Jelly Bean was Triple Buffering 60 FPS across the board. There's nothing special about user interface transitions that can't be used anywhere else (oversimplification but go with it).

 

The likely reason that the Android and iOS versions of Speedtest look different is that you have two different teams (you know, writing two different codebases), and iOS apps tend to have more development time and money sunk in to them, as well as tend to have more experienced devs. Dalvik/Java has absolutely nothing to go with graphics performance of a needle.

 

Really, the problem is the expectation of low-power embedded devices giving us similar performance to something like power-eating x86. If you think performance issues are an Android-only problem...

 

 

You still haven't detailed why C++ is so "eww".

 

 

 

 

Anyways, part of Project Butter in Jelly Bean was Triple Buffering 60 FPS across the board. There's nothing special about user interface transitions that can't be used anywhere else (oversimplification but go with it).

 

 

You're totally missing the point of this thread.

Google did Project Butter as a result of Android's architectural limitation.

Yes, animations are now better but if they used native code, they wouldn't have had the problem in the first place.

And Android could run on cheaper hardware well.

Link to comment
Share on other sites

Here's a guy who knows more than all of us

 

But the latest versions of Android don't run well on such cheap devices, he claims. "Android 4 doesn't run on 256MB of RAM... it really wants a gig." And Eich believes that Google doesn't have a solution for that, other than telling developers to fall back to the lesser Android 2.3, aka Gingerbread. "Gingerbread is still being mass produced this year and will be mass produced next year," he claims, because Google doesn't have anything better to offer. Eich also thinks that Google's app momentum could be its Achilles' heel: "Android can't really slim down... they'd break compatibility."

 

http://www.theverge.com/2013/7/1/4484052/mozilla-cto-says-android-is-too-bloated-for-mass-market-phones

 

I'm not saying I like the idea of HTML-only apps. That's simply a quote from someone whose opinion is respected more than mine.

Link to comment
Share on other sites

Why would anyone learn ob C? You learn one proprietary language so you can do 1 thing and 1 thing only. Java means you have a job when apple goes belly up. Don't tell me it's impossible. RIM will remind you it is. Learn java and you can learn android pretty easily. Learn ob C and you better hope the app store stays open until you retire.

 

Sent from my SPH-L710 using Tapatalk 2

 

Link to comment
Share on other sites

Phone processors are tiny embedded devices.

 

What does a virtual machine give you that C++ and smart pointers can't?

 

You still haven't detailed why C++ is so "eww".

 

 

 

 

You're totally missing the point of this thread.

Google did Project Butter as a result of Android's architectural limitation.

Yes, animations are now better but if they used native code, they wouldn't have had the problem in the first place.

And Android could run on cheaper hardware well.

 

Yes, I know phone processors are tiny embedded devices. Isn't that what I literally just said? Why are you repeating me? o.o

 

Hoo buddy. Can't even have a personal opinion around here. I'm not going to spend all night detailing my issues with C++. If you like it (like I already said), go have fun. It's not bothering me.

 

And hold on - what evidence do you have that triple buffering and 60 FPS animations being implemented is due to architectural limitations? How could native code have made animations smoother? Without proper interpolation and whatnot you're sitting at "terrible", native code, Objective C on iOS, or Java/Dalvik on Android.

 

And let's just get this out of the way: I agree with your point. Virtual machines are slower than native code. That's a physical fact of the universe nobody is arguing against. Android runs slower than some other operating systems on the same hardware. And no, it will never be "native", unless a complete code rewrite and language migration is done, which is highly unlikely to happen unless Oracle really goes nutso.

 

At any rate, none of us are Google engineers who can make these types of decisions, so I actually don't see the point of this thread going on any further.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...