webapp开发实战_html5开发手机app实例

webapp开发实战_html5开发手机app实例

大家好，我们又见面了，我是你们的朋友全战军。

本人从事单页开发一年多了。 这段时间，我对网站模式非常推崇，也整理了很多移动开发的知识点。 但现在回想起来，很难说是好是坏！

用于修改页面； 然后从服务器传递更多数据并再次修改页面，依此类推。

从性能角度来看，单页Web Apps与现代浏览器中的普通应用程序相当，并且几乎所有操作系统都支持现代浏览器。

因此很多人认为它是HTML5普及的最大赢家，那么它具体有哪些特点呢？

SPA（页面），即单页面，具有以下优点：

为了用户体验，内容更改不需要加载整个页面。 这样就不会出现白页的情况，并且页面之间会无缝切换，甚至有一定的动画效果。

请求量小，请求内容不需要服务器解析，对服务器的压力较小，消耗的带宽也较少。 例如，不需要每次接收完整的html结构，而只需接收json数据。

当然，单页应用程序并不完美。 他们还存在以下问题：

由于历史原因，单页应用不能很好地支持SEO，需要对SEO进行特殊处理。

首屏加载量过大，首屏加载缓慢，需要对首屏进行特殊处理。

本身进入门槛就很高，视图编码需要释放资源，防止堆值过高，这对编码人员提出了很高的要求。

现状

据说足以媲美app。 事实上，还有很长的路要走。 预计需要2-3年的时间才能填补“够用”和“够用”之间的差距。 那么事实是什么呢？

事实上，移动网站很少。 半年前一桃还在，这两天又变回来了。 小柴虽然有信心，但是信心从何而来呢？

携程独特，去哪儿iPad介入，但国内主流网站仍是传统网站。 主要原因有两个：

① 搜索引擎优化

② 不想吃螃蟹

所以说，携程的产品在中国是非常有价值的。 说这句话的时候我差点哭了……

是好是坏

小柴可以决定哪一个更好，哪一个更差。 就稳定性来说，并不比传统网站好； 对于SEO，需要其他解决方案； 对于垃圾收集，您需要自己释放资源。

说到体验，我们需要考虑首屏加载； 说到动画，就要考虑低端手机，所以还有很长的路要走！

目前的效果是app无法比拟的。 有一天，当不再受网络和设备的限制时，那么春天就不会遥远了。

即便如此，现阶段仍然有很多优化经验和技巧可以谈。 这里小柴就分享一下，希望对同学们有所帮助。

网络传输优化概述

前端优化分为两个切入点：网络传输和DOM操作，而网络传输是制约网站速度的主要因素。

网络传输优化的关键点是零请求、无流量，即尽量减少请求数，减少请求量。

对于模式应用来说，首屏加载慢是不可避免的问题，因此提高首屏加载速度是提高网站整体速度的关键。

假页面首屏加速

开发实用的移动应用程序开发示例

开发实用的移动应用程序开发示例

以上是一个网站首页的加载时间。 我们分别取加载速度为150kb和30kb。 可以看到会很慢！如果是的话我们可以做一些优化

我们应该避免页面长时间呈白色。 这时，假页面的概念就被提出了。 页面渲染只需要完整的HTML和CSS。 这是第一个优化点。

从数据请求数和请求量来看，首页的响应应该是比较慢的。 如果js加载完再渲染页面，用户很可能会失去耐心。

但从首页实际响应速度比较快来看，加载完成后会渲染页面首屏，然后异步加载js。 当js发生变化时，dom结构中的一些关键点会动态改变。

此时，会加载一个静态的HTML页面，加载首屏的基本内容，以便快速显示主页。

那么js加载完之后整个页面就会立即重新渲染。 这样用户就可以快速看到页面响应，给用户一种速度快的错觉，感觉速度快了很多。

减少请求数量

从首页来看，不可避免的会使用较多的js文件。 这些文件分为两类：

① 框架js-css

② 各业务团队的js-css

因此，可以限制每个业务团队只加载这四个文件，以最大程度地减少请求数量。 这也涉及到并行加载。 数量和容量有一个临界值。 如何确定这个临界值需要你自己去实验。

减少请求量

虽然图片压缩是不言而喻的事情，但总有时候你会发现有些网站的图片尺寸非常大，需要处理而且必须处理。

以框架库为例。 除了核心包之外，使用时可以剔除不必要的UI或函数库并动态加载，以减少初始负载。 这件事必须从一开始就做好。 如果做得不好，以后就很难改变。

以业务团队为例，第一次加载的js和html模板会压缩合并几个常用的页面，然后在访问其他页面时再请求。 如果想改善首屏加载，可以只下载需要的页面文件。

此外，以下两点需要特别注意：

① 如果想要库，可以考虑换成zepto。

② 不要乱引用第三方库。 如果你想引用它们，你必须在理解源代码后重写并使用它们。 这样做的好处是，如果了解透了，出现问题就可以改，而不用再去改库。

缓存Ajax/

该方案的原理与上一方案类似。 当我们发送Ajax请求时，我们应该缓存一些非实时数据，例如城市信息和常用联系人，但我们只能缓存非敏感信息。

从商品搜索页到列表页请求的数据会被缓存30s-60s。 如果用户在过期时间内返回列表页面，则不会再次请求数据。

这有利于服务器压力和页面响应。 这实际上在30秒内意义不大，可以减少一个请求。

另外，曾经有人对get和post的效率进行过测试：

每次平均耗时323ms； 每次平均耗时589ms，所以post方法比get方法慢，但是post请求的优点是安全，参数没有长度限制。

无论你选择post还是get，都需要进行处理，以避免截断URL或到处发布。 -

仅显示首页页面，需要时才加载其他内容，例如列表页、图片等。 一切都需要完成。

DOM操作优化概述

DOM操作主要分为页面渲染和资源清理（堆控制），两者相辅相成。 如果DOM操作没有处理好一起，感觉就不再是慢，而是卡住了。

因此，DOM操作优化的主要目的是消除页面卡顿问题，这在移动端尤为重要。

关于页面渲染

浏览器会解析三件事：HTML、CSS

浏览器首先会基于HTML生成DOM Tree，其次基于CSS生成CSS Rule Tree。 可以通过 DOM API 和 CSS API 操作 DOM Tree 和 CSS Rule Tree 来引起页面更改。

浏览器解析后，会通过DOM Tree和CSS Rule Tree形成一棵树。 只有不存在的元素才会形成树。 Tree形成后，浏览器会调用GUI来绘制页面。 在此之前要做的一件事就是或者说。 上述描述可以简单分为以下几个过程：

l 生成DOM树

l 计算CSS样式

l 构建树

l ，被定位元素的位置和大小

l 绘制页面

在这个过程中，如果动态改变DOM Tree，就会导致

对页面上元素的更改，只要不影响大小即可。 例如，仅仅改变颜色只会引起回流，但不会引起回流。

否则的话，这个时候就难免需要重新计算Tree了。

分为局部回流和全局回流，会影响下面的元素，但不会影响上面的元素。

消耗的系统资源比较大，DOM Tree中所有受影响的节点都会受到影响。 最坏的情况下，所有节点都会受到影响。 这个问题造成的现象是低性能的电脑风扇一直转，手机变得很热，耗电很大。 以下操作可能会导致

l 操作dom结构

l 动画

l DOM样式修改

l 获取元素大小的API

减少定位属性的使用（固定/）

该元素处于文档流中，其渲染速度是最快的。 我们做了一个测试：

100个元素和100个元素渲染时间差0.01-0.007ms

每个元素的渲染间隙增加到30ms左右。 这种微小的时间差在移动端表现得尤为明显，例如：

小米/三星手机（1000左右）存在明显的渲染问题，具体如下：

l 手机上无法显示定位元素。

l 定位元素动画效果无效。

上述问题都是由于频繁的UI渲染失败导致的。 最好的解决办法是减少定位元件的使用，否则只能通过产生强烈的应力来解决。

此外，产品往往有固定的要求。 例如，支付按钮总是出现在低端。 这个要求会带来两个问题：

l 修复元素遇到文本框时会失败，并可能浮动到页面中间阻止输入。

l 影响效率

第一个问题的原因与移动终端的实现有关。 暂时没有完美的解决方案。 第二个问题与渲染直接相关。

滚动时，页面上的所有像素都会滚动。 显卡可以非常快速地处理全屏上下移动。 但是，如果出现固定元素或者存在不一起滚动的元素，那么滚动将成为移动浏览器的负担。 这种滚动性能甚至在4s中都有体现，因为滚动可能会导致这种现象体现在：

使用固定效果模拟时，会出现碎片效果，现在不会出现这个问题。

开发实用的移动应用程序开发示例

奇怪的技能和技巧

当然，我们不能忽视产品需求。 固定需求要从技术上解决，用户要有好的体验。

虚拟键盘导致固定元素未对齐

固定元素肯定会伴随着虚拟键盘的出现，但虚拟键盘只是“依附”在它上面。 表面上看，它不会对 DOM 产生“任何”影响，但此时，固定元素的表现就变得怪异，变得错位。

应用层面解决该问题的方法是，将固定元素设置为虚拟键盘弹出时，虚拟键盘消失时设置回来。

由于虚拟键盘不会抛出事件，因此检测或事件会有一定的延迟，并且会出现闪烁。 因此，现有最好的解决方案是使用定时器来监控当前焦点元素是否是文本元素。 如果是，则需要进行处理，以便解决固定元误差问题。

固定元件滑动惯性平滑度

我们经常会遇到这样的产品需求。 标签栏变得固定。 当向下滚动超出选项卡栏时，它会成为固定元素并始终出现在标题中。 这种需求在电脑上不是问题，但在手机上经常会因为快速移动而出现小范围错位或者大范围错位。

这时我们可以强制浏览器重绘来解决这个问题。 这里有一个奇怪的hack：同时设置三个图像元素的src属性可以全面解决这个问题。 该解决方案得到了团队的确认并应用。

//三张图片src、，处理固定方案的惯性问题

var el = this.els.ctlc.find('img');

$(el[0]).attr("src", '');

$(el[1]).attr("src", '');

$(el[2]).attr(“src”, '');

另外，上图中tab标签下的蓝线是动画的，但在小米或三星手机上可能不会动。 这时候也可以动态引发来解决这个BUG。

其他

l CSS选择器应尽可能使用id和class，避免过多的级联。

l 避免使用数值。 例如::none不会导致渲染，但boder:0会

l 在动画过程中将元素保持在文档流之外，以避免造成大量元素

l 避免一一修改DOM样式，改变即可实现同样的功能

l 操作DOM时，会设置为none，因为该元素不会影响渲染，或者操作对象会替换页面显示的DOM。

l 避免将获取DOM样式属性的操作写在循环中，可能会造成重复

移动终端内存资源优化

首先，移动端的性能与PC端不在一个数量级上。 例如，我兄弟做了一个测试，他曾经画了一个大段，然后想获取HTML的ID节点。 事实上，他无法得到。 页面模拟多个页面，经常会出现动态创建DOM的情况。

变量 = $('

…很多结构…

'）；

$(根).html()

$('#test) //空

这种问题令人难以置信，因为页面UI渲染和DOM操作是互斥的，但即使出现这种问题，一个解决方案就是使用。 更好的解决方案是使用事件来监控页面 DOM 变化，并将我们的 DOM 操作回调放入以确保渲染结束。

以上问题只是为了说明移动端的性能问题。 这样的性能问题会引起很多莫名其妙的问题，其中很多都和渲染有关。 然而，这也说明了移动终端资源的短缺。 如果堆值太大，会导致操作卡住。 更有什者，还会导致页面卡住，直接退出。

该模式完全依赖于浏览器的垃圾回收，这基本上是一个技巧，因为传统页面一旦刷新，整个资源就被完全释放，并且不存在刷新这样的操作。 只有一种状态到两种状态，不相关的记忆会被保留。 资源必须手动释放，或者说框架必须提供垃圾释放的机制。

这从图表的堆值变化可以清楚地看出。

在视图切换过程中，如果不手动将未使用的资源设置为null，变量将不会被回收，从而脱离帧控制而失控。 所以我们在这个过程中需要注意以下几点：

l 释放未使用的封闭件

l 观察者需要清理

l 释放定时器

l 在视图切换过程中，释放视图相关资源

——感谢艾伦的友好支持

闭合陷阱

在我们的工作过程中，误用局部变量是很有可能造成闭包陷阱的。 这个问题不仅是性能问题，还会导致逻辑错误，而且很难发现。 例如，在 AMD 闭包中使用局部变量

var = {};

($.(, 选择));

此操作将更改 _ 对象。 如果是一个实例的话，没有问题，但是如果是两个实例，就会出现变量污染。

这只是一个例子，但在代码中误用局部变量可能会引起不必要的担忧，所以要小心。

资源释放

根据前面的描述，我们可以得出一个结论：

无论是视图还是UI组件，我们都必须提供统一的接口，以便用户可以继承和释放资源。

如果视图资源不释放，堆值过高，模型网站的价值就会大打折扣。 以下是需要考虑的几点：

l 保存的视图实例不超过5个。 如果多了，就会释放DOM结构和内存引用（临界值自行判断最优）

l 视图隐藏时释放内部资源并释放DOM事件处理程序

l UI组件和视图一样，需要统一的发布机制

但由于单页面应用的页面不会刷新，所以部分资源不会被释放。 这个问题还有很长的路要走。 在平时的编写过程中可以进行以下优化：

l 用函数代替逻辑

让我们的函数生成一个返回值来代替函数中的一大段逻辑。 这样做的第一个好处是逻辑清晰。 第二个好处是这些函数在不同的函数中，这个函数用完后会自动释放。 。

l 清理闭包引用

当使用了一个闭包函数什么的时候，如果不再使用的话，需要手动清理该变量，以便释放闭包之间的引用关系，释放资源。

l 使用对象属性或方法

一个对象可以引用其他对象的属性或方法，例如 obj.foo =; 在这种情况下，我们可以随时删除对象并取消引用关系，然后清理资源。

动画和假死

对于动画，建议使用CSS3来实现动画。 在CSS3中，建议使用最新的接口，比如改用top/lelf操作，这样操作效率更高。

如果使用动画，可以设置相应的元素来减少回流。 最重要的一点是

避免在 DOM 树中移动太多节点。 这时，你需要拒绝产品的无理要求，比如：

该产品需要一个日期滚动组件来显示半年的数据。 这半年的数据是180棵DOM树。

一旦动了这层DOM，整个手机就会直接卡住。 即使构建DOM树并渲染页面时，也会出现假死现象。 这个问题需要避免。

缓存

Cache是​​HTML5添加的一个供离线使用的API。 与 、 等不同的是，Cache 存储了一系列请求的资源，让浏览器无需通过网络即可请求资源。 如果设计得当，可以实现离线应用。

使用Cache主要是提升网络性能，有效降低网络延迟，提高请求加速。

开发实用的移动应用程序开发示例

但也存在一些问题，比如新版本缓存没有立即生效； 中的请求路径是相对于文件的，而不是加载页面； 更新/回滚等问题，所以是否使用还需要论证。

体验优化的区域滚动

移动终端经常需要实现区域滚动。 有成熟的解决方案，但解决方案并不理想。

开发实用的移动应用程序开发示例

对于官方的例子，会出现以下问题：

l 头消失

l 偶尔无法显示文本框焦点，或者焦点错位

如果上面的问题可以忽略，但是缺少文本框，我是不会接受的。

原因与浏览器默认事件的组织有关。 因此，我不建议大家大范围使用区域滚动，而是在区域范围内使用。

iPad版的去哪儿网用在有文本框的地方，它所改善的用户体验和它引起的问题一样吸引人。

事实上，小柴和他所推崇的图书馆，虽然存在着种种问题，但却是最有可能带来移动革命的图书馆，因为它可以：

① 解决区域滚动

② 变相解决固定问题

③ 解决动画过程导致的长短页面问题

总而言之，该计划的提出距离同类应用程序又近了一大步。 真正的平等需要浏览器的支持。

点击回复

移动端的点击响应没有问题，但是我们点击时的300ms延迟是事实。 造成这一事实的原因是

手机需要知道是否要双击放大网页内容

所以点击响应慢，但是触摸则没有这样的限制，所以触摸在移动端相当流行。 至于鼠标，它有多慢？ 我告诉你，每次都会慢300ms。

开发实用的移动应用程序开发示例

开发实用的移动应用程序开发示例

开发实用的移动应用程序开发示例

因此，这个问题需要得到解决。 详情请参见：#_h2_7

结论

这不是一天两天就能发生的事情。 总有一天，它会绽放出应有的风采！