Android入门笔记(1)

  根据Dev Guide的说话,Android的application模型是比较独立的.即是1app1线程1用户1JVM.做个比喻就是每个app都是一个单用户的独立JVM中运行.
  这样,在设计上,是把每个应用独立开来的.资源不共享,独立存在.
  在Dev Guide中还提到一个android的特点,app之间可以使用双方开放出来的程序逻辑.这听起来是个很奇妙的东西.一般来说,我们会将这种重用性称为组件.像各个编程语言里常用到的控件.这种重用性的基础是接口的开放性.而android声称能够使用任何应用的任何开放逻辑,那么,也就意味着android有一个非常优雅的程序框架,使得不管程序所用的组件实现什么功能,都拥有一个一致的对外接口,不然不能说能使用任何程序的任何开放逻辑.
  对于这个模型,android首先先颠覆了一般程序员的逻辑.即,消除了main函数的存在.也就是通常意义的函数入口.某种程度上说,是有函数入口的,只不过被隐藏了.更多时候,我们或许应该称这个入口为loader,而android的程序是loader调用的程序逻辑,或许也可以称为动态组件式的编程模型.
  android在这种程序框架下,定义了4种类型的组件:
  1.Activities
  2.Services
  3.Broadcast receivers
  4.Content providers

  acititvies或许可以称之为event,他是一个用户导向型的组件.也就是说,它的程序逻辑是以用户角度来定义的.对应于UML,也许可以用用例来称呼它.acititvies完成的是一个用户产生一个需求,然后通过activity去完成它.比如通过滚动条下拉一页,发送一条信息,或者切换一个屏幕等.对于用户来说,这是一个操作.
  对应于activity背后的操作,是其前端的交互部分.一个用户操作必然存在着交互区域.android中,这个区域称为view.android将屏幕做一个root view或者正式地说content view.而view则是在这个content view里划分出来的一块矩形区域.这个划分或称可以使递归的,也就是说,你可以在一个矩形内再划分矩形.
  从这一点也可以看出,android其实是很重视用户交互.它不像传统的UI设计,将事件的相应绑定到一定的控件范围内,而是将整个响应区域开放.如何响应,响应些什么,完全由程序员决定.

  service则更接近于传统意义上的后台进程.它可以看错是对activity的一种补充.在不要求或者不需要用户参与的程序功能逻辑上,就由service完成.
  
  broadcast receivers是基于前面那个独立编程模型的一个补充.android将每个application隔离开来,举个例子来说,就是每个application是一个工厂里的一个车间,它们之间一般无法知道车间之外的事情.于是,为了能够让车间内能够对外部的一些变化作出响应,就有了broadcast receivers.这是一个类似于进程间通讯的概念.也是借鉴与网络里的广播模型吧.google的网络作风--世界是独立而又相互联系的.一个监听器样的存在.

  content provider也许可以称为剪切板或者是一个逻辑上的文本共享区吧.

  前三种组件是由传统的消息驱动模型的,而content provider则更像是文件系统.
  只是在android中消息装在了以intent为名的信封里.
  顺便一提的是context,这个无论在何种编程环境里都会存在的东西.当然,它的意义也基本相同.
  如同进程的寄存器状态,它代表的就是当前application的所有东西的容器.