APP开发两年的心得：App代码架构设计(1)

这篇文章全程文字，不带图，不带电影。但真的有可能给你带来不同的视角；要认真看！

还有不对的地方留言评论。也但愿多评论留下你的见解，这也许能帮助到我。感谢

前言

工做两年，一直都是从事App开发方面，作过原生App，混合App，公众号，小程序也偶尔写一下简单的后台接口。在开发一个App的过程当中，开发原生以及混合的方式有很大不一样。 在原生（java）的时候常常会尽力的去构想如何构建基类，如何抽象。代码的分层分类都井井有理的感受。而在混合开发（前端代码）中，对封装，基类，类等等的构思十分少，仅仅是作一些相似工具类的封装。我本来觉得前端是不支持继承多态之类的，但没想到我错了，这仅仅是由于我不会而已。

看完能学到什么？

这里没有具体的代码，有的仅仅是本身这两年接触的项目总结，从架构的角度尽可能去思考。 不管哪一种开发形式，原生App，混合App，公众号，小程序，网站等等在开发前都应该先有对总体的设计。

博主小白的见解 框架设计是从上到下去思考，而实现代码是由下往上去实现。 举个例子，当你要去完成一个开发App的项目的时候。每每需求都不是那么的明确，总有那么一些不明确，可能被修改的点。而框架的作法就是把这些问题都抽象起来，避免具体实现；也就是说构思框架的时候不要跟业务扯上关系；不过一样有说法就是，不考虑业务的框架都是shit。这也对，总之见仁见智。

开始作一个项目以前应该要考虑的事情：

因此我在刚开始思考的是：

1. 总体框架搭建
2. 结合业务需求进行技术选型

总体框架搭建：

APP交互分层：MVC / MVP / MVVM；最总体的代码分层，各层之间的关系。 例如MVP在其中再细分层： M：

• core(核心实体类)
• domain(app辅助实体交互类)
• func(业务类)

V:

• activity/page
• fragment/component

P:

• presenter

通常我会新建一层与MVP同级别的，O(other)；这一层是辅助MVP可以顺利工做的。可以让MVP可以更加专心作本身只关心的是。 O:

• base (存放base类的定义)；
• constant（全局常量定义）
• util（工具类相关）
• http（网络相关）
• sql（数据库相关）
• imageLoader（图片相关）
• toast（）
• dialog（）
• ...

这里有不少人会有疑问，为何toast，dialog都要做为一层？直接Toast.show这样不就行了吗？其实也行，功能照样可以实现。不过你把他定义为toast到外层，每一个须要弹toast的找他。若是你的app不少地方都能作到这样的话，那说明会是一个很不错的点。譬如，你的项目经理说：那个toast有点丑，能不能把背景颜色改一改啊？只是后你就知道这样统一的出口是多么重要了，而不是散落在各个地方。触类旁通...很重要

构建基类： 也就是base类的建设， BaseApplication、BaseActivity、BaseView、BasePresenter、BaseModel、BaseMvpView.... 等等。对于基类的建设有一点要注意的是，真的只放最通用的行为在里面。不要为了贪图方便而把一些基类不该该作的事情强迫基类去作，否则基类不变成gay类了。或者是这些动做不该该是该类或者该方法去作的，却为了方便贪图一时酒池肉林而纵容本身写下这该死的代码。

案例1：

BasePresenter，以及BaseMvpPresenter。BasePresenter只放最基本的，而在MVP模式中每每须要针对MVP模式区构建一个更加适用的Presenter，好多同窗会把这些功能写到BasePresenter中去；这真的不太好。咱们要新增BaseMvpPresenter去继承BasePresenter再完成BaseMvpPresenter该作的事情。

案例2：

关于网络请求Http的封装，Http中核心方法，request()这个方法是真正发起请求的，那么就让他只作这些如何发起请求相关的事情吧，至于后面须要控制个loading显示与否；就不要让这个方法去控制了；又或者说组装参数什么的...乱起八糟的事情就不要让人家去作，真的很烦大家这样。否则到时候改个loading的控制以后,"咦，怎么喔的传参穿错了？不可能啊根本没动过这个代码...".触类旁通...很重要。。 这个话题不只仅是针对构建基类的了，而是从框架分层--->类--->方法；都要保持这样的底线。这样满满培养好的习惯，到之后接手别人代码的时候你就会想打人了，这个时候也说明你真的很不错。

结合业务需求进行技术选型

而后就是结合业务需求去进行技术选型，像图片加载的框架呀，网络请求框架呀。其实这些我我的大多都是喜欢哪一个用哪一个！！！ 最基本的网络请求框架：okhttp，retrofit，volley这几个确定要知道他们之间的优缺点差别的...不须要都会用，可是要清楚他们的优缺点，能知道用这个能作哪些不能作哪些基本就能够了，这根本不影响单手敲代码的速度。

差很少能够进入真正敲代码的阶段了！！！ 敬请收看下一篇：

虽然只有两年的开发经验，在一些大牛眼里看来可能以为对框架设计怎么可能有什么看法；你说对了，但每一个开发者都会经历的过程，从撸代码到思考设计。我是小白，但有一些比我更白的人他们有时可能会更愿意看到通常白的人是怎么开发的？由于更符合实际，哈哈哈。