Now you have heard about ICS and it's
new features. Let's think you are one step away from upgrading to
ICS. Wait a moment and read this post. Then decide on your own,
whether to upgrade or not. In this blog post, we’ll describe some
of the technical differences between GB and ICS, and what the
differences in the user experience might be.
This way you can decide if ICS is right
for you, or if you prefer to stay on Gingerbread. Maybe you will
prefer the new UI in ICS, or do you give a higher priority to the
extreme stability of the Gingerbread platform? Check this out !!
However, although ICS is new and
compelling in many ways, we would like if you are to make an informed
decision when selecting what Android™ software to use. We know that
the Gingerbread software is very stable and has great performance, so
it’s not a bad idea to stay on this release. Ice Cream
Sandwich is more intensive, for example in terms of resource
usage. As smartphones become more capable, our own applications, as
well as the Google Mobile Services (GMS) applications, are becoming
more advanced, which means that they require more CPU power,
run more network activities and use more RAM.
On the other hand, ICS brings a refined UI and some nice new features
as described below.
New features in ICS are
describer in this blog post .
Some of these changes affect the performance and stability of the system, for example by using more CPU power and RAM. ICS was developed with Galaxy Nexus in mind, which is based on a TI platform with dual-core processor and 1GB RAM. But most of the devices in the market does not have this configuration. For example, Sony Xperia™ smartphones, which are all built on a Qualcomm platform with single core and 512 MB RAM. This means that in some cases, the resource usage in ICS is heavier on the system compared to Gingerbread. The following sections identify some key areas where there is a difference between ICS and Gingerbread.
Increased RAM usage
In general, it can be said that
the RAM is
the working memory in the phone, used by running processes in
contrast to the flash
memory, which is mainly used to store things. As you might
understand, this is a simplified explanation and might not be
entirely true in all cases. However, it can serve as a help to
understand the difference between the RAM and the flash memory of the
phone.
Now, let’s look at how the RAM is
used. Out of our 512MB RAM, about a third is used for functions that
require a dedicated memory slot to operate fast enough. For example,
this is the case for certain multimedia functions. The remaining
space, which is at least 340MB, is reserved for the Linux user space,
as required in the Android
Compatibility Definition Document (CDD). Within the Linux
user space, functions like the activity manager and Home screen app
are running.
Another interesting thing is that many
apps use slightly more RAM in ICS. For example, the web browser is
quite intensive, and our measurements indicate that it uses 20-30MB
more in ICS compared to Gingerbread. All in all, there are a lot of
changes that together result in greater RAM requirement.
When running low on RAM, typically with
less than approximately 40MB left, the activity manager will start to
close processes according to priority. At first, idle background
activities are killed. The last thing to be closed down is the
foreground activity. We have described this briefly in the table
below. For more information, check out Android
developers. (Please note that all figures mentioned about RAM
usage are approximations and will differ depending on phone model and
use case.)
Table showing different types of
processes. When running out of RAM, the activity manager starts
shutting down processes from the bottom and up, so that the last
things to close are foreground and persistent activities.
Processes that are closed will
obviously have to be restarted when the user enters the app again,
which takes time and slows the system down. For example, when running
a heavy game that uses all available RAM, the activity manager will
be forced to kill all processes running in the background. This might
include vital functions like the dialler and even the Home screen
application. When you exit your game, there is a risk that the phone
is perceived as slow, since the Home screen app will have to be
restarted, just like every other activity you access afterwards.
Slower interaction with the SQL
database
Another change in ICS compared to
Gingerbread is that Google has moved a lot of the SQL handling from
the native to the Java layer. In our internal studies, we have seen
that read and write operations to the SQL database takes longer time,
which slows down the apps. Many applications perform a lot of SQL
operations when started, which greatly impacts the start-up time.
According to good practice, database
operations or http requests should not be performed in the main
thread. However, we know that there are quite a few applications that
perform these kinds of operations directly in the main thread, which
might cause them to hold up other operations. Also, when reading
feedback on ICS software out on the market now, we’ve seen comments
about people having problems with some applications and games.
If an operation takes too long, there
is a risk of getting an Application
Not Responding (ANR) as a result. An ANR occurs when an
application doesn’t answer an intent, or responds to an input
event, within a certain time limit. In case of intent, the time out
is set to five seconds. For the input event, such as screen touch or
button click, it’s ten seconds.
This can result in a user experience
that is perceived as slower and less stable, due to longer response
times and increased ANRs.
Introducing full hardware
acceleration
Yet another change in ICS, is that the
graphics hardware acceleration is on by default for all apps from API
level 14. For apps at lower API levels, it can be turned on in the
manifest with the attribute android:hardwareAccelerated=”true”.
Hardware acceleration means that the GPU is
used to render graphics, which enables a smooth user interface.
However, it also results in at need to load additional graphic
libraries for certain apps, which makes them use even more RAM.
When we performed internal tests on our
applications, we saw that the Settings app consumed 1-2MB more RAM,
and actually took longer time to start with HW acceleration, compared
to without. Once the app is running, the UI is HW accelerated, but
unless the app performs advanced graphics, the user will not see the
difference.
Another effect of the hardware
acceleration is that it can make the battery drain faster in some
cases. An example of this is video playback, where the hardware
acceleration requires every video frame to be run through the GPU,
thus making the system use more power than it would have without HW
acceleration.
As a developer, you should therefore
evaluate if HW acceleration is required or not, as it comes with a
cost in terms of RAM usage, start-up time and possibly even battery
duration which can have negative effects on the user experience. You
can read more about hardware acceleration in Ice Cream Sandwich on
the Android
Developers blog.
OK .. Now you know the depth of the river .. Just decide whether you want to jump or not ..
Cheers !!!!!!!
No comments:
Post a Comment