在webapp中，我们点击文本框，可以显示键盘。点击键盘上的“完成”，可以隐藏键盘。

按照之前文章《webapp之结构布局实现方案》介绍（回复数字8可以阅读），页面是不存在刷新，只是布局之间切换。这个时候会存在，文本框输入内容后，点击webapp上按钮执行操作后，切换到下一个页面，但是键盘仍然存在并未隐藏。

这样的情况相对尴尬，为了避免这种不流畅的体验，又怎么可以解决呢？

在web中，页面刷新，键盘会自动消失，按照这个思路，如果如果文本框节点消失，键盘也会消失。

有了这个思路就好办

比如有一个文本框

<div class="inputline"><input type="search" class="searchinput" placeHolder="请输入内容进行搜索"></div>

用户输入内容后，会切换到另外一个页面显示搜索结果，按照原来的方式，可恶的键盘会遮盖在上面，巨操蛋。

那按照新的思路，用户点击搜索按钮后,获取负节点，$(“.inputline).empty(),即可隐藏键盘。再顺利进入下一页。
这种做法，虽然能够实现问题，但也有很多负面效果。

比如：
文本框效果，内容样式变化导致的突兀感。

我的做法是，文本框一律-webkit-appearance:none 处理，文本框样式交给父元素实现。并且在父元素中定位一个备用节点，可以获取文本框内容，默认hidden。一旦文本框节点清空，备用节点显示，代替文本框的输入内容。这个就要处理好css问题，不过相信对于前端这也不是问题。

明天继续关于键盘控制，主要讲，怎么利用input实现键盘上按键的搜索功能。绝对仿真，和原生app效果极其类似。

在webapp，默认键盘功能比较有限，基本是qwerty风格，相对于ios上丰富可定制的键盘，弱暴了。

但是，在有限的情况下，safari还是给了一些支持的。那我们来看看，在已经有情况下，我们可以做那些事情。

1：默认

<input type="text">
默认首字母大写，可以通过autocapitalize="off"来关闭首字母大写。
<input type="text" autocapitalize="off">

2：html5 input

比如type=“number/tel”
<input type="number">

3：键盘实现九宫格输入数字

只需要在数字类型键盘上增加pattern="[0-9]*"正则
<input type="number" pattern="[0-9]*">

这样是不是输入数字方便了很多。

明天将继续，怎么实现键盘上搜索功能和键盘的消失和隐藏功能

昨天已经预告了今天的主题：webapp结构布局实现方案

大家在使用app中，经常会进行各种操作，实现不同的功能间切换，可以看到不同的内容。各种内容之间切换，会通过各种动画，比如从左到右、从右到左、从上到下、从下到上、透明到不透明、缩小放大等效果。

如果大家多了解些，也许和我一样也知道native app的视图view概念。原生app通过控制视图实现内容的展现和切换，以及app的内存管理。

在手机上webapp，怎么能够模拟原生webapp的实现效果呢？

如果在进行某个操作的时候，采用最简单的加载网页，可以吗？

很明显，这样做，会导致页面刷新，出现闪屏，而且无法控制页面的原始位置，继而无法实现动画效果。

那么，你可以在app store搜索“上海房税”。看看这个webapp是否接近原生app的效果。欢迎体验。

现在进入主要环节，webapp之结构布局实现方案：

大家仔细看这个大图：

大家看出端倪了吧？

在webapp和native app中，都是有默认视图，我们这里认为是“1”。当app启动时候，用户就能够看到“1”。如果用户进行操作，就可以把“2”、“3”、“4”、“5”的内容通过动画从各自的位置移动到2所在位置，这样就可以避免页面闪动等问题。

当然，具体实现的时候，还有某些细节。

我主要列举下一下原则，供大家参考。
1：所有的模块通过如图的样式和位置布局；
2：所有的模块是平级的，都包括在一个父容器中，父容器相对或者绝对定位，模块都按照绝对定位，当然也可以相对定位，但必须都保持一致；
3：父容器位置是从“1”的左上角开始，也就是“2”模块位置，是left：320px，top：0；“3”模块位置，left:-320px,top:0;“4”模块位置，left：0，top：460px；“5”模块位置，top:-320px,left:0;(已iphone 4s为例，其他的原理一致)
4：此外，需要对各个模块，标注z-index值，显示不同的层级。避免模块在“1”区域出现的层级，避免被遮盖。

此外，还有一些罩层，都是在“1”区域，但是默认hidden的，需要的时候显示即可。

大家有什么细节问题，回复即可。我基本在线的

做手机应用，最痛苦的就是适配，适配就涉及到分辨率之类的问题。

今天就我已经了解到的只是和领域和大家分享下。

我们通常所说的分辨率，就是手机的宽和高分别能够显示的像素数。

分辨率：分辨率（resolution）就是屏幕的精密度，是指显示器所能显示的像素的多少。
比如：iphone5 分辨率6401136,也就是宽可以显示640个像素点，高显示1136个像素点。总的像素点是6401136 = 727040个 。js获取屏幕分辨率方法，window.screen.width 、window.screen.height
宽度：x方向显示的像素数，width，以window.screen.width获取；
高度：y方向显示的像素数，height，以window.screen.height获取；

设备独立像素(device-independent pixels (dips))：即移动设备的显示像素，如iphone的设备宽度和高度为320568而非6401136；

由此衍生出设备宽度（Device-width）和设备高度（Device-height）。
比如iphone 5，设备高度568px、设备宽度320px。ios通常的设备宽度是320px，而android设备宽度主流为320px，也存在360px、400px等。这也为android适配带来了巨大的麻烦。

在iphone 4s之后，出现一个retina概念。这个概念，实际是iphone自己提出来的，他并不是一个标准。

那什么是retina？就要涉及到上面说的设备宽度了。

device-pixel-ratio：width/device-width，即上面说的的缩放比例值。device-pixel-ratio大于等于2时，就是苹果所称的retina了。也就是一个显示像素宽度，可以装下2个像素以上。也就是所说的一个像素点可以放4个像素点的内容。

现在很多手机早已经实现retina了，比如魅族2，4.4寸（720px1280px），小米2，4.3寸（720px1280px）。都已经是retina屏幕。

目前，可以通过window.devicePixelRatio查询device-pixel-ratio。

此外，在讲一个我不太熟悉的概念。

PPI/DPI：PPI有时也叫DPI，表示的是每英寸所拥有的像素（pixel）数目，数值越高，即代表显示屏可以显示高密度像素。计算方式（以iphone4 为例）

由上图可知，PPI在120-160之间的手机被归为低密度手机，160-240被归为中密度，240-320被归为高密度，320以上被归为超高密度。

现在的主流手机，都已经在高密度和超高密度上上。

今天同事们在折腾android的ui切图，我还不太了解，拿这些已经积累的只是，和大家分享下。

今天上海下暴雨了，下班了走不了。

一天的工作也刚刚结束，慢慢慢下心来。和大家回味下webapp遇到的那些坑。

进过webapp开发的各种坑之后，心态坦然多了。不在那么彷徨而纠结，简单整理下这些坑，给大家一些建议。
和很多webapp团队一样，我们看上webapp，就是出于跨平台、解决开发成本的原因。

1：适配的坑

屏幕适配，主要media query实现。

ios基本就是320480或者320568，比较容易确定；

android适配就比较蛋疼，虽说主流屏幕是320、仍不免有360、400之类的，而且往往屏幕分辨率一致时也有宽不同的情况，这种情况下，高度确定就更加蛋疼。而webapp的高度必须用css确定的。这个往往又影响到内部元素的大小，XX%和固定宽度的写法，都不是很好，往往采用折中实现；

2：android返回键

在ios上，不存在返回键，可以只在界面设置“返回按钮”即可，这么做的前提是，所有页面结构塞在一个html中，通过定位、动画来实现切换；

但是在android，如果不做任何设置，返回是直接退出app的。这个自然很诟病，也有通过phonegap监听返回键事件，但是效果不太理想，往往监听不到或者重复执行操作。也有通过pjax（ajax、html5 history、pushstate）来实现，但是我还没有尝试，方法可以参考”张鑫旭“最新博客

3：phonegap

webapp虽说可以用web实现很多功能，但是硬件设备和系统本身的很多事件却无法直接调用；
比如通讯录、指南针、光感应等。现在phonegap通过系统集成，提供给了才有js调用系统功能接口，目前来说，虽然能够扑捉具体事件。但是任然不够灵活、操作速度也比较迟钝。当然，这可能是我的技术功底不足，希望大家多多指正。

4：浏览器性能

这才是webapp实现的重点。原生app，会通过主视图、试图的方式加载显示内容，包括异步加载、分布加载、内存管理等光是控制优化app性能。webapp就主要取决于浏览器本身；

webapp，而是通过app加载html文件实现，我们是在一个页面中集成所有肯能涉及到的模块，通过切换加载显示对应的数据。但是，任然发现，在数据稍多，例如25条房源数据，就显得比较卡顿了。也许和经验有关系，我也在学习，尽量优化；

ios目前对浏览器优化还是不错的，主要是android的浏览器问题。可以参考昨天的文章，回复数字”4“可以阅读。我做过一款app”上海房税“，可以app store 下载。ios体验还是可以的，但是android上一塌糊涂，基本只有60%手机可以直接运行。最后折中在android上采用wap方式实现。我发现在android上，webapp的内核在支持js上基本是坑爹，坑干爹的。很多简单的算法也很难执行。也许，可以采用云计算的方式，但是后来，时间有限，其他项目也上来了，就先到此为止。

总的来说，我现在，还是很不认同webapp，不管多少书多少人造势webapp是手机应用未来。希望说这些话的人，走过这些坑之后再发表观点，而不是为html5或者其他原因举旗而已。

讲了这么久的webapp，开始给大家讲讲我们webapp中掉过的坑，并把一切基本技巧通过微信和大家分享。

在使用app时，往往在页面滚动到头部或者底部时，会出现弹性反弹效果。在原生应用中，这个是基本的ui体验细节。但是在webapp中，却需要仔细设置了。

使用safari的时候，在页面过长时，拉到底部或者头部往往都有弹性的，这是safari浏览器特有的。

在webapp上，为了实现页面的弹性碰撞，我们可以借鉴safari的这一特性。（这里特指ios系统下webapp，android的还没有找到页面弹性的方法，欢迎大家赐教）。

页面弹性，主要应用到-webkit-overflow-scrolling这一特性
条件：

1：父元素设置-webkit-overflow-scrolling: touch;overflow: scroll;属性；
2：子元素高度要大于父元素或者设置min-height大于父元素
demo：

html部分
<div class="father">
   <div class="child">
   </div>
</div>
css部分
.father{
    height: 548px;
    overflow: scroll;
    -webkit-overflow-scrolling: touch;
}
.child{
   min-height:549px;//或者height:1000px;
}

如果不设置father的属性，即使child值大于父元素，也无弹性效果，切记。

今天接着昨天的文章开始，大家可以回复数字“3”查看昨天的文章。

今天主要讲讲iphone和android平台的浏览器，也就是webapp赖以运行的核心。

对于浏览器来说，主要工作是通过内核进行渲染，包括渲染html(常见的div、table、css等)以及渲染javascript（包括dom节点操作、交互、数据读取等等）。通过渲染，可以把代码文件通过排布好的界面展现给用户。

ios系统浏览器叫做“safari”，是基于苹果自己家的safari浏览器内核，现在也以及开源了。safari在移动领域非常普及，常见的pc双核浏览器、手机浏览器，基本基于safari内核。包括全球闻名的chrome浏览器，也是基于webkit内核，但是也有一些特别的地方，稍后继续解释。

android原生浏览器，相信大家也都用过，界面恶心，操作不流畅，速度也很慢。相信大家都会用uc、海豚来代替的。

再说说chrome pc浏览器，chrome也是基于webkit，但是他在webkit上做了很多优化，形成独立分支，并且添加了渲染的javascriptV8 引擎，合并成了Chromium，现在已经开源。这点，开发者也是很认同的，chrome 并不比safari差。

但是，这里主要来解释下，为什么android的浏览器这么难用呢？而chrome pc版却这么赞？

1：Chrome for Android和 chrome pc完全是两个不同的团队；
2：Chrome for Android并没有使用google最强大的浏览器内核Chromium；
3：以及历史原因，android版本多变，现在中国区2.35版本任然达到30%以上（umeng数据）
4：android团队，并不重视浏览器，导致浏览器不够给力，而且在android开发环境也没有很好的支持webview的实现。（虽说webview是原生软件和web结合的最理想方式，这都不给力，纯webapp就更弱）

到这里，大家应该还有疑惑：为什么google有单独推出了，chrome移动版浏览器？而且没有让人失望

我的估计是，android系统内置浏览器已经是历史原因很难纠正，那就最简单的一刀切，来一个全新的浏览器，基于v8，堪比pc版。可惜，4.2android还是没有内置这版浏览器。

但愿，android系统对浏览器多一些支持，内置上chrome移动版，更多支持webview，让我们这些苦逼的webapp开发也少走弯路，用户也能流畅些。

以上内容参考，知乎、百度、wiki等
如有疏忽，欢迎指正

刚才wikipedia.org时，突然发现wikipedia.org竟然没有webapp的描述，着实雷到了。百度还是有解释的，不过范围比较宽泛。我这里限制下，本文说的webapp是指用web技术制作的手机移动应用app。传统的手机应用app基本是基于客户端语言实现的，android是java语言，而ios则是objective-c为主，window 7 以.net为主。

为什么webapp的概念呢？

做手机应用的同学肯定有这样的感觉，移动跨平台加上屏幕适配的问题，导致移动开发工作量比传统pc软件开发要增加数倍工作量。如果利用web的技术制作app，那么就只需要一个网站，实现全平台适配，无需多平台开发，开发工作量将大大减少，效率也数倍提升。而且还有很多其他的附加值，包括全平台更新无需等待，开发技术难度小等。貌似，就是基于这几条原因，webapp在数年内，概念上一直比较火。国内外也出现了众多的webapp制作框架：phonegap、sencha、jquerymobile、jquery.mobi、Dojo Mobile等等

京东搜索”移动开发“，众多”html5制作移动移动开发“书籍闪亮你的眼睛。

在详细解释下移动webapp的实现逻辑：
1：通过android、ios平台构建一个应用的外壳，里面塞一个网页，通过网页来实现应用的所有功能。
2：网页的技术则是通过html5、css3、js技术为主，后台技术就比较多了，java、php、c#等技术都可以利用起来；
3：网页开发的技术，除了移动适配和移动的部分适配特性外，其他开发等同于pc web开发；
4：那么，也就是说webapp应用不在和传统app一样，基于客户端语言，而是基于手机浏览器内核来运行的；
5：此外，浏览器本身html5的功能机发展原因，还不能直接调取手机的硬件功能，包括摄像头、电话、通讯录、指南针、声控、光控等。那么，现在的方案是通过phonegap、sencha等框架调取移动硬件，供js调取实现的。

看到，这里，大家对webapp有了初步的认识吧？

有什么不明白的或者疑问、错误，欢迎指正。

明天，开始重点解释webapp运行的基础：手机浏览器内核。这是影响移动应用的嘴关键因素，脱了这个条件，移动webapp，是不存在的。

看到这个标题的亲，是不是觉得命题太宏大了。

是的，我也这么觉得。当然，我不想在这里误导大家，我很坦诚的告诉你，我也只是半吊子。我只想用有限的经历，和大家分享下这里面的心得。

总的感觉，产品引领技术，技术实现产品。梦想伟大，两者皆光荣。无论是程序员还是产品都乐在其中。

在金山毒霸做了近1年半的产品，最后为了女朋友还是别离了北京来到上海。又有点怀念金山了。

产品的感觉：

1：做产品就是居委会大妈，侍候好一大帮人。管产品、管数据、管设计、管交互，还有运营、收入啥的，甚至还有市场的。我基本都遇到过，确实比较大。当然，都说IT 行业CEO 产品居多，这也是其中一个理由；

2：产品，往往在自身工作之外，还有更多的协调工作，平衡技术、设计、市场等部门的各种工作的平衡。侍候好各方部门，给需要给你帮助的对方最充足而极致的准备，尽量减少合作者的工作量。当然，他们给你的回报就是，产品上线运营的综合效应。相信，这也是做产品的成就感。

3：最好，当然也是最重要的。你的人性上的特色，比如秉性、价值观都会体现到你的产品上，也会在你的产品沟通、发展、运营体现的淋漓尽致。相信，你最后的产品成功取决于此。那么，就努力先成为一个优秀的人，那么你离成功的产品也不远。

技术感受：
1：做技术，更专注于自身的工作，关注技术实现的细节。收到一个活之后，了解需求完毕。剩下和其他人打交道的机会，变得非常少，除非主动型。接完需求，赶紧躲到自己的代码角落，流程、逻辑、判断，这逐渐成了你世界的所有；

2：做技术，面临的是日新月异的技术挑战。学习，成了最重要的能力。我从去年开始做前端，遇到很多机会，让我遇到很好的学习机会。从最开始的手机wap页面，到webapp，能做的事情太多了。每天学习的东西也是指数级增长。所以，最近很喜欢“分分秒秒涨姿势”这个词。后面，还有更多IOS原生开发的挑战，共勉；

3：技术，对产品实现负责。产品不可能方方面面周到，剩下的需要自己培养产品意识和全局感。虽然自认做过产品，感觉在全局观上还是要继续努力。多多理解产品，好的技术，应该对产品的成功奉献技术以外的惊喜。

分割线一下，这是最近体会的一些唠叨。

后面有机会继续展开，当然，相信你也有很多想法。请不吝赐教。

PS最新在玩微信公众帐号，目前好友只有13个，离500个关注目标还远着。希望你可以分享这篇文章到朋友圈。让更多的人关注~

多谢，以@xiazer 之名，感谢你的分享