淘客熙熙

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

共:💬70 🌺97
分页树展主题 · 全看首页 上页
/ 5
下页 末页
              • 家园 判断数据是否有用是一个课题

                问题是,如何说哪些数据有用,哪些数据无用呢?

                我的看法是这样的,我们不必要走极端。

                一方面尽可能利用手机的本地计算和存储能力,另外一方面,要有一旦数据不在本地能随时从server去下载的能力。并且从应用程序端完全看不出来。

                就和现在的memory paging/swapping一样,从应用程序角度看,他永远看到自己有4G的memory(32 bits OS),或者更多(64bits或者32Bits支持大内存模式的时候)。但是OS内部却再给他做swapping。这个模式也可以扩展到未来的终端上面。

                那么和memory swapping一样,提高算法,尽量提高命中率(Hit)。就是接下来的课题了。

                • 家园 The third storage

                  如果说,

                  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 之间。

                • 家园 我们是殊途同归

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

    • 家园 请教个问题

      主贴讨论的主要是应用层之上的问题,应用开发商对于应用层之下的问题有没有考虑?

      例如,现在用户设备的计算能力、后台服务器集群的处理能力、连接以上两者的无线网络带宽都在快速发展。对移动应用开发来说,要不要考虑怎么适应这些发展?

      我说的适应指纵向和横向两个方面。

      纵向是从时间上来说,前台、后台、带宽在不同时期的能力差别很大。在开发移动应用的时候,怎么预测未来某一个时间点上能够、或者应该提供的应用服务和这个服务的质量?

      横向是基于用户终端和网络条件的巨大差异来考虑,如何针对这些不同的条件确定移动应用?是否一种应用仅仅是针对某些满足了一定硬件和网络条件的用户群设计?是否要对不同硬件条件的用户提供类似的服务,但是在服务质量上作出区别?

      • 家园 非常正确

        马上要出门,不展开说,先把思路列在这里。

        纵向的问题,关于手机与网络服务器端的连接,不能在用户发起了请求以后,再连接网络服务器,如果对网络的依赖性太强。更稳妥的做法是,在网络连接状态好的时候,就尽可能预先下载所需要的东西。问题是,手机怎么知道应该预先下载什么东西呢?这就涉及到对用户需求的预测。

        横向的问题,对于不同款式,不同能力的手机,应该有所适配。适配的方式,不仅体现在手机端应用逻辑的裁剪和调试,而且也涉及到网络端。设想,网络端针对每个手机用户,有个MySpace。手机与MySpace的关系可以理解为前店后厂的关系。MySpace针对特定的手机,适配完了内容以及功能,然后再把相应数据推送到手机端。

        • 家园 纵向问题

          多谢邓侃兄拨冗回复

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

          • 家园 噎着了

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

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

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

            • 家园 说实话,IPHONE APPLICATION是最好的试错

              苹果把开发软件地摊价送人, 降低开发者进入门槛,由用户社区存优淘劣. 能壮大的收购,收购后更加优化软件. 为下一代的手机提供更好的用户软件. 更好的用户软件吸引更多的用户. 更多的用户吸引更多的开发者. 正反馈效应.苹果一开始的思路就是打造社区, 手机只是一个平台. 只在平台上作文章, 和苹果的距离只会越来越大. 小开发商很快就会被最大的用户社区吸掉. 大开发商也不能无视这个最大的市场. 但苹果一统江湖的可能性很小, 这是他这个商业模式所决定的. 苹果的利润来自高端和不断地推出新产品. 低端的市场他根本不想理.

              苹果其实改造了整个手机市场, 凭一个KILLER APP就能打出一片天下的(黑莓), 已经是不可能的了.

              • 家园 见识

                特别喜欢这两句话,有见识

                更好的用户软件吸引更多的用户. 更多的用户吸引更多的开发者. 正反馈效应.

                苹果一开始的思路就是打造社区, 手机只是一个平台. 只在平台上作文章, 和苹果的距离只会越来越大. 小开发商很快就会被最大的用户社区吸掉。

                Steve Jobs的思路,从来就是成体系,而不是拘于单个产品。感觉特别有纵深,王者气派。

        • 家园 手机端安装一个http server感觉不太可行

          我和几个朋友也在做这方面的产品,同样遇到了类似的问题--UI部分。

          逻辑层可以用C或C++实现(C++在不同平台上还有差异,最终选择的还是C),这部分变化很少,跨平台的问题也好解决。但UI部分确实比较麻烦,各平台差异很大,使用native language的话基本等于每种终端重写一套代码。目前我们考虑的是使用flash lite或是用纯图片方式(有点像个游戏引擎)实现UI,这样解决UI的跨平台问题。不过flash lite目前的性能还有些不足,非智能机上还没有flash lite解决方案。

          另外关于社区的想法非常好,这也是我们一直期待的。但如何组织好社区却是个值得考虑的问题。而且法律方面的隐患也会非常麻烦。

          • 家园 Plug-in as HTTP service

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

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

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

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

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

    • 家园 出处

      12月18日-19日,第二届CNGI工程技术论坛暨移动互联网国际峰会的发言稿。

      • 出处
        家园 感觉国内的LBS市场还没有启动

        国内的LBS市场还是在启动阶段,移动想着自己通吃。几个相对大的公司跃跃欲试但是市场没有大规模启动的迹象。

        不过3G上来以后移动不能独霸了以后可能会好点。

        不过对这个市场在国内的商业模式还是看不清楚。

        邓兄能否发表点意见

        • 家园 移动LBS国内市场问题

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

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

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

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

          • 家园 中国移动GPRS经常连不上?

            我印象中似乎不是如此。

            印象中是中国移动EDGE铺的太窄,大部分终端也只支持到GRPS6/8,连10都很少。如果真的铺开3G,情况应该会好很多。这是以中国移动基站的密度对比美国基站的密度推测的

分页树展主题 · 全看首页 上页
/ 5
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河