Android devices have a lot of cores, so writing smooth apps is a simple
task for anyone, right? Wrong. As everything on Android can be done in a
lot of different ways, picking the best option can be tough. If you
want to choose the most efficient method, you have to know what’s
happening under the hood. Luckily, you don’t have to rely on your
feelings or sense of smell, since there’s a lot of tools out there that
can help you find bottlenecks by measuring and describing what’s going
on. Properly optimized and smooth apps greatly improve the user
experience, and also drain less battery.To get more news about
App Installs Optimization, you can visit aso700.com official website.
Let’s see some numbers first to consider how important optimization
really is. According to a Nimbledroid post, 86% of users (including me)
have uninstalled apps after using them only once due to poor
performance. If you’re loading some content, you have less than 11
seconds to show it to the user. Only every third user will give you more
time. You might also get a lot of bad reviews on Google Play because of
it.The first thing every user notices over and over is the app’s
startup time. According to another Nimbledroid post, out of the 100 top
apps, 40 start in under 2 seconds, and 70 start in under 3 seconds. So
if possible, you should generally display some content as soon as
possible and delay the background checks and updates a bit.
Always remember, premature optimization is the root of all evil. You
should also not waste too much time with micro optimization. You will
see the most benefit of optimizing code that runs often. For example,
this includes the onDraw() function, which runs every frame, ideally 60
times per second. Drawing is the slowest operation out there, so try
redrawing only what you have to. More about this will come later.
1. String vs. StringBuilder
Let’s say that you have a String, and for some reason you want to append
more Strings to it 10 thousand times. The code could look something
like this.On the same device this happens almost instantly, in less than
5ms. The CPU and Memory visualizations are almost totally flat, so you
can imagine how big this improvement is. Notice though, that for
achieving this difference, we had to append 10 thousand Strings, which
you probably don’t do often. So in case you are adding just a couple
Strings once, you will not see any improvement. By the way, if you do:
You might be wondering, why is concatenating Strings the first way so
slow? It is caused by the fact that Strings are immutable, so once they
are created, they cannot be changed. Even if you think you are changing
the value of a String, you are actually creating a new String with the
new value. In an example like:
2. Picking the Correct Data Type
Before you start writing code, you should decide what data types you
will use for your collection. For example, should you use a Vector or an
ArrayList? Well, it depends on your usecase. If you need a thread-safe
collection, which will allow only one thread at once to work with it,
you should pick a Vector, as it is synchronized. In other cases you
should probably stick to an ArrayList, unless you really have a specific
reason to use vectors.
3. Location Updates
There are a lot of apps out there which collect the user’s location. You
should use the Google Location Services API for that purpose, which
contains a lot of useful functions. There is a separate article about
using it, so I will not repeat it.
4. Network Requests
There is a high chance that your app is using the internet for
downloading or uploading data. If it is, you have several reasons to pay
attention to handling network requests. One of them is mobile data,
which is very limited to a lot of people and you shouldn’t waste it.
The second one is battery. Both WiFi and mobile networks can consume
quite a lot of it if they are used too much. Let’s say that you want to
download 1 kb. To make a network request, you have to wake up the
cellular or WiFi radio, then you can download your data. However, the
radio will not fall asleep immediately after the operation. It will stay
in a fairly active state for about 20-40 more seconds, depending on
your device and carrier.
The Wall