需要经过
需求分析 -> 功能分析 -> 用户流程分析 -> 非功能需求分析 -> 架构层次分析
-> UI设计 -> 数据库设计 -> 模块设计
租赁服装考虑到的因素：
1.租赁价格
2.服装款式
3.卫生状况
4.面料 5.店铺评价
租赁服装时候遇到的困难：
1.款式少，找不到合适的衣服
2.店面太远，不易搬运服装
3.租价太高
4.服装太多，难以挑选；客流量大，环境杂乱无序；
5.尺码不合
6.店主不耐心，服务态度差
关键词：
| 关键词 | 具体困难 | 指导意义 | 技术需求 |
|---|---|---|---|
| 找不到 | 据走访调查，一家20平的店铺，库存都有几千件衣服，所以款式并不是真的少，而是摆放乱，空间小，在限定时间内难以找到 | 让用户在有限时间内尽快的找到心仪的商品 | 1.将租赁商品带必要参数摆上线 2.最基本的关键词法搜索，再利用机器学习相关算法辅助搜索，在一开始摆放商品的时候就想好怎么存放信息可以服务于搜索3.智能推送和产生消息，促进消费 |
| 店面远 | 首先看衣服，因为时间问题，可能就要到场好几次，根据流程，看好衣服还要预定，需要第二天来取，这又要跑一次；租衣服由于时效一般是一天，所以立马又要跑腿去还，把押金要回来 | 店面远这个问题不在APP解决范围内，所以减少或避免或让其他人代劳这个跑腿的过程，是需要注意的 | 1.让顾客在线上选好心仪商品，发出预定看衣服需求，或者直接不试发出订单，只需要跑取和拿两步 2.或者和骑手签订配送协议，但是这样就涉及我们需要引入高德等的地图接口 |
| 租价高 | 垄断，信息不透明，不知道租价为什么这么高 | ||
| 服务差 | 衣服干不干净，穿着体验如何，某些店铺老板服务态度差，店铺环境脏乱 | 需要让用户看到用户反馈，从而对这些老顽固们来一次自底向上的革命，让商家看到用户反馈 | 1.对商家引入用户评价系统，对商品引入用户评价系统，行成类似小社区 |
找不到（问题1和问题4）->一家20平的店铺，库存都有几千件衣服，所以款式并不是真的少
店面远（问题2）
租价高，老板服务态度差（问题3和问题6）
尺码找不到（问题5）->一是借助用户信息反向指导采购，二是采用可视化的预定方式
当然 我们都知道，当体量上升到一定层次后，就会产生新的问题，
所以我们目前假定1000人同时在线浏览产生数据交互的规模来做。
其他APP 是怎么做到 尤其是在服装方面，让用户找到自己最心仪的商品的
1.15
- 小开发团队不重复造轮子，只做轮子的整合工
- MVP程序设计模式 参考MVC思想 模型层 结构层 核心层 界面层
- 能画图就少用话BB processOn协作分工
- WEB端和Android端应该仅仅是展示界面的问题，应该有统一的后台http请求接口，接同一个数据库，保证实时同步，同时一些功能比如商家的 店铺管理和商品管理 可以只做WEB端
-
用户管理
实现用户的注册、用户登录退出、忘记密码、找回密码等功能
**Tips：**这里要涉及到用短信给手机发验证码，第三方账户关联先不引入，再说；同时数据库要有一个专门的表来存储放行；同时从安全性角度出发，密码至少6位，数字和字母混合，字母区分大小写，并且对密码采用MD5加密，并且登录时效性采用 JWT 令牌机制。
-
商品管理
商品的列表展示，点击后商品详情的图文多元化展示，商品多功能排序以及商品收藏，用户可以选择商品的规格参数
**Tips：**商品展示要分页，避免一次取过多导致前端缓存过大；商品的列表展示最好也可以像淘宝一样切换风格；商品的规格参数库存要实时更新；单个商品由哪几项构成自己要清楚，然后必要的可以留给商家自主添加
-
搜索功能
暂时可以先做成基于关键词的 模糊搜索
**Tips：**这个关键词应不仅仅在商品名称内 搜索完毕应该刷新商品界面并显示
-
店铺管理
店铺的列表展示，点击后进入店铺主页面，店铺主页面应留有可供商家编辑的广告，商家经过认证后登录还可以进行货物的增删改查，库存修改等（这点应该做成WEB后台），因此登录部分要把普通用户和商家分开，并且要显示不同的UI和功能
**Tips：**主页面可以尽量简单优化为类似美团，商品+侧边栏导航+必要的图片文字展示即可
-
购物车管理
购物车商品展示，商品编辑包含修改数量、删除商品，显示购物车商品总价值，资金结算
**Tips：**购物车的信息应该保留在前端，只存上一次的信息，但是App退出后，进程退出后，就需要依赖持久化存储，因此单独拿一个表出来做上一次购物车的记录存储
-
订单管理
包括提交订单，最近订单，订单跟踪（应与美团类似，可以调用地图查看货物当前位置），订单评价，历史订单（或说全部订单） 同时留好 待付款，待退款/售后的接口
**Tips：**订单跟踪应与美团类似，可以调用地图查看货物当前位置，这个应该是可以外包给第三方配送平台的，这个不需要我们自己做，我们调用接口 只做展示，甚至展示也不用做，把第三方平台给的网址以短信形式发给用户 如 瑞幸咖啡就是这么和顺丰合作的
-
收货地址管理
新增和删除收货地址，应该和美团类似，可以由地图定位，并根据输入关键字进行匹配
-
支付管理
暂时搁置
-
内容管理
专题 在附近 暂时搁置
-
广告管理
主页面UI留出Banner的位置即可，同时也要学习引导页如何动态加载不同的图片 其他暂时搁置
-
适配
包含设备本身适配，不同安卓系统的适配（深度定制化安卓系统太多了），以及手机端和WEB端的适配
充分测试，出错处理并充分考虑程序崩溃无响应的出口，界面逻辑清晰，操作方便友好等等
上一节适配中也提到了，兼容就是适配，然后在性能要肯定要运行流畅，不会出现闪退、ANR（？？）、内存泄漏（buffer overflow）等问题，主要体现在数据流、图片缓存、列表优化、数据库操作等等方面。
一定把大部分的计算放在前端完成，前后交互只收发包最好
预设应用场景：5000用户，可承受100-300并发访问不卡顿
-
服务端：Android和WEB端，其中商家管理和运行后台管理都放在WEB端
-
服务器：由于是电商服务，比较吃图片，100-300并发访问量下，预估考虑高带宽占用，
4核8G 5M带宽最理想了，当然后面还有更多技术，如果真做大的话，什么集群，负载均衡，异地缓存什么的
-
数据库：暂定Mysql Community Server 充分学习优化技术 必要时可以考虑升级 Mysql Enterprise Server
连接池技术，最大连接数
-
短信服务：阿里云短信服务SMS，用以发送验证码，短信收费，一定是必要验证时发送
-
身份认证：需要一定的计算性能，但是4核应该能Cover这个认证又不是并发的
这玩意需要我们分期来做 MVP 减少代码耦合性，但是做出来的东西要能够复用
1.首页，链接（button 或者组件) 要能跳转进去（信息应该是WEB形式呈现的 这也是为什么做Hybrid应用的原因）
2.搜索界面 和淘宝一致就行
3.备选商品界面（搜索完以后显示的备选商品界面）
4.商品介绍界面（点击商品后弹出的商品详情界面，类似淘宝的服装展示）
5.确认购买/预订界面（确认商品信息界面，可选择加入购物车或者去支付，支付界面暂时先不做）
6.购物车界面
7.商家店铺界面（商家店铺界面，按美团风格来走就行，不必像淘宝那么复杂，每个商家还都有自己的主页什么的）
8.用户个人中心界面，涉及用户管理
9.商家管理界面，涉及店铺管理，监控
10.管理员管理界面，这个会设计引入第三方监控库，到时候再说
这一个工程，也是让我们探索怎么去设计实现一个应用最好的途径
1.接口层封装了服务器提供的API，定义一个请求引擎类，对请求的发送响应结果进行处理，方便给核心层调用。
2.搜索 用关键词找到商家
3.首页信息 要么抓取，要么自己自动生成新闻（这就涉及到机器学习的技术了，但是很明显我们的机器是跑不成机器学习任务的，算力不够，做实验可以
1.根据不同板块的需求，存取数据
三层架构
https://baike.baidu.com/item/%E4%B8%89%E5%B1%82%E6%9E%B6%E6%9E%84/11031448?fr=aladdin
UI层框架：
https://github.com/Tim9Liu9/TimLiu-Android#%E5%87%BA%E5%90%8D%E6%A1%86%E6%9E%B6
图片加载框架 Glide
上面的link 小到button或者menu都有框架 已经很全面了
接口层框架:
模块设计
-
会员模块
实现普通用户注册与登录，实现普通用户个人信息管理，实现普通用户注册短信验证，并留有身份验证接口（如接下来拍摄身份证识别返回信息等等）
实现店铺用户注册与登录，实现普通用户和店铺用户，留有两者不同界面的跳转的接口，写好店铺用户修改店铺信息的接口，实现店铺用户注册短信验证，并留有店铺用户身份验证的接口
实现系统管理员的登录，实现不同的跳转
增强安全保护，对http请求，前端密码和后台数据库传输交互这个过程进行MD5加密传输
采用Token令牌机制，为用户的每次登录发放时效令牌，降耦合不将用户的登录状态存在后端
-
商品模块
实现商品管理的所有功能
实现商品搜索界面，预期效果是点击搜索，展示搜索历史，并且覆盖掉多余UI元素
点击搜索后将搜索结果展示到商品列表里
仿照美团实现商品的展示列表，类似于tableview
然后还有单个商品的展示列表
-
购物车管理
购物车管理，信息存放在android本地数据库SQLite
订单管理，包括提交订单，最近订单，订单跟踪（应与美团类似，可以调用地图查看货物当前位置），订单评价，历史订单（或说全部订单） 同时留好 待付款，待退款/售后的接口
实验报告 每一个角色做了什么事情