目录介绍
1.关于项目app的整体结构
1.1项目总体结构
1.1.1 目前项目使用架构
1.1.2 目前常见的架构
1.1.3 MVP架构优点及缺点
1.2.主要的技术要点
1.2.1 布局常用及技巧技术
1.2.2 复杂页面展示及数据渲染
1.2.3 自定义控件编写及使用
1.2.4 数据结构及网络数据使用
1.2.5 常见业务流程处理
1.2.6 工具自定义封装使用
1.3 主要开源框架介绍
1.3.1 网络请求框架
1.3.2 注解框架
1.3.3 图片加载框架
1.3.4 api 23以后权限申请
1.3.5 事件总线框架
2 .项目中的代码规范
2.1 关于包名，类名，方法名等命名
2.1.1 包名与分包
2.2.1 日志统开关，平时测试环境，上线关闭
2.3 资源文件string，color，dimen
3.项目中的总结分析
3.1 总结
4.常见问题思索
4.1 业务代码避免耦合度过高
4.2 如何解决问题
4.3 尽量少写无用代码
5.参考说明
5.1 参考链接
1.关于项目架构
1.1 该项目App整体架构
1.1.1 目前项目使用的架构
准备使用架构是MVP，Rxjava+Retrofit+OkHttp是网络请求框架，MVP是由MVC的基础演化而来，解决了MVC不少的缺点，相对MVC来说MVP提升解耦更好，业务分层清晰等特点，而以往MVC是把activity、fragment作为的controller和view使用，MVP的model相对于MVC是一样的，而activity和fragment不再是controller层，而是纯粹的view层，所有相关业务操作全部交由presenter层处理，这样做到一个相对的分离。
1.1.2 市面常见的架构
目前存在常见架构有MVC，MVP，MVVM等，
1.1.3 MVP架构优点及缺点
MVP框架由3部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。
View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity或者fragment)
Model:负责存储、检索、操纵数据
Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。
View interface:需要View实现的接口，View通过View interface与Presenter进行交互
优点：(1)MVP相对于MVC来说降低了耦合 为什么真么说呢？ MVC中我们把业务数据交织在一起，也就是activity或fragment中，那么我们后期需要去修改需求的时候会引发修改难度大改一处而动全身，所以工程量会比较大总结下来就是(降低耦合)，
(2)业务模块相对来说比较清晰，以往我们很 多业务交织在一起，所以比较模糊不太容易分辨我们具体业务，MVP能很容易看出我们的业务分层，也为我们开发后期维护有很大帮助，总结下来就是(模块划分清晰)
(3) 很多时候我们的业务模块相似，那么这个时候我们是不是想到一点就是代码复用。少写一部分代码可以提高开发效率，然而MVC就解耦性比较差，就大大减少代码复用，开发的灵活性比较差，总结就是(代码复用及灵活性高)
这些呢是个人对于MVP的一些观点当然还有其他的，这几点相对来说比较突出所以你们也可以继续探索。
缺点：(1)那么说了这么多优点我们来看看缺点，我们Persenter和View交互我们需要通过接口实现，那么各个业务不同会造成接口过多，加上我们的Model 那么代码中会相对比较繁琐，这样会使项目体积变大，后期也会有麻烦，总结下来就是(接口多项目体积变大)。
(2) View和Persenter 会频繁的交互那么如果我们的View发生变化时相应Persenter也要做出改变(交互频繁)
1.2 主要的技术要点
1.2.1 布局常用及技巧技术
布局中主要的一点就是尽量的层级嵌套不要过于复杂，因为渲染时一层一层往下渲染所以层级过于复杂的话那么耗时相对比较长，根据设计图的布局选择相对比较合适的布局方式，依然可以使用android最新的约束布局实现一个层级布局，这当中会涉及到约束布局使用，包括居中，向上，下，左，右，平分布局等，具体可以参考链接地址：study.163.com/course/intr…
1.2.2 复杂页面展示及数据渲染
对于复杂页面，我们选择是自带控件RecyclerVIew 支持扩展性强，功能强大 ，所以我们可以用它的多类型扩展特性完成我们的复杂布局，同时一个控件展示渲染也为后期业务变化修改提供便利性，具体可以参考链接地址：study.163.com/course/intr…
1.2.3 自定义控件编写及使用
通常项目中控件不能满足我们平时开发，那么这时候我们需要自定义一些控件来满足我们开发，自定义相对比较复杂，要求掌握知识比较全面一些，我们可以根据自己的需求来定义控件
这次我们自定义中涉及到事件分发，动画，自定义流程，事件回调等，具体可以参考链接地址：study.163.com/course/intr…
1.2.4 数据结构及网络数据使用
数据是我们开发中相对比较重要的一个知识点，我们View需要数据来渲染才会使我们的视图有生命，完成我们的页面逻辑及业务，项目中我们提供了真实企业级的项目接口也封装了网络 请求工具，具体可以参考链接地址：study.163.com/course/intr…
1.2.5 常见业务流程处理
项目的最终目的都是我们为了实现我们的业务，项目中要根据产品提供的文档来对业务做一些具体的操作，我在项目做了企业级的项目业务处理，虽然不是同一个项目但是万变不离其中
处理方式无非就是我们的流程控制及回调处理，具体可以参考链接地址：study.163.com/course/intr…
1.2.6 工具自定义封装使用
对于项目中我们需要用到一些方法，那么如果很多地方都用到那么写一次，这样会代码会比较繁琐， 可以把这些方法写成我们公用类静态方法以提供给其他地方调用，比如我们的时间格式化，获取手机参数，转化单位，获取屏幕宽度，高度，像素密度等，具体可以参考链接地址：study.163.com/course/intr…
1.3 主要开源框架介绍
1.3.1 网络请求框架
Retrofit: 底层基于OkHttp 实现，Retrofit 负责请求的数据和请求的结果，使用接口的方式呈现，OkHttp 负责请求的过 程，RxJava 负责异步，各种线程之间的切换
OkHttp: 也是Square 开源的网络请求库
RxJava:RxJava 一个在 Java VM 上使 用可观测的序列来组成异步的、基于事件的程序的库，总之就是让异步操作变得非常简单。
RxJava + Retrofit + okHttp 已成为当前Android 网络请求教优的选择。
1.3.2 注解框架
目前常见的注解框架：
XUtils：xutils是通过反射来实现的，跟Butterknife的是它需要手动实现注解
AndroidAnnotations：该框架的原理跟Butterknife一样
ButterKnife： 自动生成注解与类属性，Butterknife目前支持的注解有: View绑定，资源绑定，事件绑定。
1.3.3 图片加载框架
ImageLoader：异步加载本地及网络图片，同时实现缓存
Picasso：不仅实现了异步加载图片，还是决解了图片加载的一些问题，错位，压缩，自带二级缓存等
Glide：Glide具有高效 获取、解码和展示视频剧照、图片、动画等功能。
1.3.4 api 23以后权限申请
权限管理，直接使用谷歌原生权限框架
1.3.5 事件总线框架
activity，fragment，service等不同组件直接通信一直是个头疼的问题，那么我们使用事件总线来进行通信
EventBus：EventBus逻辑非常的清晰，代码之间高度解耦，在进行组件、页面间通信的时候，是很好的选择，
具体使用方法可以参考地址：github.com/greenrobot/…
2 .项目中的代码规范
2.1 关于包名，类名，方法名等命名规则
2.1.1 包名与分包规则
包名：com.xxxx.project 例如：com.ousang.tinder 其中xxxx是咱们企业名称，最后是项目名称
分包以如下图：
2.2.1 环境统一开关，平时测试环境，上线关闭
在我们的管理类中设置一个方法控制我们的环境，平时测试时使用测试环境，上线时更改为上线环境
2.3 资源文件string，color，dimen
(1)对于项目中的字符串我们统一写入到清单文件string中以规范化，后期更改只需找到清单文件更改即可
(2)因为设计颜色相对会比较繁多，所以项目中的颜色值我们统一写入到清单文件color中以规范化，后期更改只需找到清单文件更改即可
(3)同样尺寸我们统一写入到清单文件dimen中以规范化，后期更改只需找到清单文件更改即可
3.项目中的总结分析
3.1 总结及收获
(1)项目中存在问题时要多思考问题原因，因为这样才能收获，不要盲目搜索，带着问题关键去寻找。
(2)完结项目后要回头去看代码是否可以更完美，尝试优化。
(3)和他人分享，每个人的想法有可能是一种收获
4.常见问题思索
4.1 业务代码避免耦合度过高
平时开发时尽量避免项目的耦合度过高，Persenter与View尽量做到耦合低， 避免日后的维护修改麻烦增加工作量，
4.2 如何解决问题
开发时会遇到很多的问题，那么我们可以借助搜索引擎的寻找答案，但是你要能看问题的核心，报错时我们需要看我们日志然后找到问题所在倒推问题发生源，如果是业务出错时回头去仔细查看文档分析，检查代码然后调试断点查处问题，总之就是不要慌，镇定。
4.3 尽量少写无用代码
我们布局，业务代码，工具，能抽取出来成为一个公用的时，就抽取，就公用，因为这部分相同代码实际上没有意义，到还繁琐，浪费时间或者都可以放进一个公用的包内。
5.参考说明
5.1 参考链接
Android App的设计架构：MVC,MVP,MVVM与架构经验谈：
www.tianmaying.com/tutorial/An…
浅谈 MVP in Android：
blog.csdn.net/lmj62356579…
刘望舒大神，Android架构（一）MVP全解析：
blog.csdn.net/itachi85/ar…