把商品塞进购物车这个动作，入购在Android上远比点一下按钮复杂。物车我见过太多应用在这个环节翻车——用户点完“加入购物车”，入购界面闪了一下，物车购物车图标上的入购数字没变。再点，物车还是入购没变。用户骂骂咧咧地退出，物车卸载。入购问题出在哪？物车

大部分时候，锅不在UI线程。入购Android的物车点击事件默认跑在主线程，你如果在onClick里直接开网络请求，入购或者查一个没建索引的物车本地数据库，主线程就被卡住了。入购卡到第几帧？大概第3帧开始，用户就能感觉到“没反应”。第10帧，系统可能直接弹ANR对话框。所以第一件事：把写购物车的操作扔到后台线程去。Kotlin协程也好，ExecutorService也罢，别在主线程碰IO。

但后台线程只是起点。真正麻烦的是状态同步。假设你的购物车数据存在本地Room数据库，同时又要跟服务端保持同步。用户在A页面加购，B页面的购物车角标要更新，C页面的“猜你喜欢”可能还要根据购物车内容重新排序。这些页面各自持有自己的ViewModel，谁去通知谁？我见过一个项目用LiveData加MediatorLiveData硬拼，结果出现了“加购后角标显示2，实际购物车里只有1件”的经典bug。后来换成SharedFlow做事件总线，配合repeatOnLifecycle收集，才把状态收敛住。

另一个坑是重复点击。用户手指快，连着戳三下“加入购物车”。你的代码如果没做防抖，就发了三次请求。服务端返回三个成功，本地数据库插了三条记录。购物车里出现三件同样的商品，用户懵了。简单的做法是在点击后立刻禁用按钮，等回调回来再启用。但禁用按钮会闪一下，体验不好。更好的方案是用一个AtomicBoolean标记当前是否有请求在途，在途就直接忽略后续点击。这个标记要放在ViewModel里，不能放Activity——屏幕旋转后Activity重建，标记就丢了。

数据一致性也得盯紧。本地先写还是先发网络？本地先写，用户立刻看到购物车变化，响应快。但如果网络失败，你得回滚。回滚逻辑写不好，就会出现“本地显示已加购，服务端根本没收到”的幽灵商品。我倾向于乐观更新：先写本地，发请求，失败时再删掉本地记录并提示用户。但删除操作要幂等，防止多次失败回调把正常数据也删了。给每条本地记录加一个syncStatus字段，PENDING、SYNCED、FAILED，查购物车时只展示非FAILED的，后台定期重试FAILED的。这套逻辑写下来，代码量不小，但比用户投诉强。

还有个小细节：购物车角标。很多应用用BadgeDrawable或者自定义View，数字变了要刷新。如果你在Fragment里直接持有Activity的引用去改角标，内存泄漏跑不掉。用activityViewModels()共享一个ViewModel，角标逻辑放在Activity里观察ViewModel的cartCount，Fragment只管发事件。这样旋转屏幕、切换Fragment，角标都不会错乱。

最后说个真事。某电商App的Android端，加购成功率比iOS低7个百分点。排查了两周，发现是Android端在加购成功后多查了一次购物车全量数据，这个查询在低端机上耗时超过800毫秒，用户以为没成功就反复点。去掉那次多余查询，成功率就上来了。加购这件事，快比全更重要。用户要的是立刻看到反馈，不是后台把数据整理得漂漂亮亮。