前言

MVP系列文章
MVP系列文章（一） - MVC 与 MVP
MVP系列文章（二） - 优化attach()、detach()方法
MVP系列文章（三） - 动态代理优化每次判断 View != null
MVP系列文章（四）- GC回收原理分析
MVP系列文章（五）- 泛型擦除
MVP系列文章（六）- 代码架构与运行时架构
MVP系列文章（七）- 知识梳理

1. 代码架构

与业务逻辑无关，基本上每个项目都会用的。比如：访问网络、图片、BaseActivity、BaseFragment等等这些公共的东西；
代码架构一般是不会变动的，可以多花一些时间在代码架构；

2. 运行时架构

与业务逻辑有关，是自己项目特有的一些功能部分，比如：访问网络时参数要加密（RSA）、单点登录、插件换肤等等其他，这些功能是自己项目中特有的功能；

3. 如何选择架构层级

1>：所有代码，全部写到一起（适用于1个人做外包）；
2>：按架构层级分层：Base、Framework、App，每个层次一个模块（适用于2-3人）；
3>：多模块和多组件开发：多个协同开发，方便测试，单独模块可以单独测试，注意别搞成蜘蛛网，最好用路由方式，可以采用 ARouter（适用于4-5人）；

多模块和多组件开发.png

什么是模块？什么是组件？
模块：指的是你项目中的功能模块，如首页、发现、消息、我的、登录等等；
组件：指的是一些小型的辅助，比如自己找了一个动画效果、第三方的功能用到了自己项目中。组件也可以单独存在于module中；

处理不好可能会出一些问题，资源问题，命名不能冲突，返回键

4. 路由方式

1>：多花时间把代码架构、运行时架构搞好，然后建立4个 module ，分别是首页、发现、消息、我的；
2>：首页、发现、消息、我的依赖于运行时架构，运行时架构依赖于代码架构；
3>：每个人只在自己的模块中开发就行；

如果4个模块间要通信，不要直接依赖彼此，否则你依赖我，我依赖你，就全部乱了套了，如果有一天不需要发现模块了，那么到时候你再去删除发现模块，会非常麻烦。

这个时候可以搞一个路由，让这 4个模块都连接到路由上边，如果不需要哪个模块了，就直接把那个模块删除就好了，对其他模块没有影响

5. 怎样选择第三方

1>：熟悉原理：开发可控，意思就是如果出现问题，能够快速定位问题并解决；
2>：选择大多数人选择的，也就是选择星级比较多的，不要选择没人用的；
3>：一定要注意解耦，为的是重构、版本迭代；
4>：站在成员角度去选择：培训同事，倒逼；
倒逼就是：比如明天我们会用到哪一个东西，大家今天晚上去学习一下；
5>：模仿别人写好的东西，自己先模仿好别人的东西，等待自己熟悉之后，然后再去把这个东西变成自己的；

6. 其他补充

1>：需求文档：

自己需要写需求分析文档，否则如果中途修改需求，你在开发过程中可能发现逻辑不通，所以自己可以写需求分析文档；

2>：不要滥用继承和接口，多用封装；

如果觉得哪个部分比较常用，完全可以写一个工具类抽离到utils包下，不要写到基类BaseXxx中；

3>：不要嵌套：

每个功能全部分开写，不要嵌套在一个类中写；

4>：所有界面全部分开写，哪怕有两个界面时一模一样的：

尽量不要公用同一个界面。
比如：登录中的忘记密码、修改密码界面可能一样，这个时候你可能想要把这两个界面共用一个，用一个flag来区分是从哪一个界面跳转过来的，这个时候可能可以，而且也比较简单，但是如果后期你的这两个界面修改了，里边的功能发生变化，这个时候你只能在这个同一个界面中修改，可能会比较麻烦，所以要求我们把忘记密码、修改密码，即使像这种界面一样的，都不要放到一起写，都尽量分开，分成多个界面来写，如果以后界面发生修改，直接去对应的界面修改就可以，就不用去管其他界面的变化；

MVP系列文章（六）- 代码架构与运行时架构

前言