客户端业务搬砖狗的自我修养……
在日常开发中,和后台交互必不可少,比如Feeds流里的消息,需要更新、预加载等等,都需要找后台拉取信息。
那么,向后台发包,请求数据,并处理返回的数据。就是一次CGI请求。当然不同公司和团队,对此定义也不一样,不必纠结。
漫谈CGI请求的那些事
让一条CGI更加可靠,需要考虑的点很多。比如逻辑要放到合适的线程/进程中执行、并发访问兼容、多线程访问兼容、考虑监控耗时、考虑使用合适的存储、考虑用户操作、考虑请求限频、考虑节假日请求量激增问题,考虑在极端场景下,比如后台返回了错误的数据,对客户端的影响要降到最低。简言之,考虑的越周全越好。
作为业务狗,学会归纳与抽象化,对个人能力的提高极为重要,举个最简单的例子,工作一年,可能要写几十条CGI,但是,这些CGI的主流程基本都是一样的,只有归纳整理成通用流程以及方法论,才能轻松应对工作中各式各样的需求,才能切实提高自己的业务水平。
CGI请求常见考虑点
细化一下CGI流程中常见的考虑点。
1. 定义生命周期
一条CGI,或者是某个Action,总会有对应的生命周期。什么时候开始,什么时候结束,什么时候会被中断。想清楚这些,才能更好的管理请求。
2. 发起请求
首先确定要在哪个线程/进程发起,比如子线程发起的话,就可以做一些比较耗时的操作。
限定调用方线程/进程,或者要兼容调用方存在多线程调用的可能。
发请求一定要做好限频,比如两次请求之间,要间隔多少分钟,在请求发起时判断是否满足限频条件,在请求发出后更新最新请求时间。
通常,相同请求,要做好互斥,即上一条请求结束之前,不要发起新的请求。
每一条异常return分支,要打印log方便后续查问题。
发请求之前,根据业务场景增加判断当前网络的逻辑,比如无网络时不发起请求。
3. 请求回包。
确认当前线程/进程,这决定着后续逻辑能否操作UI,能否执行耗时操作。
检查对应的Request是不是自己发起的,只处理自己期望的回包。
检查Response是否正常,错误码、返回数据是否完整。
解析数据,注意空指针,注意后台异常数据,比如用户年龄,肯定不是负数。要做到和后台互不信任,互相检查,保证在后台返回了错误数据的情况下,客户端受到的影响尽量小。
有时候后台会返回下一次请求的间隔时间,记得更新到本地。
更新数据,要考虑耗时,灵活使用子线程。
写DB要处理更新失败的回退、考虑是否需要使用事务。
先更新DB,后更新UI,更新UI要切到主线程。
处理好各种失败的逻辑,比如请求失败、更新DB失败。
请求间隔、数据存储等等,要考虑影响范围,比如影响单个用户、所有用户等等。
考虑在读写DB时,用户也在同时操作UI的情况,比如某个要更新的数据,可能在本次CGI回来之前,用户已经删除了。
统一的原则
根据不同业务,不同场景,需要考虑的问题也有一定的差别,当然,规划与思考是最重要的。考虑的越全面,越不容易被祭天。
当然,从另一个角度上说,这也是属于归纳与抽象化思维的一点应用。