购物车是每个商城类的app必备的实现功能,然而购物车模块实现起来并不简单,需要考虑的地方也比较多,当初我实现起来也是一头雾水,随便翻了一下网上资料,也没有一个详细的实现思路,本着分享的精神,在此把我当初实现购物车模块的思路和细节在这里分享交流一下,另外也希望大家将可以优化的地方提出
1.需求分析:
购物车的模块其实可以按照用户行为去将需求拆解,用户使用购物车可以分解成如下几个情况
未登录状态下:
1)添加购物车(本地存储购物车列表)
2)查看购物车(购物车列表恢复)
3)修改购物车商品的购买数量(修改购物车列表)
4)删除购物车商品种类(删除一条或多条内容)
登录状态下:
1)登录瞬间购物车认领(将本地购物车列表与服务器同步)
2)添加购物车(与服务器同步)
3)查看购物车(服务器获取购物车列表并与本地同步)
4)修改购物车商品的购买数量(与服务器同步)
5)删除购物车(与服务器同步)
好了,将需求拆解成上述的情况之后,大致的思路也差不多有了,购物车一个最基本的功能就是将数据本地持久化,这必然要涉及到数据库的操作,既然涉及到数据库,那么就有两种方法可以选则了,一个是coredata,另一个是fmdb,其实两种都可以,本人当初选择了fmdb
由于当时看了一下唐巧大神分享的fmdb封装的第三方,本着尝(tou)试(lan)的心态决定用他的第三方,但是后面才发现和自己项目需求有点不合适,在做一些优化时候也费了点劲,因此建议大家,如果用fmdb的话,还是找一个只做了简单封装的第三方来用就好了。
2.代码实现
好了,废话不多说,在实现购物车模块之前,还要先定好表结构,至于表结构要怎么定,这里没有一个固定的套路,主要还是看后台哥哥的数据怎么定,这里就分享一下本人项目中商品model以及思路
第一步,直观反映商品与要购买的数量关系,因此我选择商品id-数量 这样的key-value形式建表,并且以商品id作为主键,方便后续针对某一件商品单独修改其数量
第二步,将商品描述的副属性打包装进一个字段中,因为在购物车操作中,最核心的内容只需要关注一件商品及其对应的正确数量即可,至于其他属性,只是为了显示作用,故可以全部弄进一个字段中
最终,表结构就是如下 {100456 : {"num" :1,"description":{img:"www.baidu.com","type" : 1 ......} },100478:......}
v1.0
购物车是贯穿整个app的核心模块,必然需要一个单例去维护,在我的项目中,我是在useraccount的单例中增加一个购物车列表属性去维护,其中需要准备的方法有:
1.初始化购物车(init)
2.添加购物车(add)
3.刷新购物车(refresh)
4.删除购物车(delete)
5.清空购物车(remove)
初始化购物车
初始化购物车又分为登录状态以及未登录状态两种情况,未登录状态直接读取本地数据库,然后将商品模型添加到单例的购物车数组即可, 而登录状态下,则需要先用本地数据库,然后等待网络接口数据回来后刷新一遍本地数据库,然后再清空单例的购物车数组,再把新的购物车列表数据加入到购物车数组中(这么繁琐实际上也是为了用户体验,当用户网络不好的情况下,进入购物车中,还可以看到他上一次关掉app时候的购物车数据)
添加购物车
添加购物车同样分为两种情况,未登录状态下只需要给本地数据库写入一条即可,登录状态下,则需要写入本地之后向服务器发送同步数据
这里有一个判断,如果添加购物车发现已经有该商品了,则应该调用刷新购物车的方法
刷新购物车
当增加或者减少购物车数量时,需要根据商品id取出数据,然后将更改后的数量替换回去,如果是登录状态下,还需要和服务器同步数据
删除购物车
把数据库对应的商品id的数据删除掉,登录状态下需要和服务器同步数据
清空购物车
这个最简单了,清空整张表,登录状态下需要和服务器同步数据
当将以上方法都写完之后,剩下的就是简单的调用方法了,初始化购物车在启动的时候会调用一次(为了显示购物车的角标),然后会在进入购物车的时候再调用一次
添加购物车会在每次添加购物车的时候都调用一次
至于刷新购物车和删除购物车,则会在购物车界面下,对商品对应操作的时候调用
而清空购物车则会在帐号登出以及结算成功的时候会调用
至于购物车认领,这个操作稍微复杂一点点,实际上就是登录之后从服务器获取的列表,然后遍历列表调用添加购物车的方法一件一件加入到购物车去
以上就是购物车v1.0版本的思路整理
3.细节优化(购物车2.0)
在实际应用中,遇到了几个问题
一个是购物车中商品数量太多的情况下,进入购物车以及删除购物中的商品会造成卡顿,这个原因是因为我在refresh的方法中修改购物车列表是整张表取出来,修改其中一行,然后再整张表存回数据库中,这过程会造成性能消耗,本人也是偷懒,直接使用fmdb的事务,并且将修改的操作放进子线程中进行,这样一来,用户就不会感觉到卡顿(实际上性能并没有优化)
一个是购物流程优化,由于一开始的设计,太多地方是需要等待网络回调才能进行下一步操作,在网络不畅顺的环境下,消费的过程会变得十分长,十分影响用户的付费冲动,甚至会有一些商品做了加入到购物车的操作,由于网络延迟,进入到购物车界面获取的列表还是没有该商品的情况,针对这种情况,也是做了一个优化,以本地数据为主,网络数据回调只是作为校验的数据,服务器返回的数据只用来校准商品的描述,图片,期号等等无关重要的副属性,这么一来用户在支付之前的操作都会变得十分畅顺,可以更快的让用户进入支付等待的环节
网友评论