1.验证window.innerHeight
| 系统版本 | iOS9.1.1 | 安卓4.4.4 |
| 没有输入法的情况下 | 504 | 567 |
| 有输入法的情况下 | 208 | 273 |
看来两者的window.innerHeight都不包括输入法的那部分。
也验证了当输入法弹起来的时候，$('#id').css("bottom")都是相对输入法上面区域来定位的，也就是window.innerHeight来定位的。
2.验证window.outerHeight
| 系统版本 | iOS9.1.1 | 安卓4.4.4 |
| 没有输入法的情况下 | 0 | 1134 |
| 有输入法的情况下 | 0 | 545 |
IOS不支持outerHeight属性,郁闷！
3.验证(document.documentElement||document.body).clientHeight
| 系统版本 | iOS9.1.1 | 安卓4.4.4 |
| 没有输入法的情况下 | 504 | 567 |
| 有输入法的情况下 | 504 | 273 |
看来两者的又有差异，IOS下clientHeight包括输入法部分，安卓不包括clientHeight部分。
4.验证元素的高度变化，例如：$('#id').css("height"); //节点的文档高度,绝对定位，按照bottom来确定位置的。
| 系统版本 | iOS9.1.1 | 安卓4.4.4 |
| 没有输入法的情况下 | 353px | 408px |
| 有输入法的情况下 | 353px | 114px |
可以见得：有无输入框法，ios下高度没有变化，安卓就非常好的适应了，这是个IOS下的bug哦。
验证上面元素内部元素的高度变化趋势（内部元素高度是动态变化的），例如：$('#innerid').css("height");
iOS9.1.1:311px----663px----929px---1195px;
安卓4.4.4:357px---573px----870px---1192px;
可以见得：变化都是趋势是OK的。
5.这会导致神马问题了？
在IOS下，当输入法推上去的时候，页面的内容也回推上去，内容只有window.innerHeight高度的内容了，又由于clientHeight没有变化，而输入框就占领了一部分。
同时页面元素的高度没有变化，导致元素的滚动条展开不了，那么必然会失去一部分内容，失去的内容的高度就是输入法的高度。
解决之道：
第一步：$('#id').css("height",window.innerHeight); //把元素的高度设置为window.innerHeight
第二步：由于内容是向上消失的，所以要用元素的top定位。
var inputHeight = (document.documentElement||document.body).clientHeight-window.innerHeight; //输入法的高度
$('#id').css('top',inputHeight);
动作对UI的渲染太大，用setTimeout来延迟执行。
目前搞到的就是这些，有什么牛B的好办法就好了。