主题：从曾经的Android组成员的角度来说说Android吧 -- zllwy

smartphone对于我来说就很有用。

开车的google map Navigation极大的用处,比我原先用的GPS软件还好用。我的车很老，没CD的那种，我拿它听歌，网络现场。

查邮件，基本上实现了即时查邮件，不用担心很多事情没有看到想到。

每天用手机看看新闻什么的，非常好，特别是Android那里有个Technews，综合性的新闻一起推荐，wired, Gizemode等等的一起推荐过来，很有趣.

不用带着圣经，唐诗，宋词的，想看这些的时候，一个手机就可以了。

还有Calendar很有用。

我拿手机，下面准备用Tablet看google doc shared的文档，太有用了，我基本上可以跟我的合作者边写边改，这一点是非常有用的。

下面我要买7''的Tablet就是这个意思，以后手提袋里，不多放东西了，就拿手机及Tablet，减轻很多重量。

非常看好Tablet。

• 是啊，又一个Tablet PC

很感兴趣，可以详细解释下吗，google哪些方面提供了强大的后盾？

现在小公司做mobile apps，要做好几个版本，ios、android、rim都要做，太费时间和资源。有一种方法是利用浏览器来整合apps ui，楼主对此有什么看法？

Guice, Guava(以前的google collections), protobuf, go,gwt这些在google内部都是很核心的技术（更不要说Chrome / Chromium / Android了）。其他不说，protobuf基本上是google的标准数据格式，不仅仅只用于RPC。当然Google是不可能open source很多关键的算法的。另外，很多东西也是很难open source的。比如Google公开了protobuf的实现，但RPC那部分没有，因为RPC实现跟Google内部的其他系统关联太大，就是open source了，大家其实用处也不大。再比如gwt是用来实现Google wave的。相比其他公司，Google对community的贡献还是很大的。Google是不可能告诉你search的经验公式的。其他重要技术，基本上不是有论文，就是open source。否则Hadoop也不会有了。你要说这些是边角料，可能不太公平。

个人看法啊。说了不任何负责任的。

我觉得你这个问题无解。Web UI当然好。Google在Mobile web上面也下了很大功夫的，很多应用native和web都有。而且长期来看，特别从Google的角度来看，当然都统一到web平台上去好了。WebOS虽然是个failure，但技术上看，也不算太失败。

回到现实里来，用户体验绝对是native的好。这也是为什么Android和Chrome OS都要有。Google要赌两边的，是吧。举个个人体验的例子，Google reader很长时间里只有mobile web版本，最近才有了native app，我使用的感觉是鱼终于回到了水里。所以我的建议是，尤其是小公司，一定要做native app。至于resource的问题，我觉得应该调查一下市场，如果你们的产品主要是某个平台的用户，那就优先推出那个平台的。就是Google也没有精力同时推所有的。看看Amazon的kindle app，不也花了几年才cover所有平台吗？抓大放小，从来都是这样的。

我想我已经说过了吧。再举个例子吧：Google goggle。你拍张照，然后Google拿去search它的image database，然后返回search结果。比如你去商店，看到一张CD，你就扫一下，看看网上的review怎么样。这个例子可能不好，因为实际当中我感到这个应用目前用处不大。另外一个，voice search，你的voice数据被送到Google那里匹配然后返回search结果。这个还是很有用的。总之Google一定会用它强大的data mining和分布式计算资源来给mobile console提供各种服务的。这方面大部分公司都没有这个能力。Apple有财力但没有足够的经验。

普通一个Engineer而已，和这里的大多数一样吧。所谓码工嘛。:-)

App Engine我也在学。请教就谈不上了。而且我不知道任何内部实现。基本上都是网上那些信息。

试着回答一下啊。不一定能说服你。

其实Google本身声称是没有对Android偏心的。比如有一次Google推出一个iPhone app，不记得是哪个了，那时Android还没有。我们还觉得挺不能理解的。其实我个人感觉Google开始的时候对Android也没有那么commit，据说其中一个cofounder是不喜欢Android的（谣言谣言，不要当真）。而且从Google角度来说，Android的最终目的不是dominate，而是disrupt，不能让一家（大家都知道谁）独大。最终的目的是让mobile web流行起来，Google的Ads revenue自然就上去了。现在看目的达到了。

回到Android的优势上来，我想尽管不是出于故意，Android在提供比iOS更好的Google service的支持上还是有优势。一个是平台的开放性，很多app就是在Android更容易实现，少了很多限制。另外一个就是Android可以和Google backend service的紧密结合可以更好地去实现一些应用。从内部合作方面来说，大家都知道Google内部的startup气氛。很多开发者会优先考虑支持Android，更不要说Android team本身得天独厚的条件了。岔开去一下，我最喜欢Google的一点就是内部小组之间的交流极其有效，大家都非常乐意帮助其他的组。Android team或者其他Google service的team可以比较方便地得到互相之间的帮助。自然可以比较快速有效地推出apps。从技术角度来说，Google可以很容易在client和server端同时做出优化，提供最好的用户体验。比如说google talk，我们从Android本身和google talk service两端都做了很多改进和优化以便省电，减少latency。这个绝对是iPhone上做不到的。就我最喜欢的Google navigation来说，iPhone现在还没有。好像iPhone上也没有native的Gmail app。很多service app你当然任何人都可以写，只要有API，但你要达到最好的性能和功能，没有server side的配合就很难了。Apple就要依赖第三方的service和developer来帮它做。

当然这种优势也是相对和有限的。对于Google来说，只要没有一个绝对的dominant player，它就没有损失。但对Apple来说，这就是全部了。对于我们用户来说，爱用那个用那个，没有绝对好坏。对于开发人员来说，哪个赚钱就学哪个。目前我是建议给iphone写app的，如果你想赚钱的话。:-)

对GOOGLE后台扩展性的架构和经验很感兴趣。

在iphone上很长时间用那个老中写的MobileRSS，还算不错，但有google的最好。

我们做了个类似amazon的ec2平台，希望在此基础上做一个app engine，不过目前碰到不少难题，头痛中，，，，

我说的边角料是指有很多可替代的东东，不是不可或缺的关键技术。

protobuf虽然性能突出，但是比较还是有替代品的，对性能要求不那么苛刻的时候用json也可以；另外基本上我待过的公司，只要做分布式的系统都有一套类似的东西。

不用guice也可以用spring。

当然了，google不透露核心技术也是非常理解的，呵呵，我等只是徒流口水而已。

我对map backend真的一点都不知道啊。

说来好笑，自从离开Google以后，对Google的技术反而越来越有兴趣。可惜现在都只能从公开信息去学了。最近在研究分布式存储方面的东西。Google的Spanner大家都听说了吧（看Jeff Dean的talk: http://www.stanford.edu/class/ee380/Abstracts/101110.html），bigtable的后继。有一个细节是（公开的信息），Google越来越多的使用strong consistency的replication，看App engine最近新推出的datastore就知道了。其中最重要的一个算法就是Paxos算法，这是唯一一个被证明了理论上正确的consensus algorithm。很多系统都有自己一套的replication算法，但其实都是一些经验性的，没有理论上的基础，在很多情况下不能正确地保证Consensus。Paxos最初在Google的chubby里面用。现在看来扩展到bigtable replication了。不知道spanner是不是已经可以用了。说起Paxos还是很有意思的。以前分布式系统里面consensus都是用2-stage commit或者3-stage commit。虽然很直观，其实不能处理所有的情况。就这么个看起来很简单的问题，一直到80年代的时候，Leslie Lamport（理论大牛，在微软），写了一篇考古文章，发掘出公元1000年的时候，有一个希腊的小岛上的城市国家的议会用了一个算法解决了他们在法令上达成一致意见的问题。而这个方法，正好解决了异步分布式系统中达成一致的问题。本来Lamport可以用学术界通常的文笔写这个问题的，不过为了轻松气氛，他仿照byzantine failure的那篇文章，以考古的手法描述这个问题，只在文章的最后一笔带过和分布式系统的关系。他把文章投了一个著名的杂志，结果被退稿了，编辑说你把考古那部分去掉吧。看来不是所有人都有幽默感的。大牛就是大牛，不发就不发呗。他就把文章锁抽屉里了。不过文章还是在学术界私下传开了。很多年以后，90年代中期吧，微软一个人写了篇文章解释了Lamport的算法，讨论了证明和如何使用。这下这个算法终于火了，大家意识到这是唯一理论上正确的算法。这下Lamport的那篇考古文一字不改地发表了。然后一直到2001年，Lamport终于受不了了，写了一篇Paxos made simple，说看来我的前一篇文章大家看着像希腊文写的，那我就简单地描述一下吧。Google的Chubby可能是第一个大规模在production system里面使用这个算法的。现在Hadoop的zookeeper也是类似的，不过他们不是严格的paxos算法，我不知道是否还是paxos的一种，以及理论上是否正确。

扯远了。说正经的。Google的backend的确是非常重视scalability的。在这方面做了大量的研究和实践。要是能把这套系统推广开去，应该会很有意义。Hadoop在这个方面有很大贡献。你说到对经验和架构的兴趣，这个得具体谈了。随便说几个，不知道对不对。

1 分布式存储/数据库。基本上就是摆脱传统的database model，所谓的NoSQL潮流。具体到技术就是Bigtable和GFS。

2 和存储相适应的就是map/reduce。

3 分布式协调。就是chubby distributed lock service。Chubby用得很广泛。

4 Stateless application logic。所有的app（特殊的除外）都是stateless的。随demand的变化可以增加减少instances。

5 Load balancing

这里一下也说不清。有兴趣私下聊吧。给我发站内信交换联系方式。

我们也是做这个的。私下聊。给我发短信。