功能的确定
产品的功能并不是在确定了产品之后才开始考虑的，功能与创意选择其实是一个“你中有我，我中有你”的关系。为了体现产品设计的阶段性，我才将它单独提出来分析。
这里讨论的产品功能，是建立在选定了某个基础之上的。比如我们之前选定了天气预报，那么就将产品功能围绕天气预报讨论。
头脑风暴
一开始，我们可以对产品进行一次头脑风暴，找出它的核心功能和可以拓展的外延。
什么是头脑风暴？
简单来说，就是给定一个主题，让一群身份不同的人漫无边际的想一些点子。之后将这些点子归类整理，进一步讨论它们的可行性和重要性，最后形成一个提案。
在我们这里，可以简单的理解成：为了挖掘产品的潜在的功能，我们先不管能不能实现，不管实现了有多大的意义，不管要付出多大的代价，是把我们能想到的功能都找出来。
进行头脑风暴的人最好由不同行业、不同背景的人组成，这样考虑的问题就能多角度，更全面。不过即使只有你一个人也行，毕竟你要做一个能让自己满意的产品才会感觉到快乐，对吧。
方法1
可以将我们风暴的内容，写到小纸条上，贴在黑板上，
风暴结束后，将这些小纸条按照内容进行分类整理出来，
最后按照功能的重要性、相关性，形成我们的功能列表，
方法2
在电脑上用思导图软件，将风暴的内容写在上面，例如使用Mac平台上的MindNode，
然后通过拖动的方式将它们进行整理，
最后再形成功能列表。
除了头脑风暴，我还可以去软件市场下载同类型的产品，逐个研究它们具有哪些功能，对那些确实优秀的功能点加以优化，做出修改，进行微创新。
举例
我们先来风暴一下天气预报要有些什么样的功能：
- 能够连接网络，从网络获取数据，用来显示；
- 能够将获取的数据，例如当日的温度、湿度、风向、是否晴天下雨、紫外线指数、穿衣指数、污染指数等等，显示出来；
- 可以显示当日之后多天的预报，采用曲线图的方式呈现；
- 可以显示当日之前任何日期的实际天气情况；
- 能够设定当前的位置，获取天气情况；
- 能够配合当前的天气，显示一张合适的背景，比如下雨的时候，背景就是一张雨景的照片；
- 能够配合当前的天气，显示动态的背景，比如下雨的时候，背景就是雨水滑落的动态效果；
- 能够接收提醒，比如下雨了，发出一个通知提醒用户带雨伞；
- 能够提供一个桌面小工具，在桌面就能查看到天气信息；
- 天气数据到的源可以选择，阿里提供的、雅虎提供的、腾讯提供的、百度提供的，都可以切换；
虽然我们还可以风暴出很多天气预报可以具有的功能，但是作为第一个例子，我们暂时就列出这么多吧。
接下来将功能分类，有的分类项也许有重叠，但是没有关系，
外观类：
- 配合天气显示的背景：动态图或者静态图；
- 显示温度、湿度、风向、天气、紫外线指数、穿衣指数、污染指数；
- 未来天气的预报，采用变化的曲线表示；
- 桌面小工具；
功能点：
- 通过网络获取天气数据；
- 多个天气数据源的选择；
- 多个地点的位置设定；
- 桌面小工具
- 提醒功能；
- 多天预报；
- 历史天气查询；
选定功能
列出一堆的功能后，我们就要考虑给他们排列个重要程度了，确定哪些功能是必须的，哪些是可选的，他们实现起来复杂度有多大。
对于复杂度很高的功能，我们可能还要进行一次头脑风暴，理清楚它的重要性，看能不能把它分解成相对简单的功能来加入。如果不能，那么可能就得暂时放弃了。
有的功能可能还要依据现有的素材，看能不能提供，例如紫外线指数，如果网络端都没有这样的参数，那写在功能列表里面也是没有用的。由此我们也可以看出，头脑风暴之后，多种成员参与的重要性，如果有一位开发者，他可以很快的判断这个功能点从技术上讲实现起来是否可行。
技术验证
坦白的讲，技术验证并不是在功能确定之后才开始进行的。它应该在确定功能的时候给予技术上的配合，告诉方案的提出者：“这样的功能从技术上讲是可以（不可以）办到的”。
能越早回答这样的问题，就能越早发现并减少项目的风险。
在天气预报当中，最需要验证的并不是设计出一个界面设计出来后能不能做出来，而是去哪里获取天气数据。
天气数据才是功能的核心。从哪里获取数据呢？
我们没有自己的观测站，所以数据肯定是要从其他公开的渠道获取：通过网络蜘蛛爬取；通过第三方提供的标准API接口获取，例如阿里提供、雅虎提供、腾讯提供或者百度提供。
假如我能获取到第三方的数据，那么我是否需要自己建设一个提供天气信息的服务器呢？
就我个人来讲，我希望使用自己的服务器提供天气数据，把收集到的数据都整理到自己的服务器上，一旦某一处的数据出现问题，还可以自动切换到别处的，拥有更好的健壮性。
此外，我也可以自己定义天气数据的查询方式和回传内容，可操控性更好，不会担心数据源的格式发生改变，造成应用获取数据出错的问题。
因此我决定搭建一个服务器，为大家提供这样的数据获取方式，就不麻烦大家将精力分散到与安卓入门开发关系不大的领域去了。
不过，我这里提供的数据都是构造出来的，并不能真实的天气数据，目的只是为了帮助大家学习开发一款应用。毕竟去抓取网络数据有要花费额外的心思，偏离了我的本意。
至此，我们不需要为数据展现的内容而担心了，只要能想到的数据，我都可以在服务器端通过构造产生。之后的界面设计，就需要根据这些能获取到的信息来设计，
| 数据项 | 描述 | 取值 |
|---|---|---|
| 实时温度 | 当前查询时的天气温度 | 整数数值 |
| 实时风力 | 当前查询时的风力大小 | 0-17级 |
| 实时风向 | 当前查询时的风向 | 东 西 南 北 东南 东北 西南 西北 |
| 实时天气 | 当前查询时的天气状况 | 晴天、雨天、多云、多云间晴、雾、雪 |
| 当日温度范围 | 当日温度范围 | 整数数值范围 |
| 实时空气质量 | 当前查询时的空气质量 | 优 良 轻度污染 重度污染 不利于生存 |
| 空气湿度 | 当前查询时的空气湿度 | 0-100% |
| 运动指数 | 当前查询时的运动指数 | 非常适合 适合 不适合 |
| 紫外线指数 | 当前查询时的紫外线强度 | 强 中 弱 |
| 未来5天预报 | 未来5天天气状况、最高最低温度 |
功能筛选
下面，我们就来分析一下这些功能，并为它们的重要性和难易程度作出评价。评价的原则很简单：我们只是为了展现开发的各个关节，所以尽量把功能做的简单，降低我们第一次的学习门槛
- 外观类：
| 项目 | 分析 | 难易程度 | 重要性 |
|---|---|---|---|
| 静态图背景 | 放一张静态图片即可 | 易 | 中 |
| 动态图背景 | 设置循环的动画效果 | 难 | 中 |
| 显示温度、湿度、风向等天气指数 | 具体显示哪些数据依赖于数据源 | 易 | 高 |
| 天气变化的曲线表示 | 这需要一个做曲线图的特殊组件 | 难 | 中 |
| 桌面小工具 | 安卓系统提供了桌面工具的框架机制 | 中 | 中 |
* 功能点：
| 项目 | 分析 | 难易程度 | 重要性 |
|---|---|---|---|
| 通过网络获取天气数据 | 这功能必须有，不然就没有显示的内容 | 易 | 高 |
| 多个天气数据源的选择 | 访问自己架设的服务器，不需要用户去选择 | 易 | 低 |
| 多个地点的位置设定 | 刚开始简化一点，只提供当地的天气预报，由服务器决定 | 易 | 低 |
| 桌面小工具 | 安卓系统提供了桌面工具的框架机制 | 中 | 中 |
| 提醒功能 | 需要网络端支持主动的推送数据 | 难 | 低 |
| 多天预报 | 天气类App的标配 | 易 | 高 |
| 历史天气查询 | 意义不大，用户更关心未来的天气 | 中 | 低 |
我们把重要性低的、开发难的功能暂时放一放，于是得到了下面的功能清单：
- 通过网络获取天气数据；
- 显示天气预报的位置；
- 显示当前时刻的：温度、温度变化范围、湿度、风向、风力、天气、紫外线指数、运动指数等信息；
- 未来5天天气预报，包括天气状况、温度变化范围；
此外，为了近一步简化开发，我们还可以假定：所有的数据都是从网络获取，如果没有网络，那么就不能获取到天气信息。也就是说获取到数据不需要存储到手机上，这一点又降低了开发的难度。
功能流程
确定好功能后，就要根据这些功能，为应用设计一套使用的逻辑，比如需要几个界面，每个界面做些什么事情，这些界面都要覆盖到所有的功能点。
天气预报的流程也许就是这样：
- App启动之后，自动去网络获取信息；
- 当日天气信息和近日的预报信息需要展示到界面上，但是具体怎么展示就要看设计阶段的设计方案了；
流程的设定和设计阶段有一定的交集。前者只是一个原则上的草图，而后者将会从设计的角度打磨出一款精品。
这时候的草图叫做框线图，就是一个手稿，一个示意图。这张图还要交给设计师，和设计师一起讨论设计的方案，再由设计师重新操刀，进行大刀阔斧的修改，将草图蜕变成真正的产品形态，最后形成高保真图、产品原型和UI素材。
下一版功能
对于那些我们没有被选定进来的功能，我们可以将它们放到该App下个版本当中。例如，位置的设定，桌面小工具，天气预报的曲线图等等。
未来版本的天气预报App不仅需要修复之前存在的设计缺陷，也要加入新的功能，让用户获得更好的使用体验。
本文是《从设计到实现-手把手教你做android应用开发》系列文档中的一篇。感谢您的阅读和反馈，对本文有任何的意见和建议请留言，我都会尽量一一回复。
如果您觉得本文对你有帮助，请推荐给更多的朋友；或者加入我们的QQ群348702074和更多的小伙伴一起讨论；也希望大家能给我出出主意，让这些文档能讲的更好，能最大化的帮助到希望学习开发的伙伴们。
除了CSDN发布的文章，本系列最新的文章将会首先发布到我的专属博客book.anddle.com。大家可以去那里先睹为快。