Android开发架构的一些思考

App架构和重写的一些思考

    做了很长时间的的Android，也学了不少的技术，知识点，但是知道自己对于Android架构和面向对象的思想还是很缺少。之前学过一些JavaEE开发的东西，学习过程大牛们总是对于开发的架构分的很细很有层次，代码结构清晰，明白。我们在大学初期学习javaWeb，自己做项目的时候就是代码全部写在Servlet中，不管是数据Bean，数据库操作，还是逻辑处理。最后真的搞成了一锅粥。最后时间长了学的东西多了才明白了javaWeb也是分层处理，Dao、Service、Servlet不同的层负责不同的功能，代码逻辑清晰明了，所以一直在想，Android中怎么才能写成这种清晰的效果来。

1.数据模型层（javaBean 接口数据）

    一般我们的数据现在都采用json格式，json有六种数据格式，number，String，boolean，Array，Object，null。

数据模型层是一个基础的东西，分装了接口的数据和数据库对应的数据。由于大部分是接口的数据，因此我们的属性也要和接口传回的对应。和后台交流，了解数据格式，对数据模型做一个统一的处理。比如我们的api请求返回的数据可能都包含有一个请求码resultCode，一个结果信息msg，还有可能包含数据的页数pageSize，总也是maxPage等。除此外的数据要么是一个对象要么就是一个集合，因此我们用一个泛型表示对象和集合，这样就可以定义一个ApiResponse泛型类，方便后续的数据模型处理了。

2.api接口封装（接口层）

         刚开始写程序我们没有经验，总是想到什么就写什么。这就是我们的程序乱成一团的原因吧。有经验者开始的时候总是想划分层次，进行一些封装等。前几天看了一篇文章，作者对这个过程做了一些说明。

         Api封装，通过接口将业务用到的接口api进行处理，定义出一些规则，主要是把api的业务方法，常量等做些定义。然后实现类去实现api的方法，api的实现类就是ApiImpl类。实现类需要封装好请求参数并向服务器发起请求。将结果转换为ApiResponse返回。向服务器发送请求的处理封装成Http引擎类处理。这里有一点说明，假如我们采用Http等请求网络，这个地方的http请求只是完成了请求操作，没有添加请求的异步，多线程，需要在核心层处理。

3.业务层封装（核心层）

     核心层处于接口层和界面层之间，向下调用API，向上提供Action给界面调用。核心任务就是处理复杂的业务逻辑。

Action核心层定义：

         Action接口的定义，Action接口定义业务中需要的方法，只是处理业务的一些数据和参数。

比如：我们在接口层中可能需要一些手机型号参数，请求的页码参数等。这些跟界面没有直接关系，Action只定义和界面相关的就可以了。其他需要的参数在具体实现的时候再去获取。

         Action的处理基本都是一部的，因此在这里我们在方法的调用上添加回调监听器，根据返回的结果对回调进行赋值，回调中定义了两个方式，onSuccess和onFailure。回调监听器的泛型则是返回的对象数据类型，如获取的工单数据，商品数据，返回就是一个List，没有数据就返回void。（此处使用了AsyncTask进行异步处理）

最后定义类实现Action接口中的方法。实现类中定义需要的一些常量数据，比如页码，数据量大小，手机硬件参数等。这里需要调用Api去请求网络。

Action实现类中，主要操作有两步：

        第一：对将要使用的参数进行合法验证，如是否为空，手机号码是否合法等，不合法直接在回调的接口中返回失败的参数，提供给界面处理。这个验证也是对服务器的一个缓解操作，我们在只有数据合法的时候才请求服务器，减少服务器的请求次数。

    第二：参数验证合法后，采用异步方式api接口方式请求访问网络。对于所有的请求处理都是这样进行。这个就相当于JavaWeb中Servlet层处理的一样，首先验证参数，然后调用Service层的方法处理业务。

    这里要说明的就是我们可以进一步分装。例如对参数验证的方法，进行抽取，封装成类工具。对异步任务进行处理，简化调用等。还有一些其他处理，比如添加换缓存就在api调用前处理。

        刚开始这样封装还不习惯，但是从上面的这个登录注册的验证我们也能看出一些方便来。在举例说一下，比如说我们直接登录和注册成功后到首页这两个登录方式。我们在业务层封装了逻辑，在直接登录或者注册后调用登录的时候直接创建对象传参数判断状态即可，不需要多处写登录逻辑。

        上面的这些写法其实和javaWeb中的思路就很像了，一个Dao，一个Service和一个Servlet，Dao负责数据库的交互操作，Service负责业务的实现，调用Dao层的数据库方法，最后Servlet调用Service层的方法，Servlet中对数据的合法性等逻辑进行处理。所以上面的处理，我们完全可以按照这个思路去理解。总的来说就是为了对代码解耦，提高代码的可读性。减少一个地方的改动对其他地方形成的影响。

4.界面层（activity层）

       界面层需要注意三个原则：

       保持规范性：定义好开发规范，包括书写规范，命名规范，注释规范，开发过程按照规范严格执行。

       保持单一性：布局就只做布局，内容就只做内容，各自分离好，类和方法也是，处理任务要单一。

       保持简介性：保持代码和结构的简介，每个方法，每个类，每个包，每个文件都不要塞过多的资源和代码。多了就要想办法拆分。

    界面层的逻辑，业务处理要调用Action层的方法，而且在整个应用级别都会用到，因此最好放到Application中。Activity的一个基类也是必要的，把一些共同的东西放在基类中，如Action的对象。对话框处理，进度条的处理等。这样会简化其他子类Acitivity的代码。用到适配器Adapter也是一样的操作，定义一个基类的Adpater，把共同的方式写在基类中实现，对于Adapter更新数据，等操作也在基类中完成了。让子类的适配器Adpter更简洁一些。

5.其他的一些封装

         前面的部分结合看到的文章大概总结了对于整体架构的一些思路，主要是在项目的整体把握上。下面结合最近学习思考，对于一些基础类和工具的封装做一个简答的记录。

之前的项目大都是别人做了架构，我参与其中开发。这一年来自己单独做了两个产品，也有了一些自己的想法，上面是对自己将来代码的架构优化的一个方向的总结。

         刚开始写代码总是遇到什么就写什么，没有一个整体的概念。我们可能都这样写过，就比如一个加载进度条可能在遇到的时候就去写一个，最后每个Activity都写了一个。重复 了太多的无用代码。以后的项目我们也可以提前考虑，做一些封装。BaseActivity、BaseFragment处理一些公用的东西，如处理toolbar，空视图，异常信息提示视图，沉浸式等。也可以对如我们常用的onCreate()进行功能拆分，把初始化View，绑定数据、加载布局分开在不同的方法中写，然后子类中再去重写这几个方法，保证了方法的单一性，也让代码看起来简介，不用再一个onCreate方法中写所有的处理逻辑。对于加载进度我们单独写一个LoadingProgressBar工具类，在BaseActivity中或者在需要使用的地方直接调用即可，不再写许多无用的代码，也能保证将来修改的时候不会修改多个地方。这里突然想到，其实MVP模式中抽取的接口，也是一个面向接口编程的体现吧，总的说减小代码的耦合。

参考：http://keeganlee.me/post/android/20150629
小刚的架构思考，以及代码demo