主题：【原创】大纵深的移动位置业务 -- 邓侃

非常荣幸我们能有这样一个非常好的机会和大家交流一下，作为一个应用开发商，我们在智能终端上做开发的一些心得。今天我们的话题是“大纵深的移动位置业务”，这里有一个关健词大纵深，这个概念是什么意思？是从哪儿来的呢？

回答这个问题以前，我们先看看我们面临的两个趋势。

第一个趋势实际上包括两个方面，第一个方面是，随着3G的普及，以及LTE和将来4G即将成为现实，无线网络的带宽在大大地增加；第二个方面，我们知道以往的网络后台，都是由几个有限的服务器组成，但是现在的局面不仅仅是几个服务器，而是有成千上万个服务器组成的集群，举个例子，比如说Google的云计算平台，就是这样的一个典型，还有开源项目Hadoop，功能也类似。

第一个趋势是说无线网络的带宽和后台服务器集群的规模，那么第二个趋势是说手机本身的性能也在大大增强。无论是CPU的数据处理能力还是存储的空间，当今世界的智能手机已经和前几年的PC相差无几了。

这两个趋势对用户来讲都是好消息，但是对应用开发商来讲，我们的心情相对来讲比较复杂一点。

困惑在哪里？比如我们作为移动位置业务开发商，我们面临着一个选择。移动位置业务的逻辑，我们是应该把它放在后台的网络服务器端呢？还是移植在手机本地呢？

就这个问题我们公司内部争论了很久，没有达成统一的意见。怎么办？请教专家和高人吧，其中包括中国移动院的黄院长。我们得到一些非常好的建设性的忠告，在这里和大家分享一下。

首先，应用程序到底放在手机本地还是放在网络服务器端，决定性的因素看使用的数据。

忠告一，如果某个应用涉及大量的动态数据，最好放在网络服务器端。反过来，如果这个应用涉及的数据是相对比较静态的数据，放在手机本地，可能对用户请求的响应速度会更稳定些，原因是网络的依赖性比较低。

忠告二，如果某个应用的数据的规模是海量的，你可能应该把这个应用放在网络端，充分利用网络集群的技术，做并行处理。反过来，如果你的应用涉及的数据量不是那么大，就尽可能放在手机本地，就地处理。

对于移动位置业务来讲，情况比较复杂。因为移动位置业务的数据，既涉及静态的数据，比如说道路的路名和方位，比如说餐馆这些信息，也涉及一些动态的东西，比如每条路上的交通流量等等。移动位置业务既包括海量的数据，比如中国、美国的POI，但是这些海量的数据又可以被分割成小块，比如说北京市的海淀区的 POI，这就不是海量的规模。

所以是放在网络端，还是手机本地，界限不是那么明显。怎么办？混合方案。既在手机本地移植位置服务，又在网络端支撑这个业务。而且，实现网络端和手机端之间的同步。

如果说功能的多少是一个广度的问题，那么同一个应用，既开发手机本地版，也开发网络服务器版，同时让两端协调，这就是一个纵深的问题。所谓大纵深的概念，实际上等同于开发工作的战线很长。

大纵深的应用开发在技术上有很大的挑战。

第一个问题，当你在做手机本地端开发的时候，会面临跨平台的问题。

刚才Google的黄泰一博士讲了Android有很多很多的好处（黄博士的发言题目是Google Android Java Virtual Machine），我们应用开发商心里非常希望世界上只有一种平台，Android平台。可是现实是比较残酷的，我们面临着很多不同的手机操作系统。我们能不能把所有的赌注都压在Android平台上呢？不行。我们得支持所有不同的平台，不同的版本的手机型号。

这样一来，突出的问题是开发负担非常重。

第二个问题，网络端我们也面临巨大挑战，这个挑战来自于内容，来自于内容的挖掘。如果说，数据挖掘（data mining）是在混乱的数据中，找出一些有规律的模式。我们筛选爆炸了的信息，然后提高给手机用户，这个过程，不仅仅是数据挖掘的过程，而且还要做内容的挖掘（content mining）。

总之，无论是在手机端还是在网络服务器端，我们都面临着严峻的挑战。当然机会也就在这里，挑战与机会往往是并存的。

我们先谈谈手机端开发的问题，这里最大的问题就是跨平台。

通常一个应用大致可以分为两大部分，一个是业务逻辑，第二个是UI。相对而言，业务逻辑部分跨平台的困扰相对少一点，原因是它没有大量地用到各个手机 native APIs。但是，UI部分与平台的绑定是非常强的。为什么这么讲？因为我们目前实现UI的方式，是调用每一个手机平台提供的UI APIs，通过写程序的方式渲染 UI。这样的UI程序，不可避免地，与平台绑定非常强。如果换一个型号的手机，没有别的办法，只好重新编写程序。

跨平台在UI方面显得非常突出。而且情况更糟糕的是，UI经常需要更新。

业务逻辑相对稳定，一旦装载在手机上，很少更新。譬如想知道从你办公室到香格里拉怎么走，需要求路引擎？中午想到外面吃顿饭，需要POI搜索引擎。求路引擎和搜索引擎，都是业务逻辑。很少隔三岔五地更新求路引擎和搜索引擎。但是UI经常面临更新的需求。第一，追赶时尚，第二是个性化。实现个性化的手段包括皮肤。不同的人群对不同的皮肤有不同的偏好，比如温柔浪漫风格，比如重金属风格，比如稳重怀旧风格。

支持众多手机平台，这个开发任务本身已经负担很重。UI部分还要时时更新，开发工作就越发重不堪言。所以说，跨平台的开发，矛盾的焦点首先指向UI部分，

怎么办？前几天有一个朋友跟我交流这个事情的时候，他说，我们能不能学学互联网网页的办法，不直接调用UI APIs，而是写一个HTML加JavaScript文本文件，把UI渲染的工作交给浏览器去完成？这是一个非常非常好的想法。为什么？

首先反过来想想，为什么调用APIs，通过写程序的办法去画 UI不是很好的办法呢？两个原因，1. 用户不仅需要下载软件包，还要安装它。在安装软件包的时候，不可避免的需要设置很多环境变量，这是一个很容易出错的环节，所以第一个原因是软件包的安装很麻烦。2. 安全方面的顾虑。用户怎么知道他下载的软件包不是病毒？因为这两个原因，让用户安装软件会遭到极大的抵触。但是文本文件没有安全上的顾虑，同时也没有安装上的困难。这是第一个好处。

第二个好处，UI肩负着三个方面的交互任务，第一个是应用系统和用户之间的交互，第二个是和远程的网络服务器之间的交互，第三个是和手机本地的外围设备，以及业务逻辑模块之间的交互。

对于这三个交互，浏览器已经解决了三个中间的两个，1. 和用户之间的交互，2. 和远程的网络服务器之间的交互。这对于我们应用开发商来讲，是一个非常好的消息，至少我们可以偷懒三分之二。

但是剩余的问题是如何与手机本地的外围设备，以及业务逻辑模块之间的交互。这是我们这里需要重点谈的。

最好的办法是找Google Android team的黄泰一博士这样的朋友，跟他说，“你能不能在WebKit和V8 JavaScript engine里面，给我预装一个插口，有了这个插口之后我可以插入各种各样的业务逻辑模块？”

但是目前来讲，1. 我们还没有看到一个设计成熟的，工作稳定的手机浏览器插件机制。2. 即便是有这样的浏览器，各个平台，不同厂家的浏览器，它们的插件接口也没有一个统一的，规范的标准。3. 这个业务逻辑模块能插，其它模块不一定能插，也就是说，可扩展性也是一个顾虑。

这种情况下，作为应用开发商，我们不能完全依赖手机OS层面的提供商，给我们提供一个理想的，完美的解决方案，而是得想一想，既然正面走不通，能不能找到一个绕道的办法？我们今天要讲的，就是一个绕道走的解决方案？

我们的解决办法分三步。

第一步，在各个手机平台，我们装一个很小的嵌入式的HTTP server。

第二步，对于所有的应用逻辑，包括嵌入式的求路引擎，搜索引擎等等之类，我们把它们转换为服务。把这些服务放到HTTP server里面运行。

第三步，当UI要和这些应用逻辑进行交互的时候，可以通过HTTP Protocol调用这些HTTP services。

这个办法的好处是，1. 比较容易实现，2. 在我们应用开发商可以控制的范围之内，不需要等待浏览器和JavaScript engine的支持。

这是一个临时的解决方案，最理想的解决方案是找手机的浏览器的供应商，比如Google和Apple，比如Nokia和索爱，让他们给我们提供一个标准化的插件接口，以及IPC的标准化的协议。但是在理想化的解决方案出台以前，不妨先用我们的解决方案。我们这个解决方案没有解决所有问题，我们只是解决了UI跨平台的问题，但是业务逻辑还是得写程序，还是有跨平台的困扰。

刚才我们讨论了手机端开发的一些问题，接下来我们谈谈在网络服务器方面我们面临什么样的问题。

首先是好消息，自从上个世纪90年代初期，互联网兴起以后一直在蓬勃发展，人类历史上第一次面临信息爆炸的局面，咋一听起来这是个很好的局面，但是情况未必真的那么好。在这些内容中间，真真正正适合手机用户的内容，需要筛选。

对于移动读者来讲，存在这么几个问题，1. 内容来源很分散，不太好收集。2. 很多内容没有格式化，即便有格式，每个网站的格式规范也不统一。3. 这些内容的质量并不一定有保证，很多内容是有错误的。有些错误是疏忽造成的，还有一些错误可能就是人为故意的。3. 最后内容可能不一定很完整。

怎么办呢？我们借鉴一些别的网站的做法，看看我们能够不能把它们的思想移用到我们的手机应用上来。

Digg.com是美国的一个网站，这个网站可以说是一个新闻站点。但是它提供的内容并不是这个网站的原创。实际上digg.com提供了很多链接，引用了其它网站的内容。Digg.com网站支持这样几件事情，1. 文章的标题和摘要，2. 评论和评分，3. 分类。

Digg.com非常火爆，比方说一条新闻可以在两三个小时，迅速由冷门新闻登上头版，及时性非常理想。再比如说，发表在以前不知名的网站上的某篇博客，上了头版之后，在24小时48小时内，这个冷门网站的流量突然猛增，以至于很多小网站承受不了流量的剧增而跨掉，这种现象被称之为diggnation。

Digg.com这样网站有什么好处呢？1. 筛选，2. 摘要。这两个特点对手机读者来讲，非常有用。手机读者有两个特点，1. 手机的屏幕尺寸大小，导致了手机读者的阅读速度相当慢，也导致了他们不可能读长篇大论的文章。2. 因为手机的用户经常处于移动状态，所以他们的注意力集中时间比较短，一般来讲不会超过五分钟。五分钟之内，读者没有办法看很长篇的文章。但是精选的文章，全文的摘要，就非常适合手机的读者。这是一个美国的例子。

再来看看我们中国的例子。百度里面有很多很好的创意，这里面有一个不算特别起眼的功能，叫“音乐掌门人”。百度里可以找到很多MP3，音乐掌门人的工作不是创作新的MP3，他们负责做专辑。给每首歌写几句非常浪漫，非常小资的评语，然后把十首歌放在一起，再贴张照片，作为专辑封面。这样一来就做了一个电子版的CD。

技术上来讲，这不是有很大技术含量的功能。但是让人非常吃惊的是，这么一个小小的创意，给百度创造了3%的流量。想一想，百度占领了中国的搜索市场的70%以上的流量，它的3%那可是一个相当可观的数字。所以，百度音乐掌门人这是一个非常成功的创意，尽管它的技术含量并不是特别高。

从digg.com和百度音乐掌门人这两个例子中，我们应该吸取什么经验？

传统的报刊杂志社的员工，分成两拨人，一拨人是记者，一拨人是编辑。记者创作内容，编辑负责筛选和提炼内容。如果说BBS和博客是用户生成内容（User Generated Content, UGC），UGC相当于专业记者的补充，那么digg.com和百度音乐掌门人是用户编辑内容（User Edited Content, UEC），相当于专业编辑的补充。

我们移动位置业务提供商也面临用户生成内容和编辑内容的两个问题。

比如说位置业务需要收集POI服务设施内容。这些POI内容是怎么来的呢？目前主要是靠地图数据厂商，靠扫街收集来的，所谓扫街，就是沿街挨门挨户地收集。扫街的办法，1. 投入的成本很大，2. 更新的周期很长，3. 很容易遗漏，假设收集员忘了访问每个楼面，每个拐角，有些POI信息就可能漏掉了。

怎么办？大家不约而同地想到，应该发动人民群众，靠UGC，用户生成内容的办法，解决扫街模式的弊端。

但是如何保证UGC的质量？UGC包含很多错误信息。固然有些错误是由于无意识的疏忽造成的。但是，由于POI信息涉及到经济利益，有些竞争是恶性的竞争，而恶性的竞争可能造成人们有意识地制造错误信息。过滤UGC产生的内容中的错误信息，出路是依靠UEC，让其他用户来编辑内容。

参照digg.com和百度音乐掌门人的做法，尽管有人故意地提供虚假内容，甚至错误内容，但是由于有很多其他用户来充当编辑，这些编辑担负起了筛选和提炼的职责。一言以蔽之，UGC的质量，通过UEC来保证。

有人会问，凭什么用户会志愿生成内容，并且编辑内容呢？他们为什么会心甘情愿参与这些义务劳动？热闹纷杂的表象的背后，隐藏的是价值链。价值链是商务模式的问题，今天在这个技术论坛，我们不做进一步展开，非常希望以后有更多的机会跟大家交流。

总结一下，今天我们讲了两个趋势，一个趋势暗示，手机应用的开发应该强调网络版，另外一个趋势暗示，应该着重开发手机本地版。对于移动位置业务来讲，出路是既有手机版，也要网络端支持，两者相互协调。所以，移动位置业务，是一个大纵深的应用。对于大纵深的应用开发，手机端要解决跨平台的问题，充分利用手机浏览器的强大功能，是缓解手机端跨平台开发的一个值得思考的道路。网络服务器端开发工作最主要的挑战，是解决内容挖掘的问题，内容挖掘的关键不仅仅在于 UGC，而且需要强调UEC。

我今天的讲话就到这里，谢谢大家。

• 【原创】新时代新潮流WebOS 【6】
• 在手机本地装Web Server