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

还有不对的地方留言评论。也希望多评论留下你的看法，这也许能帮助到我。感谢

前言

工作两年，一直都是从事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这几个肯定要知道他们之间的优缺点差异的...不需要都会用，但是要清楚他们的优缺点，能知道用这个能做哪些不能做哪些基本就可以了，这根本不影响单手敲代码的速度。

差不多可以进入真正敲代码的阶段了！！！ 敬请收看下一篇：

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