每个Android的application被archive在一个.apk文件中。呈现在app list中的只有其中那个被标为Main的Activity的图标。
点击这个图标就会运行这个Activity所在的application，然后系统会给这个app分配一个单独的Linux process。这个process当然也拥有一个单独的Java virtual machine(JVM)。当然了，默认的也会给这个app一个唯一的Linux user ID。虽然很“自闭”， 不过很方便(杀掉这个process就关掉app了)，也很安全(sandbox都很安全嘛)。
当然了，如果让多个Activity穿一条裤子(分配同一个Linux user ID)，她们之间就没有秘密可言了：你的东东我也可以看到可以拿来用(颇有点儿共产的味道)。如果把她们都放到一个Linux process中，用同一个JVM，那就真的“好得成一个人”了。
四朵金花(Components)
Android的一个中心思想就是共享：别的application的东东，只要她愿意，我就可以拿来用。因此，Android的application没有唯一的入口(象main()函数的东东)。整个app由四朵金花组成：Activity、Service、Broadcast receiver、Content provider。
Activity：
她虽然是MVC中的C，却握有显示大权，因为她有一个window。这个window可大(全屏)可小(浮动)。另外，Activity还可以使用一些额外的window(比如弹出的对话框)。
window里面的内容就是views。一个view可以包含别的view，就象树状结构，很多的view就组成了window里要显示的内容。使用很简单：把树根的那个view扔到Activity.setContentView()就行了。
Service：
人们都很贪心，总想在做一些事情的同时还要做其他事情(比如在某个Activity中播放音乐，却想切换到其他的Activity去画图，但音乐不要停)。如果播放音乐这件事交给某个Activity就糟了，因为离开的Activity有可能被系统干掉。这时候Service登场了！只需要把播放音乐这件事仍给某个服务就好了。服务还可以放出一些接口来给用户操作(比如暂停、前进、后退等等)。
Broadcast receiver：
系统和其他的app常常会放出一些broadcast，比如电池没电了，刚拍了张照片等等。Broadcast receiver就是专门用来接收这些broadcast的。据说一个app可以有任意多个Broadcast receiver……
Content provider：
如果一个app想把她的一些小秘密(存储于文件系统、SQL数据库或者其他地方的数据)分享给别的app，她就使用Content provider。当然，即使是好东东，其他的app也不能一拥而上，她们必须使用Content resolver来获取。
进程与线程
前面提到过，当application开始运行的时候，系统会为她分配一个Linux进程，然后是一个属于这个进程的线程(也就是主线程)。从根Activity instance开始，所有组件默认都跑在这个主线程里。当然，有凡是就有例外。
进程：
可以自由的为各个Component分配进程。方法很简单，只要使用各个Component的process属性就好了。如果让不同的app的Component使用相同的进程，那么就等于为她们分配了相同的Linux User ID！
内存不足而需要关闭进程的时候，系统会关闭重要性最低的进程。也就是说，在那个进程中的app被杀掉了。
线程：
大家都跑在进程的主线程里，就有一个问题：系统的很多服务也是跑在这里的，比如按键响应、通知等等。所以还是把一些耗时的操作扔到不同的线程里去吧。当然要注意线程安全。
