Modern Android development: Android Jetpack, Kotlin, and more (Google I/O 2018)
[Music] hello welcome to another talk welcome to modern Android development I should point out before we start that this Sun is a lot brighter than I am so yeah so we can either put on the glasses and not see the slides or don't put on the glasses
and not see anything so so that's gonna be fun we'll see how this goes today welcome to modern Android development I'm Chet Haase from the Android toolkit team and then we'll amongee from the android framework team so there's something and we're gonna talk about a bunch of stuff that you probably already know but it occurred to us that we have given you advice and information about how to develop good apps for Android over the years and that information has changed over the years as we've introduced new capabilities new API is new performance on the platform all kinds of things and so it's a little confusing you could go search for information even on some of our Doc's site and maybe get information that doesn't really apply to a lot of situations currently so we wanted to wrap it all together and say here's our current 2018 view of the important things to think about Android this 10 year old 10 years old this year and the electorate said a lot of outdated information sometimes you know I see blogs on Stack Overflow someone being really mad about something that we said 10 years ago don't be mad it's ok things change things evolve well it's not because we hate to is that because if we were wrong it's because it was a different time different needs different devices so we're going to talk about some of that just to make sure you understand the difference between the modern way of doing thing and the old way of doing thing we have a slight hint on the slides so some of the sides are going to look like this so let us begin so let's take a look at a timeline this is sort of all the you know history of Android over time so 1.8 1.
0 came out in 2008 and then apparently we didn't do much for several years and I don't know what was going on there I just couldn't think of the things to put in there optimize optimize optimize well then the Android studio came out what according to the web we were busy building bad api's apparently those weren't the ones you wanted so we've worked better at that over the years so Android studio came out so we changed from eclipse in the Android studio where now we were building in Richard capabilities then we could at the time art came out it was let's see it was off by default in KitKat and it was the only runtime in lollipop this is huge as you'll see in some of our recommendations there because it really has changed over time the way we look at the way you should write your code prior dalvik information does not necessarily apply in an art world recyclerview was released important because it was a better version of ListView with more flexibility but also we started releasing components in the support library disconnected from platform releases which means you could use these new capabilities in your applications across all the releases that you cared about little while later we had constraint layout built into Android studio a richer way of actually designing your api's as opposed to the rich way of typing XML directly Kotlin I think that came out last year I don't know some IO conference or something architecture components these were announced last year 1-0 in the fall new way of doing things where we are trying to solve or at least help with a lot of complex problems with Android and taking feedback from the community and iterating on that to create developer API is that make things easier for you that is the whole goal studio profilers so much richer way for actually figuring out what the performance metrics are for your application KTX the extension library that came out a couple of months ago for Kotlin and recently the paging library came out went 1-0 just this week so this is sort of a scope of some of the things that have happened over time I'm pretty sure there was more going on between 2008 and 2013 I just can't remember what it was all right we're gonna start with tools here's a tool that you may know how many of you have used this tool hard here oh that's pretty good and not everyone there was so that was our tool called Harkey or it was part of the sdk twister stand-alone application there was actually another version before that one that was the one our dealer wrote in the weekend because I needed the bugging tool to optimize the platform and for some reason we started shipping it in the SDK it wasn't the fastest tool it wasn't the prettiest tool actually this one was built by someone who funnily enough we're spending a lot of time actually sleeping at their desk that was very interesting never used the technique before didn't quite work so now we replaced it with something much better called layout inspector it's part of Android studio one of the nice benefits that you can open multiple inspections at once it's a lot faster so if you haven't used that tool go use it it's a very easy way to analyze your Harkey and you know debug various things like padding and margin and you know even performance sometimes if you have too many views that overlap each other here's another one that's the old way of profiling the code so that was called trace view so trace view is a tool that already existed when I joined the Android team in 2007 so it's been around for quite a while here we see it in action inside of Eclipse it used to be its own standalone tool so one of the issues that we had with trace with the original version was an instrumented profiler so there was a lot of overhead it was running on every method that was invoked it was running in interpreted mode and so you couldn't really trust the number so when he said you know this method took three milliseconds that wasn't true the method actually was a lot faster than that and the only thing you could do is compare the relative time between different methods and even that was difficult because if a method was invoking native code native code was not affected so any method in working native code was skewed because you know numbers projects also wrong over the years we added sampling for funding to the stool but so it was very difficult to use only a few of us even were using it internally because it wasn't that great a few later thankfully we introduced systrace so the big benefit of systrace of a tracer is that it gives you a comprehensive view of the entire system trace view tells you how much time you're spending in on every line of code inside your application basically but sometimes performance issues come from somewhere else in the system maybe you're blocked on something that's in a different process so this trace gives you that view that you needed before that were completely in the blind and now we have fellows that have been introduced in Android studio I think they're part of three point two or three point one I don't remember but if you go to the to the profile tab you're going to see a real-time graph of the CPU usage of your application and the memory usage of your application and if you double-click on the CPU graph you're going to get to that view looks very similar to trace you again it's a lot faster and it lets you do native code profiling instrumented profiling sampling for fighting and even systrace so this is the tool that you should be using from now on and this is what the produce graphs look like so we have now a believe three graph four graphs we have the the CPU one the memory one the network one and the energy one I've never used the network one because I'm not sure what servers are for but I'm sure you guys understand that and you'll make good use of it and that's what it looks like when you when you enter the the CPU profiler so you get a flame graph you have different ways of analyzing the data the one I like is the flame graph it's going to colorize all the function calls with the different colors depending on how much time they take so anything that shows in red shades or dark orange are the bottlenecks inside your application so very easy way to drill down and then inside your application identify the bottlenecks this is the native profiler it's available starting on android 8.
0 so in the Oreo or her to be able to run it and I mentioned briefly the new memory profiler so to do memory tracking we used to use this tool called DDMS again it was a standalone tool it was built on the Eclipse platform it was a little difficult to use Kristin was not part of the idea at some point we added it back in the idea and I was pretty much the only good way you could see whether or not we're allocating memory in the wrong places for instance when you're doing drawing or doing layout or touch handling and now it's part of again studio so when you see this graph that shows you in real time the memory usage you can even see like the different buckets so it's gonna tell you how much you're using on your Java heap or how much native memory you're using a how much graphics memory you using so you can pinpoint where the plan is coming from you can also create a slice as you see on-screen and is going to show you all the allocations during that time you can see the stack traces you can fold the references you don't have to dump to do damage profile converted using edge popcorn you don't have to run j-hat and see this horrible looking web UI that you used to have to use it doesn't do everything yet so sometimes you still have to go to J hat but it's a very good way to get sorry if you have memory issues inside your application layout design used to be like this it's hard to call a design and it's interesting because when Android came out it was very hard to convince everyone to move to XML remember a lot of angry developers really wanted to write Java code to build a UI and now we've given you this so this is the constraint layout the visual editor and now we have a lot of angry developers who would love to use only XML and not the visual tool so I guess we have to invent something new just as a decoy to make you start using this one I think the only constant is that engineers will be unhappy with whatever new option you give them especially the French and if you went to the if you went to the wedding tools talk you've seen a sneak peek of a new tool for motion layout to create animations using constantly out Nicola and John are going to show that again I think tomorrow Thursday so go find that talk and so we want to make it clear that this visual designer is only the beginning there's so much more we can do we haven't had time to build everything yet but this new motion layout editor is one is the next step and you know building animations with visual feedback real-time visual feedback is of what make sure than using XML runtime in language said sure so dalvik don't be so sad well that was awesome for doing what it was designed to do which was it was optimized for space when the g1 came out it had 192 Meg's 48 of which well 64 a small portion was a very small amount of memory was actually available for applications to use so dalvik could not as a runtime take up a bunch of memory for itself for all the the heap and where it needed to store things so that meant that as devices got better as memory got larger it didn't necessarily have the capabilities to optimize in the wholesale way that we needed to at some point they basically started from scratch on the art time that as we said came out in KitKat and was default in lollipop but back in the dalvik days we basically had recommendations that came from that because of things like allocations being really expensive it had to walk the heap and find a place to put this thing and the heap got fragmented over time which meant that even if it had a bunch of space there it didn't necessarily have a lot of contiguous space in which to find a place to put that object and then collections were also really expensive you ended up you would allocate things over time and then eventually it is going to run out of memory and when it does that when you're in the middle of an animation you're on the UI thread and it says I need to allocate space for a bitmap can't find the space better run a GC you're probably going to lose two or three frames just because dalvik needed to actually collect all the items without references anymore so some of the recommendations we had were basically avoid allocating things whenever you can that's certainly the way that we live life inside the framework because we are your inner loop but we also recommended that application developers do that one of the recommendations that I believe the community has seen batted around was don't use a news write because they are it turns out on a new structure the class structure is a whole lot bigger than an in table jekt right and we use insult over the place because we try to minimize the amount of memory we're taking out and we also try to minimize the amount of time we're creating a new object as opposed to passing primitive types around we also said that primitive types are cool insert cool floats are cool capital I integer not so cool also what's not cool is auto boxing so when you're using standard collection classes if you have a bunch of information stored in these primitive types and they're being auto box in and out or if you're using other patterns and approaches that cause these things to get created into objects you would see in the tools that we had like allocation tracker at the time the you'd be auto boxing and causing allocations along the fly and then eventually GC kicks in and you hate yourself just a little bit more so modern world we now have art it is optimized for performance it was created from the ground up not to optimize for memory but to optimize for performance and this is performance in terms of met call stuff but it's also optimized for allocations and collections way faster allocations and collections for a few different reasons one of those is it has a set aside for large objects so instead of putting everything in the same heap and then having to find space for large objects amidst all the tiny ones it puts all the bitmaps in a separate heap all the large objects overall it's way easier to find information I find space for those large objects and then the small objects go in the separate heap also really cool it candy fragments – all of it could not defragment so it would allocate over time and eventually there wasn't enough space for that thing you needed so you would get these obscure error messages where it said that it couldn't find a megabyte because there's only 48 megabytes free doesn't make a lot of sense until you realize well it's probably that the heap is fragment and we can't really do much about that now we can in our 2d fragments that heap in an earlier release it would be fragment when the application was in the background now we can actually defragment when the applications in the foreground as well so way better so the recommendation we have now are go ahead and allocate when necessary it's okay in fact if you use a noobs I don't care go ahead apparently you do care so I hope you enjoy them we still as a rule tend to not use them in a lot of framework Odin api's they are they are there sometimes but as I said we are still the inner loop so we tend to be way more conservative than you necessarily need to be in your application code use appropriate types I still think primitive types are really cool but you know what if you need to use a collection with an object type that's okay but be aware that these phones are still constrained devices memory may not be you know 48 or 64 Meg's available but it is still being shared with everything else you being used being run on that system also batteries are really important it's important to let that battery last as long as possible so if you're constantly doing things all the time if you're constantly generating garbage and collecting it sure art is a lot faster at that but art still has to do the work of actually allocating and collecting and all of that stuff uses powers so it's still good to remember that the battery uses power and that maybe you should be conservative on what you're trying to do and also like the framework be aware of the inner loop bottlenecks don't do things in a tight loop that may cause performance problems so when Android was started the team decided to go with the Java programming language to create applications and there were many reasons for that the main one was it was an extremely popular language there were millions of developers who knew how to use this language there were many excellent and free tools so you know it was really helpful for the quick adoption of the Android platform over time we have been sometimes a little bit slow at adopting new versions of the language we recently started supporting the Java programming language version 1.
8 I think they are reaching ten at one point ten but it served us for many years last year thankfully we announced full support for the couplet programming language how many of you are using it right now all right keep him up 1 2 3 almost everyone it was dead well more than 5 we'll skip a few side so we announced it last year in 2017 we're working in close collaboration with JetBrains we're making sure that our tools work work well of Catalan and it makes that we have access to the features we need overall we like it because it makes code more enjoyable to read and to write and we spend so much time reading and writing code that it does matter so have a few examples here they're gonna be hard to read but it's okay because you all know how to write cut line those examples are taken from the Kathleen extensions so I'm going to go over them really quickly I like named parameters you don't have to create multiple other loads of methods or builders all the time you can inline functions which is really useful when you create extensions or even when you create graphics code for instance we saw that operators you can overload operators you should be you know careful with that you can use this quite a bit and I've done this myself one since I created an infix operator called axe because it looks like the cross-product for vectors don't do that it's a terrible idea I put it on github because it's a terrible idea you can do this structuring assignment so when you have a POJO you create methods called component 1 2 3 etc then you can do more you can do multiple assignments in one line of code so this is an example again from Kathleen Katie Android Katie axe where we dis structure an integer so you don't have to do shifting and masking of bytes and integers we have data classes very easy way to create all those gathers and to string and calls and ash code so you don't have to and you don't even have to type the shortcut to tell IntelliJ to do it for you that's 2 level of laziness that we reached with Kathleen so that's fantastic and finally yes I just want to call out some of the things that to me make make cotton so appealing is very smart design decisions they've made in the language and one of them for instance is when a lambda is the last parameter of a function they have this special syntax that you can use you'll have to pass the lambda as a parameter to the function you can just open the curly braces and put your code right there it looks and feels a lot more natural so one of the things we're doing now when we design a new API is in the platform starting with Android P we make sure that our Java API is follow these conventions when we have a single abstract method interface we make sure that the parameter that use this interface goes at the end of the list of parameters so that cutting developers can you know benefit from this particular feature in the language and we're going to do more and more of that in the support library in all of our future api's so for those of you who are not using cart in yet project and contains both cotton and Java you don't have to convert all your application to cutting you can the next class you're at your application can be cutting or you can convert an existing class we have a ton of lint checks is there are things that are missing go to out or is going to write it like pretty much in front of you and commit it right away it's kind of a machine when it comes to trading lean checks check out the Android extensions again there's a talk by a Jack Wharton I think on Thursday morning about it it's going to talk about a lot of interesting things we also created a style guide so those of you who are still using our Java guide I mean we didn't really have one but if you're following our source code you're pretty perfect in your fields with em you're gonna be happy to know that we're not doing that anymore with cutting first because we don't really like it and also because you can't redo it because of the properties syntax and cut in any way we also have an interoperability guide so if you're gonna be writing code that is meant to be consumed by both Java developers and cutting developers beets that you're writing java code or cotton code we have gets for you that explained how you should be writing your IPS to the of the they can be used in a natural manner in both languages and those are the guys that were following ourselves for new ideas in the platform in the support libraries let's talk about api's first of all layouts and Android there are a bunch of them but these are kind of the major ones that people dealt with over time first of all there was absolute layout and you know it's so easy to use why wouldn't you then you just tell the view exactly where you want it to be right linear layout you can just nest those things as deeply as you want to and get the exactly the UI you're looking for frame layout it's fine you know you can you squint at it it's kind of like an absolute layout if that's the best thing we can say about it comply grid layout turns out it's a little bit complicated to use but you know we can figure that out and it has a lot of flexibility there and relative layout we've heard that it's expensive is this something we should be using or not so the modern world here's how we think about absolute layout we just want to make it clear [Applause] the only reason that this is not deprecated is because there is one important class that subclass it is the participate okay well we deprecated and that's about as far as we can take because webview is an absolute layout sorry don't use that hopefully you're not linear layout it's actually fine to still use especially for simple cases if you're deeply deeply nesting then you're deeply deeply wronged and there's a better solution we get to it at the bottom of the slide frame layout it's also okay for simple use cases you need to put that one thing in there with you know appropriate padding and margins that's kind of what the dirty secrets of Furman out is that it's an absolute layout in these guys use margins correctly you're busy enough so close but don't do that don't do that don't do that a grid layout so it turns out that it's it's really intended to be used with tools except the problem was we never actually wrote the tools so I think we forgot probably not the best layout to use for your situation unless you're already wrapped your head around it okay there may be better solutions out there relative layout we believe that constraint layout is in general a better solution now we think of it as a subset of the capabilities a relative layout it has a lot of the same capabilities of relative positioning of children with respect to each other but it has way more like relative positioning to guidelines and some of the new capabilities they've been working on to consider what I like to describe use construct notes these are relative layout that's works and also the best thing about it is it's tightly integrated with the tool it was written in tandem like by the same people with the tool which means the design tool works really well with that layout as opposed to well they created the api's and the tools sort of never caught up that is not the case there we mentioned 2.
0 it's not 2.
0 yet I would say it's too dotto soon so gusano I am what's up into dotto that talk by John and Nicola this week we'll go over some of that stuff probably final thought on on absolute layout just to make it clear so we have a class in the UI toolkit called adapter view it's the base class for a number of widgets so list view grid view in gallery and all I mean they served us fine for many many years they had a few issues they were difficult to maintain grid-view I think has not been used by pretty much any app for quite a while maybe for applications gallery is kind of like a horizontal ListView and I'm pretty sure it's been deprecated for a long time and we haven't certainly been looking at it for a while so I wouldn't use it if I were you anyway oh it doesn't work so you have some of the issues so an adapter view has an adapter and the adapter is the interface between your data set and the view itself so one of the things you can do in the adapter is nullified view of any changes in the data set the points that you can only notify of course grant changes all you can say is hey something has changed so absurdly enough in this view we have a lot of code that's trying to figure out what has changed wouldn't be nice if you could tell us because you probably know well we built an API where you cannot tell us so that's kind of done we also used to tell you to follow this pattern the view holder so the view holder and you know it's one of those things where I've seen a lot of people mad online about the view holder because for updates you have to write it was actually extremely important I went back and I looked at one of our old talks and using the view holder pattern would give you an extra 10 frames per second when you were scrolling your list view on its mobile g1 so it did matter a lot way back then it's not as necessary anymore but in the case of recycle you it's part of the API so you cannot get it for free anyway and funny animations animations are possible with adapter views of instance let's say you have a ListView in an item disappeared from the data set and you'd like the item to fade away and the rest of the item to collapse and close the gap you can do this with ListView all you need to do is write this little bit of code Chet wrote a blog post about it I think a few years ago that was one of the ListView animations we had a series of videos showing you how to do different ones this is part of this part of the code you only need to understand the future observer and transient state and measures and now to the animations it was rather difficult so instead now we have the recycler view thank thankful so this is just a dumb application the first time actually used a recycler view was a couple months ago it was so much easier that was really nice I was able to create the different versions the recycle view the nice battery sacrifice that instead of creating of having multiple widgets that are effectively different layouts for your data set you can specify a layout for this for single recyclerview so this is the same exact code with just different layout managers for the recycler I should point out too that all of those words verdict were vertical but you can actually have a horizontal layout for years people asked us how to do a horizontal OSB you just set a rotation on the ListView and then you have to intercept all the touch events and rotate them and then you know there's a few more ApS that you put in you to override because anyway that was easy secret though the easiest way is simply rotate your phone 90 degrees which has gotten easier with some of the system UI improvements anyway that's released so and one of the nice things about recycle view I mean there's so many things much much better ways you know we have paging and we have prefetching the API is nicer you can change level managers you can write on the out manager but also animations they come for free so the equipment have the code we just saw is this and in particular with recycle you what you get is fine grained changes so you can tell us if an item was removed what item was removed when an item was added what I think was that it you can tell us about phalanges of the of items that I've changed or you can tell us that everything has changed this is much better for you and for us all right fragments in the old days we heard that fragments were really complicated and also we would fix this thing so we didn't necessarily have everything correct or have all the api's that people needed so we would put in improvements and we put that into the platform release and then applications could only use that with devices on that platform release and so the modern device is don't use the platform version we have since ported all of that code and make all of the fixes in the sport library and we have now deprecated fragments in the core platform so don't use them there use the support library or now jetpack version of fragments we are putting more goodness there so use those and also we are making continuing to make improvements there's a talk on fragments this week tomorrow by Adam and Ian tomorrow so please check that out to hear more information about things that we are doing as well as ways to use fragments which should be a little bit easier a major one of those is the new navigation controller so check that out it sort of builds on fragments that doesn't depend on them there is no dependency but it does build on those capabilities for creating and navigating between the screens of your application activities very closely related to fragments in the old days basically Android applications consisted of multiple activities that was the application flow for all Android applications we expected developers to do this and developers did this when you want to go from one sort of screen of your app to another one you launch an intent you get a new window there you have some window animation to get you there and there you are the new approach is use single activities when you can it turns out that's a much richer experience for the user those window animations they're well they're animating but they're not doing anything interesting they're not doing anything that helps the user transition from one state of the application to another instead it's basically completely separate windows that are coming into view when you could actually use single activity approaches to retain the same chrome around the application white as well have the same action bar with the content switching out from underneath it or use richer animations which are possible with either the core platform animations or fragment transactions fragment animations so go ahead and use an activity you may have situations in your application where you have different entry points especially if you have a deep link that someone may come into your application with then it's appropriate to have separate activities that is the way to expose that information but otherwise try to use a single activity fragments are not necessary for single activity applications but they can help with this a lot especially with some of the recent improvements there and the navigation controller stuff to architecture so here was the old advice a few years ago mm okay only 2016 so basically two years ago Dianne Hackborn posted this on G+ we usually get this question from application developers where they will ask us what application architecture they should use in their application and our answer is always we don't care we are not you we don't know how your application works we don't know the best architecture for your application so please make your own decision and then there's usually a follow-up question of yeah yeah I get that but which architecture should I use so Diane posted this to basically say this once and for all we do not care the components that we have in there the the content providers the activities the services these are system level components they're not an architecture around which you build your application so please build the one that's appropriate for your applications the new advice is actually we're happy to provide you some recommended architecture because it turns out that people would at least like some common advice that makes sense and we believe that we have that now specifically with the architecture components we think that we have an approach that makes a lot of sense we have api's that are easy to use and you can build around those we are not demanding that you use this please use the architecture that makes sense to you but we do have a core architecture that we believe should work if you're starting a new application if you have new developers on your team it makes sense one of the reasons that we worked with Android architecture components was to solve hard problems one of the hardest problems was Android lifecycle and our answer was all you need to do is understand this diagram and memorize it and someone externally did their own version that diagram which looks like this which is actually a lot easier to understand if you look at it like this so that's basically everything you need to know and keep in your head at all times so the problem would be you would basically create a bunch of methods in your activity so that you could track and manage lifecycle you're handling creation and starting and stopping and resuming and pausing and you're probably doing stuff in destroy as well you're probably doing too much in oncreate you're probably having race conditions as well as the leaks and you're starting your stop and you're probably doing that in the pause and resume as well and you're not exactly sure why you're overriding on destroy but someone told you you probably should so we'll do that as well so in the meantime you actually only know the lifecycle State if you override those methods we didn't give you a way to query that we know what it is internally we're just not letting you in on the sea all right so there is no API for you to query so you need to override all those methods and then you end up chucking too much code in there so too much logic basically happening everywhere the new approach is we have an object called a lifecycle owner you can ask it for a lifecycle object and then you can either query the state if you want to know what state a lifecycle you're in or you can set an observer on it and then you can get callbacks into this methods this allows you to abstract it into a separate place so you're not basically bogging down activity code with all this information but you're putting it where it makes sense in your application fortunately we override we subclass lifecycle own or implement that in both fragment and app compat activities so in the support library please use these those are lifecycle owners so basically you can query them to get the lifecycle and then go from there so we went from a model where you would have activity with basically all of this lifecycle dependent logic in it to a model where the activity can be much smaller take that logic out abstract it into this over the thing over there set a lifecycle observer on it and get the callbacks you want we have a similar problem going on with views and data we have an activity and then we have all this information about the views in there and then we have the data for the views and we need to know when the data changes and we need to also track the lifecycle so we don't leak things or call things at the wrong time so we just end up having too much stuff there well now you have this concept of a live data and a view model where you can put that stuff you can abstract it out of the activity so you can put all that information out there observe that stuff so now in the activity you should really have only information about views and a reference to the view model and then put all of that logic in the view model it's using live data objects its handling lifecycle on its own and you can observe it way better way less buggy for data our approach our our argument to you was kind of well you you're on your own we don't we don't manage your data do whatever you want and there are lots of database solutions out there we have sequel light in the platform go ahead and use it knock yourself out whatever weird that we don't want to get into that business the new approach is we actually do offer something for data it built on top of sequel Lite but it actually offers build time verification so you're not just sending these queries down and then getting errors at runtime but you can see this problem at build time and integration with the live data stuff that we saw earlier or you can be on your own if you if you want to we're not trying to take over your database solution we're simply offering a better local persistence story than we had previously to make it easier for you the overall diagram looks like this the only new element here is this idea of repository it's a pattern for basically abstracting for where the data comes from so if it comes from local or web shouldn't matter to the rest of the people that are querying it so it's kind of nice to have an abstraction their data paging so we had this thing called cursor adapter it had some good elements about it it did have support for a database cursor that's nice but it was specific to ListView and had basically other problems with in efficiencies paging sizes stuff like that we had a sync list util which was more useful but also was really inefficient for doing things like web transactions so we'd have a new model in modern Android we have data paging the paging library went 1-0 this week and there are good things about it so it works with recyclerview it handles fine grains data changes this is much more efficient uses background threads very easily you can observe changes so it's integrated with live data but again we're not forcing this architecture on you if you're using rx Java – you can integrate with that very easily as well and flexible data fetching options so you can specify you know the window size and when you want to get these things there are of course always trade-offs I find that the bad thing about data paging is that the name is rather boring graphics so when we start the Android we only add the OpenGL ES 1.
0 we didn't even we were doing everything with software renderer that was an issue for several years it was fast enough for the ology devices it's only when we hit the tablet form factor that started to become an issue we used to do a lot of nine batches and I'm sure some of you have suffered through the creation the nine patches or even worse trying to explain your UI UX designer how to create them like where do you put the black dots which side would they go I still don't know to this day text review which refers you we touched on that on in our previous talk basically there was always this point of use the less efficient texture view but that can integrate better with the other views that at least view animations or the use surface view and managing bitmaps was hard a lot of you built applications and you were getting out of many are errors because you're trying to create bitmaps and you have to do caching and this is difficult and our answer was basically it's Tel Aviv so nowadays we have opened the other 3.
1 and 3.
2 you have computers you have Vulcan if you want to do low level a graphics rendering we do a hardware acceleration everywhere vector drawables I've basically replaced most of our drawables and bitmaps in applications we have small applications we don't want to support supporting multiple densities is a lot easier you don't need as many as matches as before and something that we're now doing is that we're working with you very often develop application they were first turn to us for solutions but when the community that means you have been building amazing libraries that we think are the right answer that's the ones you should be using so for instance glide of Picasso or la di excelent at what they do like you want to manage bitmap so if you want to create crazy complex animation with Lodi you should use those we're not gonna you know spend them we're creating something that already exists out there and that we think is very good at what it does so please go use those libraries again nowadays you should probably surface you in a text review anymore it has outlived its time and finally we used to tell you to profile your code we used to tell you to work whenever possible and to minimize memory cousin consumption but now we have better devices you know we have a lot of course but a lot of RAM we have been language is a better runtime so instead what you should be doing is providing your code and avoiding work whenever possible and also minimizing memory consumption because it turns out that devices are still constrained you need to keep that in mind battery life is critical and bandwidth is precious and all of these contribute to user experience so your user will thank you if you are actually still being conservative out these things and getting the best performance for your application that's appropriate we would like to thank you and there's a different way to say this and I think we're done thank you [Music].
Nhận xét
Đăng nhận xét