The Android Lag Fix That Really Wasn't 226
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."
article doesn't make sense. (Score:5, Interesting)
Re:How important is "true" randomness, anyway? (Score:5, Interesting)
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.
It depends on what you are doing with that entropy. Cryptographic applications, probably best not to mess with. Mathematical simulation work? Please consult your handy local PHd, spawning little spaceships in your arcade game clone? Probably not an issue.
Because it's really application dependent, Linux has two ways of asking the kernel for entropy: Reading /dev/random will pull from the kernel entropy pool and block if the pool is empty. How fast the pool refills depends on the hardware platform, presence/absence of dedicated cryptographic hardware, interrupts and network activity, etc. Reading /dev/urandom will never block; but the results may be unsatisfactorily random if the entropy pool is low.
In either case, applications are also free to use material from /dev/random or /dev/urandom to seed their own PRNGs.
Re:Does it matter? (Score:4, Interesting)
My Google Nexus tablet begs to differ with your assessment.
Re:Does it matter? (Score:5, Interesting)
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.
Just finished reading the whole thread (Score:4, Interesting)
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.
Re:Does it matter? (Score:5, Interesting)
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.
Re:Does it matter? (Score:3, Interesting)
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...
The jury seems still out on this (Score:4, Interesting)
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.
Re:Does it matter? (Score:5, Interesting)
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.
Re:Does it matter? (Score:2, Interesting)
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.
Re:Does it matter? (Score:5, Interesting)
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.
Re:Does it matter? (Score:5, Interesting)
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 four things that make Android laggy (Score:5, Interesting)
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 around like a dying fish. They might have been relevant in 2008, when Android had to run on phones with the hardware specs of a G1 or Hero. This is 2013, RAM and flash are cheap, and the lack of microSD cards for safe throw-away flash on Nexus devices is 100% Google's fault and can be remedied by putting them on new Nexi going forward.
Anyway, the fact that Android's API is so neurotic about the creation of transient and large objects is part of the reason why apps get laggy when doing things like scroll. On a PC, a Java app would usually just create and populate the whole list at once, unless you're talking about a list that's so staggeringly multi-gigabyte huge, it's literally impossible. On Android, you're practically forced to build the list piece by piece, over and over again, tearing it down and rebuilding one tiny segment from scratch every time. Apps that insist on doing this via realtime Ajax calls (goddamn, I hate Ajax... it used to only be web apps that sucked and were laggy; now, its endless request-response latency has infected real apps, too) just compound the problem.
FOUR: ANDROID'S DEFAULT CPU GOVERNORS MAKE AN ANNOYING PROBLEM INTOLERABLE
Android's default CPU governors suck. Just about everyone I know prefers the performance-oriented governors, like "interactive" or "smartass". Manufacturers, looking to maximize their battery benchmarks while shipping phones with anemic, undersized batteries just so they can be as thin as the latest iPhone, overwhelmingly prefer governors like "ondemand".
Most of the time, they don't even bother to compile 'interactive' into the kernel as a silent, unsupported option. What's the difference? Interactive gives a high priority to UI interaction and "race to completion" strategies. When you turn on the display or launch an app, it instantly kicks up the speed to 100%, and backs down slowly... and ONLY when almost nothing whatsoever is happening. In contrast, 'ondemand' tries to keep the phone running at 50% speed or less most of the time.
Governors like 'Ondemand' combine with Android's preference for killing and restarting activities to multiply the problem, because most of your app relaunches end up happening while the phone is throttled. You don't get to taste real speed until well into the launch process... and Ondemand will take THAT away from you as soon as it can.
The irony with 'ondemand' is that using a demanding live wallpaper can actually BOOST your performance, because it acts like a pilot light to keep the fire stoked. In metaphorical terms, think of the governor as being like a vertical slider that determines the current CPU speed. 'Interactive' is kind of like having a balloon attached to pull it up... it will slowly creep down on its own, but just blowing on it is enough to get it back up to 100%. 'Ondemand' is like having a lead weight attached to pull it down... you can drag it up, but the moment you let go it's going to sink, and you have to keep actively fighting and work hard to keep it from sinking.
The moral: live at XDA, buy phones that can be unlocked and reflashed, make sure it has a microSD slot that you've filled with a big class 10 card, forcibly enable swap and use a tweaked kernel that disable's Android's default "kill-instead-of-suspend" behavior, and use a governor like 'interactive' that only slows down the phone when it's truly idle, instead of a governor like 'ondemand' that makes you earn smooth performance by keeping your phone busy enough to prevent it from slowing down the CPU to 200Mhz.
Re:Does it matter? (Score:5, Interesting)
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.
Re:There are four things that make Android laggy (Score:5, Interesting)
This is a common misconception. The class of the SD card is a rating for sequential write speed, nothing more. It's important for cameras and camcorders - in fact it was developed for camcorders because some memory cards simply couldn't write the video data as quickly as the device was sending it to the card.
For an Android device you're more interested in its 4k random read/write performance. It's basically a computer reading/writing lots of small files, so it'll be most impacted by 4k read/write speeds.
As it turns out, manufacturers can tune a flash card for a certain type of performance. If you tune it for faster sequential speeds, random speeds suffer. Likewise if you tune it for random speed, sequential speeds suffer. The class 10 cards I've benchmarked typically hit 10-20 MB/s on sequential writes, but will bog down to as slow as 0.004 MB/s on random writes (yes, 4 kB/s - it was the card I bought before I learned all this. It took 4 hours to copy 4 GB of sheet music and MP3s to that class 10 card - a blissful 0.28 MB/s). Here are the CrystalDiskMark scores I got for a 32 GB class 4 card I have:
seq: 22.9 MB/s read, 4.3 MB/s write
512k: 22.0 MB/s read, 1.3 MB/s write
4k: 3.3 MB/s read, 1.3 MB/s write
Yikes! Only 4.3 MB/s write speed. Who would ever want that? Well look at the benchmarks for a 16 GB class 10 card I have:
seq: 21.8 MB/s read, 12.0 MB/s write
512k: 21.5 MB/s read, 0.9 MB/s write
4k: 5.7 MB/s read, 0.008 MB/s write (not a typo)
So yeah it's 3x faster at sequential writes. But it's slower at 512k writes, and more than 160x slower at 4k writes. It's definitely a very bad choice for an Android device despite being class 10.
The sweet spot for Android is around class 4 or 6. That gets you good 4k write speeds without punishingly poor sequential write speeds (which are important if you're doing something like copying a movie to the card). That said, not all cards are created equal. The "class 2" Samsung card which came with my phone is hands down the best card I've tested overall. It peaked at 11 MB/s sequential writes (meaning it could've been rated class 10), while 4k random writes were still above 1 MB/s. Sandisk is another company which seems to underrate their cards (and their class 10 cards have better if not stellar 4k random write speeds), which is why they're usually highly recommended for Android devices.
tl;dr - You want a class 4 or 6 card, or a good class 2 card for your Android device. Not a class 10 card.
Re:Does it matter? (Score:5, Interesting)
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.
Re:Does it matter? (Score:5, Interesting)
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.