1 00:00:04,850 --> 00:00:07,190 Now in the previous video, we improved the 2 00:00:07,190 --> 00:00:09,080 appearance of our app by creating a 3 00:00:09,080 --> 00:00:10,820 custom adapter, and you can see the new 4 00:00:10,820 --> 00:00:14,090 display of the app now. Now this lets us 5 00:00:14,090 --> 00:00:15,799 use our own layout, so that we can 6 00:00:15,799 --> 00:00:17,030 display different widgets in the 7 00:00:17,030 --> 00:00:17,750 ListView, 8 00:00:17,750 --> 00:00:19,580 rather than having to display all the 9 00:00:19,580 --> 00:00:22,130 data in the single TextView widget that 10 00:00:22,130 --> 00:00:24,560 the basic ArrayAdapter allows. Now this 11 00:00:24,560 --> 00:00:26,509 gives us far more control over what 12 00:00:26,509 --> 00:00:28,789 appears in each line in the ListView, and 13 00:00:28,789 --> 00:00:31,039 obviously, that culminated in the display 14 00:00:31,039 --> 00:00:32,299 that you can see on the screen there now. 15 00:00:32,299 --> 00:00:35,090 But the actual code for our adapter 16 00:00:35,090 --> 00:00:37,550 isn't very efficient, though. So we come 17 00:00:37,550 --> 00:00:39,200 back and have a look, or go back to the 18 00:00:39,200 --> 00:00:41,120 code - FeedAdapter - and have a look at 19 00:00:41,120 --> 00:00:44,149 this getView function. It inflates a new 20 00:00:44,149 --> 00:00:46,940 view every time it's called, and that's 21 00:00:46,940 --> 00:00:50,000 this code here on line 29. Now that means 22 00:00:50,000 --> 00:00:52,789 that if we used it to display a thousand 23 00:00:52,789 --> 00:00:55,250 items, it would create one thousand views - 24 00:00:55,250 --> 00:00:58,039 which is costly in terms of both time 25 00:00:58,039 --> 00:01:02,019 and memory. Also, the findViewById 26 00:01:02,019 --> 00:01:04,519 function is very slow because it has to 27 00:01:04,519 --> 00:01:06,980 scan the layout from the start, each time 28 00:01:06,980 --> 00:01:08,840 it's called, checking to see if each 29 00:01:08,840 --> 00:01:11,360 widget is the one we want. And it gets 30 00:01:11,360 --> 00:01:13,040 worse than that. If you start scrolling 31 00:01:13,040 --> 00:01:15,350 up and down those thousand items, it'll 32 00:01:15,350 --> 00:01:17,299 create a new view every time a new one 33 00:01:17,299 --> 00:01:19,970 comes onto the screen. Now I can 34 00:01:19,970 --> 00:01:21,290 demonstrate that, but I should mention 35 00:01:21,290 --> 00:01:24,020 that what I'm about to do may not work 36 00:01:24,020 --> 00:01:26,000 when you come to watch this video, and 37 00:01:26,000 --> 00:01:27,560 that's because I'm going to abuse the 38 00:01:27,560 --> 00:01:30,290 Apple feed. Now Apple provide a Top 10 39 00:01:30,290 --> 00:01:33,290 and a Top 25 version of each feed, but we 40 00:01:33,290 --> 00:01:35,750 can request the top 200 - at least, I can 41 00:01:35,750 --> 00:01:37,399 at the moment. There's no guarantee that 42 00:01:37,399 --> 00:01:39,049 this will continue to work in the future. 43 00:01:39,049 --> 00:01:41,990 But even if it doesn't, you'll see the basic 44 00:01:41,990 --> 00:01:44,060 principle with just a Top 25 - it just 45 00:01:44,060 --> 00:01:46,310 won't be quite as dramatic. So we're 46 00:01:46,310 --> 00:01:48,740 going to start, and make sure you cleared 47 00:01:48,740 --> 00:01:50,810 your logcat. So in my case, I haven't got 48 00:01:50,810 --> 00:01:52,490 it on but I'll click it there, and 49 00:01:52,490 --> 00:01:54,020 I'm just gonna clear that, even though 50 00:01:54,020 --> 00:01:55,729 it does usually get cleared each time we 51 00:01:55,729 --> 00:01:58,250 start the app. And what we're going to do 52 00:01:58,250 --> 00:01:59,960 is, we're going to stop running the app 53 00:01:59,960 --> 00:02:01,219 on the device - I'm just going to click on 54 00:02:01,219 --> 00:02:04,369 Stop. And by the way, you can use the menu 55 00:02:04,369 --> 00:02:07,520 to stop as well, down here, but normally I 56 00:02:07,520 --> 00:02:08,720 just click on this, as you can see me 57 00:02:08,720 --> 00:02:10,100 doing, clicking on the stop button under 58 00:02:10,100 --> 00:02:12,770 the toolbar. Now what I'm going to do is 59 00:02:12,770 --> 00:02:14,750 edit the URL and MainActivity to show 60 00:02:14,750 --> 00:02:17,660 the top 200 entries, and we can do that by 61 00:02:17,660 --> 00:02:18,500 changing this limit. 62 00:02:18,500 --> 00:02:20,780 At the moment, it's set to 25. Let's 63 00:02:20,780 --> 00:02:24,620 change that to 200, and as I said, if you 64 00:02:24,620 --> 00:02:26,030 get an error when you come to try this, 65 00:02:26,030 --> 00:02:28,640 change the limit back to 25. The 66 00:02:28,640 --> 00:02:30,080 demonstration will still work - it just 67 00:02:30,080 --> 00:02:32,030 won't be quite as dramatic. Alright, the 68 00:02:32,030 --> 00:02:33,350 other thing I'm going to do is make 69 00:02:33,350 --> 00:02:35,600 another quick change to the adapter. Now 70 00:02:35,600 --> 00:02:37,490 this isn't necessary, but it's gonna take 71 00:02:37,490 --> 00:02:38,780 me a long time to scroll through the 72 00:02:38,780 --> 00:02:41,060 list if I leave the summary in, because 73 00:02:41,060 --> 00:02:43,160 it occupies a lot of the screen. So what 74 00:02:43,160 --> 00:02:44,780 we're going to do is comment out the 75 00:02:44,780 --> 00:02:47,240 code, or the line rather, that puts the 76 00:02:47,240 --> 00:02:48,770 summary text into the text view. So 77 00:02:48,770 --> 00:02:51,410 that's this one here; tvSummary.text 78 00:02:51,410 --> 00:02:54,920 equals currentApp.summary - I'm gonna 79 00:02:54,920 --> 00:02:57,020 comment that out. So let's go ahead and 80 00:02:57,020 --> 00:02:59,989 run the app, and them I'm gonna come over here 81 00:02:59,989 --> 00:03:01,790 to the a Android Profiler tab at the 82 00:03:01,790 --> 00:03:03,410 bottom of the screen. And there's also a 83 00:03:03,410 --> 00:03:04,640 button on the toolbar towards the 84 00:03:04,640 --> 00:03:05,900 right-hand side, as well, if you want to 85 00:03:05,900 --> 00:03:08,270 do it that way. And I'm just going to put that 86 00:03:08,270 --> 00:03:11,170 emulator on the screen. 87 00:03:11,170 --> 00:03:13,250 Now this is very important if you're 88 00:03:13,250 --> 00:03:15,439 running on Windows. You may see a Windows 89 00:03:15,439 --> 00:03:17,750 Security Alert dialogue popping up when 90 00:03:17,750 --> 00:03:20,269 you first launch the Profiler. If you do, 91 00:03:20,269 --> 00:03:21,920 make sure you tick the box that allows 92 00:03:21,920 --> 00:03:24,950 access on private networks. Whether you 93 00:03:24,950 --> 00:03:26,599 untick the other box to allow access 94 00:03:26,599 --> 00:03:28,790 on public networks, is down to your 95 00:03:28,790 --> 00:03:30,379 attitude to security. I strongly advise 96 00:03:30,379 --> 00:03:32,659 you to untick it. What's important, 97 00:03:32,659 --> 00:03:34,549 because things won't work otherwise, is 98 00:03:34,549 --> 00:03:36,560 to definitely tick the Private networks 99 00:03:36,560 --> 00:03:38,959 box. Once you've ticked the box, click the 100 00:03:38,959 --> 00:03:40,730 Allow access button - so that's for 101 00:03:40,730 --> 00:03:44,000 Windows. Now this Profiler let's you 102 00:03:44,000 --> 00:03:45,859 investigate things like memory usage on 103 00:03:45,859 --> 00:03:47,810 your device or emulator, so let's 104 00:03:47,810 --> 00:03:48,919 actually take a look at the 105 00:03:48,919 --> 00:03:50,670 memory usage. 106 00:03:50,670 --> 00:03:53,280 Now the profiler's showing a real-time 107 00:03:53,280 --> 00:03:56,250 view of the CPU usage, Memory and Network 108 00:03:56,250 --> 00:03:57,420 on the device. 109 00:03:57,420 --> 00:03:59,459 Now we're only interested in the memory 110 00:03:59,459 --> 00:04:01,110 at the moment, but it's worth playing 111 00:04:01,110 --> 00:04:02,910 with this Profiler and checking out how 112 00:04:02,910 --> 00:04:05,310 your finished apps behave. If you get 113 00:04:05,310 --> 00:04:08,550 excessive CPU or Network accesses, or the 114 00:04:08,550 --> 00:04:10,770 memory starts getting eaten up when your 115 00:04:10,770 --> 00:04:11,970 app's running, then you should really 116 00:04:11,970 --> 00:04:14,550 investigate the cause. Now you can 117 00:04:14,550 --> 00:04:16,019 drill down into each of these by just 118 00:04:16,019 --> 00:04:20,370 clicking on them. If we move the mouse 119 00:04:20,370 --> 00:04:24,000 down to memory, and click, you can see 120 00:04:24,000 --> 00:04:25,470 that we've got a more detailed version 121 00:04:25,470 --> 00:04:28,500 of memory usage. I'm just going to make 122 00:04:28,500 --> 00:04:29,880 the profile a little bit larger on the 123 00:04:29,880 --> 00:04:33,360 screen, so we can see what's going on. Now 124 00:04:33,360 --> 00:04:34,770 usage is fairly level at the moment, and 125 00:04:34,770 --> 00:04:36,260 that's because we're not doing anything. 126 00:04:36,260 --> 00:04:40,230 Now before we start, I suggest you click 127 00:04:40,230 --> 00:04:42,300 on the trash can icon in the Profilers 128 00:04:42,300 --> 00:04:48,690 tool bar, over here. That forces a garbage 129 00:04:48,690 --> 00:04:50,580 collection so that any unused memory can 130 00:04:50,580 --> 00:04:52,830 be reclaimed. That way, we really know 131 00:04:52,830 --> 00:04:54,330 that we're looking at changes that our 132 00:04:54,330 --> 00:04:58,169 app causes. I'm going to do that now. Now 133 00:04:58,169 --> 00:04:59,520 the graph shows a trash can in the 134 00:04:59,520 --> 00:05:03,169 timeline - you can see that over here now - 135 00:05:03,169 --> 00:05:05,850 and the memory dropped down a little bit as 136 00:05:05,850 --> 00:05:10,410 a result. So we'll just click it again, and 137 00:05:10,410 --> 00:05:11,490 you can see how the memory goes there 138 00:05:11,490 --> 00:05:16,260 when I do that. One more time - you can 139 00:05:16,260 --> 00:05:17,460 see that it's fairly stable now when 140 00:05:17,460 --> 00:05:19,110 I'm clicking it. So we've got a fairly 141 00:05:19,110 --> 00:05:20,880 stable amount of memory. Now in my 142 00:05:20,880 --> 00:05:22,979 particular case, 143 00:05:22,979 --> 00:05:24,539 I've got total memory usage at the 144 00:05:24,539 --> 00:05:26,310 moment, at the top there showing as 27 145 00:05:26,310 --> 00:05:29,129 megabytes. But obviously, the numbers will 146 00:05:29,129 --> 00:05:30,900 vary, depending on your operating system 147 00:05:30,900 --> 00:05:32,550 and what else is running, if, on your 148 00:05:32,550 --> 00:05:36,180 emulator etc. Now, when we clicked the trash 149 00:05:36,180 --> 00:05:38,249 can icon while testing on windows, we 150 00:05:38,249 --> 00:05:39,659 didn't get those little icons in the 151 00:05:39,659 --> 00:05:42,150 timeline, that you saw on my Mac. Garbage 152 00:05:42,150 --> 00:05:43,499 collection still kicked in though, so 153 00:05:43,499 --> 00:05:44,759 don't worry if you don't see little 154 00:05:44,759 --> 00:05:47,159 icons. Alright, so now that we've got that 155 00:05:47,159 --> 00:05:49,020 going, it's time to switch to the 156 00:05:49,020 --> 00:05:50,939 emulator and start scrolling. So I'm 157 00:05:50,939 --> 00:05:52,860 going to go back to the emulator, and I'm 158 00:05:52,860 --> 00:05:59,990 going to start scrolling now. 159 00:05:59,990 --> 00:06:02,660 And depending on how fast I scroll, I 160 00:06:02,660 --> 00:06:03,889 can get different values. We can see 161 00:06:03,889 --> 00:06:06,050 that I'm pretty easily getting up to 48 162 00:06:06,050 --> 00:06:07,759 47 48 megabytes. 163 00:06:07,759 --> 00:06:13,099 I'm scrolling back up again now - over 50 164 00:06:13,099 --> 00:06:15,710 now, as you can see. And that will depend 165 00:06:15,710 --> 00:06:18,530 on whether you're running on Windows, Mac 166 00:06:18,530 --> 00:06:21,590 or Linux, as a general rule, and also what 167 00:06:21,590 --> 00:06:22,400 else you've got running on the emulator. 168 00:06:22,400 --> 00:06:24,650 But you can see that, basically, the 169 00:06:24,650 --> 00:06:26,270 memory went up significantly, and what it 170 00:06:26,270 --> 00:06:29,900 was running, before doing it. So while I'm 171 00:06:29,900 --> 00:06:31,520 scrolling through this list, an automatic 172 00:06:31,520 --> 00:06:33,320 garbage collection is actually kicking 173 00:06:33,320 --> 00:06:35,210 in, and reducing the total memory 174 00:06:35,210 --> 00:06:37,639 allocation. But we're still getting quite 175 00:06:37,639 --> 00:06:39,110 high numbers - you can see there, like 176 00:06:39,110 --> 00:06:42,800 over 50 megabytes is in use - and also 177 00:06:42,800 --> 00:06:44,750 keep in mind that our views are really 178 00:06:44,750 --> 00:06:45,919 quite simple as well. We're not 179 00:06:45,919 --> 00:06:47,650 displaying graphics or anything fancy - 180 00:06:47,650 --> 00:06:50,270 literally, just three TextView widgets. 181 00:06:50,270 --> 00:06:52,909 Now garbage collection is also a costly 182 00:06:52,909 --> 00:06:55,940 exercise, so scrolling sometimes pauses 183 00:06:55,940 --> 00:06:57,830 while that's going on. To the user, the 184 00:06:57,830 --> 00:06:59,389 app seems to freeze for half a second - 185 00:06:59,389 --> 00:07:01,909 that can be a little bit annoying. And you 186 00:07:01,909 --> 00:07:03,530 can see, there's a little bit of a - it's not 187 00:07:03,530 --> 00:07:04,789 really that prominent on mine at the 188 00:07:04,789 --> 00:07:06,800 moment, but if I scroll - you can see there's a 189 00:07:06,800 --> 00:07:08,240 bit of jerkiness that actually happens 190 00:07:08,240 --> 00:07:11,840 there. And that's the garbage collection 191 00:07:11,840 --> 00:07:13,099 I clicked, kicking in - you can see the 192 00:07:13,099 --> 00:07:14,720 icon there that has appeared on the 193 00:07:14,720 --> 00:07:17,090 screen. 194 00:07:17,090 --> 00:07:19,550 There's a big pause there, and you can 195 00:07:19,550 --> 00:07:20,780 see the garbage collector icons 196 00:07:20,780 --> 00:07:23,770 appearing in the right-hand corner there. 197 00:07:23,770 --> 00:07:26,540 Alright, so the point is that it can be 198 00:07:26,540 --> 00:07:29,540 a very costly exercise, and you know, it's 199 00:07:29,540 --> 00:07:31,040 really important to be looking after the 200 00:07:31,040 --> 00:07:32,360 amount of memory that your app's actually 201 00:07:32,360 --> 00:07:35,030 using. So make a general note of whatever 202 00:07:35,030 --> 00:07:36,260 figures you've got, when you've done this 203 00:07:36,260 --> 00:07:39,230 first bit of testing. When we started 204 00:07:39,230 --> 00:07:40,340 using the app, I think it was round about 205 00:07:40,340 --> 00:07:43,160 26 or 27 megabytes and then rose, we 206 00:07:43,160 --> 00:07:44,750 easily got it to appear over 50 207 00:07:44,750 --> 00:07:46,010 megabytes, and at the moment, it's still 208 00:07:46,010 --> 00:07:48,680 on 47. 209 00:07:48,680 --> 00:07:51,240 So what we're going to do next, we're 210 00:07:51,240 --> 00:07:52,620 going to improve the efficiency of our 211 00:07:52,620 --> 00:07:54,770 adapter, and then run this test again. 212 00:07:54,770 --> 00:07:56,910 So what I'm going to do is close down the 213 00:07:56,910 --> 00:08:01,830 profiler, and then looking at our code - this 214 00:08:01,830 --> 00:08:05,310 line of code here, on line 29. So this 215 00:08:05,310 --> 00:08:07,440 line is a problem, where we inflate a new 216 00:08:07,440 --> 00:08:09,480 view every time the getView method's 217 00:08:09,480 --> 00:08:11,610 called. Now there's actually no need to do 218 00:08:11,610 --> 00:08:13,320 that, because the ListView provides us 219 00:08:13,320 --> 00:08:15,990 with a view to re-use, when it can. So 220 00:08:15,990 --> 00:08:18,120 that's what, for this getView 221 00:08:18,120 --> 00:08:19,650 function, that's what this convert 222 00:08:19,650 --> 00:08:22,440 View parameter's for. If the ListView 223 00:08:22,440 --> 00:08:25,020 has a view that it can re-use, it passes a 224 00:08:25,020 --> 00:08:27,450 reference to it in convertView. 225 00:08:27,450 --> 00:08:29,160 Now, until a view is scrolled off 226 00:08:29,160 --> 00:08:31,200 the screen, there won't be a view to 227 00:08:31,200 --> 00:08:33,539 re-use, so we have to check if convert 228 00:08:33,539 --> 00:08:36,000 View is null and only create a new view 229 00:08:36,000 --> 00:08:38,909 if it is null. So I'm going to alter the 230 00:08:38,909 --> 00:08:40,620 getView function so that it uses the 231 00:08:40,620 --> 00:08:42,780 convertView argument, and only creates 232 00:08:42,780 --> 00:08:45,720 a new view if convertView is null. Now as 233 00:08:45,720 --> 00:08:47,760 convertView's a val argument, we need our 234 00:08:47,760 --> 00:08:49,440 own view object to store the reference 235 00:08:49,440 --> 00:08:52,680 in. So let's go ahead and do that. Alright, 236 00:08:52,680 --> 00:08:54,840 so what we're going to do is put val 237 00:08:54,840 --> 00:09:00,930 view, and here we're going to put : view. Then 238 00:09:00,930 --> 00:09:03,300 on the next line, we'll just press 239 00:09:03,300 --> 00:09:05,550 ENTER there and leave the equals there. 240 00:09:05,550 --> 00:09:08,490 And now what we can do, is check to see 241 00:09:08,490 --> 00:09:11,190 if convertView's null and re-use it if it 242 00:09:11,190 --> 00:09:14,130 isn't. So instead of just putting the 243 00:09:14,130 --> 00:09:15,270 code as we had it, we're gonna come back 244 00:09:15,270 --> 00:09:20,000 here and put, over here, we're gonna put if 245 00:09:20,000 --> 00:09:22,410 parentheses convertView 246 00:09:22,410 --> 00:09:26,970 is equal to null, code block, and then we're 247 00:09:26,970 --> 00:09:29,760 going to put view equals. And then we're 248 00:09:29,760 --> 00:09:38,259 going to grab this code here; else. 249 00:09:38,259 --> 00:09:39,999 What we're going to do is, we're gonna 250 00:09:39,999 --> 00:09:43,600 put view equals convertView. So 251 00:09:43,600 --> 00:09:46,720 basically, now we're re-using the 252 00:09:46,720 --> 00:09:48,459 view given it back to the adapter by 253 00:09:48,459 --> 00:09:50,889 the ListView, and only creating a new 254 00:09:50,889 --> 00:09:52,809 view if the ListView didn't give us one 255 00:09:52,809 --> 00:09:55,479 to re-use. Now ignore this sub warning 256 00:09:55,479 --> 00:09:56,739 over here in the right hand side, about 257 00:09:56,739 --> 00:09:58,899 the assignment can be lifted out of the 258 00:09:58,899 --> 00:10:01,119 if. It's correct - we could - but Android 259 00:10:01,119 --> 00:10:02,559 Studio doesn't know what we're going to 260 00:10:02,559 --> 00:10:04,029 do next and then we wouldn't be able to 261 00:10:04,029 --> 00:10:06,399 treat the if as an expression. Now what 262 00:10:06,399 --> 00:10:08,410 I'm going to do is add some logging, so 263 00:10:08,410 --> 00:10:09,939 that we can tell when a new view's being 264 00:10:09,939 --> 00:10:12,639 created, or when we we're re-using one. So 265 00:10:12,639 --> 00:10:14,739 let's go ahead and do that as well. So in 266 00:10:14,739 --> 00:10:17,889 the test for null, we'll actually put a 267 00:10:17,889 --> 00:10:22,809 log entry in there. So Log.d TAG, and in 268 00:10:22,809 --> 00:10:23,889 double quotes, we're going to put get 269 00:10:23,889 --> 00:10:30,220 View called with null convertView, and 270 00:10:30,220 --> 00:10:31,869 then in the else we're going to do the 271 00:10:31,869 --> 00:10:34,449 same - put a log entry in there. This time, 272 00:10:34,449 --> 00:10:42,329 getView provided a convertView. 273 00:10:42,329 --> 00:10:45,699 Okay, so let's actually now we've made 274 00:10:45,699 --> 00:10:48,129 those changes, run the app again, and see 275 00:10:48,129 --> 00:10:50,199 what effect this has had on the memory. 276 00:10:50,199 --> 00:10:52,329 So I'm going to, firstly, open the log 277 00:10:52,329 --> 00:10:55,329 cat - I'm going to clear that - and I'm 278 00:10:55,329 --> 00:10:57,399 going to run it. I'll stop it then run 279 00:10:57,399 --> 00:11:01,750 it again, 280 00:11:01,750 --> 00:11:03,639 and that was to make sure that the 281 00:11:03,639 --> 00:11:05,740 memory wasn't being held, that it was 282 00:11:05,740 --> 00:11:08,110 using previously. Open the Android 283 00:11:08,110 --> 00:11:12,449 Profiler, click on memory for more detail, 284 00:11:12,449 --> 00:11:15,310 and you can see we've still got a high 285 00:11:15,310 --> 00:11:16,509 amount, but it's obviously nowhere near the 286 00:11:16,509 --> 00:11:19,389 50 megabytes. And if I click on the trash can 287 00:11:19,389 --> 00:11:22,589 icon a few times, 288 00:11:22,589 --> 00:11:24,600 you can see it's getting down to 28 now. 289 00:11:24,600 --> 00:11:26,490 I'm just going to do that every few 290 00:11:26,490 --> 00:11:27,839 seconds until we've got a fairly stable 291 00:11:27,839 --> 00:11:30,269 amount of memory in use, and we can see, 292 00:11:30,269 --> 00:11:31,740 we're round about the amount that we were 293 00:11:31,740 --> 00:11:34,350 using previously. And clicking on the 294 00:11:34,350 --> 00:11:36,329 garbage collector is not causing, or 295 00:11:36,329 --> 00:11:37,529 not having any impact on the amount of 296 00:11:37,529 --> 00:11:40,920 memory, so that's good now. So now if we 297 00:11:40,920 --> 00:11:44,209 run, or we move over to our emulator, 298 00:11:44,209 --> 00:11:46,319 and now let's actually start doing the 299 00:11:46,319 --> 00:11:48,509 same thing again. I'm gonna start 300 00:11:48,509 --> 00:11:53,250 scrolling, up and down. Notice the memory 301 00:11:53,250 --> 00:11:55,500 this time, when I'm doing that. It seems 302 00:11:55,500 --> 00:11:57,660 to be easier to scroll, as well - it's 303 00:11:57,660 --> 00:12:00,660 quicker to scroll. But the memory, you can 304 00:12:00,660 --> 00:12:03,060 see that it's really not going much, if at 305 00:12:03,060 --> 00:12:06,329 all, above 31 megabytes, whereas before, we 306 00:12:06,329 --> 00:12:10,279 easily got to 50. 307 00:12:10,279 --> 00:12:12,600 As you can see, it's far more consistent 308 00:12:12,600 --> 00:12:14,820 than what it was. So that's definitely an 309 00:12:14,820 --> 00:12:17,700 improvement - around about 31 megabytes - 310 00:12:17,700 --> 00:12:19,740 just by making a simple change to our 311 00:12:19,740 --> 00:12:22,410 code. Now with more complex layouts, keep 312 00:12:22,410 --> 00:12:25,410 in mind that the numbers will get a lot 313 00:12:25,410 --> 00:12:28,620 larger. Now that's a much more efficient 314 00:12:28,620 --> 00:12:31,170 implementation of the getView method. So 315 00:12:31,170 --> 00:12:32,459 what we'll do is, we'll finish the video 316 00:12:32,459 --> 00:12:34,470 here, and in the next one, we'll actually 317 00:12:34,470 --> 00:12:36,300 improve it even further by employing 318 00:12:36,300 --> 00:12:38,370 something called the ViewHolder pattern. 319 00:12:38,370 --> 00:12:41,839 So I'll see you in the next video.