对一个规模较大的App开发团队来说，保持统一的代码规范是个好的事情，同时，保持统一的用户体验规范也是个好的事情。
当用户进入一个页面时，一般会有以下交互场景：
场景1， 初始化loading，页面从server拉取配置信息；
场景2， 初始化成功，页面展现业务UI布局，比如输入框，按钮等；
场景3， 初始化失败，页面从server拉取配置信息出现异常；
场景4， 初始化失败，因为设备的网络连接异常；
5， ……
对于某一个负责某一业务模块的开发人员来说，他可能会有糟糕的用户体验实现：
实现场景1， 当初始化页面的时候，直接展示业务UI布局，然后弹出一个loading对话框，用户可以看到地下残缺不全的UI元素；
实现场景2， 初始化成功之后，dismiss掉第1条的loading对话框，业务UI布局被数据填充；
实现场景3， 因为数据错误初始化失败， dismiss掉第1条的loading对话框，业务UI布局没有数据可填充，残缺不全，甚至状态不对（比如某个按钮需要让server的开关决定是不是点亮状态），然后toast一句错误给用户，之后用户只好退出页面再从入口再次点进来以进行初始化重试；
实现场景4， 因为网络异常初始化失败，同第3条，UI元素没数据填充，状态不对，用户被一句toast打发了，没有重试入口，只能退出页面再来；
对于另一个负责某一业务模块的开发人员来说，他可能会有良好的用户体验实现：
实现场景1， 当初始化页面的时候，页面暂时不展示业务UI布局，而是展示一个加载中的页面；
实现场景2， 当初始化成功之后，切换到业务UI布局，并用数据填充UI；
实现场景3， 因为数据错误初始化失败之后，从加载的状态切换到一个“没有数据”或者“数据错误“之类的页面，并且用户点击页面，可再次重试初始化接口；
实现场景4， 因为网络异常初始化失败之后，从加载的状态切换到一个”网络未连接“之类的页面，并且用户点击页面，会再次重试初始化接口；甚至，监听网络状态，当网络连接后，自动重试；
好，对比之后，我们把第二个开发人员的体验实现当做规范，并要求所有开发人员在业务页面实现过程中都遵守这个规范。
那么问题来了：
1， 业务开发人员工作量增加，上面讲的4个场景都要一一实现；
2， 冗余代码多，上面说的场景，除了第2条，1， 3，4都是一样的代码实现；
3， 场景1， 3， 4的实现没有收敛，以后无法统一修改；
然后，一个抽象的实现来了，BaseActivity， 把场景1， 3， 4都包了，只留下2给业务开发人员去实现。
更多，一般每个页面都有导航栏，导航栏是个通用实现，上面的场景都是针对导航栏下面的区域进行的，跟导航栏没关系，所以这个BaseActivity也把导航栏的实现给承包了，子类透明无感。
子类布局的root view对于BaseActivity来说，只是其布局中的一部分。
BaseActivity要做这些事情：
1， 布局，包含导航栏，以及导航栏下面的4个要切换的布局，包括loading布局、业务UI的父布局、数据错误布局、网络异常布局；
2， 重写所有setContentView方法，子类调用这个方法的时候，把其传过来的view添加到第一条里的业务UI的父布局上；
3， 假定网络请求返回的数据对象是BaseResult，BaseActivity提供protected的一个方法，该方法接收一个BaseResult参数，然后根据其内容自动切换到对应的场景布局下；
4， 提供网络异常和数据错误的点击事件回调给子类，以便子类发起重试；