心得：XHB项目

作为一个Android菜鸟，跟着老大做Android项目，从立项到上线，从架构到实现，从懵懂到掌握，在这里我总结一下在此项目中和收获、遇到的问题和解决办法

1、首先一个项目最重要的两个点就是需求和架构。需求搞不懂做的再多也是枉然，架构没设计好，之后遇到问题想改会遇到很多问题会牵扯到很多东西。需求和架构这两点没搞精通以后修改问题都是整个项目级别的。

2、需求要看实际项目来定，一般产品都会理解的比较通透。在做项目的工程中，需求改变是经常的事儿，产品经常会给你提新的问题新的设计。因为产品可能听Boss一嘴听总监一语，然后新的设计就来了。这时候我们码农再接受更好的设计的同时，我更建议并不是什么都要听产品的，因为经常因产品提的一点点的小细节需求，我们的代码结构就会被影响，影响代码的一致性和通读性，这儿做点特殊处理那儿做点特殊处理，一点点一点点我们的代码就会被腐蚀，失去整体的一致性和规范性，阅读起来就会非常反感。在这里我更建议在一开始产品或者架构师就设计好我们的逻辑规范等等，到时候我们也会有据可循，而且这些都一致了之后，用户也会习惯这种设计，也不会影响用户的使用体验。为了用户体验更棒一点，偶尔的特殊处理也不会特影响代码的结构。

3、架构设计一定要低耦合。整个项目的模块可以大致分为以下几个：

• 网络层：访问网络的底层实现，只暴露给上层接口方法。上层只管调用，网络层只需要放回该返回的数据(注意：而不一定是上层需要的数据)。将来如果有更好的网络架构我们完全可以在不变上层调用的前提下替换掉整个网络实现。一个强大的可满足上层各种需求的网络层也需要好好设计，对错误的统一接口的定义与处理，网络请求机制的定义（cookie、网络重新请求的机制、是否有cancel 机制等等），以怎样的方式暴露给用户接口（是否需要有统一的ServerAPI接口类，这样的话不同级别版本的app完全可以用一套最完整的接口，只需选择性的暴露就好）
• 数据层：用来存储各种数据的数据结构的定义。
• 通用控件层：一些常用的自定义的控件，提出来方便之后的复用
• 第三方sdk：引入的第三方sdk
• utilities工具层：用到的一些工具类似的方法，把他们都放到这里。这是一种将不相关代码统一管理的一种方法，不会将一些和业务逻辑不相关的代码写到某个Activity或Fragment中。而且，这也是一种积累，以后找工具类直接去里面拿就可以了。

4、在我们主要的app模块，代码结构一定要保证一致，例如先写生命周期方法再写初始化方法，再写刷新的方法和加载数据的方法，这样代码读起来方便并对整个Activity中方法的调用也会有比较快速的了解，而不会因为方法过多而理不清方法之间的调用关系。

5、两个提高点：第一，所有的数据请求不管是否是访问网络的请求，都统一使用异步方法来请求和设置数据。第二，业务逻辑与权限判断分离。我们之前可以通过一个AccountAction来统一处理权限的判断和截断，但是这也只能做到在入口处进行检验，而登录进去之后，token失效，这时候再操作应该让其重新登录的，而这种处理就不容易实现，而且超级麻烦。现在使用AOP面向切面编程的思想，使用AspectJ向代码中注入切点，拦截请求，判断权限，就能比较轻松的实现业务逻辑与权限判断分离。当然在实际的实现中也会遇到一些问题，结合技术文档和我们的编程经验和现有的技术一定是可以解决掉问题的。