Question

一个团队成熟与否的标志是文档。文档太多，就违反了敏捷的原则，但有几个文档是必须要提供的，下面分别介绍。

12.2.1　新员工入职文档

这份文档包括：

·部门组织结构，新员工所在的团队和将要担当的角色。

·个人简介，用于群发给部门其他成员。

·要加入的公司邮件组，部门内部用于沟通的QQ群或微信群。

·Android项目的地址，权限申请。

·Bug管理工具及权限申请。

·测试环境和仿真环境的地址。

·产品需求的地址。

·WIFI设置、VPN申请、手机邮箱配置、打印机安装，等等。

12.2.2　加强版新员工入职文档

我们针对Android开发团队，编写了一份适用于Android团队新员工的入职文档。这份文档包括：

·SVN或GIT的权限申请。

·Android开发常用软件下载。

·迭代的节奏。

·业务名词解释。

·Android App的项目结构。

·Android自动打包地址（如果有）。

·模板（模范标准）页面。这里指的是新人写程序时可以用来参考的类或方法。

·代码规范。

12.2.3　测试机清单

App开发团队一定要有一份测试机清单，如表12-1所示。

表12-1　测试机清单

这样线上有类似机型或系统出了问题，就有机会复现这个问题。Android几千款机型我们不可能全都采购，一种好的方案是，到友盟上看使用我们App的排名前10的Android手机，采购这些手机，确保开发团队和测试团队各有1部这些型号的手机。

12.2.4　模块分工表

把开发人员按照业务线（模块）进行划分。

对于小的团队，每个模块上有1个主要开发人员，1个后备开发人员，二者互为备份。在另一个模块上，这两个人的身份则反过来。如表12-2所示。

表12-2　模块分工表

分工表一旦制定，就不能随意调整了。不能因为模块A忙不过来，就把模块C的王五调过去。人员频繁流动，会导致代码质量降低。

对于规模大的公司，每个模块都会有一个3~4人的小团队，所以无所谓主从的关系，但这个小团队会有1个Team Leader。

另一方面，要尽早对Android项目进行模块拆分，按照业务线进行模块划分是个不错的选择，把各个独立的业务模块从一个大的apk中独立出来，这样才能让负责这个模块的人或者团队独立开发而不受其他团队的影响。

12.2.5　页面逻辑流程文档

每条业务线的业务逻辑都是非常复杂的，表现在Android项目中就是十几个Activity页面。其中，每个Activity中，跳转到其他Activity的情况就很多，包括startActivityForResult这样跳过去又跳回来的场景；另一方面，每个Activity都可能有多个入口。

当我们想修改页面跳转逻辑及传参时，往往会因为考虑不全面而引发灾难性的问题，直到发版后才发现（多发生于推送）。

于是我们迫切需要每条业务线的页面流程图，在修改业务流程时，这个页面流程图有很好的参考价值。我画过很多这样的页面流程图，一般而言，各条业务线的页面流程都差不多，如图12-1所示。

图12-1　业务流程图

主流程就这么6个步骤，各家App的区别就在于每个页面上会有一些子页面，用于加强信息收集。基于此，才有了这份页面逻辑流程文档，图12-2和图12-3是我设计的一款奢侈品App的页面流程图。

图12-2　一款奢侈品App的页面流程图-1

图12-3　一款奢侈品App的页面流程图-2

不要把所有页面都画在一个图中，线太多，没人能看懂。拆开画，效果会更好。

12.2.6　MobileAPI接口分布图

一般用XMind思维导图来描述一款App所用到的MobileAPI接口，如图12-4所示。

图12-4　MobileAPI接口分布图

有了这个图表，我们就可以：

·定期检查iOS和Android在做同一功能时所使用到的MobileAPI是否一致。

·每次MobileAPI发版上线，相关的测试人员，就可以根据这张图，找到这些MobileAPI接口改动影响了哪些页面和功能，需要进行相应的回归测试。

要定期更新这份文档，可以写一个脚本，定期从Android代码中，捞出所使用到的MobileAPI列表，同步到这份文档中。

12.2.7　版本管理策略文档

无论是使用SVN还是GIT，都要制定一套发版流程。Android团队中要有专门的开发人员熟悉并遵守这套流程，包括：

·正常迭代的流程。

·开新分支做技术调研的流程。

·紧急上线流程。

流程一般有两种，要么是主干开发主干上线，要么是主干开发分支上线，无论是哪一种，都要落实为文档，切忌口口相传。

12.2.8　框架设计文档

当我们把AndroidLib这个业务无关的类库从App中抽象出来的时候，就该有一份框架设计文档了。

这份文档我曾经写过，本书第1部分的第1~4章就是这份文档的扩充版，请仔细阅读。

12.2.9　发版流程文档

Android发版并不像iOS那样只提交AppStore审核，Android要发布到各大市场，为此，需要修改AndroidManifest.xml中的友盟渠道号，才能统计出各大市场的下载量。此外，对外发布的apk包要混淆，否则外界可以通过反编译看到我们辛辛苦苦写的代码。

其实考虑问题最多的是测试团队，他们往往会担心：

·渠道号是否正确？

·代码是否混淆？

·版本号是否正确？

·是否release包（而不是debug包）？

·临时决定关闭的功能是否露出来了？

·是否可以支付、分享、扫描二维码？

·升级安装是否会引起崩溃？

鉴于以上各点，我们需要制定发版流程并形成文档，包括：

1）产品经理准备发版所需要的描述文字、图片等材料。

2）开发人员进行批量打包工作。

3）测试人员要随机抽取一个apk包进行测试，包括我上面谈到的那些测试功能点。

4）推广人员发布到各大市场，要有邮件持续跟踪各个渠道的版本更新进度。

5）在版本仓库上打Tag，合并分支上的代码到主干（如果采用的是主干开发分支上线的策略）。

12.2.10　App启动流程图

如果要做App性能优化，最好的着手点是App从启动到进入首页的流程。

大多数Android App的启动Activity并不是首页HomeActivity，而是一个叫做LaunchActivity的页面，它的UI就是简单的Splash动画，同时它肩负着更多的职责，如下所示：

·注册友盟、推送等第三方组件。

·加载Splash图，同时下载新的Splash图以便下次开启时使用。

·如果是首次打开，则进入引导页。

·友盟打点，统计激活数

·如果有消息推送到达，点击消息后想不经过首页而直接进入某个二级页面，其实在代码层面还是要经过LaunchActivity的，由它对推送消息进行分发，以决定该跳转到哪个二级页面。

以上这些逻辑交织在一起，非常复杂，尤其是要区分升级版和全新安装版的时候，为此我们需要用Visio之类的软件绘制一个App启动流程图。

在业界，我们将LaunchActiity称为Bootstrapper。LaunchActivity把上述这些事情都做完，才会进入到首页HomeActivity。