购物车是每个商城类的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的事务，并且将修改的操作放进子线程中进行，这样一来，用户就不会感觉到卡顿（实际上性能并没有优化）
一个是购物流程优化，由于一开始的设计，太多地方是需要等待网络回调才能进行下一步操作，在网络不畅顺的环境下，消费的过程会变得十分长，十分影响用户的付费冲动，甚至会有一些商品做了加入到购物车的操作，由于网络延迟，进入到购物车界面获取的列表还是没有该商品的情况，针对这种情况，也是做了一个优化，以本地数据为主，网络数据回调只是作为校验的数据，服务器返回的数据只用来校准商品的描述，图片，期号等等无关重要的副属性，这么一来用户在支付之前的操作都会变得十分畅顺，可以更快的让用户进入支付等待的环节
