Deep Blue Sky

昨天夜里，确切的说应该是今天的凌晨，心情感到烦闷，辗转难眠，心中的一些话一股脑地往外倒。也许总要经历这样的过程，自省、反思，但是可能没过多久又旧病复发了。

很长时间里，感觉生命中总是一段段的空白，每每想起，心中无比的惶恐不安。除了懒散、堕落，其他的一样也没有很好的坚持下来。青春渐渐失去之后时常目睹拥有它的人却在全然无动于衷地挥霍青春。

心中的梦想像垂死的独角兽，时不时竭尽最后的气力嘶鸣，以证明自己依然存在于这个令人窒息的世间。

       似睡非睡中做了两个梦，两个梦在某种意义上有一种暗合的意味。短短的梦里重温着两种小小的幸福，但是也都是今后不能在拥有，至少不是可以无所顾及去做的事情了。

       转眼人生走过三十载，久久觑觎的两件事在短短的浅尝之后，还在意犹未尽之时难道就这么宣告结束了吗？越发难能可贵的事情可能越是如此吧，也不知道从此生命中是保持了两种神秘还是又少了两样牵挂。

　　从某种意义上，她们两个如此相似：令人有意无意地坠入其中，更让人以为可以从此相伴一生，可是自己并不能像起初感觉到的那么理所当然。今后小小的亲近，都会招来不大不小的代价，尤其是其中的一个也许一个只能放在心里了，期盼另一个还能有些许希望吧。

Script of presentation from Google

Android is an open software platform for mobile development. It's intended to be a complete stack that includes operating system through middle ware and up through applications. The next few minutes, I'm going to introduce you the overview of the architecture of the Android platform, and I'm going to talk about the key principles that are underlying the design.

Android architecture is based on the Linux 2.6 kernel. We use the Linux kernel as a hardwire abstraction layer. If you're an OME trying to bring up Android to a new device. The first thing you do is bring up Linux and get all your drivers in place. The reason we use Linux is because it provides a proven driver model and a lot of cases existing drivers, and it also provides memory management, process management, security model, networking, a lot of core operating system infrastructure set are robust and have been improved over time.

The Next level up is our native libraries. Everything you see here in green is written in C and C++. It's at this level where the core power of the Android platform comes from. I'm gonna go through and describe what some of these components are.

I'm gonna start with the Surface Manager. The Surface Manager is responsible for composing different drawing surfaces onto the screen. So it's the Surface Manager responsible for taking different windows that are owned by different applications that are running in different processes, and all drawing in different times, and make sure the pixels made up on the screen when they are suppose to.

Below that we have two boxes, OpenGL|ES and SGL. And these two make up the core graphic libraries. OpenGL|ES is a 3D library. We have a software implementation that is hardwire accelerate able if the device has 3D chip on it. The SGL graphics are for 2D graphics, and that is what most of the 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 packet video, one of the members of the Open Handset Alliance. And that contains all of the codecs that make up the core of the media experience. So in there you'll find Mpeg4, H264, MP3, ACC, and all the audio and video codecs that you need to build a media experience.

We use FreeType to render our fonts. We have implementation of SQLite. We use that as a core of our data storage. We have WebKit which is the open source browser engine that we are using as a core of our browser. It's the same browser that's powering Safari from Apple. We've worked with that engine to make it render well on small screens on mobile devices.

Next is the Android Runtime. The main component of the Android Runtime is the Dalvik virtual machine. The Android Runtime was designed specifically for Android to meet the needs of running in embedded environment where you have limited battery, limited memory, limited CPU.

The Dalvik virtual machine runs sth called DEX files. These are bit codes that are the results of converting at build time .class.jar files. So these files, when they are converted to .dex files, become much more efficient bit codes that can run very well on small processors. They use memory very efficiently. Their data structures are designed to be shared across processes whenever possible, and uses a highly CPU optimized bit code interpreter. The result of that is that it's possible to have multiple instances of the Dalvik virtual machine running on the device at the same one in each of the processes. We'll see that's important later on.

The next level from that is the Core Libraries. This is in blue meaning that it is written in Java programming language. And the Core Library contains all of the collection classes, utilities, I/O, and all the utilities and tools that you'll expect to use.

Moving up again, we now have the Application Framework. This is all written in Java programming language. And the Application Framework is the tool kit that all applications use. These applications include the one set come with the phone, like the home application or the phone application, and include applications written by Google, and include applications that will be written by you. So all the applications use the same framework and the same APIs. And again we'll go through, and talk about what some of the components are in this layer.

The Activity Manager is what manages the life cycle and of applications. It also maintains a common back stack, 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 you download new applications over the air or other devices install applications, it's the Package Manager's responsible for keeping track what you have, and what capabilities each of the applications are.

The Window Manager manages windows. It's mostly a Java programming language abstraction on top of the 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 essential to the phone experience.

Content Providers are a unique piece of the Android platform. That's a framework that allows applications to share data with other applications. We use that in a contacts application, so that all 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 used to store locally strings, bitmaps, layout file descriptions, all of the external part of the application that aren't code.

I'm gonna touch lightly on the remaining four boxes, View System, Location Manager, Notification Manager, and XHPP Service. The View System contains things like buttons and lists, all the building blocks of the UI. It also handles things like layout, drawing. Location Manager, Notification Manager, and XHPP Service are some APIs that will allow developers to create really innovative and exciting applications.

The final layer on top is applications. This is where all the applications get written, includes the Home application, the Contacts application, the Browser, your application. Everything in this layer is again using the same application framework provided by the layers below.

Now if you 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, Activity, IntentReceiver, Service, and ContentProvider.

An Activity is essentially a piece of UI typically corresponding to one screen. So if you think of sth like the mail application, that will be decomposed into maybe three major Activities, sth that lists your mail, sth that shows what in the individual mail message, and a compose screen to put together out-going email.

An IntentReceiver is sth different. An IntentReceiver is a way for what your application to register some code that won't be running until it's triggered by some external event. The set of external events that trigger your code is open and extensible, so you can write some code through XML, and register it to be woken up and run when sth happens, when the network connectivity is established, or at a certain time, or when the phone rings, or whatever trigger make 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 piece of UI, but once music is playing you want it keep playing even you're navigating to other parts the user experience, so the code is actually running through the play list, playing songs would be a service that's running the background. You can connect it later, if you want to, from an Activity, or some other components by binding the Service and sending the messages like skip the next song or rewind.

The last component is a ContentProvider. 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 way make sense for that application. They can store them in files; they can store them in a SQLite database, whatever make 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 ContentProvider is a solution for that. And reviews that for the Contacts database that comes from the Android platform, so that any application can make use of the information in Contacts.

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 pick a photo for some reason. So the 'Home' application might want to pick for a wallpaper. 'Contacts' might want to pick a person's face to associate it with the contact card. 'GMail' and 'MMS', you might wanna have a photo that you send to someone in the out-going message. Now in Android for these applications to make use of the Service of picking a photo, the first need to make a request. So the client component makes a request for a specific action. In this case, we illustrate that with a talk balloon and the 'GMail' application requesting get a pixel photo. So the talk balloon is actually representation of a formal class in our system called 'Intent'. What the system does, when the request is made, is that it looks at all of the installed components, and it finds the best available component that knows how to do whatever that's for. In this case, let's say that the system finds the built-in 'Photo Gallery'. Now what happens is that the GMail application is now connected to the 'Photo Gallery'. When the user in GMail wanna to pick a photo, he will be taken to the 'Photo Gallery', the 'Photo Gallery' will fulfil whatever was asked for in the Intent. What makes this interesting is that the picking of the matching components 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 on-line to find a richer and bigger photos, you could replace our build-in photo gallery with one, say 'Picasa', or whatever you favorite on-line photo citers. Once you've 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 the existing functionality. So if you write 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 on Android, it's not just picking photos, virtually any task has intent in the middle. The user's going from point data point B, there's 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 intent for "Sending email" which means you can replace the mail application. All of these are opportunities of replacing and reusing components.

If you're interested in finding out more about Android, I encourage you to visit the developer's website, and download the SDK. In the SDK, you'll find a lot more documentation, and sample code, and you'll also try to build applications of your own. There is also a developer group that you can join and find out more information, and I also encourage you to check back frequently, because the updates to the SDK will be posted as the platform matures.