Placeholder Image

字幕列表 影片播放

  • >> CLERON: Hi, my name is Mike Cleron. I'm an engineer on the Android Development Team.

  • Android is an open software platform for mobile development. It is intended to be a complete

  • stack that includes everything from the operating system through middle ware and up through

  • applications. In the next few minutes, I'm going to be introducing you to an overview

  • of the architecture of the Android platform. And I'm also going to talk about some of the

  • key principles that are underlying its design. If I'm going to talk about architecture, we

  • need to start with a diagram covered with a lot of little boxes and this is ours. Our

  • architecture, were going to start at the bottom work up. Our architecture is based

  • on the Linux 2.6 Kernel. We use the Linux Kernel as our hardware abstraction layer.

  • So, if you are an OEM trying to bring up Android on a new device, the first thing you do is

  • bring up Linux and get all your drivers in place. The reason were using Linux is because

  • it provides a proven driver model in a lot of cases existing drivers. It also provides

  • memory management, process management, a security model, networking, a lot of core operating

  • system infrastructures that are robust and have been proven over time. The next level

  • up is our native libraries. Everything that you see here in green is written in C and

  • C plus, plus. It’s at this level where a lot of the core power of the Android platform

  • comes from. I'm just going to go through and describe what some of these components are.

  • I'm going to start with the surface manager. The surface manager is responsible for composing

  • different drawings surfaces onto the screen. So it’s the surface manager that’s responsible

  • for taking different windows that are owned by different applications that are running

  • in different processes and all drawing at different times and making sure the pixels

  • end up on the screen when theyre supposed to. Below that we have two boxes, OpenGL/ES

  • and SGL and these two make up the core of our graphics libraries. OpenGL/ES is a 3D

  • library. We have a software implementation that is hardware acceleratable if the device

  • has a 3D chip on it. The SGL graphics are for 2D graphics and that is what most of our

  • application drawing is based on. One interesting thing about the Android graphics platform

  • is that you can combine 3D and 2D graphics in the same application. Moving over, we have

  • the Media Framework. The Media Framework was provided by PacketVideo, one of the members

  • of the open handset alliance and that contains all of the codex that make up the core of

  • the media experience. So, in there youll find IMPEG 4, H.264, MP3, AAC, all the audio

  • and video codex you need to build a rich media experience. We use Free Type to render our

  • fonts. We have an implementation of SQLite, we use that as the core of most of our data

  • storage. We have WebKit which is the open source browser engine, that’s what were

  • using as a core of our browser. It’s the same browser that’s powering Safari from

  • Apple and we’d made some, weve worked with that engine to make it render well on

  • small screens and on mobile devices. Next is The Android Runtime. And the main component

  • in the Android Runtime is the Dalvik Virtual Machine. The Android Runtime was designed

  • specifically for Android to meet the needs of running in an embedded environment where

  • you have limited battery, limited memory, limited CPU. The Dalvik Virtual Machine runs

  • something called dex files, D-E-X. And these are bytecodes that are the results of converting

  • at build time .Class and .JAR Files. So, these files when they are converted to .dex, become

  • a much more efficient bytecode that can run very well on small processors. They use memory

  • very efficiently. The data structures are designed to be shared across processes whenever

  • possible. And it uses a highly CPU optimized bytecode interpreter. The end result of that

  • is that it’s possible to have multiple instances of the Dalvik Virtual Machine running on the

  • device at the same time, one in each of several processes and we'll see why that’s important

  • a little bit later on. The next level up from that is the Core Libraries. This is in blue,

  • meaning that it’s written in the Java programming language. And the Core library contains all

  • of the collection classes, utilities, IO, all the utilities and tools that youve

  • come to expected to use. Moving up again, we now have the Application Framework. This

  • is all written in a Java programming language and the application framework is the toolkit

  • that all applications use. These applications include the ones that come with a phone like

  • the home application, or the phone application. It includes applications written by Google,

  • and it includes applications that will be written by you. So, all applications use the

  • same framework and the same APIs. Again, I'm going to go through and talk about what some

  • of the main components are in this layer, in the Application Framework. The activity

  • manager is what manages the life cycle of applications. It also maintains a common backstack

  • so that applications that are running in different processes can have a smoothly integrated navigation

  • experience. Next down from that is the package manager. The package manager is what keeps

  • track of which applications are installed on your device. So, if you download new applications

  • over the air or otherwise install applications, it's the package manager that’s responsible

  • for keeping track of what you have and what the capabilities of each of your applications

  • are. The window manager manages Windows. It’s mostly a Java programming language abstraction

  • on top of lower level services that are provided by the surface manager. The telephony manager

  • contains the APIs that we use to build the phone application that’s central to the

  • phone experience. Content providers are a unique piece of the Android platform. That’s

  • a framework that allows applications to share their data with other applications. We use

  • that in our contacts application so that all of the information in contacts, phone numbers,

  • addresses, names is available to any application that wants to make use of them. And other

  • applications can use that facility as well to share data. The resource manager is what

  • we use to store local iStrings, bitmaps, layout file descriptions, all of the external parts

  • of an application that aren’t code. I'm just going to touch lightly on the remaining

  • four boxes, view system, location manager, notification manager and XMPP service. The

  • view system contains things like buttons and lists, all the building blocks of the UI.

  • It also handles things like event dispatching, layout, drawing. Location manager, notification

  • manager and XMPP service are some APIs that I think will allow developers to create really

  • innovative and exciting applications. And the final layer on top is Applications. This

  • is where all the applications get written. It includes the home application, the contacts

  • application, the browser, your applications. And everything at this layer is, again, using

  • the same application framework provided by the layers below. Now, if youre going to

  • write an application, the first step is to decompose it into the components that are

  • supported by the Android platform. Here are the four major ones. We have activity, intent

  • receiver, service, and content provider. An activity is essentially just a piece of UI

  • typically corresponding to one screen. So if you think of something like the mail application,

  • that would be decomposed into maybe three major activities, something that lists your

  • mail, something that shows you what an individual mail message and a compose screen to put together

  • an outgoing email. An intent receiver is something different. An intent receiver is a way for

  • which your application to register some code that won’t be running until it’s triggered

  • by some external event. And the set of external events that triggers your code is open and

  • extensible. So you can write some code and through XML, register it to be woken up and

  • run when something happens, when the network, the network activities established or at a

  • certain time or when the phone rings or whatever trigger makes sense for your application.

  • The next major component is a service. A service is a task that doesn’t have any UI, that’s

  • long lived, that’s running in the background. A good example is a music player. You may

  • start playing some music from an activity, from a piece of UI, but once the music is

  • playing, you'd want it to keep playing even if youre navigating to other parts of the

  • user experience. So the code that’s actually running through the playlist playing songs

  • would be a service, that’s running in the background. You can connect to it later if

  • you want to from an activity or some other component by binding to the service and sending

  • messages likeskip to the nextorrewind.” The last component is a content provider and,

  • again, that’s a component that allows you to share some of your data with other processes

  • and other applications. Now, any application can store data in whatever may--way it makes

  • sense for that application. They can store it in the files. They can store it in our

  • super light database, whatever makes sense. But if they want to make that data available

  • as part of the platform so that other applications can make use of it, then the content provider

  • is the solution for that and we've used that for the context database that comes with the

  • Android platform so that any application can make use of the information in context. Android

  • was designed at a fundamental level to encourage reusing and replacing components. I have an

  • example here that shows how that works. On the left, there are four applications that

  • might want to pick a photo for some reason. So the home application might want to pick

  • it for wallpaper. Contacts might want to pick a person’s face to associate with their

  • contact card. Gmail or MMS, you might want to have a photo that you sent to someone in

  • an outgoing message. Now, an Android for these applications to make use of the service of

  • taking a photo, they first need to make a request. So the client component makes a request

  • for specific action. In this case, I’m illustrating that with a talk balloon and the Gmail application

  • is requesting that it picks a photo. So the talk balloon is actually representation of

  • a formal class in our system called an intent. What the system does when a request is made

  • is it looks at all of the installed components and it finds the best available component

  • that knows how to do whatever was asked for. In this case, let’s say that the system

  • finds the built-in photo gallery. Now, what happens is the Gmail application is now connected

  • to the photo gallery. When the user in Gmails wanted to pick a photo, he will be taken to

  • the photo gallery and the photo gallery will fulfill whatever was asked for in the intent.

  • What makes this interesting is that the picking of the matching component is late bound, it's

  • done very late and so you can swap software components at any time. So let’s say you

  • didn’t like the built-in photo gallery and you wanted to replace it with one that went

  • online to find a richer or bigger set of photos. You can replace our built-in photo gallery

  • with one that say goes out to Picasso or whatever your favorite online photo site is. Once youve

  • done that, then any of the applications on the left will now use the new and better component

  • on the right to fulfill the task of picking a photo. And at any time, a new application

  • can come along and make use of existing functionality. So if youre writing a blogger application,

  • you don’t have to worry about writing a photo picker yourself. You can just rely on

  • whichever one the user has configured to be their preferred photo picking application.

  • This becomes really important because in Android, it’s not just about picking photos, virtually

  • any task has an intent in the middle. If the user is going from point A to point B, there’s

  • an intent in the middle and each of those intents is an opportunity to reuse a component

  • or to replace a component. So we have intents for going home which means you can replace

  • a home application. Or we have an intent for sending an email which means you can replace

  • the mail application. All of these are opportunities for replacing and reusing components. If youre

  • interested in finding out more about Android, I encourage you to visit the developer site

  • and download the SDK. In the SDK, youll find a lot more documentation and sample code

  • and youll also be able to try building applications of your own. There’s also a

  • developer group that you can join to find out more information and I also encourage

  • you to check back frequently because well be posting updates to the SDK as the platform

  • matures. Thank you for watching.

>> CLERON: Hi, my name is Mike Cleron. I'm an engineer on the Android Development Team.

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B1 中級

安卓學 - 第1.3部分 - 架構概述 (Androidology - Part 1 of 3 - Architecture Overview)

  • 111 6
    陳連城 發佈於 2021 年 01 月 14 日
影片單字