开发APP的流程有哪些?

开发APP的流程：

在专业的app开发公司，完整的开发流程包括：产品开发需求的分析（帮助客户梳理业务流程，系统确认需求）、UI设计（界面的设计、交互架构、风格配色等）、应用开发（代码开发、功能联调）、系统测试（功能测试、压力测试等）、app试运行（在实际环境试运行，客户产品培训）、产品上线（选择对应的平台完成上线发布）。

　　（1）产品需求分析

在接触客户的过程中，我们发现，部分的创业者在有一个创意或者想法之后，就准备开始开发app，真正进入到研发阶段往往会因为模式不清晰，而耽搁非常多的时间，所以客户在产品需求分析阶段就需要对app的商业模式有一个清晰的理解，这样开发的进程才能顺利。

在需求分析阶段，app目前所处的竞争环境也是需要了解的，我们在选择app开发公司时，常常会考虑app开发公司是否有同行业的开发经验，这样在竞争分析时，能提供一定的参考意见。了解潜在对手和竞争环境可以提前预知我们进入的是一个相对饱和的市场还是存在一定空间的市场。

　　（2）UI设计

UI设计是将客户的需求和想法进行规划，变成一个有形的产品，需要考虑到界面的美观度和用户体验的友好度，用户体验是用户在使用产品或者服务时，怎么让用户有更好的感受，而界面是集中在界面的可用性上，产品使用起来是否便捷、使用效率高不高、用户满意度好不好等。在UI设计中用户界面是主要的，而用户体验是辅助。

　　（3）研发阶段

在UI设计完成相应的设计工作，并交由客户确认后，进入开发阶段，首先会由系统架构师或者项目经理在app项目整体的把控和局部细化，根据具体的应用场景给出解决方案，确立开发规范，核心架构，理清技术细节，并安排好相应的开发技术人员。在app前端和后端开发完成后，根据需求分析整理出的功能数据处理情况，建立合理的数据库表结构，优化数据算法，提升数据的处理效率，这样app在使用否过程中才能保障数据的安全性、稳定性和数据的准确性。

　　（4）提测

如果是多端口开发，那么测试的话就需要多机型同步测试，测试的内容包括app性能测试、内容测试、功能测试、压力测试等，将测试出来的BUG移交给开发进行修改完善，待再次测试合格后，提交客户进行验收。

　　（5）app发布

app发布的流程需要我们注意的是不违反国家相关规则、无侵权行为、如有收费内容，需给出明确提示，确认发布的平台，准备好不同平台所需的相关证件资质资料。

　　（6）app上线

如果上线到IOS平台，由于审核较为严格，通常需要一周的时间才能上线，；如果上线到安卓平台，Wap型app的话则直接上线。上线完成后，一般企业会将app产品交由运营人员和维护人员。此时在app开发公司的流程就结束了。

　　在饿了么业务发展的早期，移动APP经历了从无到有的阶段。为了快速上线抢占市场，传统移动APP开发的MVC架构成了“短平快”思路的首选：

　　MVC架构

　　这种架构因简单清晰，容易开发而被大多数人所接受。

　　在MVC的体系架构中，Controller层负责整个APP中主要逻辑功能的实现；Model层则负责数据结构的描述以及数据持久化的功能；而View层作为展现层负责渲染整个APP的UI。分工清晰，简洁明了。此外，这种系统架构在语言框架层就得到了Apple的支持，所以非常适用于APP的startup开发。

　　然后，这种架构在开发的后期会由于其超高耦合性，造成Controller层庞大，而这也是一直被人们所诟病。最终的MVC都从Model-View-Controller走向了Massive-View-Controller的终点。

　　2

　　Module

　　Decoupled

　　“短平快”的MVC架构在早期可以满足饿了么移动APP的快速开发迭代，但是随着代码量的不断增加，臃肿的Controller层也在渐露头角；而业务上，饿了么移动APP也从单一APP发展为多APP齐头并进的格局。这时候，降低耦合，复用已有模块便成了架构的第一要务。

　　架构中，模块复用的第一要求便是代码的功能组件化。组件化意味着拥有独立功能的代码从系统中进行抽象并剥离，再以“插件”的形式插回原有系统中。这样剥离出来的功能组件，便可以供其他APP使用，从而降低系统中模块与模块之间的耦合性；也同时提高了APP之间代码的复用性。

　　饿了么移动对于组件有两种定义：公有组件和业务组件。公有组件指的是封装得比较好的一些SDK，包括一些第三方组件和自己内部使用的组件。如iOS中最著名的网络SDK AFNetworking，Android下OKHttp，都是这类组件的代表。业务组件，则定义为包含了一系列业务功能的整体，例如登录业务组件，注册业务组件，即为此类组件的典型代表。

　　对于公有组件，饿了么移动采取了版本化的管理方式，而这在iOS和Android平台上早有比较成熟的解决方案。例如，对于iOS平台，CocoaPods基本上成为了代码组件化管理的标配；在Android平台上，Gradle也是非常成熟和稳健的方案。采用以上管理工具的另一个原因在于，对企业开发而言，代码也是一种商业机密。基于保密的目的，支持内网搭建私有服务器成为了必需。以上的管理工具都能够很好地支持这些操作。

　　对于业务的组件化，我们采取了业务模块注册机制来达到解耦合的目的。每个业务模块对外提供相应的业务接口，同时在系统启动的时候向Excalibur系统注册自己模块的Scheme（Excalibur是饿了么移动用来保存Scheme与模块之间映射的系统，同时能根据Scheme进行Class反射返回）。 当其他业务模块对该业务模块有依赖时，从Excalibur系统中获取相关实例，并调用相应接口来实现调用，从而实现了业务模块之间的解耦目的。

　　而在业务组件，即业务模块的内部，则可以根据不同开发人员的偏好，来实现不同的代码架构。如现在讨论得比较火的MVVM, MVP等，都可以在模块内部进行而不影响整体系统架构。

　　这时候的架构看起来更像是这样：

　　EMC架构

　　E(Excalibur)M(Modules)C(Common)架构以高内聚、低耦合为主要的特点，以面向接口编程为出发点，降低了模块与模块之间的联系。

　　该架构的另外一大好处则在于解决了不同系统版本的兼容性问题。这里以iOS平台下的WebView作为例子来进行说明。Apple从iOS8系统开始提供了一套更好的Web支持框架——WebKit，但在iOS7系统下却无法兼容，从而导致Crash。使用此类架构，可以在iOS7系统下仍然注册使用传统的WebView来渲染网页，而在iOS8及其以上系统注册WebKit来作为渲染网页的内核。既避免了Apple严格的审核机制，又达到了动态加载的目的。

　　3Hybrid

　　移动APP的开发有两种不同的路线，NativeAPP和Web APP。这两种路线的区别类似于PC时代开发应用程序时的C/S架构和 B/S架构。

　　以上我们谈到的都属于典型的Native APP，即所有的程序都由本地组件渲染完成。这类APP优点是显而易见的，渲染速度快、用户体验好；缺点同时也十分突出：出现了错误一定要等待下一次用户进行APP更新才能够修复。

　　Web APP的优点恰好就是Native APP的缺点所在，其页面全部采用H5撰写并存放在服务器端。每次进行页面渲染时都从服务器请求最新的页面。一旦页面有错误，服务器端进行更新便能立刻解决。不过其弊端也容易窥见：每次页面都需要请求服务器，造成渲染时等待时间过长，从而导致的用户体验不够完美，并且性能上较Native APP慢了1-2个数量级；与此同时还会导致更多的用户流量消耗。另一个缺点则在于，Web APP在移动端上调用本地的硬件设备存在一定的不便。不过这些弊端也都有相应的解决方案，如PhoneGap将网页提前打包在本地以减少网络的请求时间；同时也提供一系列的插件来访问本地的硬件设备。然而，尽管如此，其渲染速度上还是存在一定的差距。

　　Hybrid APP则是综合了二者优缺点的解决方案。饿了么移动对于此二类APP的观点在于，纯粹展示性的模块会更适合使用Web页面来达到渲染的目的；而更多的数据操作性、动画渲染性的模块则更适合采用Native的方式。

1、使用python开发APP后台要用到tornado框架，因为非阻塞io的原因，性能非常高，特别适合写后端API（App的后端应该都是rest风格的api），而且成熟稳定。

2、APP后台需要部署服务器，这方面涉及到运维、测试、开发诸多方面， 部署和测试推荐几个包：fabric、nose、unittest(python自带)，版本管理推荐git，持续集成推荐使用docker+jenkins。

3、APP后台服务性能需求方面，youtube、reddit、豆瓣、知乎这样的大流量网站都是python写的，所以App的规模不太可能遇到性能问题，即使有也应该不是python的问题，而是任何语言都会有问题。大量的pv是可以靠堆服务器堆出来，如果是计算量比较大的任务，可以考虑用c或c++写。

4、网页前端以及移动端开发后台用python写的API，让前端使用React，就可以轻松解决前后端分离这个问题。

5、现有开源实例子比较少，App后端开源的不常见，而且大部分是rest风格的api，很多时候会涉及到自身的业务和敏感信息也不会开源，所以都要自己从头开始编写。