当前位置：文档库 › 某椒直播App客户端技术演进之路

某椒直播App客户端技术演进之路

摘要：在2017年4月22日举行的『LiveVideoStack Meet 北京：后直播时代技术』沙龙上，北京密境和风科技有限公司（花椒直播）的iOS技术负责人唐赓首次对外分享了花椒直播App端的技术演进过程，涉及到花椒直播从无到有，不断演进中的方方面面，在业务不断的要求下，唐赓和他的团队需要快速试错，找到最适当的技术方案。本文根据唐赓的分享整理而成。

文/ 唐赓

整理/ LiveVideoStack点击观看演讲视频，关注LiveVideoStack，回复『0422资料』，获得此次此次分享的资料下载地址。

本文主要分为以下部分：直播兴起的历史摸索学习阶段基本情况技术问题秀场直播阶段趟过的坑和解决过的问题直播的底层技术互动秀场阶段

在经历了野蛮发展的2016直播大战后，App端的技术扮演越来越重要的角色，好的技术可以让App在大量同质化的直播App中脱颖而出，让用户体验和用户留存率显著提升。互联网老码农、朝阳区老群众唐赓将在本次分享上介绍花椒直播App在手机端技术的探索和实践、以及对未来的展望和思考。本文将涉及265、GPU技术、游戏级交互引擎、人工智

能、深度学习等技术在直播中的应用和展望。一、直播兴起的历史如今，随着直播平台如雨后春笋般的兴起，一旦有大事件发生，新闻采访时都是下面这样的：上面这张图摄于2015年，我们也是其中之一。随着国外直播平台PeriScope 和Meercat的成功，国人也发现了其中的机遇，于是纷纷效仿。映客和花椒是国内起步较早的直播平台，后面又有各种各样的其它平台出现。二、摸索学习阶段基本情况初期，我们的很多基本体验都是基于模仿的，甚至初期我们是完全照搬了MeerCat的模式。最初的内容比较繁杂，囊括了各种信息，包括达人才艺展示、授课、烹饪、杂耍等。基本的交互方式就是点赞、分享、文字交流以及视频，我们对自己的定位就是“视频版微博”，包括界面的整体布局全都是效仿微博的，连按钮位置和页面布局都几乎一模一样。整个页面的主要关注点在Feed流上面。后在滤镜比较火爆的时候，我们又加入了图片滤镜功能，然后又加入了自拍短视频的功能。出于对社交的重视，我们又加入了私信功能。在初期摸索阶段，由于产品经理以及开发人员对整个App的定位缺乏明确的认识，我们只能采取跟风做法，将市场上比较潮流的内容一网打尽，全部加上去。技术问题在这个阶段，大家所解决的都是类似的问题：1、硬编硬解我们分析过映客，结果发现映客所用的硬编硬解代码与我们所使用的一模一样，连临时文件的文件名都一模一样。原因在于：我们所使用的都是

同一套开源代码。最初iOS8还不普及，大多设备都是iOS7系统，想要做硬编硬解只能依赖系统的MovieWriter那套API （从磁盘的MP4临时文件中读取编码结果）。为了解决问题，当时有一个外国人分享了一套开源编码，解决了硬编硬解实现的问题，因此大家全都去用这套开源代码。后来到了iOS8，由于原生支持硬编硬解，这个问题才不复存在。2、看播花屏类似的问题还有很多，现在看起来觉得很基础的问题，当时却是很大的问题，比如看播花屏。丢了一帧再强行解码，就会出现花屏的问题。解决方法很简单，完全丢弃GoP里后续的内容。3、音视频同步根据我们对各家平台的分析，所有直播平台基本都不同步，只不过大家采用的方式各不相同。例如：将音频视频分开采集，并分别通过不同的通道进行传播。在此过程中，我们需要尽量保证音频是连续的，视频相对就没那么重要，这样就会导致音频和视频总有些不同步。解决办法就是保证时间戳准确。我们让QA测试是否同步的简易办法是，利用一支笔敲击桌面，同时在视频的那个瞬间，也必须要有声音发出。相对于对口型等方式，这样的方式更简单也更直接。当然，我们也尝试了很多其它方案，不过利用不同的方案去采集声音，时间戳总会有些问题存在。在这个阶段，我们做了很多尝试，一个个解决掉了这些问题。4、降低看播录播CPU消耗、直播间CPU总消耗起初我们并没有意识到这个问题，结果上线后突然出现了卡顿等

意外。经过深入分析，我们发现这是由于CPU的消耗非常严重引起的。实际应用与测试环境不同，由于实际环境下使用人数众多，点赞、发言、送礼等操作都会对CPU造成巨大的消耗。通过模拟，我们找到了各种各样的性能瓶颈，并一点点地改进。彼时大约有50%的因素是因为客户端CPU消耗太高，导致推流时会出现卡顿。5、回放／回放弹幕优化剩下的问题在于服务端，类似回放、回放的弹幕优化等问题都有可能造成卡顿。有一次我们请了范冰冰来做直播，平时的弹幕文件也就是几兆而已，结果那次弹幕文件的大小达到了200多兆。读取要花费很久，即便读取成功，下载的弹幕文件在载入时也会出现内存超过限制，随后闪退的情况。类似这样的问题层出不穷，我们也只能一个个解决。6、私有协议与公有协议、TCP与UDP在这个阶段，我们摸索了很长一段时间，包括究竟用私有协议还是公有协议，究竟用TCP 还是UDP等等。不过事实上到现在，这些问题仍旧存在。我们的线上还是既有私有协议又有公有协议，既有TCP又有UDP。私有协议的好处在于，我们可以肆无忌惮地加入各种各样的功能，包括对其进行优化，性能调试等，但公有协议的好处在于它支持CDN，各家CDN都可以拿过来直接使用。我们自己的CDN只在国内一些大城市有，像奥运会这样的活动，如果要去巴西，或者要去直播欧洲杯，都要借助其它的CDN。TCP和UDP的问题在于：UDP的性能比TCP好

得多，没有超时重传这些消耗。而且TCP还有一个问题，就是可靠连接的问题。它必须要确保数据到达，一旦出现阻塞，要想放弃的话就只能把链接断掉。7、回放录制，HLS生成一般来说，如果网络不好的话，信息流经常会出现断裂以及缺失。如果录制的回放中有缺失，生成HLS之后，通过一些私有播放器是可以正常播放的，但之前系统的播放器是无法播放这类视频的。当时我们想了很多办法，包括重整时间戳，进行其它的处理，都是为了解决播放的问题。不过现在就没关系了，用我们自己编写的播放器来播放，是始终可以正常播放的。8、秒开放在以前，大家点进去以后等一两秒再打开，都觉得挺快了。但现在来讲，超过三百毫秒都不合格。秒开应当是所有直播软件必备的功能了。在改进时，我们通过抓包分析，了解从点击到视频的第一帧展现之间，都发生了哪些事情，再把所有不必要的东西全部拿掉。例如之前先点进去的话，可能要去找对应的流服务器，需要通过302跳转。而现在在广场上就把类似这些所有的必要信息全都拿到。点击后，原本打开直播间时要加载头像、豆币等内容，但为了实现秒开，这些全部要让道，所有东西必须等到第一帧展现出来以后才开始进行。根据我们的分析，映客App做得更多一些。从手指向上滑的时候就开始切换，当手指落点超过屏幕的1/3后，就会开始加载下一个直播。这样一来，借助偷跑的零点几秒，它的秒开性能更加优越。其它优化问

题还包括CDN优化，使用成熟的CDN厂商会带来更好的效果。比如映客的GoP就是一秒，我们的GoP是两秒，都可能是因为相关的优化问题。9、用户定位、调度至于用户定位和调度的优化问题，有这样的案例：某个人明明在美国，但我们采集到的IP定位显示他在广州，根据分析他实际是使用了广州移动的sim卡漫游到美国。由于移动的原因，我们会显示他的IP在广州。这种情况下，再去对他进行调度，一定会出错。我们经常发生这种事情，比如有人特别卡，我们就会去看他实际所在的位置，是否跟我们将他调度所分配到的服务器不在同一个地方。由于经常发生类似问题，我们也形成了一套比较自动的补救机制。以前都是固定调度，调度以后在直播过程中就不能再更改了。但由于类似错误太多，我们修改了相应机制，使其能够在当直播中重新调度，强制执行一个离用户最近的流服务器。10、VR直播？这个时间段，我们还尝试了VR直播，那段时间VR特别火。为了增加这个功能，我们在客户端增加了VR播放器，结果让安装包又扩大了好几兆，结果并不成功，这个属于我们趟过的坑。

三、秀场直播阶段趟过的坑和解决过的问题1、礼物系统做了大半年之后，我们才找到一个比较好的定位，就是做秀场直播。既然是秀场直播，就得有秀场必须要有的东西，包括各种各样的礼物，连发礼物、全屏礼物、私信礼物，实际上一加上这些东西，就又会遇到各种各样的CPU问题。怎么优

化这些CPU的占用？比如说，像用PNG序列(实现的礼物)----我们一个最大的PNG序列可能会有80帧甚至180帧，全部一起加载的话，一瞬间的CPU占用会非常高。一两秒之内，推流都会停止。类似这种情况，我们都是在性能分析阶段才发现的。采用的解决方案是：让图片加载得慢一点，加几帧之后就停一下。2、金币系统金币系统，我们也走了一些弯路。最早我们用的是单币体系，就是整个世界里交易的只有一种东西，就是花椒豆。我送给你一百豆，你就拿到一百豆，当然最终提现的时候会有一些手续费。但单币体系有一个问题，就是你拿一百豆又可以送给我，我又可以再送给你，我们之间就可以无限刷下去。这样会导致一个结果：在我们的整个体系里，无论经验值还是其它的，只要跟消费量有关的东西，就可以随便刷了。其实大家在上线这个东西的时候，就已经意识到可能会有这样的问题，但由于缺乏经验，最终还是决定上了。之后就发现有人通过各种各样的方式利用这个规则，因此我们赶紧改掉，用双币种的模式，送花椒豆给对方得用币，再用币来买豆或者提现的话，就得有一定的折损。有了这样的游戏规则以后，整个生态环境就变得健康多了。实际上这个弯路走得挺不值的，因为包括YY、映客等App，都早就采用了双币系统。3、附近的人这个也算一个坑。当时这个功能我们都做了，后来又拿下了。原因在于：假设用户位置定得过于精确，会让主播产生顾虑——如果可以定

位到哪个小区，别人在小区门口守着怎么办？以前我们还有一个地图视图，可以在地图上将用户标记出来。虽然有一定的误差，但通过多收集几个手机的数据，就有可能定位到具体的位置。最后，我们还是采用了映客的方式，也就是九宫格头像。在下面稍微标注一下这个人距离你有多远，而且那个数字也是调整过的。地图视图对主播伤害很大，一般有这个功能，他们就不愿意用了。4、美颜功能美颜算是我们做得比较好的一个功能。这个功能并不是我们第一个上的，就手机APP来讲，映客就比我们上得早。之后我们了解了一下，映客用的是虹软的方案，就去找虹软谈。但虹软用的是CPU 方案，所有数据的读取和处理都要凭借CPU，之后再返回。对于本来就很紧张的CPU而言，这个方案会有很大问题。最后，我们用了GPU的方案，直接在GPU内部进行美颜的处理。最早我们尝试了多家不同的方案，上线后让很多主播一个个尝试，看哪个滤镜的美颜效果最好。最后通过实验，换了好几家的方案之后，我们终于找了一家比较好的。以前我们调到最好的状态，就觉得跟映客差不多了，但后来我们找了一个新的解决方案以后，明显感觉比虹软的效果要高一个档次。不过，现在我们所用的美颜方案已经完全是我们自己开发的方案了，这个后面也会提到。这个新方案与之前我们所用的那个效果最好的技术提供商方案，从肉眼上已经看不出区别。这里还有一个很有意思的事情，我们是做技术的，

自己觉得肉眼没有区别。我们换了一款滤镜之后，一丢出去结果就立刻真有主播找过来，问我们是不是换滤镜了，是不是改什么东西了，我要的那个效果没了，也不知道他们是不是有特异功能。我们是完全看不出来什么区别的，最后就只能用算法来做对比，将两个算法摆在一起，用程序去分析红分量、绿分量等各种分量，以及界面上有肤色的地方究竟有什么区别。因为我们所有的工程师用肉眼看完，都觉得没有问题了，只要一丢出去，就立刻有主播找过来，问我们是不是改东西了。目前来讲，我们还是有这个信心的，在美颜这块我们算有比较明显的优势。5、萌颜功能2016年初FaceU 大火的时候，我们就想到了将这个想法插入直播App中。最初的第一个版本仅花费了两天时间就出炉了，用的是苹果自带的人脸识别方案，但做出来的效果与FaceU差距很大，原因在于苹果自带的人脸识别，抖动非常厉害。即使用户和手机都保持静止，系统每一帧所识别出来的图像也会不停抖动，导致人头大小一直变化。经过了解，我们发现FaceU未采用系统自带的方案，而是用了SenseTime的方案。于是我们迅速搜寻相关信息，并积极沟通，购买相关引擎。同时我们也在开发人工智能的相关功能，例如下面写着360人工智能研究院，识别的图片。我们也有针对相关问题，积极组织工程师团队进行攻关。不过短期内我们不可能立刻做出一套能把SenseTime比下去的方案，因此前期我们用的都是

SenseTime的方案。借此解决了几个问题，一个是人脸识别的问题，识别之后在GPU内部进行处理，播放的视频效果就是视频1这样的。最终形成的结果，就是将需要的效果与真实图像叠加在一起。这个问题我们解决得很快，应该是第一个上线这个功能的APP了。具体细节我印象还很深刻，大约2016年初即将过春节的时候，之前的周末我刚把代码写完，第二天立刻找SenseTime去签合同购买引擎。对方的工程师刚上火车，经过协商，对方在火车上给我们Build版本。由于我们自己春节也要赶火车，时间非常紧张。到最后，我还是在火车上继续把代码写完的，然后打包上线这个功能了。当时这也确实是抢了一个先机，算是直播app里第一个上线该功能的，就算到现在来讲，有这个功能的App也不是很多。6、换脸、瘦脸、大眼功能当时我们还做了换脸、瘦脸、大眼这些功能。换脸就是类似下图这样的效果，这个功能我们已经下线了。原因是用了一段时间之后，我们发现整个花椒的直播间在晚上的时候，效果会非常惊悚，整个气氛都不对了。后来这个功能就被下线了。但是瘦脸和大眼的功能现在还是有的，主播现在用的这个版本就可以选择瘦脸和大眼，以及美颜、美白、磨皮程度的。7、K歌/曲库，音效当时在做K歌功能的时候，我们也遇到了很多问题。比如音效功能。话筒讲话会带有一定的混响或音效，比如大礼堂、大房间、小房间这样的。当时我们找了一些解决方案后就匆

匆上线了，实际上有一个问题并未解决，就是实时返听的功能。上线之后，我们就在攻关实时返听的功能，现在看来很简单，在iOS下面根本就不是问题，只要用AudioUnit就可以达到三毫秒以下返听的效果。但当时来说，不拿着K歌软件尝试一下，我们完全体会不出返听效果5毫秒和10毫秒之间差别有多大。根据我们通常的认识，比如打电话，只要差别在一百毫秒之内，我们会认为它是实时的，基本没有问题。但在唱歌的时候，连10毫秒的时差都是难以忍受的。唱歌时耳朵所听到的声音，和自己发出的声音之间相差超过10毫秒，歌手就没法唱下去了。实际上，iOS系统对这个问题解决得比较好，安卓系统并不是所有的手机都会支持，而iOS就可以把这个时差控制在5毫秒之内，用户耳朵里听到的声音跟自己唱得声音几乎是同步的。后来我们还做了变声、变调效果，以及气氛、音效等，基本都是对照着像全民K歌之类的软件，把能做的功能全都做上了。直播底层技术关于直播的底层技术，我们也做了很多尝试。1、降低CPU 的消耗我们做了很多降低CPU消耗的尝试，包括调整在GPU 里处理的画面的大小，让处理的像素少一些。效果非常明显，最下面那根线就是我们改进之后的效果。

之前我们的CPU消耗还是很高的，经过处理后一下子就降了下来。这个问题的解决办法，就是要保证在GPU里，所处理的像素是最少的。因为最终我们要把画面从GPU里拿出

来，放到CPU中进行传输，只要把这个像素压缩小了，读取所消耗的时间也会相应减少许多。2、码率、帧率、分辨率自适应，带宽自适应、崩溃续推当时我们还做了码率、帧率、分辨率的自适应功能，以及带宽自适应、崩溃续推等功能。之前我们遇到画面崩溃的问题，就在考虑续推的解决方案。后来发现，这个问题非常简单，整套直播体系本来就支持这个功能。原因在于：用户的网络本身就会断掉，闪断然后再连上，本身就说明它已经具有这个续推的功能了。网络都断了，又继续新建连接。于是我们就做了一个简单的提示，如果需要续推，我们会提示用户刚刚发生闪退，是否要回到直播间，这就OK了。3、画质改善/清晰度测试（PSNR／静态画质清晰度／动态清晰度）我们还做了许多改善画质的工作。一种是用PSNR这个业内比较直截了当的方式，但我们同时借鉴了单反相机评测的方法，用了一些比较标准化的测试。原本是用来评测单反相机的解析度，后来我们用那个标准，对我们各种各样的算法和处理进行打分。这个功能其实也做了蛮长时间的，应该来讲效果还是比较明显的。四、互动秀场阶段新的尝试1、双人连麦和多人连麦现在我们新加入了双人连麦的功能，实际上最近我们还在做多人连麦的功能，昨天才发了新版。之前我们一直熬夜加班在加这个功能，不过我也不敢保证上线后一定会很好。目前我们做了一些比较激进的策略，比如不连麦的时候，我们会切换到成本比较

低的线路上。一旦真正开始连麦了，再切换回成本比较高的BPG线路上去，当中会发生各种各样的切换，主播要切换、嘉宾要切换、观众那边也得切换，只能等上线后再看效果，再看会有什么问题。这个功能中间还是有很多坑的，因为切换需要CDN厂商的支持，当时我们也是找了CDN与我们一同进行修改。至于后效如何，也只能等着看了。（LiveVideoStack注——唐赓反馈了低成本连麦策略的运行情况：经过一个多月上线运行，稳定性超预期，没有发生需要救火的情况，我们设计的连麦异常自动补救机制有效运行。同时，明显降低了成本，用户连麦活跃度明显增加，连麦推流流量（BGP流量）却降低了，直接减少了5成以上费用，同时对用户体验基本没有影响，没有用户抱怨我们在后台切换线路导致的短时卡顿，完全达到了我们的设计初衷。）2、2D和3D互动礼物如今已经是后秀场时代，我们必须更多地跟主播进行互动，因此我们加了很多东西，包括2D和3D的礼物。然后也尝试了很多游戏引擎之类的内容，实际上熊猫直播也尝试过，他们加了Unity引擎，不过后来失败了。我们需要的引擎，其生命周期应当是与直播间的生命周期接近的，甚至是跟礼物的生命周期接近的，出现礼物包的时候才用，不用的时候就释放掉。但这与游戏引擎的设计理念不符，对Unity这样的3D游戏引擎来讲，中途释放是释放不干净的。后来我们对Cocos2D-X也是做了非常多的改

造，才比较完美地解决了这个问题，包括各种内存泄露、状态清理不干净的问题，当然最终效果还需要大家等待一下，我们很快就会上线。3、多人游戏/PK，语音场控/DJ/主持比较有意思的功能还有一个，就是主播跟观众之间的互动游戏功能。上面的图片实际上是截自YY，他们加了语音场控、DJ、主持人的功能，以及多人游戏、PK这些功能，我们也在努力，尽快上线这些功能。4、多人连麦游戏最近狼人杀等App就用到了12路甚至15路连麦的技术，上图来自于美播，其中的一些思路我们也是可以借鉴的。这些都能让直播间的玩儿法更丰富起来。互动秀场的AI应用

1、绿幕和FABBY抠像我们做的绿幕抠像技术，实际上主播一开始是下面第一张图的情况，背后是绿色的。当他选好背后的背景视频之后，绿幕就会被替换掉，换成第二张那样视频。不过这里有个要求：主播背后必须是一块绿色的背景。我们对这个功能并不是很满意，做完这个功能之后，有一款新的APP出来了，叫做FABBY。它可以在没有绿幕的情况下，就把人像给抠出来。它们所使用的方案是深度学习方案，360研究院也立刻就跟进了，上图是我们做出来一些效果。

2、其他我们还有很多其他研究，包括手势识别、场景识别、物体识别、主播自动分类（性感、清纯等）、画质监控、聊天机器人等。手势识别：在很低的CPU消耗下，系统自动识别出主播的手势，比如比心。引入265简单说一下265，我们

对市场上各种265的解决方案进行了测试，结果发现确实能带来非常明显的带宽节省效果。节省的带宽高达40%甚至54%，这个数字非常夸张了。具体数字如下：896*504，265 300k > 264 500k，带宽节省大于40%

1280*720，265 500k=264 1100k ，带宽节省54%

但是，由于现在H5或者其他的一些分享渠道都必须用到264，我们必须在服务端进行转码。由于对转码集群的需求，会有一定的费用消耗。此外，金山的这个方案本身也非常贵，因此这个方案整体来说也是有一定成本的，并且还需要CDN 厂商的支持，才能将265的内容传递出去。因此，我们需要整体做一个权衡，去考虑损益。不过在目前来看，我们觉得这是未来的一个趋势，而我们也一定会紧跟这个趋势。游戏录屏现在我们还推出了游戏录屏功能，我们所使用的是AIRPLAY的录屏功能，实际上苹果建议使用REPLAYKIT，但由于REPLAYKIT会要求游戏厂商本身要提供支持，我们还是采用了AIRPLAY的方案。这里有个问题：AIRPLAY的方案是苹果明令禁止的，我们在实现时使用了它的私有API，以企业发布的形式发布了采用AIRPLAY的这个版本。人头拾音这也算是个黑科技，如果观众戴上耳机去听的话，会觉得主播是真的在耳边说话。声音会跟随主播从左耳慢慢走到右耳，甚至连触摸耳朵的感觉都能感觉出来，闭上眼睛汗毛都要竖起来了。更多UGC内容我们认为，一个直播平台想

要成功的话，必须要有更多的UGC内容。这点快手就做得非常漂亮，我们的app在内容的丰富度上跟快手相比差太远了，快手上什么都有，有人在展示如何修理iPhone手机，有人在玩儿飞机，有人玩儿多肉植物，有人玩儿玉器，各种各样的内容全都有。而我们的多样性还相距甚远，主要都是妹子唱歌跳舞这些，需要后期等待运营人员的改进。关于分享者

唐赓唐赓，北京密境和风科技有限公司iOS技术负责人，负责直播技术开发与研究，目前工作集中在主播端功能特性开发与优化。在音视频多媒体技术、云计算、系统优化方面有多年工作经验。广告时间『LiveVideoStack Meet：后直播时代技术』系列沙龙来杭州和上海了！

6月17日和6月24日，『LiveVideoStack Meet：后直播时代技术』将分别在杭州和上海举行，淘宝直播的研发负责人陈举锋（丰火）、涂图CTO 邱彦林、又拍云CTO 黄慧攀、即构科技合伙人林君、vipabc研发总监董海冰、喜马拉雅FM 音视频工程师马力、沪江CCtalk技术负责人杨继珩、爱奇艺技术经理周志伟将做分享。网易、蜗牛云直播、B站和声网的讲师还在邀请中。

此外，一如既往的直播技术技能图谱、LiveVideoStack纪念胸针、《WebRTC权威指南》第三版、《H.265/HEVC原理、标准与实现》、小米蓝牙音箱及各种小礼品，还有晚宴和

OpenSpace与专家自由讨论应有尽有。

长按图片识别二维码进入各报名页面，抢30张免费票

APP开发合同通用版范文

合同编号：2021-xx-xx 合同/协议(模板) 合同名称：甲方：乙方：签订时间：签订地点：

APP开发合同通用版范文甲方：____________ 地址：____________ 邮编：____________ 电话：____________ (软件开发实施组织方) 乙方：____________ 乙方公司全名地址：____________乙方公司地址(如有搬动第一时间通知甲方) 邮编：____________ 200063 电话：____________ 乙方公司联系电话双方本着平等自愿、互惠互利、长期合作的原则，根据中华人民共和国《民法典》及相关法律法规于上海市普陀区签订本合同。双方申X，双方都已理解并认可了本合同的所有内容，同意承担各自应承担的权利和义务，忠实地履行本合同。第一条本合同技术开发项目的内容等由附件载明。第二条合同履行期限自________年________月________日至 ________年 ________月 ________日，(包含软件开发、测试、安装和质量保证;该日期仅供参考，实际开始时间以该合同签订生效日期为准);若因需求变动、优化完善产品或其它客观因素原因可能造成延时，经双方协商一致，可以延长该期限(以下统称合同期限)

第三条整个开发周期分四个阶段：____________ 3.1 第一阶段(需求确认与设计)，乙方提供全部UE原型图：____________ 天，UI设计稿：____________ 天。期间甲方需提供给乙方所需要的相关文件(图片，文字，)，若因甲方未及时配合提供相关文件和出现需求变更及反复修改导致延误超时，所延误的时间则按合同规定的总开发周期继续往后延伸，因延误超时导致的所有后果和责任，全权由甲方自行承担。(每三天正面互动)，乙方提供全部UI交给甲方确认，时间：____________ ________年 ________月________日 3.2 第二阶段(封闭开发)：____________第一阶段后，乙方进行程序封闭开发，开发时间：____________ 天，提交给甲方测试，时间为：____________ ________年 ________月 ________日：____________若因甲方未及时配合提供相关文件和出现需求变更及反复修改导致延误超时，所延误的时间则按合同规定的总开发周期继续往后延伸，因延误超时导致的所有后果和责任，全权由甲方自行承担 3.3 第三阶段(软件测试)：____________完成项目最终验收，项目测试至最终验收：____________ 天，交付时间：____________ ________年 ________月 ________日，若因甲方未及时配合提供相关文件和出现需求变更及反复修改导致延误超时，所延误的时间则按合同规定的总开发周期继续往后延伸，因延误超时导致的所有后果和责任，全权由甲方自行承担。

APP开发合作协议(通用版)

APP开发合作协议（通用版）甲方：地址：乙方：地址：风险提示：合作的方式多种多样，如合作设立公司、合作开发软件、合作购销产品等等，不同合作方式涉及到不同的项目内容，相应的协议条款可能大不相同。本协议的条款设置建立在特定项目的基础上，仅供参考。实践中，需要根据双方实际的合作方式、项目内容、权利义务等，修改或重新拟定条款。甲、乙双方经友好协商，甲方委托乙方开发《______________》，以下简称“本软件”，一致同意签订如下合同。一、合作内容甲方委托乙方开发可以在________环境下运行的软件《__________》（以下简称“本软件”），软件需求（以下简称“需求”）双方协商确定。二、合同期限自______年______月_____日始，至______年______月_____日止。并在______年______月_____日之前确定需求。风险提示：应明确约定合作各方的权利义务，以免在项目实际经营中出现扯皮的情形。再次温馨提示：因合作方式、项目内容不一致，各方的权利义务条款也不一致，应根据实际情况进行拟定。

三、甲方权利与义务 1、甲方提出的本软件需求不含有反动、黄色及违反国家法律规定的内容。风险提示：应约定保密及竞业禁止义务，特别是针对项目所涉及的技术、客户资源，以免出现合作一方在项目外以此牟利或从事其他损害项目权益的活动。 2、甲方拥有本软件的使用权、复制权、发行权、出租权。甲方保证对乙方所开发的软件不作篡改，不泄露给第三方等。 3、甲方提出本软件的需求内容作为附件时，必须以书面形式（一式二份且加盖公章）详细地说出需求内容和测试方法（或指标）。 4、甲方负责软件的验收工作。 5、甲方负责按照合同规定及时付款。四、乙方责任 1、本软件是乙方自行研发，保证不是侵权软件。基本内容包括：本软件包括的客户机端app端和服务器端两部分。客户机端app端：开发运行在______环境下的app程序，提供使用说明，并可在______环境下顺利运行。服务器端：开发满足客户机端app需求的服务器端程序，提供管理界面和使用说明，并可以在_____（或者_______）平台下顺利运行。应用平台：本软件客户机端app端经过测试在______下运行正常；服务器端在______环境下运行正常。本软件提供中文简体用户界面。乙方承诺只针对甲方提供的需求开发，不增补任何需求以外的功能。 2、乙方拥有本软件的著作权、署名权、翻译权、许可权、转让权，乙方授权甲方使用权、复制权、发行权、出租权。

APP软件项目外包开发合同范本

编号：_____________ APP软件项目外包开发合同甲方：___________________________ 乙方：___________________________ 签订日期：_______年______月______日

甲方：联系人QQ：乙方：联系人QQ：甲乙双方经协商一致，本着诚实信用、互利互惠的原则，依据《中国人民共和国合同法》，以及相关法规的规定，就甲方开发项目达成如下协议：1. 合作内容 1.1 乙方接受甲方委托，完成甲方提出的的开发工作，本合同中提到的开发工作，是。 1.2 乙方负责开发的产品功能需求，具体内容详见《附表1》。 1.3 开发时间： (1) 启动日期：X年Y月Z日为项目的正式启动日期。 (2) 完成期限：X年Y月Z日完成项目软件系统的交付，乙方可选择提前交付。 2. 双方权利义务 2.1 甲方：（1）甲方应当按照协议，按时向乙方支付开发费用，逾期支付需负违约责任；（2）甲方按照合同规定支付乙方所有开发费用后，即拥有XXX软件系统及其源代码的所有权；（3）甲方需要向乙方提供开发所需要的产品文档、UI设计和服务器端支持等资源或服务；（4）甲方有责任对本协议的内容进行保密；（5）甲方有责任保密乙方的个人信息，不得向第三方泄露。

2.2 乙方：（1）乙方有责任按甲方的要求在规定时间按照所列功能内完成项目开发，完成需要开发的内容；对于甲方在项目开发期间提出的增加或修改内容，双方需另行协商开发费用及开发时间；（2）乙方有责任对本协议的内容进行保密；（3）乙方在完成项目交付，且甲方支付所有开发款项后，按项目代码交付之日起算向甲方提供天的免费维护服务，此维护仅包括软件重大bug的修改及相关代码技术支持，不包括新增的产品功能需求。 3. 费用和支付方式 3.1 费用：此项目开发的现金费用合计为元人民币； 3.2支付方式： (1) 第一阶段：在合同签订之后的日内，甲方向乙方支付项目总费用的 %，即元人民币，第一阶段费用到乙方账户后，项目正式启动。 (2) 第二阶段：在乙方开发完项目、甲方做了项目验收之后，甲方在日内向乙方支付项目总费用的 %，即元人民币。随后乙方提交APP源代码给甲方。 (3) 第三阶段：在甲方完成产品最终功能验收，乙方提供天技术服务支持之后，甲方在日内向乙方支付项目总费用的 %，即元人民币。 (4) 开发延期说明：

APP开发合同样本(标准版).docx

编号：_____________ APP开发合同样本甲方：________________________________________________ 乙方：________________________________________________ 签订日期：_______年______月______日

委托方(甲方)：__________________________ 公司地址：_____________________________ 法定代表人：___________________________ 联系方式：_____________________________ 受托方(乙方)：____________________________ 公司地址：___________________________________ 法定代表人：____________________________ 身份证号：____________________________ 联系方式：____________________________ 根据《中华人民共和国民法典》等相关法律的规定，甲、乙双方经友好协商，就委托乙方开发“软件“，以下简称“本软件“，一致同意签订如下合同。一. 合作内容与软件开发具体要求甲方委托乙方开发“软件“，可以在IOS和___________________________NDROID 环境下运行，开发需求按照本合同附件中的APP开发要求确定。二. 合同期限

1、乙方UI需在本合同签订之日起_____________________________________________________________________ ___日内完成。 2、乙方须在本软件UI完工之日起_____________________________________________________________________ ___日内，乙方必须完成软件demo开发工作。 3、乙方须在本软件UI完工之日起_____________________________________________________________________ ___日内，乙方必须完成软件的初步开发工作，并且开始测试，在_____________________________________________________________________ ___日内完成测试工作。三. 甲方权利与义务 1、甲方提出的本软件需求不含有反动、黄色以及违反国家法律规定的内容。 2、甲方拥有本软件的所有权利，包括但不限于以下权利：所有权、著作权、使用权、复制权、发行权、出租权、署名权、翻译权、许可权、转让权等。乙方不享有以上权利。 3、甲方为乙方提供在APP开发中必要的协助。四. 乙方责任 1、本软件是乙方自行研发，保证不是侵权软件。 2、功能和界面符合甲方要求。

打车APP技术解决方案

打车解决方案需要定制开发一个打车，本文档则分别从功能与技术两个方面介绍了该项目的解决方案。预期目标该项目的想要实现的预期目标其实说起来非常简单，只要通过能够完成叫车服务即可，图描述了该项目的本质需求。打车需求及时出行且获得优惠获得车菠返现推荐殊取織金载客需求增加收入获得车费补曲打车软件均传统电调打不相比: -具有立位功能，方便用户准确报出所在位誉： -具有与词机实时沟迪功龍.方便信息交流，避免不愛要的信息传递错渝-操作更简单，与霸三方支忖公司件柞町实现柱變支廿形成童易闭环与笫三方支付公司合作图项目需求从图中可以看出，本项目的本质需求从大的方面来说其实就三个方面：首先满足用户的打车需求，让用户可以及时获取出行服务，并且可以享受到一些优惠活动。其次要满足司机的载客需求，降低出租车的空载率，增加司机的收入。最后，如果可以，最终在线上完成支出操作，使得可以更好的管理出租车司机。这里可以通过与第三方支付进行合作达到目的。为了可以更好达成以上需求，通过这三个本质的需求可以引申出来一些周边的辅助需求，主要有一下几点：在匹配用户和司机双方的供需信息时，可以增加一些语音功能，不仅使得用户操作更方便，也使得司机可以在不影响开车的情况下或许信息。增加加价功能，在用户与司机双方认可的前提下，如果遇到比较极端的出行服务，可以适当的

进行加价，这样可以更高的调动司机的积极性，并且对用户来说也不失公允。在使用完订车服务后，可以增加评价功能，完成评价体系，可以让更好的司机以及更好的乘客脱颖而出，也为出租车公司提供了更好的考核依据。提示：以上这些功能只是笔者本暂时想到的，如果还有其他需要改动的需求，可以随时增加或修改。以上这些所有的需求点，在移动互联网时代，通过打车的定位功能可以非常高效的满足以上所有的需求。功能框架通过对预期目标的需求分析，可以很容易的得出本项目的需要实现的功能，图给出了本项目所有功能点的框架图。司机企业管理员图本项目功能框架图图详细给出了本项目的功能框架，从大的方面来说可以分为三个端口，分别是司机端、用户端以及企业管理端。提示：以上功能点只是暂时建议的功能点，除了几个核心的功能点之外，其余所有的辅助功能点都是选购的，例如运营功能，可以后期根据委托方具体的运营需求再进行确定。司机端司机端是出租车司机操作的平台，主要用来满足司机载客的需求，使得出租车的空车率得到降低。司机端主要包含以下几个功能点：一键抢单：当用户发布叫车需求后，临近的可以满足服务的出租车司机可以进行抢单操作，有且只会有个司机抢到订单。该功能是司机端的核心功能之一语音读单：出租车司机大部分时间是无法去阅读订单内容的，也无法操作手机的，语音读单可以帮助司机更及时方便的了解叫单的内容。管理功能：其中包括我的订单，我的账务，我的消息以及司机服务排名，这些功能可以帮助司机更好的维护自己的服务历史记录。用户司机肓理 1 1 官网管理订单 as 莒珂檢右功能第三方第三方

APP开发合同范本(标准版).docx

编号：_________________ APP开发合同范本甲方：________________________________________________ 乙方：________________________________________________ 签订日期：_________年______月______日

甲方：________________________________(以下简称甲方) 地址：_______________________________________________ 法定代表人：_____________联系电话：_______________ 乙方：(以下简称乙方) 地址：_______________________________________________ 法定代表人：联系电话：甲、乙双方经友好协议，就甲方委托乙方开发《____________________________________》(以下简称"本软件")的事宜达成一致并同意订本合同。一、项目内容 1. 甲方委托乙方开发的软件《_XX系统APP,安卓系统APP,网络平台__》(以下简称"本三个软件") 在安卓，XX，PC环境下运行的软件，本三个软件需求(以下简称"需求")双方协商确定。

2.本合同APP和网络平台应用开发的栏目架构及相关功能开发细节由《APP和网络平台开发需求表》载明。二、合同价款和付款方式 1.本合同总价款包括乙方相关的税费及软件开发期间办理相关手续的所有费用。该价款为固定包干价，除上述款项外，甲方无需支付任何其它款项。 2.付款方式：前期不要源码的甲方总支付乙方费用是27500元，预付定金为10000元，软件和平台做好交付可以使用付清前期不要源码的费用的余额17500(留3000元质保金)，即14500元后期甲方要回乙方源码，乙方要另加收甲方27500元费用，并付清3000元的质保金三、开发进度自合同签订日起，甲方把钥匙交给乙方匹配乙方将在_____30_______个工作日内完成客户端开发，此时间并包括审核和测试时间。乙方的工作时间从本合同签订之日的次日起开始计算。

APP客户端开发合同

项目开发合同甲方： ___________________ 号：___________________________________ 乙方： ___________________ 号：___________________________________ 甲乙双方在平等互利的原则下，建立合作伙伴关系，就XXiOS客户端以及安卓客户端的开发达成合作协议具体细则如下：第一条合同容: 1.1 甲方委托乙方负责XXiOS客户端以及安卓客户端开发事宜 1.2 乙方负责的容包括如下： 1.2.1 乙方的开发周期为九十天（自开发项目订金付款日起算）。 1.2.2 乙方需按双方约定项目结束时提供相应的安装文件、项目源代码、项目文档（iOS端发布到appstore ）。 1.2.3 程序的开发执行费用，按照双方协商达成协议，费用总额为叁万元整人民币。 1.2.4 项目验收：开发完毕后，乙方提供的程序安装文件进行测试，由甲方参与测试，通过后发布到相应的应用渠道（appstore、安卓市场）

1.3 费用结算方式: 1.3.1 预付款：甲方需在签订合同后三个工作日支付预付款，为费用总额的 50%即人民币__________ 元整。 1.3.2 二期款：乙方提交安装包以及甲方通过测试后（即发布后）的三个工作日向乙方支付30%勺费用，即人民币__________ 元整。 1.3.3 项目完成验收后：项目上线后如无明显漏洞，甲方需付给乙方剩余20%的费用，即人民币 _________ 元整。 1.4 完成制作后期维护：乙方在为甲方程序制作完成验收后的半年，如果程序发现功能性bug，需要进行维护。 1.5 乙方收款账户信息：户名：开户行：账号：甲方的责任 2.1 甲方需要在五月三十号提供整个项目的设计稿，在乙方提交接口文档后的二十日提供所有接口以及切图，如由于甲方的进度问题造成乙方的项目延期，乙方无需负责。 2.2 定期沟通，议定设计制作方案。

APP开发合同

APPLE ITUNES APP 软件开发合同甲方：乙方：甲、乙双方经友好协商，甲方委托乙方开发《_________________》，以下简称“本软件”，一致同意签订如下合同。一、合作内容甲方委托乙方开发可以在美国苹果公司iPhone和iPad环境下运行的软件《_________________》（以下简称“本软件”），软件需求（以下简称“需求”）双方协商确定。二、合同期限自2011年11月___日始，至201__年___月___日止。并在____年___月___日之前确定需求。三、甲方权利与义务 1.甲方提出的本软件需求不含有反动、黄色及违反国家法律规定的内容。 2.甲方拥有本软件的使用权、复制权、发行权、出租权。甲方保证对乙方所开发的软件不作篡改，不泄露给第三方等。 3.甲方提出本软件的需求内容作为附件时，必须以书面形式（一式二份且加盖公章）详细地说出需求内容和测试方法（或指标）。 4.甲方负责软件的验收工作。 5.甲方负责按照合同规定及时付款。四、乙方责任 1.本软件是乙方自行研发，保证不是侵权软件。基本内容包括：本软件包括的客户机端APP端和服务器端两部分。

●客户机端APP端：开发运行在iPhone、iPad环境下的APP程序，提供使用说明，并可在iOS 5.0.1环境下顺利运行。 ●服务器端：开发满足客户机端APP需求的服务器端程序，提供管理界面和使用说明，并可以在Windows XP(或者Windows Server 2003) 平台下顺利运行。 ●应用平台：本软件客户机端APP端经过测试在iOS 5.0.1下运行正常；服务器端在Windows环境下运行正常。 ●本软件提供中文简体用户界面。 ●乙方承诺只针对甲方提供的需求开发，不增补任何需求以外的功能。 2.乙方拥有本软件的著作权、署名权、翻译权、许可权、转让权，乙方授权甲方使用权、复制权、发行权、出租权。 3.乙方只负责开发并向甲方交付软件，不提供iTunes软件商店审核、销售服务。 4.乙方不承诺在“越狱”设备上正确运行。 5.当甲方增加或者修改需求时，乙方有权利每次收取不低于本合同总金额 20%，不高于50%的服务费用。 6.乙方在交付软件时，对甲方提供相关技术培训。五、验收标准 1.甲乙双方验收时，甲方按照需求标定的指标验收，没有指标的以运行甲方测试数据结果的正确与否为依据。 2.乙方完成软件工作，甲方应在三日内组织验收。甲方超过七日不验收，视为验收合格、通过。六、费用结算方式 1.该软件甲方付给乙方费用总金额_____________元整。 2.甲乙双方签订合同当日，甲方将预付保证金_________元整(占总造价 30%)。 3.乙方交付软件当日，甲方验收合格后付甲方人民币_________元整(占总造价_70_%)。 4.甲方收取完开发费用后，免费为乙方维护软件叁个月。

APP软件开发维护服务合同模板

软件开发维护服务合同合同编号：甲方：法定代表人：联系地址：联系电话：电子邮箱：乙方：XXXX有限公司法定代表人：联系地址：联系电话：电子邮箱：根据《中华人民共和国合同法》及其他有关法律、法规及规章，甲乙双方本着平等互利、公平自愿的原则，经双方友好协商就乙方向甲方提供定制开发专业系统软件服务、后续维护服务及相关事宜(以下简称“项目”)达成如下协议，以供双方共同遵守执行，具体内容如下：第一条项目概况 1.项目名称： 2.项目内容：乙方向甲方提供适用于ISO系统及Android系统的手机软件产品，具体功能模块详见《项目需求规格说明书》（附件一）；并提供年的后续维护服务，具体维护服务内容详见《项目维护服务明细》（附件四）。第二条项目开发进度依据本合同第一条约定的项目开发内容，乙方在甲方向乙方支付首笔款项后

应按照以下项目开发进度展开工作，若《项目需求规格说明书》内容超过本合同约定的项目内容，双方可重新约定上述开发周期及项目开发进度。 1.第一阶段:项目需求调研工作内容:乙方应与甲方部门相关人员进行需求沟通，并与甲方就项目实际需求进行讨论分析，分析后描述项目实际需求内容。工作成果:乙方向甲方提交《项目需求规格说明书》，甲方应按照合同约定进行书面确认。经甲乙双方确认的《项目需求规格说明书》应作为本合同的附件一。 2.第二阶段:系统开发设计工作内容:乙方应在甲方签字确认《项目需求规格说明书》并提交软件开发所需的所有素材（包括但不限文字、音频、图片、视频等）之日起个工作日内，依据《项目需求规格说明书》的描述完成软件开发工作，并将软件交付给甲方；若甲方对软件功能有异议，则甲方应于签收《系统功能测试报告》之日起3 个工作日提出书面异议；若甲方逾期未提出书面异议，则视为甲方对乙方开发并交付的软件无异议，且乙方完成第二阶段工作。工作成果:乙方向甲方提交《系统功能测试报告》，经甲乙双方确认的《系统功能测试报告》应作为本合同的附件二。 3、第三阶段:上线运行工作内容:辅助将软件发布至苹果应用商店（App Store）、安卓腾讯应用宝、百度手机应用市场；苹果应用商店（App Store）上架费为，安卓腾

(完整)app开发合同范本

app开发合同范本合伙开发app需要签定合同，如何起草app开发合同？下面请参考小编给大家整理收集的app开发合同范本，希望对大家有帮助。 app开发合同范本1 甲方：乙方：甲、乙双方经友好协商，甲方委托乙方开发《xxxxxxxxxx》，以下简称“本软件”，一致同意签订如下合同。一、合作内容甲方委托乙方开发可以在美国苹果公司iPhone和iPad 环境下运行的软件《xxxxxxxxxx》，软件需求双方协商确定。二、合同期限自20XX年11月xx日始，至201年xx月xx日止。并在xx年xx月xx日之前确定需求。三、甲方权利与义务 1. 甲方提出的本软件需求不含有反动、黄色及违反国家法律规定的内容。 2. 甲方拥有本软件的使用权、复制权、发行权、出租权。甲方保证对乙方所开发的软件不作篡改，不泄露给第三方等。 3. 甲方提出本软件的需求内容作为附件时，必须以书

面形式详细地说出需求内容和测试方法。 4. 甲方负责软件的验收工作。 5. 甲方负责按照合同规定及时付款。四、乙方责任 1. 本软件是乙方自行研发，保证不是侵权软件。基本内容包括：本软件包括的客户机端APP端和服务器端两部分。客户机端APP端：开发运行在iPhone、iPad环境下的APP 程序，提供使用说明，并可在iOS 环境下顺利运行。服务器端：开发满足客户机端APP需求的服务器端程序，提供管理界面和使用说明，并可以在Windows XP(或者Windows Server 20XX)平台下顺利运行。应用平台：本软件客户机端APP端经过测试在iOS 下运行正常；服务器端在Windows环境下运行正常。本软件提供中文简体用户界面。乙方承诺只针对甲方提供的需求开发，不增补任何需求以外的功能。 2. 乙方拥有本软件的著作权、署名权、翻译权、许可权、转让权，乙方授权甲方使用权、复制权、发行权、出租权。 3. 乙方只负责开发并向甲方交付软件，不提供iTunes 软件商店审核、销售服务。 4. 乙方不承诺在“越狱”设备上正确运行。 5. 当甲方增加或者修改需求时，乙方有权利每次收取不低于本合同总金额20%，不高于50%的服务费用。

企业APP解决方案

企业APP解决方案广州企业APP开发公司【商侣软件】，转载企业APP解决方案。适用范围 ?本方案适用于各行业企业APP、集团APP，达到宣传企业品牌、宣传企业产品的目的。方案描述全方位展示您的企业 ?我们将您的企业放在了客户的口袋里，将你的品牌、服务深植于客户心中，便携的同时更易宣传，这是一个提高企业品牌知名度的强势手段。将企业历史、企业文化、企业团队、企业地理位置以及企业旗下品牌等等，深入人心。产品展示平台 ?我们将您的商品移植到手机中，客户可以随时随地浏览您的商品；同时在客户最感兴趣的时候利用手机直接拨号咨询。代理加盟平台 ?客户直接在手机上了解到企业最新的代理商加盟政策，提交加盟需求，有利地增强了产业销售链。代理加盟平台 ?客户直接在手机上了解到企业最新的代理商供应商供应公告，提交供应信息，有利地增强了企业的供应链。即时消息推送 ?打破传统邮件短信营销方式，无论是Iphone还是Android您将可以随时将最新促销活动推送到客户的手机桌面，这将获得比传统推广方式提高5~10倍的推广效果。线上线下完美互动 ?我们帮助您线上线下紧密结合，与客户实现完美互动。主要功能手机客户端 ?企业宣传：包括企业介绍、企业地址、企业旗下品牌以及企业文化等功能?商品展示宣传：包括商家介绍、商品展示及促销信息等功能 ?加盟宣传：包括加盟政策、加盟条件、提交加盟需求等功能 ?供应链宣传：包括供应政策、加入供应条件、提交供应需求等功能 ?应用推广：包括Web应用下载专题页面及主流应用市场发布应用等服务平台服务端 ?企业信息管理：管理企业信息、企业地址、企业介绍、企业旗下品牌以及企业文化 ?商品管理：维护商品信息，实时发布商品 ?加盟信息管理：处理客户提交过来的加盟信息 ?供应信息管理：处理客户提交过来的供应信息 ?短信平台：提供业务短信通知及短信营销服务

APP软件开发合同模板

软件项目开发合同甲方：乙方：地址：地址：联系人：联系人：电话：电话：第一条总则 1)甲方选择乙方为其开发软件，乙方将在之前推出未上线的测试版本，之后根据甲方的要求完善优化，并在之前推出完整功能的版本（争取同时提交到应用商店），具体需求详见本合同的附件一。 2)甲、乙双方经友好协商，根据《中华人民共和国合同法》等有关法规，就乙方承担甲方信息系统开发项目事宜，达成以下协议条款。 3)甲乙双方各指定两名对接联络人负责协调各自的工作开展，甲方指定联络人：，乙方指定联络人：。 4)本合同中所用术语的定义如下：服务由乙方提供的需求分析、软件开发、测试，以及咨询、计划、实施、培训、安装、调试、维护、升级等服务。规范软件系统在功能、操作、环境及性能等方面要求的周密而完整的说明。任务为完成“合同范围”所述服务而进行的相关活动。第二条费用和支付方式 1)合同总金额为人民币元整（大写元整），作为整个项目的开发费用，甲方须在本合同签订之日先付人民币元整（大写元整）给乙方作为开发启动资金；乙方完成内测版本的开发后，甲方再支付给乙方人民币元整（大写元整）；待甲方确认乙方在约定时间内符合合同附件的所有要求后，再支付给乙方余款，即人民币元整（大写元整），乙方须在收到甲方全部款项后的两个工作日内把所有源码和开发文档移交给甲方的指定联络人。 2) 甲方向乙方支付的费用，除另有规定外，所有费用的支付币种为人民币，由甲方按双方事先约定的付款方式（支付宝或银行卡号）划入乙方指定的帐户中，税务由甲方承担。第三条需求变更 1)任何一方要求对合同内容进行变更时，所有的变更要求都必须以电子版文档或书面的形式提交，并经双方指定联络人在线文字约定或书面签字同意。 2)对合同内容的任何变更都可能导致对预定计划、可交付资料或费用的变更。根据变更要求的范围和复杂程度，乙方应对实现变更要求的工作而相应增加或减少收取费用，并将预计发生费用以书面形式通知甲方，待甲方确认后执行。

手机APP开发合同

手机A P P开发合同(总5页) -CAL-FENGHAI.-(YICAI)-Company One1 -CAL-本页仅作为文档封面，使用请直接删除

手机客户端开发合同甲方：联系人：联系电话：乙方：联系人：联系电话：甲、乙双方经友好协商，甲方委托乙方开发《》以下简称“本软件”，一致同意签订此《开发合同》，条款如下：一、合作内容 1． APP制作 1.1提供适用于iOS及Android系统手机的APP手机客户端； 1.2搭建APP管理后台； 2． APP服务 2.1 APP发布服务： 2.1.1 APP发布至IOS系统及ANROID系统各一个应用市场； 2.1.2 根据甲方的需求将APP发布至其他应用市场； 2.2 APP运行服务 2.2.1 APP运行的硬件环境；

2.2.2 APP运行的软件系统； 2.3 APP另付费升级服务： 2.3.1 APP功能的更新升级； 2.3.2 APP性能及视觉的更新升级； 2.3.3 APP对终端设备的兼容升级。注：更多需求，根据客户需求，另行订价。 2.4 APP售后服务： 2.3.1 APP使用培训； 2.3.2 APP管理后台培训； 2.3.3 APP使用咨询服务； 2.3.4 APP下载二维码生成。二、开发周期 1．开发流程 1.1需求确定 1.2 App主要功能设计 1.3 App的界面构思和设计 1.4 大功能模块代码编写 1.5 界面模块编写 1.6 Demo确认 1.7 UC美化 1.8 上线前测试 1.9 UI美化

1.10完成交付 2．服务条款 2.1 合同签订之日起（__________）个工作日内甲方向乙方提供APP制作所需的素材； 2.2 乙方在收到甲方全部素材后（__________）个工作日内向甲方交付APP并开始提供相应的APP服务； 2.3 甲方提交素材迟延，乙方交付APP的时间亦相应顺延； 2.4 甲方确认接收APP的时日，为乙方向甲方提供APP服务的起始日。三、验收标准 1．甲乙双方验收时，甲方按照需求标定的指标验收，没有指标的以运行甲方测试数据结果的正确与否为依据。 2. 乙方完成软件工作，甲方应在七日内组织验收。四、双方陈述及保证 1. 双方均是根据中华人民共和国相关法律合法设立并有效存续的法人或经济体，同时完整地享有法定的民事权利能力和民事行为能力，能行使《开发合同》的权利和履行《开发合同》的义务。同时，双方在履行义务时，不违反任何法律，也不会侵犯乙方以外任何第三方的合法权益； 2. 双方均拥有合法资质从事《开发合同》的合作； 3．双方的法定代表人或授权代表已获得法定资格或充分授权可代表签署《开发合同》。

技术类app策划书

技术类app策划书 APP产品策划书一、项目简介（一）项目背景（二）市场机会（三）成功关键二、APP产品/服务三、目标市场分析与竞争优势四、目标市场和需求（一）消费人群定位（二）竞争优势（三）盈利模式

五、知识产权六、战略和计划七、SWOT分析 .. 八财务计划九、风险评估（一）技术风险（二）政策风险十、其他因素. 十一、风险资本的退出一、项目简介_技术类app策划书。 (一)项目背景：

__数据显示，截至xx年底，我国60岁及以上老年人口已达1.94亿，占总人口的14.3%，预计在xx年将突破2亿，2034年突破4亿，2054年突破 4.72亿。随着国内老龄化问题的加重，政府部门除了将子女探亲立法之外，还开始注意到，新一代的智能手机对这个问题具备解决能力。，xx年一季度国内智能手机用户中，年龄在50岁以上的占比高达15%，老年群体逐渐进入安卓的网络世界。但是一方面老年群体对智能手机APP应用的需求日益增加，另一方面国内专门针对老年人量身定做的app应用十分稀缺，于是就促使了我设计这一款专门为老年人服务娱乐生活的APP，让他们也可以跟随时代的潮流，享受到智能手机带来的便利与乐趣，而不只是死板单调的老人机。（二）市场机会：近年来，国内 APP 市场呈现爆炸式增长。随着3G 的普及、手机应用的丰富和智能化的不断提升，以随身性和便携性考量，手机给用户带来的互动性体验是电脑不能比拟的。随着 Android/苹果等智能机的出现，更多的应用进入手机，微博、客户端软件、手机游戏等新应用大大提升用户的手机娱乐体验。用户上行数据成为手机互联网的显著特征。可以预见，手机互动娱乐体验超越电脑已为时不远，手机

手机APP开发合同协议书

手机A P P开发合同协议书文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-

手机客户端开发合同甲方：联系人：联系电话：乙方：联系人：联系电话：甲、乙双方经友好协商，甲方委托乙方开发《》以下简称“本软件”，一致同意签订此《开发合同》，条款如下：一、合作内容 1．APP制作 1.1提供适用于iOS及Android系统手机的APP手机客户端； 1.2搭建APP管理后台； 2．APP服务 2.1APP发布服务： 2.1.1APP发布至IOS系统及ANROID系统各一个应用市场； 2.1.2根据甲方的需求将APP发布至其他应用市场； 2.2APP运行服务 2.2.1APP运行的硬件环境； 2.2.2APP运行的软件系统； 2.3APP另付费升级服务： 2.3.1APP功能的更新升级；

2.3.2APP性能及视觉的更新升级； 2.3.3APP对终端设备的兼容升级。注：更多需求，根据客户需求，另行订价。 2.4APP售后服务： 2.3.1APP使用培训； 2.3.2APP管理后台培训； 2.3.3APP使用咨询服务； 2.3.4APP下载二维码生成。二、开发周期 1．开发流程 1.1需求确定 1.2App主要功能设计 1.3App的界面构思和设计 1.4大功能模块代码编写 1.5界面模块编写 1.6Demo确认 1.7UC美化 1.8上线前测试 1.9UI美化 1.10完成交付 2．服务条款

2.1合同签订之日起（__________）个工作日内甲方向乙方提供APP制作所需的素材； 2.2乙方在收到甲方全部素材后（__________）个工作日内向甲方交付APP并开始提供相应的APP服务； 2.3甲方提交素材迟延，乙方交付APP的时间亦相应顺延； 2.4甲方确认接收APP的时日，为乙方向甲方提供APP服务的起始日。三、验收标准 1．甲乙双方验收时，甲方按照需求标定的指标验收，没有指标的以运行甲方测试数据结果的正确与否为依据。 2.乙方完成软件工作，甲方应在七日内组织验收。四、双方陈述及保证 1.双方均是根据中华人民共和国相关法律合法设立并有效存续的法人或经济体，同时完整地享有法定的民事权利能力和民事行为能力，能行使《开发合同》的权利和履行《开发合同》的义务。同时，双方在履行义务时，不违反任何法律，也不会侵犯乙方以外任何第三方的合法权益； 2.双方均拥有合法资质从事《开发合同》的合作； 3．双方的法定代表人或授权代表已获得法定资格或充分授权可代表签署《开发合同》。五、甲乙双方的权利、义务

APP软件项目开发合同

甲方：____________________________________ 乙方：____________________________________ 第一条总则 1)甲方选择乙方为其开发软件系统，乙方将在甲方规定的时间内，根据甲方要为甲方开发___________________软件系统。 2)甲、乙双方经友好协商，根据《中华人民共和国合同法》等有关法规，就乙方承担甲方信息系统开发项目事宜，达成以下协议条款。 3)本合同中所用术语的定义如下：服务由乙方提供的项目管理、需求分析、软件开发、测试，以及咨询、计划、实施、培训、安装、调试、维护、升级等服务。规范信息系统在功能、操作、环境及性能等方面要求的周密而完整的说明。任务为完成“合同范围”所述服务而进行的相关活动。第二条价格 1)合同总金额为RMB￥_________万元，计人民币_______整，作为系统的开发费用。 2)甲方向乙方支付的费用，除另有规定外，所有费用的支付币种为人民币(_________￥)，由甲方按本合同规定的付款方式以电汇或支票划入乙方指定的开户银行帐户中。第三条变更 1)任何一方要求对合同内容进行变更时，所有的变更要求都必须以书面形式提交并经双方签字同意。 2)对合同内容的任何变更都可能导致对预定计划、可交付资料或费用的变更。根据变

更要求的范围和复杂程度，乙方应对实现变更要求的工作而相应增加或减少收取费用，并将预计发生费用以书面形式通知甲方，待甲方确认后执行。第四条知识产权约定 1)除非另有规定，本合同中乙方向甲方售出的产品（包括源码、程序、文件、文档资料），所有权和版权属乙方。未经乙方许可，甲方不得公布文件、源码，不得复制、传播、反编译、出售、出租或者许可他人使用其相关的程序、文件、源码和反编译等。 2)乙方保证所售出的产品享有合法的权利，没有侵犯任何第三方的权利。 3)甲方只能按乙方的规定享有相关产品的使用、升级、开发、转让等权利。如果甲方违反乙方的规定和国家法律规定，应承担相关的法律责任。第五条保密 1)双方不得向第三者泄露本协议的任何内容。 2)双方按本合同规定相互提供和提交的全部文件资料，凡涉及需要保密的，以预先说明的有关条款为据。并且任何一方在没有经过另一方书面同意的情况下，不能将另一方的保密资料（如技术资料、用户信息）透露给第三者。第六条合同的解除 1)任意一方欲提前解除本合同，应提前通知对方，经双方协商签字同意后方可解除。甲方要求解除合同，无权要求乙方返还甲方向乙方已支付的费用，并应对乙方遭受的损失承担赔偿责任；乙方要求解除合同，应返还甲方已支付的费用，并赔偿由此引起甲方的损失。 2)订立本合同所依据的客观情况发生重大变化，致使本合同无法履行的，经双方协商