网上很多解释这三者关系的文章，鄙人咋一看，内容不无道理，但细思一下，感觉解释起来还是有点牵强，还是不能完全理解这三者的作用和关系。究其原因，无非是从应用开发的角度去解释。而从应用开发的角度分析，难免过于局限。鄙人之前有幸做过android framework相关的开发工作。下面从系统设计的角度来解释一下这三者的关系，作为三者关系的补充。
毫无疑问，window,activity,view都是和显示相关的模块。这里就涉及到设计一个操作系统的显示模块的时候，需要解决哪些问题。
问题一，如何解决抢占display resource的问题。
这个其实就是要解决各模块抢占屏幕资源的问题。
我们知道，手机一般只有一个屏幕，各个模块都要在一个屏幕上显示内容，比如状态栏要显示手机状态信息，虚拟导航栏要显示虚拟按键，键盘要显示键盘按键，app要显示自己app的内容等等。那么一个屏幕怎么去显示这些内容，以及这些内容如果显示区域重叠的时候，又该优先显示谁的内容。google为了解决这个问题，设计了window的概念，各个模块拿到一个window,往window里填充要显示的数据（其实是往surface，这里涉及到window和surface和surfaceflinger的关系，大家先忘记surface的存在,只要知道window就行了。），window有window type属性，可以理解成window的优先级。最后把所有的window按window type的顺序进行垂直叠加（z-order顺序叠加）然后送往framebuffer.这样一个屏幕就能够有规则的显示各个模块的内容了。
问题二，如何解决scenario问题。
什么是scenario问题呢，其实就是人能够正常理解的场景切换问题。
我们想一下，如果从界面a进入界面b,然后关闭界面b,那么按正常的理解，我们应该退回到界面a.这些场景交互过程在设计操作系统显示模块的时候都得考虑清楚，并提供一套默认的行为。google为此设计了activity的概念，通过activity间的切换来解决scenario问题。这里插一句，activity是用来解决scenario问题的，那actity本身就肯定要承载显示内容，而显示内容刚才讲是通过window来完成的。所以activity里面肯定就有一个window。activity用于控制这个window里数据的显示和隐藏。
问题三，如何高效解决绘图和事件处理问题。
解决了问题一和问题二后，整个显示框架的二个老大难的问题就不是问题了，那么还剩下的问题三应该是应用开发者更关系的，因为这涉及到如何快速开发一个应用。我们知道，要在屏幕上显示内容，几乎所有的操作系统都有提供画布和画笔api，用于绘制显示的内容。可是这远远不够，第一，单纯靠画布和画笔api来开发太难了，效率太低。第二，画出的ui，要处理事件响应也太复杂。第三，每个模块用画笔和画布去画，那整个界面显示风格必然不统一，最后看上去肯定很丑。google设计了一套view system。里面有很多控件，主题等。大家拿着这个直接用，方便快捷。
以上就是window ,activity,view之间的关系。但设计一个操作系统的显示框架，除了以上三个问题外，还有很多其它问题要解决。如果深入去理解android的显示框架，就会发现除了以上三个模块外，还有其它模块支撑起整个显示框架。
