imweb/mobile

library for mobile develop

mobile

Library for mobile develop.

#####Solve your problem

1.Mobile开发经验沉淀，欢迎 Fork & Pull Request & Issue。

• IOS7 白屏 bug
• Android2.3 下transform失效
• Listview 太长在手机上的性能问题
• 手Q内多页面刷新
• Tap点击穿透问题
• IOS下页面input呼起软键盘导致fixed元素错位问题
• IOS8 闪屏问题
• IOS 5+快速回弹滚动问题

2.响应式开发

• rem实践

3.性能优化

• 图片优化

  • Baseline and Progressive

mobile's Issues

Mobile开发经验沉淀

在手Q开发过程中，遇到各种问题，解决之后沉淀如下，细分为：

1、经验沉淀：开发过程怎么快速开发并在开发过程中可以兼顾到一些场景的出现
2、疑难问题：一些机型出现的疑难问题，如和解决，以及对应的机型等问题详细描述（截图）

-webkit-min-device-pixel-ratio的常见值对照表

-webkit-min-device-pixel-ratio的常见值对比（是设备上物理像素和设备独立像素，设备像素比率）
来源参考网上，欢迎完善。测试地址：https://bjango.com/articles/min-device-pixel-ratio/

设备	分辨率	设备像素比率
Android LDPI	320×240	0.75
Iphone 3 & Android MDPI	320×480	1
Android HDPI	480×800	1.5
Iphone 4	960×640	2.0

设备像素为:1.0 (-webkit-min-device-pixel-ratio)

所有non-Retina mac电脑
苹果iPhone(第一代)
苹果iPhone 3 g
苹果iPhone 3 gs
苹果iPad(第一代)
苹果iPad 2
苹果iPad mini(第一代)
宏碁Iconia A500
三星Galaxy Tab 10.1
三星Galaxy S

设备像素为:1.3 (-webkit-min-device-pixel-ratio)

华硕MemoPad高清7
Goole Nexus 7(2012型)

设备像素为:1.4 (-webkit-min-device-pixel-ratio)

诺基亚流光(Lumia)520

设备像素为:1.5 (-webkit-min-device-pixel-ratio)

Google Nexus S
Samsung Galaxy S II
HTC Desire
HTC Desire HD
HTC Incredible S
HTC Velocity
HTC Sensation
Kindle Fire HD
三星Galaxy S II
索尼XPERIA Tablet Z平板电脑
索尼 Xperia U

设备像素为:2.0 (-webkit-min-device-pixel-ratio)

所有Mac Retina显示屏
iPhone 4
iPhone 4S
iPhone 5
iPhone 5c
iPhone 5s
iPhone 6
iPad (3rd generation)
iPad 4
iPad Air
iPad mini (2rd generation)
HTC One X
Google Galaxy Nexus
Google Nexus 4
Google Nexus 7 (2013 model)
Google Nexus 10
摩托 Moto X
三星 Galaxy S III
三星 Galaxy Note II
索尼 Xperia S
索尼 Xperia T

设备像素为:2.6 (-webkit-min-device-pixel-ratio)

诺基亚 Lumia 930

设备像素为:3.0 (-webkit-min-device-pixel-ratio)

HTC One (M7)
HTC Butterfly(蝴蝶)
华为荣耀 6
iPhone 6 Plus
LG G2
Google Nexus 5
一加 OnePlus One
Oppo Find 7 (X9076)
三星 Galaxy S4
三星 Galaxy Note 3
三星 Galaxy Note 4
索尼 Xperia Z
小米 米3

关于移动端输入时弹出虚拟键盘问题测试

ios弹出的虚拟键盘是浮在上面的，而安卓的虚拟键盘是压缩窗口大小，如f12，所以导致fixed在底部的东西在ios上和安卓上的不同差异。
测试地址为：http://output.jsbin.com/fecare/1/
测试结果：安卓的fixed底部会随着虚拟键盘的弹出而提上去，因为窗口变小了，而ios的fixed底部会看不见，因为窗口大小并没有改变。

添加写测试用例方便回归？

Baseline JPEG vs. Progressive JPEG

概念

JPEG有两种存储格式：baseline 和 progressive。Baseline JPEG 会在数据可用时，一行一行自上而下显示。Progressive JPEG会先显示模糊图片，然后逐渐清晰。

浏览器渲染

Progressive JPEG在所有浏览器都会显示，这里的关注点是如何渲染。

Chrome + Firefox + IE9 下 Progressive JPEG 加载很快。

对比

用户体验

Progresssive JPEG 用户体验更好，用户从开始就知道图片长什么样子，对于弱网用户来说，尤其必要。

文件大小

一般，Progressive 比 Baseline 格式小几KB。参考这里
实验
随机从网上下载图片，剔除4xx 和 5xx 错误后，剩余10360张图片，分别转化成 Baseline 格式 和 Progressive 格式。
结论

• 大于 10K 的图片，Progressive 格式更小 （in 94% of the cases）。
• 小于 10K 的图片，Baseline格式更小（75%）。

实际测试结论（这里受限于机器性能，样本不大）：

浏览器支持情况：

即便在浏览器不支持的情况下，由于 Progressive 格式的图片比原图小，加载也会更快。

性能

Progressive 比较耗CPU， 对于移动设备来讲，这是一个顾虑，在低端机型上面可能不会支持Progressive，但是随着硬件升级。这个问题会得到解决。

参考文献：
http://yuiblog.com/blog/2008/12/05/imageopt-4/
http://calendar.perfplanet.com/2012/progressive-jpegs-a-new-best-practice/

用zepto1.1.6发ajax在特定安卓机出现INVALID_STATE_ERR: DOM Exception 11异常

问题描述：

在用小米2，安卓版本4.01.07，qq5.9.1，zepto1.1.6测试页面的时候发现页面报JS错误。

原因：

具体跟进发现zepto1.1.6里有这么一段

    if (settings.headers) for (name in settings.headers) setHeader(name, settings.headers[name])
    xhr.setRequestHeader = setHeader

    var async = 'async' in settings ? settings.async : true
    xhr.open(settings.type, settings.url, async, settings.username, settings.password)

第一行语句会给xhr.withCredentials赋值。
在特定机型特定系统特定浏览器下，

1. 给xhr.withCredentials赋值
2. 调用xhr.open方法
   如果2在1之后调用会导致异常。

看看w3c里的描述：
http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#the-withcredentials-attribute
里面有这么一段：

1. If the state is not UNSENT or OPENED, throw an "InvalidStateError" exception and terminate these steps.
2. If the send() flag is set, throw an "InvalidStateError" exception and terminate these steps.
   意味着规范里写着只要在send之前调用，open和withCredentials的顺序应该不会导致InvalidStateError才对。所以zepto这样写应该还是符合规范的，作者之所以不把open提前，原因可见https://github.com/madrobby/zepto/issues/921。

解决方案：

快速的解决方案可以考虑：

1. madrobby/zepto#921 这里提到的open提前。
2. try catch捕获异常
3. mscienski/zepto@d4ddb34 这里提到的对ajax.js的修复。

rem自适应方案

H5自适应改造方案——rem方案

原理

之前我们H5页面使用的方案是设置viewport meta头，让浏览器帮我们把页面缩放，使得页面看起来好像是自适应。实际上这不是自适应，只是在中小屏设备上，看起来差距不大，问题不明显而已。

现在大屏高清设备流行，自适应的问题也越来越明显了。在大屏设备上，课程封面小，title被拉长，文字小，按钮扁等问题越来越突出，已经达到不能忍受的程度，因此需要一套自适应的方案。

页面缩放

在viewport meta头里，取消让浏览器自动缩放页面，页面的自适应由页面自身管理。
因为有dpr的问题，为了统一管理，让浏览器帮我们根据dpr缩小页面，比如dpr=2，就缩小0.5让页面统一处在dpr=1的环境中。

rem

rem是一个半相对单位，它相对的是html(或body)元素的font-size值，例如有html { font-size: 10px; }，则1rem = 10px。

当html元素的font-size是根据设备宽度自适应时，使用rem的页面也就会有自适应的特性。

文字

根据以下两个原因，对于文字使用px：

• 在大屏设备希望看到更多的文字
• 中文点阵最好是在12px，14px，16px这种尺寸，使用rem就会无法避免使用13px，15px尺寸，这样文字会显示的很奇怪

没有浏览器帮助我们缩放页面，在高清设备里面需要我们手动对文字进行缩放，为了方便这个而不需要写media query，页面在计算html的font-size值的同时，会设置一个data-dpr的属性。这时文字的media query就可以这样写：

p { font-size: 12px; }  /* dpr = 1 */
[data-dpr="2"] p { font-size: 24px; }   /* dpr = 2 */
[data-dpr="3"] p { font-size: 36px; }   /* dpr = 3 */

规范

1. 在head头引入初始化js脚本，可以使用两种代码：

   • 淘宝移动端自适应方案开源代码，注：这里的因子是10，即font-size = W/10
   • 腾讯课堂公众号最新代码里面（路径：src/inline/rem.html），里面的代码是淘宝现网代码copy下来的，与开源代码对比过，大致一样。注：这里的因子是16，即font-size = W/16

2. 开发时，假如视觉稿宽度是640，则最好使用第二种方案，选择16作为因子，则比例为640/16=40。那么，页面所有的rem数值的换算公式为：在视觉稿中的px数值/40。

   以后会开发一个fis插件，在开发时只需填入视觉稿中的px数值，由fis插件帮助我们自动换算，在插件开发出来之前，先人工计算吧。

3. 文字使用px单位，同时需要写media query，借助html元素上面的data-dpr属性，详见原理部分。