chanong 时间从来没有等过我们。 时间是一把刺在你脸上的刀。 它让你充满沧桑。 你一定很担心你的工作。 我不知道你现在在哪里，是否有你爱的人照顾你。 活得幸福还是活得委屈？
哦，我忘了。 你是一个有故事的人，“你想让她过得比你好，我希望你永远不会知道。”
年轻的时候不要惊慌，我来帮你布置一个框架。 进则可以重振雄风，退则可以养精蓄锐！
这篇文章适合什么样的人？
从这篇文章中你能得到什么？
前言
本文是在反复挖掘、总结、分享的基础上摘录自在线APP。 但由于商业原因，无法透露。 因此，任何与业务相关的用例都不会被提及。 并且不会包含任何商业项目的提及。 所有技术仅供技术学习交流。 本文不会是一篇纯粹的代码解释文章。 文中的故事也是虚构的。 具体技术实现请逐步参考，地址在文末。 特此声明。
致谢
感谢、、、几位前辈的无私分享。
踩到陷阱
什么？ 要求一个月后上线？ 我只是一个摆渡车。 只需复制并粘贴并将它们拼凑在一起即可。
上线一周后。 小王. 和老板讨论完产品后，我们下一步就是把首页的XX改掉。 后面主要流程就不再这样了。 你接下来要做什么……？
他妈的！ 你们之前为什么没有考虑一下呢？ 如何改变这一点。 代码是一团糟。 稍有动静，就有可能导致它到处倒塌。
项目中的代码如下：
请问劳资双方如何改变？ 是你说一个月内上线的。 以前只有上帝和我能看懂这个项目的代码。 现在只有上帝了。
分析
想想就让人恼火。 这都是你们加班一个月才想出来的。 上线不到一周就需要更改。 现在我头大了。 没有考虑到将来可能会进行维护或扩建。 改变？ 你还不想杀我。 但也没有更好的办法了。 我不得不默默地处理代码。
第二天，一个看起来像Dalao的人走进了项目。 大老看完会心一笑，小王。 这个时候，我们宁愿重建，也不愿在原来的基础上改变。 我们可以拯救今天，但不能拯救明天。 就这样，我向上级请求延长一些时间，我们一起重新设计了结构。
以前的项目结构：
Dalao的项目结构：
完成
等一下，大佬。 如果你只给我一张图片，我无法理解。 并且还没有解释清楚如何实现分离。
dalao咳嗽一声，嘀咕道：首先，我们的总体思路是，让我们现在开发的app依赖于
，我们尽量精简，只需要依赖即可。
{ 'xxx.xxx.xxx:' }
作为一个通用的依赖库，它有三个独角兽臂，分别是，，。
是一个基于MVP+的基础框架。 秉承了MVP的设计风格。 我们上层APP只需要继承它、、、就可以了。 上层所要做的就是将特有的服务填写到相应的层中。 下图5是基础。 APP中的业务单元如图6所示。 具体用法请参考，地址在本文末尾。
它是一个通用的工具箱集，可以解耦上层所依赖的第三方框架。 这句话怎么理解呢？ 如果我们要加载图片，你肯定不会自己在图片加载框架中重新发明轮子。 当没有层时。 项目1.0依赖的是2.0的时候发现这个库有bug，需要更换为主流的glide框架。 但是因为项目中很多地方都用到了API。 加载图片不可能只改一行代码，所有业务都需要使用新的加载工具。 此时的威力可想而知。 ，中间做解耦，调用上层。 调用第三方依赖。 当然这只是一个例子。 可以进行二次包装的地方有很多。 比如我们封装网络请求、视图动画等，下面是图片加载的二次封装实现代码。
//使用统一约束Api
{
无效初始化（）；
无效（，网址，）；
void ( , int resId , );
空白 （ ， ， ）;
void ( , 文件文件 , );
空白 （ ）;
空白 （ ）;
班级 {
最终整数=-1；
int = ;//正在加载的资源id
int = ;//加载失败的资源id
() {
新的 （。， 。）;
（整数，整数）{
这。 = ;
这。 = ;
//具体实现
班级 {
@
无效初始化（）{
@
无效（，网址，）{
加载((.()).load(url), , );
@
void ( , int resId , ) {
加载((.()).load(resId),,);
@
空白 （ ， ， ） {
load((.()).load("文件:////" + ), , );
@
void ( , 文件 文件 , ) {
加载((.()).加载(文件), , );
@
空白 （ ） {
Glide.get().();
@
空白 （ ） {
Glide.get().();
( ) {
Glide.with();
无效负载（，，，）{
if (== null) = .();
如果（。！=。）{
.(.);
如果（。！=。）{
。错误（。）;
。（）。进入（）;
//暴露给上层进行加载
班级 {
;
() {
如果（==空）{
（。班级） {
如果（==空）{
=新的();
;
它是自定义视图的依赖项。 所有不包含业务类型的视图都应放置在此处。
应用程序
APP是上层项目。 注意，除了传递依赖之外，还可以有自己独立的依赖，所以我们这里可以在APP中添加业务类型依赖。 比如：后端SDK、友盟统计、微博分享等，只在本项目中出现的应该放在这里。
我们再看一下架构图，看看是不是清晰多了。
比较的：
亦硕项目结构：
优势：
缺点：
建筑学：
优势：
缺点：
总结
该项目的建筑设计绝不是一成不变的套路。 应根据业务类型将其拆解为模块。 而且其实我个人认为很多时候在开发一个项目的第一个版本的时候，甚至会考虑搭建一个框架来编写它。 但由于进度、协作等因素，理想状态可能会有所不同。 一旦在线稳定，您应该考虑重组您的项目。 我见过一个同事，他的编码风格是一边写业务一边重构之前的代码。 将带领同仁与您共同发展。 读完之后我很困惑。 每次都再读一遍。 这不是一个好主意。 最好在与团队成员达成共识后开始该流程。
本来我不想发表这篇文章，担心我的知识匮乏会误导新人。 再加上工作上的变化，最近事情有些仓促。 希望各位读者多多留言。 如果觉得有用，就点个赞吧，这是对我最大的鼓励。
这个框架的最终地址是：
感谢脆皮鸡排同学提交文章，地址：
本文同步仓库。 如果对您的发展有帮助，欢迎您给作者star并分享给您的朋友。 编辑每天都在努力整理干货信息。 为了支持编辑，请在下面给予 +1 鼓励。 需要投稿的朋友有疑问可以在下方留言，编辑会尽快与您联系！
微信扫一扫打赏
支付宝扫一扫打赏
