Jump to content
maximus1987/lou99

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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

no idea, I am not an android developer, I only play one on the interwebs.

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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.

 

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

 

Share this post


Link to post
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.

Share this post


Link to post
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.


  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Similar Content

    • By Handyman
      Just installed the 8.1 update on my Pixel.  Still no Sprint Wi-Fi / LTE calling
       
      But ... I did get the mandatory Google Search button added to my launcher.
       
    • By mikejeep
      Hello all,

      I have been visiting S4GRU for quite some time, and one of the most common issues I see popping up is confusion from users--especially when they first get 4G LTE devices and/or LTE service--regarding their signal strengths. For some reason, the signal bars on many devices do not display what most users expect them to display. It seems strange that we have to enter special dialer codes just to see what our LTE signal is!

      With that in mind, I started creating an Android app from scratch. I had never created an app before, so it took a few months before it was ready for the public, but its time has come. Robert and a few others have been beta testing it for me since October, and I recently released it onto Google Play. Robert gave me the go-ahead to give it a mention here on S4GRU, so here goes..

      It's called SignalCheck, and it is available on Google Play here: https://play.google.com/store/apps/developer?id=Blue+Line+Computing
       
      The "Lite" version is free; the "Pro" version has a small one-time fee but includes a bunch of extras, including signal bars in the notification area, a widget, the ability to alert a user when they pick up an LTE or 800 SMR signal, one-button instant connection reset, the street address of the connected 1X site, and menu shortcuts to some screens that are usually only accessible with dialer codes. I intend to offer S4GRU Premier Sponsors special benefits in the near future, as soon as I figure out a feasible way to do that.

      This is the first app I have ever developed, so I'd appreciate any and all feedback, both positive and negative. I have been trying to educate myself as much as possible regarding cellular technologies, as I didn't know much before I started this project. My goal is to make this app as accurate and useful as possible for all the "nerds" on here.. myself included!

      I intend to continue squashing bugs as they are reported, and adding features as they are requested. As I learn more about Android programming and cellular technology, I'll improve things. Please let me know what you would like to see, and I'll do what I can.
       
      My "Beta Crew" helps test out the app before public updates are pushed out. Membership is by invite only but anyone is welcome to join in our discussions or get a sneak peek at what is going on (see thread here).
       
      Links:  SignalCheck Help / FAQ  |  Change Log  |  To-Do "Wish" List  |  Known Issues  |  SignalCheck on Google Play
       
      -Mike
       
      Here are some screen shots from a previous version.. there have been tweaks since this release, but this is basically what you get:

         
    • By danlodish345
      hey guys i m curious what you guys think about rooting phones and the positives and negatives about it.... let the discussion begin!
    • By JDP121
      Supposedly it will be released on all major carriers in Nov. We will def. see how this will play out. 
       
      http://www.androidpolice.com/2015/08/18/blackberry-venice-android-phone-pops-up-in-a-few-more-promo-pics-courtesy-of-evleaks-allegedly-coming-to-all-carriers-in-november/
       
    • By derrph
      With the FCC and Sprint, T-Mobile, AT&T and Verizon have agreed to this new unlocking policy. How does this effect sprint phones such as the IPhone. I have heard that Sprint can unlock your phone but you can not take it to other carriers such as Verizon and the IPhone can only be used overseas.  (Correct me if I am wrong). I am glad that this has finally happened. But when it comes to Sprint how would this work?
  • Posts

  • Recently Browsing

    No registered users viewing this page.

×
×
  • Create New...