Saturday, December 7, 2013

memory usage of my app in Android

Memory usage on modern operating systems like Linux is an extremely complicated and difficult to understand area. Android apps have more memory available to them than ever before, but are you sure you're using it wisely? This talk will cover the memory management and explore tools and techniques for profiling the memory usage of Android apps.
 

first question is in my mind is how to know application heap size available to an Android app. ofcourse it may vary on the basis of phone device.

  1. How much heap can my app use before a hard error is triggered? And
  2. How much heap should my app use, given the constraints of the Android OS version and hardware of the user's device?
For item 1 above: maxMemory()
which can be invoked (e.g., in your main activity's onCreate() method) as follows:
Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();
Log.v("onCreate", "maxMemory:" + Long.toString(maxMemory));
This method tells you how many total bytes of heap your app is allowed to use.
For item 2 above: getMemoryClass()
which can be invoked as follows:
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
int memoryClass = am.getMemoryClass();
Log.v("onCreate", "memoryClass:" + Integer.toString(memoryClass));
This method tells you approximately how many megabytes of heap your app should use if it wants to be properly respectful of the limits of the present device, and of the rights of other apps to run without being repeatedly forced into the onStop() / onResume() cycle as they are rudely flushed out of memory while your elephantine app takes a bath in the Android jacuzzi.
At runtime, the heap grows dynamically in size as the Dalvik VM requests system memory from the operating system. The Dalvik VM typically starts by allocating a relatively small heap. Then after each GC run it checks to see how much free heap memory there is. If the ratio of free heap to total heap is too small, the Dalvik VM will then add more memory to the heap (up to the maximum configured heap size).

Memory Anatomy

PSS : Proportional Set Size

Amount of memory shared with other processes, account in a way that the amount is divided evenly between the processes that share it. This is memory that would not be released if the process was terminated, but is indicative of the amount that this process is “contribution” to overall memory load.

USS : Unique Set Size

USS is the set of pages that are unique to a process. This is the amount of memory that would be freed if the application gets terminated.

Heap

Runtime memory available for allocation (Used by applications, services, daemons)

Dalvik Heap

The dalvik heap is preloaded with classes and data by zygote. 

Commands for run time memory usage

  • To spit out a bunch of information about the memory use of each JAVA process
$adb shell dumpsys meminfo 
  • To see memory for particular process: ( e.g. System)
$adb shell dumpsys meminfo system
  • Summary of the overall memory
$adb shell cat /proc/meminfo 

Run Time Memory: Gallery Use Case

Rum time memory usage will depends on kind of use case running on android system. Following are the context where – run time memory will be allocated by android system.
  • All java process will run with the instance of DVM. DVM will again have its own run time heap requirement based on java application code complexity.
  • Binder IPC will allocate run time memory for marshalling objects
  • Service or daemon will allocated run time memory for internal usage
  • Following example will show run time heap change with respect to gallery application use case.
    • Size : Total size of particular heap
    • Allocated : Portion of heap is allocated to process
    • Native Usage : Usage by application or service code
    • Dalvik Usage : Usage by Dalvik virtual machine (libdvm)

Android's inbult API ActivityManager.getProcessMemoryInfo return few more interesting numbers.

The Pss number is a metric the kernel computes that takes into account memory sharing -- basically each page of RAM in a process is scaled by a ratio of the number of other processes also using that page. This way you can (in theory) add up the pss across all processes to see the total RAM they are using, and compare pss between processes to get a rough idea of their relative weight.
The other interesting metric here is PrivateDirty, which is basically the amount of RAM inside the process that can not be paged to disk (it is not backed by the same data on disk), and is not shared with any other processes. Another way to look at this is the RAM that will become available to the system when that process goes away (and probably quickly subsumed into caches and other uses of it).
Android added this crucial topic in detail. http://developer.android.com/training/articles/memory.html
Here is nice youtube link http://www.youtube.com/watch?v=_CruQY55HOk

Friday, December 6, 2013

Five years at infoedge india ltd.

I would like to take this opportunity to talk about a great milestone here at InfoEdge. I complete 5 years of my journey at this company.A journey filled with stories of struggles,success,fights,fun & joy. This journey is made even more memorable,just because of the great co-operation that each one of you always gave. I take pride in THANKING each and every one of you here for the support.I have innumerous moments that make experiences with many ups and downs.But with each experience,whether good or bad,I strongly feel connected.Because the learning cycle never stops.
I have learned from everything,from my mistakes to my appreciation.Of course there were differences,fights & issues but thats all healthy in the quest for success.I intend to continue to support new upcoming leadership talent as we begin our new quest for a great new tomorrow.
Obviously,I intend to carry new burdens and responsibilities too.Just to learn more & get each moment with new excitement in this journey.A JOURNEY THAT WILL NEVER END.
Once again thanks alot!!!


Wednesday, November 6, 2013

R.I.P Codeigniter



See my tweet https://twitter.com/raviraj4u/status/398343198151430144 It's really sad that
EllisLab stop support for codeigniter. CI is very fantastic framework and need to take advantages of PHP's upcoming releases which are more mature and stable. Well i have stopped working on CI since last an year ( currently i am working on Android native app development) but i loved it very much and proudly says that i was involved with CI at core level. Here are few links which shows my contribution to codeigniter.


Even some developer made plugins using my CI code. http://getsparks.org/packages/login-cookie/versions/HEAD/show

I wish that it should go with safe hand. Bye bye Codeigniter !!

Saturday, May 18, 2013

Google Developers Blog: Google I/O 2013: For the developers

Google Developers Blog: Google I/O 2013: For the developers: By Scott Knaster, Google Developers Blog Editor “Google I/O is an annual developer conference featuring highly technical, in-depth sessi...

Tuesday, April 9, 2013

Hybrid app development PhoneGap

Creating mobile apps is a trend nowadays. we've chosen PhoneGAP for creating mobile apps to look at more closely. So, let’s start. but big question is should we use native app or hybrid app or HTML5 based webapp.

PhoneGap application is a “native-wrapped” web application. Let’s explore how the web application is “wrapped”.

Many native mobile development SDKs provide a web browser widget (a “web view”) as a part of their UI framework (iOS and Android, for example). In purely native applications, web view controls are used to display HTML content either from a remote server, or local HTML packaged along with the native application in some way. The native “wrapper” application generated by PhoneGap loads the end developer’s HTML pages into one of these web view controls, and displays the resulting HTML as the UI when the application is launched.

If JavaScript files are included in a page loaded by a web view, this code is evaluated on the page as normal. However, the native application which creates the web view is able to (in different ways, depending on the platform) asynchronously communicate with JavaScript code running inside of the web view. This technology is usually referred to as “the bridge” in the context of PhoneGap architecture – the “bridge” means something slightly different in Titanium, as we will see later.

PhoneGap takes advantage of this to create a JavaScript API inside a web view which is able to send messages to and receive messages from native code in the wrapper application asynchronously. The way the bridge layer is implemented is different per platform, but on iOS, when you call for a list of contacts, your native method invocation goes into a queue of requests to be sent over the bridge. PhoneGap will then create an iframe which loads a URI scheme (“gap://”) that the native app is configured to handle, at which point all the queued commands will be executed. Communication back into the web view is done by evaluating a string of JavaScript in the context of the web view from native code.
There is much more to PhoneGap than that, but the messaging from web view to native code via the bridge implementation is the key piece of technology which allows local web applications to call native code.There’s quite a bit happening behind the scenes in a Titanium application. But basically, at runtime, your application consists of three major components – your JavaScript source code (inlined into a Java or Objective-C file and compiled as an encoded string), the platform-specific implementation of the Titanium API in the native programming language, and a JavaScript interpreter that will be used to evaluate your code at runtime (V8 (default) or Rhino for Android, or JavaScriptCore for iOS). Except in the browser, of course, where the built-in JavaScript engine will be used.

So major differences are:

PhoneGap:

  • JavaScript API that provides access to Native Functions
  • Supports HTML5/CSS3
  • Supports Web Standards & Re-use Across Enterprise Apps
  • Supports DOM based JavaScript Libraries/Frameworks
  • Supports the most platforms

Appcelerator Titanium:

  • JavaScript API that provides access to Native Functions
  • Compiles to Native Code
  • Could provide better performance.

Issues:

Of course, both Titanium and Phonegap fall into the category of “hybrid” but the key difference is implementation: while Phonegap application runs inside browser, Titanium’s app runs inside javascript interpreter. Runtime performances are SLOWER than native code because it's using a javascript engine as a bridge. Especially with a big TableView, it's much more slower, and the feeling is just not the same.

I have build two diff applications based on phonegap for testing purpose and i found that both are very slow as compare with browser rendering. When i cross checked same application in my phone's browsers, it looks much responsive than in app. Might be current browsers are using hardware acceleration by default. I have used mobile Jquery & phone gap APIs for demo.




I know that jquery mobile can be a little slow by nature, imagine my surprise and disappointment when my compiled phonegap app UI is magnitudes slower running on my phone than running in the phone's native browser. How can the compiled app be so noticeably less responsive than the same app running in the phone's native browser? The responsiveness is completely unacceptable.

http://apachecordova.blogspot.in/2012/11/who-is-murdering-phonegap-its-jquery.html

Even phonegap provide better solution to use JS Framework.

Saturday, March 23, 2013

Back to blog : understanding ppi,dpi,mdpi, hdpi, xhdpi

Sorry guys !!! was little bit busy with Quora :-) https://www.quora.com/Ravi-Raj-7

Anyway A man who is losing his house in the morning and reach in evening in house you can not say him the loser :D
Actually in last one -two months i am working on mobile site and apps and found very interesting things. I will share my experience here in my coming posts. So enjoy reading and be sure to leave comments here.

In Feb 1993, Marc Andreessen had requested for new HTML tag, the proposal was proposal for image basically about html tag. We have seen drastically improvements in web & HTML since last few years. People ( http://movethewebforward.org/ , http://www.sultansofspeed.com/ , http://web-performance.meetup.com/all/ ) are contributing to make web faster. Accenture like companies started campaign with slogan "High Performance. Delivered".

According to the HTTP Archive http://httparchive.org/interesting.php,the average web page is 1292 KB, with 801 KB of that page weight — more than 60% — being taken up by images. In shiksha its around 50 -60%. we have seen many algorithms for image optimization http://www.netmagazine.com/features/best-image-compression-tools

Then i found WebP :-) really i appreciate Google Engg. who are trying to make our life easier ...

So here are my findings.

  • Lossy and lossless compression
  • Transparency (alpha channel)
  • Great compression for photos
  • Animation support
  • Metadata
  • Color profiles

Gmail, Drive, Picasa, Instant Previews, Play Magazines, Image Search, YouTube, ...) with WebP support. Most recently, Chrome Web Store switched to WebP, saw ~30% byte reduction on average, and is now saving several terabytes of bandwidth per day!

Back to basic:
A digital photograph is made up of millions of tiny dots called pixels. For example, one camera might produce photos that are 2272 pixels wide and 1704 pixels tall (2272 x 1704). Another camera will produce an image that is 4492 x 3328. You can find out the number of megapixels by multiplying the horizontal and vertical pixels. In the first example, the camera captures about 3.9 megapixels (2272 x 1704 = 3,871,488). In the second example, the camera captures about 15 megapixels (4492 x 3328 = 14,949,376).

Computer monitor generally displays images at 72 pixels per inch. This means that our 3.8 megapixel image is going to measure about 32 inches by 24 inches when viewed on a monitor. We can determine the display size of the image by dividing the horizontal and vertical pixels by 72.

In this case, 2272 / 72 = 31.6 and 1704 / 72 = 23.7. 
Use the 72ppi standard when you want to post an image to the Internet.

But printer needs to use more pixels per inch to produce a high-quality image than our monitor does. If print a photo at 100ppi, it is not going to look like a professional print. You will be able to see grain and fuzziness, the actual pixels that make up the digital photograph. If we print at 250ppi, it increase the pixels per inch, so it reduce the size of the printed photo. Let's say you print 3.9 megapixel photo at 100ppi. This isn't high-quality, but you can print a photo that measures 22.7 by 17 inches (2272 / 100 = 22.7 and 1704 / 100 = 17).

Now you print the same photo at 250ppi. You get a great looking photo, but the print size is 9.1 by 6.8 inches (2272 / 250 = 9.1 and 1704 / 250 = 6.8).


Hope you enjoyed little bit maths that we did above but hold on ... Now screens are changed ..





iOS devices measure density in PPI (pixels per inch) and Android in DPI (dots per inch). The more pixels or dots you fit in one square inch on a screen, the higher the density and resolution of it.
The original iPhones and iPads had a screen density that was classified as non-retina. The current generation of iOS devices sport higher density displays referred to as retina. Android devices have evolved from low density, ldpi, all the way to extra high density, xhdpi.

There are five widely used densities across iOS and Android devices, which fall into four progressively larger groups:

  1. non-retina (iOS) and mdpi (Android)
  2. hdpi (Android)
  3. retina (iOS)
  4. xhdpi (Android)





Scaling the UI elements of your design and understanding how an asset at one density would scale to another can be confusing at times.

According to the official Android “Supporting Multiple Screens” documentation:

  • xhdpi = 320dpi
  • hdpi = 240dpi
  • mdpi = 160dpi
  • ldpi = 120dpi
  • Retina iPhones = 326dpi (roughly equivalent to xhdpi)
  • Retina iPads = 264dpi (roughly equivalent to hdpi)

See more details here. http://developer.android.com/guide/practices/screens_support.html

So we have seen here some basic ABC about images pixels, ppi and dpi. So image can be render with diff resolutions in diff screen density. 

Will back with more details about responsive image rendering with all possible options. Till then enjoy reading and happy learning !!!