以下是我这个系列的相关文章，有兴趣可以参考一下，可以给个喜欢或者关注我的文章。
[Android]如何做一个崩溃率少于千分之三噶应用app--章节列表
看到这个标题，可能有人会耻笑，认为这应该很简单吧。
但是请认真思考一下啦，
你设计的app是否有经过万级的日活，十万级的日活，千万级的日活？
你设计的app是代码量是多少？你能保证你代码不停迭代，依然保持低崩溃？
你设计的app的有没有通过云测？
你设计的app的适配性和优化性是否已经达到业内领先？
产品的设计和运营是否已经达到瓶颈？
如何算崩溃呢？这里崩溃是指app被强制关闭或者app捕获异常重启。
就以现在的手机YY为例吧，他们的日活超过百万，他们的崩溃率是千分之七。
我们现在研发的app经过六个月的迭代，崩溃率却依然低于千分之三。
如何统计崩溃？一般成熟的app都会有抓log后台上传机制，这里就不过多的介绍啦。
下面属于我的观点
1.过度的代码框架设计不是好的设计，以我看来过于臃肿噶设计框架，大大降低了文件噶可读性（有时，你找一个别人写的文件都需要找半天这样效率是多低），文件命名和层级别嵌套太深。
2.需要一定基础工具类构建，而且需要这些类的扩展性很好。图片和网络类型库等等，还有定义的BaseActivity和BaseFragment。
3.很多大公司都会自己封装一些框架类，而不是用第三方的开源。这样的好处很明显，就是可以减少代码方法和避免一些不必要的适配，或者是多种库的优势的集合。但是缺点就是，可能会缺乏维护这样的框架，而且也不如成熟第三方开源更新得快。
4.是没可能完全解决耦合的，没有任何依赖是产生代码关联的，我们要只是降低代码耦合，所以现在出现了很多代码注入的框架（例如Dragger2），一些设计模式（MVP，MVVM）。
这里先说明一下，这是个持续更新的贴子，只是一些经验分享，如果有更（犀）好（利）的经（吐）验（槽）在帖子里回复。
可以给你们看一下现有的工程框架
简单介绍一下这套框架，不同于其他MVP，MVVM的代码框架。我们这套框架最主要通过功能分层。
1.base依赖于core和framework两个module
2.modules里面是有很多功能模块，都是通过独立的library，每个library都依赖于基础的base。
3.client是依赖了modules里面全部的功能library。
4.mi和baidu是属于多渠道特征加载入编译里面，也是依赖于base。
可以考虑一下这样的设计有什么特别的地方？
一个工程有多个modules的好处体现在，做业务就是功能叠加，倘若需要移除和添加功能模块，就要最低消耗下降低模块的耦合。
如果我想添加一个功能模块只需要在添加一个功能modules的libray，然后再client里添加依赖，client添加一个modules的调用入口和布局入口。（client是所有modules的调用入口，和整体布局，也是通过client来生成app），删除一个功能module也是同理。而且就算保留这些入口，直接移除modules也是不会出现崩溃的。
可以接入多个渠道的定制功能，每个渠道可以独立加入不同的模块（支付，登录，登录页特效等等）。
所有模块都可以共用core和framework提供的接口。
*2016.11.27更新
架构的示例图
****2017.3.6****
有些同学是想说崩溃率是怎么计算的，每次发版后计算 崩溃数/启动次数
然后某直播公司的灰度是千分之三就可以发版了。
这只是个开端，如果简友有更好的框架推荐，可以留言地址，谢谢！
我建立了一个关于Android架构学习的群，里面可以进一步进行组件化学习的交流。
群号是316556016，也可以扫码进群。我在这里期待你们的加入！！！
