4 ms·
> Battery life is still not acceptable How do you know this is an Android issue rather than a hardware-specific one? It's hard to come to a strong conclusion
by briandh 12y ago
> Battery life is still not acceptable
How do you know this is an Android issue rather than a hardware-specific one?
It's hard to come to a strong conclusion without having hardware that runs both iOS and Android.
Unless there are major power-oriented architectural differences in iOS, which I would be interested in hearing about if that is the case.
- deleted 12y ago[deleted]
- XorNot 12y agoIt's hard to come to thia conclusion without knowing what apps you're running - looking at you Facebook with chat turned on.
- fleitz 12y agoThere are huge power-oriented architectural differences. 1) Background an app, it doesn't use power. 2) ObjC doesn't keep gobs of unused memory around 3) Hardware / software integration allows things like spinning up the radios, doing all the updates, shutting the radios down. 4) C code runs lightyears faster (aka. uses less power) than java. 5) iOS uses the GPU rather than the CPU to do most rendering tasks, and provides great tools to let developers know when it's CPU rendered. 6) Instruments tells you exactly what code is using power. 7) Location services, if an app uses too much GPS you ban it from location services. 8) Timer coalescing allows the CPU to sleep more
- danieldk 12y agoC code runs lightyears faster (aka. uses less power) than java. First of all, it's not lightyears, usually only a factor of two. Secondly, iOS apps are usually written in Objective C, which uses dynamic binding, sacrificing part of C's performance. 5) iOS uses the GPU rather than the CPU to do most rendering tasks, So does Android: http://developer.android.com/guide/topics/graphics/hardware-accel.html#determining http://developer.android.com/guide/topics/graphics/hardware-... 8) Timer coalescing allows the CPU to sleep more The Linux kernel has timer coalescing (since 2.8.28).
- lumpypua 12y agoFirst of all, it's not lightyears, usually only a factor of two. That's true if you're running java on the jvm, android uses dalvik which is nowhere near as performant. https://code.google.com/p/android-benchmarks/ https://code.google.com/p/android-benchmarks/
- Yetanfou 12y agoBefore quoting performance comparisons it is a good idea to check whether they are up to date. That page compares a very early version of Dalvik (1.6 a.k.a. 'Cupcake') to native C and a server JVM with a smart-ish jit compiler ('hotspot'). The first release of Dalvik which contained a jit compiler was 2.2 ('Froyo'), comparisons for that versions with Java have been performed by Sun/Oracle [1] showing it to be about half as fast as Java SE embedded 1.6.0_21. Both the JVM as well as Dalvik have made speed gains in the intervening 3.5 (!) years. As of Android 4.4 there is an experimental new runtime (prosaically named 'ART' for 'Android RunTime'...) which pre-compiles as much of the code as possible to native code. The speed gains currently are subject of much debate.
- fleitz 12y agoHaha no kidding, only a factor of two... thats not much faster... If you consider that it generally takes about 1 year for mobile processors speed to double I'd call that a lightyear.
- Yetanfou 12y ago1) A backgrounded app on iOS is usually suspended immediately and as such comparable to a cached app on Android, neither uses power. Both platforms allow apps to continue to run code in the background, both platforms reclaim memory from inactive apps. Android is more flexible when it comes to running several tasks in the background, iOS is slowly moving in that direction. 2) What do you mean by 'keep(ing) gobs of unused memory around'? Neither iOS or Android keeps 'gobs of unused memory around', both use inactive memory for caching purposes. 3) The same is true for Android. 4) This has already been debunked in this thread. 5) The same is true for Android. 6) More or less the same in Android. 7) This is where Android runs behind iOS in the default configuration. Alternative distributions (Cyanogenmod, Paranoid Android, etc) do offer more fine-grained control over services, as do extensions like the 'Xposed framework'. The device needs to be rooted to install the latter. 8) as does the Linux kernel... It does not make sense to portray iOS as superior to Android because it isn't. Both platforms have their idiosyncrasies, both have their strengths and weaknesses. Android is more flexible, iOS offers more fine-grained control over permissions. The latter can be retrofitted to Android, while it is hard - and against the EULA - to add flexibility to iOS. Both platforms show the intentions of their creators: Google wants to know as much as they can about their users, Apple wants to have their 30% cut of anything done on or through their platform.
- fleitz 12y agoYup, it's all the same Android is totally on par with iOS yet somehow the battery life on a typical iOS device with actual real software installed and used frequently results in far higher battery drain than on iOS. Sure, the GPU is integrated now, but the graphics still chug on a Note 3. Sure, if you unwrap any two android and iOS devices they will be on par, ask two heavy android/ios users how long their battery lasts and you'll get vastly different answers.
- Yetanfou 12y agoThere are plenty of places where just these questions are asked, and answered. For Android I'd suggest looking around the xda forums. For reference, I use an oldish (launched in 2010) Android device (Motorola Defy) running Android 4.4.3. The battery generally lasts for 3-4 days before I get a low battery warning (meaning 14% left). Had I loaded the thing with constantly updating all-singing-and-dancing apps and widgets I'd need to charge the battery every day. Doing absolutely nothing the battery lasts for 28 days (from 100% to 2%). And yes, there are differences between Android devices, just as there are differences between cars and televisions and chainsaws and any other device which is produced in an open market.