原帖地址：https://plus.google.com/u/0/105051985738280261832/posts/XAZ4CeVP6DC
發表時間：2011年12月9日
A few days ago I wrote a post trying to correct a lot of the inaccurate statements I have seen repeatedly mentioned about how graphics
on Android works. This resulted in a lot of nice discussion, but unfortunately has also lead some people to come up with new, novel, and often technically inaccurate complaints about how Android works.
These new topics have been more about some fundamental design decisions in Android, and why they are wrong. I’d like to help people better
understand (and judge) these discussions by giving some real background on why Android’s UI was designed the way it is and how it actually works.
One issue that has been raised is that Android doesn’t use thread priorities to reduce how much background work interrupts the user interface.
This is outright wrong. It actually uses a number of priorities, which you can even find defined right herehttp://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_AUDIO in
the SDK.
The most important of these are the background and default priorities. User interface threads normally run at the default priority; background
threads run in the background priority. Application processes that are in the background have all of their threads forced to the background priority.
Android’s background priority is actually pretty interesting. It uses a Linux facility called cgroups to put all background threads into
a special scheduling group which, all together, can’t use more than 10% of the CPU. That is, if you have 10 processes in the background all trying to run at the same time, when combined they can't take away more than 10% of the time needed by foreground threads.
This is enough to allow background threads to make some forward progress, without having enough of an impact on the foreground threads to be generally visible to the user.
(You may have noticed that a “foreground” priority is also defined. This is not used in current Android; it was in the original implementation,
but we found that the Linux scheduler does not give enough preference to threads based on pure priority, so switched to cgroups in Android 1.6.)
I have also seen a number of claims that the basic Android design is fundamentally flawed and archaic because it doesn’t use a rendering
thread like iOS. There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave.
Android had a number of very different original design goals than iOS did. A key goal of Android was to provide an open application platform,
using application sandboxes to create a much more secure environment that doesn’t rely on a central authority to verify that applications do what they claim. To achieve this, it uses Linux process isolation and user IDs to prevent each application from being
able to access the system or other application in ways that are not controlled and secure.
This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all.
An important part of achieving this security is having a way for (EDIT: It has been pointed out to me that iOS does in fact use multiple
windows and multiple GL contexts. Lesson to me, just don't talk about anything I haven't directly verified. :) That still doesn't change things for Android, though, where as I mention later we simply did not have hardware and drivers that could do multiple
GL contexts until fairly recently.)
individual UI elements to share the screen in a secure way. This is why there are windows on Android. The status bar and its notification
shade are windows owned and drawn by the system. These are separate from the application’s window, so the application can not touch anything about the status bar, such as to scrape the text of SMS messages as they are displayed there. Likewise the soft keyboard
is a separate window, owned by a separate application, and it and the application can only interact with each other through a well defined and controlled interface. (This is also why Android can safely support third party input methods.)
Another objective of Android was to allow close collaboration between applications, so that for example it is easy to implement a share
API that launches a part of another application integrated with the original application’s flow. As part of this, Android applications traditionally are split into pieces (called “Activities”) that handle a single specific part of the UI of the application.
For example, the contacts lists is one activity, the details of a contact is another, and editing a contact is a third. Moving between those parts of the contacts UI means switching between these activities, and each of these activities is its own separate
window.
Now we can see something interesting: in almost all of the places in the original Android UI where you see animations, you are actually
seeing windows animate. Launching Contacts is an animation of the home screen window and the contacts list window. Tapping on a contact to see its details is an animation of the contacts list window and the contacts details window. Displaying the soft keyboard
is an animation of the keyboard window. Showing the dialog where you pick an app to share with is an animation of a window displaying that dialog.
When you see a window on screen, what you are seeing is actually something called a “surface”. This is a separate piece of shared memory
that the window draws its UI in, and is composited with the other windows to the screen by a separate system service (in a separate thread, running at a higher than normal priority) called the “surface flinger.” Does this sound familiar? In fact this is very
much like what iOS is doing with its views being composited by a separate thread, just at a less fine-grained but significantly more secure level. (And this window composition has been hardware accelerated in Android from the beginning.)
The other main interesting interaction in the UI is tracking your finger -- scrolling and flinging a list, swiping a gallery, etc. These
interactions involve updating the contents inside of a window, so require re-rendering that window for each movement. However, being able to do this rendering off the main thread probably doesn’t gain you much. These are not simple “move this part of the UI
from X to Y, and maybe tell me when you are done” animations -- each movement is based on events received about the finger on the screen, which need to be processed by the application on its main thread.
That said, being able to avoid redrawing all of the contents of the parts of the UI that are moving can help performance. And this is also
a technique that Android has employed since before 1.0; UI elements like a ListView that want to scroll their content can callhttp://developer.android.com/reference/android/view/View.html#setDrawingCacheEnabled(boolean) to
have that content rendered into a cache so that only the bitmap needs to be drawn as it moves.
Traditionally on Android, views only have their drawing cache enabled as a transient state, such as while scrolling or tracking a finger.
This is because they introduce a fair amount more overhead: extra memory for the bitmap (which can easily total to multiple times larger than the actual frame buffer if there are a number of visual layers), and when the contents inside of a cached view need
to be redrawn it is more expensive because there is an additional step required to draw the cached bitmap back to the window.
So, all those things considered, in Android 1.0 having each view drawn into a texture and those textures composited to the window in another
thread is just not that much of a gain, with a lot of cost. The cost is also in engineering time -- our time was better spent working on other things like a layout-based view hierarchy (to provide flexibility in adjusting for different screen sizes) and “remote
views” for notifications and widgets, which have significantly benefited the platform as it develops.
In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around
having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just
didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.
I hope this helps people better understand how Android works. And just to be clear again from my last point -- I am not writing this to
make excuses for whatever things people don’t like about Android, I just get tired of seeing people write egregiously wrong explanations about how Android works and worse present themselves as authorities on the topic.
There are of course many things that can be improved in Android today, just as there are many things that have been improved since 1.0.
As other more pressing issues are addressed, and hardware capabilities improve and change, we continue to push the platform forward and make it better.
One final thought. I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling
in iOS lists: “Getting it up to sixty is more difficult—you may have to simplify the cell's view hierarchy, or delay adding some of the content, or remove text formatting that would otherwise require a more expensive text rendering API, or even rip the subviews
out of the cell altogether and draw everything by hand.”
I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers,
and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS.
討論區：
"...when combined they can take away more than 10%..."
Should this read "...*can't* take away more..." instead?
I have to admit that I'm doubly impressed by this post. You could easily have let the inanity go, letting outside devs fight dopey fires for you.
Additionally, instead of calling out the wrongness and those who have spouted it directly, you've written a level-headed, clear, straightforward response that is concise and completely approachable.
If I could '80s movie slow-clap in here, I would.
+Tau-Mu Yi There is no simple answer that you seem
to be looking for. In fact the question isn't even as simple as you are asking, because you need to specify for what particular part of the UI and what is going on at that point in both systems.
The thing that was so satisfying about the intern's post was that it identified a primary problem and offered a clear solution for Android's lagginess. Whether it was right or wrong I don't know. But Dianne, these posts from you make me worried
because I feel like you're essentially saying, "We're already doing everything we can. We don't know what else to do." And that makes me think maybe something is being evaded, and/or that the Android lag is going to be around for some time to come.
This post is a statement of how things work technically. Which is fine, but it's not what people want to know. They want to know why Android doesn't scroll as smoothly as other OSes and they want to know that you guys acknowledge the issue and know how to fix
it. Or at least that you're looking into how to fix it, and not sidestepping the issue by simply explaining how Android works.
+Craig Hammell It's not what
you want
to know. I am writing these to explain how things work. I am not trying to make excuses or promises or make you feel better. I just want there to be accurate information about how Android actually works. I think you are looking for a simple answer to a topic
that doesn't have one, that doesn't even have simple questions. If you are looking for "by doing X there will be no lag on Android," you are never going to be satisfied; heck, it's not like iOS never suffers from lag. I think all I can really say on this topic
is that Android has been improved greatly over the last few years, through a variety of changes including a number I have previously mentioned, and it will continue to be improved.
+Dianne Hackborn Yes, you've done great work. I love
Android and I anticipate greatly its improvements over time. The thing that gets me in this debate is that I'm not sure the topic of "how android works" as a general question was what people were ever really interested in. The question was more, "how does
android work, qua improvable system with identifiable UI issues". IE, what can be done to improve it? I appreciate the time you've taken to explain what you have, however I don't think it'll satisfy many, because it's not answering questions that they're asking.
Edit:
+Kun Li You're right. I'm ignoring the purpose of the post. My apologies,
I'll stop.
+Craig Hammell As far as I know, iOS doesn't (or at
least didn't originally) need multiple GL contexts, because the current application was the only thing that draws to the screen. And let's be clear: if what you are looking for is someone to identify some specific problem or two that someone can take care
of and there is no lag any more, you are looking for someone selling snake oil.
It is probably worth quoting the rest of Brent Royal-Gordon's comment at this point: "But that's where the cultural difference lies—iOS developers will do those things. They will redesign a table view so it has a chance of scrolling faster. They will write
a bunch of manual drawing code, see if it's faster than the view-based stuff, and act accordingly. The iOS culture tells them that this is what you have to do to make a good product."
These kinds of performance issues can everywhere across the stack -- from the GPU and its driver, through the kernel, the platform and application framework, and in the design of apps. Even if everything under the apps is perfect (and I am certainly not going
to claim it is), you can still make it fall apart by not doing things well and putting the work needed into your app.
+Rasmus Backman The reason we are reading this (or
the previous) article at all is as a defense against various (also often incorrect) reasons why Android's UI is so much slower than that of iOS. Only, the primary defenses listed in this second article are of the form "iOS does X, we could not do X because
we believe Y is more important, forcing us to do Z instead of X as a necessary tradeoff", when in fact (if you spend the time to pull apart how the system works, which a lot of us in the jailbreak scene have done extensively) iOS does not do X, and quite to
the contrary actually does Z, but because Apple doesn't particularly want developers doing anything "awesome" (which sucks), simply makes it look like they are doing X, even though the system totally supports the glory that is Z. Unfortunately, this mistake
totally undermines any confidence in this analysis being correct, and also brings up serious doubts of whether the people on the Android team actually understand the core problem in the first place. :(
+Jay Freeman I would honestly love if you could correct
any misinformation about iOS. As I said in the post, I would never claim to be an expert on iOS, and only base my ideas of how it works on information I see people provide that I judge as worthy of trust. There isn't really any way for me to directly get information
about it -- I can't look at the source code, and to be honest I have kept myself away from looking at even the SDK to avoid any legal issues (especially since they had that agreement you have to sign to look at it, though I don't know if that is still the
case).
+Dianne Hackbornhttp://news.ycombinator.com/item?id=3332357 <- check out the responses from Xuzz and ryanpetrich.
In particular, iOS in fact has a multi-window architecture: applications can be made up of multiple UIWindows, and you can have UIWindows from different processes on screen at the same time. When you click on applications in SpringBoard, the transitions you
see are animations of windows, and it would not at all be difficult to implement (from a rendering perspective) a scheme where different processes registered something similar to Android's activities, where clicking links slid one process's content off-screen
while sliding another process's content on, even while sharing a navigation bar.
The status bar actually used to be an example of this, but they changed it at some point (and honestly I do not remember why, but I do not believe it to have been due to a rendering issue); the notification center, however, is a good current example: the window
for the notification center is in SpringBoard, but it is rendering over and at the same time as the window for the application you are covering. There is also no issue having these windows alpha composite onto each other: the little popups that happen from
clicking the volume buttons are windows in SpringBoard.
The reason for this is that, like with most multi-window environments (including Android), there is a window manager that is handling all of the actual compositing. In this case, it is SpringBoard, the process that manages the home screen, task switcher, notification
center, lock screen, and honestly almost anything that has to be "always happening". The way this works is that surfaces (backed by system or video memory) are managed by a driver that allows them to be passed between processes: applications can render directly
to their surfaces, while the actual surface hierarchy is maintained by SpringBoard.
Honestly, though: around here is where my knowledge is really fuzzy, and can't be trusted; Ryan Petrich's knowledge can be, so I will quote his comment from Hacker News: """On iOS, all standard rendering is done in a single context by the Core Animation window
server which lives in SpringBoard. Only when an app adds an OpenGL ES layer to the view hierarchy does a separate context need to be created. When that happens, the render graph is split into subgraphs that are rendered to surfaces and displayed as overlays
(with SpringBoard rendering all the standard layers and the app rendering the OpenGL layer)""".
The result of all this is that your comments regarding iOS's inability to handle multiple applications sharing screen real-estate in an efficient and secure manner are simply false: the fact that Apple does not support the Android notion of seamlessly moving
between applications, with a back-button instead of simply an up/home-button, is simply an irritating business decision they make. As mentioned by Xuzz on Hacker News, it would be a simple manner to, for example, modify UIKeyboard to be handled by a separate
process from the app that was calling for it: the involved work would not be rendering complexity.
Finally, the reason why you need to be careful with your view hierarchy to get 60fps scrolling is due to the complexity of loading new table cells and rendering them for the first time: once they are rendered they scroll quickly as the entire layer is cached
(afaik, and if I'm wrong on this it doesn't actually matter). The problem on Android is that, even in the best possible cases, where you are staring at a trivial table implemented by the Android team itself (such as the Settings/Preferences app), there is
noticeable UI latency and slop while moving your finger over the screen. When you read threads like the response to your first article on Hacker News, you can see this is a serious challenge for Android.
http://news.ycombinator.com/item?id=3310301 <- the top-voted comments just lambast this lag issue
Now, I have no clue why that happens, and will certainly not pretend to know enough about Android to even guess (at least in public ;P in private I have tons of theories, and have even discussed the matter with some old-school Apple/NeXT people that chimed
in with their own reasons that I sometimes attempt to parrot), but I'd love someone from the Android team to explain what was up. These posts, which I really do appreciate from the "enlightenment regarding Android" perspective, are not instilling any confidence
that the Android team understands what is causing this issue, and is in a position to someday fix it. :(
(
http://news.ycombinator.com/item?id=3310475 <- and, I guess while I'm at it, can we get a "true facts" response to this?
;P)
(Oh, and here are a couple possibly interesting references that do not require accepting any agreements. I am not 100% certain this will be useful, however, especially without any context.)
http://developer.apple.com/library/ios/#documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/WindowsandViews/WindowsandViews.htmlhttp://developer.apple.com/library/mac/#documentation/graphicsimaging/Conceptual/Animation_Overview/MacOSXAnimTech/MacOSXAnimTech.htmlhttp://developer.apple.com/library/mac/#documentation/Miscellaneous/Reference/IOSurfaceAPI_header_reference/Reference/reference.html
+Jay Freeman Thank-you very much for the great information,
it is a lot of stuff I didn't know about their architecture. Unfortunately for us, until recently we just didn't have GPUs that could do multiple contexts, so if our system worked like that we wouldn't have been able to ship. :}
What you say about scrolling lists in iOS is still exactly how Android works -- each item is cached in a layer so scrolling is fast, but introducing a new item can be slow because it needs to be re-computed and re-rendered. For example, a Nexus S can definitely
does 60fps on well written lists. It is very hard to address broad statements of "there is always slop and lag," because often this is not broadly true, and the behavior of individual devices can vary greatly. For example, I have seen some touch screens that
introduce many frames of lag with the data they report to the kernel. (We have even spent quite a bit of time on some older touch screens we shipped with tuning their parameters to get data out faster at the expense of it being more noisy, and cleaning that
up in the platform.)
+Dianne Hackborn While I feel the large number of
commenters on a variety of devices would, to me, indicate this is a wide-spread issue and not relegated to "some older touch screens", I will personally state that I have a Nexus S that I find incredibly bothersome with regards to touch interaction, even in
simple situations such as the Settings/Preferences application.
It honestly seems to not be having a difficult time rendering the tables (hence why I would not personally attack you on that), but the touch events have a tremendous amount of lag/slop: not only does it react slowly to initial movements, if you sit there and
move your finger up and down you get this almost sea-sick feeling where the screen is still going up as your finger is already moving downwards.
Now, this (my device) is still 2.3: maybe you guys made major improvements in ICS. However, the comments from other people (even on brand new hardware: the Galaxy Nexus [1]) seem to indicate that this is not the case; and, if it were, I'd kind of think your
article should be trumpeting "old news: we fixed that" rather than "people are misinformed about what causes that known issue" ;P.
[1]
http://digithoughts.com/post/11647614966/the-samsung-galaxy-nexus-and-the-android-lag
Really, it's the kind of thing that could "be anything": touch screen hardware latency, event dispatch context switch costs, rendering and compositing lag, slow bytecode execution performance, poorly thought out momentum calculations, or even explicit code
"if (movement.distance < 5) return DelayTouch;" (such as to determine "is this really a movement or just a sloppy click").
So yeah: I understand it is a really complex problem. However, this article seems to try to pin the problem on a false comparison between iOS and Android's rendering pipelines, arguing that Android's entire architecture made a better tradeoff that people should
respect, when in fact "we really still don't know". Even if you didn't intend it this way, that is how everyone is interpreting it.
I mean, check out these headlines. Some of these articles are responding to your first article, some to Munn's response, and some to this latest post made by you; the key thread, however, is clear: people are looking for answers, and even if you are just trying
to respond with some facts, people are taking what you are both saying and "running with it", reading the discussion as "iOS vs. Android".
http://www.iphoneanswers.net/6139/why-does-iphone-seem-more-fluid-than-android.htmlhttp://www.redfoundry.com/2011/12/is-the-android-ui-framework-fundamentally-broken/http://www.lazytechguys.com/news/google-dev-explains-why-android-user-interface-is-laggy-while-ios-wp7-qnx-are-fluid/http://www.phonearena.com/news/Here-is-why-Android-is-laggy-and-why-its-going-to-remain-like-that-in-the-near-future_id24434
To pull a comment from someone summarizing this specific post: """What I took away from her article is that Android decided security was more important early in its development life because they were creating an open operating system that wouldn't have the
luxury of a curated app store, but ultimately it was this decision which compromised the UI's ability to exploit graphics hardware because you end up with multiple processes needing to write to the same display (instead of one) and the hardware and drivers
which would allow sharing of a hardware accelerated surface across multiple processes haven't started coming out until just now."""
http://www.reddit.com/r/Android/comments/n5ppz/android_engineer_dianne_hackborn_clears_up/c36iudh
To put into some concrete context how dangerous this all is, the situation at this point could easily be spinned as follows: "The key problem actually /is/ an architecture decision, specifically that Android runs on devices from third party manufacturers, leading
to poorly chosen graphics hardware and uncalibrated touch screens in the majority of shipped devices." <- Obvious article-bait. ;P
Obviously, without a bunch of evidence showing that that actually was the underlying problem, getting a bunch of people to run with the new headline "Android's open-ness inherently causes UI lag" would be really bad for everyone, and not something any of us
would want to see. However, that's pretty much what this post did, asserting that there was some kind of security issue on iOS due to its graphics performance. :(
You're still skirting the thread priority issue when it comes to animatingsystem widgets.
If the kernel didn't offer a working scheduler (as Linux historically has problems with), Google could've created its own that was more BSD-like, and very well known to be more fair and responsive for foreground threads, or even real-time threads.
When any standard list-view scrolls, it is now animating. This animationshould not belong to any application, but submitted to system "animation engine" (maybe through IPC) which should be running at high-priority levels to
make sure the animation never skips. The fact it skips, as well as the initial lag in detecting touches ( which should be a system real-time thread also ), is indicative of the on-going negligence and sloppiness. There should be a special
mode for scrolling where the finger movement is interpolated so there isn't more lag waiting for the latest "real" event to get through the laggy system. Afterall, scrolling already has a predictable velocity and inertial.
You shouldn't need multi-GL contexts unless you're doing this threaded, but since RBO and FBOs exist, you should be treating the renderer more like single-threaded blitter server. The only reason to use multi-GL contexts is to load textures (producer) and prep
them for the "blit renderer" server (consumer) to churn through its scene-graph independent of rendering. If you're getting slow-down because you're doing all that GLES context switching for each app, you're doing it wrong. This is where the idea
of using a mature game engine comes in. They've solved this issue.
Being that Windows Mobile had fairly mature OpenGLES drivers near the end days of v6.5, it's inexcusable to now claim Android's GLES drivers were immature until now, -- 2 years later. Consider, Apple made sure their drivers were fully-usable for the UX level
needed even on the OG iPhone -- it obviously was not a priority for Android.
If you can't get lag-free, fully-responsive animation with system widgets on a 600MHz single-core system, you're doing it wrong. I really wish Google would just fix it, for good, now, instead of worrying about "correcting" people, apologizing
for, or explaining it. Actions speak louder than words.
+Joseph Lee To be honest, it is hard for me to take
this kind of comment seriously, when you are talking about game engines solving the needs for OS platforms and speculating about maybe using IPC. Really? Maybe it is possible that you are a little too convinced in your own understanding of the problems.
For example, drawing a list involves way more than rendering to the screen. You have a touch screen processing low-level input in firmware to generate the higher-level touch data (and less than good touch screens can introduce all kinds of issues here, ones
I have seen on shipping devices), you have the kernel pulling this data out of the screen and publishing it in a driver, the framework dispatching these events to the appropriate window, the window interpreting them and updating its state, and finally the
UI being updated on screen. Issues can happen at any point in this process, and I have certainly seen a number. And it is ridiculous to say that this interaction can't belong to the application -- each frame of the list view tracking the finger needs to belong
to it, since there is actually a lot of complicated logic going on that the application needs to be involved with, from the list view itself deciding how to interpret the events, through populating the list as new items appear, to the application being able
to watch them and decide other things like we are now going to do a horizontal swap between pages.
Also you act like a list view widget should be designed as some super-special built-in part of the OS, like it is running way off in some other process that the app has no part in. So, what, an app developer just can't write their own widget that scrolls well
because they can't run their code there? That seems like a very bad idea, and there is no need to go there.
Finally, good gracious, stop with the "apologizing" schtick already! As I have said repeatedly, none of this is any kind of apologizing or excuse. As I have said before, a lot of work has gone into Android to improve responsiveness over the last years, and
a lot of work continues to go into it. If you hold stock ICS next to 1.0 on the same hardware, ICS is going to be a ton better, due to changes all over the place, not just in the graphics system, and work will always continue on there... because there is never
a "it works perfectly now, we are all done" point -- iOS isn't perfect in this regard either, there are always improvements to be made. There is no one magical thing that if done today is going to make all issues go away.
Can anyone name a Google app with a list view that isn't laggy? Every one I run I see lag. I'm not much of a Android or iPhone dev, but I wrote a simple list view app on iOS the day the SDK was released on an iPhone 1.0 with text and icons,
and it scrolled buttery smooth. I still can't find any Android apps that are that smooth. Even the small list view in Settings is laggy and the separator lines flicker on Nexus S and 2.3. News and Weather is laggy, gmail is laggy, Market, Reader etc. Also
I find typing impossible since it's just not responsive enough.
+Steve Gehrman Flickering list items would have nothing
to do with screen rendering, that would only be an artifact of the display. Android's screen is double buffered (actually twice since each window surface is also double buffered) so you never see incomplete frames of drawing.
I do not touch iOS devices (for reasons mentioned elsewhere) so can not address comparisons with them, but I think it is pretty clear that JB is significantly smoother than ICS. Is it "as good" as iOS? I have no idea, but from the reviews
of the Nexus 7 I have been seeing, it seems to me that this is becoming a pretty subjective area.
For example take
http://venturebeat.com/2012/06/29/nexus-7/#s:dsc02161with this comment:
"Thanks to Project Butter, the 7 feels nearly as smooth as the iPad. No major kinks, blips, or bumps to speak of — at least so far."
That is the last I am going to post on this discussion. I am interested in having discussions about technical issues and other such more fact-based areas.
+Dhruvraj Singh Aren't those benchmarks measuring
GPU performance? So you are saying we are running with half or a third the performance of Apple devices and still being competitive? That doesn't sound so bad. :)
This is a very nice post.. I am wondering how a process is assigned to the background cgroup. Dose all the bg priority threads gets assigned to the background cgroup? or there is another mechanism(by android) in assigning tasks to this group?
+Kanishka Ariyapala Processes are assigned to the
background cgroup based on the type of components they have active in them and the state of those components. Basically, you get to be foreground if you have an activity displayed, you have a foreground service, and a few other conditions that vary over the
different platform versions. Changing the cgroup of a process means changing the cgroup of all of its threads, since Linux doesn't really have per-process state like this.
"Processes are assigned to the background cgroup based on the type of components they have active in them and the state of those components" implies android keeps track of the services and activities running in a process and switches the cgroup
(SP_FOREGROUND/SP_BACKGROUND/SP_SYSTEM..) when an activity switch states. Could you point to component where this done ?
![]()
Also use "adb shell dumpsys activity" to get a summary of the activity manager state, which includes all app processes with their memory management and cgroup state.
Amazing to look back a couple years and see all there comments, this article, and compare it to how far Android has come today.
The Nexus 5 rivals any other phone out there for speed and responsiveness, and even bests the iPhone 5S in many performance areas.
The only thing that really is left to nail down is touch latency.
+Dianne Hackborn;
I seriously doubt you'll take the time to answer me, but are is the Android tab aware of the large touch latency generally visible on Android (including Nexus) devices, and is it being worked on if so? Outsidee of that,
any information at all would
be welcome on the subject. Is latency in touch mainly caused by hardware; software; both? It's my last peeve with Android.
It's even visible on my Nexus 5.
+Kurian Abraham Thampy that I agree with. Android
tablets still have to improve.
My Nexus 10 is the best example. The Nexus 4 and 5 are on a different playing field of UI performance than the 10. Probably because any issues are exemplified further due to the large display.
I disagree on standby life, though. My father's Nexus 7 2013 could easily go a few weeks on standby.
+Kurian Abraham Thampy The Nexus 5 and 2013 Nexus
7 actually have the same screen resolution, so trying to make implications about dealing with more pixels being a "problem" in Android does not pan out here.
Also smoothness issues related to the size of the screen (which I assume you are using to imply related to screen resolution / number of pixels), is almost entirely going to be related to just the performance of the chipset's GPU in relation to the screen resolution,
not something about Android. You can certainly find Android devices that have an under-powered GPU in relation to the screen resolution they are driving, and thus have lower frame rates. This has been a continual struggle on these devices as the screen resolutions
have increased so spectacularly. Apple has also struggled with it, for example the original retina iPad clearly had a fairly underpowered GPU compared to its screen resolution. But yes, you will see this problem more on Android, since there are actually
lower-end Android devices you can buy. :)
And the launcher on the Nexus 7 or any other modern Nexus device is not a custom OpenGL launcher, it is written purely with the standard Android framework. I assume you haven't used the 2013 Nexus 7 much at all, either, because there are plenty of other smooth
apps on it.
(On the other hand, I played around with the original iPad Mini last week, and it is certainly laggy in some significant apps, like the app store. There is not something magical about i devices where there is no lag in them.)
As far as battery life, yes it is true that you can install apps that will use your battery, since Android does have more flexibility in what apps can do. It is not some universal truth, however, that if you install apps your battery life will become terrible,
it depends very much on the apps you install. And those apps may well be using your battery because they are doing things that you want... and if they aren't, generally they will show up in the battery stats so you can know what app is impacting your battery
more than you think it is worth and remove it.
+Colton Walker Touch latency on the Nexus 5 is I believe
fairly competitive with iOS devices. There has been a fair amount of work put into the platform over the last couple years to improve touch latency; at this point the primary issue I believe is usually more related to the touch firmware, which is outside
the control of the platform and something the hardware manufacturer needs to take care of.
Unfortunately as far as I know the public touch latency comparisons that have been done have never used Nexus devices, so it is hard to infer from them much about the platform itself, since the touch screen firmware is so important to overall latency and outside
of the platform's control. It is also easy to introduce latency elsewhere, such as adding an additional frame (adding 16ms) to the back-end screen updating, etc.
+Dianne Hackborn thanks very much for the reply.
Glad to here it HAS been worked on. Just for the sake of confirmation, I played around a bit with a friend's iPhone 5 today to compare the touch latency to my Nexus 5. They're very close. Much better than, say, the Galaxy Nexus.
It's actually my favorite thing about this device. It's incredible.
The main problem I see with tablets is that ANY issue with the touch controller, OS or otherwise is greatly magnified by the larger display (and hence, greater finger travel while scrolling, swiping, etc.). Regardless of the resolution.
I haven't seen any tests on latency either that include Nexus devices; although I saw one recently which placed the LG G2 only ~15ms behind the iPhone 5S, which is a feat in itself. I'm hoping the touch controller from the G2 is present in the N5.
One final question: I noticed that applications written using the NDK are EXTREMELY touch responsive compared to the standard development kits. Any particular reason for this? Would ART, when finalized, provide a boost to touch response? I'm using it now on
my Nexus 5, and overall I do notice a performance boost although not major.
+Kurt Stammberger <****@**> This is not showing "heavy
apps", this is the Chrome browser. The latency being shown there is not
something the Android platform is imposing on apps, it is being introduced
by the browser app.
And by the way, this is also a counter-example to your previous statement
that you can't use the Android UI toolkit to achieve a non-laggy UI, but
need to directly use OpenGL, since Chrome is actually an app that doesn't
really use the UI toolkit, since it is a cross-platform rendering engine.
So yes, individual applications can be implemented in a way that is laggy.
As I said, this isn't unique to Android -- from my use of the iPad Mini,
this can happen on iOS as well, even in Apple's own apps. But certainly in
these days there is nothing intrinsic about the Android platform that
prevents you from implementing a non-laggy UI using the standard toolkit.
You just aren't going to succeed if that is the argument you want to make.
Now, there could be some interesting discussion about the relative
complexity in implementing smooth UIs on Android vs iOS using their
standard UI toolkits. I could certainly accept that it is harder on
Android, and we have been and will continue to work on making it easier.
Unfortunately, I can't have such a discussion, because I don't know iOS
well enough to do so, and for legal reasons it is best for me to continue
to be fairly willfully ignorant in that regard. :(
