Slashdot Mirror
The Android Lag Fix That Really Wasn't
jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."
If the problem is that they can't generate "random" number fast enough, maybe they could just return 42 when the entropy pool is empty.
Have you read my blog lately?
This is why "vortex" generators for carburetors are still sold http://www.vorteccyclone.com/ , Magnets for your fuel lines to "align the molecules" http://en.wikipedia.org/wiki/Fuel_saving_device are still sold, and oddly shaped bicycle cranks http://z-torque.com/ are still sold. Its really no surprise that it happens in the software world too. Really, its been happening for a long time. Regcure, anyone?
Nobodies Prefect
Tidbits for Techs Technology Blog
but sent using Android, so...
The butter project was about latency with user interaction. The issues talks about /dev/random, which is totally unrelated.
My Google Nexus tablet begs to differ with your assessment.
I've only been using Android since 2011 and my devices have never had any kind of lag. Maybe because I have Nexus devices that aren't encumbered by third party skins and interfaces.
The problem is that xda is full of this kind of crap. Kernels which disable fsync (libEAT-MY-DATA, anyone?), exotic I/O schedulers and CPU governors, overclocking processors and other hacks... Very often, they do not have any measurable effect, or even cause new problems, such as freezes, hangs, sleep of death,...
I believe I stated modern. I would have no problem to tell you if my Nexus 7 or HOX lag, but they don't... I'm sure you can dig up a case where they lag, but normaly, they are fluid.
Here you go: http://download.cyanogenmod.org/?type=nightly .
There are a lot of comments on the bug report page. Clearly this is not a dalvik bug since dalvik does not use the /dev/random. But the other commentatros are still unsure that there might not be some issue in how randomness is generated in android from user input, which might induce lag.
Right now, some folks still investigate.
Because you can't fix stupid.
I can only speak for the Galaxy Tab 2 7.0, but modern Android devices are faster in part because of software performance improvements. Android 4.1 and 4.2 both have performance improvements, and upgrading the Tab 2 from the 4.0 it came with to 4.1 or 4.2 makes the OS visibly faster. The Nexus 7 comes with Jelly Bean (can't recall if 4.1 or 4.2 out of the box), so everything is fast to begin with.
In this way, Android is similar to Mac OS X - initial releases were rather slow, and subsequent versions (10.1, 10.2, maybe 10.3) were faster simply because there was a lot of easy optimization work to be done.
As an iOS user I didn't really like Android until Jelly Bean.
>> "didn't actually speed Android up."
If you actually read the bug mentioned in the summary - most devs are arguing that explanations about why the fixes work don't make sense in terms of Dalvik (java) that the android bug was filed against - not that it doesn't improve latency or that it doesn't work or there isn't a lower level issue. One developer https://code.google.com/p/android/issues/detail?id=42265#c162 (sorry I don't know enough about android to know if he is part of the core team or not) - is doing testing to measure results of a patch from the mainline linux kernel https://patchwork.kernel.org/patch/1745611/ plus some re-arranging of the android code to see if he has found a lower level solution.
This might be related to chrome.
Maybe you want to try firefox for android - it works quite well for me. If it turns out to be faster, it's still google's fault, but then you know the chrome guys are responsible, and not the android guys...
Having slogged through the linked discussion, there is no conclusion either way whether this effect is real or not. There are several theories on mechanisms that could cause an increase in responsiveness, but no conclusion. The most plausible seems to be that when the entropy pool is near empty, each input event causes a context switch as it is used to refill the entropy pool. Slower input handling obviously leads to poor responsiveness.
The summary seems to just be random android-bashing.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
Bad crypto can cause you no end of trouble. There are people out there who know what they're doing who've written PRNG systems in the general direction that you're talking about, but understand what to do and not do in the designs. Some of it's pretty subtle, like only bringing in new entropy in big chunks rather than trickling it in, and knowing what crypto algorithms work well for applications like this and what don't. And some of it's tuning.
Go read the "/dev/urandom" Wikipedia page. If you need Yarrow, use it.
The general speculation is that something in Android is using /dev/random when it would probably be ok with /dev/urandom, but nobody's sure quite what. Google Maps was mentioned; maybe it's using https to fetch map segments or something?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Reading that bug report makes me incredibly glad that I've only worked on open source developer tools, if the comments on that bug report are typical I imagine Google must have high turn-over of developers on the project.
but modern Android devices are faster in part because of software performance improvements.
Historically you can always get more performance improvements out of software than hardware. Software improvements of 100x on bottlenecks are not uncommon (Google for example has made a ton of them in search, http, maps, etc). This is the same as running on hardware that is five or six generations in the future.
The classic quote is that primality testing has benefited more from better algorithms than from 40 years of Moore's law.
Bullshit fanboy.
Even the Nexus 7 lags. I'll buy that you don't' notice it, but it most certainly does. I've had and returned two Nexus 7s hoping to find the lag had been fixed, but it hasn't.
Part of the issue is the way apps are written rather than the OS at this point I think. The play store is a prime example of visible lag that exists due to a poor app design.
Scroll through the play store on a nexus 7 device quickly and it'll scroll fine then stop cold in its tracks, which a sliver at the bottom of the screen saying 'loading' or something to that effect. Technically its not lagging, but it sure as hell FEELS that way. The simple solution is to get a total count at the start, then calculate how far you can scroll total and not stop scrolling to display the loading screen, just scroll into blank space.
This scrolling into black space and loading later is what you'll find on Apple written apps for iOS and is why iOS doesn't get the same perception.
Yes, I'm an iOS fanboy, but I've TRIED to be a Android fan and I just can't do it. Put them side by side and the built in Apps on iOS will feel far better than those built into Android. Actual performance is irrelevant. How they feel matters.
The only people I know that say Android isn't laggy are people who don't use iOS devices. If you have nothing to compare with, you just don't notice.
Yes, 4.1 is smoother than 4.0, Yes, 4.2 is smoother than 4.1. But the apps need worked now that the OS isn't as bad as it once was. I've seen Android apps that don't lag, but the default ones due. Chrome has the same sort of shitty lag when scrolling, where mobile Safari doesn't.
Perception is far more important than reality when it comes to user interface. Another thing as an iOS user that makes Android 'feel' laggy is the lack of rubber banding on scroll. Yes, the Nexus 7 has the blue glowy thing when you try to scroll past the end, but again as an iOS user, it feels like lag to me as the blue glowy isn't all that noticeable compared to the rubber banding. Yes, I understand Android previously couldnt' do rubber banding due to patent issues, but my point is that while Android may not ACTUALLY be laggy, it still is perceived as such due to the UI.
You can deny the perception, but it doesn't change it to most people and it will certainly remain one of those things that you're going to hear from iOS users until it changes.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Or you just don't notice it.
I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.
If all you use is Android devices, you probably don't notice.
Its not actual lag so much as poor UI choices that are perceived as lag at this point in my opinion, but I most certainly can 'feel' the lag.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Possibly. I never had a 'nexus', just the basic Samsung stuff. One problem that I noticed is when running 'drum kit' apps. I have tried some on my Android phone and several on my iPad (1st generation). On the iPad the drums react almost instantaneously. On the androids there's a noticable (and fatal) delay.
Did you ever try anything like that on you nexuses?
Apparently the OP didn't read the thread he alleges disproves the performance increase. There is actually a very lively discussion going on about it, and while there's a general agreement that it's not as simple as the /dev/random pool getting depleted, there is some evidence that it is related to locking in the UI (see comment 162).
I like to try drum kit apps ( I have kids ). But on my Android phone there's a perceivable (and intolerable) lag when you tap the drums with all the apps I tried. On iOS (1st gen iPad) they're all nearly instantaneous.
Ever try anything like that?
Don't get me wrong, I'm not an Apple fan, I'd like Android to win, but not by closing my eyes for its faults.
There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.
ONE: KILL-VS-SWAP
Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.
One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.
That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.
Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).
TWO: DISDAIN FOR 2D GPU ACCELERATION
Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.
Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.
THREE: ANDROID'S MEMORY-MANAGEMENT SUCKS
Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.
I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.
No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash aroun
Untrue. Modern Java (since 1.6, if not earlier) has nearly native performance on most platforms.
Android's "Java" problems are specific to DalvikVM inferior heap management strategy. Java 1.5 and newer does a VERY good job of dealing with mountains of short-lived objects that get promiscuously created, then discarded almost immediately. DalvikVM falls flat on its face, and ends up stalling to do garbage-collection.
Part of the blame lies with Android's strong (if not overwhelming) architectural preference for destroying and restarting activities, vs suspending them to swap. The truth is, Android handles long-lived processes VERY poorly... partly, because its preference for kill-and-relaunch has allowed them to sidestep the larger issue of managing resources with long-lived processes for several years now. That's the REAL reason why Gingerbread began actively killing even well-behaved background services that were running for "too long". Metaphorically, they were like a little old lady with a nice, neat house right smack in the middle of an urban block some developer wanted to bulldoze and redevelop with a skyscraper.
Sun had to grapple with the problem directly and solve it properly. When you have something like a web server written in Java that needs to be able to run for months without restarting, you MUST be able to hunt down insidious resource leaks, and keep them under control in the long term without being too disruptive at any moment in time. In contrast, Dalvik just ignores them until it runs out of space, then halts everything while it does garbage collection and moves things around.
This is actually one of the problems people who've experimented with adding support for swapfiles to Android have encountered. In order to make Android swap instead of kill, you have to modify its default behavior. The problem is, when you allow your Activities to live for hours or days instead of minutes, problems due to resource leaks that wouldn't get bad enough to notice start to become visible. As a practical matter, an Android phone with swapfiles forcibly enabled has to be rebooted at least once or twice a day, or the phone will start hanging to do garbage collection more and more often (defeating the point of having the swapfile in the first place).
Having spent significant time with iOS devices, I can safely say that the notion that they do not lag is FALSE. Having just installed iOS 6 on an iPhone 4, the lag between just opening and closing basic applications is definitely noticeable. Hell, even my father's iPad 2 lags, and it runs on iOS 4!
My S2 Skyrocket, on the other hand, runs Jellybean 4.1.2 just fine, and cases of lag are rare, if any.
The fact is, all devices, get laggy with use, and your bias against Android makes you ignore the lag that the shiny animations of iOS induce.
There is no perfect, lag-free device.
We're currently finishing up a fairly simple music app for Android with a couple of fun features.
In the beginning we were fussing around a lot with the Android UI and Audio APIs, as the lag when a user pressed a button widget until audio was played was very noticeable, we couldn't get rid of it. After hitting a brick wall we simply started from scratch using only a blank canvas, manually drawing buttons and handling events and the like and things worked perfectly.
So I the lag we (and probably everyone else) experiences has little to do with Dalvik but everything to do with the Android UI widget event handling, it causes unresponsive UIs.
I never noticed it before but now I see it all over the place. The only apps that don't have it are games and apps like ours who sidestep most of the Android Widget/Event API and go the manual route.
This sig is intentionally left blank
You can't have 0 latency audio drivers. But the latency can vary from system to system due to design decisions.
The main source of latency in audio drivers is related on how many audio samples are generated for each call to the interrupt handler (buffer size).
Bigger buffer sizes help avoid gaps in audio due to interrupt jitter. They also reduce the CPU load and energy usage which are very important in mobile devices.
Driver infrastructer for very small buffer sizes need to be designed very carfully to work reliably. So there are many reasons why android developers decided not
to use very small buffer. BUT of course for any kind of interactive audio low latency is crucial.
It seems like on Android, the less you rely on built-in libraries/APIs the better your app will be.
Which is the opposite of how things tend to go with iOS development.
When a user clicks (touches, slides, speaks, whatever) an object in the interface, the expectation is that the response will be immediate. Leaving aside communications delays, which users largely understand they have to live with, there is nowadays no excuse whatsoever for the device failing to respond instantly, even if only to provide feedback that acknowledges the interaction (for example when it involves an operation that is known to take measurable time such as opening an image file).
But the OS's own processes are regarded as sacrosanct, so the user interface just has to wait until they condescend to allow the user a few of their precious cycles. This happens on all end-user systems running multiple processes (leave IBM mainframes out of this :-) — just look at the time it takes to get a response from the Unity Dash, or the Gnome menu button, or the Windows Start button (or whatever it's called this week), or the Mac menu button...the first time you click it. It sits there loading its menus. Finally it lets you see them. You run your application, and for a short while, another click on the dash/start/menu will get a fairly swift response. Leave it a little longer, and it's been swapped out and takes another age to reload.
Developers, achitects, engineers, and programmers need to grasp the fact that their background processes must take a back seat when the user wants to do something. Their reply, quite naturally, is that their background processes are vital, essential, cannot be delayed or interrupted, etc etc. And quite right, some of them are. But it's their job to see to it that they are written and scheduled in such a way as not to interfere with the interface. Anything else is a design failure.
Can I root for no one to win, but for it to remain a stalemate with several competitors?
Or do we all need to wave the flag for one uncaring corporate juggernaut or another?
(Also, do we have to present credentials like this with every opinion we post? Would the validity of your opinion change if you were an Apple fan? Are we reddit?)
You do understand, don't you, that the reason the user interface has to wait isn't because developers think our processes are more important than the users.... but because the user interface DEPENDS ON THOSE PROCESSES TO BE ABLE TO DISPLAY!
Car analogy: You're complaining the the engine management computer insists on doing its fuel map calculations before responding to the throttle.
The time between clicking an app and it appearing on your screen is not lag. That is just the OS being a little slow. Lag is scrolling on the screen and having the graphics catch up with your finger. It's there and it has been perceptible on every Android phone I have used.
I have nothing against Apple perse, but I have serious issues with the closed nature of their iOS devices and especially how I don't have the ability to control what gets transfered on or off the device. Everything has to go through iTunes or some cloud solution.
Android has no such restricting policies, that's why I'd like to see it 'win'.
Or you just don't notice it.
I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.
If all you use is Android devices, you probably don't notice.
I found the opposite.
I only used Android up until work made me carry an Iphone 1 week out of every 4. Found that IOS was so slow compared to Android 2.3 (Gingerbread) but they just covered it up by using animations. It too longer to open the messaging application on IOS than on Android.
I timed them side by side, Android was much faster to open the application. The phones in question were an Iphone 3GS and a Motorola Milestone (Moto Droid) so they had fairly similar specs. This was on IOS version 3, when we updated to IOS 4 it slowed down horribly.
I tried it again recently comparing an Iphone 4GS to my (Samsung) Galaxy Nexus, there was an even bigger gap between Android 4.2 and IOS 4 (the owner hadn't updated to IOS 5 yet)
but I most certainly can 'feel' the lag.
Here's the problem. You "felt" it, you didn't test it. I actually tested it.
If you get lag on a Nexus device, you're almost certainly imagining it.
Now beyond this, I find IOS far more infuriating to use as it forces me back to the home screen every time I want to use another application where as Android has rapid task switching, not to mention the lack to text reflow. Even if Android lag was as bad as you said (and having run some really bad community ROMs on my Milestone and Desire Z, I've seen bad lag) it would not slow me down anywhere near as much as IOS is _designed_ to slow me down.
Calling someone a "hater" only means you can not rationally rebut their argument.