产品汪入门级知识纲要

一、产品之源：需求
**
1、需求的来源；
1）领导和上级：

• 这类需求必须做，而且优先级较高，但是做之前必须沟通好具体的需求内容；

2）竞品分析：竞品中提取需求需要注意两点：

• 别人为什么会做，逻辑是什么，如果照搬会不会产生一样的效果？
• 自己的技术储备是否跟得上？
• 自己的运营能力是否跟得上？
• 不要局限从同类型产品中提取，而要广泛观察；

3）用户反馈：

• 用户提的建议是否是伪需求？
• 用户的动机是什么？
• 是否还有更深的需求？

4）运营需求：

• 为运营服务的功能，需要考虑是否长期性、是否值得做？
• 有没有具体的数据支撑？

5）产品策略上：

• 产品的方向性整体性规划；
• 信息架构等框架性调整；
• 技术重构、性能优化邓；

2、需求分析
1）需求的过滤

• 不合理的需求。需求本身缺乏所支持的合理立场观点，导致需求本身不清晰或低价值。
• 找不到合理实现方案的需求。既然是正当的需求，如果没有合适的产品设计方案，那么也无从实现。
• 有技术实现性难度的需求。就算需求是合理的，产品也有相关的设计方案，但是从技术实现上，有较大难度的，可以不着急实现。
• 容易返工和容易被更改的需求。这次的需求在当下这个阶段实现后，紧接着进入到下一个迭代周期时，就会被马上调整更改的需求，可以重新思考其实现的优先级。
• 具有潜在风险的需求。既然都没有上述4点的问题，如果一些核心的业务需求，在没有经过实际的业务操作团队确认之前，都可视为具有潜在风险。

2）需求的分析

• 通过人性来探寻需求的本质，马斯洛需求原理、人性七宗罪，从本质上反映了人们的欲望；
• 通过分析场景来构造具体功能，即时间、环境/背景、事件/状态；
• 通过分优先级，来决定工作进度；

二、产品工作几大文档输出
1、MRD；
1）概述：说明背景和要解决的问题；
2）市场概况：

• 当前的市场特征是什么？
• 整体的一个情况，规模多大、细分情况，增长情况是怎样（需要罗列市场数据），整体的市场趋势如何？
• 市场存在哪些问题？
• 主要竞品的概况、商业模式？

3）用户的需求分析：

• 用户的痛点是什么？
• 需求的场景是什么？
• 还有哪些需求没被满足？

4）机会评估：

• 进入的机会？
• 预期的成果？
• 存在哪些风险？

2、BRD；
1)市场背景：说明市场的现状、存在的问题、进入的机会
2)用户分析：用户的需求和痛点
3）产品规划：

• 产品定位是什么？
• 产品路线图？

4）预期的收益、用户；
5）存在的风险；
6）需要的资源；

3、PRD
1）版本

• 版本记录
• 需求排期
• 人员职责
• 升级注意事项

2)账号

• 游客访问：功能是否有区别？游客模式下如何提示用户去登录；
• 账号状态：正常、限制部分功能、被封禁；
• 不同等级和账号的权限；
• 多账号管理，账号切换；

3）页面

• 页面类型：导航页、列表页、内容页、logo页、新功能引导弹层；
• 实现方法：native、h5、hybrid;
• 交互：页面间交互（向左覆盖、向左推动）；页面特殊交互（页面为空、页面获取失败、页面被删除、页面已过期、键盘弹出收起）
• 数据逻辑：本地数据、服务端数据、本地缓存；
• 页面加载：不同加载状态样式；加载方法（自动、手动、局部）；
• 自我检查：考虑横竖屏；优化整体布局（信息层次、相关信息、功能操作、文字简单易懂）；流程的完备性（反馈提示、返回层级）；

4）控件

• 文本框：是否必填、数据类型、位数限制、数据区间、默认键盘、提示文字、初始值；初始状态、开始状态、默认状态；其他特殊规则
• 单选框：是否有初始选中项；
• 上传图片：上传流程、图片格式、图片尺寸、展示的加载状态；
• 图片：图片尺寸、图片展示状态；
• 文本：显示长度、数据格式、敏感词限制、静态还是服务端动态返回、文字是否有误；
• 时间：时间格式、时间类型；
• 列表：读取多少数据、排序规则、分页机制；
• 弹层（alert）：确定/取消，还是仅仅确定；弹出场景；
• 提示（toast）：应用本身场景（断网、网络不稳定）；加载场景（加载中、加载成功、加载失败）；功能提示（各种反馈提示..）
• 站内提醒：小红点/气泡
• 提交按钮：操作后的反馈、初始状态、按住状态(高亮还是怎样）、禁用状态（需要有提示）、触发区域（点击哪部分区域可以触发）
• 5）动效
• 页面手势：点击、拖动、滑动、拉伸、缩放、摇一摇；

6）硬件环境

• 横竖屏是否需要锁屏；
• 不同分辨率的适配；
• 是否调用手机物理按键？什么情况下调用？如何调用？
• SD卡的问题
• 硬件交互:拍照权限、GPS权限、等等；

7）前后端对接

• push；
• 数据更新说明；
• 软件权限/安全性：
• 数据监控/管理:
• 网络状态说明：无网络时的内容显示；网络不好时有无超时限制；缓存问题如何春丽
• 数据埋点：埋点方式（页面埋点、行为埋点）；如何上报
• 缓存：存储的数据类型、更新规则、删除规则；

4、产品规划文档
1）现状分析

• 数据回顾；
• 产品面临问题；
• 竞争对手和市场环境简要分析；
• 本次规划要解决的问题；
• 产品基本策略；

2）产品路线图（各产品在每个季度要做的大点，计划时间点）
3）年度产品目标／业务目标

5、竞品分析文档
1）竞品选择
2）背景：市场概况/竞品信息
3）用户反馈：知乎/论坛/应用市场/用户访谈
4）核心数据对比：市场份额/下载量/日活/留存/新增
5）产品信息架构对比
6）产品主要功能对比：核心功能的流程/功能点差异化分析（分析功能差异的原因，哪些可以借鉴）
7）界面设计风格
8）交互

• 全局手势
• 退出机制
• 显示机制
• 特殊交互效果

9）性能对标，可以发现产品性能的差异，例如卡顿情况、UI绘制、启动时间、响应时间；
10）分析产品的发展路径，通过每个版本的功能点，可看出产品的发展路径，从而学习产品规划节奏；

三、产品设计需要考虑的关键点和细节
1、交互规范
1）交互细节

• 打断后重新打开APP：返回桌面/临时接入电话（继续显示页面和弹层）、异常关闭/闪退/崩溃（启动）、临时植入短信/其他APP通信（不处理）；
• 常用手势：浏览页面（向上滑动、向下滑动、点击长按）、点击返回（返回到浏览的页面）；
• 点击按钮：点击、提交中、提交成功、提交失败/加载失败/刷新失败/获取失败；
• 上传图片：未上传（显示默认图片）、上传中（显示进度条弹层）、上传成功（显示上传后的图）
• 文本框，一般需要作如下说明定义：字段名称/是否必填/数据类型/位数限制/数据区间/默认键盘/约束条件和提示
• 点击页面空白区域：向下滑动隐藏键盘；
• 用户从wifi切换到移动网络：弹出提示弹层；
• 页面加载、下拉刷新、提交中（提示）；

2）全局的交互说明

• 页面切换方式
• 吐司提示（toast）
• 弹层提示(alert)
• 上拉菜单（actionsheet）
• 页面的异常状态：无网络；数据加载失败；空数据；页面被删除；

2、数据和内容规范；
1）基本状态

• 确定内容是静态写死，还是动态调用服务端；
• 确定内容的加载方式，刷新机制，是手动刷新还是自动刷新？是实时更新or定时更新？；
• 输入框的内容描述和约束机制；
• 内容的排序机制
• 缓存机制，需要缓存那些数据？什么时候缓存？能否用户自定义缓存？缓存是自动清理还是手动？

2）异常和边界状态

• 数据内容为空如何处理？是否支持离线功能？是否有空数据页面设计？
• 内容长度、大小、约束？
• 不同内容条件下的提示？
• 内容违禁如何处理？敏感词过滤、涉及版权、专利、隐私的内容，删除或违禁后如何展示？
• 内容审核机制如何建立？

3、反馈机制；
1）互动的反馈设计：

• 各种提示语的梳理；
• 点击后的跳转；
• 数据刷新时的页面；

2）系统的反馈设计：

• 无网络状态下的提示；
• 网络切换时的提示；
• 申请系统权限的提示；
• 系统崩溃的提示；
• 网络信号不好时候的提示

4、账号状态及用户权限；
1)基本状态

• 不同账号状态下的功能说明：登录、非登录、不同等级、付费和非付费；
• 不同账号状态切换时是否有特殊提示；

2）特殊和异常状态

• 是否说明一个账号多终端登录的问题？是否允许多终端登录同一账号？不允许登录时候如何给予提示
• 是否考虑清楚一个用户多账号的问题？账号的信息如何处理？

5、数据加载
1）整体加载

• 定义：先显示加载提示，同时客户端拉取数据，当全部拉取成功后再展示。
• 优点：能保证内容的整体性，能系统化的阅读所有内容。
• 缺点：可能有强烈的等待感，如果超过3s会让用户产生焦躁。
• 适用于：h5活动页。

2）文图加载

• 定义：根据不同资源类型依次加载。先加载文字，再图片，再语音，再视频，最后其他资源。
• 优点：可以帮助用户快速阅读内容。
• 缺点：也许会丢失掉重要的关键信息，无法建立信息获取的闭环。
• 适用于：文章阅读页、新闻详情页。

3）整页加载

• 定义：当前页与下一页是整页切换的时候，可以考虑采用整页加载的形式，每个页面的数据量不能很大。
• 优点：能保证每个页面的完整性，体验比较顺畅。
• 缺点：不好保证整页的加载效率，且有可能影响浏览的流畅度。
• 适用于：微信的全屏查看大图。

4）分页自动加载

• 定义：展示列表数据的时候，例如默认展示20条，滚动到最后的时候自动再加载20条。
• 优点：把用户代入无尽浏览模式，让用户一直向下滚动，不需要手动点击下一页。
• 缺点：没有尽头，容易迷失，不方便快速索引定位到某个内容。
• 适用于：商品列表页、瀑布流页。

5）分页手动加载

• 定义：展示列表数据的时候，例如默认展示20条，滚动到最后的时候，点击加载20条。
• 优点：方便快速索引定位到某个内容。
• 缺点：需要手动点击下一页。
• 适用于：商品列表页、瀑布流页。

6）分屏加载

• 定义：该页面内容有很多页并且比较大的时候，先加载框架和文字，再加载第一屏数据，等滑动到第二页的时候再加载第二页的数据，以此类推。
• 优点：可以帮助用户快速阅读内容。
• 缺点：也许会丢失掉重要的关键信息，无法建立信息获取的闭环。
• 适用于：h5电商活动页。

7）智能加载

• 定义：当用户处于非WiFi网络下，只加载内容框架以及文字，图片视频等只显示占位符。点击占位符，才去获取真实图片。wifi网络下，默认加载图片视频等资源。
• 优点：根据具体场景来控件流量和加载速度。
• 缺点：不一定真实有效的命中用户需求。
• 适用于：优酷的视频详情页。

四、产品的一些共性功能
1、注册登录
1）设计注册登录之前需要考虑的几个问题

• 是否需要注册功能？
• 注册和登录的场景问题，是否进入app就要注册，在什么时候需要用户去注册登录？
• 功能点的覆盖问题？哪些功能必须登录才能使用？
• 不同用户状态的权限？
• 给用户哪些选择？是否支持第三方登录，第三方登录和正常登录的权限如何梳理？
• 不同终端，账号的同步问题？
• 同一账号，多终端的互斥问题？
• 注册登录完成后的跳转问题？
• 一键登录；
• 二维码登录；
• 语音登录；
• 手势、指纹、刷脸登录；

2）注册登录功能需要考虑的细节

• 密码的设定规则？
• 注册流程中的元素及极限策略，所选的字段是否必要，必须要填写的是什么，选填的是什么，上下限是什么；
• 注册流程意外退出后，再进入是什么样；
• 每一个页面的返回逻辑是什么？是返回到上一步or退出流程？如果是退出流程是否需要弹窗确认，退出后进入什么页面。
• 自动登录和保存密码的规则？
• 用户协议、服务条款、账号申诉；
• 用户资料的关键词屏蔽；
• 手机号占用判断；
• 验证码获取时间、长度；
• 邮箱占用判断、合法性验证、自动联想；
• 用户信息完善时间；

2、推荐系统
1）用户、物品数据

• 显性反馈：直接可以拿来用的数据，用户明显的反馈，比如对电影、音乐的打分，标签数据等；
• 隐性反馈：不是直接的评分数据，往往基于用户的行为数据，根据一定的计算规则才能得出评分；

2）数据清洗

• 数据降噪；
• 刷量数据；
• 无效数据；

3）数据建模

• 数据归一化：
• 对各种行为数据，按照一定的权重和规则组合，计算出用户对物品的喜好程度[0 1]，形成用户偏好数据【用户-物品评分矩阵 】；

4）算法设计

• 基于用户的协同过滤；
• 基于物品的协同过滤；
• 隐语义模型；

5）效果评估的问题

• 覆盖率；
• 用户满意度；
• 预测准确度；
• 多样性；
• 新颖性；
• 实时性：
• 健壮性：
• 惊喜度：

6）冷启动的问题

• 非个性化推荐的最简单例子就是热门排行榜，我们可以给用户推荐热门排行榜，然后等到用户数据收集到一定的时候，再切换为个性化推荐。
• 利用用户注册时提供的年龄、性别等数据做粗粒度的个性化。
• 利用用户的社交网络账号登录（需要用户授权），导入用户在社交网站上的好友信息，然后给用户推荐其好友喜欢的物品。
• 要求用户在登录时对一些物品进行反馈，收集用户对这些物品的兴趣信息，然后给用户推荐那些和这些物品相似的物品。
• 对于新加入的物品，可以利用内容信息，将它们推荐给喜欢过和它们相似的物品的用户。

3、用户系统；
1）注册登录功能的设计；
2）vip会员等付费业务；

• vip的权益和付费规则设定；
• 第三方支付接入；
• 会员的持续运营活动；

3）用户积分和等级体系；

• 是否需要积分体系；
• 积分规则设定，从业务逻辑出发；
• 覆盖哪些用户行为；
• 积分兑换规则的逻辑；

4）用户行为体系；

4、搜索；
1)联想词功能

• 字符串。随着用户输入字符串的增加，显示其关联的热门搜索词，减少用户输入；

2)关键词预处理

• 特殊符号
• 主题性关键词
• 分类型关键词
• 同义词映射
• 中文同音错别字
• 拼音简写
• 别名

3)分词器/语言分析器

• 将文本信息转换成索引中的项，主要是在建立索引和检索时使用，通俗的说就是将文档信息和查询关键值进行分词处理。

4)查询器
5)索引器
6)查询结果（热度算法排序）

5、消息通知系统；
1）用户对用户

• 评论
• 回复
• 留言
• 私信
• @我
• 请求（如添加好友需要双方确认）

2）系统对用户

• 提醒（如新增粉丝、新增@等）
• 系统通知（如系统公告、升级提示）
• 应用通知

3）设计消息通知需要着重考虑的点

• 消息通知的频率：实时、小时/天/周、固定周期；
• 是采用pull还是push；
• 消息通知的样式；
• 通知后的处理；
• 消息的回收删除处理；

五、app基础性能优化
1、启动速度优化

• 将数据按照「必须的」、「可延时加载的」和「不需要主动加载的」进行分类， 启动速度优化的关键点，就是准确的区分出这三类资源，并尽量的压缩「必须」资源的数量，以及降低「可延时加载的」资源对UI操作的影响。

2、操作和卡顿流畅度优化

• 卡不卡，实际上是app流畅度的反映。流畅度的概念是，你的手机1秒钟能显示多少次画面，单位是fps。
• 在我们滑动列表的时候，app开始不断 的往显卡提交画面，然后由显卡绘制出来，这个过程越快，给人感觉越舒服，流畅度就越好。对于电影来说，24fps的速度就够了，但对于手机app，需要 60fps才能不让像我这样有强迫症的人感到难受。
• 系统提供了一个可以直观的展示app流畅度的工具，就在系统设置的「开发者选项」里。

3、UI过度绘制

• 我们设想一个最简单的场景：一个白色的界面，里面有一个蓝色的按钮。显卡在画这个界面的时候，先画白色背景，再画蓝色按钮，非常简单。但是，如果你的白色背景的后面，又有一个红色背景，那么显卡就得在画白色背景之前，画一遍红色背景。但是，用户看到的却是，白色背景挡住了红色背景，整个界面和之前是一模一样的。
• 这就是UI过度绘制的结果，不仅消耗资源而且影响体验。

4、内存优化

• 内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。
• 内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。
• memory leak会最终会导致out of memory！
• 内存泄露会造成程序崩溃、响应速度慢，随着内存占用越来越大，甚至会造成后台自动关闭，是极其严重的问题

六、产品的数据分析
1、数据来源

• 数据埋点；
• 服务器日志；
• 第三方数据统计：友盟等；
• 直接用数据库的数据；

2、数据的应用和分析
1） 分析渠道用户获取

• 分析目标：了解渠道获取用户的能力，从而针对性的进行渠道推广
• 从渠道点击—下载—激活—注册—更深的行为，用户获取的链条上，每个环节都会发生转化，要逐个分析每个环节的提升空间。从而降低每个用户的获取成本。
• 每个渠道的用户获取能力，需要有一定的评估，在进行渠道推广的时候针对性的动作；

2） 分析用户质量

• 分析目标：了解用户的质量，分析应用的状态
• 它有两个典型的指标，留存和活跃。留存和日活应该是产品最重要的2个指标，应该每日关注。
• 留存率可以一定程度地反映出产品对用户的适配程度;活跃度反映的则是用户对产品的依赖程度。当基本的留存率和活跃度有保证之后,开发者可以看一些更细节的行为指标如关键行为点击率，这个指标对于有些应用来说可能是付费，可能是分享、评论、注册或者你认可的APP重要操作。

3）分析关键行为转化

• 分析目标：了解各环节转化情况，分析其异常或不合理情况，进行调整，以提升各环节的转化率。
• 针对特定功能最常用的分析，通过自定义事件来监测更为具体的点击和操作。

3、常规的业务监控和告警
1）确定监控的数据指标

• 成功率
• 转化率
• 错误率

2）设定告警阀值
3）设定告警的通知方式

七、需要了解的技术常识
1、网络协议；
1）网络七层协议；

• 是为了解决硬件间如何通信而诞生的；
• 需要知道传输层的协议TCP/UDP，应用层则是http、https、fcp这些；
• 要了解http协议的基础知识，程序之间是如何通信的，api接口设计的基本知识；

2）TCP和UDP有什么不同，各自有哪些应用？

• 基于连接与无连接；
• UDP更高效，传输效率更高，资源占用更少；
• UDP程序结构较简单；
• TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。
• 即时通讯由于通讯效率考虑，往往使用的UDP传输。

3）ping

• ping命令是TCP/IP协议族中的一部分，他的原理是向目标ip地址发送一个数据包，如果对方返回一个相同大小的数据包，则证明是通的，并且整个过程可以测试时延；

4）关于网络一些基础名词：ip和域名、端口、网关、路由、网卡、；

• ip、域名、网卡：IP是分配给网卡的，如果一台机器有多个网卡，那么就会有多个ip，有了网卡才能正常上网，一个IP可以提供不同的服务，对应不同的域名，域名可以通过DNS解析转换成IP；
• 端口： 一台拥有IP地址的主机可以提供许多服务，比如Web服务、FTP服务、SMTP服务 等，这些服务完全可以通过1个IP地址来实现。那么，主机是怎样区分不同的网络服务呢？显然不能只靠IP地址，因为IP地址与网络服务的关系是一对多的关系。实际上是通过“IP地址+端口号”来区分不同的服务的。
• 网关、路由：就是一个网络通向其他网络的IP地址，路由器可以理解为是具备一种网关的功能， 比如有网络A和网络B，网络A的IP为“192.168.1.1~192. 168.1.254”，子网掩码为255.255.255.0；网络B的IP地址范围为“192.168.2.1~192.168.2.254”，子网掩码为255.255.255.0。在没有路由器的情况下，两个网络之间是不能进行TCP/IP通信的， 而要实现这两个网络之间的通信，则必须通过网关。

5）tcp的三次握手

• 主机A通过向主机B 发送一个含有同步序列号的标志位的数据段给主机B ,向主机B 请求建立连接,通过这个数据段,主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.
• 主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事:我已经收到你的请求了,你可以传输数据了;你要用哪佧序列号作为起始数据段来回应我
• 主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B 的数据段:”我已收到回复,我现在要开始传输实际数据了这样3次握手就完成了,主机A和主机B 就可以传输数据了.

6）https；

• 使用HTTPS的服务器，需要在受信任公司申请一套数字证书，也就是密码学中的公钥和私钥，用于进行非对称加密。公钥加密的数据需要用私钥解密，私钥加密的数据需要用公钥解密；
• 客户端发起https请求；
• 服务器将公钥发送给客户端，客户端可以根据公钥验证服务器的身份；
• 客户端生成一个加密密钥，公钥加密后，将密钥传输给服务器，服务器用私钥解密报文获得客户端密钥；
• 服务器和客户端的数据传输都通过客户端密钥进行加解密；

7)FTP；

• HTTP是面向网页的，而FTP是面向文件的, 相比于HTTP，FTP协议要复杂得多。复杂的原因，是因为FTP协议要用到两个TCP连接，一个是命令链路，用来在FTP客户端与服务器之间传递命令；另一个是数据链路，用来上传或下载数据。

8)socket;

• Socket是一个针对TCP和UDP编程的接口，你可以借助它建立TCP连接等等。而TCP和UDP协议属于传输层 。
• HTTP是轿车，提供了封装或者显示数据的具体形式；Socket是发动机，提供了网络通信的能力。

9）长连接和短连接；

• 短连接是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。
• 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是短连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket创建也是对资源的浪费。
• 而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。

10)盗链和反盗链；

• 盗链就是盗取别人的链接，在你的网站A上直接引用另一个网站B的图片或者视频的链接。我们都知道，一个网页中，图片和视频是占用最多流量资源的。这种场景下，用户访问了网站A的页面，网页是从A的服务器拉取的，而图片或者视频资源却是从网站B的。对于网站B来说，用户根本没有访问到它的网页，对于它没有任何收益，却耗费了大量带宽资源，网站B就成了老王一样的冤大头了，势必它要做出一些反应，也就催生出了。一般网站的反盗链都是返回一个警告图片。
• 反盗链，大部分的浏览器在请求一个资源时，会将当前网页的域名放在http请求头的refer字段里面，服务器只用判断这个域名是否是允许请求该资源的站点，如果是就返回正确内容，否则就返回一张反盗链的图片，达到老王的效果。

11）劫持；

• DNS劫持的现象：你输入的网址是http://www.google.com，出来的是百度的页面。
• HTTP劫持的现象：你打开的是百度的页面，右下角弹出唐老师的不孕不育广告。

12）代理（http代理、https代理、tcp代理）；

• 正向代理就相当于一个中转站，用户实际上访问的是原始服务器，我们常常使用的翻墙软件，就是通过代理的原理；
• 反向代理则相反，相对于正向代理而言，它更像是原始服务器，反向代理经常被来做缓存;

13）token

• 令牌，用户授权中使用，用户输入支付密码后，代表用户已经授权了，这时候系统自动生成一个长度比较长的token串返回给服务使用者，后续进行扣款的时候，则进行验证该token串的合法性即可，注意该串需要保证一定的长度，一次性有效，并且较短的有效期等特点。
• 在开放平台中，对外外部站点的授权服务，用户授权后，同样可以给外部站点发放一个token，后续访问服务的时候，带上该token即可，避免每次均需要进行授权。

14）DNS；

• DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为IP地址的工作。DNS就是这样的一位“翻译官”

15）重定向；

• 转发过程：客户浏览器发送http请求——》web服务器接受此请求—》调用内部的一个方法在容器内部完成请求处理和转发动作——》将目标资源发送给客户；在这里，转发的路径必须是同一个web容器下的url，其不能转向到其他的web路径上去，中间传递的是自己的容器内的request。在客户浏览器路径栏显示的仍然是其第一次访问的路径，也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。
• 重定向过程：客户浏览器发送http请求——》web服务器接受后发送302状态码响应及对应新的location给客户浏览器—》客户浏览器发现是302响应，则自动再发送一个新的http请求，请求url是新的location地址——》服务器根据此请求寻找资源并发送给客户。在这里location可以重定向到任意URL，既然是浏览器重新发出了请求，则就没有什么request传递的概念了。在客户浏览器路径栏显示的是其重定向的路径，客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。

16）cookie和session；

• 后台能知道客户是谁，并且可以知道这个用户的状态，后台记录的这个编号就叫session id，这个机制就称为session。
• 购物车的例子，一个未登陆用户访问了京东网站，这个时候京东对其下发了一个cookie，假设是cookie的名字叫做abc，那这条记录就是abc＝001，同时京东的后台也生成了一个session id，TA的值也为001，001这个客户再2点、3点、4点分别加了三件商品入购物车，这样后台也记录了session id为001的用户的购物车里面已经有三件商品，并且只要每次客户端cookie带上来的值里面包含session id，后台都能够展示相应的数据，如果这个时候，你在浏览器里面清空cookie，cookie数据消失之后，后台和客户端无法建立对应关系，购物车的数据就会失效了.

2、服务器和运维相关知识；
1）常见的服务器软件相关名词；

• Apach和tomcat：Apache是Web服务器，Tomcat是应用（Java）服务器，可以认为是Apache的扩展，但是可以独立于Apache运行。如果客户端请求的是静态页面，则只需要Apache服务器响应请求；如果客户端请求动态页面，则是Tomcat服务器响应请求，将解析的JSP等网页代码解析后回传给Apache服务器，再经Apache返回给浏览器端。
• nginx:是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器,有非常好的性能，同时也是一个非常高效的反向代理、负载平衡。
• redis：一款内存高速缓存数据库,Redis以内存作为数据存储介质，所以读写数据的效率极高，远远超过数据库。

2）正向代理和反向代理；

• 正向代理，就像是一个中转站，设置代理后，通过代理服务器去请求原始的资源；
• 反向代理，可以接受请求，然后再转发到相应的内容上；
• 可以这样理解，正向代理用户访问的仍然是原始的url，而反向代理，返回的url是反向代理服务器的域名
• 反向代理常用作负载均衡；

3）服务器的性能指标：吞吐量、并发量、带宽

• QPS（TPS）：每秒钟request/事务 ，但是事务是基于虚拟用户数的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是 1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达 到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快 慢。
• 并发数： 系统同时处理的request/事务数；
• 响应时间：一般取平均响应时间；
• QPS（TPS）= 并发数/平均响应时间；
• 带宽：等于并发数为每个连接提供的带宽，假设理想的速度是能够为每个连接提供40KB/S的带宽，而此刻同时有1000人向服务器发出请求，那么100040/1024=39M的带宽就可保证计设中的速度。

4）缓存；

• 应用层缓存： 应用层缓存是指我们在代码层面上做的缓存。通过代码逻辑，把曾经请求过的数据或资源等，缓存起来，再次需要数据时通过逻辑上的处理选择可用的缓存的数据。
• 数据库缓存： 我们可能听说过memcached，它就是一种数据库层面的缓存方案。数据库缓存是指，当web应用的关系比较复杂，数据库中的表很多的时候， 如果频繁进行数据库查询，很容易导致数据库不堪重荷。为了提供查询的性能，将查询后的数据放到内存中进行缓存，下次查询时，直接从内存缓存直接返回，提供 响应效率。
• CDN缓存： CDN缓存一般是由网站管理员自己部署，为了让他们的网站更容易扩展并获得更好的性能。通常情况下，浏览器先向CDN网关发起Web请求，网关服务器后面对应着一台或多台负载均衡源服务器，会根据它们的负载请求，动态将请求转发到合适的源服务器上。从浏览器角度来看，整个CDN就是一个源服务 器，从这个层面来说，浏览器和服务器之间的缓存机制，在这种架构下同样适用。
• 代理服务器缓存： 代理服务器是浏览器和源服务器之间的中间服务器，浏览器先向这个中间服务器发起Web请求，经过处理后（比如权限验证，缓存匹配等），再将请求转发到源服务器。代理服务器缓存的运作原理跟浏览器的运作原理差不多，只是规模更大。
• 前端缓存
• 浏览器缓存

5）CDN;

• 内容交付网络 (CDN) 是一种全球分布式缓存的服务。
• CDN 在世界各地的许多地方保存了应用程序文件的副本。当用户访问时，会选择离这些地方接近结点，内容不需要走长距离网络来传递，所以它能访问到达速度更快，以此来改善用户体验。CDN 节点设在世界各地希望尽可以能接近的用户。它有自己的 URL 负载平衡解析器，根据用户不同地理位置，无论用户在什么地方将用户引向最近的节点。

3、大型系统的架构模式；
1）分层

• 系统设计最基本的思想，将系统分为不同层级；

2）分割

• 业务分割/
• 应用和数据分割/

3）分布式

• 分布式应用和服务，将分层和分割后的应用和服务分布式部署/
• 分布式静态资源/
• 分布式数据和存储/
• 分布式计算/

4）集群

• 不同的应用服务，部署服务器集群，通过负载均衡来调用/

5）缓存

• CDN/
• 反向代理/
• 本地缓存/
• 分布式缓存

6）异步
7）冗余
8）自动化工具

4、编程思想和设计模式；
1）环境搭建和部署

• 开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。所有的开发和配置在这个环境里进行。一般情况下，只有这个环境可以改配置和进行开发，并且一般不在这个环境下创建数据。（开发环境就是每个开发人员电脑上的开发环境，只有开发人员可以配置和开发，写数据测试放在测试环境）
• 测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。
• 新开发和配置通过系统传输到测试环境，进行功能测试，可以创建数据。（开发人员开发完上传到SVN，测试人员下载下来测试。我们公司测试人员不懂IDE，所以是由我们开发人员下载好，他直接通过IP地址访问来测试的。）
• 预生产环境：从生产环境不定期同步，保持和生产环境的设置、数据一致性，也是用于测试，它和测试环境最大的区别就是它和生产系统的同步性最高，几乎一样，有些测试，例如需要大数据量的，用这个环境测试看程序性能比用测试环境（一般情况下数据较少）会更准确。(不是必须的，我们公司没有)
• 生产环境：是值正式提供对外服务的，一般会关掉错误报告，打开错误日志。
• 三个环境对应着软件开发的三个阶段：开发->测试->上线，其中生产环境也就是通常说的真实环境。
• 正式使用的系统环境。 一般情况下，一个环境对应一个服务器，也有一些公司把开发、测试等环境放到一个服务器的。（从SVN上通过FTP下载下来，然后在服务器上的eclipse部署、发布，服务器是linux的）
• 从开发到提交，测试到生产环境是怎么个过程？过程如下：windows下开发：提交war到svn或者ftp服务器，测试人员下载，部署，搭建测试环境。测试环境：windows下测试和linux下测试，测试分功能测试和性能测试，例如用loadrunner或者jmeter等。测试的目的是查漏补缺，让产品更健壮。解决完测试人员提出的bug后，重新打包，进入2。备份功能完好的代码和war，提交给PM，确定后让测试人员部署到正式环境。然后进入3。写书册、使用说明等。

2）面向对象思想：抽象、类、封装、方法、接口、对象、实例、多态；

• 面向对象的编程是根据类的，所有程序必须在类中执行，一个类中包含的成员包括属性、构造器、对象、方法；所有的成员都会被一定的修饰符进行修饰例如public/private/protected，不同的修饰符有不同的意义；
• 属性：用来定义该类所包含的数据;
• 对象：类的实例化，用new关键字调用类构造器进行构造；
• 构造器：构造器是一种特殊方法，要来构造实例；
• static：用static修饰来方法和属性，表明这个方法、属性是属于这个类的，而不是某个实例；static修饰的方法和属性既可以通过类来调用也可以通过实例来调用，而没有static修饰的，只能通过实例来调用，或者使用this关键字；如果某个方法是static方法，那么不能直接调用其他非静态方法，只能通过实例来调用，不能使用this调用；
• void：用来声明没有返回值的方法，一个方法如果有返回值得话必须有return；
• 类和实例调用属性和方法的格式为：类|实例.方法|属性；
• this：用来调用方法或者属性，最大的作用就是让类中的一个方法来调用另外一个方法或者属性，this作为关键字可以指代任何对象，用以代替对象实现对不同方法的调用；
• 方法：方法要么属于类要么属于实例，static修饰的方法属于类方法；
• 成员变量和局部变量：成员变量指的是类变量也就是属性，局部变量指的是某个方法的变量
• package和import：前者用于导入包（各种类的集合），或者用来导入类；
• 继承：使用extend关键字，子类继承了父类，可以调用父类的属性和方法，也可以实现方法的重写；
• final：可以用来修饰类、属性、方法，用final修饰的属性和变量，意味着不可变的，修饰的方法不能被重写、修饰的变量不能重新赋值、修饰的类不能被继承，不能有子类；
• 抽象方法和抽象类：抽象类用abstract修饰，只能被继承，不能被实例化，抽象类往往类似于一种模板的作用，提供给子类用；
• 接口：用interface修饰，接口里面不能使普通方法，全部是抽象方法，接口体现的是一种规范，主要的作用也是用来被继承extend和实现implement，类继承接口的时候可以继承多个接口，这也弥补了单继承的不足；

3）编程模式

• MVC： Model负责数据，View负责显示，Controller负责处理逻辑、用户操作， View将用户操作和事件传递给Controller，Controller将用户命令翻译成消息来传递给Model，Model在处理完数据后，通知View来显示给用户，而View又从Model取出数据。
• MVP： MVP与MVC最大的区别就在与将Model和View通过Presenter隔开了，不再允许其互相直接通信，而所有的消息都是通过Presenter这个中间人来传递。Model，负责定义数据（解决什么是数据）；Presenter, 负责在Model和View之间，从model里取出数据，格式化后在View上展示（解决如何把数据和用户界面放在一起）。View，负责担任一个被动界面，用于展示数据。（解决如何展示数据）

4）同步/异步/回调，阻塞/非阻塞

• 你打电话问书店老板有没有《分布式系统》这本书，如果是同步通信机制，书店老板会说，你稍等，”我查一下”，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结果）。
  而异步通信机制，书店老板直接告诉你我查一下啊，查好了打电话给你，然后直接挂电话了（不返回结果）。然后查好了，他会主动打电话给你。在这里老板通过“回电”这种方式来回调。
• 阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。还是上面的例子，你打电话问书店老板有没有《分布式系统》这本书，你如果是阻塞式调用，你会一直把自己“挂起”，直到得到这本书有没有的结果，如果是非阻塞式调用，你不管老板有没有告诉你，你自己先一边去玩了， 当然你也要偶尔过几分钟check一下老板有没有返回结果。在这里阻塞与非阻塞与是否同步异步无关。跟老板通过什么方式回答你结果无关。

5）进程、线程

• 应用程序都是用来“应用”的，也就是我们平时所说的“打开”、“运行”某个应用程序。在每个平台上，应用程序都会有一个供操作系统使用的“入口”，这个“入口”就是让系统通知应用程序“运行”的关键所在，也就是系统启动应用程序的门户。当我们点击桌面上应用的图标，系统就会收到一条指令：“启动XX应用”，这时系统的应用加载器就会找到应用程序的安装目录，并为应用程序创建一个“进程”，进程创建后，系统就会利用“入口”把应用程序的“逻辑”和“数据”加载起来，并根据应用程序的需要为进程分配资源，如内存、cpu等，这样，应用程序“运行”的条件就满足了。
• 进程中会包含若干“线程”，这些“线程”共享进程的资源，并且按照应用程序中指定的“逻辑”完成既定的任务，如启动闪屏，播放视频，响应用户的交互操作等。

6）多线程

• 线程是程序执行的最小单位，也就是只有当你是一个线程的时候，你才有机会获得CPU的临幸，给你 一个小段的时间，让你来执行。一个排水孔就是一个线程，当打开一个排水孔的时候，称为单线程程序。当打开多个排水孔的时候，称为多线程程序。因为一个程序 有更多的线程，那么这个程序中的多个线程获得CPU的几率就更高，获得的时间就更多，所以执行速度也会更快。
• 例如：你现在所看到的所有的下载器（迅雷、旋风、浏览器自带的下载），都是多线程实现的，如果单线程的话，下载速度最多是别人的一半（哎呦~，人家三个以上的线程在同时下载数据并写到磁盘哦，当然干不过人家，后台的服务器系统都是多线程的，如果是单线程的，我在访问的时候，占用了CPU，别人就访问不了了哦，这个就是并发的意思，以后有机会，给大家讲讲并发和均衡负载，oh yeah~。你所见到的任何一个app，其实启动的时候都做了大量的事情，都是多线程的，有的线程可能在加载新模块，有的线程在做上报，有的线程在收集lbs信息

7）内存池、线程池、连接池；

• 由于服务器的硬件资源“充裕”，那么提高服务器性能的一个很直接的方法就是以空间换时间，即“浪费”服务器的硬件资源，以换取其运行效率。这就是池的概 念。池是一组资源的集合，这组资源在服务器启动之初就完全被创建并初始化，这称为静态资源分配。当服务器进入正式运行阶段，即开始处理客户请求的时候，如 果它需要相关的资源，就可以直接从池中获取，无需动态分配。很显然，直接从池中取得所需资源比动态分配资源的速度要快得多，因为分配系统资源的系统调用都 是很耗时的。当服务器处理完一个客户连接后，可以把相关的资源放回池中，无需执行系统调用来释放资源。从最终效果来看，池相当于服务器管理系统资源的应用 设施，它避免了服务器对内核的频繁访问。
• 内存池则是在真正使用内存之前，先申请分配一定数量的、大小相等(一般情况下)的内存块留作备用。当有新的内存需求时，就从内存池中分出一部分内存块，若内存块不够再继续申请新的内存。这样做的一个显著优点是，使得内存分配效率得到提升。
• 进程池和线程池相似，所以这里我们以进程池为例进行介绍。如没有特殊声明，下面对进程池的描述也适用于线程池。进程池是由服务器预先创建的一组子进程，这些子进程的数目在 3~10 个之间（当然这只是典型情况）。线程池中的线程数量应该和 CPU 数量差不多。
  

8)代码混淆、反编译；

• 将代码中各种有意义的变量名、函数名都用简单的几个字母组合来表示；

9）栈和堆

• 栈(Stack)是操作系统在建立某个进程时或者线程（在支持多线程的操作系统中是线程）为这个线程建立的存储区域，该区域具有FIFO的特性，在编译的 时候可以指定需要的Stack的大小。在编程中，例如C/C++中，所有的局部变量都是从栈中分配内存空间，实际上也不是什么分配，只是从栈顶向上用就 行，在退出函数的时候，只是修改栈指针就可以把栈中的内容销毁，所以速度最快。
• 堆（Heap)是应用程序在运行的时候请求操作系统分配给自己内 存，一般是申请/给予的过程，C/C++分别用malloc/New请求分配Heap，用free/delete销毁内存。由于从操作系统管理的内存分配 所以在分配和销毁时都要占用时间，所以用堆的效率低的多！但是堆的好处是可以做的很大，C/C++对分配的Heap是不初始化的。

10）哈希

• 哈希也称散列，哈希表是一种与数组、链表等不同的数据结构，与他们需要不断的遍历比较来查找的办法，哈希表设计了一个映射关系f(key)= address，根据key来计算存储地址address，这样可以1次查找，f既是存储数据过程中用来指引数据存储到什么位置的函数，也是将来查找这个位置的算法，叫做哈希算法。

………..

八、产品测试
1、测试用例；
2、自动化测试；
3、性能测试；
4、产品测试需要注意的点
1）安装和卸载

• 应用是否可以在IOS不同系统版本或Android不同系统版本上安装（有的系统版本过低，应用不能适配）
• 软件安装后是否可以正常运行，安装后的文件夹及文件是否可以写到指定的目录里。
• 安装过程中是否可以取消
• 安装空间不足时是否有相应提示
• 如果应用需要通过网络验证之类的安装，需要测试一下断网情况下是否有相应提示
• 是否可以删除应用（可通过桌面删除，也可以通过软件卸载安装。曾发现在IOS手相上有个应用安装时未完全安装，终止安装后，未完成安装的应用图标一直显示在手机上，并且无法成功删除）
• 测试卸载后文件是否全部删除所有的安装文件夹
• 卸载过程中出现死机，断电，重启等意外的情况，待环境恢复后是否可以正确卸载
• 卸载是否支持取消功能，单击取消后软件卸载情况是否正常

2）运行

• APP安装完成后，是否可以正常打开软件
• APP运行时，是否有加载图示
• APP的速度是可以让人接受，切换是否流
• 用户登录状态太久，sessionId会过期，会出现“虽然是登录状态，系统会提示用户没有登录。

3）登录

• 登录用户名和密码错误时，界面有提示信息
• 用户主动退出登录后，下次启动APP时，应该进入登录界面
• 对于支持自动登录的APP，数据交换时 ，是否能自动登录成功且数据库操作无误
• 密码更改后，登录时是否做到了有效数据的校验
• 对于未登录时一些页面的操作，是否做了控制
• 切换账号登录，检验登录的信息是否做到及时更新
• 对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新
• 对于一些软件，支持一个账号只允许登录一台机器，这时，需要检查账号登录多个手机时，是否将原用户剔除，且能够给出提示信息
• APP切换到后台时，再次切换到前台的测试，如登录时，有电话打进来
• 对于IOS与Android不同设备登录同一个账号时，对个人信息等数据进行操作后，确保数据数库操作无误，且IOS与Android设备看到的数据都是最新的。

4）离线

• 离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用
• 对于一些程序，需要在登录进来后，这时没有网络的情况下可以浏览本地数据
• 对于无网络时，刷新获取新数据时，不能获取数据且能给出友好提示
• 切换到后台，再次切换到前台时，可以正常查看
• 离线后又连上网，这时对数据有更新时，需要从服务器端获取新数据来更新客户端数据，且要更新本地缓存信息
• 对于一些界面的数据不提供离线查看，需要给出相应提示且界面更新后无任何数据
• 确认在无网情况下可以浏览本地数据
• 确认退出APP再开启APP时能正常浏览
• 确认切换到后台再切回APP应用时可以正常浏览
• 锁屏后再解锁回到应用前台可以正常浏览
• 服务端的数据有更新时有离线的提示

5）消息推送

• 默认开关应该是全打开状态
• 设置开关可以自由打开关闭
• 设置开关打开状态下，消息推送是否可正常接收（应用启用中和应用关闭时都应该可以收到）
• 确认后台未打开APP客户端时，手机消息栏可以接收到消息提醒。且点击可查看。点击后消息栏中消失
• 确认APP客户端启动时，可以收到消息提醒，且点击可查看。客户端运行时，消息不会进消息栏。
• 设置开关关闭时，客户端接收不到消息推送。

6）软件更新

• 当客户端有新版本时，有更新提示
• 软件更新一定要测，确保Android软件更新可以正确更新新版本，且安装运行正确。
• 确保IOS软件更新会有限制，只有上了商店且有版本更新时才会测试，但是如果真有问题，再发现问题不点晚，可以让开发先在测试机上模拟一个地址进行测试。
• 用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提示
• 当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）

7）异常测试

• 没有内存空间时，APP能否正确响应
• APP运行中手机断电
• APP运行中断开网络
• 反复操作某个功能，不断点击，刷新时，是否会闪退
• APP运行时拔打或接听电话
• APP运行时发送信息、收取邮件等
• 多个APP运行时
• 不断切换前台和后台，是否影响应用正常功
• APP运行时，启动相机功能

8）网络环境

• 测试２G、３Ｇ，４Ｇ，wifi 网络下应用运应的速度
• 内网测试时，选择到外网操作是否有异常处理
• 网络不好时 ， 提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒
• 有网到无网再到有网环境时，数据是否可以自动恢复，正常加载

9）其他

• 接口测试。让开发提供一份接口文档，一定要将接口测试通。在接口测试阶段，将缺少接口，接口不完善的缺陷挖掘出来。这个需要准备充分的后台数据
• 导航测试。在运行APP时，不管在哪个接点，导航是否直观，精准，页面切换是否正确。
• 图片测试。图片，按钮是否自适应。
• 内容测试。要进行超长字符，空字符校验且校验是否有错别字
• 功能测试。功能是否实现。
• 易用性测试。所开发的功能，是否让用户容易接受，是否符合大众的操作习惯。
• 适配性测试。应用在不同设备，不同系统上是否适配。
• UI测试。应用的设计是否够美观。