android工程上线,Android 项目开发的流程

今天我们来介绍一下 Android 项目流程的相关知识，在本篇文章里面我们将从需求的产生到交互的实现，再到视觉的输出到最后我们开发并完成上线，描述一下一个典型的产品开发流程是什么样子的，项目流程一般分为这几个阶段：

Android 项目开发流程

在整个流程里面，除了编码属于开发的基本工作以外，工程师还有需要参与流程的其他里面去。第一个就是产品需求产生的需求评审，让开发参与需求讨论了解需求，并提出一些意见、解决一些问题；同时也可以进行一定的脑报帮助完善需求；同时评估实现复杂难易程度和性价比。在这之后，有一个交互评审，开发对官方交互的设计了解是必不可少的。在这个阶段的评审可以提出自己的意见和官方的指导意见，同时呢，可以评估一下实现的难易复杂程度和性价比。视觉阶段，主要是对于技术是否能够实现的考虑，有些视觉设计可能过于理想化，需要及时更正。之后到我们开发的重点，交互和视觉评审，有一点是非常重要的，就是我们开发要从我们开发的角度去思考，从而及时发现交互和视觉没有发现的问题和细节，这样非常有利于我们后面的开发工作，减少反复的成本。开发完成之后我们要进行性能调优，这个我们会在后面具体讲到。

Android 产品的并行开发

正常的开发流程都是并行的，开发不会等到的这个版本完全开发完成了，才开始开发下一个版本，下个版本的产品需求也不会在这个版本上线之后才开始设计。一般情况下，在上个版本还在测试发布前，下个版本的需求就已经开始输出了。在产品开发的后期开发往往有一些空闲时间，刚好可以用来做产品需求的评审和交互的评审。在这个图上面，我们可以看到在这个，测试的中后期，产品需求就已经开始输出，并完成评审，然后交互设计随之进行开展，交互设计完成时间点不是特别确定，一般要求尽快完成交互评审。这样在发布了三个版本之后开发就可以稍作休整，观察一下现场的反馈，就可以接着下个版本开发了。与此同时，视觉设计的整个过程也是和开发一样是并行的。在测试的中后期就会开始验收，验收非常重要，是验证每个环节是否达到了预期，不同小组的工作并行非常重要，这样才能极大的发挥团队的协作能力，提高工作效率。

开发和视觉的配合

在评估完交互和设计之后，我们会进行版本开发计划，并评估每个模块开发的具体需要时间，然后把具体开发工作分配到每一个开发人员身上。比如说我们有三个人并行开发，每个模块的开发时间和人员安排都被评估出来，视觉会根据我们的开发计划分批输出视觉。比如说在这个这个时间点会输出模块1、2、3，我在这个时间点会输出4、5、6，然后在这个时间点会输出7、8。这边特别要去注意的是，最后一批视觉输出，一定要把控好时间要保证留足够的时间给开发进行资源的替换，这样才能保证在体测时间可以完成开发工作。要保证留足够的时间给开发进行资源的替换，这样才能保证在体测时间可以完成开发工作。所以其实在某些阶段，开发工作是没有视觉资源的，所以要先完成逻辑和功能开发，这个过程应该是完整的，包括各种分辨率的适配，唯一留下来工作就是替换美术资源。

开发和后台的配合

那同样开发和后台的配合也是非常重要的，它跟视觉的配合有点类似，因为后台的接口也是分批给出来，所以在一定阶段我们开发是没有结口的，这就需要我们根据实际来 Mock 些数据。同样，最后一批计划输出时间也一定要确定好，保证剩余足够的时间来跟后台进行接口的联调。

接下来我们重点来看看开发的基本流程：

开发的流程

我们拿到需求之后，首先要对需求进行分析，具体要做什么工作是为了解决什么问题？然后我们对功能进行划分，哪些部分是关联的，大概分成哪些模块。同时能对这些情况进行技术思考，可能用到什么技术方案去实现难点，大概技术点是什么样子的。需求分析之后我们就进入模块设计，首先我们要对技术方案进行对比，选择一个适合自己的方案，方案不是越复杂越好，要能解决需求的同时又有一定的扩展能力。那接下来就是结构框架设计，搭建好结构框架，包括定义好接口，通信模型流程结构等等，然后进行详细设计，比如详细的协议、涉及数据算法的选择。必要时，我们会输出设计文档以便后面的维护。接下来我们就进入编码阶段，我们把设计转换成代码，实现完整的逻辑流程功能，但实际上我们花在编码上时间并不多，可能会占了20%，大部分时间我们都在调试，通过不断调试来解决各种Bug，最后还要进行必要的优化和重构，来完善我们的代码。现在调优在开发过程后期占很大的比重，偶尔通过排查可以发现一些潜在的问题，比如内存泄露，CPU 占比过高，滚动掉帧等等。通过一些工作进行调优，不可缺少。最后是自测，自测是必须的，这是属于每个开发者的责任。自测很重要，只有通过自测代码才可以提交给后面专门的测试人员来测试，没有通过自测的代码，甚至都不允许提交到代码仓库，如果提交了这被认为是一种不负责任的表现，自测有很多种，常见的有冒烟测试、功能测试、边界测试、回归测试等。

一般情况，每个模块开发完成之后，开发就需要对这个模块进行测试，所以基本的流程是，开发一个模块测试一个模块。这部分自测时间是包括在我们的开发时间里面的，刚才提到没有通过自测的开发代码，是不能提交到代码仓库的，通过开发自测后，其实是可以直接作为上线标准的。开发不应该依赖于后面还有专门的测试人员来保障我们的产品质量。

接下来我们介绍几个时间节点。第一个是需求截止时间，我们最讨厌的就是需求不断的变更或者新增，最正规的项目开发流程里面应该规定有需求截止时间，但因为计划赶不上变化，所以同时应该也有需求变更和新增的流程，为了保证项目质量，绝对不允许临近上线还在改变需求。

只有开发跟交互一起去了解各种细节，后面的开发才能顺畅起来，否则后面遇到交互、视觉有问题就会影响我们的开发效率。同样，视觉得分配输出节点和后台的接口分配输出节点，在前面已经讲过了。

只有及时沟通好了，才能跟视觉和后台配合得好，我们才能在约定的提测时间点提测。当然重要的是知道我们一个版本的发布计划，上个流程晚了就会影响测试时间，从而影响发布时间。

在发布里面有一种发布叫做灰度发布，就是只有少量用户可以更新到我们的最新版本，这样的话，那我们可以通过这种方式来暴露出一些问题，然后可以进行一轮修正之后再全量发布，可以减少受影响的用户。灰度发布有很多办法，比如说我们通过尾号推送版本更新等等，那根据一般的经验来讲在有一定规模用户基础上，一般20%用户升级到最新版本，大概需要3到5天就可以完成暴露出这个版本的问题。