Html5与APP开发比较心得

第一篇：Html5与APP开发比较心得

Html5与APP开发比较心得

引言

大量新生移动设备的兴起，改变了当今互联网的格局。在技术的发展上，HTML5会取代 App 应用吗？或者说能够在多大程度上取代呢？在 HTML5 规范中，已经加入了相机、磁力罗盘、GPS 信息的支持。很多新兴浏览器也已经开始支持这些新特性。能否用一个统一的 HTML5 来替代 Android 和 iOS 并行开发的双重成本呢？详细分析了 HTML5 和本地 App 的优缺点。

以下为文章原文：

移动应用程序(App)和 HTML5 都是目前最火的技术，二者之间也有不少重叠之处。在移动设备浏览器里运行的 HTML5 的 Web 页面，也可以重新打包成不同平台上运行的 App。目前很多浏览器都有很好的跨平台支持性能，HTML5的 Web 方案，对开发者来说更为方便。完成一次开发，即可多平台使用。但这确实可行吗？目前，仍有许多原因，使开发者选择了 App 开发。很明显，很多人已经在这么做了。本文将详细分析这两种方案的优劣。

1、功能丰富

正方：App 里可以开发出更丰富的功能。我们把移动功能分成两类。程序本身和程序与系统的结合。比如在 Android 里，加入 Widget 图标或者通知提醒之类的。App 对这两者都没问题。不用多说，这是肯定的。

反方：虽然 APP 发展迅猛，但 Web 也正在迎头跟进。确实很多原生 App 实现的功能是 HTML5 望尘莫及的。不管你的 Web 做的再好，如果停留在一个没有摄像头支持的沙盒中，还是无法满足一些功能。幸运的是，现在没有这样的沙盒限制了。如果你需要你的 Web 来照相，可以做一个负责照像的 App，再把你的 Web 打包进这个应用里面。开源的 PhoneGap 框架就是这么做的。

但这种混合开发的问题在于，增加了项目的复杂性，而且不象传统 Web 那样可以直接在浏览器里运行。这个问题短时间内恐怕还无法解决。不过好在现在网络标准在不断的高速扩充，先进的浏览器也在一直跟进。Android 3.1 已经支持 Camera 了。iOS 浏览器也开始支持 WebSocket 和设备方向检测了。

总得来说，移动设备在发展，而 Web 也同样在快速变化。而目前也有 5 家主要浏览器开发商在改进现有标准，丰富新的功能。所以原生 App 在快速前进，同时，Web 也在缩小差距。

2、运行效率

正方：原生 APP 速度更快。原生 APP 没有瓶颈，而且可以直接调用 GPU 加速、使用多线程。

反方：现如今 Web 的速度已经很快，而且多数应用不需要这么快的速度。

这种说法有点落伍了。Chrome 发布之时带来的 Javascript V8，给 Web 访问速度带来质的飞跃。而现在，计算速度变得更快了。

图片处理引擎已经使用 Web 来加速。现在硬件加速也已经开始。让我们看看用上硬件加速的 Canvas 的效果：

如果要开发 3D 游戏，或许速度还不够，但对于普通用户来说，新闻、邮件、时间管理、社交网络，这些用 Web 就已经足够。另外，越来越多的框架结合 WebGL，可以发挥 OpenGL 的优势了。

3、开发感受

正方：原生 APP 易于开发。原生 APP 使用强壮的程序语言（Java, Objective C, C++），适合编写复杂的程序，API 丰富，在桌面环境可以方便的用模拟器进行测试。而 Web 程序的 Runtime 和乱七八糟的各路浏览器让人头疼不已。

反方：一般来说 WEB 更简单一些，特别是需要兼容不同设备的时候。WEB 最初的功能只限于文档展示，而不是程序应用。更何况 Web 不只是静止的，HTML5，CSS3都给开发者极大帮助。虽然你喜欢C++，Java, Javascript，但是现在没人能否认 Javascript 也和前者站在同一擂台上。

浏览器/Runtime 的互不兼容（碎片化），APP 也存在同样的情况。用 Java 写了 Android App，然后又要面对 iOS 的 Objective C。此外还有 WebOS, BlackBerry，Windows Mobile 等。如果能写一个程序，马上能在所有平台上运行，这该多么方便啊。当然，这只是一个理想。要是想让程序在每个平台都能正常的运行，就要做不少调试和妥协。这对很多原生 APP 也是一样的。

所谓的 Web 碎片化，一直都是如此。但好消息是现在已经有很多不错的解决办法。比如 Modernizr 库就可以帮你兼容一大批主流设备，不管是哪种系统平台。有兴趣的话，你可以看看2011年的 Google IO 演示。

4、用户体验

正方：原生 APP 更契合原有平台。操作感受的定义之一，就是用户希望在你的程序里，用与系统连贯统一的方式来操作。不同的平台，都有一些约定俗成的习惯。你不能期望用一套统一的 HTML5 App 去满足所有用户。

此外，整个平台的操作感受都由用平台自有的软件库协调。直接调用平台工具包就能直接免费获得完整支持。

反方：Web 有自己的传统，但如果你想开发带有原有平台那种感觉的 Web，同样可以做出来。前面已经讲过，WEB 开发的方式，是先做一个大体适合所有平台的版本，然后再针对不同平台不断改进。当这些改进主要是针对功能时，你可以选择几个你最关心的平台做优化。类似于 浏览器检测。我们经常可以听到技术论坛里的程序员们，抱怨有太多的浏览器版本要测试。不过如果你优先关注两三种主流平台，是值得为它们多花点时间做优化 的。

Web 本来就有自己的操作感受。我们也可以说，不同的默认浏览器以及运行环境造就了独特的“Web 感受”。从更广的角度看，这本身就是一种用户公认的方式。此外，还有很多成功的案例并不遵循移动设备的原生操作习惯，但却成功了。想想你最喜欢的手机游戏 的界面？很多更传统的 App 也是一样，比如 Twitter 的客户端。

5、传播途径

正方：原生 App 更容易接触客户。像 Google Play 和 Apple Store 这样的 App 商店这几年势不可挡，推动了整个移动行业的发展。每个程序员都能在市场里发布自己的应用。用户都挤在市场里浏览、搜索、接受推荐。不仅如此，只要你的程序 足够好，现有用户的打分会帮助你说服更多新的客户。

反方：其实 Web 才容易接触到客户。通过 Web 找到内容，这是经过论证的可靠途径。利用 URL，每一项发布的内容都有一个独立的地址，包括在网站上发布的应用程序。搜索引擎帮助发现内容，其他网站提供链接，还有一些类似应用市场的分类网站。用户还可以通过邮件、短信和社交网站分享你的链接。你的应用链接可以直接在不同设备上直接打开。

6、收费

正方：App 收费，应天意，顺民生。“六岁孩子在午饭时做的 App，3美刀一个，已经卖出几百万”。最近常听到类似的新闻。各种大小厂商也跟着蜂拥而至，等着圈钱。应用商点帮开发商直接收费。最简单的办法，一次性 收费。也有在 App 里再另行收费或者做订阅收费的，这都帮助开发商赢得长期稳定的回报。

此外，传统网站的广告、赞助，在 App 里也同样适用。

反方：网站赚钱，从来都不是问题。现在机会还会越来越多。Web 能成为现在社会的推动力，有能力用多种方式取得回报，这是基本条件。虽然使用付费并不普遍。但 SaaS 的模式已经相当普及了。成功案例包括 Google Apps 系列产品，各类邮件的收费版等等。另外，直接收费并不是 Web 应用的唯一模式。广告、会员链接、赞助和其他产品服务的交叉推广都是可选的模式。

看着能在应用市场里直接赚钱而眼红的 Web 开发者们，你们不能直接把你的 URL 发进市场，但是做一个浏览 Web 的 App 的壳子来连接到自己的 Web 上怎么样？现在市场中已经有成百上千的 App 正在这样做。有些包装的很好，以至于你甚至都察觉不到它是一个 Web 程序。

以后应用市场会直接支持 Web 程序吗？这个现在还不好说，但 Google 已经建建立了 Chrome Web Store。虽然还只能从桌面电脑放问，但这已经挑起了浏览器厂商的兴趣。

结论

现在还看不出有完胜的一方。有些应用适合做 App，有一些适合用 HTML5。以目前的情况来看，原生 APP 肯定是一个很重要的方向。上面提到的混合式开发，可能是一个不错的妥协方案。能用 Web 的时候用 App 调用 Web，Web 实现不了的功能再用 App 开发。

如果你选择 Web 方式，就要在 Web 标准和不断的改进上用心。Web 技术本身的优点就是能兼容大批不同的操作系统和设备。

第二篇：iOS Web App开发心得(四)

泽思网络 – 上海APP开发商

iOS Web App开发心得

（四）1、关于jQuery

事实上，jQuery已经针对移动设备推出了jQuery Mobile（2012年8月27日注：jQuery和jQuery Mobile完全不是一个东西），但是我没有去下载，而是直接用了jQuery，并没有什么理由。从实际效果来看，也还算理想，mobile safari跑jQuery还算流畅，与桌面浏览器的差异并没有那么夸张。

但是，有一点不完美，就是触控的事件，不能使用jQuery的绑定方式（bind方法），而必须使用javascript的原生语法。猜测应该是jQuery对事件做了封装并做了兼容性处理，没有考虑到触控事件。（2012年8月27日注：完全可以用jQuery来绑定，只是在事件处理的时候取jQuery封闭事件中的originalEvent就可以了。）

2、viewport带来的问题

其实这一点在前面已经讲过，还是想再重复一下。

因为只有viewport的概念，导致了很多和桌面浏览器不一样的地方，比如没有滚动条，需要手工去处理很多事情。

同样因为viewport，元素的fixed定位方式失效。

另外由于viewport自身的操作需要很多触控动作，给交互也带来不小的麻烦，前

泽思网络 – 上海APP开发商文已经说过。

3、iOS自己的处事方式

iOS在一些地方有自己的特殊处理方式，需要注意。

比如不允许用户从浏览器中上传文件，这个特性就让应用的空间一下子少了好多。(2012年8月27日注：iOS6已经允许了。)

再比如对于选择框，并不是像桌面浏览器一样下拉，而是一个系统的模态窗口选择，完全是苹果自己的风格。

4、SVG支持不力

网上查到SVG的嵌入方式有三种，除了iframe外，其余两种均试过，很遗憾，不能生效。

5、背景缩放的bug

按照CSS的标准，背景图片大小是可以缩放的。实际使用时，在有的机器上有明显bug，表现为有时候缩放变为平铺，有时候需要再加一个多点触控才能触发缩放。

第三篇：app开发合同2018

*************

手机APP开发协议书

委托方（下称甲方）： 法定代表人： 注册地址： 联系电话： 电子邮箱：

受托方（下称乙方）： 法定代表人： 注册地址： 联系电话： 电子邮箱：

双方经友好协商，依据《中华人民共和国合同法》的有关规定，就委托乙方开发（以下简称“本软件”）的事宜达成如下协议，以资共 同遵守。第一条 定义

1)甲方选择乙方为其开发软件系统，乙方将在甲方规定的时间内，根据甲方要求，为甲方开发 APP 软件系统。

2)所开发的软件可以在iOS、安卓操作系统下运行的软件，软件需求，App应用开发的项目架构及相关功能开发细节，由双方协商确定，作为本合同附件。3)甲、乙双方经友好协商，根据《中华人民共和国合同法》等有关法规，就乙方承担甲方系统软件开发项目事宜，达成以下协议条款 4)本合同中所用术语的定义如下： 服务 由乙方提供的项目管理、需求分析、软件开发、测试，以及咨询、计划、实施、操作培训、安装、调试、维护、升级等服务。

规范 信息系统在功能、操作、环境及性能等方面要求的周密而完整的说明。

************* 任务 为完成“合同范围”所述服务而进行的相关活动。

指在本软件开发完成后乙方需要交付给甲方的文件，包括但不限于：交付文件 程序文件、编译前的源代码、数据库文件、操作手册、产品制作原型图、技术开发文档等。

第二条 项目内容

甲方委托乙方开发可以在iOS、安卓操作系统下运行的软件，软件需求，app应用开发的栏目架构及相关功能开发细节，由双方协商确定，作为本合同附件。第三条 履行期限

乙方应在本合同签订之日的次日起 45 个工作日即 2017年7月15日之前完成，本软件开发并交付软件和相关文件。乙方可提前交付，并协助甲方进行软件的测试、鉴定工作。第四条 费用及支付

1)本次项目开发费用合计为人民币（币种下同）肆万 元（小写：￥40000.00），甲方按以下方式分期支付：

2)在合同签订之日起5日内甲方向乙方支付合同额的50%金额为 贰万元元（小写： ￥20000.00）；

3)在项目开发十五个工作日内甲方向乙方支付合同额的 50%项目款为

元（小写：￥20000.00）。

第五条 验收

乙方完成本软件开发工作后，甲方应在 十五 个工作日内完成验收，逾期验收的，视为验收合格。第六条 双方权利义务：

6.1 甲方的权利义务

1)甲方有权利督促乙方按规定时间完成项目开发，有增加或修改内容双方需另行协商解决;在不影响进程的情况下，对于甲方的细微规模变动的需求，乙方必须满足;若出现较大幅度的变更，则甲乙双方商议增加开发费用和延长开发周期。2)甲方完全拥有软件系统的所有权，包括使用权、著作权等所有权利;3)甲方应当按照协议，按时向乙方支付开发费用;

************* 4)甲方有责任对本协议的内容进行保密;5)甲方有责任对乙方的软件开发技术进行保密，在未经乙方书面许可的情况下，不得向第三方泄露。

6)甲方从项目成立起，派专人全程跟踪，乙方必须配合。

7)甲方有责任自行向乙方提供或者请求乙方协助提供软件开发所需要的硬件、软件接口、产品需求说明书及必要配合，其中甲方须在合同签订时或合同签订日之后 1工作日内向乙方提供明确的《产品需求说明书》，该《产品需求说明书》内容包括产品的后端和接口说明；

8)甲方有责任保密乙方的个人信息，不得向第三方泄露。

6.2 乙方的权利义务

1)乙方有责任按甲方的要求在规定时间内完成合同项目内容的开发并向甲方提供相关文档，项目开发内容以该合同及产品需求说明书为准，若甲方提供的合同及产品需求说明书未明确说明产品开发需求，则乙方与甲方协商明确完成相关内容开发;2)在项目开发完毕之后，乙方有义务协助甲方软件上线部署，在乙方对甲方提供的维护服务期之内，由于甲方设计变更而导致的变更，若变更范围在本合同所规定的功能范围之内，乙方有义务协助甲方修改变更内容;3)乙方有责任对本协议的内容进行保密;4)乙方有责任对与甲方项目的接口规范进行保密，在未经甲方书面许可的情况下，不得向第三方泄露;5)乙方有责任在项目验收合格完成之后，向甲方提供一年的免费售后服务，此售后服务包括但不限于由于乙方开发原因而导致的功能故障、bug。

6)乙方有责任自行准备软件开发所需的硬件设备、开发资料、安排相关人员配合及 项目启动日起每周向甲方通过邮件或 QQ作为媒介以图片或简单描述报告形式汇报甲方所委托的 APP开发进度。

第七条 保密条款

1)双方不得向第三者泄露本协议的任何内容。

2)双方按本合同规定相互提供和提交的全部文件资料，凡涉及需要保密的，以

************* 预先说明的有关条款为据。并且任何一方在没有经过另一方书面同意的情况下，不能将另一方的保密资料（如技术资料、用户信息）透露给第三者。第八条 合同的解除

1)

任意一方欲提前解除本合同，应提前通知对方，经双方协商签字同意后方可解除。甲方要求解除合同，无权要求乙方返还甲方向乙方已支付的费用，并应对乙方遭受的损失承担赔偿责任；乙方要求解除合同，应返还甲方已支付的费用，并赔偿由此引起甲方的损失。

2)订立本合同所依据的客观情况发生重大变化，致使本合同无法履行的，经双方协商同意，可以变更本合同相关内容或者终止合同的履行。第九条 违约责任

1)甲方每逾期付款一天，应按照乙方开发费用的 5 %支付逾期付款违约金。2)乙方未按时交付的，每逾期一天，甲方将扣除开发费用的 5%作为补偿，如因甲方未提供相关技术资料、调试环境支持、需求沟通不明确等原因，致使乙方延期交付的，乙方不承担违约责任。

3)任何一方不履行或不妥善履行本协议下任何条款被视为违约，守约方有权要求违约方赔偿另一方因违约而造成的一切损失，本合同对违约责任另有约定的，从其约定。

第十条 纠纷解决

本合同履行过程中所发生的争议，双方协商解决；协商不成的，任何一方可向 所在地法院起诉。

第十一条 通知与送达

1)甲方、乙方确认，双方履行本合同的沟通可采取面谈、电话、传真和电邮的方式，本协议所载的双方联系地址、电话和电子邮箱均为真实、有效的联系方式。双方确认，一经向对方发送电邮，即视为收到通知；一方按本协议载明地址所发出的书面文件，自发出之日起七日内视为送达，无论是否签收或拒收。

2)甲方指定本协议的联系人为，联系电话： ；乙方指定本协议的联系人为，联系电话：。甲方、乙方指定的联系人为履行本协议所作出的意思表示和行为均分别代表甲方、乙方。

************* 3)如任一方的联系方式有改变，应在3天内书面通知对方。

第十二条 其他事项

1)双方签订的补充协议、附件系本合同的组成部分，具有同等法律效力。2)本合同自双方签字盖章之日起生效，一式两份，双方各执一份。

3)本协议标题仅供参考之用，并不构成本协议的一部分，亦不得被用以解释本协议。

4)本协议一方延迟或未能行使本协议下的权力、权利或救济不应作为对任何该等权力、权利或救济的弃权。

5)如果本协议的任何条款或规定在任何适用法律下被认定为全部或部分无效或不可强制执行，其应（在该等无效或不可强制执行的范围内）从本协议中被排除，但本协议的所有其他条款和规定均保持全部有效。

（本页以下无正文）

甲方： 乙方： 负责人： 负责人：（签章）（签章）

年 月 日 年 月 日

第四篇：iOS Web App 开发心得(三)：App化

iOS Web App 开发心得

（三）：App化

三、App化

1、放到桌面

其实这个最简单啦，点浏览器的加号，就会有一个菜单，添加到屏幕就行。

2、设置图标和启动画面

添加到屏幕后，默认的是一个白色图标，启动画面则是上次运行时的画面截图（所以感觉不到有启动画面）。

为了更像原生的App，我们添加一下图标和启动画面。

图标的添加方法是在head区添加如下代码：

其中，xpadicon.png是图标，必须为png格式，大小为57*57像素，不需要添加圆角和光影效果，iOS自己会处理。

启动画面的添加方法也差不多：

其中，xpadstartup.png是图标，必须为png格式，纵向图片，iphone/itouch的大小为320*460，ipad为768*1004。

要说明的是，启动画面的时间会很短，而且这个时间似乎是不可控的，个人感觉是在页面ready的时候启动画面消失。

另外，在我试验用的itouch3上，图标和启动画面均未生效，iphone4和ipad上有效。

3、隐藏地址栏

为了更像本地App，我们要隐藏掉地址栏，而在隐藏这个之前，我们必须设定程序全屏，否则无效。

全屏：

隐藏地址栏：

4、控制用户的缩放

作为一个网页，事实上可以无限缩放的（当然，缩小到比viewport还小时会自动充满viewport），而作为一个程序，我们有时候不希望这样的事情发生，如下代码可以解决：

上述代码的意思是，viewport的宽度为设备宽度，initial-scale是初始的缩放值。（按照我的理解，viewport的宽度值和initial-scale这两个属性应该是不可以同时存在的，因为定义了一个值会自动推算出另一个值，比如我将viewport的宽度设为屏幕宽度的2倍，那么initial-scale应该自动为0.5，待验证。）后面两个自然是能缩放的最小和最大值了。

如果不想让用户缩放，则可以将最小值和最大值设为一样，都为1.0，或者直接将user-scalable设为no。

5、离线

到这里，我们的App已经很像原生App了。可是，如果断网了怎么办？

于是，最的一步–离线。离线之后，我们的程序就可以在没有网络的时候正常运行，完全和原生App一样了！

上述的特性都是iOS的，但是离线是HTML5的特性。

要实现离线，首先得有一个先决条件：能修改web服务器的MIME（确切地讲，是MIME中有manifest类型）。关于MIME是什么就不详细介绍了。首先，我们需要在web服务器中将.manifest后缀的MIME设

为”text/cache-manifest”。对IIS，在站点属性中可以设置，对apache，则能直接通过修改.htaccess文件实现。不详述。

接下来，我们需要创建一个离线文件列表，列表中的文件将被缓存供下次使用。

我建立的名叫cache.manifest，内容如下：

CACHE MANIFEST

# xpad v0.1.0009

# 指明缓存入口

CACHE:

index.html

index.css

jquery.js

xpadicon.png

xpadstartup.png

images/pic.png

# 以下资源必须在线访问

NETWORK:

login.php

# 如果index.php无法访问则用404.html代替

FALLBACK:

/index.php /404.html

#开头的是注释，这个好理解。文件分为三段：CACHE、NETWORK、FALLBACK。CACHE表示要缓存的文件，即可以离线使用的资源，可以看到，html/css/js/pic都可以缓存，当然，其他类型的也可以。

NETWORK表示必须在线访问的，例如登录之类的页面。

FALLBACK表示如果在线访问失败时，用什么文件替换。上面的代码表示

index.php访问失败时用404.html替换。这个可以用在网络不好的时候，例如一个离线应用去访问一个在线页面，但是没有访问成功，这时就可以调用一个已经离线了的页面去，不破坏用户体验。

再接下来，就是告诉iOS，我们的程序需要离线，方法是在访问的页面中的html标签中加入一个属性标记上面说的manifest文件：

访问一次，只要文件传输完毕，我们的应用就成功离线啦！这时断开网络再次打开，依然可以使用！

App化的操作基本都完成啦，可以先喝口茶休息下。

接下来呢？接下来你可能会修改你的页面，但是，悲剧来了，你发现无论你怎么刷新，页面都没有变化，即使清掉缓存也不行。

事实上，更改页面文件并不会导致离线文件也更新，而清掉缓存也不会清掉离线的文件！

更新缓存的条件是：.manifest内容发生变化！所以如你看到那样，我在最前面加入了版本，这样一方面可以标版本，另一方面刚好让程序更新缓存。

我们的Web App在打开时会检测更新，但是，本次打开使用的仍然会是老版本，如果更新完成，再刷新或者再次启动会是新版本，而如果更新过程未完成，则仍然是老版本。这中间不会有任何提示。

（当然，可以用脚本更新，不详述。）

至此，一个完美的Web App就诞生了！

现在唯一的局限就是技术限制了–网页不可能调用系统的API，如文件IO，摄像头等等。要使用这些功能，就得老老实实地下载SDK回来开发原生的App。可是，如果用HTML+js+css，也能调用本地API，和原生App实现同样的功能，是不是很心动？

事实上，已经有这样的框架出现，如PhoneGap等等。有兴趣不妨Google之。因超出本文范围，故就此打住。

第五篇：APP开发保密协议

软件开发保密协议

该保密协议（以下简称“协议”）由（以下简称“甲方”）与_______________________(以下简称“乙方”)，于2018 年 月 日签署并生效。本协议适用于甲、乙双方合作洽谈阶段。不论甲乙双方签订服务合同与否，除非另外签署，此保密协议将持续生效。

鉴于乙方将开发甲方的手机应用（APP）软件项目，为确保双方的保密信息不向

3、从合法拥有该信息且对另一方无保密义务的