iOS 页面组织 显示规则

画了一个简单的组织结构 示意图，看图说话

1 每个App必须有一个window用于展示页面。

2 每个App的这个window必须有一个rootViewController，用于直接/非直接管理后续的ViewController。

3 显示规则：系统将正在显示的页面 挂载到window上，用于展示。而不展示的页面，则会从window上暂时移除(其window为nil，而他被所归属的ViewController管理生命周期)，等待需要展示的时候再重新挂在window上，可以做测试，如上，制作一个简单的demo，在显示ViewController3对应的view的时候，查看ViewController2，ViewController1的view对应的window，可见是nil的。但是，在ViewController3的每一个子view上，获得到的window都是同一个。pop掉ViewController3，此时ViewController2的view及其子view的window又不是nil了，而是这个window。

4 通过查看UIView中window的接口，开始怀疑window是view缓存的一个变量，但是通过kvo，无法监测到它的变化，可见，xxView.window是一个获取接口，其实现是深度递归其父view，父辈view满足window规格即为其window。

因此，用ViewController来组织页面，用于展示的只有window和当前显示的页面的view，而不显示的view暂时被移除，以备内存紧张的时候被系统回收掉，而不影响程序正在显示的界面。这一切都不需要程序员来管理，是框架提供的。

所以，那些通过view来组织页面的App是不合乎iOSapp设计规则的，需要程序员来管理view的生命周期，缺点是：可能内存占用过大而不能灵活利用，并且维护view的逻辑代价比较大。

为了制作一个view而创建一个ViewController，然后把ViewController的这个view 添加到某个view上的做法是错的，不合乎框架规则的。

在写程序的时候，要时刻想着：我创建的这个对象，归属于谁，被谁管理(也就是谁负责他的销毁，内存的回收)，这样你熟悉他的生命周期，你就熟悉你的程序在内存方面的使用情况，内存是计算机比较重要的资源，要节省资源和重复利用资源，你的App才能运行持久哇。