项目的框架搭建，是项目必须完成的一项重要工作。框架——我们可以理解为项目开发的一个模板，该模板的质量高低将直接影响后面项目开发的质量与进度。模板定型之后，业务层面的开发基本上是依葫芦画瓢，填充逻辑、功能和数据，未开发带来极大的便利。那么框架搭建包含哪些工作内容呢？

A、先说框架搭建和通用UI的封装和测试：

1、正对不同状态和结果的展示：主要是网络请求过程及结果这块，通常包含请求过程和请求结果两大部分，其中请求结果又分成功和失败两个，失败里面又分很多种。每一种状态都需要考虑并且每种状态时的后续操作选项，比如：请求过程中是否允许进行其他操作，比如点击事件、交互编辑等，请求失败时提示点击重新加载等。我们可以考虑将展示分以下几种场景：一是定制专门的UI来展示结果，二是通过Dialog来提示，三是用Toast提示，或者三者组合使用。这部分直接关系到全局的交互动效的工作，需要在项目初期框架搭建时结合需求、UI、后台提前封装完成，方便后面调用。否则，事到临头各种风格的封装，一点也不统一，就等着头疼吧。另外针对全局通用的场景，还应配合网络框架来处理调度。

2、列表页的Adapter/ViewHolder的通用适配、点击效果、界面刷新效果、item的顶吸效果等。

3、供用户选择的列表弹窗样式，这部分实现方式很多，通常有三种：Dialog、PopupWindow、悬浮型的Activity；三者结合回调、项目全局弹窗样式进行封装。

4、防止重复点击，即在短时间内，防止用户多次点击某个View产生某种交互，重复调用接口、重复提交造成逻辑异常。特别是金融类App最重视这块。

5、界面间的交互动效。交互动效可以极大地增强App的体验，让生硬的交互变得富有活力，让人爱不释手。

6、通用的时间选择器。

7、各种形状的ImageView，如原形的、圆角的。各种状态的TextView，如内容过多时展示部分内容，点击展开全部等。

8、横竖方向的列表、网格列表、分割线、流式布局框架等。

9、H5与原生的交互、H5对应的WebView的各种属性封装。

10、EditText的各种输入状态的监听与封装，如有输入内容时，在右边显示一个“×”，表示清除或者清空；当输入内容变化时下方的按钮的背景色和可点击事件也跟随变化；当要求输入数字时，输入了小数点开头的内容自动清空输入框；对输入的内容进行正则匹配，如不允许输入表情，只允许输入邮箱类型的，特定样式的密码输入框等等，内容不一而足，这需要根据UI/UE来进行封装=。

B、网络请求框架的封装
当下主流的网络框架非RxJava + Retrofit + OKHttp + Gson + FastJson莫属。另外，网络请求完成后，无论成功还是失败，都应该有对应的回调和后续处理，这里应该结合前面A 1来实现封装。另外还应考虑到未来根据不同的业务需求进行扩展。
同时，还要注意这几种场景：与用户界面有交互动效的网络请求，以及用户感知不到的交互的网络请求，特别是一个逻辑或者功能或者界面要调用多个接口的场景，交互动效最好是不要：启用动效——关闭 ——启用——关闭，这样反复启用和关闭，这样体验很不好。最好是一气呵成，让用户感觉交互的完整性。

另外，我们还应注意到网络这块最可能出现的问题——内存泄漏以及闪退：结果请求回来了，界面关闭了；界面关闭了，但是网络请求还持有某些对象等。

C、控制用户的显示界面：成功显示的内容，失败显示的UI并确定是否提供用户重试请求的加载，请求成功但数据为空时的状态。

D、文本、文件、图片的上传工具封装，以及文件下载工具的封装。

E、异步加载框架、线程间的通讯、线程切换框架：Handler、EventBus、RxJava、Interface等等。

F、屏幕适配，可以参考今日头条方案：今日头条屏幕适配方案终极版 AndroidAutoSize

G、图片管理及加载框架：Glide？Picasso？Frecsco?

H、权限请求框架。

I、三方工具，如第三方登录/分享/推送/日志管理/统计/异常统计等等。

J、数据库？SQLight？GreenDao？Realm？LitePal？

K、Activity的栈管理工具。

L、线程管理工具，Android开发中尽可能的避免直接通过new Thread的方式开启线程，最好是通过线程池的方式来实现。节约资源和开销。

M、各种倒计时显示工具，如最常见的验证码请求倒计时工具。

N、沉侵式状态栏的封装，BaseActivity/Fragment、BaseApplication的封装。

O、架构模式：MVC？MVP？MVVM？

再说技术选型，这一点没有前面部分内容要考虑的那么多，但是却是比前面部分更重要的 。毕竟前面部分搞不不好，顶多是让项目开发进度慢，代码质量不高，不易维护，问题比较多。但是技术选型这块，一个不慎就可能让项目无法继续下去的可能。搞不好还要推到重来，特别是大型项目里面。所以技术选型这块，要慎之又慎。

对于这块儿，笔者以为，除非互联网的领军企业，比如国内的阿里、腾讯、京东、百度、字节跳动等，国外的Google、IBM、Apple Pay等，一般的中小公司，对于重要的项目还是尽可能的选用当下开发街用得最多、最流行、最稳定的技术，除非非用不可；否则尽可能少用非常前沿的技术；或者虽然某些领军互联网使用的很成熟，但是适用范围很窄的技术。这类技术一旦出了问题，比较难迅速的找到解决方案。另外某些领军互联网使用的很成熟但不对外公布的技术，是人家多年开发研究出来的，即便对外提供授权，如果没有一定技术底子的团队钻研，用起来也是跌跌撞撞。用得好是福，用不好就是灾难。毕竟人家数年的研发成果，岂是你段段时日就能够领悟，研究透切的。

之所以选用使用的最多的技术，是因为大家都在用，市场认可的，不易出问题，同时市场上有足够多的的异常解决方案供参考。之所以选用最流行的技术。

同样的道理，能够流行起来并被市场加start的技术，必定是被广大市场开发者接受认可的，，想必不差。

之所以选用最稳定的技术，这点不必多说，谁愿意自己开发的功能，三天两头的出问题，一点也不稳定？而且还是无法预知的问题，莫名其妙的问题。

最新最前沿的技术，或许有其过人之处，但大多是不成熟的，出现异常或故障的可能性很大，可解决方案有限。会给项目带来意想不到的困难。

当然，如果是公司的技术研发团队，则另当别论，毕竟这些团队的主要研究方向就是研究新的技术方案，进行技术攻坚，供本公司项目和别的团队使用。