android客户端开发过程中，所有页面都会有的一个元素，也就是栏了（标题栏），尽管Google给我们提供了ActionBar和升级版的Toolbar，但是在中国的移动端设计中，我们往往会看到原生的ActionBar/Toolbar的元素不怎么用得上，比如我们需要title居中，而不是贴着左边，比如我们会在中间加一个tab切换的控件。
于是就出现了各种奇技淫巧，比如用一个xml来定义出一个通用的title_bar.xml，内部包含所有在栏上出现的元素，按钮、图片、文字、tab切换等等，然后通过在每个activity/fragment中各自去setVisibility来控制显示和隐藏。
结果导致整个xml庞大无比，可能有数百行，着各种view，而需求的变更则更可能导致同一个都有好几个元素，因为他们有一些小小的不同。
然后某个同事看到这个，觉得太重了，于是做了一个title_bar_sub.xml，相对轻量，只包含了左按钮、标题，以及中按钮。于是有些layout include title_bar.xml，另一些则title_bar_sub.xml。
噩梦开始了，有一个，设计改版要求间距调整，字体大小调整，噩梦来了，接到这个需求的新同学发现有好几个titlebar的xml，里面又乱七八糟，有的元素还在用，有的元素又貌似过时了（然后又可能在插件工程里还在引用），如此一般，一个在产品/设计眼中小小的界面调整，变成了一个庞大的体力活，还可能导致一些全局的恶性bug。
这里这种方法还算不错的，笔者还见过在每个layout里各自去写标题栏的，除非团队的设计真的不可能改，否则未来简直是个。
support v7中的是actionbar的升级版，不同于Actionbar，Toolbar直接继承了ViewGroup，从而可以直接在layout里面进行申明，并在里面添加子view，比如tab，和自定义控件等，更加灵活。
所以，类似地我们也使用一个xml来放Toolbar，但在里面，使用viewstub来对一些不常用的view进行lazyload。而对于原生Toolbar的title位于左侧的问题，我们同样使用自定义子view。
如此一来，manifest里的label会直接变成标题栏中间的文字，当然，也可以通过activity的setTitle方法来设置，是不是比findViewById简单方便了很多呢。
而对于各种viewstub的inflate，和一些自定义UI的设置，则有两种方案
- 继承Toolbar实现扩展
- 在BaseActivity里定义通用的方法
而fragment也可以通过getActivity然后转换为BaseActivity来调用到栏的设置。
究竟是做一个内聚的扩展性自定义Toolbar，还是在BaseActivty里加一系列相关方法，则见仁见智了。
另，强烈不多个xml！！完全可以通过常用元素直接visible，次常用gone，偶用元素viewstub来做。
像栏这种全局性的东西，随着项目的发展可能会越变越大，逐渐从不想改到改不了，所以在项目初期趁早使用良好的方案，避免给以后埋下一个，是很有必要的。
笔者强烈推荐使用Toolbar，既能自定义UI，又可以使用google支持的那些很不错的效果（比如design support里不少动画都要求Toolbar，抽屉的一些动画也会要求ActionBar或者Toolbar）。
推荐：