移动端程序的开发

移动端程序的开发

伴随移动互联网的不断发展，每个企业都想开发自己的独立app，那app要怎样开发呢？一款app的开发，不单只是app开发人员把软件各个功能模块进行逐一敲代码，在进入app研发阶段之前，还需要经过市场调研、功能需求分析、app原型图设计、UI设计、app前端设计。

App开发是一项充满挑战的任务，具有许多创意和创新。如果你想开发一个优秀的App，需要经过一系列的流程步骤。这篇文章将为你介绍app开发的具体流程步骤，并列举一些应注意事项。

开发一个APP首先要明确几个大问题

1、针对的行业

2、大致用户基数评估

3、商业模式确定（一个用户从进入APP开始，需要哪些操作来完成你给他的商业套路?然后怎么结束流程。）

4、差异化：当然这个不是必须的，只是个人建议。

中国50年才能出一个大创意，创意类的应用就完全不建议大家去做，很容易胎死腹中，很难推。而且所谓创意这种东西，不太容易出现在刚需部位，多数是发起者自己拍脑袋想的，把个人需求当做市场需求。移动互联网发展了十多年了，你能想到的多数已经都做起来了。

我的建议目前市场还能玩的东西有两种

一、市场空缺

至少我周围还活着的产品，吻合以上定律。讲讲自己的理解，

例子1：《饿了么》是很牛逼，模式也相对成熟了，但是针对人群其实都在一二线城市。在一些下沉市场其实“饿了么”本身是没有覆盖到位的，这就是“市场空缺”。

例子2：中国其实是全世界互联网应用最发达的国家，比如你在淘宝下单，然后有人给你送过来了，中国人已经习惯了这种体验。但这个体验在老外看来简直“按比例我包““鹅美静”！所以前年有个朋友成功了，把京东搬到了澳大利亚，现在一年大概上亿流水吧，这就是“市场空缺”。

二、细分化的专业应用

细分化的专业应用：说的简单点就是行业深度，你对行业足够了解，足够专业，然后做一个APP来解决行业的问题。

例子1：创业第二年的时候有人找我合伙，当时2016年，他们想做的东西我大概描述下背景，中国从有电梯到2016年差不多到了15年这个结点，做电梯维修保养的都知道，这种大结点，有大量的电梯需要维修保养了，是个巨大的市场需求，但是我们不在行业里的人肯定不知道，他们就做了一个平台，把大量的运维师傅和甲方做了一下整合，包括派工单、路线规划、零件集成商等。结果-------------又大赚了。很遗憾，我又错过了...........这就是细分行业。

例子2：比如有人做二手车平台，你只做二手车的玻璃，因为玻璃你十分专业，知道他从出厂开始的所有流程，这也是细分，有了以上步骤，你应该大致明确了自己想要做什么样的APP，先整理出来一个大致的流程。

App需求整理

大部分创业型项目在这个阶段只是一些比较抽象的想法，有一份相对完善的需求文档，不仅有助于创业者自身对项目的理解和周全性分析，如果项目是交由设计公司去完成的话，也更有利于对方准确把握项目的定位和商业模式，以便给出专业的建议和解决方案，下面是需求整理过程中比较关键的点：

1、清晰认识项目是为了解决什么用户痛点，行业需求？

2、分析要解决这些痛点或者需求的过程中需要通过哪些有效的功能布局去实施，逐一将核心功能列举并适当完善一下，通过文字或图文的方式描述清楚。

3、建立完善并且合乎逻辑，功能完整呼应的需求文档不是一件简单的事，如果你是 PM（产品经理）出身的话会比较容易上手，否则最好还是由第三方机构协助完成。

开发预算评估

不论项目是由自己团队执行开发，亦或是交由第三方公司代为设计开发，建立在一份完善且有质量的需求文档都是非常有必要的，对需求文档进行人力时间的投入，可以较准确地估算出项目需要投入的预算，同时这些文档后期会有助于产品经理，UI 设计师，技术开发人员等等对项目的理解，减少人员沟通中可能存在的误差。

某项目的需求文档和逻辑结构为例。

App原型设计

接下来会根据上面提到的具体需求文档，项目经理进行会进行原型图的设计，包括：

1、功能的结构性布局

2、各分页面的设计

3、页面间业务逻辑的设计

最终输出每个足够示意出页面所包含的功能的原型设计图，比如：

UI设计

1、APP UI 

原型图经过反复推敲修正后，UI设计师会进行UI界面相关的配色设计、功能具象化处理、交互设计、以及各种机型、系统的适配。UI 设计师经过多次与项目经理沟通修改后，最终的到定稿的高保真设计图。

2、后台 UI  

绝大部分 APP 项目都会有相应的管理后台，虽然后台是用户无法接触到的，但是与 APP 侧的功能是意义对照的，合理的设计能让后台管理人员快速上手。

App开发阶段

经过以上几个过程之后，会正式进入到开发阶段，一个完整的 APP 项目一般包含以下几个板块：

1、服务器端：编写接口协议文档，服务器环境架设（国内一般都是用阿里云服务器，国 外一般用亚马逊），设计数据库和编写API接口。

2、APP 端：根据UI设计图进行界面开发，UI 开发完成则进入和服务端接口对接，通过服务端的接口获取数据，编写功能上的逻辑代码。

3、Web 管理端： 根据前端的业务逻辑，后台会有相应的功能与之匹配，同样需要编写功能上的逻辑代码。

App测试调试

APP功能开发完成之后，测试人员会对整项目进行系统性测试，这个环节会调动起项目组内所有人相关人员。而测试这个环节的重要性不亚于前期功能的规划，如果团队没有经过专业系统性训练的测试人员，很可能会导致项目出现与设计初衷存在落差，以及遗漏下一些逻辑上的坑（这些坑是以后给自己带泪跳下去的...）

而完成项目测试调试最重要的环节是问题的管理，追踪各个 bug的进度以及状态，包括指派给谁、优先级、修复状态等等，以便有质量地完成问题的处理。

发布到应用市场

经过至少两轮的内部测试以及小范围外测（或者完成满足测试要求的周期）后，会进行最终版本的上架，以常用的 iOS 和 Android 应用市场为例：

1、Android : 涉及的应用市场很多，主流市场是应用宝、360手机助手、小米商城，不同的应用市场的受众属性会有所不同，流量也有较大的差别，需要根据实际情况选择。

2、iOS : 发布到 AppStore（苹果审核比较严格，是否符合最新的上架要求，是否涉及到虚拟货币、是否支持最新环境等等等 N 多问题都会导致审核是否能通过，这个对经验的要求就很高了，而最坑爹的是，比如某 APP 存在 5 个导致不通过的问题，苹果是不会把5个找出来告诉你为什么拒绝的，而是找到一个就马上拒绝你，所以如果经验不足的话上架 n 次花费几个月都是很有可能的。）

App运营迭代

产品正式投放到市场之后，会得到用户以及市场本身的一些反馈，从而知道该如何修正或者调整运营策略，当目前系统的功能再也无法满足项目需求时，就需要规划新一版本功能的迭代问题了。（重新经历：需求整理-预算评估-原型设计-UI 设计-开发-测试调试-发布  这个产品的生命周期 ）

App日常维护

在项目正式运作的时候，即便是已经达到相对稳定的阶段，也会有可能出现一些小问题，或者发现一些隐藏得比较深的 bug，这个时候就需要有相关的市场人员进行问题的收集以及技术人员对问题作出及时的修复，简单理解就是需要有人值守。

App版本流程总结

版本流程详解：

版本流程共分为5大部分，分别为需求、开发、测试、发布、反馈收集。

需求部分

1、需求池：产品会将各组需求进行优先级排序，跟进技术资源的数量来安排当前版本可以做哪些需求。

2、立项：需求较大，涉及较多不同开发组、或部门的需求需要立项，项目进度与资源有独立的项目经理跟进。

3、需求评审：其中包含需求预审，需求预审是各组老大对该版本的需求进行一次预审与工作量初步评估。确定版本需求后产品经理会在规定的时间节点内召集开发、测试进行需求评审。

开发部分

4、设计评审：服务端开发接口设计完成后进行设计评审，与android、iOS开发沟通清楚接口设计。确保信息一致性。

5、开发编码：开发各自根据需求进行开发。

测试部分

6、用例设计、用例评审：在开发编码过程中进行用例设计，用设计完成后召集产品、相关开发、相关测试进行TC评审

7、功能预演：在开发提测时进行功能预演，最好能邀请产品参加，产品提前介入能够提前发现需求、交互与产品预想中的差异。降低修改成本

8、冒烟测试：功能预演通过后进行冒烟测试，冒烟测试如果遇到主干流程不通可以直接打回。冒烟测试过程中需要保证主要功能正常，不影响后续测试。

9、功能测试：根据项目复杂度确定功能测试轮数

10、适配测试：手工适配，挑选用户量占比较多的手机进行适配测试，保证不同分辨率，不同操作系统的手机都能正常使用。自动化适配，使用自动化工具在机房进行monkey测试，测试APP在不同操作系统、机型上的安装、卸载、启动、跟稳定性。

11、服务端性能测试：根据需求、预估线上用户量，是否需要提交申请性能测试。需要在上线前完成性能测试与性能调优。

12、客户端性能测试：理论上来说新增的功能都需要进行性能测试。需要用工具检查APP的内存占用、CPU占用、FPS、流量、电量等指标是否符合预期。

13、bugbash：在完成功能测试后进行bugbash，需要邀请产品、交互、视觉、开发、测试参与，将bugbash中发现的问题汇总修改完成后可以进入发布流程。

发布部分

14、发布计划制定：发布计划分为两部分，一为服务端发布，二为客户端发布。

服务端发布根据项目涉及到的应用，制定发布顺序，一些独立工程或者独立项目可以以项目上线流程提前上线。剩余应用排定顺序后在发布日按顺序发布。

客户端根据需求制定需要灰度的时间，策略，渠道等。灰度完成后再正式发布到市场。

15、发布执行，在服务端发布日当天如果涉及应用较多可以进行集中发布，将PE、开发负责人、测试负责人集中到一起进行发布。具体发布细节可以参考发布流程。

16、客户端发布：服务端发布完成后客户端打渠道包进行渠道灰度，一般2~3天左右，根据收集的问题修复后，测试进行客户端大回归，大回归通过后，发布到各个应用市场

反馈收集

17、发布完成后分析crash日志，收集用户反馈将收集的问题加入到需求池。