Wandering through the forums and various websites dedicated to Android, we are constantly confronted with tips on how to increase the performance of the smartphone. Some recommend to include swap, others - add special value to build.prop, and others - to change variables of the Linux kernel. Such recipes in different ways you can find a huge amount of that on the
XDA and
4PDA. But do they actually work :confused:
Tenacity with which some seemingly competent smartphone users are trying to push their ideas public optimum adjustment Android and the underlying Linux kernel. And the right to it was limited to a slight tuning virtual memory management subsystem, or the inclusion of experimental options. No, we usually offer a very long use scripts that change literally every variable core, remount filesystems with different odd options, including the swap, activate various system daemons and perform billions of different operations.
No, well, you can, of course, assume that the Linux kernel, Android and proprietary firmware for smartphones develop illiterate idiots, whose work must be radically alter, but in practice some reason it turns out that the most famous tuning tools, published on XDA, - it nothing but a hodgepodge of disparate huge number of recommendations, it is not clear who invented and no one knows why. The absurdity of the situation reaches that these instruments can be found rows copied unchanged from the scripts to increase Linux-server performance under heavy loads (I'm not kidding, look at the contents of the famous script ThunderBolt!).
In general, the situation is more complicated than. All advise all, no one suggests anything, and those who understand something, sitting and drinking tea and laughing over what's happening.
SwapLet's start with the swap - the most absurd ideas of all that you can think of for use in smartphones. Its purpose is to create and connect the paging file, thereby manage to free storage space in memory. The idea itself is certainly sensible, but only if it is a server, which rests on the interactivity of nowhere. Using your phone regularly used pagefile will lead to lags arising from slips past the cache - just imagine what will happen if an application tries to display one of their icons, and it will be in the swap, which will have to re-load the disc, after freeing up space by placing data swap another application. Horror. :(
Some users can be argued that in fact after the swap no problems, but for this we must thank the mechanism lowmemorykiller, which regularly kills very swollen and have not used the application. Thanks to him, the device with 1GB of memory can never reach the necessary performance data in a swap. He is the reason why, in contrast to the Linux-desktop on the Android swap is not needed.
Verdict: A very stupid idea, the implementation of which is fraught with serious lags.
zRAMThe idea is so right that even Google recommends zRAM for KitKat-based devices in the event that the amount of RAM is less than 512 MB. Only snag is that the method only works for modern cost devices based on multi-core processors from the budget any MTK and 512 MB of RAM. In this case, the encryption stream can be taken to separate the kernel and do not care about performance.
On older devices with a single core, and which recommend the use of this technology, we again get the lags, and in fairly large quantities. The same, incidentally, applies to technology KSM (Kernel Same Page Merging), which allows you to combine identical memory pages, thus freeing space. It also recommended that Google, but on older devaysakh leads to an even greater lags, which makes sense, given the constantly active core thread that runs continuously from memory in search of duplicate pages.
Verdict: it depends on the device, in most cases, the system slows down.
SeederAt the time this application has done a lot of noise and gave rise to many analogues. The network has a huge number of reports of alleged phenomenal growth performance of the smartphone after installation. Homegrown custom firmware collectors have begun to include him in their assembly, and the author was declared a savior. And all this despite the fact that Seeder not doing anything dirty hacks, but just corrected a stupid bug Android.
The bug consisted in the fact that some high-level components of the Android runtime actively used the file /dev/random to get entropy. In some moments buffer /dev/random devastated, and the system is blocked until it is filling the required amount of data. And as he filled that have been reported from various sensors, buttons and sensors of the smartphone, the time for this procedure took so much time to notice that lag.
To solve this problem the author Seeder took Linux-demon rngd, compiled it for Android inastroil so that he took random data from a much faster (but also much more predictable) /dev/urandom, and every second merges them into /dev/random, without allowing the latter exhausted. As a result - the system never experienced a lack of entropy and work quietly.
This bug was closed back in Google Android 3.0, and it would seem, we do not need to think about Seeder. But the fact that the application has since actively developed and even today, is recommended by many "experts" for the application. Moreover, the application has several analogues (eg, sEFix), and many of the creators of the scripts/tools to accelerate still include this functionality in their creations. Sometimes it is the same rngd, sometimes - the demon haveged, sometimes just symlink /dev/urandom on /dev/random.
Everyone who tried it, excitedly shouting about the effectiveness of the solution, however, according to Ricardo Cerqueira from the company Cyanogen, in newer versions of Android /dev/random is used in all three components: libcrypto (encryption SSL-connections, generating SSH keys and etc.), wpa_supplicant/hostapd (to generate the WEP/WPA-keys) and several libraries for generating random ID to create ext2/3/4 filesystems.
Application Efficiency in today's Android, in his opinion, is not connected with the completion of the pool /dev/random, and that rngd constantly awakens the device and causes it to increase the frequency of the processor, which has a positive effect on performance and negative on the battery.
Verdict: The placebo effect.
OdexStock firmware smartphones always odex. This means that along with the standard package for Android apps in APK format directory /system/app/ and /system/priv-app/ (since KitKat) are also of the same name files with the extension odex. They contain so-called optimized bytecode applications already passed through the validator and optimizer virtual machine and recorded in a separate file (this is done using dexopt utility).
Meaning odex files to offload virtual machine and thus speed up the launch of the application (runoff). On the other hand, ODEX files to prevent modifications to make to the firmware, create problems with the update, and for this reason many custom ROMs (including CyanogenMod) distributed without them. Return (or rather, generate) files odex a variety of ways, including using simple tools/scripts like Odexer Tool. Using them is easy, and many of the "experts" are advised to do so.
The only problem is that this is purely a placebo. Not finding odex-files in the directory/system, the system itself will create them the next loaded and placed in the directory /system/dalvik-cache/. This is what she does when loading a new firmware on the screen the message "Busy ... Optimizing Applications." In relation to applications from the convenience store is also, incidentally, works. But at the stage of installation of the software.
Verdict: The placebo effect.
Lowmemorykiller tweaksThe implementation of multitasking in Android is very different from other mobile operating systems and is based on the classical model. Applications can work quietly in the background, in the system there are no restrictions on the number, the functionality of the transition to a background execution is not curtailed. All as on the desktop, except for one detail: the system has every right to kill any background application in the case of lack of memory, or (since KitKat) excessive greed application resources.
This mechanism, called lowmemorykiller, was coined to, retaining features of a full-fledged multi-tasking OS, Android could live normally in a limited amount of memory and lack of swap-partition. The user can easily launch any application and quickly switch between them, and the system will take care of the long-unused application completion and to always remain free memory in the device.
In the early days of Android purpose of this mechanism for many users it was unclear why have become popular so-called task-killer - apps that from time to time to wake up and have completed all background applications. Profits in this case, it was considered a large amount of free RAM, which was perceived as a plus, though no advantages in this, of course, was not. But there were many disadvantages in the form of a longer switch between applications, increased battery consumption and problems c awakening in the morning the owner (Service also kills).
Over time, multitasking principles of understanding has come, and from task-killers gradually abandoned. However, they were quickly replaced by another trend - tuning of lowmemorykiller mechanism (for example, by MinFreeManager applications). The main idea of the method is to lift the boundaries of filling the RAM at which the system will start to kill background apps. A sort of the way ", and us and you", which allows you to free up some memory by regular means, without disturbing ideas Android multitasking.
But what it ultimately leads? For example, the standard value memory is full of borders - a 4, 8, 12, 24, 32 and 40 Mb, that is when the free storage space of 40 MB will be killed by one of the cached applications (loaded in memory, but is not running, is this optimization Android ), with 32 - Content Provider, has no customers, 24 - one of the seldom-used back-end application, then go to the expense of service processes application (for example, the music player service), visible on the app screen and the current running application. The difference between the last two is that the "current" - this application, which is currently dealing the user, and the "visible" - is that, for example, has a notification in the status bar or display on top of the screen any information.
In general, all this means that the smartphone will always be available 40 MB of memory, which is enough to accommodate another application, and then start LKM flow and begin cleanup. All OK, everyone is happy. The system uses the maximum memory. Now imagine what would happen if the user take advantage of advice homebrew "expert", and raise these values so that the latter would be, well, let's say, 100 MB (usually raised only the last three values). In this case, it happens one simple thing: the user will lose 100 - 40 = 60 MB of memory. Instead of using this space to store back-end applications, it is useful, as it reduces the time to switch to them, and the charge of the battery, the system will keep it free is not clear why.
It is fair to say that the LKM tuning can be useful for devices with very very little memory (less than 512) and Android 4.X on board, or to temporarily increase thresholds. Some developers tweaks directly recommend the use of "aggressive" setting only if you run heavy software like hi-end games, and all the rest of the time to stay on the standard. This really makes sense.
Verdict: better not to touch.
I/O tweaksThe scripts that are published on the forums, you can often find tweaks I/O subsystem. For example, in the same script ThunderBolt! has the following lines:
Code:
echo 0 > $i/queue/rotational;
echo 1024 > $i/queue/nr_requests;
The first gives the I/O scheduler to understand that he is dealing with a solid state drive, the second increases the maximum size of the queue IO 128 to 1024 ($i variable in commands contains a path to the tree of block device in /sys, eg /sys/block/mmcblk0/, the script runs on them in the loop). Hereinafter you can find the following line relating to the CFQ scheduler:
Code:
echo 1 > $i/queue/iosched/back_seek_penalty;
echo 1 > $i/queue/iosched/low_latency;
echo 1 > $i/queue/iosched/slice_idle;
This is followed by a few more lines belonging to other planners (by the way, pay attention to a whole extra semicolon at the end of instruction). What all of these lines is not so? The first two commands are pointless for two reasons:
1. Schedulers I / O in a modern Linux kernel itself able to understand what type of storage medium they deal.
2. Such a long input-output queue (1024) completely useless on a smartphone. Moreover, it is meaningless, even on the desktop and is used on heavy duty servers (of tuning recommendations which it, apparently, and got into the script).
The last three are meaningless for the simple reason that for a smartphone, where there is virtually no separation applications prioritized in the input-output and there is no mechanical drive, the best planner - is the noop, that is simple the FIFO-queue - who first turned to memory, he also got access. And this scheduler is not any special settings. Therefore, all these multi-screen lists commands better replaced by a simple cycle:
Code:
for i in /sys/block/mmc*; do
echo noop > $i/queue/scheduler
echo 0 > $i/queue/iostats
done
In addition to enabling noop scheduler for all drives it off the accumulation of statistics I/O, which should also have a positive impact on the performance (although this is only a drop in the sea, which will be completely invisible).
Another tweak that can often be found in the scripts tuning performance - this increase readahead values for memory cards up to 2 MB. readahead mechanism for early reading data from the media even before the application requests access to these data. If the kernel sees that someone long enough to read the data from the media, it is trying to figure out what data will be needed in the future application and pre-loads them into RAM, thereby enabling to reduce the time of their return.
It sounds cool, but, as practice shows, readahead algorithm is very often wrong, which leads to unnecessary operations of input-output and consumption of RAM. High values readahead (1-8 MB) are recommended for use in RAID-arrays, whereas on the desktop or smartphone is better to leave everything as is, that is 128 KB.
Verdict: in addition to noop, do not need anything.
Tweaks virtual memory management systemIn addition to the subsystem I/O, it is also common to do tuning virtual memory management subsystem. Often, change affects only two kernel variables: vm.dirty_background_ratio and vm.dirty_ratio, which allow you to adjust the size of the buffer for storing the so-called dirty data, ie the data that has been written to disk application, but more are still in memory and waiting until they are written to disk.
Typical values of these variables in the desktop Linux-distributions and Android are as follows:
Code:
* vm.dirty_background_ratio = 10
* vm.dirty_ratio = 20
This means that when the "dirty" data buffer size in 10% of the total amount of RAM wake pdflush nuclear flow and starts to write data to disk. If the operation of recording data on the disk will be too intense and even though the job pdflush, the buffer will continue to grow, then when it reaches 20% of the amount of RAM the system switches all the subsequent write operation in synchronous mode (without pre-buffer) and the work of writing to disk application will be blocked until such time as the data is written to disk (in the terminology of Android is called a lag).
It is important to understand that even if the buffer size is not reached 10%, the system anyway pdflush starts the flow after 30 seconds. What we are given this knowledge? In fact, anything that we could use for their own purposes. The combination of 10/20% is quite reasonable, for example, on your smartphone with 1 GB of RAM is about 100/200 MB of memory, which is more than enough in terms of rare bursts records that speed is often below the speed record in system NAND-memory, or SD-card (when installing software or copying files from a computer). But the creators of scripts optimization with this, of course, disagree.
For example, in Xplix script can find something like this (in the original, they are much longer because of the checks on the amount of RAM and use BusyBox):
Code:
sysctl -w vm.dirty_background_ratio=50
sysctl -w vm.dirty_ratio=90
These commands apply to devices with 1 GB of memory, that is, set limits on "dirty" buffer equal to (approximately) 500/900 MB. These high values are absolutely meaningless for the smartphone, as only work under constant intense recording on the disc, that is, besides for heavy server. In a situation with a smartphone they are no better than the standard. By the way, in the script ThunderBolt! used much more reasonable (and close to the standard) values, but I doubt that by their application the user will notice at least some difference:
Code:
if [ "$mem" -lt 524288 ];then
sysctl -w vm.dirty_background_ratio=15;
sysctl -w vm.dirty_ratio=30;
elif [ "$mem" -lt 1049776 ];then
sysctl -w vm.dirty_background_ratio=10;
sysctl -w vm.dirty_ratio=20;
else
sysctl -w vm.dirty_background_ratio=5;
sysctl -w vm.dirty_ratio=10;
fi;
The first two commands are run on smartphones with 512 MB of RAM, the second - with 1 GB, and others - with more than 1 GB. But in fact there is only one reason to change the default settings - a device with a very slow internal memory or memory card. In this case it is reasonable to spread the values of the variables, that is, to make something like this:
Code:
sysctl -w vm.dirty_background_ratio=10
sysctl -w vm.dirty_ratio=60
Then, when a surge system write operations, without having to record data on the disc, up to the last will not switch to synchronous mode, which will allow applications to reduce lag when recording.
Verdict: better not to touch.
P.S. There are numerous and smaller optimizations, including the "tuning" of the network stack, changing the variables of the Linux kernel and Android (build.prop), but 90% of them have no effect on the real performance of the device, while the remaining 10% or improve some aspects of behavior devices at the expense of others, or so insignificant increase productivity, you do not even notice it. From what really works, we can note the following:
****Acceleration. The small acceleration to improve performance and andervolting - save a little battery.
****Database Optimization. I seriously doubt that this will give a noticeable increase in speed, but the theory tells us that the work should be.
****Zipalign. Ironically, despite the built-in Android SDK feature content alignment within the APK-file in the store you can find a lot of software is not transmitted through zipalign.
****Disable unnecessary system services, removing unused system and seldom-used third-party applications.
****Custom kernel with optimizations for a specific device (again, not all nuclei are equally good).
****Already described I/O scheduler noop.
****Saturation algorithm TCP westwood +. There is evidence that he is in wireless networks more efficiently used in the default Android Cubic. Available in custom kernels.
Useless settings build.propLaraCraft304 from XDA Developers forum has conducted a study and found that an impressive number of /system/build.prop settings that are recommended for use "experts" do not exist in the source AOSP and CyanogenMod. Here's the list:
ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
ro.kernel.checkjni
dalvik.vm.verify-bytecode
debug.performance.tuning
video.accelerate.hw
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
ersist.sys.shutdown.mode
ro.HOME_APP_ADJ
To be continued...