1、电商发展初期，SKU数量较少，而用户需求一般来讲是一个恒定量，这种情况下，较少的SKU无法起到很好地满足用户需求和带动用户需求提升的作用。
2、电商发展初期，由于对新生事物信任感的缺失，网购人数及频率较少，客单量也较少，用户倾向于立即购买。
3、电商初期无法解决合并支付带来的拆单后货款的分配问题等（主要表现在平台型电商）
随着互联网电子商务行业的发展，目前，各大电商平台都已经引入了购物车这个概念。
我们首先看下移动端电商产品中购物车的作用。
·收藏
对于用户来讲，购物车首先发挥的是收藏的作用，相对于[收藏夹]来说，购物车在收藏属性上应该是一个“弱收藏强购买属性”（购物过程中有比较强烈的购买倾向），而收藏夹则是一个“强收藏弱购买属性”（比如我看重一款鞋子，但这款鞋子没有适合我的尺码，所以我不能加入购物车（加入购物车需要填写尺码）只有收藏下来等到有合适尺码再来买）。因此，购物车展示的商品以SKU形式显示，而收藏夹以SPU显示。
·筛选
由收藏带来的筛选，对于用户来讲，在面对海量的商品资源的情况下，对意向的商品加入购物车，利于快捷的对不同商品的横向对比，提高用户购物决策的效率。
·凑单
凑单下包含两种情况，一是用户本身需求较多，需要一次性支付，提高购物效率；另一方面是一个随机性的购物需求的增加（冲动消费），这个主要是基于商品优惠活动的影响（主要指范围促销，比如满减，满赠，满返等）。
对于产品方来讲，促销是购物车的主要目的，而促销一般包括两种类型：单品促销和范围促销。
单品促销是指对单个商品的优惠促销活动，比如打折，赠品等；这种促销一般在单个商品详情页用户即可得知最终的优惠情况，购物车只是作为一个补充说明。
范围促销是指多多个商品的优惠促销活动，比如满减、满赠、满返；而这种促销一般由于门槛较高（比如满100减10，满500返100等），一方面商品单价往往不能cover所有的优惠另一方面单个商品详情页只指出优惠规则，因此在单个商品详情页用户并不能明确最终的优惠情况，需要购物车做一个合并最终得出优惠情况。
而以上两种促销的目的都是为了提高客单价，以提升销售额。
前面讲到，购物车对于用户来讲最重要的是收藏作用，因此用户放在购物车的商品就可以作为用户的“个性化数据之一”，产品可以根据该数据对用户做个性化推荐。因此，一般在购物车的下方，都会有“看了又看”“大家都在看”这样的推荐。而在此值得说的是，前者是基于用户的个性化数据做的推荐（也就是用户有收藏、加入购物车等行为）；而后者是在未掌握用户个性化数据下做的推荐，这种推荐一般来源于商品的热度（大家都在看，都收藏或加入购物车）；运营需求（商品上新；库存紧张等）。
从用户在电商平台的使用流程来看：打开App——选择意向商品——加入购物车——下单——支付——完成。那么在这一过程中，下单环节是一定需要获取用户的详细数据（姓名、收货地等），产品需要明白是哪一个用户下的单，以匹配唯一的订单。而在这前一步，也就是加入购物车环节，是否需要用户登陆后才可使用尼？
在这方面的处理上，不同产品的方法是不一样的：目前主流的电商产品中，除了天猫、淘宝将“登陆”前置的购物车之前，其他的比如京东、苏宁、亚马逊、国美等都将“登陆”后置的用户下单之前，加入购物车之后。那么很显然，后者的用户体验会更佳，因为这时候用户已经有明确且强购物意愿了（可能阿里财大气粗，非要将此环节前置到加入购物车之前）。
那么在这一环节设计上，因为购物车要匹配用户的信息实现购物车的唯一性，因此需要明白的有两点。
第一、用户在无登录状态下加入的购物车和用户登陆后的购物车是两个概念：前者是离线购物车，其匹配的用户信息是设备ID信息，设备ID信息的唯一性带来购物车的唯一性；而后者的购物车属于在线购物车，匹配的是用户的注册登录信息，注册登录信息的唯一性带来在线购物车的唯一性，因此需要用户进行登录。而考虑到用户设备的作弊、更换与丢失等风险，因此，在下单环节需要将离线购物车切换到在线购物车，以获取安全、真实的用户注册登录信息来匹配唯一的订单。（插个话，在这种情况下，如果用户使用设备ID来直接下单购买，是不是具有可行性？恳求指导..）
第二、也就是用户进入下单环节前，需要从离线购物车切换到在线购物车，这时候要同步的有两个：
1）离线购物车的商品同步到在线购物车（否则用户很懵逼）。
2）PC端在线购物车的商品同步到移动端在线购物购物车。
基于用户和产品的需求，在购物车页面的设计上，主要包括两大部分：购物车商品信息流和个性化推荐商品信息流。
由于购物车的商品以SKU形式展示，这就带来的因库存变化、价格调整及促销信息调整等带来的SKU的变化，从而会对用户购买意愿产生影响，那么这方面是怎么解决的尼？
在电商产品中，库存和购物车分别是两个单独的系统存在的。
一方面不同的SKU分布在不同的仓库（天猫或淘宝中的店铺）中，因此购物车需要从库存系统调取SKU所属的仓库信息（天猫或淘宝中的店铺）已备后续的拆单支付。
另一方面购物车中SKU的变化受到库存的影响，因此购物车中SKU需要关联到库存系统。这样以来，在电商前端有三种情况：
1）当可售库存>某个阈值X，前端显示库存充足或者不进行显示。
2）当0<可售库存<某个阈值X，前端显示库存紧张，提高用户的紧迫感和危机感，利于促进转化率的提升。
3）当可售库存=0，前端将所属商品灰置，并提示用户商品已下架。
当然以上是理想化状态，库存的变化是比较复杂的，涉及到何时锁库存以及库存类型（逻辑库存、实时库存、调配库存等）。
同样在电商产品中，促销系统和购物车分别是两个单独的系统存在的，购物车系统可以调用促销系统数据。当用户增删商品数量，商品类型，促销系统会经过计算将其满足的最大优惠反馈到前端，带来最终价格的变化；此外，对于单个商品而言，当出现价格下降时，会在前端显示“已下降XX”，进而促进用户的购买欲望，提高转化率。
想要设计App的整体框架，首先要清楚我们做的是什么
一般我们与网络交互数据的方式有两种：主动请求(http)，长连接推送
结合网络交互数据的方式来说一下我们开发的App的类型和特点：
数据展示类型的App：特点是页面多，需要频繁调用后端接口进行数据交互，以http请求为主；推送模块，IM类型App的IM核心功能以长连接为主，比较看重电量、流量消耗。
手机助手类App：主要着眼于系统API的调用，达到辅助管理系统的目的，网络调用的方式以http为主。
游戏：一般分为游戏引擎和业务逻辑，业务脚本化编写，网络以长连接为主，http为辅。
一般我们做的App都是类型1，简要来说这类app的主要工作就是
把服务端的数据拉下来给用户展示
把用户在客户端修改的数据上传给服务端处理
所以这类App的网络调用相当频繁，而且需要考虑到网络差，没网络等情况下，App的运行，成熟的商业应用的网络调用一般是如下流程：
UI发起请求 - 检查缓存 - 调用网络模块 - 解析返回JSON / 统一处理异常 - JSON对象映射为Java对象 - 缓存 - UI获取数据并展示
这之中可以看到很明显职责划分，即：数据获取；数据管理；数据展示
确定了职责，就可以进入正题了
1. 传统的Android App架构
Android最原生也是最基础的架构，可以理解为MVC，Controller即是Activity和Fragment，但是这两者掌握了Android系统中绝大多数的资源，并且在内部直接控制View，因此传统的Android App一般是以Activity和Fragment为核心，将网络模块，数据库管理模块，文件管理模块，常用工具类等分离成若干工具类包，供Activity和Fragment使用。
这是比较基础的Android项目架构，市面上大部分App都是这种造型
优点：就是开发简单，以页面为导向；如果构建水平可以，项目就已经基本实现模块化，基于Activity，Fragment这这两个上帝般的存在，很多事情直接就妥了，不用绕。
缺点：维护难，因为是以页面为导向的，有些需要共用的业务逻辑就会很烦，don't repeat your self， 你要不要repeat ？不想repeat就要写模块，慢慢的项目就会多出一堆乱七八糟的小模块。另一方面，测试很困难，因为所有的数据处理都在Activity和Fragment，假如现在想先用假数据显示，就要直接改Activity和Fragment的数据控制逻辑。
还有个最恼火的问题，那就是业务复杂起来后Activity和Fragment的代码量激增，举一个例子，电商App的购物车，如果只是管理一下购物车中的商品，无非就是查、删、改调用，列表管理，300多行代码应该就搞定了，假如现在加了个优惠券提示呢？光优惠券不够，还有满减，还有凑单，要计算运费。还要能领取优惠券…… 噢，忘了一般来说还有一个商品推荐，好了现在有两个列表要管理了，你觉得CartActivity 2000行代码能止住么？
在上面这些缺点的描述中，可以看到一个很大的痛点在于：Activity和Fragment不应该管这么多数据处理逻辑
2. 分层架构
如果仔细看自己的项目，可以发现绝大多数数据处理的代码是不需要使用Activity和Fragment持有的资源的（比如Context），而很多时候我们需要多个页面共用一套数据和请求逻辑，很经典的例子是应用中的User对象，一般来说都是全局单例。
这些全局的数据源写多了，很容易就能想到将数据处理统一抽出来形成一层，向上层提供数据接口，而上层并不关心数据的来源（内存，缓存，网络），因为不用从Activity和Fragment拿资源而且主要工作是数据处理，所以这一层是UI无关的，大幅提升了复用性，我把这一层称为DataManager层。
这是我一个项目的包结构
Activity和Fragment剥离了数据处理的责任后，持有DataManager的引用，负责获取数据并展示，向DataManager传递数据，绝不进行网络请求和缓存读写。
基于Android的牙齿健康科普App设计与开发简析国民生活品质不断提升,越来越多的国人开始关注自己的口腔健康，且我国儿童患龋情况已呈上升状态, 中年人牙周健康状况仍有待提升。为了增强大众口腔健康意识, 自发关注牙齿护理,文章介绍的是一款牙疾病科普类App。
一、App的设计与开发
1、总体设计
本App采用 C/S (客户端/服务器)架构 ,基于 Java 语言开发 ,运行于Android平台上。客户端主要基于 Android Studio 平 台 开 发 , 服 务 器 端 采 用 MySQL 与 Android 相连接 ,进行数据存储和处理。
2、界面设计
利用Axure RP进行App全界面设计,配色方面具有强烈的秩序性 ,以白、蓝为主色调 ,关注界面中控件、字体及图标 ,使界面协调、细致 。设计前 ,本团队在用户角度设问“用户能够干什么?”,解决了诸如此类的问题,再持续性挖掘用户更深层次的需求。
3、数据库设计
对于数据库的设计,本设计建立了6张数据表，共36个属性字段 ,继而整理完成数据字典。
4、功能开发
App的功能较为完善 ,包括牙齿健康知识科普、口腔保健用品销售、牙齿自检问卷、社区交流等 。本团队选择移动端而非PC端进行设计 ,大大提高了用户使用的智能性和便利性。在兼顾便捷性的同时,也更注重用户的使用安全,用户登录时除输入用户名和密码外,还设置了图片验证码 ,防止机器人程序恶意破解。
二、模块设计
1、科普视频模块的设计
科普类视频播放通常由两种方式实现 。第一种方式即通过 MediaPlayer 与 SurfaceView 相结合的模式进行播放 ,使用 MediaPlayer 控制视频的播放、暂停、进度等功能 ,使用 SurfaceView 显示视频内容 。此方法虽然灵活性高 ,方便自定义使用 ,但难度比较大。本系统使用 第 二 种 方 法 , 即 通 过 继 承 SurfaceView 类 , 使 用 VideoView 进行视频播放 。MediaPlayerController 接 口 可以控制媒体播放 ,另外在 VideoView 上还有一个面板用于对媒体播放进行控制 ,可以快捷使用快进、快退、 播放、暂停等按钮。
2、购物车模块的设计
用户点击进入商城 ,可以查看商品、搜索商品并且购买。对于商城购物车结算功能 ,本团队尝试了两种方式 :(1)通过 LinearLayout 嵌套 LinearLayout 实现 ,但这种方式在数据过多时会造成页面卡顿。(2)通过 ExpandableListView 实 现 购 物 车 分 店 铺 功 能 , 由 于 ExpandableListView 是系统原生控件 ,因此由系统底层 维护并提供了更多的方法供本团队使用 , *** 作简单、页面流畅且代码量较前一种小了很多。实际开发中，本设计仍然用 ScrollView 嵌套 ExpandableListView 控件保证页面的正常滑动。本设计主要使用 onItemClick( ) 函数选 中 结 算 物 品 , sumPrice ( ) 函 数 计 算 商 品 价 格 总和。
3、牙齿健康知识科普模块的设计
针对牙齿健康知识科普,本团队推送大量的科普视频和护牙小知识,用户可选择各种牙疾病的相关介绍并查看注意事项。在口腔保健用品销售模块中,用户可查看相关的口腔用品并购买。本团队通过调查牙齿护理的相关知识 ,设计牙齿自检问卷 , 可供用户定期评估牙齿健康 ,例如“龋齿占牙齿的比例”“牙龈出血次数”等常见口腔问题皆有涉及。
4、社区模块的设计
社区为用户推送热门的牙齿健康话题、热门的用户动态以及热门的牙齿专题,展示用户关注的好友发布的动态信息 ,用户具有点赞、关注和评论的权利。同时,用户也可以搜索自己感兴趣的话题或其他用户。系统根据用户的爱好为他推荐他可能感兴趣的好友 ,并且推荐点赞和分享综合性较高的用户。
在研究阶段 ,本团队查阅大量资料 ,进行初步分析,通过对口腔 健康知识科普类 App 用户的需求进行剖析 ,综合分析界面设计、交互开发、功能设计等多个方面 ,对设计目的、设计理念全面梳理后 ,完成 App 开发。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）