主题：【原创】手机应用开发商之烦恼 [4] 跨平台 -- 邓侃
哈哈，我尽快写。
多谢。
我平时用的就是第一款的iPhone，8G存储空间。
第一款iPhone问题不少，但是仍然很喜欢。
什么叫cool？描述起来不容易，但是看看iPhone就觉得cool。艺术就是挠你心里痒痒但是又不可名状之处。
如果让我给这四个制约派个顺序，
1. 存储容量，
2. 带宽，
3. 电池，
4. 计算能力。
各家有各家的麻烦事。我这样排序，与我们开发的产品有关，我们的产品涉及到大数据量。
容量不够就得去网络服务器拿，带宽的需求就高。一来一回时间就拖得久，电池就吃紧。
计算能力虽然重要，但是比起其它三个来，问题就不是那么那么的突出。查看一下系统在各个环节的消耗，发现IO最大，而不是计算复杂性。
对于其它应用开发商而言，他们的瓶颈或许在CPU上。所以排序没有普遍认同的定论。
俺专业是移动通信，所以有此一问。主要是想不出来除了视频之外还有多少应用需要B3G超过100Mbps的下行速率。听你介绍的这个项目，看来俺们做通信技术的还有的混。
其实我用美国的t-mobile超过4年了，t-mobile基本上是买了个小运营商VoiceStream起步的，覆盖面一直不大，很多地区都是靠租用别家公司的线路。北美t-mobile的吸引力在于：
1. 经常有比较好的手机促销，通常是免费，甚至是倒贴。
2. 话费比ATT，Verizon便宜10块20块
HTC Excalibur在t-mobile的型号叫DASH，当初吸引了很多新用户。HTC也没办法嘛，本身品牌知名度不高，没什么bargain power. 北美的手机绝大多数都是通过运营商渠道销售的。
这两年是手机市场重新洗牌的关键时期，Apple和Google已经说过了，RIM新的触摸屏手机也上市了，看上去也非常有吸引力。Nokia也即将上市新款触摸屏手机 http://www.youtube.com/watch?v=aFKyAMQPbmI，听说价格也很有吸引力。
这种趋势对研发能力比较弱的手机厂家如Moto，索爱及其他二三线日本、韩国厂家压力很大，独立研发平台肯定做不到，Feature Phone是夕阳产业，唯一的办法是选边站。我不知道别人怎么看，我感觉在这个转变中Limo，WM都不会是赢家。
我一直不明白微软在这方面为什么这么迟钝，到现在眼睛还盯着Yahoo，手机市场这么大，三四年前WM虽然缺陷很明显，但还是蛮有优势的，几年过去了怎么就没想到好好改进。
这里实际上有几类厂家
1.系统厂家或联盟
Google/Andriod(Linux)
MS/WM
Apple/MacOS Mobile
Symbian(Nokia)/Symbian+S60
RIM/Blackberry OS
LiMo/Linux
2.OEM或产品厂家
HTC/ Dream(G1)/ Raphael(Touch pro)/…
Apple/iPhone
Nokia/N96/5800/…
RIM/Storm/Bold/….
Moto/Q/Razr/…
SE/X1/P1…
LG/...
Samsung/...
3.运营商
T-Mobile
ATT
Verizon
Orange
NTT
各类厂家的目的不同其结果也就不同
1. RIM/Apple 肥水不流外人田,又各自有一手,小日子过得不错 - 其实主要靠后端赚钱
2. MS/Google 提供系统给OEM,他们必须有另外的来钱渠道,其实日子应该或将来也不会错
3. Nokia+Symbian, 80%的Apple+20%的MS, 别看市占率高,应该是想往Google模式靠,靠后端赚钱比卖手机容易多了
4. T-Mobile/ATT/Verizon等控制网络,赚钱也相对容易
5. Moto/HTC/SE/LG等OEM就难了.研发越来越耗时耗钱,终端越来越便宜,利润越来越低.上10个项目可能也就2到3个能出货.你让他们怎么办?
所以所有的有点实力的公司一定会在后端想办法.我不相信有Killer app,我只相信有killer service. RIM的email, Apple 的iTune, MS的Exchange/Live, Google的Internet(future).That's the direction. 我相信Nokia的OVI也是这打算.如果大家有好的后端的想法倒是值得多探讨探讨.邓兄的基于LBS的服务就很有潜力.但前期投资是个问题.
另外,实际上,HTC/WM也不是这么不堪.我就只用WM,没别的原因,Exchange支持而已.Email/Calendar/Tasks/Contacts共享可以使日常工作非常方便.其实习惯是最重要的.当然6.1的smartphone版要好用的多.
俺不认为killer “app”就没有了， service不是“应用”？
这话说的有点抬杠
俺分析Chrome的目的之一也是想看看Google里面的牛人是如何具体地解决跨平台的问题。
服务就是应用,应用也是服务.语音电话,SMS,浏览器,youtube等是应用也是服务.
以前听人介绍Extreme programming，说基本意思就是两个同时在一台电脑前面工作，这样效率高。觉得不可思议。都说多线程并发效率高，没听说多线程集中在同一个任务上效率高。
后来试了试extreme programming，发现真的效率高。什么原因？因为两个人同时同地点做同一件事，一边干活一边讨论，虽然表面上花了很多时间说话，而不是写程序，但是，1. 工作兴致高，2. 由于充分的讨论，程序的质量好。
分析WebKit也一样，几个人同时分析，相互讨论，不仅兴致高，而且讨论有深度。
类似，也许很搞笑的是，有时候我们这里有一些问题，无非就是找我去看看，结果两个人走过去，不用我看，对方就发现了问题在哪里。
总结了一下读Chrome的经验，有些不同的观点。
1.跨平台的编译。这个一要看公司可调动的人力资源的情况，二要看是否是Open Source。Chromium中就准备了两套方案：VC 200x中的Solution文件的和x:\chromium\src\build目录中的SCons配置文件（俺是不懂那个SCons，但起码看静态的文件是这样的，见笑见笑）。这个吗，好像前几年流传的段子 --- 如果俺有钱了,俺就弄两个手机，左手拿移动,右手持联通，想联通就联通，想移动就移动。俺是Windows上的懒人，绝对用Solution文件。因为大多数公司是“没钱的”，而且不Open Source，所以楼主的观点是“没有错误”的。
2.如果是NATIVE BINARY CODE,所谓之跨平台语言根本没有什么选择 --- 就是C/C++。所以选语言不如说选基础框架,Chrome的选择包括基础函数库 --- ICU（International Components for Unicode），插件接口 --- NPAPI，图形方面，自然是Google的私家货 --- skia。反正用VS 200x不用MFC。出于Windows上插件兼容性的考虑，ATL用了一点点。
3.第3条俺比较赞同，模块的分割与抽象很重要。这方面Chrome做的比较好，比如Renderer模块中与webkit的衔接，Plugin中和第三方的衔接。
4.该用特定平台的地方不要含糊 --- 80:20法则。Chrome在进程安全性方面，使用了Windows的DEP，Desktop, 进程Token, Job等等。LINUX上有没有类似的东西俺不知道，俺对那上面的开发是一窍不通。
5.叫什么名堂不重要，神似胜过形似 --- 好东西要大胆的借鉴，管它是来自M$还是其它。比如Factory,scoped_ptr,Release(),AddRef()。
6.如果大家的技术都趋向于同质，大家是否会沦落为目前中国的状态 ---“世界工厂”，生存链的底端？如何保持自己的核心竞争能力？
之所以要解决跨平台的问题，动机是给应用开发商减轻负担，尤其是鼓励和培育千千万万个中小型应用开发商，甚至于个人也可以鼓捣点东西，就像很多个人用户自己动手设计QQ空间皮肤，表情，又譬如很多个人用户自己动手设计Facebook游戏，小工具一样。
1. 跨平台的编译。同意你的意见。
2. 选语言不如说选lib，这话有洞见。
太守能否多说几句ICU，NPAPI, Skia？Skia和OpenGL是什么关系？请教一下。另外，VS200X和MFC的问题，ATL的问题，相信感兴趣的人不少。
坑挖不填，后果很严重，呵呵。
3. 想一起去了。
4. 平台的特定lib。不是愿意不愿意的问题，而是回避不了的问题。
打个比方，不同的硬件对应不同驱动器。所以OS的代码不可能100%跨平台。
5. 拿来主义。你所说的借鉴，是模仿M$的Factory,scoped_ptr,Release(),AddRef()，开发一套跨平台的lib？
6. 核心竞争力。是产品功能的不同。跨平台的负担越轻，开发商或者个体开发者越有精力去繁荣产品的功能，而不是疲于本命，推广单一产品去多个平台。
多谢这么有深度的反馈。
所以不是有人说在自己桌上放个玩具熊对着它叨咕就行了
当然可以，如果玩具熊能够激发思维的话 ：p