Tab 模块 (三)

Tab 模块 (三)


TabContainer作为一层layout的存在有些浪费的，是当时应急为了实现调整tabViewList的gravity而作为layout添加的.
TabContainer完全可以作为TabMenu的一部分或者一个组件存在.


<1>TabContainer逻辑上也是一个中间层的角色，上下传达消息.
TabMenu的一部分C逻辑被分在了TabContainer内.


<2>TabContainer开放了Listen接口，主要目的是为了和上层的TabMenu交流消息<只有tabMenu implements了这个Listener>.
TabContainer类内部维护了很多和TabMenu重复的引用<TabManager,用于获取M>，因为两者的功能其实是一层的.


<3>同样处于对Bitmap构造成本的考虑，一个专门的基于LRU的Bitmap cache被构造<主要为thumnail服务>，
因为很多时候，在TabMenu显示出来时，很多TabView的thumbnail不会变化<只有当前用户所在的Tab会因为打开关闭网页而不断的变化>，
但是如果为每个TabView都直接对应维护一份Bitmap的thumbnial，有些占用内存，而如果不维护，每次TabMenu显示都会造成多次的screenshot，极为浪费时间，
出于平衡，一个有一定容量限制的Bitmap的cache是比较好的选择.
而每个Tab对象本身可以作为key来尝试从cache获取，在每次设置Tab的thumbnail时，都优先从cache中取得.
出于性能，这个过程也是一个延迟的post，在真正执行时，要先检查tab是不是还有效，以及tab的thumbnail是不是已经得到了.


<4>ActionBar这个UI组件的height被记录为dimen resource并提取，因为截取主界面的时候不需要截取ActionBar部分.


<5>更新某个TabView，如果TabViewList还没有被初始化，那么post一个delay再调用,否则，转发给TabVieList.


<6>TabViewList在最初需要一次初始化以设置要显示的View的相关的M，会有一个flag标示以避免重复init.


<7>TabContainer不是一个UI上可以交互的对象，没有任何的UI交互逻辑，只有转交逻辑.


<8>TabConatiner在被TabMenu<TabMenu监听了M层的增加一个Tab的消息>通知UI上增加一个新的TabView时，如果是有Thumbnail的模式，会发起一次截图延迟Add的request而，
在thumbnail的Bitmap创建成功以后的callback里会将Tab和thumbnail绑定，并通知刷新UI以显示新增加的TabView.


<9>更新显示某个或所有TabView的内容<主要是显示的内容>对外接口也由TabContainer提供，不过TabContainer也基本是简单的转发给封装的子View

<之前会检查子View是否init了>.