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

真是英雄所见略同。这正是我的建议的初衷。

多谢邓侃兄拨冗回复

我说的纵向是以月或者年计算的时间。俺在物理层捣鼓，所以很想知道应用开发商如何根据未来用户端的计算能力和带宽发展的趋势决策在哪些时间点推出什么服务、什么质量的服务。也就是，基于硬件发展，对用户的需求做一个长期的预测。

每次只用一个，在用的电池有明显标记，用过的电池也有明显标记，并且自动断开连接，电池可以很容易的拆卸，配三四个备用电池，把用过的换下来。这样可以部分解决电池问题。

直接用GPS有什么问题么？耗电要省得多，地图可以用wired download，费用也要省得多

用HTTP server来解决plug-in，的确有很多争议。

关键问题不是占用CPU，Memory和电池，因为这些硬件发展会很快。

最头痛的是，如何解决UI的炫的渲染效果。譬如图片下方搞个半透明的倒影，再譬如动画效果。

用HTTP service来支持这些渲染效果，不太好办。

Flash lite倒是一个不错的思路。如果能把flash lite和Webkit结合在一起，那就好了。

Gmap是网络版，Google map只做网络版，不做手机版。

为什么？因为Google的战略方向是把赌注押在，1.无线网络无所不在，2.无线网络带宽随处都足够宽。

但是我们觉得这个赌注太冒风险了。所以，我们不能完全依赖网络版。我们选了最稳妥的方式，手机版 + 网络版。

嵌入式HTTP server的存在，不是要解决web application，而是要解决在HTML+JavaScript里，如何调用业务逻辑，譬如embedded POI search engine。

因为目前的HTML和JavaScript中，没有直接调用local library的机制，所以，只好退而求其次，搞了Embedded HTTP server这么一个救急的办法。

我的理解，sky100的问题其实不是web application的问题，而是有没有必要做手机本地版的问题。

如果没有必要做手机本地版，那就没有必要讨论Embedded HTTP server。

多谢WiFi兄的回复。

爆发式同步，我非常认同。在回答四方兄的问题时，我说过，不能等到用户发出请求了，然后再联网，这时已经太晚了。要预先联网同步，同步的方式就是就是WiFi兄所说的“爆发式”，也就是批处理，不能滴滴答答。

关于耗电量的数据，非常有价值。有没有更详细的资料？

这个做法，遭到很多人诟病。

如果说，

the first storage is the RAM,

the second storage is the HDD,

那么the third storage is the network storage.

完全同意Yueyu同学的说法，memory swapping不仅存在于the first storage和the second storage 之间，也存在与the first two storages 和 the third storage 之间。

这个业务在国内市场没有发育。原因，

1.目前国内的LBS业务，是照搬国外模式。国外的主体用户是开车族，中国开车的人毕竟少。所以，第一个原因是国内移动LBS定义不符合国情。

2.技术支持问题。Google手机地图以及其它同类产品，对网络依赖太深。中国移动的GPRS数据网，经常连不上。

将来3G发展起来以后，是否就意味着无线网络更可靠了呢？我的看法是比较保守的，所以强调手机本地版。

其电量十倍左右于手机电池，利用充电孔连接手机，我不太懂，似乎不用改造就可连接了，电池大，似会便宜点，也许也是（在好电池出现前）解决的一个临时出路。

不知道别人怎么看这个问题。就我所了解到的情况看，其实目前大家没有一个很好的办法决定什么时候推什么业务。

现在的做法更像是赌博，如果下手晚了，失去先机。但是下手过早，会成为先烈。

iPhone把手机制造的标准一下推进了两三年。以前一直没有人敢这么预测，但是Steve Jobs这个疯子，他做了，而且做成了。现在其它手机制造商能做的，是一边骂，一边咬牙切齿找办法跟上去。