IT瘾mobile推荐

微信收费事件背后被广泛忽略的技术细节

Sun, 14 Apr 2013 22:27:17 CST

作为一个横跨通信与互联网两大行业的从业者，前四年的核心网经验和后五年的互联网经验让我不得不感慨一个非常遗憾的现实：通信与互联网两大行业本来可以有珠联璧合的技术协同，为移动互联网提供近乎零耗电零流量的PUSH机制，但由于两个行业之间长期以来的价值观隔阂和互防心态，导致如今的手机PUSH技术不仅为用户增加了显著的电量消耗，还对移动运营商的基础设施造成了完全不必要的信令压力。微信与运营商的纷争正是这种冲突集中爆发的结果。

看到不少来自两个行业的专业分析，通信行业的专家谴责微信过于频繁的心跳和短包导致“信令风暴”，而互联网人士则往往站在用户与道德的制高点上对移动运营商挖苦讥讽，双方都很少探究这个问题的深层次技术和利益矛盾。这里我不妨提一提有些大家没有真正重视的技术细节。

为什么使用同样PUSH技术的Apple和Google等巨头，没有被运营商卯上，唯独单单拿微信下手？大家也许会认为这是运营商欺软怕硬，拿Apple和Google没办法。其实从实际数据上来看（下面将提到），微信确确实实产生了远超Apple和Google的信令需求。难道是因为腾讯技不如人，被逮着了尾巴？其实不然，我们曾经也在PUSH技术上投入了较多的分析研究，其中一项发现或许可以解释各种原委。根据分析，一般当基带空闲超过一定时间后，运营商的IP网关会自动释放（关闭）连接。目前各家所使用PUSH通道的实现原理虽然同为『长连接慢心跳』，但这个『慢』字却有很大的文章。 Google在Android系统中使用蜂窝（2G/3G）网络连接GCM的PUSH通道时，默认采用的心跳周期是28分钟，这才是所谓“慢”的含义 —— 尽可能降低心跳的频度，从而达到尽量省电的目的。但这个放诸全球绝大部分地区借行得通的规则，到了中国大陆，就出现了问题。以中移动的2.5G网络为例，经过粗略测试，大约5分钟左右的基带空闲，连接就会被释放，这就是为什么微信Android版本选择以『5分钟』为周期发送连接心跳。可能有人会有疑问了，『那Google以28分钟发送心跳，岂不是在中移动的2.5G网络下无法保持PUSH长连接？』事实上，确实如此，这也是为什么Google的PUSH通道经常『迟到』。当我们活跃使用手机时，由于基带往往并不会闲置，所以部分掩盖了问题的本质。另外，当连接到Wi-Fi时，宽带的网关一般没有空闲释放机制，所以长连接会得到保持，这也进一步减少了我们平时遭遇的PUSH迟到。

『5分钟』的心跳周期到底是什么概念？可以理解为，每部安装了微信的Android设备每天发送近300条短信（其实占用的信令资源还远超这个数量）；还意味着每天你的手机将被从待机省电状态唤醒近300次，每次相当于打一个几秒钟的电话。粗略测算，一般的Android手机每天有超过15-20%的电量被消耗在发送过度频繁的心跳上。其实，这都还远不是最糟糕的事情。由于众所周知的原因，大陆行货渠道发售的Android手机都无法使用Google的PUSH通道，原本每个手机中只需要建立的唯一共享的PUSH通道，被人为分裂，以至于每一个声称为用户提供实时通知的国内App，基本都在重复上面微信所做的行为。当你的手机中同时安装了多个这类App时，无论手机的耗电，还是运营商的信令负担，都要数倍于上述情形。

虽然我向来不惮以最坏的恶意揣测国内的垄断巨头，但在这个事情上，中移动或许确有它的苦衷。正如很多技术文章中所言，2G网络的基础结构和协议并未针对IP传输优化，其服务IP链路的信令承载能力相对较弱，而TD-SCDMA又长期得不到真正的发展，导致中移动的2.5G网络承受了超龄超载的负荷。刻意缩短空闲连接的释放超时，可能原本是期望能起到节省信道资源的目的，没想到聪明反被聪明误，这一限制性的举措让互联网应用不得不以远高于正常的频率发送心跳以维持PUSH长连接，结果大大加重的信令负担，给本就脆弱的2.5G网络雪上加霜，而且更给用户的手机造成了远超常规PUSH技术的电量消耗，造成了如今这一『三输』的格局。

其实，不光是微信，整个移动互联网行业都在努力解决PUSH机制目前所面对的各方面问题。包括Google、Apple这样在整个行业举足轻重的巨头，都仅仅在OSI通信协议的4层以上作各种努力，目前几乎所有的PUSH机制都基于『TCP长连接慢心跳』方式实现。虽然『慢心跳』如果得以正常工作，可以在一定程度上降低手机基带模块的工作频度，但无论互联网行业在技术上再如何标榜“PUSH”相比“PULL”的流量优势，但在OSI的下三层来看，基带模块所承受的负担和“PULL”仍然没有本质差别。这就决定了耗电问题不可能从互联网技术层面彻底解决。事实上，在移动通信网络中，信令是一种天然的最佳PUSH载体，它不需要任何IP层的收发包（也就不需要TCP连接）就能实现秒级的实时性，最重要的是它没有任何额外的电量负担，手机完全只需处于正常的待机状态。可惜移动运营商只会将其运用在一本万利的SMS（及WAP PUSH）服务，压根不可能无偿提供给互联网产业使用。结果，互联网行业选择了虽然不用付费，但却代价高昂的『TCP长连接』，只为让用户享受到免费的通知服务。这种两大行业置用户体验于不顾的分庭抗礼，已经相持近10年，而当互联网终究开始以免费服务反噬移动运营商的SMS甚至语音业务时，运营商再也坐不住了…… 但与其饱受信令风暴的折磨，不如主动免费开放信令通道作为更高效的PUSH通道给互联网产业使用，再以『免费增值』的思路构建有QoS保障的VIP PUSH服务。不仅可以大幅度节约信令资源，更能以用户体验的提升打造核心竞争优势和增值空间。能否走出这样一条转折的道路，就看运营商是否愿意转变思维了。

注：由于iOS系统的相对封闭性，暂时未能测定Apple的Push通道APNS在2.5G网络下的长连接心跳周期。欢迎了解的朋友补充测试数据。

UPDATE：更正微信Android版在中移动2.5G网络下的心跳周期为5分钟（此前测定的2.5分钟存在偏差）

如何通过 OAuth 2.0 使 iOS Apps 集成 LinkedIn 登录功能？

Mon, 21 Mar 2016 14:44:02 CST

社交网络早已成为人们日常生活的一部分。其实，社交网络也是编程生活的一部分，大多数 App 必须通过某种方式与社交网络交互，传送或接收与用户相关的数据。大多数情况下，用户需要登录某种社交网络，授权 App 代表自己进行请求。

目前，此类社交网络的种类非常丰富，以 Facebook 与 Twitter 最为常用。而且，iOS 系统内置了对这两款社交网络的支持。然而，对于其他类型的社交网络，开发者必须投入更多的努力，以使 App 获得授权访问这些社交网络，继而运行经过授权的合法请求。LinkedIn 就是这样一种社交网络，在本教程中，我们会了解如何为 App 授权，使之与 LinkedIn 的服务器交换受保护的数据。

为 iOS App 授权以访问 LinkedIn，并根据后者提供的 API 运行特定的操作，可以通过两种方法实现。方法一：使用 LinkedIn 支持的 OAuth 2.0 协议。方法二：使用 LinkedIn 提供的 iOS SDK。与所有第三方 SDK 一样，LinkedIn 提供的 SDK 必须集成到项目中，经过合理的配置才能使用。

在本文中，我们将仅专注于第一种方法。因此，我们将学习 LinkedIn 与 OAuth 2.0 指南中与此相关的指定内容，包括让用户通过 App（是任何 App，而不仅仅是 iOS 系统）登录 LinkedIn 并为 App 授权执行进一步请求的必要流程。尽管 LinkedIn iOS SDK 也是很好的选择，但笔者更喜欢 OAuth 方法，原因有三：

笔者个人更偏爱此类任务：使用 REST API 调用与服务器进行直接的交流，以顺利完成授权过程。
LinkedIn 网站中有关 LinkedIn iOS SDK 的介绍相当明确详尽，因此笔者认为基于相同主题写的教程恐怕益处不大。
笔者认为，使用 LinkedIn iOS SDK 时存在一个缺陷：官方的 LinkedIn App 必须已经安装在设备中，否则登录与授权过程就无法完成。如果某个 App 需要获得用户的 LinkedIn 主页信息，但用户并不想安装 LinkedIn 官方应用，就会造成不便。

关于 OAuth 2.0 协议，能说的实在太多了。读者最好还是登录官网仔细研读一下。简而言之，为了成功完成登录与授权过程，本教程将会遵循以下步骤：

必要地，我们将在 LinkedIn 开发者网站创建一个新的 App。从而得到完成后续过程必备的两个重要密匙（Client ID 与 Client Secret）。
通过一个 Web 视图，让用户登录其 LinkedIn 账户。
根据以上所得，再加上一些必要数据，向 LinkedIn 服务器索取授权码。
与一个访问令牌交换授权码。

访问令牌是与 OAuth 交互的必要条件。通过一个有效的令牌，我们便能向 LinkedIn 服务器发送经过授权的请求。并根据 App 的性质，“get”或“post” 数据到用户的主页。

在继续阅读之前，请确保你理解 OAuth 2.0 的工作原理，以及它的流（flow）。如果必要，阅读其他资源以获取更多信息（比如这儿，这儿和这儿）。

说了这么多，让我们进入正题，介绍本教程的演示应用，然后进入具体实现。笔者相信，我们将要学习的内容是趣味无穷的。

作为参考，以下是 LinkedIn 官方文档的链接：

演示 App 概览

我们在本教程中将要实现的演示 App 由两部分视图控制器组成：第一个（默认的 ViewController 类）只包含三个按钮：

一个名为 LinkedIn Sign In（LinkedIn 登录）的按钮，用于启动登录与授权流程。
一个名为 Get my profile URL（获得我的主页 URL）的按钮，用于执行一个经过授权的请求，使用访问令牌获得用户主页的 URL。
一个展示主页 URL 的按钮，点击之后会在 Safari 中打开用户的 LinkedIn 主页。

默认情况下，只会启用第一个按钮。实际上，只要还未获得访问令牌，该按钮就会一直可用。在其他情况下，第一个按钮会被禁用，同时启用第二个按钮。第三个按钮是隐藏的，只有当得到（通过第二个按钮）用户主页的 URL 时，才会可见。

第二个视图控制器会包含一个 Web 视图。通过该试图，你可以登录 LinkedIn 账户，这样认证与授权过程才能成功进行。当获得用于向 LinkedIn 发送合法请求的访问令牌后，该视图控制器就会被移除。

与往常一样，我们不需要从头开始创建项目。你可以下载一个启动项目，在此基础上继续搭建。

基本上，我们的主要努力将专注于获取访问令牌。我们会遵循 OAuth 2.0 协议以及 LinkedIn 指南的指定，一步一步地完成所有必备流程。获得访问令牌之后，我们会继续解释如何向 LinkedIn 发送合法请求，以获得授权用户公共主页的 URL。成功得到 URL 之后，我们会请用前面提到的第三个按钮，将主页内容显示在 Safari 浏览器中。

在你继续阅读之前，请确保已经下载启动项目，打开它并熟悉它的。准备就绪之后，请继续往下看。

LinkedIn 开发者网站—— 创建新的 App

实现 OAuth 2.0 登录流程的第一步，是在 LinkedIn 开发者网站创建一个新的 App 记录。为此，你仅需访问此链接。如果你还没有登录 LinkedIn 主页，你将收到提示以完成登录操作。

注意：如果你在下面的步骤中使用 Safari 出现问题，请选择其他浏览器。我使用的是 Chrome 浏览器。

登录之后，找到网站“我的应用（My Applications）”部分，你会发现一个名为“创建应用（Create Application）”的黄色按钮。点击它开始创建新的应用，之后我们会将它与 iOS App 进行联结。

在接下来出现的表格中，填写所有栏目。如果需要填写公司名称或上传应用 logo，不用担心，输入一些虚假信息也可。之后，接受使用条款，点击提交按钮。请一定要在带红色星号的栏目中输入内容，否则你将无法继续。以下为示例：

我们的目标是抵达下一个页面：

如你在上面的截图中所见，在此页面可以看到 Client ID 与 Client Secret 的值。请不要关闭该窗口，因为接下来的步骤中会用到它们。你可以使用窗口左侧的菜单选项，随意探索应用的设置。

此处，除了得到 Client 密匙（Client ID 与 Client Secret 的值），我们还要完成的另一项重要任务，是在“合法重定向 URLs(Authorized Redirect URLs)”一栏填入合适的值。当客户端 App 试图刷新现有的访问令牌，用户无需通过 Web 浏览器重新登录，使用合法重定向 URL 即可。OAuth 流会自动使用该 URL 将 App 重定向。在正常的登录过程中，客户端 App 与 LinkedIn 服务器会交换该 URL，同时取得授权码与访问令牌。总之，该值不能为空，稍后会用来与服务器进行交换，因此必须定义它。

重定向 URL 不需要是真实存在的 URL，可以是任何以 “ https://” 开头的值。在此，笔者将其赋值如下。你可以将其改为任何你希望的值。

  https://com.appcoda.linkedin.oauth/oauth

如果你使用了一个不同的 URL, 千万记得对后面出现的代码进行相应的修改。

在“OAuth 2.0”一节写入合法重定向 URL 后，必须点击添加按钮，保证将其加入 App 中。

此外，记得点击屏幕底部的更新按钮。

至于有关访问权限的选项，保留基本选项即可，因为其完全满足本教程的需求。当然，你也可以选择更多权限，或在演示 App 准备就绪之后再做修改。请注意，如果 App 请求的最初权限遭到改动，用户必须重新登录以认可这些改动。

开始授权过程

现在，打开 Xcode 中的启动项目，我们即将开始实现，并最终完成 OAuth 2.0 流。不过，在开始之前，请选择项目导航栏（Project Navigator）中的 WebViewController.swift 文件，打开它。在该类的头部，你会看到两个名为 linkedInKey 与 linkedInSecret 的变量。你需要将之前从 LinkedIn 开发者网站得到的 Client ID 与 Client Secret 值分别赋值给这两个变量（简单的复制、黏贴即可）。

本步的主要目的，是准备好用来获取授权码的请求，并通过一个 Web 视图加载它。界面生成器（Interface Builder）中的 WebViewController 已经包含了一个 Web 视图，因此我们将以 WebViewController 类为基础构建视图。用于获取授权码的请求必须包含以下参数：

response_type：取值为恒定的标准值：code。
client_id：取值为来自 LinkedIn 开发者网站的 Client ID，之后会赋值给项目中的 linkedInKey 属性。
redirect_uri：取值为在前一节指定的合法重定向 URL。请确保在后面的代码段中填入相应的值。
state：取值为唯一的字符串，用于预防跨站请求伪造(CSRF)。
scope：取值为 App 请求的访问权限列表，以 URL 形式编码。

下面，介绍代码的具体实现。首先，在 WebViewController 类下创建一个名为 startAuthorization() 的新函数。该函数的第一个任务是根据上文的描述为请求参数赋值。

  func startAuthorization() {  
    // Specify the response type which should always be "code".
    let responseType = "code"

    // Set the redirect URL. Adding the percent escape characthers is necessary.
    let redirectURL = "https://com.appcoda.linkedin.oauth/oauth".stringByAddingPercentEncodingWithAllowedCharacters(NSCharacterSet.alphanumericCharacterSet())!

    // Create a random string based on the time interval (it will be in the form linkedin12345679).
    let state = "linkedin\(Int(NSDate().timeIntervalSince1970))"

    // Set preferred scope.
    let scope = "r_basicprofile"


}

请注意：不是简单地将合法重定向 URL 赋值给 redirectURL 变量。我们需要将 URL 中的特殊符号通过 URL 编码替换为百分比编码字符。因此，下面的链接：

  https://com.appcoda.linkedin.oauth/oauth

将会转换为：

  https%3A%2F%2Fcom.appcoda.linkedin.oauth%2oauth

(See more about URL-encoding here).

（点此了解 URL 编码的更多信息。）

其次，state 变量必须包含一个唯一且莫测的字符串。在上面的代码中，我们将“linkedin”字符串与当前时间戳（自1970年以来的时间间隔）的整数部分进行联结，以此确保字符串的唯一性。你也可以生成随机字符，再将其附加到 state 字符串上。

最后，将 scope 赋值为“r_basicprofile”，后者与之前在 LinkedIn 开发者网站设定的 App 访问权限相匹配。当你设置访问权限时，请确保与官方文档中的规定一致。

Our next step is to compose the authorization URL. Note that the https://www.linkedin.com/uas/oauth2/authorization URL must be used for the request, which is already assigned to the authorizationEndPoint property.

下一步，创建授权 URL。请注意，URL https://www.linkedin.com/uas/oauth2/authorization 必须用于该请求，而该 URL 已经赋做 authorizationEndPoint 属性的值。

回到代码：

  func startAuthorization() {  
    ...

    // Create the authorization URL string.
    var authorizationURL = "\(authorizationEndPoint)?"
    authorizationURL += "response_type=\(responseType)&"
    authorizationURL += "client_id=\(linkedInKey)&"
    authorizationURL += "redirect_uri=\(redirectURL)&"
    authorizationURL += "state=\(state)&"
    authorizationURL += "scope=\(scope)"

    print(authorizationURL)
}

此处，笔者添加了打印命令，是为了让读者亲眼看到该请求最终是如何形成的。

最终，我们需要在 Web 视图中加载该请求。请记住，只有前文所述的请求配置得当，用户才能通过 Web 视图成功登录。否则，LinkedIn 将返回错误消息，导致无法进行下一步操作。

因此，请确保正确拷贝了 Client Key、Client Secret，以及统一的合法重定向 URL。

在 Web 视图中加载该请求只需短短几行代码：

  func startAuthorization() {  
    ...

    // Create a URL request and load it in the web view.
    let request = NSURLRequest(URL: NSURL(string: authorizationURL)!)
    webView.loadRequest(request)
}

在结束本节之前，我们必须调用上面的函数。可以通过 viewDidLoad(_: ) 函数进行调用：

  override func viewDidLoad() {  
    ...

    startAuthorization()
}

此时，你终于可以运行 App，测试其是否成功了。如果你根据笔者的指导配置正确，应该可以看到以下页面：

不过，先别急着登录 LinkedIn 账号，本节还有一部分工作未完成。然而，如果你看到了登录表格，说明你已经成功发送了获取授权码的请求。登录之后，LinkedIn 会向浏览器（在本例中，也即我们的 Web 视图）返回一个授权码。

除此之外，还会在控制台打印出 authorizationURL（授权 URL）字符串：

Getting an Authorization Code

获取授权码

授权码请求函数准备就绪，且在 Web 视图中成功加载之后，我们可以继续执行 webView(:shouldStartLoadWithRequest:navigationType) 委托函数。在此函数中，我们会捕获来自 LinkedIn 的响应，并从中抽取出渴望已久的授权码。

包含授权码的响应如下所示：

  http://com.appcoda.linkedin.oauth/oauth?<strong>code=AQSetQ252oOM237XeXvUreC1tgnjR-VC1djehRxEUbyZ-sS11vYe0r0JyRbe9PGois7Xf42g91cnUOE5mAEKU1jpjogEUNynRswyjg2I3JG_pffOClk</strong>&state=linkedin1450703646

因此，我们需要将该字符串分为多个部分，隔离出“code”的值。不过，有两点注意：其一，我们必须确保委托函数中的 URL 是我们感兴趣的。其二，必须确保授权码的确存在于该 LinkedIn 响应中。代码的实现如下：

  func webView(webView: UIWebView, shouldStartLoadWithRequest request: NSURLRequest, navigationType: UIWebViewNavigationType) -> Bool {  
    let url = request.URL!
    print(url)

    if url.host == "com.appcoda.linkedin.oauth" {
        if url.absoluteString.rangeOfString("code") != nil {

        }
    }

    return true
}

首先，通过请求参数获得该 URL。接着，检查 URL 的主机属性值以确保这是我们需要的 URL（也即在 LinkedIn 开发者网站设定的重定向 URL）。如果是，请求字符串中 “code” 所在的范围，以验证该 URL 是否真的包含授权码。如果返回不为空，则证明授权码的确存在。

将 URL 字符串分为多个部分并不难。为了简化步骤，笔者将该任务分为两步：

  func webView(webView: UIWebView, shouldStartLoadWithRequest request: NSURLRequest, navigationType: UIWebViewNavigationType) -> Bool {  
    let url = request.URL!
    print(url)

    if url.host == "com.appcoda.linkedin.oauth" {
        if url.absoluteString.rangeOfString("code") != nil {
            // Extract the authorization code.
            let urlParts = url.absoluteString.componentsSeparatedByString("?")
            let code = urlParts[1].componentsSeparatedByString("=")[1]

            requestForAccessToken(code)
        }
    }

    return true
}

除了上面新出现的两行代码，你也肯定注意到了对 requestForAccessToken(_: ) 函数的调用。这是我们将在下一部分实现的自定义函数。在此函数中，我们会用此处获得的授权码读取访问令牌。

如你所见，只差一步，我们就能使用 OAuth 2.0 流获取访问令牌了。此处扼要重述一下之前的步骤：首先，我们成功创建了获取授权码的请求。接着，作为授权过程的一部分，用户通过该请求连接他们的 LinkedIn 账号。最后，得到并抽取出授权码。

如果你想对目前的 App 进行测试，只需注释掉 requestForAccessToken(_: ) 函数的调用部分即可。你大可以在任意位置添加打印命令，从而深刻理解每个步骤的作用。

Requesting for the Access Token

信息结构，创作我们的信息就是如此，我已经很是在此基础上我们创作就是token整个结构就是做这些事情的

请求访问令牌

此前，我们与 LinkedIn 服务器的所有交流都是通过 Web 视图进行的。从现在起，我们将仅通过简便的 RESTful 请求（也即 POST 与 GET 请求）与服务器交流。更具体地说，我们会发起一个 POST 请求来获取访问令牌，之后再用 GET 请求获得用户主页的 URL。

话虽如此，现在要先创建在上一部分末尾提过的新的自定义函数：requestForAccessToken()。在此函数内部，我们将执行三个任务：

准备好 POST 请求的参数。
初始化并配置一个可变的 URL 请求对象（NSMutableURLRequest）。
实例化一个 NSURLSession 对象，继而执行一个数据任务请求。在得到恰当的响应之后，我们将访问令牌存储在用户默认的字典中。

准备 POST 请求参数

与获取授权码的请求准备相似，为了获得访问令牌，我们需要在请求中 POST 特定的参数与其对应的值。这些参数包括：

grant type: It’s a standard value that should always be: authorizationcode.
code: The authorization code acquired in the previous part.
redirect_uri: It’s the authorized redirection URL we’ve talked about many times earlier.
client_id: The Client Key value.
client_secret: The Client Secret Value.
grant type：取值为恒定的标准值：authorizationcode。
code：取值为在上一部分获得的授权码。
redirect_uri：取值为前面多次提到的合法重定向 URL。
client_id：取值为 Client Key 的值。
client_secret：取值为 Client Secret 的值。

在上一部分得到的授权码将在新函数中用作参数。首先，让我们为参数“grant type”与“redirecturi”赋值：

     func requestForAccessToken(authorizationCode:     String) {
    let grantType = "authorization_code"

    let redirectURL = "https://com.appcoda.linkedin.oauth/oauth".stringByAddingPercentEncodingWithAllowedCharacters(NSCharacterSet.alphanumericCharacterSet())!
}

其他所有参数的值 App 都已经知道了，因此，我们可以将其整合为一个字符串：

  func requestForAccessToken(authorizationCode: String) {  
    ...

    // Set the POST parameters.
    var postParams = "grant_type=\(grantType)&"
    postParams += "code=\(authorizationCode)&"
    postParams += "redirect_uri=\(redirectURL)&"
    postParams += "client_id=\(linkedInKey)&"
    postParams += "client_secret=\(linkedInSecret)"
}

如果你曾用 NSMutableURLRequest 类创建过 POST 请求，那你一定知道 POST 参数无法以字符串的形式传送。它们必须转化为 NSData 对象，再赋值给请求的 HTTPBody 部分（后文会有解释）。因此，让我们按照要求转化 postParams：

  func requestForAccessToken(authorizationCode: String) {  
    ...

    // Convert the POST parameters into a NSData object.
    let postData = postParams.dataUsingEncoding(NSUTF8StringEncoding)
}

准备请求对象

准备好 POST 参数之后，我们可以继续初始化并配置 NSMutableURLRequest 对象。初始化时会用到获取访问令牌所需的 URL( https://www.linkedin.com/uas/oauth2/accessToken) ，而后者已经赋值给 accessTokenEndPoint 属性。

  func requestForAccessToken(authorizationCode: String) {  
    ...    

    // Initialize a mutable URL request object using the access token endpoint URL string.
    let request = NSMutableURLRequest(URL: NSURL(string: accessTokenEndPoint)!)
}

Next, it’s time to “say” to the request object what kind of request we want to make, as well as to pass it the POST parameters:

接下来，告诉请求对象我们想要创建的请求类型，并传入 POST 参数：

  func requestForAccessToken(authorizationCode: String) {  
    ...

    // Indicate that we're about to make a POST request.
    request.HTTPMethod = "POST"

    // Set the HTTP body using the postData object created above.
    request.HTTPBody = postData
}

根据 LinkedIn 文档，请求的 Content-Type 部分需要设置为 application/x-www-form-urlencoded：

  func requestForAccessToken(authorizationCode: String) {  
    ...

    // Add the required HTTP header field.
    request.addValue("application/x-www-form-urlencoded;", forHTTPHeaderField: "Content-Type")
}

终于，请求对象的必要配置完成了。现在可以使用它了。

Performing the request

执行请求

我们将把用于获取访问令牌的请求实现为 NSURLSession 类的对象。通过该对象，创建一个数据任务请求，并在完成处理程序（completion handler）内部处理 LinkedIn 服务器的响应：

  func requestForAccessToken(authorizationCode: String) {  
    ...

    // Initialize a NSURLSession object.
    let session = NSURLSession(configuration: NSURLSessionConfiguration.defaultSessionConfiguration())

    // Make the request.
    let task: NSURLSessionDataTask = session.dataTaskWithRequest(request) { (data, response, error) -> Void in

    }

    task.resume()
}

如果请求成功，LinkedIn 服务器将会返回包含访问令牌的 JSON 数据。因此，我们的任务是得到该 JSON 数据，将之转化为字典对象，然后抽取出访问令牌。当然，这一切只有在返回的 HTTP 状态码是 200，也即请求成功时，才能进行。

  func requestForAccessToken(authorizationCode: String) {  
    ...

    // Make the request.
    let task: NSURLSessionDataTask = session.dataTaskWithRequest(request) { (data, response, error) -> Void in
        // Get the HTTP status code of the request.
        let statusCode = (response as! NSHTTPURLResponse).statusCode

        if statusCode == 200 {
            // Convert the received JSON data into a dictionary.
            do {
                let dataDictionary = try NSJSONSerialization.JSONObjectWithData(data!, options: NSJSONReadingOptions.MutableContainers)

                let accessToken = dataDictionary["access_token"] as! String
            }
            catch {
                print("Could not convert JSON data into a dictionary.")
            }
        }
    }

    task.resume()
}

我很好奇

此类操作可能抛出异常，将json 数据的倒换就是加载我们呢自身的SDK，接入信息就是从来不会有很多的考很多事情就是自己做起来用户就是会考请注意，转化发生在一个 do-catch 语句内部，因为从 Swift 2.0 开始，此类操作可能抛出异常（并不存在错误参数）。在我们的演示 App 中，无需特别考虑出现异常的情况，因此可以向控制器发送一条信息，表示转化失败。如果一切运行顺利，我们就将 JSON 数据（闭包中的数据参数）转化为字典（dataDictionary 对象），之后就可以直接读取访问令牌。

接下来做什么呢？将字典保存在用户默认的字典中，然后移除视图控制器：

  func requestForAccessToken(authorizationCode: String) {  
    ...

    // Make the request.
    let task: NSURLSessionDataTask = session.dataTaskWithRequest(request) { (data, response, error) -> Void in
        // Get the HTTP status code of the request.
        let statusCode = (response as! NSHTTPURLResponse).statusCode

        if statusCode == 200 {
            // Convert the received JSON data into a dictionary.
            do {
                ...

                NSUserDefaults.standardUserDefaults().setObject(accessToken, forKey: "LIAccessToken")
                NSUserDefaults.standardUserDefaults().synchronize()

                dispatch_async(dispatch_get_main_queue(), { () -> Void in
                    self.dismissViewControllerAnimated(true, completion: nil)
                })                
            }
            catch {
                print("Could not convert JSON data into a dictionary.")
            }
        }
    }

    task.resume()
}

注意，视图控制器会在主线程中移除。请永远牢记，与 UI 相关的改动必须发生在 App 的主线程中，而不是背景线程中。而上面显示的完成处理程序（闭包）则永远在背景线程中执行。

Our ultimate goal has been finally achieved! We managed to acquire the access token that will “unlock” several API features.

我们的终极目标终于完成啦！得到访问令牌之后，可以“解锁”许多 API 功能。

获得用户主页的 URL

接下来，我们将演示如何用访问令牌获得用户主页的 URL，并在 Safari 浏览器中打开它。然而，在此之前，让我们先讨论一点别的问题。当你启动 App 时，你有两个选择，如下图所示：

默认情况下，LinkedIn Sign In (LinkedIn 登录)按钮是启用的，而 Get my profile URL（获得我的主页 URL）按钮是禁用的。既然现在已经得到了访问令牌，我们需要启用第二个按钮，同时禁用第一个按钮。这要如何完成呢？

一种实现方式是使用委托模式，通过一个委托函数通知 ViewController 类：访问令牌已经得到，请启用第二个按钮。另一种方式是从 WebViewController 类中 Post 一个自定义通知（NSNotification 对象），在 ViewController 类中监听该通知。其实，两种方法都可以实现。但是，还有一种更为简单的方法三：在 ViewController 出现时，检查访问令牌是否存在于用户默认的字典中。如果存在，就禁用登录按钮，启用第二个按钮。否则，就保持不变。

此处，我们会在 ViewController 类中实现一个新的小函数来进行检查。请注意，我们还设置了第三个默认隐藏的按钮（也即 btnOpenProfile IBOutlet 属性）。当得到用户主页的 URL 时，该按钮就会变为可见，并以此 URL 字符串作为其标题（后文会有示例）。

Now, let’s define this new function:

现在，先来定义这个新函数：

  func checkForExistingAccessToken() {  
    if NSUserDefaults.standardUserDefaults().objectForKey("LIAccessToken") != nil {
        btnSignIn.enabled = false
        btnGetProfileInfo.enabled = true
    }
}

我们会在 viewWillAppear(_: ) 方法中调用该函数：

  override func viewWillAppear(animated: Bool) {  
    super.viewWillAppear(animated)

    checkForExistingAccessToken()
}

之后，App 就能合理地启用或禁用 ViewController 中的两个按钮了。

接下来，让我们聚焦于 getProfileInfo(_: ) IBAction 方法。此方法会在 Get my profile URL（获得我的主页 URL）按钮被点击时执行。届时，我们可以向 LinkedIn 服务器发送 GET 请求，使用访问令牌获得用户主页的 URL。此处采用的方法与在上一部分创建获取访问令牌的请求时所用的方法非常相似。

现在，让我们从指定请求的 URL 字符串开始吧。请注意，当你不是很确定自己需要什么 URL，或者指定哪些参数时，大可以寻求官方文档的帮助。

  @IBAction func getProfileInfo(sender: AnyObject) {
    if let accessToken = NSUserDefaults.standardUserDefaults().objectForKey("LIAccessToken") {
        // Specify the URL string that we'll get the profile info from.
        let targetURLString = "https://api.linkedin.com/v1/people/~:(public-profile-url)?format=json"
    }
}

此处，作为额外措施，我们再一次检查了访问令牌是否存在。通过 if-let 语句，如果访问令牌存在，我们便将其赋值给 accessToken 常量。而且，上面的 URL 会返给我们用户主页的 URL。不要忘记，在执行这类请求之前，必须获得适当的权限。在本演示案例中，我们已经获得了访问用户基本介绍信息的权限。

接下来，创建一个新的 NSMutableURLRequest 对象，并以“GET”方法作为理想的 HTTP 方法。此外，还需指定一个 HTTP 头字段，此处将用访问令牌为其赋值。

  @IBAction func getProfileInfo(sender: AnyObject) {
    if let accessToken = NSUserDefaults.standardUserDefaults().objectForKey("LIAccessToken") {
        ...

        // Initialize a mutable URL request object.
        let request = NSMutableURLRequest(URL: NSURL(string: targetURLString)!)

        // Indicate that this is a GET request.
        request.HTTPMethod = "GET"

        // Add the access token as an HTTP header field.
        request.addValue("Bearer \(accessToken)", forHTTPHeaderField: "Authorization")        
    }
}

最后，再一次地，使用 NSURLSession 与 NSURLSessionDataTask 类创建该请求：

  @IBAction func getProfileInfo(sender: AnyObject) {
    if let accessToken = NSUserDefaults.standardUserDefaults().objectForKey("LIAccessToken") {
        ...

        // Initialize a NSURLSession object.
        let session = NSURLSession(configuration: NSURLSessionConfiguration.defaultSessionConfiguration())

        // Make the request.
        let task: NSURLSessionDataTask = session.dataTaskWithRequest(request) { (data, response, error) -> Void in

        }

        task.resume()
    }
}

如果请求成功（也即 HTTP 状态码为 200），闭包中的数据参数将会包含服务器返回的 JSON 数据。与之前一样，我们必须将此 JSON 数据转化为字典，才能最终抽取出用户主页的 URL 字符串。

  @IBAction func getProfileInfo(sender: AnyObject) {
    if let accessToken = NSUserDefaults.standardUserDefaults().objectForKey("LIAccessToken") {
        ...

        // Make the request.
        let task: NSURLSessionDataTask = session.dataTaskWithRequest(request) { (data, response, error) -> Void in
            // Get the HTTP status code of the request.
            let statusCode = (response as! NSHTTPURLResponse).statusCode

            if statusCode == 200 {
                // Convert the received JSON data into a dictionary.
                do {
                    let dataDictionary = try NSJSONSerialization.JSONObjectWithData(data!, options: NSJSONReadingOptions.MutableContainers)

                    let profileURLString = dataDictionary["publicProfileUrl"] as! String
                }
                catch {
                    print("Could not convert JSON data into a dictionary.")
                }
            }
        }

        task.resume()
    }
}

现在，回到之前提到过的一点内容：profileURLString 的值将会赋给 btnOpenProfile 按钮的标题，该按钮也会变成可见。还记得不？我们现在的工作都是在背景线程中进行的，因此，我们还需将其加入主线程中：

  @IBAction func getProfileInfo(sender: AnyObject) {
    if let accessToken = NSUserDefaults.standardUserDefaults().objectForKey("LIAccessToken") {
        ...

        // Make the request.
        let task: NSURLSessionDataTask = session.dataTaskWithRequest(request) { (data, response, error) -> Void in
            // Get the HTTP status code of the request.
            let statusCode = (response as! NSHTTPURLResponse).statusCode

            if statusCode == 200 {
                // Convert the received JSON data into a dictionary.
                do {
                    ...

                    dispatch_async(dispatch_get_main_queue(), { () -> Void in
                        self.btnOpenProfile.setTitle(profileURLString, forState: UIControlState.Normal)
                        self.btnOpenProfile.hidden = false

                    })
                }
                catch {
                    print("Could not convert JSON data into a dictionary.")
                }
            }
        }

        task.resume()
    }
}

现在，运行 App，如果你成功得到了访问令牌，在点击 Get my profile URL（获得我的主页 URL）按钮后不久，你就能看到自己主页的 URL 显示在第三个按钮的位置。

在 Safari 浏览器查看主页

现在，通过使用访问令牌与 LinkedIn API，我们得到了用户主页的 URL。接下来就该验证其是否正确了。既然已将此 URL 设置为一个按钮的标题，最快的验证方法莫过于打开它了。具体的实现方法箱单简单，因此笔者也不必要多言：

  @IBAction func openProfileInSafari(sender: AnyObject) {
    let profileURL = NSURL(string: btnOpenProfile.titleForState(UIControlState.Normal)!)
    UIApplication.sharedApplication().openURL(profileURL!)
}

The last line above will trigger the appearance of Safari, which will load and display the profile webpage.

上面最后一行代码会触发 Safari 浏览器，后者会加载并展示用户的主页。

你可能已经发现，教程已经步入尾声，却仍然没有提及废除或刷新访问令牌的内容。其实原因如下：关于废除访问令牌，LinkedIn 并未提供任何相关的 API。因此，如果你需要停止 App 发送合法请求，最好的做法应该是从存储机制（数据库，用户默认设置等）中删除之。除此之外，一个访问令牌的有效期大约为60天（在笔者撰写本文之时，官网文档是如此规定的）。LinkedIn 建议，在此时间范围到期之前，刷新访问令牌。刷新的操作非常简单，你只需要从头进行验证与授权过程即可。刷新时，如果访问令牌有效，用户便无需再次输入登录信息，一切都会在后台进行，访问令牌会自动刷新，延迟有效期60天。然而，对于大多数 Web 应用，存在一个常见情况：后台刷新的一个基本前提，是用户已经登录了他们的 LinkedIn 账号，而对于 App 中的内部 Web 视图，这一条件无法满足。因此，在访问令牌快要到期之前，你很可能要让用户再走一遍登录流程。想要了解更多信息，可以点击此处，查看“刷新访问令牌”一节。好了，说再见的时候到了。笔者希望本教程对你有所帮助，并成功向 LinkedIn 发送经过授权的请求。

作为参考，你可以从 GitHub 下载本案例完整的 Xcode 项目文件。

OneAPM Mobile Insight 以真实用户体验为度量标准进行 Crash 分析，监控网络请求及网络错误，提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验，想阅读更多技术文章，请访问 OneAPM 官方技术博客。

[翻译]谈谈当今移动端设计者必备素质

Tue, 24 Jun 2014 00:46:13 CST

移动端一直以来都有自己的一套规则制约。同时,这也是一个高速发展的平台,随着新技术和功能的推陈出新。我们不能再像我们做海报和网页那样设计移动端。那么如今的移动设计者需要怎样的技能和思维模式呢？

挑战和约束

每个载体都有其局限性。即使是移动平台—设计者梦想中最理想的画板之一，都有其必须被遵循的特点。

设备的多元化

如今有不计其数的智能手机和平板电脑,每一种有不同的屏幕大小,像素密度,和物理输入(更不用说屏幕旋转)。这意味着我们不能只考虑iPhone 5 屏幕大小然后设计适配它。在移动网页端,响应式设计让我们不必大费周折地设计匹配,就能使设计适应不同屏幕。本地移动设计缺少流动性,因此我们需要考虑设计对于不同屏幕大小的适配，并记录不同变化对布局的影响。

操作系统多元化

如今，我们有3个主流的移动端操作系统，Android，IOS和Windows OS。每种操作系统都有其独有的接口标准，外部输入和设计规范，更别说系统版本之间的升级和变更。其中Android系统更加复杂，不同的安卓设备会受到设备制造商的限制，比如不同终端商的UI设计是不同的，硬件架构和处理能力也不尽相同。（更不用说运营商提供的后续升级）

虽说系统多元化的到来不至于使设计工作迥然相异，但是确实会影响到用户对操作系统在用户体验上的期望值。举例说吧，大多数用户对于安卓系统体验习惯于TouchWiz（三星用户界面）或Sense（HTC界面）。

性能

应用程序设计的方式可以影响系统耗电量。换句话说,我们的设计可以使我们的用户电量消耗殆尽。某些不必要的视觉效果或动画需要大量的图形运算处理;一个大量 Javascript Web页面会比较耗电。我们新买的设备可能运行APP非常流畅,2年后的老设备就会相应迟缓。这些例子只是来说明,移动设计师需要更了解他们的设计对于系统资源占用以及APP性能的影响。

开发成本的考量

很酷的新APP并不意味着它很容易实现。我们设计APP的方式可以直接导致我们的应用能否按时发布。如果我们不清楚地理解我们的设计决策的开发成本,那基本上是在给开发人员徒增负担，并为以后的摩擦埋下隐患。

新技能的学习

我们中的许多人作为设计师在某领域已接受专业的培训，但在数字设计领域才刚起步。我们从比较客观的从以往的经验来看一下（有人直接从火狐导出HTML 吧？）,并且这种有争议的方法依然在学校传授。随着移动端的发展其中的差异性越来越大，带来了我们当前的语言,几乎所有的工具和方法的不足，所以是时候改变我们的心态了。

移动平台并非白板

HTML也不是画布。你不能像你设计海报一样随意布局。我想用Photoshop也不能帮助我们改变,因为我们一直用它来设计海报和插图和润饰照片二十多年。我们仍然“画”我们的接口,而屏幕尺寸多样化和移动的动态交互特性都要求我们用一种不同的方法设计。

最佳界面思考并开始思考交互

我们开始认识到界面式的呈现并不会影响到移动端的设计。感谢Facebook和Yahoo天气为我们展示了不同的设计方式,让我们明白设计应该更专注于交互而不是静态展示。
交互,一次惊艳的视觉体验,正成为移动用户体验核心。他们不仅让接口本身变得生动友好，他们本身也是一个接口元素。交互能够建立APP与用户沟通的桥梁并表达动作，空间，转变以及一系列通信方式。这让纯静态的展示相形见拙。

把设计师的身份放下

你不需要独一无二或原创,尤其是只是为了“独特性”而重新设计一个已知接口的时候。往往坚持原本UI元素和模式是让应用程序按时完成是最明智之举。比起从头开始设计你的UI组件,专注于建立一个简单、有效的界面和创建品牌更有价值。

寻找灵感，现有的APP会比设计类网站更好

许多设计师喜欢去Behance或Dribbble上为他们的下一个移动项目寻找灵感。当然你会找到绝佳艺术的网站,但如果你不是一个经验丰富的移动设计师,这些模型可能会误导人。很多人只是创建模板但从未实现,而且他们会误导你相信每次都能为用户定制的UI。
真正的灵感来自于成功的应用。你会发现设计让产品稳步增长。他们的接口交互已经被现实世界检测过,而且你确认这些可以被复制。

学习新技能

对于平台的学习

就像你作为一个不错的网页设计师需要了解HTML / CSS是一样,你需要了解移动应用程序的底层结构,和他们是完全不同的网页。例如,他们并非像HTML / CSS一样呈现流内容,这会改变我们考虑布局的方式。你将没有神奇的CSS继承(至少不能像那样开箱即用)从页面中分离标记。甚至连标记的概念都没。

你需要阅读一些开发人员来的阅读手册,了解移动应用程序架构,编译和发布。理解一个移动设备是如何工作的以及哪些比较消耗电池。甚至你可能需要学习一些代码基础,作为长期回报:学习开发语言后,你的设计工作会更具效率和可行性。

学习移动端的各种元件

这里有一个清单:位置服务(Wi-Fi和GPS),蓝牙,蓝牙低功耗,灯,前后摄像头、麦克风、陀螺仪、加速度计、振动器、指纹扫描仪,眼球跟踪、语音识别,人脸识别,压力检测,这样的技术不胜枚举。每一个新技术都为全新APP的实现打开了大门。而你的职责是成为一个走在科技尖端的设计者。

学习你能用原生的组件做到什么

原生的UI组件实际上给了很多自由定制的空间,但是你需要知道如何使用它们。如果你能做到让你的UI在原生组件上做出的一点调整,开发人员会感谢你为他们节省大量的开发时间。

了解移动端的工作流

了解移动端SDK,集成并运行。了解移动框架,如RubyMotion Xamarin或Titanium。熟悉IDEs,以及图片资源位于一个移动项目位置,他们应该如何命名等。

了解移动端的用户界面模式

三大移动平台上有相似之处而差异在于对移动交互设计诠释。他们的用户期望从它们展示不同的东西。作为一个移动设计师,你应该完全意识到这些差异,能够检测到它们。
不要只关注一个移动平台。尝试所有三个,或者每天至少使用Android和iOS坚持6个月。我做到了，太棒了—你对每个平台的深刻理解将避免你盲目使用它们。而且多尝试切换的好处是：成为一个平台专注的粉丝并不利于移动设计者。

对UI解释说明的文档

因为界面并不能直观呈现所有业务,你需要文档说明不同的状态状态,交互,和动画以及如何应用对数据和环境。注释你的原型,提供动画实例,并为策划设备旋转。

在项目设计阶段学习UX

现代设计师应该是一个战略设计师。所以你的目标,并非仅仅创造美感,是投入到设计团队了解了产品的一切。优先快速原型为了得到早期的预见的用户想要什么。细节的艺术创作工作放到后面去做。确保所有设计与核心价值满足用户的需求。

在项目实现阶段持续关注UX

你不能光顾着给开发人员原型而忘记用户体验,因为大多数的图形需求将出现在开发阶段。新的交互和状态变化,需要新的图形资源。你需要实时响应，所以把你的椅子放在开发人员旁边并准备随时进入设计工作。

Mobile Web的一些小贴士

对响应设计负责

对于移动Web,响应设计并非一刀切的万能方案。在某些情况下能行得通,有时则不可取。你的责任是知道哪些情况移动端可用专用解决方案，哪些情况维护一个独立的代码库去做一些响应调整。即使你是“传统”的网络设计，也得优雅地计划你的页面布局,让它适应不同的屏幕尺寸。并去考量资源的大小:华丽的全屏1M背景图片会让你的用户在使用移动蜂窝数据访问时浪费金钱。

谨慎使用CSS和JS

诚然，CSS 动画、渐变、转换和阴影卓越而且非常易于实现。并且视觉效果很赞，还有一帮很酷的技术人员在开发，对吧？但这些元素在移动端都会对电量造成负面影响。使用越逼真生动的实现，我们的设备就会越不流畅而且越耗电。

CSS3 选择器可以控制在低端的设备上的性能影响。尽可能使用ID和 Classes，并保持你的元素选择器低版本。如果你用#submit替代.main .container .form > div .submit，那也是个好办法。

选择合适的工具

Sketch （移动开发的工具箱）。可以说是继承了 Adobe Fireworks，目前在移动端表现抢眼。
LiveView 和 Sketch Mirror 是能够在虚拟设备上映射你产品的工具。要知道很多东西再实际设备上效果会不一样，你能够运用它们轻松测试尺寸，交互和控制
Origami (by Facebook) 和 Quartz Composer 都是移动端的快速原型工具，能够让你在无需代码的情况下快速建立一个UI原型，并且为你带来一些逻辑思考和编程使用的大致了解。
PaintCode能够直接将UI和矢量图形直接导出成Objective-C的神器.
基于Web的原型软件。有很多： Balsamiq Mockups, Axure, UXPin, Moqups, Proto.io。
Flinto能够创建交互原型，并把他们实际安装到你的iPhone中，模拟真实应用。（利用 Safari 的添加到主屏幕功能）。
ImageOptim 能够为你无损压缩 PNG，JPG 文件。
版本控制软件，最好是 Git or Mercurial. 即时提交你的资源和改动到远程存储库，会比邮件一个Zip去给开发人员好的多。

所有这一切即将过时

不完全肯定,但移动技术发展的步伐令人难以置信的快速。很快我们将面临将可穿戴设备、智能设备和传感器和我们的移动应用互联的挑战。每天都有新的挑战和创新出来。所以,如果可以，保持求知欲，灵活思维，好奇心将会让作为设计师的你不会被时代所淘汰。

本文由人人都是产品经理小核桃翻译，转载请注明并保存本文链接

原文：http://uxmag.com/articles/what-does-it-take-to-be-a-mobile-designer-today

（关注更多人人都是产品经理观点，参与微信互动（微信搜索“人人都是产品经理”或“woshipm”）

微软发布 Office Mobile for Android 应用

Wed, 31 Jul 2013 21:13:02 CST

微软本周已经发布了 Office Mobile for Android 应用，可以在 Google Play 应用商店下载，率先从美国用户开始，将逐步在接下来扩展到其他 33 种语言和 117 市场。该 Office Mobile 应用面向 Android 4.0 或以上版本的手机推出，并没有提供平板的适配。

类似于 iPhone 版 Office Mobile，Office Mobile for Android 应用同样需要 Office 365 订阅来使用该应用，而且两者的功能非常相似。Office Mobile for Android 应用也包括了最近文档标签卡，访问 SkyDrive 和 SkyDrive Pro 的文件夹或 Email 附件，可以创建 Word 和 Excel 文档，也可以查看和编辑 Word、PowerPoint 和 Excel 文档。

有 Office Mobile 激活支持的 Office 365 订阅包括家庭高级版、小型企业高级版、中型企业版、企业版 E3/E4、教育版 A3/A4、ProPlus、大学版。大部分 Office 365 订阅比如家庭高级版都包括了 5 台移动设备的激活数量，大学版为 2 台移动设备，其中 Windows Phone 手机不纳入统计。

如果你拥有 Android 手机和 Office 365 订阅，则可以在 Google Play 应用商店下载该应用。（via Office）


Office for Mac 2011 SP3 更新发布，支持 Office 365 订阅激活	Office Mobile for iPhone 发布，需 Office 365 订阅	微软正式发布 Office 2010 SP2	Producer Beta for Microsoft Office PowerPoint 2007 发布	开源 Bing Maps SDK for Android 已在 Codeplex 发布
无觅

Google Search for Android 升级，Google Now 增加目的地天气、本地事件和歌曲识别

Thu, 06 Dec 2012 06:16:33 CST

Google Search for Android今天继续升级（依然需要Android 4.1以上系统），还是改进Google Now，让它变得更智能，帮助你更多：

在你出发前告诉你目的地的天气如何
在你到机场的时候自动弹出登机牌并告诉你具体的航站楼、登机口、座位号（这个超有用，不过目前登机牌只支持美联航，其它航空公司将陆续支持，除登机牌外其它信息各个航空公司都支持）
达到目的地之后告诉你周围有啥好玩的事情
在你搜索一些事物之后，推荐合适的网站
在博物馆的时候帮助你学习更多细节（需要使用Google Goggles）
只要在播放歌曲的同时说对着Google Now说“What's this song”，它就会告诉你了
说“Scan this barcode”即可查找商品信息
直接用语音发送Google+信息流

Google Now和Siri是助手的两种形式。Siri需要你主动问她，你不提出自己的需求，她就不理你（当然也许你提出需求了她又理解错或爱莫能助）。而Google Now则主动提供帮助，随时随地利用Gmail和你在Google所有服务上的互动来猜测你的需求，然后给出他认为合理的信息（当然Google Now其实也具备Siri那种语音命令提出的要求）。

所以这么一看Google Now确实比Siri高出那么一筹了。

Via TNW

© musiXboy 发表于谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2012. | 没有评论 | 永久链接 | 关于谷奥 | 投稿/爆料
Post tags: Android, Google Mobile App, Google Now, Google Search, Jelly Bean, Siri

微软展示基于 WP8 核心的 Windows Embedded 8 Handheld 等嵌入式系统方案

Tue, 15 Jan 2013 15:28:28 CST

在本周举办的 NRF 展会上，微软和嵌入式领域的 OEM 合作伙伴展示了诸多新的技术，主要是 Windows Embedded 8 相关的产品。

Windows Embedded 8 Handheld

Windows Embedded 8 Handheld 基于 Windows Phone 8 核心，原生支持微软企业生产力应用比如 Lync、Office 365、Dynamics for Retail 和设备管理方案。开发者现在可以利用 Windows Phone 8 SDK 来为 Windows Embedded 8 Handheld 开发应用，包括了更多嵌入式产品相关的 API 的全新 SDK 将在今年年底发布。

目前 Handheld 合作伙伴包括 Motorola Solutions、Intermec、Honeywell、Ingenico 和 Bluebird，他们将为企业提供定制的手持设备。

Windows Embedded 8 Industry

今天，微软也发布了 Windows Embedded 8 Industry 的技术预览版。

Windows Embedded 8 产品线

去年 11 月，Windows Embedded 团队分享了最新的产品线路线图：

Windows Embedded 8 Standard – 基于 Windows 8 核心代码库，3 月发布。

Windows Embedded 8 Pro – 即之前的 Windows Embedded 8 Enterprise，也基于 Windows 8 核心，3 月发布。

Windows Embedded 8 Industry – 即之前的 Windows Embedded POSReady，今天已经发布社区技术预览版。

Windows Embedded Compact 2013 – 即之前的 Windows Embedded 8 Compact，第二季度发布。

Windows Embedded 8 Automotive – 微软未透露太多，但也将“基于 Windows 8 技术”。

（via Microsoft）


Next App Star：推荐 Windows Phone 应用上电视	三星联合微软展示弯曲屏幕 Youm，以及 Windows Phone 8 原型设备	AdDuplex 数据：Windows Phone 8 初期份额	更多跳转问题？Google 阻止 Windows Phone 访问 YouTube	可视频 QQ for Windows Phone 8 内测版曝光
无觅

芒果圈：芒果粉必备神器

Mon, 14 Jan 2013 17:24:19 CST

芒果圈是湖南卫视推出的一款移动APP，通过此应用可轻松参与芒果台的实时互动、节目竞猜和投票，还可以参加幸运摇号、转盘、芒果机等各类游戏。

Watsonxu语：在去年大量社交电视应用出现的时候，就提到卫士媒体应该迟早也会推出自己的社交电视应用，从逻辑的角度非常合理，当然在我印象中湖南卫视其实在移动互联网这一块也做了不少的探索，从最早的聊天交友到后来的在线问答社区，也在一步一步摸索最适合的自己的移动应用之路。那芒果圈这样的应用个人觉得是比较合适的方向，一是沉淀用户，将电视用户，沉淀到应用，进而通过自有的节目和艺人、主持人增强与用户之间的互动，慢慢强化用户与用户之间的互动。那未来有可能更好的通过互联网的方式来挖掘用户的价值。

当然这个我觉得还是要看卫视媒体对于这种方式价值的重视程度，上周五天天向上节目推荐的五款应用基本上占据了最近移动应用下载的前五位，所以卫视媒体有着很强大的对于用户决策的影响力，如果对于应用重视（也能找到合适的有互联网基因的团队），那按照现有的收视率情况，其实很容易构建一个相当规模的移动社区。当然这一切取决于传统卫视媒体的态度。

链接： http://q.hunantv.com/

@唐兴通:移动互联网的游戏规则

Thu, 27 Dec 2012 12:31:02 CST

之前曾经给奔驰中国、招商银行、广东移动、广东联通、广东省电信、伊利集团等企业培训、交流过移动互联网营销、新媒体传播方面的内容。近日笔者相继出版《决战第三屏：移动互联网时代商业与营销新规则》、《移动营销的魔力》等书，有一些心得体会。现将思考的部分内容和大家切磋。

1. 消费者带着企业、市场人员跑

市场营销人员如何使用移动互联网将成为移动互联网发展的重要推动力。技术将会继续被完善，终端处理速度也将越来越快，更快的网络和更多创新在移动互联网行业及应用中出现。

更重要的是，消费者的行为将继续演变，企业和品牌与消费者交互的方式也从根本上发生改变。企业将不得不重新考虑如何和这些消费者进行沟通和对话。营销信息在移动互联网时代需要的 是简短、相关和有效的。在交互中给移动互联网用户提供恒定的价值。

企业必须将移动营销从由内向外式转向由外向内式，许可式的营销方式。这意味着将不再是企业在内部确定好营销，广告信息然后发送给消费者，而是由消费者主动申请营销信息或服务的方式驱动。

移动互联网已经重新定义消费者获得信息的方式和与品牌交互的方式改变。消费者购物的时候对基于位置的有用信息的需求会增加。 移动互联网将彻底改变一对一的营销理念，让企业可以直接面向正在购物的移动终端的消费者。

腾讯的微信已开始对商家的地推合作，微信营销的方式将有别于微博营销的“弱链接”式的信息传播，其将一方面发力“强链接”的信息传播，另一方面适当拓展“公众账号”增加覆盖、信息传播力。微信营销的核心是：1.客户的关系管理、维护、拓展；2.信息传播的有效性。目前快速消费品品牌企业做的尝试略微多一些，围观的企业有一堆。

2 . 传统企业才是移动互联网的主要玩家

移动互联网为传统的实体零售商提供巨大商机，因为客户在他们店里购物，使用关于产品的实时信息。这将会给企业机会实施“即时营销”。这允许企业可以在准确的时间和地点对客户进行市场推广， 其中准确的时间和地点作为两个对客户和企业最有价值的因素可被利用，背后的潜台词是在消费者购买决策时候做市场营销，临门一脚。当顾客从一个位置到另一个位置时,总是带这独特的移动的信息源。

卡夫的移动APP，是收费的0.99美金，有别于众多品牌的APP免费，还没有人下载的原因是：卡夫为客户提供更多价值。在国内笔者唐兴通见到许多品牌企业盲目上马移动客户端，面临的问题：1.客户端产品拙劣；2.为下载量投入巨资；3. 用户使用频率低；4.客户端的更新、运营糟糕。本质问题是在做之前没有想明白，没有进行移动互联网营销的规划。

消费者和市场营销人员都需面对移动信息超载的问题。因为用户的手机是精准定位的，如果他们选择接受推送信息，将面临来自多种来源的信息的冲击。

3 . 新产品的营销推广有诀窍

移动互联网的发展关键是拥有更多的智能手机用户。这些消费者可能是技术障碍，预算约束，或在交流，购物，习惯方面抵触变化。然而,随着更多的人看到智能手机的价值，会向其他用户进行口碑传播，这样产品的爆发将获得推动。

正如我在演讲中使用的这张产品营销推广曲线图，其清晰的标出典型的产品推广节奏。我们在营销推广中常常犯的错误是： 在新产品推广的初期，对晚期采用者和落后采用者采取过多的宣传。他们是需要有人来引导才会采用新产品。有效的产品营销是抓住早期采用者的13.5%， 他们的典型特征是喜欢新产品，但可以容忍产品的不完美。这正是我们新产品推广中心目中梦寐以求的目标客户群。你说呢？

当消费者看见其它用户扫描并获得即时的折扣，并且可马上使用。 这将不再是关乎什么技术、手机，其实是价值。市场营销人员应想办法抓住能够煽风点火的13.5%创新者。

借助移动互联网可以和时间，地点，供求和需求无缝对接，因为它们都是可衡量，确定的。企业如果抓住移动互联网的这些特色，将在这场变革中获得胜利。

企业必须认识到移动互联网的革命带来的不是多了一个销售通道或多了一个投放广告的平台。它将从根本上改变消费行为，改变和提高消费者的预期。未来移动互联网带来的影响将超过电视，桌面电脑。

讲讲你对移动互联网看法吧~

投稿&作者： @唐兴通联系邮件: along5418@gmail.com 素材来自互联网

您可能也喜欢：
移动广告为啥让营销人员如此头疼？	日本移动互联网的奥秘	移动应用广告平台：探路蓝海	三星结盟网络广告商OpenX 涉足移动广告领域	手机用户怒吼：App们，别再乱推送了！
无觅

看过这篇文章的人还看过：

Google 测试在移动搜索结果里加入快速预览按钮，带你到适合移动设备观看的网页

Thu, 27 Dec 2012 09:26:23 CST

有人发现在用手机进行Google搜索的时候，搜索结果右侧出现一个醒目的Quick view按钮，点击即可直接进入到一个叫做快速预览的页面里，似乎看起来就好像是该网站的移动版，但应该是Google重新排版的：

另外就是Quick view其实不是第一次出现在搜索结果里，当你的搜索结果里出现PDF文件的时候，就可看到一个Quick view按钮方便快速预览PDF文件。

Via SEL

© musiXboy 发表于谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2012. | 没有评论 | 永久链接 | 关于谷奥 | 投稿/爆料
Post tags: Google Mobile, Google Search, Quick view, SERP

百度推出语音助手

Tue, 25 Dec 2012 15:53:33 CST

百度今日推出首款名为“ 语音助手”的安卓版智能语音服务软件。其融合“语音指令、语音搜索、语音问答”等功能，用户通过语音即可完成打电话、搜索信息、下载应用、打开网址、趣味问答、手机设置、LBS周边服务等几乎所有手机常用功能。

百度语音助手最基本的功能是让用户从此可以不用手即可实现电话、短信、调闹钟、设置手机等；打电话、发短信这些基本指令操作，用户手机不联网也可操作，为离线使用场景所做的专门设计。而百度语音助手更为强大之处在于提供语音搜索能力，比如查询天气、彩票开奖、交通限行、股票、航班、搜歌、附近美食、甚至红烧肉的做法、白菜的价格等生活中常用的功能。

类似服务：

之前搜狗也推出了类似的语音语音应用搜狗语音助手。链接： http://yy.sogou.com/

Watsonxu语：移动互联网的发展使得用户的生活方式也在慢慢的开始发生改变，搜索尽管还是很重要的一个用户获取信息的方式，但是在移动端上，还是让用户通过书写的输入方式显然不是最佳的选择，用户甚至慢慢通过应用来代替原有的搜索需求，比如打开天气的App查看天气而不是通过搜索；所以对于搜索服务显然希望通过一种更简单的方式和用户发生互动，并且提供给用户需要的内容，那语音显然是一种更好的选择，iPhone的Siri，Google的Google Now，其实本质都是希望更好的解决信息搜索和用户需求对接的方式。搜索将变成重要而又基础的后台的服务，对于用户而言，更好的交互方式，比如语音，比如现实增强等将这种更简单的交互方式会是一个趋势。

链接： http://shouji.baidu.com/voiceassistant/

可以替换iPhone原生应用的APP

Fri, 08 Mar 2013 21:18:01 CST

iPhone上面自带了邮件、日历、浏览器、备忘录、提醒事项、地图等常用的App，不过现在确实出现了很多体验很棒的可以完全取代iPhone上的这些原生应用的App。

1.邮件-MailBox

这个应用之前刚上线的时候由于采用了排队预约系统，我从应用下载之后整整等了进20天才正真使用到，不过使用之后发现确实觉得这样一种方式处理邮件是很棒的方式，将邮件当做任务来处理，可以极大的提高邮件处理的效率，并且软件的应用体验很棒！

链接： http://www.mailboxapp.com/

备选推荐：Sparrow。

2.日历-Sunrise

Sunrise是一款由前Foursqure设计师创建的一个具有社交功能的日历应用，个人下载体验下来觉得这款日历应用体验非常棒。

Sunrise使用时需要使用Facebook账号登录，登陆之后可以整合Facebook、Google Calendar、LinkedIn上面的日历事项，个人最喜欢的是其登录后首页类似信息流的方式展示日历事项，而在这个信息流中强化了社交关系和人的信息，并且整合了天气信息。（ Via）

链接： http://www.sunrise.am/

备选推荐：Fantastical

3.浏览器-Chrome

其实和Safari相比Chrome不够简洁，不过个人觉得最棒的功能就是各Chrome终端浏览器标签同步。

链接： https://itunes.apple.com/app/chrome/id535886823?mt=8

备选推荐：暂无

4.备忘录-Evernote

支持多平台同步使其最大的优势，不过平心而论，对于一款笔记应用而言，Evernote正在变得越来越臃肿，尽管功能越来越多，也越来越象一个平台，但是我还是只记录文字内容而已！

链接： http://www.evernote.com/

备选推荐：Catch、有道笔记等（更多）

5.提醒事项-OmniFocus

如果只是想简单的记录一些todo事项，原生的提醒事项也是不错的选择，不过从个人觉得Omnifoucs是最理解GTD的一款应用，个人最喜欢其的就是将Todo和日历（从iPhone中读取日历）整合在一起的视图，每天日程和todo一目了然。当然Omnifoucs需要配合Mac版效率会更高。唯一不足价格略高。

链接： http://www.omnigroup.com/products/omnifocus-iphone/

备选推荐：Things

6、地图-Google Maps

Google Maps，也许是之前习惯了用Google的地图吧，实际上国内百度、搜狗地图现在做的也都还不错。

链接： https://itunes.apple.com/cn/app/google-maps/id585027354?l=en&mt=8

备选推荐：百度地图，搜狗地图，高德地图

mobilebone.js-mobile移动web APP单页切换骨架

Fri, 31 Oct 2014 13:34:00 CST

by zhangxinxu from http://www.zhangxinxu.com
本文地址： http://www.zhangxinxu.com/wordpress/?p=4381

一、mobilebone.js吹牛不打草稿

mobilebone.js是鄙人2014下半年个人开源项目代表作。

先容我吹嘘一番，反正吹牛又不要交税。

轻便体积小
原生无依赖
插件可扩展
设计无限制
动效可定制
动静两相宜
能进亦能退
桌面也兼修

一句话功能简介
跟传统网页浏览的差别仅仅在于无刷新！

例如，我们浏览首页，首页上有个如下HTML链接：

<a href="mocamoca.html">摩擦摩擦</a>

在传统页面，页面会刷新跳转至 mocamoca.html, 但是，引入 mobilebone.js后，就是无属性滑动到 mocamoca.html页面。

OK，我特意用手机拍手机拍了段视频给大家感受下（视频中的页面为项目中的测试页面）（舍不得买iPhone, 测试机为Android）（优酷上传太慢40K/s果断投奔爱奇艺了2M/s）：

当然，你也可以打开自己的手机浏览器、或者微信扫描下面二维码，体验同时顺便帮忙众测下，可以评论或者去Github项目issues( https://github.com/zhangxinxu/mobilebone/issues)反馈给类问题（前后两个图分别是develop和master两个分支的测试页）：

如果你是在手机浏览器访问本页面，试试直接点击这里感受一番。

二、mobilebone.js项目、资源以及八卦

Mobilebone项目已经发布到Github上了，项目地址为： https://github.com/zhangxinxu/mobilebone

如果你觉得此项目很赞，欢迎star, 如果你想参与建设，欢迎fork!

为什么叫Mobilebone？
1. 顾名思意，移动骨头。 mobilebone.js也确实人如其名，只做一件事情，移动端单页切换，所以 mobilebone.js很轻便，也很灵活，也没什么限制，反而铸就了其强大。
2. 以前的一些个人项目，会加上zxx之类的标示，甚觉得格局太低了。所以，命名为Mobilebone这么大气的名词，就是希望可以冲出中国，走向世界。万一火了呢，就可以跟Backbone平起平坐啦！
3. 我特意百度谷歌之，恩，没人用这个名词。Github上也没有类似名字的项目，于是就是它的，独一无二的！

为何想到做Mobilebone？
早在11年移动刚兴起的时候，我就折腾过 jQuery Mobile以及Phonegap. 好吧，也就是折腾过，后来很快就把jQuery Mobile给丢弃了，主要有两点：一是重，而是UI限制太大，只适合个人项目！但是，其switch切换是挺值得借鉴的。

上个月，应该是上上个月，游击了一个手Q的项目，做重构稿的时候，写了个单页切换方法，主要是为了重构稿交互演示。结果被开发直接拿去用了，于是问题来了，此切换方法并没有添加Ajax处理，也没有history路由处理。以至于最后的实现代码不醇厚-用人话表示就是“乱”。此时，我意识到，应该可以写个专门负责单页切换的JS组件。加上自己多年的相关积累，Android2.3这些版本不需要兼容，我觉得时机很成熟了。

于是，前后一个多月，利用业余时间，编写、测试与反复优化、细节调整，终于发布了这个个人项目。我会积极在厂内外推广，农村和城市齐包围，万一真火了呢！

Mobilebone适用场景
类原生APP的过场体验，适用于这些场景：
1. Phonegap等类似跨移动开发平台，其静态页面都是index.html, 单页面，因此，需要跟原生一样的过场体验。自己帮设计师实现iOS原型时候需要。
2. Hybird app开发，原生APP内嵌web APP, 为了两者体验一致，不至于交互太唐突，也需要无刷新过场效果。例如，上面提到的那个手Q项目。
3. 就算是纯粹的移动web APP, 使用无刷新模式也不失为一种不错的选型策略。
4. 一些高大上的在线幻灯片演示……等

Mobilebone兼容性
mobilebone.js基于ES5编写，应用了部分HTML特性，原生JS，不依赖任何其他JS框架，不支持Android 2.3及其以下版本，不支持IE6-IE9. 如果这些搓浏览器引入 mobilebone.js, 不会报错，不影响正常使用。

三、mobilebone.js基本使用

首先，引入相关的CSS和JS:

<link rel="stylesheet" href="mobilebone.css">

<script src="mobilebone.js"></script>

此时，就会有一个全局的Mobilebone对象，包含一些属性与方法。

然后，HTML结构有一定的规则。

body
  page
  page
  page

上面规则是什么意思呢？

我们可以看下 mobilebone.css结构相关的CSS代码：

传统网页， body基本上就是页面代名词，滚动条多半也是 body标签产生。但是，一个页面貌似只能一个 body，所以，单页switch切换主体就不能是 body元素，于是，降级，以 body子元素 page作为每个页面的框架结构，担当 body角色。于是，偶们看到的切换效果，就是 page间的相互纠缠效果。

这种HTML结构与CSS布局的另外一个好处就是，可以方便实现兼容的头部底部固定效果（ position:fixed效果问题依然多多）。例如下面这个 base-slide测试页面的HTML结构：

<body>
  <div id="pageHome" class="page out"></div>
  <div id="page1" class="page out"></div>
  <div id="page2" class="page out"></div>
  <div id="page3" class="page out"></div>
</body>

.page对应的元素就是我们的每一个页面，我们可以在此 div中尽情书写我们的设计布局。一般而言，要在 page元素内部再嵌套一个 content元素，主要为了实现滚动。如果使用 iScroll滚动, 无需定高；如果原生滚动， content元素需要有特定高度值。

然后，什么也不用做，页面就能进入无刷新切换模式，超赞的有木有。

如果你想做一些设置，直接在引入 mobilebone.js之后设置就好了。例如下面 Mobilebone.captureLink的设置：

<script src="mobilebone.js"></script>
<script>
Mobilebone.captureLink = false;
</script>

因为，Mobilebone的默认初始化在DOMContentLoaded之后，因此不需要担心顺序问题。不过，如果你是页面 load完毕后再以模块化方式（如seajs~）加载 mobilebone.js，需要手动初始化一下，此时，就要注意顺序，初始化在参数设置的前面，如下：

Mobilebone.captureLink = false;
Mobilebone.init();  // 初始化

记住，一个页面只能初始化一次，以免文档事件重复绑定。

四、mobilebone.js与基本切换

所谓基本切换，指的是无请求，无延迟的即时切换。表现为：每个page在第1次加载完毕后，就已经存在页面，所谓的切换仅仅是这些page元素的位置变化。

就好比我们使用PowerPoint文件，每次打开一个屁屁踢幻灯片文件，一个一个幻灯片页面实际都是已经存在的，我们的浏览，其实都是幻灯片页面的位置变化，这就是基本切换。

在DOM层面，只有一种情况会触发基本切换， href值为锚链的 a元素。例如：

<a href="#pageId">

于是，当我们 tap/click这个 a元素的时候，Mobilebone会自动寻找 id为 pageId的页面，如果此页面存在，则发生切换动画；如果没有该页面元素，没有任何反应，死链。

若有兴趣，可以轻戳这里访问感受基本切换效果。

相反的过场方向
动画的方向不可能都是从右往左的，例如，返回，显然是需要刚进入动画相反，符合正常认知。要实现，很简单，通过添加 data-rel="back"就可以了，例如：

<a href="#pageHome" data-rel="back">返回</a>

此时，元素过新增一个类名 reverse反方向运动。

然而，有时候，我们无法确定动画的方向，例如，固定在底部的导航，如果导航3从导航2过来，自然是正方向；但如果是从导航4过来，则要反方向。 data-rel该如何设置呢？

哈，使用 "auto"即可，如下：

<a href="#pageHome" data-rel="auto">前进还是后退？</a>

Mobilebone会自动判别页面在舞台上的位置，智能识别运动方向。浏览器的历史记录前进与后退也是采用的 "auto"判别机制。

此应用可参考头尾固定测试页面 – test/fixed-header-footer/index.html.

data-rel控制访问同样适用于下面的Ajax切换。

五、mobilebone.js与Ajax切换

实际项目，可能有10+个页面，显然是不可能全部一次性载入的，又大又慢，对于流量如金的移动页面，是损耗也是浪费。所以，页面内容还是要一个一个加载实在，这就需要Ajax切换了。

Ajax加载并切换的实现很简单，你不需要做任何操作，就跟传统的web页面一样就好，使用 href指向要加载的页面地址，例如：

<a href="ajax.html">

此时，当我们 tap/click这个 a元素的时候，Mobilebone会以Ajax的形式请求 ajax.html这个页面，返回的数据会封装成 page页面，并以指定的过场动画载入。是不是简单得有点过分了？没错，所以下面要加点料。

1. Ajax请求参数
既然是Ajax请求，自然少不了请求参数了。Mobilebone中的Ajax借用了jQuery中 $.ajax()方法的参数命名，主要如下：

var defaults = {
    url: "",
    dataType: "",
    data: {},
    timeout: 10000,
    async: true,
    username: "",
    password: "",
    success: function() {},
    error: function() {},
    complete: function() {}	
}

<a>元素传参策略
对于元素，我们是直接通过属性设置传参。有两种支持的形式，分别为 data-*和 data-params.

data-*是指需要传递参数，把参数名替换这里的星号（不区分大小写），并赋予参数值。例如：
```
<a href="ajax.html" data-timeout="30000">
```
就是设置请求超时时间为30秒。

不过仍有两个注意点：
1. 如果 href值正常，则 data-url地址会被忽略，依然使用 href对应地址作为Ajax请求地址。
2. 没有 data-data, 而是 data-formdata. 例如：
```
<a href="ajax.html" data-formdata="c=1&d=1">
```
data-params值则是查询序列串。因为如果需要自定义的参数过多，标签上就会有很多 data-*属性，略啰嗦。于是，可以以查询序列串的形式作为 data-params的值，例如：
```
<a href="ajax.html" data-params="datatype=json&timeout=20000&success=fun_success">
```
有人可能会疑问，如果存在 data-*和 data-params冲突情况怎么办？哈， data-*优先级大于 data-params. 所以，类似下面代码，则最后请求超时时间为 30s, data-params中的 20s会被忽略。
```
<a href="ajax.html" data-timeout="30000" data-params="datatype=json&timeout=20000&success=fun_success">
```
还有一点，不支持 data参数的序列化使用，请使用上面的 data-formdata. 有兴趣可以轻戳这里看下如何使用的。

Ajax回调函数
Ajax回调函数有三个，跟jQuery的Ajax请求一样，分别是 success, error, 与 complete. 分别表示请求成功，请求失败与请求完成（包含部分失败情况）。注意，下面开始高能了：

<a href="ajax.html" data-success="globalObject.fun.xxx_ajax_success">

上面的传参就是上面提到的 data-*策略，类似，错误回调，可以使用 data-error或者 data-params="error=xxx". 下面问题来了， globalObject.fun.xxx_ajax_success表示什么意思？

如果使用了上面代码，只要不是估计瞎搞，在JS的世界里肯定有下面这位兄弟：

window.globalObject = {
    fun: {
        xxx_ajax_success: function() {}
    }
};

意思就是，当请求成功的时候，执行全局对象 globalObject下的子对象 fun下面的 xxx_ajax_success这个方法。最后一个字符串段一定是方法名，否则是不会有任何执行的。例如：

<a href="ajax.html" data-success="xxx_ajax_success">

则表示请求成功的时候，调用全局方法 xxx_ajax_success.

成功回调函数支持两个参数， success(response, status), 其中 response表示Ajax请求返回的内容，HTML或者JSON. status这个参数其实没啥用，返回成功的状态码。其中，默认的 this上下文是Ajax执行的完整参数们，是个对象。结构类似本小节展示的 defaults对象。
错误回调也支持两个参数， error(xhr, status), 其中 xhr是发送的请求对象， status跟上面一样意思，就不多说了。其中，默认的 this上下文是Ajax执行的完整参数们，是个对象。与其他两个回调有一个很大的不同，多了个 message属性，告知了错误原因，如，网络掉线、超时或是是JSON解析异常等。
完成回调也支持两个参数， complete(xhr, status), 其中 xhr是发送的请求对象， status跟上面一样意思，就不多说了。其中，默认的 this上下文是Ajax执行的完整参数们。

字符串类型返回值
默认返回的是字符串，会按照HTML字符串处理。

例如，我们请求 ajax.html页面，该页面最好是完整的 body > page结构。因为，就算页面JS挂掉，无法阻止默认链接行为，发生跳转，也不会影响可用性。但是，如果请求的是个动态页面，直接返回的是干净的HTML代码，如果没有 page元素，则不能含有 html以及 body标签。

因为Mobilebone会寻找返回HTML中的 page元素作为页面载入；如果没有，则会将返回的所有HTML封装在自己创建的 page中。简言之，要么返回“完整HTML页面代码”，要么返回“干净的HTML片段代码”。

2. JSON类型的请求
由于某些团队的中间层还没成熟，前后端半分离状态，导致请求得到的数据只能是JSON数据。虽然个人建议是后台那边使用某些框架基直接吐HTML返回，但现实是骨感的。不过不要太多担心，Mobilebone是有考虑过这种情况的，其暴露了一个方法名为 Mobilebone.jsonHandle(json), 专门用来处理JSON数据源，需要返回渲染的HTML视图代码或者直接就是 page元素。

支持一个参数 json, 此参数必须，为Ajax请求返回的JSON数据。于是，你就可以在此处理方法中套用模板，吐出页面完整HTML. Mobilebone会自动根据吐出的内容生成页面，并以过场动画形式载入。

需要注意的是， Mobilebone.jsonHandle是个全局的唯一的方法，所以，如果页面有多个JSON渲染，请使用返回的JSON数据的 id或其他标志量做区分，精准返回HTML数据（也可以自己返回页面-不多见）(可参考测试页面中 Backbone的例子)。

下面是JSON测试页面的例子代码：

Mobilebone.jsonHandle = function(json) {
    var page = document.createElement("div");
    page.className = "page out";
    page.setAttribute("data-title", json.title);
    page.innerHTML = json.html;
    return page;
};

简单示意，不要太认真。若有兴趣，可以轻戳这里访问体验下。

更好的JSON包括HTML加载建议
虽然Mobilebone提供了直接请求JSON数据的方法，并提供了视图渲染接口。但是，以我个人经验，对于实际开发，这种实现策略是不推荐的。我认为更好的实现方法应该是这样的。页面骨架，也就是page主体，也就是一个空 div默认就载入，然后所有的切换都是基本切换，而不是Ajax切换。在切换即将开始的时候（回调），您就可以使用自己，例如Zepto的Ajax方法去请求你需要的JSON数据，做你任何想做的事情，完全没有Mobilebone的限制。

页面slide是有时间的，350ms, 这个时间点很可就就完成呈现了最终的页面。于是，我们看到的就是，一点击，页面slide，slide结束，内容呈现。哇哦哦~~操作感不要太流畅哦！而且技术上更可控，因为数据请求、处理与Mobilebone完全解耦。

当然，如果就是个原型页面、简单的静态页面，或者是不喜JS的小伙伴，依赖Mobilebone的Ajax整体请求与呈现策略显然是最好的选择，因为，你什么都不需要做~

3. 请求页面的缓存机制
默认情况下，Ajax请求的页面，如果之前已经请求并载入，下次请求时候，就会启用基本切换，也就是直接使用之前的page过场，而不是再次发起Ajax请求。这就是Mobilebone请求页面的缓存机制。但是，实际开发时候，有些页面数据是需要实时更新，不能被缓存的。此时怎么破？很简单，使用 data-reload="true"即可( ="true"可缺省)！例如下面代码演示：

<a href="ajax.html" data-reload>

于是，请求的页面就不会被缓存了，而是不断的新旧替换。

对了，Mobilebone中的所有Ajax请求都加了时间戳，也就是只要有请求发生，基本上都不会使用浏览器缓存。

4. Ajax加载的loading效果
Ajax是个需要等待响应的过程，尤其网络较差的情况，比如高峰时段的地铁。Mobilebone自带loading效果。

默认情况的loading效果为， 35%白色半透明全屏遮罩，中间是个斑斓的菊花旋动效果，如下截图：

此效果对于90%的移动开发，以及部分的PC页面是适用的。但是，应用场景千千万，有时候，我们 loading可以希望出现在局部，例如，我们点击的按钮、或导航上。此时该怎么办？对此，Mobilebone也留了一手。很简单，使用 data-mask="true"( ="true"可缺省)就可以了。如下所示：

<a href="ajax.html" data-mask>

于是，当我们点击这个链接时候， loading相关的HTML就会显示在这个 a元素中，通过简单的CSS控制，就能实现我们需要的自定义loading效果了，例如，只覆盖按钮，或者菊花在文字后面显示。如下面两截图效果：

若有兴趣，可以轻戳这里访问体验下。

对了，插一句：Mobilebone已经对Ajax连续点击可能会重复请求的问题作了处理，大家无需担心额外的请求损耗。

5. 避免Ajax加载，使用传统刷新
Mobilebone默认会对同域的地址做Ajax请求无刷新加载。但是，万一人家就是希望要请求呢？以及，虽然跨域，但是人家依然希望使用Ajax请求了（如跨子域而已）。

轮到 data-ajax属性出场了。如下代码：

<a href="ajax.html" data-ajax="false">  // 此情况下也可使用data-rel="external"

于是，点击上面 <a>元素时候，就会是浏览器的刷新跳转。

如果人家要页面上所有的链接，或者大部分都是跳转，总不能一个一个设置 data-ajax="false"吧，哈，Mobilebone提供了一个全局参数， Mobilebone.captureLink，只要设置成 false布尔值，页面所有链接诶都是传统可刷新跳转链接。

Mobilebone.captureLink = false;

例如，测试引导首页就是这么设置的。

事情还没有结束。Mobilebone自带域名判断技能，如果跨域，默认会认为是刷新链接。但是，XMLHttpRequest 2.0支持Ajax跨域。例如 a.qq.com下的页面请求 b.qq.com, 此时需要按照Ajax请求来走，怎么办？还是 data-ajax, 这回值设置成 "true"就可以了。

<a href="//b.qq.com/ajax.html" data-ajax="true">

六、mobilebone.js与过场回调方法

所谓“过场回调”，就是从牛A页面切换到牛C页面时候，触发的一些回调函数。

Mobilebone提供了多个回调接口，以应对各种交互需求。有如下四个：

onpagefirstinto(pageInto, pageOut, response)
当过场页面第一次进入的时候执行，一般用在事件绑定，或实现元素动态显示。支持三个参数： pageInto 进入的page元素。这个参数一定会存在的。 pageOut 离开的page元素。这个参数可能为 null, 如页面刷新时候。 response 返回的数据。这个参数多半应用在Ajax请求时候。
callback(pageInto, pageOut, response)
每次过场页面进入的时候都会执行。参数与 onpagefirstinto含义一致，不赘述。
animationstart(page, into_or_out)
过场动画开始的时候执行。离开的页面和进入的页面都会触发。两个参数： page 当前动画的page元素。 into_or_out 字符串。只可能下面两个值之一： "into", "out"。
animationend(page, into_or_out)
过场动画结束的时候执行。离开的页面和进入的页面都会触发。参数与 animationstart含义一致，不赘述。

下面问题来了，如何绑定这些回调方法？

OK，跟Ajax参数绑定类似，使用自定义属性。同样是两种模式： data-*和 data-params.

例如下面这个 data-*模式：

<div id="pageHome" class="page out" data-onpagefirstinto="home" data-animationstart="start">

或者下面这个 data-params模式：

<div id="page1" class="page out" data-params="animationstart=start&animationend=end">

模式不是重点，重点是函数名关键字。例如 data-onpagefirstinto="home"表示什么意思呢？

有些类似Ajax的回调，但有差别。在默认没有任何设置的情况下，Mobilebone会认为 home是个全局函数的名字。于是，会使用类似 window.home()的形式执行该回调方法。但是，显然，JS中应该是要尽量避免不必要的全局变量的，对于实际项目而言，都是全局方法是不实际的。于是，Mobilebone暴露了一个可以修改回调主对象的接口， Mobilebone.rootTransition. 例如，你的页面有如下对象：

FUN = {
    home: function(pageInto, pageOut, response) {},
    start: function(page, into_or_out) {},
    end: function(page, into_or_out) {}
};

则，你就可以设置：

Mobilebone.rootTransition = FUN;

“哎呀，我不想修改全局，只想局部开花”，OK，没问题，使用 root关键字修改根对象。例如：

<div id="page1" class="page out" data-root="window">

哈， page1的回调函数又变成 window对象下面的啦~ 同样，支持 data-params查询字符串模式。另外， data-root也支持对象级联，可以帮你获取层级较深的方法。

关于过场回调，如有兴趣，可轻戳这里浏览观摩体验。

直接全局设置
有些回调，每个页面发生过场的时候都会执行，我总不会每个页面都加一个 data-callback吧，又累又啰嗦。此时，你可以使用全局回调设置。直接：

Mobilebone.callback = function() {};

每次有页面进入都会执行，此实例可参考头尾固定的那个例子。

如果发生冲突，也就是 data-callback也存在，则直接覆盖全局的 Mobilebone.callback方法。

七、mobilebone.js与使用其他过场动画

mobilebone.css默认只提供了一种过场效果，就是左右 slide效果。

如果你希望有更多的过渡效果。试试外链一个 animate.css, 此CSS位置位于Github项目的 test/transition/animate.css, 包含 fade, slideup, slidedown, turn, flow等多个过场动画效果，然后，添加特定属性，就可以实现我们的效果了，很easy!

<link rel="stylesheet" href="http://rawgit.com/zhangxinxu/mobilebone/master/src/mobilebone.css">

于是，我们在page元素上，使用 data-form="xxx"或 data-params="form=xxx"指定特定的过场动效。例如， fade淡入淡出效果：

<div id="page1" class="page out" data-form="fade">

八、mobilebone.js与模块化加载

mobilebone.js可以符合AMD, CMD规范的加载器加载。例如 seajs, 或 requirejs.

用法其实很简单的：

var Mobilebone = require('mobilebone');

然后，用法基本上就跟平常时候一样，除了需要手动初始化一下：

// Mobilebone API设置...然后...
Mobilebone.init();

若有兴趣，可参考 test/modular-load中各个文件的源代码示意( index.html使用的是 seajs, require.html使用的是 require.js)。这里要看代码，效果没啥看头。

九、mobilebone.js与地址栏前进、后退与刷新

Mobilebone强大的另外一个体现就是利用HTML5 history API和地址栏融为了一体。

地址栏的前进、后退或者刷新都跟传统网页一样，可以准确显示对应内容。因此，无论是Web APP或者Hybird APP，手机上的返回键都能很好地操控我们的内容呈现，就跟Native APP感受一样（文章开始的视频应该有所体现）。

原理
早些年时候，我直接使用 hash做路由指向，后来发现经常会干扰定位。原因可参考我之前的文章：“ URL锚点HTML定位技术机制、应用与问题”。

这里有必要再次感谢下jQuery Mobile. Mobilebone的history处理与jQuery Mobile一样，路由地址前面加了一个 &符号，从而解决了锚点定位的问题。

当然，从使用者的角度讲，这些你都不需要关心。

十、mobilebone.js与插件扩展

mobilebone.js核心就是切换，其也只做了这一件事情。正是因为这种简单与专一，方能体现其强大。如果你想有更丰富强大的功能，你可以很自如地进行扩展。

前面的 animate.css过场动效就是不错的扩展。当然，不知CSS，JS层面的扩展更具有潜力。

举个例子，你希望swipe时候，页面也有过渡效果，OK，你参考API文档扩展下就可以了，或者添加键盘控制，实现类似在线幻灯片浏览的效果，也是可以的。

在 plugins/ppt文件夹下面，就有我写的一个在线幻灯片演示插件，做的事情其实很简单，单击非链接区域，上下左右键盘，以及鼠标滚动，会让幻灯片前后播放。

您可以在PC或者pad上访问该演示页面。

当然，如果你有其他idea, 也能做出其他很精彩的作品。

十一、mobilebone.js其他tips说明

1. tap/click事件依赖
该Tips还是蛮重要的！所谓事件依赖，就是，如果浏览器大环境支持 tap事件（比如使用了含touch events的Zepto.js），则使用 tap事件来触发一系列的过场行为，否则就使用 click事件。然而，大家可能都知道的，在移动设备上， click具有较长时间的延迟，用户在操作的时候总会有点怪怪的不顺畅的感觉。怎么办？在这里，我必须郑重推荐下 fastclick.js. 很多小伙伴都在用它，Github上面的star要奔万的节奏去了， https://github.com/ftlabs/fastclick.

直接引入 fastclick.js，然后如下代码绑定：

FastClick.attach(document.body);

然后我们就能愉快地在移动设备上玩耍啦！此js对Mobilebone很友好，有种千年好基友的感觉。在 test/complex演示的模拟微信交互页面上就使用了 fastclick.js.

2. 一些原型扩展方法

给元素扩展了一个 getParentElementByTag方法，根据标签寻找匹配的父元素，没有返回 null.
给字符串扩展了个 queryToObject方法，可以把查询字符串转换成对象。

3. 已知问题

一些老三星手机上，会出现第一次animation页面比例突然变小再恢复的诡异问题。希望有经验的朋友赐教！

4. 其他杂七杂八tips

在Github上查看 mobilebone.js时候，最好在后面加上 ?ts=4会以最佳排版效果显示。
```
https://github.com/zhangxinxu/mobilebone/blob/master/src/mobilebone.js?ts=4
```
Github上 mobilebone.js以及 mobilebone.css都是非压缩版本（因为我比较懒），实际上线，需要大家自行压缩。我测试了下，现在写这段文字的此时此刻最新的JS版本压缩后只有 8.69K, Gzip后真的只有3~4K，跟着图标大小差不多。

十二、mobilebone.js API文档

见下面表格，颜色淡的就是表示不常用的，正常颜色的是可以关注的：

API名称	类型	默认值	示例	吐槽
Mobilebone.support	布尔值	-	-	是否兼容Mobilebone, 只读，亲，只读
Mobilebone.VERSION	字符串	-	-	当前mobilebone.js的版本号，只读，注意了，只读
Mobilebone.autoInit	布尔值	true	Mobilebone.autoInit = true	是否DOM加载完毕后自动初始化，默认为true. 如果页面加载完毕之后的require加载，此值失效，按false处理。
Mobilebone.captureLink	布尔值	true	Mobilebone.captureLink = true	是否捕获页面上的a标签，执行无刷新过场效果。此为全局设置，影响整个页面。默认为true
Mobilebone.rootTransition	对象	window	Mobilebone.rootTransition = window	过场回调方法的根对象。默认是全局window.
Mobilebone.classPage	字符串	"page"	Mobilebone.classPage = "page"	page元素的标志类名
Mobilebone.classMask	字符串	"mask"	Mobilebone.classMask = "mask"	mask元素的标志类名
Mobilebone.pushStateEnabled	布尔值	true	Mobilebone.pushStateEnabled = true;	是否启用历史记录。此参数我是没有想到需要使用的理由，但总感觉可能用到，于是就放着。

API名称	类型	返回类型	参数	示例	吐槽
Mobilebone.transition(pageInto, pageOut, back, options) 或者 Mobilebone.transition(pageInto, pageOut, options)	函数	-	pageInto DOM元素。表示进入的page元素. 必须参数。 pageOut DOM元素。表示要移出的page元素. 可选。没有移出元素使用 `null`. back 布尔值。是否反方向过场。可缺省。 options 对象。此参数多内部使用。一般有用的是两个参数接口： `id`和 `response`.	Mobilebone.transition(element); Mobilebone.transition(element1, element2); Mobilebone.transition(element1, element2, true); Mobilebone.transition(element1, element2, { id: “only” }); Mobilebone.transition(element1, element2, true, { id: “only” });	此API在插件扩展的时候应该是最常用的。此方法为Mobilebone切换的核心。含缓存机制、事件回调触发等。
Mobilebone.getCleanUrl(trigger, url, params)	函数	字符串	trigger DOM元素。一般表示 `<a>`元素。可选参数，和 `url`至少一个存在。 url 字符串。Ajax请求地址。如果 `trigger`有合法 `href`值，此参数酱油。可选参数，和 `trigger`至少有一个有效。 params 对象或者字符串。主要用来获得请求查询数据.可选。	Mobilebone.getCleanUrl(elementOfA); Mobilebone.getCleanUrl(elementOfA, ”, “a=1&b=2″); Mobilebone.getCleanUrl(null, “xxx.html”); Mobilebone.getCleanUrl(null, “xxx.html?a=1&b=2″); Mobilebone.getCleanUrl(null, “xxx.html”, “a=1&b=2″);	获得干净完整的Ajax请求地址。基本上，此函数API内部用得多，大家大可不必关心。
Mobilebone.getPage(children)	函数	DOM元素或null	children DOM元素。必须参数。	Mobilebone.getCleanUrl(childElement)	根据子元素获取当前所在的page元素。
Mobilebone.createPage(dom_or_html, element_or_options, options)	函数	-	dom_or_html DOM元素或字符串。必须参数。 element_or_options DOM元素或者对象。可选参数，作用是获知需要移除的页面。可以是 `<a>`元素， `page`元素，也可以是第3个 `options`参数。 options 键值序列对象。可选参数。此参数多内部触发，基本上来自Ajax请求的参数。主要作用是获得 `response`返回数据。	Mobilebone.createPage(pageDom); Mobilebone.createPage(generalDom); Mobilebone.createPage(‘<div class=”page out”>xxx</div>’); Mobilebone.createPage(‘<p>xxx</p>’); Mobilebone.createPage(pageDom, triggerLink); Mobilebone.createPage(pageDom, { reponse: ‘<div…>’ }); Mobilebone.createPage(pageDom, triggerLink, { reponse: ‘<div…>’ });	重要API. 直接根据DOM或者HTML字符串创建页面，并载入。别看API名字较长，好像很复杂，其实很简单滴。
Mobilebone.getFunction(keys)	函数	对象或函数	keys 字符串。必须参数。当字符串级联的时候，例如’a.b.c’, 用来返回纯正的 `window.a.b.c`这个对象，才能执行与调用。	Mobilebone.getFunction(“a.b.c”)	此API内用，大家很少会用到，不要太关心。
Mobilebone.ajax(trigger_or_options)	函数	-	trigger_or_options `<a>`元素或者Ajax请求参数对象。必须参数。	Mobilebone.ajax(document.querySelector(“a”)); Mobilebone.ajax({ url: ‘xxx.html’, success: function() {} });	很重要，应该会比较多用到的API，大家需要留意。
Mobilebone.isBack(page_in, page_out)	函数	布尔值	page_in 元素。必须参数。进入的元素。 page_out 元素。可选参数。离开的元素。	-	此API没什么机会使用的，内用居多，不必太在意。
Mobilebone.jsonHandle(json)	函数	DOM元素或 HTML字符串	json JSON数据。必须参数。	-	此方法JSON请求必用。全局方法，因此，如果存在多个JSON需要处理的情况，请使用JSON数据中特定的标志量进行区分，例如，返回个 `id`. 如： { "id": "homePage" , "data": [] } 和这个： { "id": "listPage" , "data": [] }
Mobilebone.init();	函数	-	-	-	初始化方法。默认DOM载入完毕会执行，无需关心。如果 `Mobilebone.autoInit`为 `false`, 或此方法在页面 `load`完毕后动态载入，则需要手动初始化。
Mobilebone.handleTapEvent(event)	函数	-	-	-	起初我只是为了排版好看才将此方法暴露出来的。后来发现，某些场景还是可以用到的。比方说你做了某些操作，直接把 `click`给永久消灭了，然后使用自己的自定义tap方法，此时就可以类似这样处理： document.body.addEventListener('myCustomTapEvent', Mobilebone.handleTapEvent, false); 来绑定过场效果。

十三、mobilebone.js结语与展望

一分耕耘一分收获，终于赶在月底前把这篇文章发布了，扳一扳手指头，快40天去了，鲜有项目做这么长时间。来鹅厂目前最大的收获之一就是做产品的态度，一定要花足够的精力去精雕细琢，kill每一个痛点，完善每一个体验。虽然过程很辛苦，但是做出来的东西大家会都喜欢。看上去好像谁到知道，做产品要用心，但事非经过不知难，一定要亲历与感悟，才能真正成为自己所得之物。

虽然上面调侃多次“说不定回火”，但自己实际并没有真在意。我并不确定有多少人会使用mobilebone.js, 但是，唯一我确定的是，心有多大，舞台就有多大，如果没有制作精品的态度，没有完成世界top级作品的胸怀，没有用心的反复雕琢与实践，一定是不会火的，最多就是发布时候众人捧个场、鼓个掌，然后，就没有然后了，就像千千万万昙花一现的小企业一般。

所以，细心的你可能发现， mobilebone.js中的注释都是英文的，且API用法，参数，示例都放上面了；提示信息也是蹩脚英文，ReadMe.md也有英文介绍。当下，虽举目三尺皆白壁，但心在壁外三万里。用人话表示就是，虽然我身处一个小屋子，但我希望我做的东西能够漂洋过海得到肯定。因此，花了很多额外的功夫做了些国际化的工作，万一哪个老外慕名前来，也不会因为看不懂中文文档而放弃。

谋事在人成事在天，做好自己能够最好的一切，期待理想之花静静绽放。恩，至少，我自己用起来是很顺手的！

希望大家多多支持，共同建设，提出问题或提供建议！

回头，如果大家关注度不错，我会申请个相关域名，把此项目独立出去……一切才刚刚开始……

本文为原创文章，会经常更新知识点以及修正一些错误，因此转载请保留原出处，方便溯源，避免陈旧错误知识的误导，同时有更好的阅读体验。
本文地址： http://www.zhangxinxu.com/wordpress/?p=4381

（本篇完）

有话要说？点击这里发表评论。

雷锋学堂：谈谈Mobile Web App的设计

Mon, 12 Nov 2012 18:29:57 CST

【编者按】本文作者：邓腾（ @千年牛皮糖），百度无线交互设计师。在本文中，作者将给大家谈谈Mobile Web App的设计方法，内容包括：Web App定义、Web App的特点、发展现状及设计等等。希望对大家有所帮助。

Native App与Web App的争论从未停息过，尽管很多人在批判Web App的各种不是，但也阻止不了各种各样的Web App如雨后春笋般出现，尤其是伴随智能手机的普及而受到重视的Mobile Web App。这是一种在非议声里成长起来的产品形态，无论其结果如何，都应该吸引开发者和设计师的关注。

一. Web App定义

维基百科对Web App的定义是：

Web App是指使用浏览器支持语言编写的App，运行于浏览器中，通过网络访问。所以移动Web App就特指特指运行在智能手机浏览器中的Web App。我认为在用户眼里，它是App；在开发者眼里，它是Web。

二. Web App的特点

Google Chrome开发小组推出的《Web App开发指南》提出了如下对Web App的判断标准：

是否独立，完成当前任务不需要链接到另一个完全不同的使用环境？

使用它是否可通过交互、参与并完成特定任务？

是否具有良好的用户界面，看起来非常美观，并且占据全屏？

是否使用和本地应用一样的界面模型，比如按钮、对话框或者其他元素？

是否可以离线工作？

是否应用了设备的某些功能，比如使用到来自GPS的定位和动作传感器的数据？

是否隐藏了传统的网站导航栏和导向链接？

应用是否是参照客户端架构模型设计？

这也不是本文讨论的重点，仅供读者参考。

另外就是谈Web App和HTML5的文章必提的Web App相对于Native App所存在的优势和不足。

【优势】

跨平台和终端

更新实时，无需用户手动升级

开发成本和技术门槛很低，前段开发工程师可快速上手

无需安装、占空间少

易于维护

搜索引擎索引优化

调试，发布方便

【劣势】

受限于浏览器，性能和界面效果存在差距

严重依赖网络连接

调用硬件和本地文件不便

无法在app store里上架销售，但未来搜索引擎可以扮演Web App的分发入口也说不定

下面是关于开发各平台应用的语言、开发工具、应用格式和应用商店的对比图：

三. 发展现状

截止到目前，app store和google play中的app数量均已接近70万，marketplace的app数量接近13万。而且随着iOS、Android、Windows Phone各平台层出不穷的新设备的发布和普及，app数量始终保持着增长态势。

Web app由于其定义比较模糊，所以暂时还没有一个比较准确的统计数据。但国内主流的手机浏览器都将Web App放在很重要的位置（从左到右依次是遨游、百度、360、QQ、UC浏览器的应用中心）：

根据最新的调查显示开发者对开发HTML5 Web App的兴趣也在与日俱增：

jQuery, Sencha, JQ.Mobi, Zepto等移动UI组件和框架的发展也使得Mobile Web App的开发越来越简单、高效和性能更好。

封装了webView的Hybrid App则兼具Web App和Native App特点，在开发成本和用户体验上取到了一个很好的平衡点。好的Hybrid App完全能媲美Native App的用户体验。这种开发模式正在得到越来越多的开发商和开发者的青睐。Facebook，百度都使用过这种方式开发过自己的产品。

四. 设计

1. 屏幕适配

移动设备的屏幕是各式各样的，对设计影响较大的主要是屏幕分辨率、尺寸、屏幕方向这些因素。

现在的iOS设备有320×480，640×960，1136×640，1024×768，2048×1536这些分辨率，3.5寸、4寸、7.9寸、9.7寸这些尺寸。

Android设备的碎片化则更严重。所以需要关注Web app在不同屏幕下的界面适配问题。

1.1 适配不同分辨率

通过响应式网页的设计方法提升页面在不同分辨率下的兼容性：

由于手机屏幕尺寸下，一般来说只能一个模块一个模块地从上到下排列。此时设计者就需要考虑模块摆放的优先级了。一般来说，用户重点关注的、最近更新、与用户相关的信息应该放在前面。

另外最好以主流分辨率480×800进行设计，对略高于和略低于该分辨率的屏幕可将界面元素进行缩放，对间距、边距进行适当调整。

所以，在设定容器、图片、文本框的宽度时最好避免使用px单位，使用%可使页面在不同分辨率屏幕下保持布局和页面结构不发生改变。

1.2 平板电脑

使用CSS3的媒体查询（media query）语句可获得浏览器的高宽和设备的像素比，并可根据开发者的需要对不同的设备应用不同的样式表。所以开发者可以控制一个页面在不同设备上的表现。

由于手机屏幕和平板电脑的屏幕尺寸和像素都相去甚远，所以为了充分利用平板电脑的大屏优势，以获得良好的用户体验，最好在两种设备上使用不同的界面布局。相信iOS用户都有这样的感觉：有的App只适配iPhone，在iPad上运行则无法布满屏幕，只能点“2X”按钮显示一个粗糙的界面。还有一种App可同时兼容iPhone和iPad，在手机和平板的屏幕上都能完美显示，用户也无需单独下载两个版本。很明显，后者使用起来更方便，更美观。

Mobile Web App使用媒体查询功能即可实现这种功能。那么在平板电脑上，有哪些需要注意的设计点呢？

因为平板电脑多在横屏下使用，所以使用分栏视图可在一个界面内显示两个层级的内容，方便用户快速切换item。

首页多以宫格视图、Tab为主，微博、QQ这种以内容为主的界面将分栏视图作为默认首页也是可以的。在手机上最常使用的list在平板上就不是很常用了，整个屏幕显示list，不仅浪费空间，也没有分栏视图的操作高效。

需要注意的是，IE9以下的浏览器不支持media query.

1.3 横竖屏切换

由于目前还不能在webkit内核里禁止设备方向的旋转，所以如果用户的设备开启了屏幕方向根据重力自动旋转，那么运行于浏览器的Web App也是会跟着旋转的。

如果能够捕捉到设备的方向，可以对横竖屏分别进行布局设计，但最好能保证界面风格和样式不会有大的变化。

反例就是iPhone的音乐App，在竖屏下会显示歌曲list，但是切换到横屏下显示专辑封面。两种界面风格跳动太大会导致部分用户不适应，以为是两个不同的页面。计算器App也只有在横屏下才显示科学计算模式，竖屏下用户根本无法切换到该模式，连引导也没有。

宫格视图是横竖屏切换最平滑的布局，看看iOS系统的主屏幕就知道了。一个个应用程序图标在横竖屏切换时，几乎只是图标旋转了一下方向。

还有一点就是切换到横屏时，可自动进入全屏模式以显示更多的内容。否则标题栏和底部栏将会占去很多空间

2.动效

受浏览器性能影响，很多Native App能实现的华丽动画在Web App里的表现并不是很好。所以应该果断去掉非必要的动效以保证Web App能够运行流畅。

因为很多动效会对用户起到很好的引导作用，如果没有这些动画，可能会导致用户对界面逻辑关系的理解产生混乱。这就对动效的设计提出了较高的要求。

总结了一下Web App的几点动效设计原则：

尽量不使用不必要的动效。

优先使用简单的动画。如平移、缩放。尽量避免使用3D动画。

避免刷新页面。因为整个页面白屏，浏览器走进度条的体验会给用户浏览网页的感觉，而不是在使用app

框架元素优先显示。只在内容加载区域显示loading动画

避免跳变。在不影响性能的情况下，可尽量用缩放和平移动画，保证用户视觉焦点的延续性和理解的延续性。

同类界面/对象，同层级界面/对象的动效保持一致。可帮助用户理解产品架构和导航逻辑。

高层级界面的动效对应高级物理位置。如果左右平移的动画是用来切换上下一层级，那么首页应该是在最左边，如iOS。如果前后切换的动画是用来切换上下一层及，那么首页应该是在最上面，如Windows Phone。

3.信息架构

讲导航和信息架构的文章众多，Mobile Web App既然要实现Native App的操作体验，照传统的移动客户端的设计模式去设计即可。只需要记住你设计的Web App需要运行在iOS, Android, Windows Phone等多个平台，多种设备上即可。

由于iOS相比其他平台，没有back按键，所以在iOS上运行需要保证界面内的导航能够实现闭环。所以Android上有些操作可以通过Menu键唤出，但是在iOS上就需要直接暴露出来。

下图左侧是Zaker的Android版，右侧是iPhone版。Android版的菜单栏需要点击Menu键才出现。

4.使用Native App的UI控件

使用Native App的UI控件，可以让Mobile Web App更有Native App的操作体验。常见的如Badge，Back button，Bubble，Picker，Indicator，Title bar，Dialog，Toast，Loading，Drap down to refresh，Notification等。

下图分别是Facebook的Native App和Web App，由于后者使用了客户端常见的一些UI控件，所以用户很难从视觉上识别出后者是Web App.

避免使用传统的Web UI控件，如面包屑、文字链：

另外，在控件尺寸上也应该像Native App那样提供尽量大点击区域的控件。参照经验和各平台的官方人机界面指南，可以知道适合用户手指点击的尺寸应该在7-9mm之间，不能小于7mm。相邻点击控件的行距不应小于2mm。

5. 针对浏览器优化

为了兼顾浏览器的性能和交互，需要注意以下几点：

页面使用尽量少的DOM元素；

简化动效；

避免与浏览器的交互冲突，如左右滑动，如浏览器的tab bar, action bar, 以及浏览器全屏后的虚拟按钮；

考虑保存用户的哪些数据：设置、个人数据、阅读锚点、跳出页面等。

规则图形用Canvas绘制，避免向服务器请求img.

注意离线数据存储，通过manifest定义需要被缓存的文件，以便用户离线时使用。

减少数据请求频率。

6. 其他

Track：建立Track机制可以快速获取用户的操作习惯和页面的浏览情况。从而方便设计师和产品人员快速改善产品。这一点比在Google Analytics获取到的数据更方便，更准确。

SEO：使用SEO提升Mobile Web App的曝光率。因为很多手机用户会通过搜索引擎进入你的website，而不是地址栏。

域名指向：m.site.com，mobile.site.com，site.mobi，www.site.com/mobile，3g.site.com，wap.site.com，shouji.site.com，www.site.com/mobile等带有明显手机网站含义的域名都应该指向你的Mobile Web App（或Wap站）所在站点。如果条件所限只能绑定一个的话，请使用m.site.com。ps.这一点来自Nielsen的《Usability of Mobile Websites》.

本文转载自作者博客：千年牛皮糖

莫须有 @雷锋网

手机智能了，app还没有：这就是移动广告赚不到钱的原因！

Wed, 12 Dec 2012 20:00:34 CST

在今天旧金山举行的2012年Mobile-Loco大会上，几位业内人士就如何更好地在移动应用上为本地商户发布广告展开了讨论。其中关于“智能手机App是否真的智能了”的观点引起了我的注意。

对手机用户的价值定位真的明确了吗？

其实，绝大多数移动应用公司都在挣扎如何赚钱，尤其是那些守着一大群用户却不敢轻易采取行动的公司；而对于商家，他们都已经明白消费者越来越多在移动设备那端，都愿意把广告预算从传统渠道转移到移动渠道上来，但是他们挣扎的是该不该把钱投在移动应用上，或者该以怎样的方式投在怎样的移动应用上。每个人都说，我们有用户有数据，只要在对的时间、对的地点为用户提供对的商家信息就行了。可是回归到用户的价值本身做具体分析，可能并没有多少人能说清楚那是怎样的一个价值定位，也不敢向广告主做出保证。

Drew Breunig是基于位置的智能服务公司 PlaceIQ的高级产品主管， 他认为广告主和品牌之所以在移动渠道（甚至在 Web渠道）上行动缓慢，正是因为移动端用户的价值还没有被清晰定位。甚至可以说价值还很低。但移动应用公司 Banjo的创始人Damien Patton并不认同，他说：“很多人早上匆忙出门，走到半路发现钱包忘拿了，他们可能并不会返回去拿，但是如果是智能手机忘拿了一定会专门折返。正是技术让这种状况成为可能。”所以他认为智能手机和移动应用对于用户的价值很明显，同样用户本身的价值定位也非常清晰。广告主和品牌只是不确定怎样把广告预算转移到新的战场。

而就在以上讨论进行的时候，另一个质疑问题最源头的声音跳了出来。

智能手机 App真的智能了吗？

Sam Liang是 Alohar Mobile公司的联合创始人，也是CEO和CTO。6年前，正是他领导了一个团队为Google实现了手机地图上的“定位”功能。 Sam认为，现在移动应用说怎么赚钱还太早，智能手机是够智能了，但是手机应用还没有实现真正意义上的智能。智能手机可以追踪到用户的位置数据，但是孤立的数据本身并不能告诉你它背后的真相。用户的位置显示周六下午他在某个理发屋，并不表示他一定是去那里理发；位置显示用户周日中午在某家餐馆，也并不表示用户在那里进餐乃至喜欢那样的食物。况且很多用户已经厌倦了“签到”这样的事情。也就是说，移动应用公司不能用这样的数据说服商家投放广告，也不能用这样的数据来自以为是得投用户所好。而真正智能的应用是，在用户快饿了的时候自动建议用户今天去哪儿吃，怎么走；在用户车快没油的时候，自动提醒用户该加油了并且告知附近的加油站位置。只有实现了这样的智能化，移动应用才能谈赚钱。

会后，Sam向我展示了他的公司正在做的一个移动应用平台 PlaceMe。Sam说PlaceMe会像随身日记一样自动记录用户每一天的行踪（详细到每一个地方的名称、地址、去过的次数、停留的时长等），甚至在用户并没有打开手机的时候。基于这种方式获取的数据再通过进一步的分析和应用，PlaceMe可以为移动应用实现他所提出的真正智能化。

Sam说已经有很多移动应用开发者在试用Alohar的技术，并试着把移动应用放到PlaceMe平台上。我很期待，也会持续关注他口中的真正智能了的移动应用。

GSMA 带来好消息，45 家主流运营商支持 SIM 卡内嵌 NFC

Fri, 18 Nov 2011 21:05:00 CST

分类: 科技新闻, 智能手机

你应该已经知道 NFC 芯片可以内嵌到 SIM 卡中去吧？现在这个技术马上就会推广开来了。全球移动通信系统协会（GSMA）这次给我们带来了好消息，嵌入近场通讯（NFC）功能的SIM卡已经得到45家全球主流电信运营商的支持。里面就有我们熟悉的中国移动和中国联通，这两家运营商目前在中国有 8 亿的用户数（很奇怪中国电信没提及）。其它让人熟悉的运营商包括 America Movil，AT&T，德国电信 Deutsche Telecom，荷兰 KPN，Orange，Rogers，SFR，韩国 SK Telecom，日本软银 Softbank，Telus，Verizon 以及英国 Vodafone。为了加速这项技术的推广应用，GSMA 已推出新的行业规范说明，以此保证基于 SIM 卡 NFC 服务全球部署的安全性和互动性。

当然对于我们消费者来说，行业规范及业内新闻有进展是好事，最主要的是将来我们可以感受到这个技术带来的便利性。你最想用 NFC 来干什么？想一想到时候大家的手机都可以碰碰，或许名片就少印了许多。

引用来源 | 此文章网址 | 转寄此文章 | 回应

Web 前端优化最佳实践之 Mobile(iPhone) 篇

Wed, 14 Dec 2011 13:24:48 CST

Web 前端优化最佳实践最后一部分是针对移动应用的，其实只是针对 iPhone 的，目前只有两条规则。

1. 单个数据对象小于 25K (Keep Components under 25K)

这个似乎只是针对 iPhone 研究的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M，但经过测试，发现也就是 25K 左右。

iPhone 在市场上的优异表现，让 Web 人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。

2. Pack Components into a Multipart Document

把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详，等待后续更新吧。

Updated: 根据这篇 iPhone caching 的文章，可供 Cache 的最大单个数据对象是 15K，而不是前面说的 25K。iPhone 总的 Cache Size 为 1.5M。浏览器地址栏的刷新按钮将导致无条件刷新所有组件。这些也是挺有趣的。

作者: Fenng | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/web/best_practices_for_speeding_up_your_web_site_server_mobile.html

您可能也喜欢：
未來生活進行時：創新科技應用與博物館的複興蔓延——Mobile & Social Media篇 (@mydesy)	T-Mobile:演繹現實版憤怒鳥 (@mydesy)	Web 前端优化最佳实践之 CSS 篇	Web前端优化最佳实践之内容篇	Web 前端优化最佳实践之 JavaScript 篇
无觅

Mobile App 将死？！

Wed, 14 Dec 2011 12:00:37 CST

日前，Mozilla 产品副总监 Jay Sullivan 称移动应用不久即将成为历史，未来将是移动 Web 应用的天下。光盘好歹还能当杯垫，可怜 Mobile App，难道就这样一下跌落进历史的垃圾堆？

Mozilla 的产品副总监杰 • 沙利文（Jay Sullivan，上图）日前表示，移动终端应用（Mobile App）没有未来，真正有前途的是移动 Web 应用（Mobile Web App）。原因有三：

每个移动终端设备都有自己独立的技术堆栈、操作系统和编程语言。因此，开发 App 需要适应多个系统，进行多次独立开发。
开发 1 个移动 Web App 比一次开发 2 个、 3 个甚至 4 个原生应用（Native App，下载到本地）要经济得多。沙利文表示，HTML5 的优势在于性价比高，尽管目前还不完善，但相比写 7 种不同的语言版还是要好得多。
移动 Web App 在技术上更加便于管理，而且，照如今移动网络的发展态势，移动 Web App 达到与移动 App 同等的用户体验只是时间问题。

沙利文指出，移动 Web App 欠缺的只是合适的商业模式。当网络上形成一个良好的商业生态系统后，移动 Web App 对开发商将更具吸引力。

Yahoo 开放平台项目副总监布鲁诺 • 费尔南德斯 – 鲁伊斯（Bruno Fernandez-Ruiz）表示，Yahoo 正在开发一系列全新的跨平台移动 Web App，适用于手机、电视、平板电脑等不同的移动终端，而且用户体验与 Native App 效果一致。

Mobile Web Apps：技术和产业文化的双重挑战

构建 App 全集成平台的 Appcelerator 公司，其共同创始人之一的杰夫 • 海尼（Jeff Haynie，上图）表示，移动网络业务将持续快速增长，但现在断定移动 App 将死还为时过早。从 Native App 转向移动 Web App 的过程中，开发商需要应对双重挑战。

首先，移动 Web App 必须满足用户对高质量、高性能的需求。海尼表示，短期内移动 Web App 还不足以实现 Native App（如 Flipboards 和 Instagrams）带给用户的优质体验。其次，人力方面，即使是在 Mozilla 和 Yahoo 这样的企业，负责开发移动 Web App 的也大多是 Web 开发人员。如何让 Web 开发人员开发出适用于本地和 Web 的通用 App，将是这次转型更大的挑战。

搭建移动网络的关键：JavaScript 和 nodeJS

JavaScript 和 nodeJS 是实现从 Native App 向移动 Web App 成功转型的两项关键技术。

目前，要使内容在所有移动终端以及设备平台上运行一致还非常难以实现。许多公司都试图通过转化操作系统的代码来解决这个问题。而 Yahoo 则期望通过是简化多语言环境来降低开发的复杂程度。

Yahoo 的新套件 Cocktails 以 JavaScript 和 nodeJS 作为核心组件，它能帮助开发人员使移动 Web App 在外观和感觉上都跟高品质的 Native App 没有分别。

Cocktails 系列产品之一的 Mojito 就是用 JavaScript 和 nodeJS 编写，成功实现了服务器端和客户端单一代码库运行，前端和后端用的是完全相同的代码。 Cocktails 系列的另一款产品 Manhattan，可以把移动 Web App 包装成 Native App（即所谓的混合 App ）提交到 iTunes App Store 或 Android Market，或者直接在浏览器中运行。Manhattan 有助于改善访问不同带宽的网络时用户的体验，还能让 App 在没有足够 HTML5/CSS3 支持的平台上得以运行。

Yahoo 的费尔南德斯 – 鲁伊斯（上图）表示，nodeJS 有出色的性能表现，但 Yahoo 看重的主要是 nodeJS 能够在服务器上运行 JavaScript 这一特点。JavaScript 正在进化，未来的 JavaScript 将会成为高效而可靠的语言，为 Web App 提供跨平台的、一致而流畅的使用体验。

费尔南德斯 – 鲁伊斯还表示，对用户来说，同一个 App 在电视、平板电脑、智能手机或 PC 这些不同的终端上切换的体验很恼人，而 HTML5，CSS3 和 JavaScript 则可以消除不同平台上外观和操作体验的不同。

从 LinkedIn 最新发布的 App 可以看到，移动 Web App 使用起来几乎已经与 Native App 无二。

Zurb 公司刚刚发布的 Foundation 框架也和 Manhattan 类似，致力于为 Web App 的设计和开发提供跨平台的支持。 Zurb 公司的员工梅德 • 德拉基列夫（Dmitry Dragilev）表示，基于 Web 技术，开发者不必再为每个终端设备单独考虑，框架把这些工作都做了。 Foundation 框架试图让 Web App 在各种环境下都能运行，无论是移动终端还是桌面终端。在移动终端正在赶超桌面终端的当下，这显得尤为重要。

搭建适合的销售渠道

如何搭建渠道向市场推销移动 Web App 是这次转型的第二个挑战。对此，Mozilla 的一个方案是“通用型 App 销售”：通过电子邮件地址，用户即可获得应用，在任何终端设备上都可以使用。你在 PC 上买了一款游戏，你在手机上也可以玩。因为你的 App 属于你，而不是你的设备。即使你换了不同的设备，你也应该能够同样地使用这款 App。这种模式下，用户将会从“云端”的虚拟商店中购买各种好用的 App，或者直接从开发商处购买。

沙利文表示， Mozilla 在浏览器运营以及插件营销方面积累的实战经验将有助于搭建一个良好的销售系统，以应对近年来 App 边缘市场的 “FUD”（恐惧、不确定和怀疑）氛围，其中部分阴影是 Google 和 Apple 直接造成的。

Native App 的“终结”

沙利文还表示，移动 Web App 在用户隐私和使用权限方面更加透明，而且网络“沙箱模式”（网页应用只能使用自己的数据，不能随意读取用户设备上的文件——译注）能够针对恶意 App 提供更好的防护措施。

Mozilla Firefox 的开发总监乔纳森 · 南丁格尔（Johnathan Nightingale）表示，鉴于特定的硬件功能以及 Native App 在硬件访问上的优势，有开发商仍然会愿意开发 Native App，但 Mozilla 不会。这也是在为 Mozilla 未来推出移动 Web 开发工具做铺垫。

说到硬件访问，也有人对维持目前模式的幕后主力——操作系统生产商及原始设备制造商，能否在向移动 Web 技术转型的过程中做到公平竞争表示怀疑。对此，海尼表示，虽然目前确实有计划让 Web 开发商也能够访问那些特定的硬件性能，但他认为 Apple 绝对会加以阻挠。

沙利文则做出了一个保守的估计。他说，在电脑软件还是装在盒子里用光盘销售的时候，人们都以为电脑任务中大约 80％会由桌面软件处理（在本地运行），剩下的 20％在网上运行。

沙利文表示：随着性能的提高，当初 80/20 的划分不但完全转了过来［即 80％的任务在网上运行，剩下的 20％在本地处理］，而且几乎所有的任务都转移到了网上。我不认为本地 App 会消失，因为它们还会在本地运行，但我认为未来的移动 Web 也会出现一个 80/20 的局面。

Zurb 公司的设计负责人，乔纳森 • 斯迈列（Jonathan Smiley）也表示了类似的看法。斯迈列认为， Web App 和本地 App之间的差别最终会消失；尽管两者不会完全一样，但随着用户通过硬件使用 Web App ，同时本地 App 也使用更多的 Web 服务，最终两者会合二为一，统称为 App 。

“好的用户界面（User Interface，UI）是我们至始至终的追求，”LinkedIn 的移动开发总监基兰 • 普拉萨德（Kiran Prasad，上图）表示，“好的 UI 就是简单的 UI 。简单就是速度快、操作简单、性能可靠。”

普拉萨德表示，适用于手机的 Web App“的确是未来的”，但这个未来距今仍很遥远。因此，技术人员需要“在正确的时间使用正确的技术……这并不是一个本地 App 和 Web App 之争，而是一个在界面和互动层面上的较量：本机界面［鼠标和键盘］还是 Web 界面［触屏］。我们关注的是最佳的用户体验，那么，在当前就意味着既要利用移动 Web App 的优势，也要用好移动 Web App 和本地 App 相互接入的特点。”

本文由果壳的歙砚编译自 VentureBeat 。

Tech2IPO新服务： HT实验室 | 创业者服务 | 投资人服务

2012全球移动广告行业五大趋势

Thu, 22 Dec 2011 18:18:28 CST

Google刚刚发布了最新的移动广告报告。智能手机和平板电脑平台引人关注。报告开头就提到，随着智能手机和平板电脑的融入人们的日常生活，商家们的问题已经从“该不该投放移动广告或要不要做一个移动网站”，转变为“如何开始移动化”。

以下为Google发布的2011年移动行业五大趋势：

趋势一：人人移动

智能手机和平板电脑不仅仅是极客的玩物。旧时王谢堂前燕，飞入寻常百姓家。报告称有79%智能手机用户会在购物时用到手机，比如比价，查询产品信息或者寻找零售店。70%用户在商店里使用智能手机。77%会通过手机联系商家，61%会打电话，59%会访问商家。

趋势二：移动搜索永远改变了购物

分析移动搜索趋势可以让行业更好地了解人们的购物习惯。智能手机和平板电脑让人们可以随时随地地上网，移动设备已经成为桌面电脑的补充。越来越多顾客在赶往店铺的路上或者在店铺里通过手机进行产品搜索。不管人们是寻找或电话联系商家，在商店内比价，或者直接通过手机访问网站和移动应用，搜索和搜索广告将带来一种新的购物体验，都可以和商家保持联系，在线或离线进行产品调查和购买，一切都在手机上完成。

趋势三：移动广告渠道的进步

广告主用来开发、提供和测量移动广告的系统、产品和技术还处在早期阶段，但是MRAID（移动富媒体广告节目定义）等标准的进步，以及HTML5背后的动力正在让移动社区重整旗鼓，让营销者和顾客可以更方便地连接到平台上。无论是搜索还是图片广告，行业所熟知的工具正在移动化。

趋势四：平板电脑加入移动阵营

平板电脑是今年的黑马，越来越多的人们通过平板电脑购物、消费媒体，寻找乐趣，而且大部分是在晚上进行的。平板电脑是营销者需要关注的第三类计算设备，2011年11月平板电脑的流量比去年12月增长了440%。不仅用户更有可能在平板上逛街购物，而且平板电脑也拓展了广告平台，让广告效果更好。

趋势五：商家开始真正考虑移动先行的策略

智能手机和平板电脑并不是迷你版桌面电脑，而是一种截然不同的全新设备。今天商家开始大量拥抱这些设备，很多商家通过专门为移动设备开发的广告和网站尝到了甜头。

令人难以置信，但就2011年的行业现状来看，我们仍处在移动发展的早期阶段。人们通过移动设备和商家保持联系的方式，以及商家使用的工具今年都取得了很大进展，并且我们很快将看到人们和实体店的互动关系也会被改变。

移动行业将在2012年全速前进，智能手机和平板电脑将火力全开、阔步向前，你准备好了吗？

本文来源： 36氪

您可能也喜欢：
2012年十大科技趋势语音识别时代来临	《纽约时报》：互联网正向实体物联网演变	谷歌要求广告主为移动设备优化网站	太突然了！谷歌125亿美元与摩托罗拉移动合体	Rovio自称不是游戏开发商，而是全球第一移动广告服务商
无觅

看过这篇文章的人还看过：

移动支付的应用与进化

Wed, 09 Nov 2011 15:29:15 CST

移动支付是近几年来越来越流行的技术，其过程就是用手机或者 PDA 设备作为一个终端进行交易和支付。由于潜在需求巨大，各大公司纷纷出台自己的技术方案，甚至一些创业公司也加入了这场博弈。

几种传统支付手段

使用流通货币进行现金支付当然是广为使用的支付手段之一。现金的流通范围广，除非特殊情况，否则几乎所有场所都接受现金交易。但如果要使用现金频繁进行小额支付，通常要进行找赎，而如果需要偶尔进行大额支付，现金又存在携带、保管与金额确认上的不便。

日常生活中使用的交通卡是一种非接触式 IC 卡，这种卡片使用起来方便，通常用于无需确认的小额支付，还具有功能拓展性，能够用于身份验证，采用读取器与卡片相互认证的方式可以保证一定的安全性。目前第二代身份证和公交卡都采用了这种技术，但这种卡片由于设计上的缘故，数据全部存储在本地，如果没有将卡片放在读卡器可以读取的范围内，就无法进行管理。由于同样的原因，卡片难以通过第三方监管，在挂失和非法盗用的处理上有一定困难。此外这种卡片还存在互不通用的问题，即便采用同一种技术，但如果用途不同，则无法相互通用，比如门禁卡、公交卡、身份证和会员卡。繁多的种类和名目实际上降低了便利性。

我们常常使用的信用卡和借记卡属于磁卡，也是一种流行的支付手段，卡片内的数据仅用于进行有限的身份识别，实际交易数据存储在远端，因此也可以脱离卡片进行交易或管理。通过输入密码或签名的辅助认证，可以用于较大额度的支付。磁卡技术的好处是显而易见的，因为数据不保存在本地，在监管上更为方便。但同时也意味着任何一笔交易都必须接入远程系统，因此在没有互联网接入的环境下无法使用。这种卡片也同样存在无法通用的问题，虽然各个银行机构颁发的磁卡现在大都相互兼容，但无法在一张卡片上保存多个机构的账户信息。

理想的移动支付手段

将上面说到的几种支付手段的优点综合一下，我们渴望有这样一种支付手段：

适用范围必须足够广泛
在保证便捷的同时安全性必须符合需要，在进行小额支付时足够简单方便，而大额支付则可以使用额外的安全与身份验证
监管途径多，数据最好能够从本地和远程同时存取，与此同时还要保证数据的一致性
灵活性上也要有要求，要能将多种不同业务有机地结合，不同的数据信息最好能存放在同一个介质当中

这些要求听上去足够苛刻，但也相当美好，如果能够得以实现，将会大大提高支付的便捷性。目前，为了处理好这些问题，大多数解决方案不约而同的选择了目前使用方便而广泛的手机来作为载体，这种技术统称为移动支付。

移动支付的成熟应用

先来看看日本和韩国两位领先者的移动支付发展情况：

日本移动通信龙头企业 NTTDoCoMo 是移动支付业务开展得最好的运营商之一，采用的技术是日本索尼公司研发的 FeliCaIC 智能芯片，属于 NFC 技术的一种应用。

其之所以能够大获成功，原因主要有以下几点：

首先，选择在日本已有广泛基础的FeiliCaIC技术作为移动支付技术，保证适用范围足够广泛。

其次，三井住友银行和DoCoMo联合推出的ID借记卡业务使得DoCoMo的移动支付业务突破了小额支付的界限。DCMX信用卡业务使DoCoMo的移动支付业务渗透到消费信贷领域。此外日本公交系统和自动零售机系统也能兼容它的手机钱包功能。真正实现了将不同业务有机地结合在了一起。

出于安全性上的考虑， DoCoMo 还规定，消费额超过预存款和 DCMX 移动信用卡业务每笔消费超过 1 万日元都需要输入 4 位验证密码。用户可以通过已注册电话或者公用电话告知 DoCoMo 锁定移动支付业务；针对 DCMX 信用卡业务推出的定制手机中有指纹和面部识别功能，使安全性更高一层。

由此可见日本的移动支付很好的满足了安全、便捷、多功能、适用范围广的要求，因此能够发展的如此蓬勃不足为奇。

再把目光转向韩国。早在 2001 年韩国运营商 SK 就推出了名为 MONETA 的移动支付业务品牌。起初， MONETA 只是一种有“理财帮手”之称的多功能卡，后来通过与 VISA 等信用卡机构合作，凡持有 MONETA 多功能卡的用户，均可轻松使用信用卡、公交卡等支付功能。智能手机的使用普及了以后， SK 将 MONETA 移植到了手机上。发展至今韩国的移动支付业务也已经非常成功。

申请了 MONETA 业务的移动用户可以获得具有信用卡功能的手机智能卡。移动用户只要将具有信用卡功能的手机智能卡安装到手机上，就可以在商场用手机进行结算，在内置有红外线端口的 ATM 上提取现金、在自动售货机上买饮料，还可以用手机支付地铁等交通费用，在韩国有几万家餐馆和商店拥有能从手机通过红外线读取信用卡信息的终端，使顾客能够通过手机进行消费，适用性足够广泛，也同时支持多种不同的支付手段。

在韩国每个月有超过 30 万人在购买新手机时，会选择具备特殊记忆卡的插槽，用以储存银行交易资料，并进行交易时的信息加密，能够满足移动支付的安全性需求。

未来的移动支付

国际范围内也有很多公司尝试涉足移动支付，各种解决方案层出不穷，有硬件方案，有软件方案，也有软硬结合的方案。下面将讨论 Google Wallet ， Paypal ， Bump ，Square 以及国内的支付宝和中国移动手机钱包。

Google Wallet 是一种软硬结合的移动支付技术，依托 Google Wallet 软件和手机上安装的 NFC 硬件，相较其他技术方案有不少优越之处。

Google 跟大量商户合作，支持 Google Wallet 服务已经涵盖了 30 万个万事达卡的购物点， Google 还宣布得到了Visa payWave 的全球授权，全球发行 Visa 卡的银行将支持帐户持有者将自己的信用卡、借记卡和预付费帐户整合到 Google Wallet 移动支付服务中。这些举措使得 Google Wallet 适用范围得到提高。 NFC 技术在美国本身使用也非常广泛，有利于用户平滑迁移。此外， Google Wallet 开放 API 使得第三方开发者能够在其之上定制自己的支付程序：超市可以向用户提供基于 Google Wallet 的储值卡，公司可以向雇员发放基于 Google Wallet 的门禁身份识别软件，餐厅可以向用户提供基于 Google Wallet 的优惠卷……但遗憾的是由于目前支持 Google Wallet 的设备在市场上仅有一款，因此可以使用此服务的用户非常有限，相信将来这个问题会有所改善。

在安全性与便捷性的考虑上， Google 也找到了一个平衡点。对于储值卡，优惠卡或会员卡，用户只需要从程序中将其选中并在屏幕开启的情况下接触读卡器即可完成支付或验证，而对于用户的银行卡等限额较大的支付操作，则需要输入四位数的安全码。此外，程序和设备本身也可以通过采取各种安全措施阻止非法使用，基于 NFC 技术的硬件安全保护和独立的硬件数据存储芯片更是较其他软件方案有更多的优势。在监管上 Google Wallet 也做到了很好的突破，由于基于 Android 的设备通常具有网络功能，用户可远程锁定设备，清除设备上的所有数据，当然也可以选择直接打银行电话取消信用卡。

为了能让用户使用支付业务时有更多的选择，并尽可能多的替代现有支付方案， Google 现在已经支持花旗银行的信用卡和 Google 预付费卡，开放的 API 还将为用户带来更多的业务， Google 更是在自己的官方主页上宣称“未来你唯一需要携带的塑料片就是你的手机”，可见其野心之巨。

Paypal 不光宣布在未来将支持像 Google 一样的 NFC 支付方式，还已经推出了一种软件的解决方案，用户只需要在手机上点击下就可以向另一个账户付款，也可以向其他账户收款，并更进一步支持分摊付费以及集资等交易方式。但目前 Paypal 的支付方式缺点十分明显，他无法向支付方提供付费人的身份识别信息，因此一切都要手动输入，人工确认。因此你无法使用 Paypal 付公交车费，也没法用它在超市买单，因为没人会愿意在这些地方输入自己的 Paypal 帐号，更没有商家会愿意主动索取。此外它还需要联网，由于安全性要求数据也存放在远端服务器内。国内银联的手机支付软件与之大同小异，此处不再赘述。

Bump 最早的时候是一个交换名片的应用，他的特点：酷！只要两台手机碰一下，信息就这么传递完成了。后来 Bump 开始传递照片，音乐，日历，社会化应用信息，甚至你的 App 列表。不知不觉中 Bump 意识到了自己的天赋：实现近场通信而无需增加设备。于是团队将 API 大方的公开，一个新的生态圈就此成立。

Bump 的服务器会根据设备间撞击的时间，地理位置，IP 地址等数据来识别身份。通过撞击的时间来判断哪两台设备需要连接，很天才的想法。

上图是 ING Direct ，一个由银行开发的 App，除了能查看你的帐户信息以外，因为利用了 Bump 的技术，它能实现设备间的快速转账——近场支付。

Bump 的优势是显而易见的，它不需要增加任何设备，不过他对网络连接和手机传感器准确性的依赖较大，且在安全性上还有待考证。

Square 刚发布了自己新的支付软件，利用 iOS5 的“ Geo-fence ”技术，用户只需要走进支持 Square 支付的零售店，挑选想要的东西，然后在收银台说出自己的名字——然后就没有然后了，你可以放心的离开，不必担心有后面有一位愤怒的店主拿着霰弹枪向你冲来。他的工作原理如下：根据地理位置信息，向附近的零售店提供访问用户帐户信息的权限，在用户说出姓名买单时，店员就能够通过姓名检索用户的账户，并向其收费，用户随后会收到确认请求，点击完成即可付费。显然该方案对网络依赖较重，且便捷性不如 Google Wallet 的 NFC 技术方案高。

此外， Square 还有另一种增加硬件的支付方案，这种方案要为设备增加一个专用的刷卡器， Square 承诺给注册用户免费提供。

这个读卡器把信用卡磁条的信息转换成音频，然后 iPhone，Android 的 Square 应用会把音频再转换成数字信息，然后把这些付款信息用加密的方式传输到服务器端，服务器端然后返回刷卡是否成功的信息。这个设备主要是提供给不愿意增加 POS 机的小型商户，以增加支付途径，本质上并不能让用户的支付行为变得更为便捷。

支付宝推出的手机客户端软件，无需用户增加任何硬件设备就可以使用。和 Paypal 类似的是也支持点到点的交易服务，但此外还增加了非常有中国特色的彩票购买，手机充值，缴纳水费，电费，燃气费，固话宽带费，购买游戏点卡以及 Q 币功能。作为解决即时交易的一种尝试，支付宝还支持条码收银和支付，但目前我还没有机会在任何消费场所使用过此功能，看来普及率有待提高。此外，支付宝也是依赖网络的，所有数据都放在远程服务器上。期待有一天，能够通过扫描支付宝条码直接在零售店购买商品。

中国移动手机钱包服务需要用户更换特殊的 RFID-SIM 卡，相当于增加硬件设备。好处当然是显而易见的，很多现有的手机都可以用上这个服务，且由于软硬结合的优势，交易行为既可以直接在远端进行操作，也可以在不联网的情况下进行，比如我使用的手机深圳通完全不需要任何特殊操作，只需要将正常待机的手机贴近刷卡器即可，而充值更是只需在手机上点几下就能完成，完全无需专用设备，当然也可以通过网银向手机钱包划款。此外，令人高兴的由于是 NFC 系统的特性，手机钱包支持直接在手机上查询消费明细和余额，带来很多管理上的便利。不仅如此，脱离了硬件设备，手机钱包仍然是可用的，有了手机钱包支付账户，用户也一样可以在网上进行购物，真正做到了处处通用。经过仔细研究，我发现中国移动手机钱包在设计上并没有集成银行金融业务，或许是为了避免和银行业直接竞争，但手机钱包的野心仍十分巨大，其一卡通功能介绍中提到“通过将您的员工卡、门禁卡、内部消费卡整合到手机 SIM 卡中，使您在工作单位、住宅小区、学校内真正实现一卡通行”。虽然现在除了手机深圳通外我几乎没有在其他商户用到这个服务，但未来中国移动可能会将手机支付业务的适用范围进一步拓展，让我们拭目以待。

最后的话

移动支付当然是一种支付形式的进化，但也带来了很多其它问题，比如手机没电时，上述的所有移动支付方案都完全无法使用。不仅如此，移动支付的加入会使手机丢失的代价更为巨大。移动支付风行导致产业模式的变化会对用户带来未知的影响，新型支付手段在经过时间的检验之前，都不能说绝对安全。移动支付还需要考虑用户转换成本等一系列问题，其普及程度甚至有可能受到国家政策影响。

不过，移动支付必定会替代很多传统的支付途径，因为其杰出的便利性会让我们的生活变得更加美好。我至今仍记得在威尔·史密斯主演的科幻电影《我，机器人》中，威尔·史密斯使用手机在酒吧买单的画面，没想到这一天这么快就已经到来了。

最后一个问题就是：各位准备好接受这些越来越便捷的支付方式了吗？支付一直都是个非常痛苦而复杂的过程，但移动设备的发展让它越来越轻松，或许不久的将来，用户唯一该郁闷的就只有自己的消费能力和赚钱能力之间的严重矛盾了……

徐浩岑

“我不害怕计算机，我害怕没有计算机。”–艾萨克.艾西莫夫（Isaac Asimov）

所在地邮箱新浪微博

本月活动“体验 Chrome 浏览器，赢取 Nexus S 手机”，详情请点击这里。

path 2.0的华丽转身

Mon, 26 Dec 2011 11:39:39 CST

　　path2.0惊艳了很多人吧。敢于拒绝google一亿美金的收购，果然有留一手：）

　　她的创始人Dave Morin说新版不久就已经超过150万人下载，而老版一年才突破了100万关口。用户一天内在新版分享的内容超过老版一年的内容。

　　path2.0之后带来的用户量和活跃用户的暴增最大的功臣莫过于 界面设计和体验上的不俗表现：
1、产品定位的转变引发UI设计的调整

　　path1.0的时候大家似乎还没有看出她和instagram等等一系列社交软件明显的差异化。path2.0已经将定位清晰表达出来了： 和亲密好友分享生活日记的app(Path is the smart journal that helps you share life with the ones you love)。

　　虽然她在可添加好友数量从50暴增到150,但无论是睡眠、起床之类的个人信息分享，强化的timeline feed样式，还是只有昵称没有头像的简约，都传递出她希望和亲密的人分享自己生活日记这一中心。

　　在界面表达上，设计师也传递着这一核心定位：

对比path1.0的图标，2.0在UI上做了日记本隐喻的处理

loading时候，如日记本打开的翻页效果

2、突破ios瓶颈的架构方式

path1.0 vs. path2.0

　　在整个path的改版中，最为惊艳的还是她突破ios的一些制约，创新的一些架构模式。

　　在path1.0时，底部还是采用非常传统的tab导航方式。架构上也普普通通没有新意。

　　由于手机屏幕尺寸和手指碰触的限制，44*44像素的最小触碰尺寸造成了底部导航tab只能放少于等于5个。这对于功能的扩展造成了限制和瓶颈。

　　path2.0完全颠覆了iOS guild line的模式，采用三屏模式（左屏、主屏、右屏）

　　同时架构上凸显了这种方式具有的极好的扩展性。

　　可以假想，path在设计之初也面临添加各种其他动能（比如音乐、地点、和谁在一起、起床睡觉）时候面临，中间的拍照键不好满足的情况。因此，采用这种三屏模式，极简了主页面，主屏仅留下feed展示，和添加功能。将导航放入左侧的屏幕，增加了未来的可扩展性，同时也保证主屏幕清晰的内容：动态展现和添加我的动态，还有最新的消息提醒。

　　她深知对于消息来说，新增的消息才是重点。一方面在主屏底部显示了最新一条消息的摘要和未读消息的数量，另一方面把全部消息收在左屏的activity里面。

3、timeline的影响

　　好吧，path的创始人来自于Facebook，path2.0出场的一刹那我们就看到了Facebook的timeline的影子。Facebook的timeline也出现的在终端上了，和path几乎一模一样。先不去争辩究竟是谁抄袭的谁。path在feed的展示上格外强调时间线的展示方式。

　　在手指拖动屏幕向下滚动的同时，右侧浮现各个feed分享的时间，时钟动态的显示回转，强化了时间线（timeline）。
4、更加直观的表达

　　交互设计中，所见即所得（WYSIWYG）对于用户来说是一种最容易学习的交互模式。

　　新手任务中，用户需要添加个人cover。添加的个人信息，即时的在当前位置表达、编辑信息。之后的展示上也采用一致的布局，让用户非常清晰了解到所输入的内容结果如何，也算是“操作前结果可预知”的体现。

　　社会化网络的两大精髓：表达自我，了解他人，在个性化cover上表现的淋漓尽致。

　　另一个方面是手势的直接表达。path摒弃了除了点击（tap）以外的其他手势。对于滑动显示等其他手势来说，点击（tap）才是最直观的、优于其他操作的手势。

　　主屏左下角的+绝对是亮点。有没有想过为何放在左下角？又为什么采用弧形展开？仅仅是为了追求炫目的效果么？

　　其实对于手势来说，多数人都使用右手为利手，同时使用右手拇指单手操作。那么方便的可触碰区如下图：

右手利手的拇指可触碰区

　　图中的easy区是容易操作的区域，且成弧度展示。对于展开的6种功能平等且易操作的展示。那么path2.0的主操作，放置在左下角，采用弧度展开也有依据的。并且，她在同一个位置展开后，转变为×号，复用位置，节约操作空间。

　　除此之外，path2.0在动画效果展示上也极富爱心。loading的翻书动画，图片upload效果，音乐播放的从大到小展示，都让path的体验变得卓越。

　　The End

Thanks for kiwi‘s illustrations.

酷云阅读：个性化泛阅读应用

Mon, 09 Jan 2012 23:07:40 CST

“酷云阅读”是一款个性化泛阅读软件。它通过语义分析技术对文章、视频内容进行归类整理，通过用户行为分析绘制用户肖像，由智能推荐算法将内容推送给用户，并根据用户对内容的反馈不断优化推荐效果。

主要功能：

智能云端最懂你：采用语义分析技术对文字、音频、视频信息进行归类整理，并根据用户的阅读习惯、喜好和好友关系推送内容。
高品质的阅读体验：支持文字、图片、视频等多种内容形式，有效过滤广告及垃圾信息，提供杂志化的展现效果。提供多套制作精美的皮肤，可随心而变。
海量内容资讯盛宴：汇集上万种内容资讯，门户、杂志、微博、报纸、美图应有尽有，全网内容实时更新。支持智能推荐，主题订阅两种内容获取方式，做永不“OUT” 资讯达人。
以文会友，共享愉“阅” ：加关注，求互粉，秀勋章，做“阅读达人”。精彩内容一键分享，还可指定对象哦。
多终端同步：登录之后即可在不同手机终端，iPad，PC上实现同步，我的收藏中还提供离线阅读功能。

类似服务：

指阅是一款和Zite类似的个性化阅读应用，是一款资讯发现与阅读应用，致力于打造适合用户个性化口味的阅读体验。指阅将互联网上的繁多资讯收集梳理，以『话题』的形式重新组织成“微媒体”，帮助用户方便快速地发现感兴趣的内容。（ Via）

链接： http://zhiyue.me/index.html

Watsonxu语：前两天在 2012年移动社会化发展趋势中也提到个性化推荐是一个未来很有潜力的发展方向：在移动上用户更希望更容易的获取自己感兴趣的内容，而不是自己去主动需找内容。比如Foursuare向用户推荐周边热门的优质商家，Zite通过用户选择的兴趣点直接推荐用户可能感兴趣的内容，通过用户的反馈不断改进推荐；豆瓣电台也是一种方便的让用户发现音乐的方式。在移动个性化阅读领域，指阅在这领域内探索，另外如Zaker，鲜果等相信也会逐渐往这个方向发展。

链接： http://www.kuyun.com/

从Mobile World Congress看未来智能机五大趋势

Wed, 29 Feb 2012 17:25:02 CST

世界移动通信大会无疑是全球最具影响力的移动通信展览会，每年业界大佬都将自己的精品展示，MWC可以说是移动行业的风向标，那么今年，在智能手机领域，你看到了什么趋势？

1) 四核处理器

如果你想成为2012高端Android智能机的竞争者，那么四核是必备。上周LG发布了Optimus 4X HD；周日HTC也展示了One X；周一，中兴展示了Era，所有设备都搭载Nvidia的Tegra 3处理器。华为也开发了自己的四核处理器K3V2，用于其Ascend D Quad及Ascend D Quad XL手机中。

LG称：使用四核手机，计算机具有更强的密集型人物处理能力，不过，不是所有任务都需要这么强的处理能力，有的需要低一些的处理能力以延长电池寿命，比如Tegra 3就用于简单任务，比如接打电话，收发邮件，听音乐等。

2)高清的大屏

除了拥有四核处理器，高清的大屏也必须有，比如LG Optimus 4X HD及HTC的One X，两者都4.7寸，分辨率为1280×720。

3)NFC

利用NFC来实现移动支付已成为一个热点，在MWC上，宏碁，化为，LG，诺基亚，Orange，三星以及中兴都展示了具有NFC功能的手机。更多这种手机的出现将会推动NFC技术的的发展，美国高德纳咨询公司研究员Sandy Shen说，其实NFC的最大障碍是改变用户习惯，花费时间比开发基础设施或设备更长。

4)LTE

和NFC一样，LTE智能手机也开始普及。一些新产品，从中兴的N910到PF200，从LG的Optimus Vu到Optimus LTE Tag，都使用LTE网络。LG的目标就是在2012年拥有各式各样的的LTE智能机。

但LTE并不适用于所有智能机，因为对处理器能力有要求，比如搭载Nvidia Tegra3 四核处理器的手机就不能使用LTE网络，不过Nvidia已宣布，将与芯片制造商GCT Semiconductor and Renesas Mobile合作，解决这个问题。

在美国，LTE已成必然趋势，欧洲次之。LG称，公司在今年将会向欧洲用户销售LTE智能机。

5)价格实惠

虽然奢侈智能机赚足了眼球，但在低端消费者（比如那些无法使用四核处理器及4.7寸屏幕的消费者）的获取方面，竞争也很激烈。诺基亚发布了Lumia 610，价格254美金，将于今年第二季度面市，竞争者包括中兴的Orbit，对于想要购买便宜Windows Phone的消费者来说，也是个不错的选择。

大会上，英特尔也想凑凑热闹，发布了1GHz的Z2000处理器，第一款搭载此处理器的手机将会于2013年面市，价格150美金。

Via IW

hover已死有事烧香——移动设备的hover转化

Fri, 09 Mar 2012 19:04:06 CST

　　hover是指鼠标悬浮状态，网页设计师们再熟悉不过。有时，hover是为点击区域提供更多的信息。

比如，dribbble上，hover显示作品更多信息。

　　有时，hover提供更多的操作。

qzone单条feed上面的屏蔽更多操作

　　无论用于哪种方式，即便网页中非常常见，在触屏移动设备中hover将不复存在。这倒也容易理解，因为在手机和人之间不再存在其他间接设备（比如鼠标），人们可以直接使用自己的手指触摸进行交互。

　　由此，所有在桌面web端依赖鼠标悬浮的交互体验都需要重新思考。hover出的信息往往不象点击那样重要：直接显示太过，没有他也不行。因此hover从桌面端倒手机端的转化不能忽视。

　　对于移动设备，你对于hover菜单的选择可以是： 当前页打开，点击或拨动显示，跳到另一页面，或者干脆放弃。

1、当前屏展示

　　如果hover后的内容很重要，例如重要的操作和内容，那么最好的方式就直接展示到当前页面。Twitter在其官方触屏版就是这么做的。

桌面端，将鼠标hover在twitter单条feed就会展示出几个操作：收藏，转发，回复。

Twitter认为这些操作足够重要，因此在移动触屏的体验上直接展示在屏幕上。

2、点击或滑动

　　在手机web 浏览器中，如果代码没有对hover进行特殊设置，会自动设为点击效果。如果你对于现有网站上hover所出的菜单无计可施，可以考虑将他设为默认点击展开。当然，这点上如果hover所出的菜单中操作逻辑上是指下一步那就最好了。但是这对于无疑会造成打断，使得操作进程中多了一步。

　　对于桌面端hover显示更多操作的情况。操作表（Action Sheet）也可以算作一种当前页弹出的展示方式。

　　如果hover后的操作不属于“下一步”，可以考虑拨动显示更多这种方式。不过，相对于点击，拨动手势不太直观，需要更多学习成本，最好采用一些隐喻或轻量的动画－让人们知道他应当如何操作。

　　USA Today更多内容分类采用的截字加阴影的效果，暗示用户拨动显示更多。同时，用户第一次进来的时候会显示一个右滑的动画。

　　同时提醒大伙，在使用不显而易见的手势（比如滑动）时，最好提供其他可选的方式。比如yahoo！邮箱，需要滑动的手势显示，同样支持全屏时候显示。

3、另开一页

　　如果hover所展示的信息属于扩展类型，那么在手机这么有限的屏幕下，最好把hover后的内容单独打开一页。Barnes&Noble就使用了这个方法。

Barnes&Noble把桌面端hover出现的更多信息，单独打开一页展示。

4、去掉更健康

　　如果hover菜单意义不大，就直接舍弃吧。去掉对于用户没啥价值的多余选择和信息，不仅会让你的界面更佳清爽，还让你省去多余的开发时间，所以别害怕扔掉hover。

部分翻译来自《mobile first》

Windows Mobile Marketplace将于5月9日关闭

Fri, 09 Mar 2012 09:40:59 CST

日前，微软宣布将于5月9日正式关闭Windows Mobile 6.x Marketplace，将更多的资源投入 Windows Phone平台。

其实，早在去年6月，微软就已宣布计划关闭Windows Mobile Marketplace，虽然用户仍可以在短时间内通过该平台下载或更新应用，但开发者将不再为该平台做新开发。

此举可能会让很多用户感到失望，但Windows Mobile是移动操作系统进化过程中重要的垫脚石，它曾试图将标准PC体验转移到其他设备。但随着微软最终决定用Windows Mobile 6.5取代它，加上来自 iOS和 Android系统的双重冲击，Windows Mobile注定会在这场激烈的角逐中败下阵来。

当然，在5月9日之前，Windows Mobile还不会彻底消失，用户还可以抓住最后的机会利用一下其余热。

Via TC

Google 将停止移动设备的免 cookie 登录支持

Tue, 20 Mar 2012 03:31:56 CST

尽管影响不广，但这一动作确实够大——Google 旗下的应用将不再支持不支持 cookies 的移动浏览器。
Google 指出，受影响的主要是老款手机，以日本市场为主，这些手机将无法登录 Google 旗下的服务。但不需要登录的业务，如 Google Maps 仍然可以通过过时的浏览器访问，而 Calendar 则将无法使用。
这些变化将在5月1日施行，所以如果用户还在用六年前的翻盖手机登录 Gmail 查收邮件，就该考虑升级了。

Via Engadget

© musiXboy 发表于谷奥——探寻谷歌的奥秘 ( http://www.guao.hk ), 2012. | 没有评论 | 永久链接 | 关于谷奥 | 投稿/爆料
Post tags: Google Maps, Google Mobile

手机版 WordPress 界面插件 - WPtouch

Tue, 30 Aug 2011 00:54:33 CST

最近对触摸设备的浏览器做了功能兼容, 但在小尺寸的移动设备上效果还是不尽人意, 所以看了别人怎么做, 找来了一个叫 WPtouch 的 WordPress 插件制作手机浏览器版本.

随着智能手机和移动网络的广泛应用, 手机浏览器成了最常用的网页载体之一. 但因为受手机屏幕小所限, 很多网站对手机浏览进行了特殊处理, 让访客方便阅读...

使用动机

可能你也曾想过做一套针对手机用户的界面, 或是进行网页兼容 (比如: 不显示侧边栏). 无论是再做一套还是进行兼容, 工作量都不少. 然而, 如果你使用 WordPress, 一切并没有那么艰难, 你可以使用 WPtouch, 它为我们提供整套的浏览器兼容方案. 该插件简单易用, 安装激活即可.

功能特点

WPtouch 支持 iPod, iPhone, iPad, Android, 黑莓, Palm OS 等常用的触摸设备浏览器. 而且强大如一个网站管理工具, 免费版就可以进行一些常规的页面修改, 如选择是否显示文章 Tags, 分类, 作者信息, view more 链接, 菜单管理, 搜索, 分享按钮等常规的功能. WPtouch Pro 版貌似很犀利, 可以自定义主题, 管理广告, 还支持平板电脑界面.

显示效果

如果有 iPhone 或者 Android 手机, 可以访问我的博客看看效果.

免费版已经很强大, 没有必要使用付费版本. 如果要定义主题, 可以修改 default 主题达到效果. 插件提供的那些强大的自定义功能对个人博客来说没什么用, 而且平板设备屏幕大, 进行网页兼容即可兼容, 没有必要另起一套.

后话

插件提供默认主题功能很强大, 连 AJAX 加载文章的功能都有, 但页面结构并不好, 建议有时间爱折腾的同学自我修改和优化.

本来我是想自己多做一套针对手机设备的 WordPress 主题, 在 PHP 层判断浏览来源, 如果是手机设备则使用这套主题. 后来望月告诉我有这个叫 WPtouch 的插件, 就把玩了起来. 我不知道以后会不会一直用着, 但会研究一下这个插件, 这么强大一个插件有很多可以借鉴的内容.

2011年10月6日更新: 现在我已经开发了一个名叫 WordPress Mobile Themes 的插件, 可以为使用手机浏览的访客选择另一套主题, 作为手机主题. 也为该博客设计了一套手机主题, 用手机浏览器访问即可看到...

微观：移动个性化阅读应用

Sun, 15 Jan 2012 22:04:44 CST

微观是由点趣科技推出的移动个性化阅读应用，只要选择你的兴趣点，就会为你推荐你感兴趣并且适合移动阅读的内容。使用阅读，推荐的内容就会越准确，同时也可以发现兴趣相同的朋友

微观特点：

1. 内容精选，并且是最近较热，或比较流行的；
2. 内容经过一定方式的处理，更加适合移动的阅读，并且内容推荐不会重复；
3.个性化推荐，体现从聚合到挖掘和分析的进步；
4.可以发现具有类似阅读兴趣的朋友；

Watsonxu语：如果你还不知道微观，但是我想可能很多都会知道蹲蹲乐这款创意应用，蹲蹲乐是一款适合在蹲坑时阅读的移动阅读应用，当年凭借这个典型的碎片时间切入，受到了很多人的关注，微观是蹲蹲乐团队推出的又一款个性化移动阅读应用。使用体验了一下，感觉比较深的一点是其内容都进行了一定的处理，内容很适合移动阅读，图文并茂，内容推荐的质量也不错，相比较我用过的其他个性化阅读，个人觉得体验很不错。

移动个性化阅读我相信会是一个移动互联网的热点方向，并且Zaker、鲜果、指阅、酷云，甚至新浪、网易、腾讯都会切入这个领域。移动设备上用户都很懒，相对于主动寻找自己感兴趣的内容，个性化的推荐将会是一个更好的方式。当然个性化推荐就涉及到内容的来源，一种是系统自动基于某种算法推荐，一种是算法+人工的方式推荐。我相信个性化阅读的核心竞争在于如何推荐用户更感兴趣的内容，但是从实际操作的角度要做到可能并不容易。相比较于音乐，文章内容的推荐难度更大，不过有这么多在这个领域探索相信会有越来越棒的个性化阅读服务。

链接： http://www.wguan.cn/

中国移动 2011 年度财报发布，日进 3.4 亿元人民币

Fri, 16 Mar 2012 16:16:00 CST

分类: 中国动态

中国移动今天发布了 2011 年度财报，公司全年实现营运收入 5,280 亿元人民币，同比增长 8.8%；实现净利润 1259 亿元，同比增长 52%，按照这个公布的数字做一个粗略计算，差不多每天拿到的净利润约 3.4 亿元人民币。上面的数字看起来是满堂红，不过还有一点冷水泼，那就是经营业务现金流入净额及自由现金流，按年分别下跌 2%、82%。后面的下滑原因其中很大一部分是对手机的补贴，还有就是平均每月用户收入有所下降。在用户数的增长方面，倒是保持了一个健康的态势，到去年年底，中国移动 3G 客户突破 5100 万户，但是优势已经不够明显，必须靠 4G 来做突破。所以 4G 的到来还会给中国的移动市场造就一个新的机遇，各个运营商的疆土也会进行一番重新划分，但那应该是两三年以后的事情了。TD-SCDMA 版 iPhone 到来会给其打一针强心剂么？还需要时间来解答。

引用来源 | 此文章网址 | 转寄此文章 | 回应

福布斯：移动是革新广告，还是扼杀广告？

Thu, 13 Jun 2013 10:58:08 CST

目前来看，无论是从智能手机用户，还是从广告主的角度而言，在手机小屏幕上发布广告似乎都算不上是成功的业务，这也是移动广告营收远远落后于网络广告营收的一大重要原因所在。一般而言，广告主在移动设备上花费与网络上相同的广告时间，得到的营收却远不相同。

那么移动广告如何才能起作用呢？据周一出席麻省理工学院科技评论杂志的移动峰会的诸多人士称，从定制广告到新格式广告在内的许多个性化广告都不是什么真正的广告。

但是，没有人能够给出完全令人信服的答案。据科技评论杂志的发行人兼总编辑贾森·庞丁（Jason Pontin）称，无论是机构，或者是营销人员，在“移动网站上的好广告会是什么样子”这一问题上似乎都无计可施。当然，这些机构和营销人员一直在努力从中找到答案。众所周知，Facebook自从去年进行IPO（首次公开募股）以来，就一直在努力将自己打造成移动网站。Facebook的产品营销负责人布莱恩·波兰德（Brian Boland）上周曾宣称，Facebook计划简化未来几个月的广告活动，以此作为该公司向移动计算方向转变的一种回应。波兰德还透露了一些具体措施，以此阐述Facebook也已经开始考虑针对移动用户的新广告方式。

波兰德声称，Facebook已经认识到，该社交网站必须改变整个网站，以此适应移动设备，而且还要推出新广告形式来更好地适应移动用户，但在此方面，Facebook将面临最为严重的挑战。去年，Facebook推出了所谓的“原生态广告”，这些广告就出现在用户的信息流当中，而且看上去与“有组织的”贴子非常相似，尽管这些广告被标注为受赞助广告。

不过，部分人士认为，例如移动应用奖励网站Kiip的联合创始人兼首席执行官布莱恩·王（Brian Wong）就认为，我们认为是广告的各种广告都不会在移动设备产生作用。他指出，人们之所以为付费版的应用支付资金，就是为了避免广告。

这一点不足为奇，不过布莱恩·王也认为，移动营销会产生回报，并不是所有的营销都会像令人厌烦的广告那样。Kiip最初从确定游戏内容开始，然后又向食品和食谱以及音乐等内容进军。这一创意就是及时地利用重要时机和内容，并让用户们尽力参与其中。这听起来像是在反对广告，但事实上，今年初，该公司曾从一家大型广告股份公司——Interpublic获得了投资。事实上，广告巨头们也已经认识到，移动可能会要求非常多样化的思维。

但是，即使那些内容得到了认证之后，那又会怎样呢？Kiip为用户提供回报，只要用户点击某一内容，就像是完成一个任务管理器一样，但是，Kiip努力想通过偶然的方式来这样做，而不是仅仅提供一些内容，来让用户点击获得奖励。在过去的三年中，Kiip已经发送出1.8亿个奖励。当有人索要奖励时，营销人员就会向Kiip支付一些费用（换句话说，就是按照每次行动来支付成本）。

波兰德则认为，这种广告并不糟糕，而是坏广告本身太糟糕。波兰德称，让人感到惊奇的是，用户并不太关注他们移动设备上出现的广告。波兰德还称，Facebook一直努力让用户明白这些广告的价值，例如移动安装广告强调了用户想要的应用（而一位用户则称，事实上他并不喜欢移动广告，特别是在Facebook上的广告）。

有位用户想知道广告主是否能够追踪用户在现实生活中的活动，例如通过智能手机或可配戴计算设备等，并由此进一步向用户发送广告。对此，波兰德称，用户的电子邮箱就是常常被广告主追踪的信息之一，而且通过电子邮箱发布的广告数量也很多。

数字广告平台公司OpenX的首席执行官蒂姆·加多根（Tim Cadogan）认为，移动广告要想取得成功的最大关键因素，可能就是要放弃那种观点——即必须推出针对小显示屏的独特广告。OpenX目前正在努力研究，什么样的广告才是未来能够在各种显示屏上都能够产生作用的广告。加多根还称，我们必须赶在科技的前沿，并把更多的重点放在消费者身上。电视和买家并不一定需要知道多大的显示屏来运行各种广告，但是，这恰恰是网络广告买家必须要清楚的事。这必须要进行调整，因此重点才能真正地面向实际的消费者。

换句话说，就在我们停止谈论移动广告的时候，我们或许知道移动广告已经取得了成功。

本文来源：腾讯科技

看过这篇文章的人还看过：

Zemanta

您可能也喜欢：
福布斯称企业面临三大趋势：移动、社交和云	福布斯：未来网络广告将不必跟踪用户	DSP:发展移动广告的利器	原生广告，论品牌营销的可持续发展	移动广告为啥让营销人员如此头疼？
无觅

您可能也喜欢：
Web2.0Share周刊：FIT™写字板、飞豆、时尚搜索、Frenzy等	移动应用周刊：酒店小秘、易到用车、乐宝贝、畅行等	Sharein：很棒的社会化分享服务	社会化应用基础服务汇总	SocialToo：帮助你自动应付Twitter
无觅

您可能也喜欢：
百度2012Q2移动趋势报告	每每度情商网：提高情商的网站	百度推出百度网盘（附邀请）	『招聘』百度LBS市场部招聘	百度推出音乐随心听频道，瞄准个性化音乐推荐市场
无觅

您可能也喜欢：
PhoneClean：清除iPhone上的垃圾	Sunrise：体验很棒的社交日历应用	移动应用周刊：30秒名片秀、流利说、秀美甲、美拍等	Isites.us：第三方App Store应用制作服务	iPhone拍照应用推荐
无觅

您可能也喜欢：
Mobile Web App发展现状及展望	雷锋学堂：浅谈产品竞争分析的方法	高效交互设计中的用户需求	微软新版Office Web Apps已可在SkyDrive使用	20121107雷锋日报：搜索未来、拯救App、快捷支付
无觅

您可能也喜欢：
2012年移动社会化10大趋势	最新移动互联网应用推荐第五期『2011.01』	最新移动互联网应用推荐第四期『2010.12』	Android 小助手 1.02 发布	推荐三款iPod Touch/iPhone付费应用\|天涯海阁\|Web2.0Share
无觅

您可能也喜欢：
酷云阅读：个性化泛阅读应用	移动互联网图谱11月	中国移动互联网图谱『2010.10』	移动互联网图谱—12月	2011豌豆荚Android应用年终盘点
无觅

IT瘾mobile推荐

微信收费事件背后被广泛忽略的技术细节

如何通过 OAuth 2.0 使 iOS Apps 集成 LinkedIn 登录功能？

演示 App 概览

LinkedIn 开发者网站—— 创建新的 App

开始授权过程

Getting an Authorization Code

获取授权码

Requesting for the Access Token

请求访问令牌

准备 POST 请求参数

准备请求对象

Performing the request

执行请求

我很好奇

获得用户主页的 URL

在 Safari 浏览器查看主页

[翻译]谈谈当今移动端设计者必备素质

挑战和约束

设备的多元化

操作系统多元化

性能

开发成本的考量

新技能的学习

移动平台并非白板

最佳界面思考并开始思考交互

把设计师的身份放下

寻找灵感，现有的APP会比设计类网站更好

学习新技能

对于平台的学习

学习移动端的各种元件

学习你能用原生的组件做到什么

了解移动端的工作流

了解移动端的用户界面模式

对UI解释说明的文档

在项目设计阶段学习UX

在项目实现阶段持续关注UX

Mobile Web的一些小贴士

对响应设计负责

谨慎使用CSS和JS

选择合适的工具

所有这一切即将过时

微软发布 Office Mobile for Android 应用

Google Search for Android 升级，Google Now 增加目的地天气、本地事件和歌曲识别

微软展示基于 WP8 核心的 Windows Embedded 8 Handheld 等嵌入式系统方案

芒果圈：芒果粉必备神器

相关阅读推荐

@唐兴通:移动互联网的游戏规则

1. 消费者带着企业、市场人员跑

2 . 传统企业才是移动互联网的主要玩家

3 . 新产品的营销推广有诀窍

看过这篇文章的人还看过：

Google 测试在移动搜索结果里加入快速预览按钮，带你到适合移动设备观看的网页

百度推出语音助手

相关阅读推荐

最新jQuery Mobile 1.2版本新特性

Widgets

Popups （弹出层）

Tooltips（工具提示条）

Menus（菜单）

Form（表单）

Dialogs（对话框）

Photos（图片展示）

List Views （可缩放列表）

功能加强

jQuery支持更新

列表视图的自动分隔

只读列表

提供了更好的表单元素宽度调整

其它的设备的支持

完整的更新列表

可以替换iPhone原生应用的APP

1.邮件-MailBox

2.日历-Sunrise

3.浏览器-Chrome

4.备忘录-Evernote

5.提醒事项-OmniFocus

6、地图-Google Maps

相关阅读推荐

mobilebone.js-mobile移动web APP单页切换骨架

hover已死有事烧香——移动设备的hover转化