Related
I was just wondering, why do we try to optimize stock .apks? If HTC or T-Mobile released them, I doubt they would purposely bloat them up or anything to make them even the slightest bit slower. What if our "optimizing" instead has zero or in fact adverse side effects? My point is if it could be further optimized, then HTC would do it. (This is just out of curiosity)
Well, to be brutally honest, I highly doubt T-mo, HTC, etc. actually goes through their newly made apk, to look for any and all optimizations right off the bat, their most likely far too busy, and odds are, they could care less, as long as it fits in the first place.
As far as adverse effects, I for one haven't noticed anything slow/unacceptable about any apps, I've ever used
And most of the optimizations are so that the apk will fit in the actual ROM release ( guessing here, I'm not really a 'developer' ;P ) givin' that the rom contains many apps/etc.
Although with most apps2sd stuff going on now, I don't see the point, but it's still valid
(Look at in the eyes of a user, if a file is 20mb, and takes 20secs to dl, or 10mb and takes 10secs to dl, for the exact same thing, which would you pick?)
Hope I cleared up some stuff, or at least brought up some more/different questions xD
The real reason? So "devs" can type "ZOMG! Optimized all apks!!!" on their rom descriptions. The supposed "optimization" boils down to two steps: using optipng or roptipng; a tool that does some agressive, yet still lossless, compression passes to png formated images and reduces their sizes by certain amounts (depending on previous compression, up to ~60%), and then running zipalign; a tool from the android sdk that aligns the zip/apk to dalvik memory so that loading and execution become a tiny bit faster.
coolbho3000 made a windows bat script that does all that automatically plus a third step, compressing the apk/zip to anorexic levels with an agressive, mx5 zip compression. This usually cuts down the size of the /system/app folder a reported 10%.
Why do it? Size. It's the ONLY advantage. Most people seem to forget that compression requires decompression at runtime, and the more aggresive the compression algorithm used, the more cpu cycles and memory it requires to decompress, in fact, making your whole experience slower and less enjoyable. About the only thing that's beneficial in the whole "optimization" is running zipaling, but then whatever gain is lost by the heavy compression everywhere.
Don't get me wrong, shrinking everything has it's advantages, for example, I was able to whip a WHOLE Hero build into the space of the death spl's /system partition because of compression, but actual usage was frustrating because the system would so often run out of memory (or, if used with 64 MB compcache, be just too slow). I actually created another build (just a test) with no compression anywhere, just zipalign, and it was so enjoyably fast, but having only 20 MB left in /data after a fresh install is no fun...
So there you go! roptipng>7za>zipalign make all masters of "optimization" (we have only about 1 person here in the forum who's actually gone on the nitty-gritty of editing baksmali dumps and actually trying to make the damn thing run faster/properly).
If you have ever had T-Mobile motorola Z3, then you kow that T-Mobile DOES slow down the os on phones they can, or at least some of their proprietary apps do, like my faves, cause thats what got me into modding a lot, (and comp programmin ) i just wanted a faster z3 lol.
This is now android works. The way I see this, this is very much similar to "pre-fetch" concept in windows 7.
I have a 6 GB RAM laptop. Base OS uses less than 1.5 GB of RAM. But like an hour or so when I see my RAM usage, its to the tune of 3-4 GB. What I have noticed is that my most frequently/recently used apps are loaded to RAM and kept there idle. Some amount of RAM is always kept free instead of using up all RAM. This way apps start faster. When I load a different memory heavy program, it pushes the existing one out and loads this.
More or less the same in android too. When u go to any task manager app n see the running apps, u'll notice that many of the apps loaded are the ones u use frequently.
These apps do NOT use any CPU. They are just loaded to memory and kept there for quick access.
When I boot up my phone I have like 190+ MB free RAM. Though left in standy mode, within an hour, I see my free RAM fall to 80-120 MB range. I never saw it go less than 80 MB. And the apps in memory are the ones I used the last time, and the ones I use all the time.
Even if u use a task killer to kill these "inactive" apps at intervals, they would be loaded again sooner or later. That's the principle of android. So by using task killers, though u feel u r freeing up memory, in fact, u r only draining ur battery. What's the use of memory if u r not using it effectively.
Don't worry abt free RAM amount. Let android manage it. Systems are intelligent enough these days.
Hope this helps. Below is more about the same in detail.
Android Memory Management
Android is a Linux based OS with 2.6.x kernel, stripped down to handle most tasks pretty well. It uses native open source C libraries that have powered Linux machines for years. All the basic OS operations like I/O, memory management, and so on, are handled by the native stripped-down Linux kernel.
How to use memory for each application
Android’s process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.
Each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management to the Android run time, which stops and kills processes as necessary to manage resources.
Dalvik and the Android run time sit on top of a Linux kernel that handles low-level hardware interaction including drivers and memory management, while a set of APIs provides access to all of the under- lying services, features, and hardware.
Dalvik Virtual Machine Dalvik is a register-based virtual machine that’s been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.
The Dalvik Virtual Machine
One of the key elements of Android is the Dalvik virtual machine. Rather than use a traditional Java virtual machine (VM) such as Java ME (Java Mobile Edition), Android uses its own custom VM designed to ensure that multiple instances run efficiently on a single device.
The Dalvik VM uses the device’s underlying Linux kernel to handle low-level functionality including security, threading, and process and memory management.
All Android hardware and system service access is managed using Dalvik as a middle tier. By using a VM to host application execution, developers have an abstraction layer that ensures they never have to worry about a particular hardware implementation.
The Dalvik VM executes Dalvik executable files, a format optimized to ensure minimal memory foot- print. The .dex executables are created by transforming Java language compiled classes using the tools supplied within the SDK.
Understanding Application Priority and Process States
The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s priority is equal to its highest-priority component.
Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports.
All Android applications will remain running and in memory until the system needs its resources for other applications.
It’s important to structure your application correctly to ensure that its priority is appropriate for the work it’s doing. If you don’t, your application could be killed while it’s in the middle of something important.
The following list details each of the application states shown in Figure (see the attached image) explaining how the state is determined by the application components comprising it:
Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.
Active processes include:
* Activities in an “active” state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter.
* Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
* Services that are executing an onStart, onCreate, or onDestroy event handler.
Visible Processes Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.
Started Service Processes Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.
Background Processes Processes hosting Activities that aren’t visible and that don’t have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat- tern to obtain resources for foreground processes.
Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when they’re re-launched. These processes are rou- tinely killed as required.
How to use memory efficiently
Android manages opened applications which are running in the background, so officially you shouldn’t care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness’ in everyday performance. We can use advanced task killer/task manager and it does its job very well.
Source:
Code:
http://mobworld.wordpress.com/2010/07/05/memory-management-in-android/
NICE!!
diablo009 said:
This is now android works. The way I see this, this is very much similar to "pre-fetch" concept in windows 7.
I have a 6 GB RAM laptop. Base OS uses less than 1.5 GB of RAM. But like an hour or so when I see my RAM usage, its to the tune of 3-4 GB. What I have noticed is that my most frequently/recently used apps are loaded to RAM and kept there idle. Some amount of RAM is always kept free instead of using up all RAM. This way apps start faster. When I load a different memory heavy program, it pushes the existing one out and loads this.
More or less the same in android too. When u go to any task manager app n see the running apps, u'll notice that many of the apps loaded are the ones u use frequently.
These apps do NOT use any CPU. They are just loaded to memory and kept there for quick access.
When I boot up my phone I have like 190+ MB free RAM. Though left in standy mode, within an hour, I see my free RAM fall to 80-120 MB range. I never saw it go less than 80 MB. And the apps in memory are the ones I used the last time, and the ones I use all the time.
Even if u use a task killer to kill these "inactive" apps at intervals, they would be loaded again sooner or later. That's the principle of android. So by using task killers, though u feel u r freeing up memory, in fact, u r only draining ur battery. What's the use of memory if u r not using it effectively.
Don't worry abt free RAM amount. Let android manage it. Systems are intelligent enough these days.
Hope this helps. Below is more about the same in detail.
Android Memory Management
Android is a Linux based OS with 2.6.x kernel, stripped down to handle most tasks pretty well. It uses native open source C libraries that have powered Linux machines for years. All the basic OS operations like I/O, memory management, and so on, are handled by the native stripped-down Linux kernel.
How to use memory for each application
Android’s process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.
Each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management to the Android run time, which stops and kills processes as necessary to manage resources.
Dalvik and the Android run time sit on top of a Linux kernel that handles low-level hardware interaction including drivers and memory management, while a set of APIs provides access to all of the under- lying services, features, and hardware.
Dalvik Virtual Machine Dalvik is a register-based virtual machine that’s been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.
The Dalvik Virtual Machine
One of the key elements of Android is the Dalvik virtual machine. Rather than use a traditional Java virtual machine (VM) such as Java ME (Java Mobile Edition), Android uses its own custom VM designed to ensure that multiple instances run efficiently on a single device.
The Dalvik VM uses the device’s underlying Linux kernel to handle low-level functionality including security, threading, and process and memory management.
All Android hardware and system service access is managed using Dalvik as a middle tier. By using a VM to host application execution, developers have an abstraction layer that ensures they never have to worry about a particular hardware implementation.
The Dalvik VM executes Dalvik executable files, a format optimized to ensure minimal memory foot- print. The .dex executables are created by transforming Java language compiled classes using the tools supplied within the SDK.
Understanding Application Priority and Process States
The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s priority is equal to its highest-priority component.
Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports.
All Android applications will remain running and in memory until the system needs its resources for other applications.
It’s important to structure your application correctly to ensure that its priority is appropriate for the work it’s doing. If you don’t, your application could be killed while it’s in the middle of something important.
The following list details each of the application states shown in Figure (see the attached image) explaining how the state is determined by the application components comprising it:
Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.
Active processes include:
* Activities in an “active” state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter.
* Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
* Services that are executing an onStart, onCreate, or onDestroy event handler.
Visible Processes Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.
Started Service Processes Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.
Background Processes Processes hosting Activities that aren’t visible and that don’t have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat- tern to obtain resources for foreground processes.
Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when they’re re-launched. These processes are rou- tinely killed as required.
How to use memory efficiently
Android manages opened applications which are running in the background, so officially you shouldn’t care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness’ in everyday performance. We can use advanced task killer/task manager and it does its job very well.
Source:
Code:
http://mobworld.wordpress.com/2010/07/05/memory-management-in-android/
Click to expand...
Click to collapse
Sweet!! Good Info.. But wrong Section. You should port this in the General Section to help all!
rickysa2000 said:
Sweet!! Good Info.. But wrong Section. You should port this in the General Section to help all!
Click to expand...
Click to collapse
Oh. I thought this belongs to Q&A.
Any mods here who can move this to "General" please.
This would be why when you open the built in task manager nothing or only your launcher shows up but when you open ATK multiple other programs are shown open, correct?
I found similar information while researching battery saver programs. I keep ATK when I have stubborn apps that are stuck because it is easier to get through than Android Task Manager but the auto-kill feature is always disabled. Good coverage of this info.
bclark said:
This would be why when you open the built in task manager nothing or only your launcher shows up but when you open ATK multiple other programs are shown open, correct?
Click to expand...
Click to collapse
Exactly! If all programs/processes show up, like they do in ATK, it could cause instabilities in the system when the user kills any important process knowingly/unknowingly.
trekie86 said:
I found similar information while researching battery saver programs. I keep ATK when I have stubborn apps that are stuck because it is easier to get through than Android Task Manager but the auto-kill feature is always disabled. Good coverage of this info.
Click to expand...
Click to collapse
Thanks you. Saw too many threads/posts with questions about ATK and killing tasks. So compiled this so they could all be directed to this thread.
I don't mean to go digging up old threads, but I just wanted to post my opinion here on this memory clearing ordeal.
After reading the entire thread, I am even MORE inclined to want to use ATK or something similar...
At the very bottom of the post, last paragraph, it reads -
How to use memory efficiently
Android manages opened applications which are running in the background, so officially you shouldn’t care about that. This means that it closes the applications when the system needs more memory. However, most android users are not very satisfied with how it does its things because sometimes it leaves too many processes running which causes sluggishness’ in everyday performance. We can use advanced task killer/task manager and it does its job very well.
Click to expand...
Click to collapse
Here's my take -
While there is no way to override Dalviks operations for application retention, at least while you're operating the device you can keep the memory clear by monitoring and assisting in clearing it out, manually; Which will in fact yield a performance boost for a duration of time. Based on the description of how Dalvik operates, this is true.
Exactly how long of a duration I don't know. But it is as obvious as it gets that while Dalvik memory management is indeed cool, it is far from perfect and definitely induces low memory situations that CAN in fact cause sluggish performance. That much is already known.
So, in my opinion, if you enjoy the absolute maximum performance out of your device, ATK or something similar is definitely NOT a bad idea. Though it has to be done manually and after a period of time applications are brought back into memory, clearing the memory before opening an application allows full memory access to that application and also inevitably reduces CPU load as it removes the requirement for Dalvik to "shove" other applications on idle off the memory to make room for the active applications.
Personally, I just use Task Manager. It seems much more effective at clearing the memory.
Well, there are times when my phone is on for abt a week or so without turning off or rebooting (the times when I resist flashing roms or kernels or modems) and still I hardly feel any sluggishness. And I do NOT use any task killers. I let android handle everything its way.
And there is a difference between cleaning up memory say once every couple days, and having ATK set up to free up memory every hour or two. The first one could be helpful while the second is a battery killer.
rickysa2000 said:
Sweet!! Good Info.. But wrong Section. You should port this in the General Section to help all!
Click to expand...
Click to collapse
why quote such a big post to tell this
come on
regards
strategist99 said:
why quote such a big post to tell this
come on
regards
Click to expand...
Click to collapse
^
Why necropost ?!? Come on !
(just messin with ya)
Sent from my SGH-I897 using xda premium
how about file expert's memory management options?
ok - i get what's being written at the top of this. however, i do wonder about being able to tweak things some, mainly because on file expert's memory manager there's several memory config options: gamer, multi-tasker, light user, whatnot.
i got a phone to fit in my pants pocket, so it doesn't come with tons of RAM. and it freezes quite a bit when swapping between apps. of course there could be many other reasons, but still...
file expert's options don't seem to be persistent, so it's hard to get a handle on which setting would work best. now - would there be a way of making persistent memory optimization changes? if, how?
what is an amount of free memory that would need to be there for things to be smooth? by ATK, i get south of 50Mb quite often, which seems low.
i don't really like ATK's auto-kill - don't know what it will kill, and it seems that a free memory kill-threshold would be better than one based on time.
zdoe said:
ok - i get what's being written at the top of this. however, i do wonder about being able to tweak things some, mainly because on file expert's memory manager there's several memory config options: gamer, multi-tasker, light user, whatnot.
i got a phone to fit in my pants pocket, so it doesn't come with tons of RAM. and it freezes quite a bit when swapping between apps. of course there could be many other reasons, but still...
file expert's options don't seem to be persistent, so it's hard to get a handle on which setting would work best. now - would there be a way of making persistent memory optimization changes? if, how?
what is an amount of free memory that would need to be there for things to be smooth? by ATK, i get south of 50Mb quite often, which seems low.
i don't really like ATK's auto-kill - don't know what it will kill, and it seems that a free memory kill-threshold would be better than one based on time.
Click to expand...
Click to collapse
Auto-kill is quite bad as the it kills processes that always reset.
As for your ram, you could run a Bigmem kernel. 50ram is fairly normal with regular processes and a couple extras. It all depends on what you use/run.
I would need your phone's setup to help you more towards it though.
xperia ray, snapdragon, 512Mb of RAM
don't know what bigmem kernel is or would do. i'm a noob.
the phone as above. list of installed apps courtesy titanium attached - except i've since killed ATK and now trying autokiller, which is good at least for the SD-card parameter tweaks it gives. not sure about its memory management aspects, but at least they're persistent.
list of apps
here's the list - the forum didn't take .htm
and i'm on CM7.2.
EDIT/UPDATE: unrelated to killer apps, but for those of you who came to this thread to find remedies for RAM shortage - my observation currently is that the best thing you can do to yourself is to enable swap. that, and taking out the "play store" took me from 5 crashes a day to 1 - and after half a day of multi-tasking apps i can see up to 80Mb of swap in use, with 60Mb of RAM free, and the phone still running smoothly.
How to detect if an app is in background
In the above article it is said that the memory management is completely under control of Dalvik VM and Android runtime.
Is it not possible for a device driver to intelligently check if any app in background and release memory (allocated inside driver).
onStop(): All the rendering is stopped.
Is it possible to check some app state value to see if app in background or minimized?
This is not the explanation of memory management but process management
I have open this thread for all(me included)user with no idea about ART,so here are some infos about it,what is ART,how does it work,pro+cons.
Maybe its helpfull for some peeps here.Source: Android Police
Link p1
Link p2
-------------
Part 1:
It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.
What Is ART?
ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.
At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from libdvm.so to libart.so, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.
How Much Better Is It?
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.
What Are The Compromises?
There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.
Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!
---------------------------------------------
Part 2 in next post.....
Part 2
---------
By now you've probably heard about ART and how it will improve the speed and performance of Android, but how does it actually perform today? The new Android Runtime promises to cut out a substantial amount of overhead by losing the baggage imposed by Dalvik, which sounds great, but it's still far from mature and hasn't been seriously optimized yet. I took to running a battery of benchmarks against it to find out if the new runtime could really deliver on these high expectations. ART is definitely showing some promise, but I have to warn you that you probably won't be impressed with the results you'll see here today.
Reality Check
Let's be honest, benchmarking apps tend to be inaccurate and unreliable, often giving wildly varying results even when run in precisely identical situations. However, they are the only option available for recording meaningful and measurable values on performance. Further, since most popular benchmarks are built on the NDK (Native Development Kit), they won't gain any benefit from running under ART. Despite these limitations, there are some interesting and unexpected results that help us learn a little more about the current state of performance.
How The Benchmarks Were Run
Each benchmark was run at least 4 times on a completely stock Nexus 5 (it isn't even rooted) with both Dalvik and ART. To ensure there was no interference from apps at startup, a minimum of 5 minutes was given after a reboot before any tests were run. In addition to the 6 benchmarking apps listed below, I also tried 2 browser benchmarks (SunSpider & BrowserMark) in Chrome, but neither displayed significantly different scores. So, let's get to the results.
Linpack for Android
One of the key factors in getting good test results is knowing that the tools are measuring the right thing. While many of the benchmark apps target the NDK, a few stick to the SDK. The first and most consistent among them is Linpack for Android, a port of the already popular benchmarking app used throughout numerous computing platforms. It produces a score by performing a series of calculations on floating point numbers. I think this is an obvious choice after reading the description, "This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor." Thanks to ART, scores are 10%-14% higher than they would be with Dalvik. Not too shabby…
Real Pi Benchmark
Calculating digits of Pi is another popular way of stressing a processor, and particularly suitable because most methods stick to integer calculations and avoid floating-point math entirely. Along with Linpack, this gives us coverage of both basic mathematical operations. On top of it, Real Pi happens to use native code to perform the AGM+FFT formula, but uses Java for Machin's formula. On the native side, ART came out about 3.5% faster, probably due to interface optimizations rather than mathematical performance. More importantly, testing with the java code turned out to be 12% faster. (link) Note: in this test, lower numbers are better.
Quadrant Standard
The previous tests are highly specific to mathematical performance, so it's time to branch out to test more of the system. Both Linpack and Real Pi show some positive improvement with ART, but Quadrant gave a result that borders on the amazing, perhaps even too good. The CPU score is off the charts for ART, almost doubling that of Dalvik, which is substantially better than even the most optimistic estimates we've heard so far... While tests for I/O, 2D, and 3D rendering show fairly negligible differences, Dalvik does take an oddly high 9% advantage in the memory test.
3D Mark
I was leery of using a benchmarking app that clearly focuses on the NDK, as it theoretically shouldn't be affected very much by ART. However, as the tests were run, an interesting pattern emerged where the Dalvik runtime repeatedly held a slight advantage. It's difficult to attribute a reason for Dalvik to do better here, but I'm open to theories.
AnTuTu Benchmark
Breaking performance down even further, AnTuTu helps to expose a pattern. It's increasingly clear that ART is making significant strides with floating-point operations, but doesn't usually turn out huge gains for integers. A strong showing in "RAM Operation" also hints at better use of caching as opposed to just raw memory I/O. These high scores indicate areas where the Dalvik virtual machine was probably very expensive, causing more extensive overhead. The other results weren't particularly remarkable except for the Storage I/O, which might suggest a couple of specific optimizations. One significantly low score appears for UX Dalvik, but it's not clear what AnTuTu is measuring, so this may not be particularly relevant.
CF-Bench
For the ultimate in number production, Chainfire's own benchmark tool takes out a lot of the guesswork by performing tests built on both the SDK and NDK. Again, native code displays a small but curious advantage on Dalvik. Here we can see the integer calculations are swinging back towards Dalvik, as well. Mostly confirming the pattern, floating-point operations demonstrate a significant speed gain, this time in the 23%-33% range.
Other Interesting Measurements
Measuring the first boot after switching runtimes isn't your typical test, no doubt, but the time it takes is quite striking. I wanted to record just how long it took to complete both the App Optimization step and then the total time to actually reach the unlock screen. When I ran this test, I had 149 apps installed.
The Other Stuff
While numbers can be helpful, they don't tell the full story. Benchmarks usually push the hardware to work as hard as possible for a few seconds, then switch to a new test that does the same thing. Sadly, this ignores details that aren't easily measured. I don't have a good way to measure the smarter timing of memory management (especially garbage collection) or better handling of multiple threads. While I can't show numbers for these things, I can demonstrate them. The classic test for a browser simply requires flinging the page as fast as possible and watching it try to keep up. After stress testing Chrome for Android with the mobile version of David's gigantic HTC One review, it turns out that even the supercharged SoC of the Nexus 5 can't quite keep up while running on Dalvik… ART, on the other hand, never lost a pixel. Take a look for yourselves.Videos below.
Fast scrolling with dalvik: http://youtu.be/JGyktLPvORU
with ART: http://youtu.be/L9lpCssSdMc
To be fair, switching to the desktop version and giving a single fling will easily send you into blank screen territory, but it's still obvious that the renderer catches up faster on ART than on Dalvik. When more optimizations are in place, maybe we won't be far off from flawless scrolling even in the desktop version. For another demonstration, a user by the name of spogbiper has posted his own side-by-side comparison with two Nexus 7s. The one running ART seems to be more responsive.
Summary And Conclusions
The numbers and the videos together paint a picture of where ART stands today. It will definitely make a difference, but its current incarnation just hasn't matured enough to deliver significant gains. Floating-point calculations and basic responsiveness are obviously reaping the benefits of the new runtime, but that's about it. There's little or no overall improvement for integer calculations, most regular code execution, or much of anything else. In fact, it looks like gamers would be better served by sticking to Dalvik, for now.
Why aren't the benchmarks blowing us away? If I were to make a guess, it's probably because the first goal in developing ART was to make sure it was functional and stable before the heavy optimizations came into effect. If that's the case, there is probably quite a bit of code for error-checking and logging just to ensure everything is operating as it should, which might even be responsible for more overhead than we had with Dalvik. Even in the places where ART doesn't outperform Dalvik, the numbers tend to remain reasonably close. As subsequent versions of the runtime emerge from Mountain View, we should expect to see the performance gap growing wider as ART pulls ahead.
Now for the real question: is it worth switching to ART right now? Google obviously isn't recommending it for regular users, and I tend to agree. While ART seems very solid and I feel like responsiveness is better - possibly just the placebo effect - there are still circumstances where it is unstable and causes apps to crash. If there is even a single instance where you have to switch back to Dalvik to get an app to run correctly, that inconvenience far outweighs the minimal performance gain you might have had. Once I've finished this series, I will probably stick to Dalvik for the remainder of KitKat; and I imagine most people will be better served by doing the same.
Introducing ART from: source.android.com
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)
The dalvikvm command line tool can run with either of them now. See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.
A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.
Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart
------------------------------------------------------------
MANY GREEEETZ+STAY ADDICTED!!!!
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
velosa said:
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
-CALIBAN666- said:
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
Click to expand...
Click to collapse
Thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
thank you very much for your work about ART presentation ! very nice and perfect ! :good:
conclusion : don not use ART for the moment on CM11 ! ok ! wait more stability ...
i've downloaded gapps kk from cr3pt thread for cm 11, while i'm waiting for more stability i wanna ask you if they are art compatible.
Best presentation of ART!
When the gapps are odexed than yes.
STAY ADDICTED,GREEEETZ!!!
I don't know anything about rooting phones was just curious if maybe someone could take this exploit and use it for good use and we would be able to root our phones. I used a program called Quadrooter By Checkpoint and we are vulnerable to CVE-2016-2059 (Elevation of privilege vulnerability in Qualcomm networking component) and CVE-2016-2504 (The Qualcomm GPU driver devices allows attackers to gain privileges via a crafted application, aka Android internal bug 28026365 and Qualcomm internal bug CR1002974.). I'm on Marshmallow with the latest updates.
The article is here
http://thehackernews.com/2016/08/hack-android-phone.html
That is interesting, im not a developer, so im no help, only to test if someone comes up with something. 5.0 OF3.
Quadrooter is a menace, yes, in short time, around 2 months, the gpu may be destroyed only installing unchevked apks.
They are doing a new kind of apk, that i am searching how to forbid these "new" apk model, named as multi dex system.
This is running binary codes inside the cache of the app.
For example:
The telegram.apk is all disabled, the system is capting that all relative to trlegram.apk, is not running.
When you never imagine, a notification, appears on the bar, showinh a new message, but, why?
The app is disabled, but the cached-dex no.
This is a serious menace, because these cached codes are "temporary".
If some "cached dex" is executing, the ram memory goes down, and the system, does not captures this dex running.
Imagine another worst thing:
Any cached dex is programmed to copy and send some victim's bank password for determinated site, in background, on where the system will never shows the relathive dex process at least the relative apk that created this dex.
Be carefull only with the apks thst you install, and never use if is multidex .
You can check if is multidex or not before installing, if haves zipped or jar classes , don't install.
Or the device may be burned.
That is all
Sent fro SomeFon
Automatically optimizes SQLite databases on boot, on schedule, every X days.
Just a quick and dirty adaptation of an old SQLite3 optimizer script from init.d days to a Magisk Module using a service.sh script instead, with an internal date offset mechanism to run the script every X days (default: 3 - which is plenty, and specifically to stop silliness).
Update And credit note: finally after a fair bit of digging, i think i located the original author of the original init.d version of the main vacuum code snippet ive repurposed (stolen) for this module. It appears to be from user @mcbyte_it (doesnt seem to be current or active) and from a post here. Although i only saw derivative reworkings of this script, and used only the main sqllite script function, i arrived at a different method of tracking last run date, when his is arguably more mainstream/concise. Im fairly certain this is the originator especially as the post also has a zipalign script that was also suggested to me to do....and which i have been fiddling with for months....
The script will wait until boot is completed AND then until avg CPU usage is under 30%, to minimise the risk of possible corruption.
Disclaimer: As always any use of any 3rd party script/software/advice is at the users discretion. All reasonable efforts have been made to make this as safe as possible, but the responsibility ultimately falls to the user whether to use and run the script.
What it does:It:
Reindexes
Vacuums
Analyzes
all .db files under /data.
It runs a 1st run optimize after install (temp file optimsql_first_run on sdcard is used to enable this, and removed after first run), and then on schedule after that.
By default it logs just script progress to /storage/emulated/0/autosqlite.log, but you can choose to enable more detail in the log if you wish
User Configurable Options:The schedule and loglevel can be changed by an external file on sdcard:
Create a file named autosqlite_options on sdcard (/storage/emulated/0/)
Inside create the follow key=value pairs to suit your preference:
interval=x (where x is the number of days between script runs, for the love of god do not put 1 (this goes out especially to the kind of people who put every app on their Magisk magiskhide/deny list) there is no benefit and you just heighten the possibility of corruption)
loglevel=x (where x is either 1 (detailed logging) or 0 (basic logging - default))
Requirements:This module requires a working SQLite3 binary. If your ROM does not provide one (you can check via typing sqlite3 into a terminal), you can choose to use my SQLite3UniversalBinaries module located here:
https://github.com/stylemessiah/SQLite3UniversalBinaries
Dont forget you need to download a named SQLite3UniversalBinaries.vx.x.zip file from the Releases page under Assets. Do not try installing the source code with Magisk Manager, it will not go as you expect
All the modules action takes place in the service.sh file, its commented reasonably well for those wanting to check how it works
* See... now theres something else to use with my SQLite3 Universal Binaries module other than the GPay SQlite Fix Module <- dont use that anymore, it makes me stabby. It is literally the last resort for getting Google Pay/Wallet to work ,
Please note: the included LICENSE only covers the module components provided by the excellent work of @Zackptg5 's Magisk Module Extended, which is available for here for module creators
https://github.com/Zackptg5/MMT-Extended/
All other work is credited above and no one may fork or re-present this module as their own for the purposes of trying to monetize this module or its content without all parties permission. The module comes specifically without an overall license for this intent.
Download:
Repo: https://github.com/stylemessiah/AutomaticSQLiteDBOptimizer
Release: https://github.com/stylemessiah/AutomaticSQLiteDBOptimizer/releases/latest
Powered by Ponkle
@73sydney Nice! If you're looking for newer sqlite3 binaries, I have a build script you can use to build it or you can just grab the precompiled ones at my repo: https://github.com/Zackptg5/Cross-Compiled-Binaries-Android
Zackptg5 said:
@73sydney Nice! If you're looking for newer sqlite3 binaries, I have a build script you can use to build it or you can just grab the precompiled ones at my repo: https://github.com/Zackptg5/Cross-Compiled-Binaries-Android
Click to expand...
Click to collapse
cheers man, i was trying not to pinch all your toys
i mean i could have done an androidacy and scraped your repo for just the files i needed
plus im lazy
73sydney said:
optimizes SQLite databases
Click to expand...
Click to collapse
Nice
how about no schedule, i want to execute it whenever i want
possible ?
loopypalm said:
Nice
how about no schedule, i want to execute it whenever i want
possible ?
Click to expand...
Click to collapse
I refer the gentleman to the name of the module and title of the thread:
"Automatic SQLite DB Optimizer"
the distinct lack of the word "manual" should be a clue
what are they teaching in school these days?
i made this to be automatic and made special note about the intervals because theres people who would abuse this and run it every day if they could, both designed to avoid misuse/abuse:
interval=x (where x is the number of days between script runs, for the love of god do not put 1 (this goes out especially to the kind of people who put every app on their Magisk magiskhide/deny list) there is no benefit and you just heighten the possibility of corruption)
im not really interested in making a manual version option unless you can convince me where there is a use case benefit, because all i see is potential for misuse/abuse that i specifically made this to avoid....
running it by default it runs every 3 days which is twice a week and probably still overkill, but trying to cover all bases
your other option is to ask me for permission (sadly because of abuse in the past from certain entities trying to monetize my and others work, my contributions are not GPL etc) to fork and alter the code yourself....
73sydney said:
I refer the gentleman to the name of the module and title of the thread:
"Automatic SQLite DB Optimizer"
the distinct lack of the word "manual" should be a clue
what are they teaching in school these days?
i made this to be automatic and made special note about the intervals because theres people who would abuse this and run it every day if they could, both designed to avoid misuse/abuse:
interval=x (where x is the number of days between script runs, for the love of god do not put 1 (this goes out especially to the kind of people who put every app on their Magisk magiskhide/deny list) there is no benefit and you just heighten the possibility of corruption)
im not really interested in making a manual version option unless you can convince me where there is a use case benefit, because all i see is potential for misuse/abuse that i specifically made this to avoid....
running it by default it runs every 3 days which is twice a week and probably still overkill, but trying to cover all bases
your other option is to ask me for permission (sadly because of abuse in the past from certain entities trying to monetize my and others work, my contributions are not GPL etc) to fork and alter the code yourself....
Click to expand...
Click to collapse
i was planing to use it once a week
categorizing me with people who do dumb stuff is an 'insult'
i asked a simple question man, don't jump to level 3 mind game please ...
loopypalm said:
i was planing to use it once a week
categorizing me with people who do dumb stuff is an 'insult'
i asked a simple question man, don't jump to level 3 mind game please ...
Click to expand...
Click to collapse
Im sorry, did you miss the double smileys intended to completely avoid any misunderstanding that i was being jovial. the other tip off that i wasnt burning you was taking the time to write several paragraphs
Can i suggest you just set the options file interval to 6 or 7 and let the module do what its described in the title as doing, it would make no functional difference, other than saving you a trip to terminal?
As i said, give me a valid reason for adding a manual option and ill gladly consider it, choosing a reason that fits completely within the actual parameters of the existing module doesnt really fit that offer...
ill go further to why i specifically didnt put in an option to run it manually (really folks are lucky i didnt block the option to run it every day) because you should understand what the sqlite vacuuming and other processes do:
* They copy the data from the db file to temp file before optimising it and writing it back, at any point in this theres the potential for corruption (sudden power loss, other processes accessing the file etc). Ideally any such corruption would be minimised by journaling but anyone who had used Linux for long enough knows not to count on such things.
* If any db is being written to, then the optimization process will NOT optimize that db...for the above possible corruption reasons. Hence why i not only put in a wait till boot completed function BUT also added a function to block the script from running unless avg cpu load over 5 minutes is less than 30%. all this to try and make things as safe as possible. So im not overly fond of a manual option which bypasses these safeties i specifically put there to hopefully safeguard people as best as possible. I dont want to get messages about how my module hosed someones apps.
Perhaps that better addresses my reasons?
As said, you can also ask me to fork the code, and ill even tell you how to add a manual function, but i personally wont be releasing such a version without a better reason than i want to do it every 7 days, when the script as it stands can do that AND at a far more predictably safe time and way than you manually likely can or will use it....
BTw, how is actually responding, even taking the time to do so and being jovial about it "level 3 mind games?", whatever the hell that even is?
73sydney said:
.
Click to expand...
Click to collapse
i was planing to make a recovery backup of "DATA" after the optimization of DB files ...
if you want better result add a comand to kill the coresponding app, then it would be more stable
or tell the people to use FlushRam or something like that before the proccess start, to make sure the result will be good, or make a 2nd module for advanced users ...
even with the condition you said some system apps stays working in the background and messing with their data can lead to corruption
i don't know you or your previous work and i don't have time to care for that
i just asked a simple question
answer with "NO, my module will not do that"
this will save your time and other people time
loopypalm said:
i was planing to make a recovery backup of "DATA" after the optimization of DB files ...
if you want better result add a comand to kill the coresponding app, then it would be more stable
or tell the people to use FlushRam or something like that before the proccess start, to make sure the result will be good, or make a 2nd module for advanced users ...
even with the condition you said some system apps stays working in the background and messing with their data can lead to corruption
i don't know you or your previous work and i don't have time to care for that
i just asked a simple question
answer with "NO, my module will not do that"
this will save your time and other people time
Click to expand...
Click to collapse
1) whether before or after backup, the files will eventually get optimized - if you want a more manual version use SD Maid or as offfered you can ask me how to alter the code as it sits and make your own version.
2) Im not ever releasing a script that kills anyones apps in the background, i would consider that suboptimal, and basically malware
3) I never said that some "system apps stays working in the background and messing with their data can lead to corruption". What i said was i designed the script to best avoid corruption by running only after boot completed and when avg CPU usage over 5 minutes was less than 30%. The sqlite3 itself generally wont allow access to a file in use. Im just adding what i think is a reasonable level of extra safety by deciding when the optimization routine starts to run, and that it isnt abused/misused by running multiple times in an unreasonable timeframe
4) How does
I refer the gentleman to the name of the module and title of the thread:
"Automatic SQLite DB Optimizer"
the distinct lack of the word "manual" should be a clue
not equal "NO, my module will not do that", only with some attempt at humour and a long explanation (soon followed by a more reasoned explanation) because i didnt want to appear dismissive. Yet it looks like you’d have preferred dismissive??
You seem impossible to please anyway someone tried to do it....
To be honest Im tired of this circular conversation. Everyone else knew from the word automatic in the title how things was going to work. Ive made suggestions of alternatives (SD Maid) and even offered to give you the info to change the script for yourself, and cant do more than that.... please choose one and lets move on, please?