APP项目完整搭建小结

前言
最近公司在开发一个新的 app。个人决定使用一套完整的项目架构来实现这个 app，以将学习运用到生产环境以及学会真正从全局高度来设计一个架构合理，逻辑清晰，扩展性强，代码优美的产品，并且能达到任务书的需求。

框架选择

因开发的为 音乐播放器 类型的 app。根据以往经验，需要使用一个 播放音乐的 Service 与多个界面进行交互。Service 的作用有与 c++ 播放器交互从而播放音乐，获取状态，回调状态给 UI，资源出错处理。
界面的作用主要是展现数据，提供操作，显示状态。

根据个人对比 MVP 以及 MVVM 两种项目架构。更倾向于使用 MVP 来进行项目的搭建。因为总感觉在 xml 中 binding 数据对象不符合于 xml 只做数据展现，而不做逻辑处理 这个个人认为的观念。 MVP 存在的问题就是整个项目的类会偏多，重复的创建相似结构的操作比较多，但是对于结构清晰的项目，这个不会作为首要问题。

MVP 的封装 待写

对于项目的分包，个人倾向于按照 功能模块分包 。而一些共同的如工具类、网络请求、数据库操作、bean 对象则按照文件类型分包。总的原则是 大方向按照文件类型分包，具体功能按照模块分包

项目分包的示例 待写

网络请求决定使用 Square 全家桶 OkHttp3， Retrofit2.0 结合 Rxjava 来完成。对于这三个工具的使用，以后详述。

OkHttp3 及 Intercept 的使用 待写

RESTFull 和 Retrofit2.0 待写

Rxjava的简单使用及操作符的示例 待写

图片加载本来准备使用 Square 公司的 fresco，后来被使用 glide。个人更倾向于 picasso(因为其名字更具诗意)。后期有机会做个使用方法对比，封装替换以及三者的比较。

Fresco、Glide、Picasso对比 待写

数据库目前使用的为 LiteOrm，因为更为熟悉，后期项目可能会替换为 GreenDao，并使用加密的数据库。使用数据库为了保存帐号信息，缓存数据信息，默认配置

GreenDao3、GreenDao2 与 LiteOrm的比较 待写

ButterKnife与Annotation及其原理APT的学习 待写

数据分析

难点分析

使用环境的网络状态多为弱网情况，为了让用户验尽可能流畅，做了一些处理：

1. 播放界面的播放按钮的显示

2. 网络数据缓存

3. 收藏/取消收藏请求缓存

4. 弱网重复请求播放
   最先是写在界面，存在的问题是界面销毁时请求需要取消，打开下一个界面时又需要继续发起请求

5. 音频广告插入

6. 账号切换及多终端登录

7. 实时监听网络状态的变化

经验总结（踩过的坑）

• Service 的生命周期

• 没有执行的 unBind() 的 Service 不会销毁

• aidl 文件不能删除前面的方法

• 对于需要对外提供的 aidl， 最好的办法是专门做一套代码专用

• 对于通过源码依赖的第三方项目，自己写的功能独立，代码庞大的项目，需要创建一个 module，并使工程主 module 依赖于该 module，而该 module 则完全不依赖于工程主 module

• 项目框架的搭建不是一蹴而就，在整体确定的前提下，代码量不多的地方可以编写到一个人间，等到后续需求明确或增加在做持续的重构，优化。根据项目的需求来使用更合适合适的方式实现。总的宗旨是 该使用 interface 的使用 interface， 该抽取到父类的抽取到父类，该创建独立功能的创建独立功能

• 对泛型的合理使用会使代码量更少，代码层次更优美

后续优化

• 抽取公用的代码成一个独立的 module

• 数据库使用 GreenDao

• 夜间模式

• 日志分析，日志上传

总结

• dex 分包解决 65k 问题

• 一个界面对应多个 Presenter 的问题和一个 Presenter 对应多个 Module 的问题

• 懂再多的框架，开源项目的使用终会跟不上潮流，要明白更本质的原理，思想，设计模式。