主题：【原创】大纵深的移动位置业务 -- 邓侃
非常荣幸我们能有这样一个非常好的机会和大家交流一下，作为一个应用开发商，我们在智能终端上做开发的一些心得。今天我们的话题是“大纵深的移动位置业务”，这里有一个关健词大纵深，这个概念是什么意思？是从哪儿来的呢？
回答这个问题以前，我们先看看我们面临的两个趋势。
第一个趋势实际上包括两个方面，第一个方面是，随着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。
我今天的讲话就到这里，谢谢大家。
本帖一共被 2 帖 引用 (帖内工具实现)
12月18日-19日，第二届CNGI工程技术论坛暨移动互联网国际峰会的发言稿。
主贴讨论的主要是应用层之上的问题，应用开发商对于应用层之下的问题有没有考虑？
例如，现在用户设备的计算能力、后台服务器集群的处理能力、连接以上两者的无线网络带宽都在快速发展。对移动应用开发来说，要不要考虑怎么适应这些发展？
我说的适应指纵向和横向两个方面。
纵向是从时间上来说，前台、后台、带宽在不同时期的能力差别很大。在开发移动应用的时候，怎么预测未来某一个时间点上能够、或者应该提供的应用服务和这个服务的质量？
横向是基于用户终端和网络条件的巨大差异来考虑，如何针对这些不同的条件确定移动应用？是否一种应用仅仅是针对某些满足了一定硬件和网络条件的用户群设计？是否要对不同硬件条件的用户提供类似的服务，但是在服务质量上作出区别？
马上要出门，不展开说，先把思路列在这里。
纵向的问题，关于手机与网络服务器端的连接，不能在用户发起了请求以后，再连接网络服务器，如果对网络的依赖性太强。更稳妥的做法是，在网络连接状态好的时候，就尽可能预先下载所需要的东西。问题是，手机怎么知道应该预先下载什么东西呢？这就涉及到对用户需求的预测。
横向的问题，对于不同款式，不同能力的手机，应该有所适配。适配的方式，不仅体现在手机端应用逻辑的裁剪和调试，而且也涉及到网络端。设想，网络端针对每个手机用户，有个MySpace。手机与MySpace的关系可以理解为前店后厂的关系。MySpace针对特定的手机，适配完了内容以及功能，然后再把相应数据推送到手机端。
国内的LBS市场还是在启动阶段，移动想着自己通吃。几个相对大的公司跃跃欲试但是市场没有大规模启动的迹象。
不过3G上来以后移动不能独霸了以后可能会好点。
不过对这个市场在国内的商业模式还是看不清楚。
邓兄能否发表点意见
谢谢邓兄好文。
我考虑问题的角度是从终端出发。我的看法是应该在终端缓存尽可能多的数据。然后用爆发式的同步来减少对网络端的依赖。这样做至少有两个好处：一是最好的用户体验。你不希望你的用户下线后无法使用你的服务。最好是用户根本就体会不到是否在线。二是电力消耗。爆发式同步可以最大限度的减少与网络端数据链接的时间，也就可以延长终端的使用时间。我给你一个3G基带芯片的电源数据：
Average(mA)
IDLE mode with GPS ON full power mode* (Stand by mode; no call in progress; GPS ON)
AT+CFUN=1 WCDMA 117 GSM 113
AT+CFUN=4 WCDMA 109 GSM 109
WCDMA TX and RX mode with GPS ON full power mode*
WCDMA Voice 785 (WCDMA voice channel)
WCDMA Data 775 (WCDMA data channel)
HSDPA Data 825 (HSDPA data channel)
GSM TX and RX mode with GPS ON full power mode*
GSM Voice 410 （GSM voice channel)
GPRS Data Class12 880 (GPRS data channel)
EDGE Data Class12 650 (EDGE data channel)
考虑到邓兄的应用，我给出的是GPS ON的数据。这里还必须再加上主机端的耗电量。500MHz CPU，3吋左右屏正常亮度正常使用时的耗电量大约100mA到250mA。取决于系统Idle（不是Standby)时电源管理的优化程度。
可以看到如果应用程序总是呼叫数据连接，终端的可用性是要大大降低的。
对某些应用，的确可以一次性cache相当多数据。比如一个小地区内的POI数据或者地图数据。或者自己所有的好友的信息。
但是对于更大规模的应用。比如我在上海，想找南京的饭店然后开车过去吃饭。这就让手机很为难是否要能否cache得下来。
当然，我非常同意终端电池使用时间的重要性。在技术没有突破之前，只好用最土的办法，随时充电。希望研究人员尽快把手机电池做的更好
浏览器就是一个很好的例子，用户可以动态调整cache大小。下一代的终端至少有256MB的ROM，再加上8G到32G的SD。用户有足够的空间。
电池现在就是瓶颈。想像你的手机：
1GHz CPU，256MB RAM， 1GB ROM
3”+ 800x480电容屏
2D/3D加速器
Video加速器 720P 30fps playback
GPS, WiFi(
)，BT2.0+EDR
3.5G
各种感应器。
你说多大的电池可以支撑这样的终端？2小时充一次电？
从我做的东西的经验，数据量远不止这么点
我和几个朋友也在做这方面的产品，同样遇到了类似的问题--UI部分。
逻辑层可以用C或C++实现（C++在不同平台上还有差异，最终选择的还是C），这部分变化很少，跨平台的问题也好解决。但UI部分确实比较麻烦，各平台差异很大，使用native language的话基本等于每种终端重写一套代码。目前我们考虑的是使用flash lite或是用纯图片方式（有点像个游戏引擎）实现UI，这样解决UI的跨平台问题。不过flash lite目前的性能还有些不足，非智能机上还没有flash lite解决方案。
另外关于社区的想法非常好，这也是我们一直期待的。但如何组织好社区却是个值得考虑的问题。而且法律方面的隐患也会非常麻烦。
这个idea和传统的web application有什么区别呢？最多只是传统的web application的手机版。那么，何必非要浏览器单独开放接口呢？传统的web application已经可以提供足够强的用户交互能力了。举个例子来说， gmap是绝大多数能上网的智能手机都有的应用，google要求所有的手机浏览器给它专门为gmap开放个接口吗？另外，干嘛业务逻辑一定要放在本地呢？业务逻辑也完全可以放在网络服务器端呀。这样你干嘛还要embedded http server?传统的http server就可以实现。
另外，业务逻辑可以即放在手机本地，又放在网络服务器端，并不是你想的放在一个地方，就像光的波粒二象性一样。不能联网就先在本地处理，等能连上网时再动态同步本地的数据与服务器端的数据。google gear的开发包就提供了这样的框架和接口。
比如开车导航，如果我没有带车载充电器，我一般不太敢用。开远了的话，就是能开过去不能开回来。而一般开远了都是不太熟悉的路。白天导过去，晚上绕几个弯才回来实在不是好的体验。
但是并不是所有的情况下，正好有车的马达可以给你充电。电池就死和相当重要了
以前看到过可以手摇充电，可以太阳能充电什么的。但是最好还是搞一个相当皮实耐用的电池，以及每个器件都搞成低功耗
取决于在多大的时间段。如果是一两天时间，那你需要重新定义你的服务模式。我不知道用户可以真正用到多少。你应该不希望用户下载无用数据到他的终端。高清晰视频流媒体例外。
其实最初HTML仅仅是用来显示文本。但是它是一个很好的概念。基本上是一个XWindow的一个简化的实现。
其实现在的问题是，web application目前的接口已经不能满足现在的应用程序的开发了。即使是google gear也无法满足。而等待各方面达成一个新的协议，那么又太慢，应用程序开发商耗不起。
而且很有可能在这个新协议达成之后，发现又过时了，又得重新协商来做个新协议。这就陷入了一个怪圈了。
所以自己做，其实是无奈的体现。特别是在手机端的所有的web接口还更加弱的时候，只能自己做
问题是，如何说哪些数据有用，哪些数据无用呢？
我的看法是这样的，我们不必要走极端。
一方面尽可能利用手机的本地计算和存储能力，另外一方面，要有一旦数据不在本地能随时从server去下载的能力。并且从应用程序端完全看不出来。
就和现在的memory paging/swapping一样，从应用程序角度看，他永远看到自己有4G的memory(32 bits OS)，或者更多(64bits或者32Bits支持大内存模式的时候）。但是OS内部却再给他做swapping。这个模式也可以扩展到未来的终端上面。
那么和memory swapping一样，提高算法，尽量提高命中率（Hit）。就是接下来的课题了。