1 00:00:00,000 --> 00:00:04,710 [MUSIC] 2 00:00:04,710 --> 00:00:09,594 We've learned all about threads and services and we've already seen the word 3 00:00:09,594 --> 00:00:14,480 process a few times, but we still don't know much about processes. 4 00:00:14,480 --> 00:00:18,097 Let's fix that by taking a closer look at process in Android. 5 00:00:20,080 --> 00:00:22,348 Let's start in the Android device monitor. 6 00:00:26,076 --> 00:00:30,091 Everything over here on the left is a process, and 7 00:00:30,091 --> 00:00:35,159 if we click to show the threads, say for our music machine app, 8 00:00:35,159 --> 00:00:40,340 we can see the threads associated with this process. 9 00:00:40,340 --> 00:00:45,020 So a good way to think about processes would be as a group of threads. 10 00:00:45,020 --> 00:00:49,670 We already know that by default everything in an app runs on one thread, 11 00:00:49,670 --> 00:00:51,420 the main thread. 12 00:00:51,420 --> 00:00:58,030 Now let's add to that that by default, each app also runs in its own process. 13 00:00:58,030 --> 00:01:03,300 So when we launch an app, all of the code execution will happen on the main thread 14 00:01:03,300 --> 00:01:05,840 and this thread will be a part of our apps process. 15 00:01:06,860 --> 00:01:12,010 When we create new threads, they're also a part of our apps process. 16 00:01:12,010 --> 00:01:16,190 Remember when we were trying to download using just a thread and no service? 17 00:01:17,190 --> 00:01:21,140 When we killed our apps process, the download stopped. 18 00:01:21,140 --> 00:01:25,034 This is because the new thread we created was part of our app's process. 19 00:01:25,034 --> 00:01:29,001 So when we killed the process, we killed the thread. 20 00:01:29,001 --> 00:01:34,080 However, we are not limited to one process. 21 00:01:34,080 --> 00:01:36,600 There are a few occasions where it might make sense for 22 00:01:36,600 --> 00:01:39,210 an app to run in more than one process. 23 00:01:39,210 --> 00:01:43,120 A good example of this is, not surprisingly, a music player. 24 00:01:44,155 --> 00:01:48,700 In Android, each process is only allowed to use a certain amount of memory 25 00:01:48,700 --> 00:01:51,940 based on the total amount of RAM on the device. 26 00:01:51,940 --> 00:01:55,650 Using one process for our activity and a separate process for 27 00:01:55,650 --> 00:01:58,990 our service gives both access to more memory. 28 00:02:00,460 --> 00:02:04,060 But more than that, having two separate processes lets 29 00:02:04,060 --> 00:02:08,030 Android reclaim the activities process when it's no longer needed. 30 00:02:09,120 --> 00:02:11,900 If we've been listening to music in the background and 31 00:02:11,900 --> 00:02:14,690 haven't interacted with the activity in a while, 32 00:02:14,690 --> 00:02:18,060 then Android will be able to kill just the activities process. 33 00:02:19,330 --> 00:02:20,080 This way, 34 00:02:20,080 --> 00:02:24,198 we can free up system resources while making sure that our music keeps playing. 35 00:02:24,198 --> 00:02:25,922 Cool, right? 36 00:02:25,922 --> 00:02:31,894 [SOUND] Another important thing about processes is how they get killed. 37 00:02:31,894 --> 00:02:35,044 We already know that when Android needs to reclaim memory, 38 00:02:35,044 --> 00:02:37,670 it will start killing processes. 39 00:02:37,670 --> 00:02:40,380 But how does Android pick which processes to kill? 40 00:02:41,760 --> 00:02:46,300 Well luckily, Android has a method to determine which processes to kill 41 00:02:46,300 --> 00:02:48,190 first and which to kill last. 42 00:02:49,260 --> 00:02:53,420 It does this by grouping processes into five groups of varying importance. 43 00:02:54,610 --> 00:02:57,700 The first group is foreground processes. 44 00:02:57,700 --> 00:03:02,480 These are the most important processes and will be the last to be killed. 45 00:03:02,480 --> 00:03:07,960 More specifically these are processes that a user is currently interacting with. 46 00:03:07,960 --> 00:03:11,160 When we're clicking buttons in our music machine app, 47 00:03:11,160 --> 00:03:13,830 our apps process would be considered a foreground process. 48 00:03:15,720 --> 00:03:18,640 The second group is visible processes. 49 00:03:18,640 --> 00:03:22,060 These are processes that don't have any foreground components, but 50 00:03:22,060 --> 00:03:24,270 can still affect what the user sees on the screen. 51 00:03:25,520 --> 00:03:29,860 An activity in the pause state would likely be running in a visible process. 52 00:03:31,500 --> 00:03:33,610 The third group is service processes. 53 00:03:33,610 --> 00:03:37,219 This is for processes which are running started services. 54 00:03:38,260 --> 00:03:42,790 The importance level of a process running a bound service, on the other hand, 55 00:03:42,790 --> 00:03:46,090 is determined by the importance level of what the service is bound to. 56 00:03:47,480 --> 00:03:50,350 The fourth group is background processes. 57 00:03:50,350 --> 00:03:52,360 If our activity isn't visible, 58 00:03:52,360 --> 00:03:55,469 then our apps process is likely a background process. 59 00:03:56,980 --> 00:04:00,960 The fifth, and least important group, is empty processes. 60 00:04:00,960 --> 00:04:04,570 An empty process is what's left after all of our app's components 61 00:04:04,570 --> 00:04:06,310 have been destroyed. 62 00:04:06,310 --> 00:04:10,650 The only reason to keep an empty process around is for caching. 63 00:04:10,650 --> 00:04:14,290 When Android needs more memory, these processes will be the first to go. 64 00:04:16,430 --> 00:04:19,960 Hopefully that clears up some of the mystery surrounding processes and gives 65 00:04:19,960 --> 00:04:24,260 you a good idea about how Android decides which processes can be safely killed. 66 00:04:25,290 --> 00:04:29,310 In the next video, we'll see how to use two separate processes for 67 00:04:29,310 --> 00:04:30,030 our music machine.