标签：android

Safari 下 Date 不支持”2018-01-01 00:00:00“

Chrome 可以支持非标准格式时间如 2018-01-01 00:00:00，safari 不支持，所以有时会导致错误。

前两天发现一个小程序的问题，Android 正常，iPhone 出错。我们都知道，Debug 的关键在定位，如果是某些特殊环节，不常见的错误，就会浪费很多时间。

这个 Bug 也是如此，反复拉锯之后终于发现，问题出在下面这句：

let a = new Date(`${date} 00:00:00`);

date 是服务器端返回的值，我是把它和后面的 00:00:00 连起来，记作某天零点零刻，和今天的零点零刻做减法，计算日期差，并按照日期差来决定接下来的逻辑。这段代码在开发工具（包括 Mac）、Android 手机上运行都正常，只有在 iPhone 上不正常，于是我打开 Safari——苹果这点做得不错，桌面版 Safari 环境和 iOS 几乎没有差别，该出的问题一定会出——果然复现了这个问题。

按照规范，中国的日期格式是：“2018/01/01”，Safari 只支持这个格式。而 2018-01-01 和 2018-01-01T00:00:00 ISO 格式，Safari 也支持，但是会以格林威治时间为准，和我们有8小时的时差。Chrome 和 Android 内嵌的 WebView（基于 Blink 或者 Webkit）则都支持，所以在本地和 Android 手机上没有问题。

Android Hybrid App四大坑

我们没有选择phoengap为技术基础，而是自行开发原生框架，主要目标平台是Android——嗯，就是那个从系统版本到模块组合都巨分散的Android，可以这么说，坎坷从立项的那一刻起就已经注定了……接下来，便请听我一一讲述，Android Hybrid App四大坑。

首先解释下题目，Hybrid App，混合应用，代表平台Phonegap，一般指使用原生包装Web页面开发的应用。与原生应用相比，主要用户界面和业务逻辑都是用Web技术也就是HTML+CSS+Javascript实现的；与Web应用相比，Web部分打包在应用内部，使用时不需要网络。

顺便说一句，很多解决方案其实不算Hybrid，比如Adobe AIR、Titanium、Mono，这些都是使用某一特定技术开发跨平台应用的工具，最终产品都是编译成原生来跑的。

我们没有选择phoengap为技术基础（我对此并不满意，我认为以phonegap为基础可以少走一些弯路，少花一些精力，还能产出很多有价值的副产品），而是自行开发原生框架，主要目标平台是Android——嗯，就是那个从系统版本到模块组合都巨分散的Android，可以这么说，坎坷从立项的那一刻起就已经注定了……接下来，便请听我一一讲述：Android Hybrid App四大坑。（此文主要针对Android 4.3-的webview，部分浏览器比如Chrome已经改善了具体实现，所以Web App其实环境不错。）

游戏泡泡v0.2首页截图
游戏泡泡v0.2首页截图

前端代码开源就好，https://github.com/Dianjoy/gamepop，要跑起来需要修改config.js，把if (debug) {}的内容删掉。

继续阅读“Android Hybrid App四大坑”

的pathname在不同浏览器中表现不同

的pathname在不同浏览器中表现不同。

<a href="download://gamename/游戏名称">Download</a>

在桌面版Chrome 32里，这样的<a>，其pathname会被解析成“//gamename/游戏名称”。

在Android 4.2的WebView里，会被解析成“/游戏名称”。

Phonegap 2.6在Android上的Icon设置

Phonegap 2.6设置应用的桌面icon，在AndroidManifest > Application > Application Nodes > Activity。

这个问题Google了半天也没找到答案，难道只有我碰到了？

我的测试平台：Windows 8 + Eclipse 4.2 + ADT 21.1 + 小米 2 + Phonegap 2.6。

开发测试一切正常，只是编译输出的应用装到手机上只能用默认图标，怎么都改不过来。我把所有res/drawable-xxxx里面的icon都换了也不行。然后修改AndroidManifest > Application > Application Attributes里的icon和logo设置，也不行。怎么试都不行，Google也找不到。安装时提示的图标正常，查看运行过/运行中的图标也正常，就那个桌面上的图标不对。

刚才吃过饭，来回点，突然发现在Application Nodes里有个Activity，还可以设置icon和logo，想着反正也不亏，就也给填上了，居然OK了。

哎，记一下，省得以后忘掉。

原来早期Android的WebView真的很奇葩

Android 3系统之后才支持overflow:scroll用手指触摸滚动，之前需要用js模拟。并且touchmove事件只触摸一次，如果需要自主控制，则需要event.preventDefault();

以前没在Android下做过原生HTML开发，所以一直觉得大家的吐槽很莫名其妙——不同于桌面错综复杂的环境，高度统一的webkit内核浏览器能整出什么幺蛾子来？结果这次遇到了，才发现原来早期Android系统的WebView真的很奇葩。

先是有一块文字，可能比较长，我就在作容器的div上写样式为overflow:scroll，以为这样就能用手指触摸滚动了，拿来小米1S一试，通过。结果后来同事找来，说他的手机不行。研究半天，在StackOverflow上看到Android 3.0之后才开始支持触摸滚动，想在2.x系统上实现还得自己写JS实现。一看他的手机，2.3.5。OK，写JS嘛，好说。

事先我已经知道触摸事件的触发机制，所以很自然的就去侦听touchstart，touchend，touchmove。结果，不行，滚不起来。我以为自己记错了，去MDN上查了查，没错；又猜是事件用错了，尝试touchleave和touchcancel，也不行；2.x的系统不能装Chrome，测试也不好搞。后来终于通过输出发现，touchmove只触发一次，然后Google之，原来Android设计的机制就是只触发一次，想要自主控制事件结束的时机只能event.preventDefault()。这……难道touchmove不是对应mousemove么？

只这两点就花了我不少时间，不知道还有没有其它的坑。反正做完这个需求我不禁感慨，早期Android的WebView真的很奇葩啊。

PS：这篇博文应该早于上一篇，换言之就是这个时候我为了在本地调试打开了“Emulate Touch Events”开关的。

Nexus S很诡异的单击变双击现象

如果在三星Nexus S上，遇到单击一次触发两次事件的情况，并且使用的是Zepto作为底层类库，可以尝试用“tap”替换“click”。当然一直使用“tap”可能更好。

被报告了一个很诡异的Bug，在且只在三星Nexus S上出现，系统版本4.0.4和4.1.1都有：

一次点击，会触发两次点击事件。两次事件的 target 和 currentTarget 都相同。

因为只在三星Nexus S上出现，调试相当困难，反复无果。后来想起来我用zepto类库作为底层库，而且编译时把touch部分也编译进去了，所以尝试着将 click 替换为 tap ，居然解决了……

具体问题症结，以后再研究吧。

Flash开发Android应用的一点摸索

今天早上在小米手机上跑通了Flash Builder开发Android应用的流程，大致经验如下：

  1. 真机测试要求移动设备必须有驱动，能够被windows系统识别
  2. Flash Builder比较傻，只能真机调试
  3. 调试的设备需要安装air，我的xt800系统只有2.1，无法安装air，所以虽然可以识别，但是无法调试，用小米就没问题
  4. 发布的时候可以直接打包运行时，但是体积会膨胀很多（大约8M，应该包含了air运行时）
  5. 发布后的apk能否在机器上运行仍需比照air的系统要求，xt800又败了……

分析Adobe的现状，我这么认为：

正如之前宣布的，已经放弃继续开发移动端的Flash Player插件，因为他们认为在移动端，Native App会击败绝大多数的Web App，而且开发者也几乎不会针对移动用户做很好的优化。与此同时他们加大对新开发环境的布局，新版Flash Pro和Flash Builder都支持至少三种Native App的发布（iOS、Android、Blackberry）。不过可惜的是，相对于iOS直接编译成原生应用，Android系统必须附带一个内绑定的air运行时实在让人很不爽，性能和系统要求会给产品发布带来很大问题。而且我相信iOS那种封闭的环境都能搞定，Android这种开放的标准理应更好做才是。

这可能跟air的尴尬处境有关。相比Flash Player这个事实标准，air从推出到现在始终不温不火，Adobe始终没有公布过它的安装率，估计一定不高。air除了能让我们这些前端工程师能不太费力的开发一些本地应用，似乎并没有起到很大的作用。但是Adobe官方对他寄予厚望，应用市场、开发大赛一直在搞，不过似乎没什么起色。如今，他们将air定位成移动端开发解决方案，试图和Flash Player各自霸占一条业务线。但是AIR对系统的要求使得它无法适用于所有机型，这就更让人心生迷惑了，有谁会选择这样一个解决方案呢？

或者我只能这样理解，air本身提供了多种成熟的解决方案，比如视频支持、3D支持、绘图API等，这些东西如果使用标准SDK自行开发的话会是很大一笔开支；而系统是可以自己刷的，所以相对起来，我们可以认为用户会比看起来的更多。