作者:58沈剑 互联网分层架构演进有两条核心原则: (1)让上游更高效的获取与处理数据(复用); (2)让下游能屏蔽数据的获取细节(封装); 数据从数据库缓存层,到微服务层,到站点应用层,最终都汇聚到客户端。服务端的分层架构设计已经讲了很多,客户端的分层架构设计应该怎么玩呢,服务端的分层架构设计是否有能够借鉴的地方呢,今天和大家简单聊一聊。 先来看小诗一首: 《Android猿》 曾经 所有代码 都被写在Activity里 几乎 没有代码 可以复用 每当 看到Activity里 2000行的函数 我就 想要离职 上面,是团队中一个文艺Android程序员的自述,表达的核心观点是:几乎所有代码都写在了Activity里(不理解Activity的,暂且认为是MVC里的view层),完全没有封装和复用。 假设一个具体的例子,微信登录的界面,点击登录按钮,此时可能要执行: (1)验证用户名密码; (2)拉取好友列表; (3)拉取用户信息; (4)拉取好友信息; (5)拉取离线消息; (6)。。。 画外音:那个大月亮的画面,要卡很久。 如果把这些都写在微信登录Activity里,会发现一些很严重的问题: (1)登录整个逻辑不能复用; (2)登录过程中的每个子逻辑也无法复用; 假设产品里有一个离线后重新登录的功能,步骤与登录相同,就需要把上述在重新登录Activity里代码复制一遍。 又假设产品里有一个地方需要拉取用户信息,也将把登录Activity里拉取用户信息的代码复制一遍。 封装复用的道理谁都懂,拷贝代码的坏处也谁都明白,那为什么大家还这么做,代码越来越腐烂呢? 根据个人经验,主要是这么几点原因: (1)早期业务压力大,APP是少数几个同学的,没有提前做规划; (2)后期代码越来越臃肿,不敢动,一动怕影响功能,怕出问题,怕担责任; (3)项目中,是以功能界面进行编码划分的,一个同学会同时负责MVC三部分编码,加之项目压力又大,既然是一个人写,就没必要分层了,搞多了调用反而麻烦; (4)项目中,有个需求好像之前做过,代码一看,写在Activity里,纠结。抽象成函数?还得改别人的代码,算了,还是拷贝一份吧; (5) 不管历史原因,项目原因,个人的原因,大家都知道分层抽象,代码复用是正确的,那有什么方案能够将这个分层抽象落地,从后端的分层架构中是否有可借鉴的地方呢? 一个典型业务系统的后端架构如上: (1)webserver层调用RPC接口,从service层获取数据,拼装htmljson,完成数据展现; (2)bizservicedataservice向上游提供可复用的原子接口,实现业务逻辑,并通过DAO层,从db层获取数据; (3)db层提供数据; APP端的分层架构不是非常相似么? 还是以登录业务为例: (1)登录Activity有两个按钮,一个确认按钮,一个取消按钮,这两个按钮的点击,分别只能调用一个函数: onLoginConfirmClick onLoginCancelClick 这里相当于展现层,除了交互与展现,View层只能调用这两个函数。 (2)这两个函数的实现,是通过若干可复用的原子业务逻辑函数实现的: 验证用户名密码:boolverifyPass(name,pass) 拉取好友列表:ListgetFriendList(uid) 拉取用户信息:UsergetUserInfo(uid) 拉取好友信息:ListgetUserInfo(List) 拉取离线消息:ListgetOfflineMst(uid) 这相当于服务层,实现业务逻辑,提供封装和复用 (3)原子业务逻辑函数执行的过程中,需要访问数据,数据的获取又分为两类: 同步获取:通过文件,内存,本地数据库获取 异步获取:从server获取,往往通过回调实现 这里相当于数据层,向上游屏蔽数据获取的复杂性,分别用不同的Proxy去实现。 在这种结构下: (1)展现层非常轻,只调用一个函数,用于展现数据; (2)原子业务逻辑可以复用,不同的展现层Activity可以随意组合,实现不同的业务逻辑,用于处理数据; (3)Proxy对上游屏蔽的数据获取的复杂性,向上游提供数据获取接口,用于获取数据; 分层架构封装复用的思想,前后端有共通的地方。 Activity里一坨坨复杂的代码,也是你曾经的痛么? 最后 在这里就还分享一份由大佬亲自收录整理的Android学习PDF架构视频面试文档源码笔记,高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理,帮助大家在未来取得一份不错的答卷。 当然,你也可以拿去查漏补缺,提升自身的竞争力。 真心希望可以帮助到大家,Android路漫漫,共勉! 如果你有需要的话,只需私信我【进阶】即可获取