 The icons size, size also will vary, so less frequent callers will come here, smaller icons, most frequent callers will come here and even the number of calls will be shown here, so very complex control and when you press 7 more, this control will expand and will show each call as a single row, this is a very complex control, that's where I said when you say will not draw is set, when you press 7 more it will not expand actually because this will take care of the drawing, it will not draw, so that's example of that. Now optimizing the Android application, so what we do is we, most of the time we have a set of few phones that we test on, probably emulated our things and we test this in the few devices, for example there are like when we launch one of the apps, there were 768 compatible devices in the market, so we are not going to test for 768 devices anyways, that's not going to happen for a startup, but what we can do is we can adhere to the guidelines and make sure that our app works on this, we can assume that and it works most of the time, so what happens is we have a decent mobile maybe like Nexus 1 or HTC or Google Galaxy S2 or something and we test on that and it works fine, but the problem with Android phones is that there are many people who use phones with very small footprint, very small memory capability and things like that and your code might fail, there are a lot of combinations that come in like QVGA with 2.1, to you know, HVGA with 2.3, to lot of combinations, there are a lot of combinations happening, so unless you optimize your code based on the guidelines, it might crash on few of the devices, so I will tell you some of the guidelines that we follow and we found out which will help reduce this, first things is I will come to that, okay, so that's what I said, so it scales up and down based on the devices and best practices are used and let us make the best use of memory and battery processing, so I will come to the memory part, what we do is whenever we have a list view, I am still stuck with list view, so when we have a list view and it has a lot of images, as you flick it, if there are 100 more animals, something crashes and gives you an out of memory exception, so this happens when you have images, because images take a lot of memory and when you don't probably handle it, it easily crashes, you know, even if it's a good device like Galaxy S2, if you have 100 plus images in the list and you just flick it, it will crash, if not in the first time, you just, you know, take the layout, make it landscape, portrait, landscape, portrait, four times, it will crash, because the memory leak is happening there, so what we do for that is the common myth is everybody does this step, system.run finalization is called the garbage collector and you believe everything is fine, all the garbage is collected, but the problem is the definition of garbage is very, very different from what we perceive, it's not that if we can say that, okay, this is not more in any more use, so this should be a garbage that the system doesn't understand like that, so there are a set of tools in, you know, Android ADT, developer tools, which can actually help you find out if there's a memory leak, if you're using a memory efficiently, so one of them is just look at the lock app, I think everybody is familiar lock app, yeah, so what you can do is you might see these kind of things, I'm sure you have seen this and you have just ignored it, like I also did, so what this says is, exactly says that the current state of your, you know, memory usage of your application, this says that this is the soft limit for your, this is the soft limit for your internal memory, that's the program memory that for the memory allocation of the objects and things like that, the next one, the second one, external says the memory allocated for the resources, like the images and things like that, so once your memory allocation touches 8.5, like 8K, it again upscales it to maybe 10K, the soft limit is set again to 10K, when it touches 10K, it goes like that, but there's a point, like yesterday, I think if you have, you were there in the session by, for the memory operation, they'll say there's a limit for the memory for each application, I think at 16 MB or something, so when this combined value goes out of 16 memory, you are done, the app crashes, so how, you can just watch for this, just put a lock at filter and just flip your phone up and down, like landscape, portrait, portrait landscape, you do it five times and you'll see this, this will be growing, this thing will grow, that means there's a leak, there's a leak in your program, so first you understand what are these parameters, these are defined in the android developer documentation, you can go and see that, I think explicit means, as I told you, the memory allocated for the external thing, for malloc means, because there's no more memory left, when the malloc was called, the OS is forced to call a GC, and GC concurrent means that a lot of objects already ready for garbage collection, so it takes some time, so if you're in between the list scrolling, if you're calling GC, it will scroll smoothly for some time, suddenly it will stop for a few seconds, maybe a second, but it will be visible because you're smoothly scrolling the list, you're flipping the list, suddenly it stops and then moves again, so that will be irritation for your UI, so you can also use a tool called memory analyzer tool, that's also part of the android ADT, and very good session is given about MAT in the Google IO session, I think that's the best way to understand that is watching that session, that's a one-hour session, he clearly shows how memory leak starts in an application, and where, how to peg it, things like that, it's a very detailed session, and next I'll come to another important topic, wherein how you can peg this GC, the GC problem is, I'll come to hard reference and software reference, I'll show you how exactly GC works and things like that, and another important point is that images are the most common memory hoggers in our applications, so even if you're using one single image, like I told you, if you're supported both orientations, like landscape and portrait, when you flip around, the images footprint might be growing, so try to minimize the size of the image, it's good in both case of runtime and also in packaging your app, most of the phones even today has a very limited internal memory, so your phone doesn't support SD card, moving to SD card, and if your phone is running 2.1, there's no option also, so for applications 10MB, nobody's gonna download it, they'll say that it's too big for my phone, so try to minimize, in that aspect also try to minimize the memory used by an image, or even otherwise when the runtime also it's gonna cause a problem for you, so like I think last session there, in the top, they were talking about how to use nine patch images, so use nine patch images wherever possible, so that will really, really bring down the image size, for example, a button icon, a button background image which was like 30KB will come down to like 2KB with nine patch, if it is nine patchable, first thing, and also there's no transparency, go with JPEGs instead of PNGs, see even if you, one more interesting fact is that, we have tried to optimize the PNGs from Photoshop or the tools to reduce the memory of the PNG, so that by probably reducing the resolution and things like that, but what Android does is, before compiling and making the package, it actually reformats the PNG, it compresses by itself, so whatever compressing you have done, beforehand for the PNG, is going down the drain, because Android again will do that, and it'll only be as good as the compression used by Android, so PNGs have that problem, so stick with JPEGs if you don't have transparency, and only when you need transparency use PNG, so I'll come back to, you know the weak references and strong references or soft, you can call it weak references versus strong references, or you can say soft versus hard, so what are strong references? I have a class called foobar, I'm initializing an object with that, now what is happening? I'm putting it in the hash map, now this function goes out of say use, so the actual foobar is supposed to be gone for memory garbage collection, but since the object is still in the hash map, it is referenced hard way, there's a hard reference to the object in the hash map, this object is not gonna die, until the hash map also is dying, so what happens is even if the foobar is not in use, it's still in the memory, it will not be available for garbage collection, this is a very simple example, then you are assigning an object to multiple variables, what happens is there are a lot of strong references to this object, so even though the original object has gone off the scope, the object is still referenced by somewhere, though not in use, they are like a dormant, and they'll remain in the memory, unless it goes out of memory and crashes, this is a strong reference scenario, so these strong references are not at all eligible for garbage collection, it'll never be collected by garbage collector, so what we can do for this is, we can, there's a class called a B reference, and use the B reference, you know, class, and then if you assign that to the foobar, using the B reference, what it will do is, the code, the B reference is not direct, the weaker references will be the one object that will actually hold the reference for the object, and for each places, you can actually say, weakfood.get, and it will return you the object, so what it is returning is a weak reference of the object, so if I'm putting the hash map into the list, I'll be putting here, I should have put the code also, like weakfood.get I'll have put, so it is not actually, there's no hard reference to the actual object, the actual object is held only by the weak reference class, so when this actual weak reference class goes out of scope, it's available for garbage collection, so there are actually different kinds of weak references, one is weak reference, as I told you, and the soft references, the difference between weak reference and soft reference is very subtle, soft reference will, weak reference is what it'll do is, whenever the object is going out of scope, it'll automatically make it available for garbage collection, but soft reference what it'll do is, it'll return it for some more time, so that if the memory's allowing you to do that, there are a lot of memory available for you, it'll still hold that object, not kill that object, so the hash map will still be able to access the object, even though the original object is going out of scope, if at all, there's a memory available, so soft reference is a little bit more, what to say, a lenient on releasing the actual object, and there's another phantom reference, this is a really different thing, which is only used, okay, I'll get into that, whenever you actually, whenever you actually put an object in the weak reference, and when it's the reference, that is when the object goes out of scope, it's put into a reference queue, so the reference queue will hold all the dead objects, and next garbage collection cycle it'll be killed, so in both weak references and soft reference, you can actually go to the reference queue, and retrieve the dead object, you can resurrect that object, so in phantom reference, even that is not allowed, phantom reference makes sure that, when it's gone out of scope, it's completely gone, that is about the, okay, the gist of what that is, try to use a weak reference class or a soft reference class, whichever you feel is good for you, and this is not used actually anywhere, I have not seen any case where it's used, and if you use a weak reference, the garbage collector will be much, much more capable to release the object I have not used. Next is optimizing the layouts, I talked about the optimizing memory using these techniques, now I'll talk about optimizing layouts, okay, so I'll go through using two tools that ADT provides, one is hierarchy viewer, hierarchy viewer as it says, it is a tool that is available with the Android SDK, that will actually show the hierarchy of your view, like they showed in the first slide, it'll show a little bit more graphically, the actual hierarchy from left to right, from the linear layout, you have a probably a ready layer, instead of your list, list items, things like that, and it'll show the whole hierarchy, and this is one example, in the hierarchy, this is one object, say in the end we have a button, and it'll show you three dots in that, these dots represent the time taken by that object to get drawn, first thing is, I guess, time taken to measure, second is time taken to the layout, third is time taken to execute a draw call, and this color coding will tell you whether it's healthy or not, if it is green, it means that it has taken a time less than 50% of the, it is faster than 50% of other objects in that same layout, if it is yellow, it is slower than 50% of the other layout, and if it is red, it means it's the slowest object, so when you actually run an application on the device, you can plug it in and you can see the view hierarchy run time, in the real time, and you can see which object is misbehaving, which object is taking the most time to draw, this is also useful when you're designing your own custom controls, so you can make sure that, whether your control is the, your control is behaving properly, or is it taking longer time to draw, measure, or even putting the layout, so using this tool, you can actually pick the rendering speed, you can find out which is the problem creator, and the problem is it works only on developer devices, but I think that's good enough, and it shows the entire view hierarchy of the activity to take and the time taken for each view to draw, so as I told you the color coding also, another tool is layout opt, layout opt is another command line tool provided with the Android SDK, when you know first you run view hierarchy and find that, say this object is a problem creator, the dot is there in this object, so what will you do next? How will you know that, why is this object slow? So what you can do is, the first step you can do is you can take layout opt, you can run this layout, an XML layout through the layout top, it'll tell you the most probable reasons, the most probable guidelines you have missed, probably you have put an invalid object, you have used an object that is never drawn, things like that, the errors of the logical errors in the XML layout file will be picked up by the layout of cloud, a code, and it'll also suggest the remedies if it is possible, most of them it gives a good suggestion, so with these two tools you can actually pick the layout drawing issues from the XML's perspective, the next thing is very important thing, we do great apps, apps look really good, the UI is great, it works great, the only problem is it drains your back into us, your phone dies into us, and that's a common that you see in most of the good apps in the Android market, and this happened to us also, we did a very good app but the problem is it drains the battery a lot, what is the reason? So even if you have a very powerful phone, say you have a very good phone with a dual code processor, a lot of memory, the battery is always a bottleneck, you know the battery is gonna drain, if it becomes dual code it's gonna drain really faster, so what to do about that? So there are set of optimizing techniques that you can use, these are, even if it's not about battery it's a very good practice to follow on how to use a battery and network judiciously, you know, when you write apps, I am talking about apps which are connected to a network which fetches information from the internet or probably uses location, GPS to find out where you are, these kind of apps use a lot of sensors, and you can actually do a check before you actually use a network, for example, if you're in a roaming state or if there's no Wi-Fi network, if there's no internet, there's no point of you calling the HTML, you know, HTTP request to the server, it is anyway gonna fail, but you're actually going to drain the processing and battery time. So before calling network or GPS or things like that, first put a check on the function, see if there is a network available, see if GPS is turned on, these simple checks will actually, you know, along with your apps, a time in the phone at the time, your battery time will really go higher, and another simple, but some thing that most people don't follow is using wake locks. If you don't know what wake lock is, when you are using an app, say you're watching a video, a screen locks after five seconds. In beginners app this happens, but when you Google search, you know, you find what the reason is. Reason is that you have not set a wake lock. If you watch a video in the YouTube app, it'll never lock the screen, it'll never die. That's because they have acquired a wake lock. Wake lock is something, see the Android architecture is like this. When you are doing something, when the phone is idle for some time, there's a time out that is set in the settings that you can manually change. After the time out, the system will lock. The screen will lock, the screen will die, the touchpad, the keyboard, if it is there, the backlighting will go, and actually the processor goes to suspend mode, except for some essential services like phone calls and your network, all the system is in a suspend mode. So, if your apps need to run on the background, there are pretty different scenarios. Take an example of a YouTube app. YouTube app, what it needs to do is, when the screen is live and the YouTube app is running, you just need to make sure the screen doesn't lock. But when the user manually locks the screen, you don't, the YouTube app doesn't need to run anymore. It can still put the processor to suspend mode, that's one scenario. And this scenario is an example of an app like Twitter. Twitter app doesn't need the screen, even the screen can lock, but even after locking, probably the app will pull the internet to find if there are new tweets. So, at that time, you can let the system lock the screen, but you cannot actually send the processor to the suspend mode. So, in that scenario, you need the processor to be running and giving Twitter app some control, some kind of control so that it can again pull and get the value from the internet. So, there are different kinds of wake locks provided by Android for each of the scenarios. A full wake lock will actually never lock the screen, never kill the processor. It'll always keep the processor alive and it'll actually keep the screen backlighting everything alive. On after release is another wake lock, which probably will, I guess will, you know, when you press manually, you lock the screen, it'll stop everything. And partial wake lock is what I was talking about Twitter. It'll lock the screen, but the processor will be running in the background. Screen bright wake lock means it will remain, the screen will remain brighter as well. Sometimes you can dim the screen at least. So, the dim wake lock will keep the screen alive, but it'll dim after some time. So, these kind of different wake locks are available. Again, it's available, the complete specification of this available in the market. So, people, what they do is, they actually acquire the wake lock and set the wake lock. So, for example, if you take the Android phone and go to settings and go to the system information, go to the battery usage, usually the 50% of the battery is used by display. So, when you actually keep the screen awake, you're actually killing the battery like anything. So, this full wake lock will be acquired. Say, somebody is watching a YouTube video and he acquires a full wake lock. After the video is finished, probably you should release the wake lock. Most of the applications, they don't release the wake lock. And what happens is the screen will remain open, even when you press the home button and the app goes back in the dominant state till the wake lock is acquired. So, it will remain on all the time, probably for hours, and the battery will probably die in half the time it should have actually died. So, whenever you acquire a wake lock, try to release it after it's used. Another thing is services. My services is like something, the most toughest thing to do. And when you do a service, you get like, yeah, I'm going to the next level. So, you use service for everything. But, and we also found for many scenarios for like, pulling the location, the background, and things like that. We thought service is the best way to go. But actually, there are methods which you can actually eliminate services. For example, if you wanna pull the location, if you wanna pull system states and all, we have actually system broadcasts. When the location information available, if you subscribe for the system broadcast in the XML file, you can actually get the broadcast even when your app is not running. So, you wanna show a pop-up whenever you enter a region. So, the simple solution would be run a service in the background, pull for location every 10 minutes. When you are in this GPS location, just put a pop-up. That's a simple implementation. The better implementation is, just subscribe to the location, the change broadcast intent in the XML file. And whenever the location is changed, you will get the intent back to your application. In this way, you are actually saving the memory also and you're actually removing your background application. So, another thing is, you have the ways to set services not to be persistent. If you go to the system settings and kill a service, it will resurrect again. That is because in the settings in Android Manifest, they have said that even a service is killed, please restart the service. So, if your service needn't be restarted, if it's not something critical, if it's something like, it's a simple fun app, something, if someone is killing the service, let it die. And the next time when you start an app, let the service come again. So, don't make the service persistent if you're not needed. And best part is, this is the most important thing, abide by the rules. Just blindly, religiously follow the rules and they actually make your app lot, lot better. And it will be future proof as well because the form factors of the device are changing and the capabilities of the device are changing. So, if you stick to the guidelines, your app, which is created for 1.6, will still run on a device on ice cream sandwich without much change needed, you know? Again, another important thing is you can adapt your app to your system condition. For example, when you're using network, you get this, some broadcast in the system, denoting about the system condition. This is what I told you earlier, like when the network is turned off, you don't have to pull. And another important thing is, there's an event, there's a system broadcast event called action battery change that system throws. This is a broadcast event, anybody can subscribe to that. So, when the action battery is low, the actual value, the battery is low, you can actually turn off part of the system. For example, your GPS thing, your network thing, you can actually reduce your application usage of the GPS network, but in low battery, your application is not the one who actually kills the system. Because the users, the way they perceive it, you're on low battery and they take your app and your system stays power off. They're not very intelligent or they're not very, they're just lame and who will think that your app is the one who actually accelerated the shutdown of the system. So try to be a good guy and whenever the system condition is low, reduce everything, go to safer mode, and you can, using these kind of system broadcast, you can actually disable some of the facilities or capabilities of the application. Also, you have specified some of the permissions in the applications XML file. Say, you have to stay for the location, you have to stay for the network, things like that. You can actually go to the package manager class and during runtime, you can disable these permissions. So that is also possible. So they give all kind of facilities for you to make your app as memory optimized as possible and it's up to you to actually implement that. Another thing is optimize the list, optimizing the list, because we are talking about lists. Another problem I've seen is the list, when you create a list that you don't really bother about optimizing, you're more concerned about making it work properly, but you can actually optimize the list. For example, whenever you are downloading images from the list, you might use a thread to do that so that you lazily load the image. But using a thread, make sure, for example, you're flicking a list in a very fast, you're doing a fast flick of the list. You don't have to load images for each of the list items. What happens is I have, I'll take an example to Twitter again, I flick the list very fast. So probably I would have skipped 100 items in a second, but I would have started 100 threads also to load 100 icons. Why do you need that? Because I'm not gonna see that icons. So what you can do is you can listen to the scrolling, scroll listener, and then only when the list stops, just load those items. Don't load the images and stuff for each of the list item that has been scrolling. So if I scroll 100 items in a second, I'm not gonna load 100 threads and crack the system. And again, using the threads, be very careful. There are a lot of documentation about this on the internet, how to optimize threads on a list. Because once you start a thread, you don't really have much of a control how to stop it or how, where it goes, it just runs in the background. So you start 20, 30 threads, because they have dynamic number of items. So you scroll down and up, you're starting threads here and there. So if you scroll down and up, you're actually starting through two threads for the same image. Because they don't have happened, just think about it and you will find that you can actually optimize these kind of scenarios. And as I told you earlier, the Android list control is a very intelligent control. It will only load that much items, it will only call that much views, it will only create that much views, it will cache the views, it'll do a lot of things. And if you want to know more about that, just go to the Android source code of the list view. It's very beautifully written. And don't try to over optimize it or counter optimize it. And then in the closing, I just want to say that the Dalvik machine and the Java machine are not the same. The heat size and all those things are different. So don't, even if you're a seasoned Java programmer, you might be committing mistakes. Try to watch the Google videos. They're very, very important because they actually throw up a lot of new light to the way you actually look into an Android program. And don't just try to check out the densities of the application when you create an XML, as he told in the previous session. And you can also check the Android source code. People think that Android source code is really hard to understand. It's a big, big, big goal and it's a rocket sign. It's very simple. Anybody can understand, it's heavily documented. And whenever I try to create a custom control, I actually go to the Android source code and see how they have done a similar control and I start from there. It's very simple. And you can use portal like stack out from Google. I know all of you know that. And one more important thing is, try, if when you're in doubt, you can actually call up these guys. You can actually ping these guys in Twitter or in Google Plus. If you have really have some problem, like my list is not working properly, this is what happens to me. You can contact Ritome, Romain, go there and Romain, they actually respond to your queries. We are really issues and they'll give you answers. So that's what I will say. And I would like to thank my colleagues who tried to help me create this presentation. If you have any questions, you can ask me. Hello, everyone. Due to time constraints, we'll have to end this session here. We'll thank Mr. Narayan for the quiet interactive session. Please give me a big round of applause.