多年过去，宾州大学已经改用 Java 教授此课，麻省理工大学也亦步亦趋的改用了当下流行的 Python。

为什么？

教材的合著者 Sussman 解释：1980 年代时的技艺和 90 年代中期或 2000 年之后的不同。在当时，优秀的程序员花费更多时间思考，代码精炼短小，且和思维的节奏相似。即便如 Scheme，也能一气呵成的从头看到末尾。就像是电阻器，当你懂得如何读出色条并且知道额定功率、容差、阻抗和欧姆定率的时候，你就知道了一切。6.001 即是以此为基础，讲授如何理解小段代码，以及，如何使用简单的技巧将它们合并成你想要的大家伙的方法。

不过，Sussman 说，今非昔比。现在，你要纠缠在难于理解和不知谁人攒写的代码中。你得先做一些调查，了解库是如何工作的，或尝试不同的输入，看看代码如何回应。这和 80 年代的工作全然不同，因此需要新的课程。

有趣的是，新的 6.001 的核心是教你如何给一个机器人编程。学期的末尾， 你得让你的机器人动起来。不过，机器人和电阻不同，它需要面对实时变化的环境考验，例如轮组打滑，因此，系统要稳健可靠。这同样和最初的 6.001 讲授的内容不同。

至于为什么是 Python？Sussman 说，也许是因为 Python 已经有了和机器人有关的库吧。

虽然教材已换，Alan J.Peris 在这本术士之术的序言中反复提及的一段话仍是适用的 —— 「乐趣常驻」。

已经GoldenMaster的iOS 4.2系统为音乐人带来了一份大礼：CoreMIDI。这意味着你的USB-MIDI接口或USB键盘（说的是演奏音乐用的键盘，不是QWERTY键盘……）只要支持Mac OS X的Class驱动，即可将其USB接口通过Apple官方的Camera Connection Kit转换接口连接到iPad、iPhone和iPod touch上直接使用，让MIDI信号自由在iOS设备和你外部的MIDI设备之间传输。

不过iOS设备毕竟不是电脑，它的供电也许带不动你那有着一堆LED灯的MIDI控制键盘和多进多出的MIDI接口，所以如果你的MIDI设备可以通过电池或电源供电一定要接上，要是仅能通过USB供电的话，只有最简单的MIDI键盘和一进一出的MIDI接口才有可能跑的动。其实还有一个办法：通过可用电源供电的USB HUB或双头USB线缆给它额外的电力，减轻iOS设备的供电压力，不过这样似乎就失去了移动的意义了，有点蛋疼。

下面这段视频就演示了将Novation X-Station 25合成器（有外部供电）通过USB连接到iPad，利用Pianist Pro这个应用让X-Station 25内置的合成器引擎发声。

WiFi-OSC-MIDI：

其实在iOS 2.0时代就出现了一大票的音乐制作应用和音乐设备控制应用，他们也都可以跟外部设备互动，当时用的是OSC协议。但由于很少有音乐制作软件和硬件支持比较先锋的OSC协议，所以用起来比较折腾。iOS设备的应用通过WiFi发出OSC控制信息到你的电脑（PC或Mac均可），然后你必须在电脑上运行一个OSC to MIDI的转换软件，将OSC信息转换为音乐软件或硬件可以识别的MIDI信息。

下面这段视频就演示了iPad把Pianist Pro应用发出的OSC信号通过WiFi发送到一台电脑，电脑再将其转换为MIDI信号通过USB传输到Novation X-Station 25合成器来发声。

Line 6 Mobilizer：

用Camera Connection Kit还是有一些局限性，就是你只能连接带有USB接口的MIDI设备，而大批早期制造的老设备是没有USB接口的，那怎么跟iOS设备互动呢？“WiFi-OSC-MIDI”是个办法，但你还需要一台额外的电脑来做OSC to MIDI的转换，能不能让iOS设备直接跟MIDI接口连接呢？

答案当然是肯定的，只需要购买一枚Line 6 Mobilizer即可，一头将其插到iOS设备的30针接口上，另外一头则甩出一进一出的两根MIDI线，直接连接你的任何MIDI设备就是了，异常方便。

不过由于是第三方的外设，所以系统本身不支持从Mobilizer输入/输出MIDI信号（不清楚iOS 4.2是否可以），你必须安装一个免费的MIDI Surface应用，在这个应用里你可以控制Mobilizer的工作方式。Mobilizer还提供官方的免费SDK，音乐制作应用的开发者只要使用该SDK，即可让自己的应用直接与Mobilizer协同工作。

Line 6 Mobilizer售价70美元左右，通利琴行是其代理，香港只卖到500港币，我去买的时候他们还特意给我打了8折，400港币拿下，合人民币仅有343元，绝对的超值。

下面可以看看Mobilizer的宣传视频：

目前支持Mobilizer的应用包括：

• MIDI Memo Recorder
• MIDI Surface
• S1MIDI Trigger:
• Little MIDI Machine
• MIDI Live
• Pianist Pro
• bs-16i
• NLog MIDI Synth
• NLogSynth PRO
• Music Studio
• NanoStudio
• StepPolyArp

iConnectMIDI：

iConnectMIDI可以看作是一个专业版的Mobilizer，它也是跟Mobilizer类似的原理，但具备外部供电能力，提供两进两出的MIDI接口。最重要的是，它符合CoreMIDI标准，就是说你不必跟Mobilizer似的启动一个单独的应用，或等待那些音乐制作应用去单独支持Mobilizer，就可以使用──只要音乐应用都支持CoreMIDI即可。

iConnectMIDI最大的问题是，你不知道什么时候可以买的到。这是一家新公司，只在今年1月的NAMM展会上展示了一下他们的产品，而且看上去外观设计毫无感觉，像一块板砖。

iConnectMIDI演示视频见下：

DIY：

DIY达人们甚至可以自己制作iOS输出MIDI的转接头。你需要准备一根MIDI线和一根小四芯音频线，将它们嫁接在一起（电路见上图），就是说一边是MIDI的莲花头，一边是小四芯的头，将小四芯接头插到你iPhone的耳机输出接口上，另外一边的MIDI莲花头则插到你任何音乐设备的MIDI输入接口上，配合HMB-TEC Midi Controller这个iPhone应用（已经降价到0.99美元）就可以直接在这个软件里控制iPhone输出各种MIDI信息了。

HMB-TEC Midi Controller这个应用可以发送预先编辑好的MIDI音序，而你可以在这个软件里自己编辑MIDI音序，并存储下来，一键触发。不过软件并没有图形化的MIDI音序编辑界面，你得手写代码，囧。

有了对外部音频和MIDI设备CoreAudio和CoreMIDI的支持，你还敢说iOS设备不是一台适合做音乐的“电脑”吗？

Via CreateDigitalMusic 1、CreateDigitalMusic 2 and Synthtopia

这个数字是今年 3 月份调查时的两倍，是今年年初时的 5 倍。这或许表明，苹果在推动 HTML5 视频被采用方面的努力起到了不少效果。兼容 HTML5 的网页视频可以在不支持 Flash 的 iPhone 和 iPad 上直接观看。

MeFeedia 表示，移动互联网是带动 HTML5 视频增长的主要原因，兼容 HTML5 的视频格式（主要是 H.264 ）是 iPhone 、iPad 和 Android 上的常用格式。现在，很多内容出版商和平台服务商已经提供 iframe 嵌入，它可以根据访问设备的不同动态地切换播放器。MeFeedia 的调查基于对主流的 33000 家出版商和视频网站，包括 Hulu 、CBS 、ABC 、YouTube 和 Vimeo 等。

其中 YouTube 早已支持 HTML5 ，可以在 iPhone 和 iPad 上直接观看。如果你经常有在 Mac 上用 Safari 翻墙观看 YouTube 的爱好，这里有一个 Safari 扩展，叫做 YouTube5 Safari Extension ，它的原理类似于将你的 Safari 浏览器模拟成为 iOS 版本，就像 iPad 的 Safari 浏览器，这样当你打开 YouTube 时它就不会载入带有 Flash 格式的视频，而是完全的 HTML5 视频。

这样，你的 Mac 就不会因为看几个 YouTube 视频而风扇狂转了（降低了 CPU 使用率）。另外，这个扩展还有另一个好处—— YouTube 在 HTML5 视频中是不显示广告的，相当于帮你除去了广告干扰。附带一句，如果你发现无法观看 YouTube 高清视频，请在 Safari 扩展设置面板中设置默认的最大视频格式大小。

• FaceTime 只做视频聊天，不做文字。
• FaceTime 没有相互的好友关系，不需要对方验证（类似于 Email 和电话系统），只要知道对方的 FaceTime ID （电话号码或邮件地址）就能发起通话。

除此之外，FaceTime 还有一个杀手级的功能：所有传统即时通讯（IM）集成的视频通话功能都要一个前提——两个人需要同时登录一个 IM 并且知道对方在线。以往想用 Skype 视频聊天的时候，总是先发一条短信告诉对方上线，然后才可能使用。

但 FaceTime 不需要，只要一方发起呼叫，对方就能收到 FaceTime 的提醒铃声（当然了，需要有网络环境）。不仅在 iOS 设备上如此，就算是 Mac 上用户都没有开启 FaceTime for Mac 应用，只要有人呼叫，你的 Mac 便会自动启动 FaceTime for Mac ，并发出提醒铃声。

（图：苹果在 FaceTime for Mac 的介绍中写到「你的 Mac 铃声响了」。）

FaceTime 仅仅为用户省去了几个简单步骤，但易用性一下子就增强了很多。你可以想象一下，当你向父母解释如何用 FaceTime 的时候，「就像电话一样，只管呼叫或接听就好了」，他们很容易就明白了。但如果他们不太懂电脑，你向他们解释如何使用 Skype 或 QQ 视频恐怕要花费一番功夫了。

但 FaceTime 是如何实现「即便没有开启软件，也照样能收到信息」的呢？在 iPhone 4 或新的 iPod touch 上 ，它是通过 iOS 的通知推送（Push Notification）实现的——只不过不是一个弹出的小气泡。

但 Mac 电脑上的 FaceTime for Mac 呢？

一个德国的博主对 FaceTime for Mac 的软件包进行了分析，发现苹果已经将 iOS 的通知推送（Push Notification）功能引入到了 Mac 。

在 FaceTime for Mac 安装文件中有一个叫做「apsd-ft」的文件，它的文件名很可能是「Apple Push Service Daemon – FaceTime」的缩写，即「苹果推送服务后台程序 – FaceTime」（下图）。

苹果的技术支持论坛里也有用户反映，在试图卸载 FaceTime for Mac 的时候遇到了 Mac OS X 的提示 FaceTime for Mac 仍然「正在使用」，虽然此时 FaceTime for Mac 并没有开启。但在终止了「apsd-ft」的程序进程之后，卸载就能顺利完成了。

这表面，苹果确实将 FaceTime for Mac 的推送服务作为一个后台程序，一直在 Mac OS X 中运行，一旦有检测到有人呼叫就会发出提醒。

考虑到 Mac OS X 和 iOS 在 Lion 版本中更深入的整合，Mac OS X 的通知推送功能会不会应用到更多的 Mac 程序中呢？

Mac App Store 刚刚宣布不到一天，App Store 上的著名游戏 Flight Control 的开发商 Firemint 已经宣布，将推出 Flight Control 游戏的 Mac 版本，通过 Mac App Store 来销售。

iPhone 开发者们或许该感叹一下，乔布斯对他们不薄，当 iPhone 和 iPod touch 的市场接近饱和的时候，乔布斯给他们带来了 iPad ，现在乔布斯又给他们带来了 Mac 这样一个平台。用了三年时间，iOS 设备的总共销量达到了 1 亿台。现在乔布斯来一个决定，立马又增加了 5000 万台终端数量 —— Mac 电脑。

Mac 拥有更大的显示屏、实体键盘和鼠标、多点触摸板——剩下的就看开发者的想象力如何施展了。苹果完善的销售和支付体系，或许将再次创造一些开发者的致富神话吧。相信已经有开发者在认真思考 Mac App Store 这个全新的平台了。

Mac 机器上的游戏或许也会因此进入一个辉煌的时期？

另外一点在于，Mac App Store 或许也将改变传统的捆绑软件分销方式——下面的这张截图暗示，苹果很可能会将目前的套装软件 iLife 分拆成为数个单独的软件，如果你只需要 iPhoto ，则单独购买即可，无需为你几乎不用的 GarageBand 付费。反之，专业的视频剪辑用户也可以只购买 iMovie 这一款软件。

这同样也适用于 iWork 办公软件套装，就像它们的 iPad 版本已经在 App Store 单独销售那样。分拆销售更符合用户的意愿。

文/ Tim Bao

布丁达人是一款定位为中国的本地生活类信息的聚合以及同城交友的一款免费软件。开始做布丁达人其实仅仅是发现随着移动互联网的兴起，人们的第一需求就是找身边的一些基本生活信息，比如电影、演出、美食、团购等。于是乎，我们团队简单的讨论了下，就先从最基本的需求做起了。

我们团队里几个都是做 Android 出身的，没人懂 iPhone 开发怎么玩，所以最开始在讨论做不做 iPhone 版的过程中一直在纠结。最后觉得是说 iPhone 的用户其实都很潮，应该是典型用户，所以还是搞出几个人从零开始学习，买 Mac Pro，买 iPhone ，一个字，做。

所以这里是你设计的产品本身是哪一类人群的问题。我简单的感觉是 iPhone 用户都比较潮，比较有消费力，而且有那么点意见领袖的味道；而 Android 目前基本上还是 IT 圈子在玩，我身边似乎都是程序员在玩 Android，所以二者适用的类型不尽相同。

举例来说，生活类服务应该属于通用需求；而交友类虽然属于通用需求，但是 Android 用户 iPhone 用户的交友类需求可能是不太一样的，一个是比较闷，一个是比较活泼，这也许会影响你产品本身的设计等。

不过 iPhone 开发似乎也没有想象中那么难，实际上我们也就是一个专职的 iPhone 前端开发加一个后台，一切从零开始一个月也基本上把 Android 版的大部分功能移植过来了。不过 iPhone 开发在很多细节上确实让我们遇到了问题：最大的就是UI规范上。我们的 UI 都是按照Android UI 出的，可是 Android 和 iPhone UI 差得还真是挺远，想统一基本是没办法了，而且 iPhone 4 之前的版本都是单进程，会让很多调用比如看地图只能跳出程序外，或者就自己写个 view 来包一张地图。这里还有一个小 tip：我们在提交苹果审核时有一次被打回来，说是某个按钮点击无反应，的确这个按钮当时没怎么仔细看就放上去了，想做一个 title 来提示界面的，这让我感叹苹果审核的严谨啊……所以这里有一个很大的建议：大家应该去把苹果 UI 规范先好好拜读一遍，先了解人家的游戏规则再跟人家玩。

我们 iPhone 上的 1.0 版本就是只有找活动: 电影、美食、演出，原因是因为这块的数据我们可以从合作方那边拿到，目前是支持全国大部分城市的，没办法，从已有的资源做起嘛。不过在 mtime 不能用的今天，这里的看电影功能还是不错的。

不过在不断开发的过程中，我们发现其实很多人有交友类的需求，但我们觉得现在很多交友很无聊，应该把有共同活动兴趣和想法的人配在一起，让你可以找到更多志同道合的人。于是我们在 iPhone 1.1 版就把身边同趣功能做进去了。目前还比较初级，未来会逐步强化。

很多人找活动的同时愿意把这个意愿分享出来，这往往对好友是个推荐或暗示作用，也能起到交友或者一起去玩的目的。于是我们就做了好友的活动意愿分享，比如你看到某个电影好，你就点一下「我想看」，系统就会给你同步到微博等 SNS，这样你真实的好友都会知道你的需求，也许还可以约着一起去看。这个功能在 Android 版本上有了，但 iPhone 还没有。

目前，整个团队处于紧张的开发期，希望尽快的完善同城交友的功能，让更多人可以享受到交友的乐趣，享受更丰富的活动人生。

最后，总结下，给想搞 iPhone 开发的人一些建议:

1. 其实 iPhone 开发难度并不高，而且 iPhone 不像 Android 要适配无数个版本和机型，而且 iPhone 的用户量巨大，所以有想法就赶紧来试吧。
2. 想清楚你开发 iPhone 软件是为了什么，你的产品是做什么的，用户是谁。如果你是个人开发者，想赚钱，那么做一些游戏和高端工具类软件如教育、医疗可能比较挣钱；如果你是团队开发者，那就看你团队的目标来定了。但是一定要分析 iPhone 用户的用户类型，或者多观察观察你身边用 iPhone 的人，猜测他们大概喜欢玩什么，或者拿他们的手机看一看就知道他们平常哪些软件下载的更多了，那就什么都知道了。
3. iPhone 开发前期可能得多一些成本，比如 Mac ，比如 iPhone ，所以如果是个人其实是做定位于全球的应用更能收回成本，如果是团队的话就看团队本身的目标了。
4. 开始之前先拜读 iPhone UI 规范，你会发现很多好处的。
5. iPhone 应用表面上没太多推广渠道，不过多多 Google 你会发现还是有很多奥妙在里面，不要以为丢给 App Store 就可以了，尤其是付费软件，价格策略，更新机制等都很重要。这点我也在摸索，希望有机会可以给大家总结一个 iPhone 应用推广经验
6. 最后最好用 iPhone 的 SVN 管理，不然代码丢了都不知道怎么恢复了……

iPhone 版下载链接； Android 版 APK 下载

本周的 Google Atmosphere 云计算大会上，Google 宣布 Google Docs 在线办公应用即将支持用户在 iPad 上进行在线编辑给你，同时支持的也包括 Android 手机。

在此之前，Google Docs 仅支持在 iPad 等移动设备上预览和阅读，不支持编辑功能。Google 表示，移动设备上的在线编辑功能将让人们能随时在任何角落与他人进行协同办公和文档处理。

某种程度上，Google Docs 支持 iPad 在线编辑功能也是对苹果的 iWork for iPad 版的冲击。不久前 Google Voice 应用也进入 App Store 销售 ，而 Safari 在线版 YouTube 正在增加许多比 iOS 的「YouTube」应用更强大的功能，Google 似乎正从各个方面出击，试图用自己的在线服务去取代苹果 iOS 的原生应用。

今天，Google 还更新了 iPhone 版 Google Earth ，开始支持 iPhone 4 的高清显示屏。

VLC 是一款跨平台的多媒体播放器，也是许多 Mac 用户首选的媒体播放器，当然了它也有 Windows 版本。

两周前 VLC 开发团队 Applidium 向 App Store 提交了 iPad 版 VLC 播放器，今天这款媒体播放器正式进入 App Store 供用户免费下载（App Store 链接）。

得益于宽大的触摸屏，iPad 是一款很不错的视频观看设备（除了有些重之外）。但目前很多用户很少通过 iTunes 向其中的「视频」应用导入电影或视频短片观看，主要是因为 iPad 的自身「视频」应用支持的格式较少，仅.mov /.mp4 /.m4v 等几种格式。虽然可以通过 QuickTime 、 iMovie 或其他专业软件进行视频格式转换，但都比较麻烦，普通用户用的不多。

因此 iPad 用户或许可以尝试一下 VLC 媒体播放器，它支持绝大多数视频格式，并且可以在 iPad 上播放高清视频。导入视频，之需要在连接到 iTunes 时将媒体文件托拽添加到该播放器资料库中。

如果你已经试用过，不妨在留言中分享你的使用体验。

iOS 4.1 主要提供了一以下部分功能：

• Game Center ：基于 App Store 的社交游戏中心，可让寻找或匹配多个玩家进行对垒或共同进行游戏（iPhone 3G 暂不支持该功能）；

• iTunes TV show 租赁：支持 iTunes 99 美分电视剧集租赁，以上款型全部支持；

• 集成 iTunes Ping ：以上款型全部支持；

• HDR 拍摄模式：详细，仅限 iPhone 4 ；

• 高清视频上传：可直接将 iPhone 拍摄的高清视频上传至 YouTube 和 MobileMe ，仅限 iPhone 4 。

需要升级的用户，将自己的设备连接至 iTunes 后点击「检查更新」，即可下载安装更新程序。

在前两天的苹果发布会上，史蒂夫·乔布斯展示了 iOS 4.1 里的一个功能──「HDR」(High Dynamic Range, 高动态范围) 摄影模式 (在官方网站上你可以看到简单的解释)。这让 iPhone 4 在手机拍照领域几乎达到了「傲视群雄」的地步。

许多 Photoshop 爱好者对「HDR」这个字眼并不陌生。在 Flickr 上搜索「HDR」，你可以看见许多颜色极度绚丽以至于「超现实」的PS作品。但是，苹果在手机上用「HDR」技术并不是为了实现这种光怪陆离的效果。

先解释一下「HDR」的基本原理：对相同的景物拍摄3张照片，分别是 1) 正常曝光、2) 曝光不足、3) 曝光过度，然后将3张照片进行拼合(详情可见wikipedia)。因此，在正常照片 (或者说「标准动态范围的照片」) 上原本应该是「高光」或者「黑死」的部分也被还原出来，丰富了照片的细节，扩大了「动态范围」。

苹果很聪明地将「HDR」这个少数人的玩具变成了一项大众化的功能──既然在「细节正常」的相机图片上使用「HDR」技术可以制造「细节过度」的图片，那么，在「细节欠缺」的手机图片上应用「HDR」技术就可以制造「细节正常」的图片。

在将 iPhone 4 升级到 iOS 4.1 开发者版本之后（公开版本将于9月8日发布），我们对「HDR」摄影模式进行了简单的 A/B 对比。iOS 4.1 支持同时保存「HDR模式」和「普通模式」两张照片，所以照片是同一时刻拍摄的。

这是一个很常见的场景：办公室。按理说，光线并不复杂，但是你也能看到明显的区别。「HDR」让办公室里墙上和桌面的高光部分得到了更好的还原，你甚至可以看见屏幕上更多一些的细节(虽然没有那么明显)。

这是一家商场的外部。使用「HDR」模式拍摄的照片，记录了商场内部和外墙上的更多细节。

这是手机摄像最容易「露怯」的一种情况：室内外高对比+大范围逆光。在大多数手机上，你只能选择室外或者室内的景物，而不可能两者兼顾。「HDR」非常好的解决了这个问题，用软件的方法让照片几乎达到了一台普通数码相机的效果 (当然你别指望能媲美单反相机)。

拍摄人像，手机最常用的功能。「HDR」对于人物皮肤质感的提升非常明显，原本会过曝的部分都被很好的着色。这简直是80后90后居家出行必备佳品。

当然，「HDR」并非「绝对正确」的功能。如果你的光线本来就够好(比如在正面错落有致的光线)，画面中又没有细碎的高光，那么「HDR」将会导致的结果就是：画面颜色变淡，也没有更多的细节可言，照片整体层次感下降。

在评测文章的最后，对 iPhone 4 做一下个人角度的评价。对比于 iPhone 3GS ，这台 iPhone 4 的真正飞跃除了「视网膜显示屏」，就是那颗画质飞升的摄像头。重点是「画质」，而非「像素」。在以「分享」为核心的手机摄影中，前者比后者重要得多。而「HDR」技术的加入，让 iPhone 4 成为一台非常杰出的相机。

最好的相机，正是你能够随身携带的那一台。

苹果已经放出了 iTunes 10 下载，请点击这里转到下载页面。

安装 iTunes 10 后，即可登录体验苹果的 iTunes Ping 音乐社交网络服务。

下周三苹果的发布会上，除了 iPod 系列和 Apple TV 的硬件产品升级换代，软件或许也将成为亮点，有传闻称苹果可能会推出新版 iLife 软件套装和全新的基于网页的轻量级 iTunes Store 。

关于新版 iLife 的推测，主要是基于该软件的更新周期大约为 18 个月，上一次 iLife 的重要升级还是在 09 年初。此前，曾有消息称，新版 iLife 将完全剔除 iDVD 程序，并对 iWeb 进行重大升级，还将增加一款“神秘”的未知软件。但考虑到此次发布会的主题仍是音乐和娱乐产品，新版 iLife 出炉的可能性或许并不大。

然而，每年 9 月新一代 iPod 的发布都会伴随着 iTunes 软件的重大升级。今年最大的变化，可能是苹果将推出完全基于网页的 iTunes Store ，这或许是 iTunes Store 自 2003 年上线以来最重要的一次变化。

事实上，关于 iTunes Store 走出封闭的 iTunes 客户端，成为基于浏览器的互联网的一部分，已是公开的秘密。今年 2 月我们就曾介绍过这一变化：苹果悄悄推出的 iTunes Preview 以及收购网页流媒体音乐公司 Lala 都是在为 iTunes Store 的网页化做准备。

但网页版 iTunes Store 的真正意图是什么？之前的许多猜测是，苹果将重点提供基于云端的在线流媒体播放服务，毕竟苹果已经在兴建自己的大型服务器中心。

但本周 All things digital的作者彼得·卡夫卡(Peter Kafka)与唱片公司高官进行了谈话，唱片公司方面表示「苹果还没有与唱片公司就提供流媒体服务所必须的相关授权进行磋商」，这意味着苹果可能暂时还不会提供流媒体播放服务。

但即便没有流媒体服务，这位唱片公司的高官仍然同意，下周三的苹果发布会上 iTunes 将有重大更新。他提示应该「Think social, not streaming」，即朝着「社交功能」的思路去猜，而不是「在线流播」服务。

「因为即便是苹果的合作对象，苹果也有可能会玩游戏、放烟雾，所以与我谈话的这位高官也只能基于信息进行判断。这么说吧，这位唱片公司的消息源告诉我，他预计于下周将有一款轻量级的、基于网页的 iTunes Store 版本出现。这个版本将设计的更容易与其他互联网服务进行同步，让顾客能更容易地与朋友们分享自己的音乐品味（不仅包括歌曲）」，彼得写道。

当前 iTunes Store 顾客浏览和下载歌曲都需要通过 iTunes 客户端，网页版 iTunes Store 能让更多用户从浏览器进行访问和操作。苹果还可以让 Twiiter 或 Facebook 等社交服务直接链接到 iTunes Store ，让朋友之间分享推荐或歌曲列表等，这可能会带来一些有趣的事情。

本周四，苹果放出了 iWork 9.0.4 更新，除了修复 Pages 、Keynote 和 Numbers 的细节漏洞，主要为 Pages 新增了 ePub 电子书格式导出功能。

对于那些手头有大量电子文档的 iPad 用户，或升级到 iOS 4.0 的 iPhone 用户，都可以使用该功能方便地制作标准 ePub 格式的电子书，方便自己随身阅读。

您可以通过系统的「软件更新」查找该更新，更新后 Pages 的「文件」-「导出」中已增加了 ePub 选项（下图）。

不得不承认，这是一个激进的想法，但又非常地合乎逻辑。今年上半年苹果申请了一个专利，它的初衷或许很简单——制造一台可以用触摸屏操作的 iMac（见下图）。

一台常规的 iMac ，运行的是 Mac OS X 操作系统，通过键盘和鼠标来进行操作。如果为 iMac 添加了触摸屏，那么不可避免地 Mac OS X 操作系统的界面需要进行修改，才能适合手指的触控操作。苹果想了一个更聪明的办法：

当用户在用键盘、鼠标进行操作，iMac 就运行 Mac OS X ；

如果用户用手指进行触摸操作，iMac 就自动切换到 iOS 模式，直接使用 iOS 操作系统。

这个想法令人叫绝，但仔细一想 iOS 不也正是为触摸屏而优化的 Mac OS X 吗？上图中，当 iMac 的屏幕竖起时，仍是一台普通的 Mac ；但只要将 iMac 的屏幕放平缓，则机器自动切换到 iOS 模式，操作系统的界面会变成适合手指触摸的元素，见下图。

你或许已经等不及想要买一台这样的 iMac 了。但如果告诉你，有这样一台 MacBook 笔记本，它可能会像 MacBook Air 那样轻薄，开启屏幕后它就是一台工作用的笔记本。但只需将屏幕旋转一下，正面朝上，它立刻变身为一台 11 英寸触摸屏 iPad 。

你会怎么想呢？

没错，这也在苹果的这份专利档案之中（下图）。

浏览器能够做什么？查邮件、看视频、在线 Office 办公，这些都是线上软件目前能做的不错的，但还能否做的更多呢？这也是这两天「Web 死或不死」的讨论核心之一，即移动互联网上浏览器能不能提供不输于本地应用的体验。

目前看来，本地应用对比线上软件可能有着更多的优势，所以会有「浏览器已死，Web 只是在进化」的看法。但在 Google 看来，浏览器都不会死。浏览器仍有十分巨大的潜力，至少玩一些像植物大战僵尸这样的游戏是没问题的，而且未来 PC 和平板上 Web 仍有很大的空间。

根据 Google 的计划，今年 10 月份将正式上线 Chrome Web Store，一个基于 Chrome 浏览器的 Web 应用商店。开发者可使用 Flash、HTML 5/JaveScript 和 C++ 语言来为这个线上软件商店编写应用。

Google 表示,整个线上应用从创建、封装、上传和发布的过程都十分简单，快速。而且浏览器仍然有许多独到的优势，比如多标签页、即时安装和关闭、全屏浏览等。

最重要的是，Google 为 Chrome Web Store 创建了一套自己付费和销售体系，并且 Google 只从开发者的应用销售收入提成 5% 的象征性“手续费”。绝大多数利润都归开发者所有。这是否会让 4399 这样的游戏站紧张起来？

最后，归根到底线上应用究竟能达到怎样的效果，Google 也举了几个例子：

1、前段时间很受关注的，完全用 CSS 完成的 Twitter「Fail Whale」动画，点击这里可以看见。

2、Google 自己的尝试，当然是 PAC-Man Google doodle ，你可以访问这里继续玩这个游戏。

3、当然了，目前最多的还是 Flash 游戏。

当我按照上面图片中 Chrome 地址栏里的地址，一个个字母敲出下面这个链接：

http://www.popcap.com/prettypkg/games/pvz/flash/1033/pvz_9_15.swf

稍等了片刻之后，伴随着诡异声音的响起，我惊了！

昨天我还有些怀疑 Chrome OS 平板怎么卖出去，今天我已经想着可能自己要买一台了，如果足够便宜的话。

最后推荐阅读，之前的一个讨论：
线上软件 vs. 桌面软件

我在写「NEON on iPhone 入门」的时候，曾以为读者已经比较了解 iOS 设备的处理器知识。然而，看过网上的一些讨论，我才发现，原来这些知识并不普及，我的错。此外，我觉得了解这些东西对 iPhone 编程有益（不仅仅针对喜欢 NEON 的人），即便你用的是 Objective－C，虽然，不了解也无碍工作，但这些知识会让你成为一个更好的 iPhone 程序员。

基础

到目前为止，所有的 iOS 设备都使用 ARM 结构处理器，它和台式机上的 x86 和 PowerPC 有些不同，然而绝对不是「特殊」或「小众」的产品。几乎所有的手机（不只是智能手机）都基于 ARM，例如几乎所有的 iPod，几乎所有的 MP3 播放器，PDA 和 Pocket PC 更不用说了。任天堂从 GBA 开始转入 ARM，它甚至还侵入图形计算器的地盘，出现在一些德仪和惠普的计算器中。如果你还想继续溯本逐源，那么牛顿用的也是 ARM（苹果是 ARM 的早期投资者）。而且上面只说了一些小玩意，还有无数的 ARM 处理器运行在嵌入式系统中。

ARM 处理器因为低功耗和小尺寸而闻名，它的性能在同等功耗的产品中也很出色。这种结构（至少在 iOS 平台）使用小端（Little-endian）排序，就像 x86。它和 MIPS、PowerPC 一样，属于 32 位 RISC 结构。请注意，模拟器并不运行 ARM 代码，软件会被编译成 x86 可以运行的指令。因此接下来的内容适用于目标设备，而非模拟器。

ARMv7，ARM11，Cortex A8 和 A4，天哪！

多年来，ARM 结构演化出几个不同的版本，每一版都增加了新指令，在提升的同时保持了后向兼容的能力。初代 iPhone 使用了 ARMv6 结构的处理器（ARM 第六版的简称），而最新的 iPhone 4 支持 ARMv7。所以，编译代码的时候，依目标版本的指令集不同，生成不同的指令。汇编程序也一样，代码中使用的指令必须兼容特定的版本。最后，生成机器码，对应 ARMv6 或 ARMv7（或者 ARMv5 和 v4，不过 ARMv6 是 iOS 开发的底线，所以这两者就不用考虑了）。目标文件和可执行文件有标注自己对应的版本，可以通过运行 otool -vh foo.o 来查看。

不过呢，「初代 iPhone 4 搭载了 ARMv6 处理器」这种说法是错误的，因为 ARMv6 不是指特定的处理器，而是处理器可以运行的指令集。初代 iPhone 使用了 ARM 11 核心（确切说是 ARM1176JZF－S，不过这不重要，只要记得它是 ARM 11 家族的成员就行了），正如刚才提到的，这款处理器采用 ARMv6 指令集。之后的 iOS 设备仍采用 ARM11，直到 iPhone 3GS 发布，苹果开始尽数转向 Cortex A8 处理器核心（尽管尚不确定，但 iPhone 4 很可能用的就是 A8 ）。这个核心采用了 ARMv7 指令集，或这么说，它支持 ARMv7。

我已经说过，不要在程序里植入设备判断代码，然后通过已知信息侦测设备所支持的 ARM 结构。这种代码极不可靠，而且运行在（软件完成后才发布的）新设备上会导致中断。所以请别这么做，否则我发誓，我会跑到你家里废了你。以上知识是为了让你粗略了解，有些设备支持 ARMv7，有些设备支持 ARMv6。至于如何侦测，我马上会谈到。

不过，你可能会想「iPad 和 iPhone 4 用的是 A4，不是 Cortex A8 吧？」不然，A4 其实是一个完整的单片系统（SOC），其中不只有 Cortex A8 内核，还包括了图形硬件、音视频编码加速器和其他数字模块。单片系统和处理器是两个很不相同的概念，处理器在硅片上甚至不占主要空间。

如果不懂得如何利用，即使设备支持 ARMv7 也无济于事。当然应用新的指令集也没有问题，但如果总是这么做，早先的设备就无法运行你写的代码了，我猜，这也许不是你想要的结果。那么，应该如何侦测设备所支持的结构呢？— 只有确定它是否支持 ARMv7 才能好好利用啊。答案是：没必要知道。相反，把代码编译两次，一次针对 ARMv6，另一次针对 ARMv7，接着把这两个可执行文件打包成一坨肥硕无比的二进制文件。好了，运行的时候，设备会自己决定打开哪一个更好。是的，Mach-O 不仅可以用来组合完全不同的 CPU 结构（例如 PowerPC 和 Intel），或者相同结构的 32 位和 64 位版本，它还可以对付同一种结构的 2 个变体，用 Mach-O 的术语来说，这叫 CPU 子类。从程序员的角度看，这么做的结果是：编译时决定一切。针对 ARMv6 编译的代码只运行在 ARMv6 设备上，同理，针对 ARMv7 编译的代码只运行在 ARMv7（或者更好）的设备上。

如果你读过了我写的 NEON 那帖，你也许会记得我推荐过一种在运行时（Runtime）中侦测和选择结构的方法。如果再去看，你会发现我已经把那部分移走了，现在，我不建议那么做，因为虽然这的确有用，但不能确保（或者说，所需技巧太复杂而不能确保不出错）在将来的 ARMv8 处理器上能够稳定运行。文档中是否有相关 API 的状态不重要（不在 iOS 的手册页中），如果你想在 ARMv6 上运行又希望利用 ARM7v，就用我刚才讲过的办法。

补充一点：在 iOS 环境下，ARM 结构不一定能反映处理器的型号。例如，对应 ARMv6 的 iOS 代码需要浮点指令的支持（VFPv2，准确的说），对 ARMv6 而言，虽然这是可选项，不过自从第一代 iPhone 发布以来就已经存在。所以，如果在 iOS 开发（例如编译器 -arch 设置或一个可执行文件的 CPU 子类）中提到了 ARMv6，就表示需要硬件浮点的支持。这对 ARMv7 和 NEON 也一样：虽然 NEON 实际上是 ARMv7-A 配置的一个可选项，但是因为它出现在所有支持 ARMv7 的 iOS 设备中，所以，提到 iOS NEON 即部分提到 ARMv7。

条件执行

ARM 结构一个实用的功能是，大多数指令可以有条件地执行 — 如果条件不满足，则指令无效。这可以缩短过程，让区块（Blocks）部署地更为有效。通常的办法是，如果区块不符合条件则跳过，但是通过把判断指令植入块内，省去了该步骤。

如果这仅仅是编译器用来提高代码效率的手段，我就不会在这里提到它了。虽然，这的确是它的一个功用，但之所以提到是因为，在调试（Debugging）时，它可能会令人吃惊。事实上，有时你会发现，调试器会进入状态为假的条件区块（if block，例如早期的错误回报），或者进入 if-else 的两个分支。这是因为，虽然代码尽数经过处理器，但是一部分没有实际执行，即条件执行。另外，如果你把断点置入这样的条件区块中，即使状态为假，它仍有可能执行。

话虽如此，但是在我有限的测试中，编译器似乎拒绝在调试配置中生成条件执行指令。因此它应该只发生在调试优化后的代码的时候，不幸的是，有时候你没得选择，只能这么做。

Thumb

Thumb 指令集是 ARM 指令集的一个子集，经过压缩，因此指令只有 16bits（所有 ARM 指令的大小都是 32bits，它仍然是 32 位结构，只是占用的空间少了）这不是一个全然不同的结构，而应将其视作常见 ARM 指令和功能的缩写。它的优点，显然是大为缩小代码尺寸，节约内存和缓存，以及代码带宽。虽然更适用于内存紧张的微控制器型应用程序，但是在 iOS 设备中，它仍然有用处，也因为如此，Xcode 默认在 iOS 项目中打开这项功能。虽然代码尺寸因此减少很多，但是不可能达到 50%，因为有时候完成一个 ARM 指令需要对应的两个 Thumb 指令。ARM 和 Thumb 指令不能随意混合，处理器需要针对二者切换不同的模式，而这只能在调用或从函数返回时发生。

当目标平台是 ARMv6 的时候，编译 Thumb 指令面临着很大的权衡取舍。ARMv6 的 Thumb 代码可以访问的寄存器较少，缺乏条件指令，特别是，它不能使用浮点硬件，例如浮点加法、减法、乘法等等。使用浮点 Thumb 代码必须调用系统函数，没错，听起来就像速度很慢的感觉。基于这个原因，针对 ARMv6 时，我建议禁用 Thumb 模式，但倘若你执意如此，请确保先分析代码。如果某些部分速度很慢，至少先试着禁用那部分 Thumb（很容易，在 Xcode 中使用命令行参数， -mno-thumb）。请记住，浮点运算在 iOS 中非常普遍，因为 Quartz 和 Core Animation 使用浮点坐标系统。

当目标变成了 ARMv7 的时候，所有这些缺点就消失了：ARMv7 包含 Thumb-2，它是 Thumb 指令的扩展集，增加了条件执行和可以访问所有 ARM 寄存器以及硬件浮点与 NEON 的 32 位 Thumb 指令。用 Thumb-2 缩减代码的代价几乎没有，所以最好是开着（如果关掉了请重新打开）。在 Xcode 的条件生成选项中，对 ARMv7 打开，对 ARMv6 关闭。

你也许在网上听到人们说，代码需要「互通」（Interworking）才能使用 Thumb，除非你想写汇编代码，否则不必担心，因为 iOS 平台的所有代码都是互通的。当显示汇编的时候，Shark 可能难以判断函数是 ARM 还是 Thumb。如果你看到无效或无意义的指令，最好互相对调一下。

对齐

iOS 支持非对齐访问，然而比起对齐访问，它的速度更慢，建议不要使用。在某些特殊情况下（涉及加载/存储多个指令，如果你有兴趣的话），非对齐访问的速度可能比对齐访问慢上百倍，因为处理器无法处理，而且必须请求操作系统的协助（参考此文，这和 PowerPC 上导致非对齐双精度浮点数变得超慢是同一个现象）。所以，要小心，而且，对齐仍然重要。

除法

这家伙总让每一个人吃惊。打开 ARM 结构手册（如果你还没有，请看「NEON on iPhone 入门」的结构概览那节），找到整数除法指令。去吧，我等你。找不到？正常正常，根本没有的。是的，ARM 结构不支持硬件整数除法，必须通过软件执行。如果你编译下面的代码：

int ThousandDividedBy(int divisor)
{
    return 1000/divisor;
}

在汇编代码中，你会看到编译器插入了一个调用函数的「___divsi3」— 这是一个系统函数，用来执行软件除法（注意，除数不能恒定，否则除法可能会被转换为乘法）。这意味着，在 ARM 上，整数除法实际代表了操作系统的性能。

「不过，」看完手册归来，你也许会说：「你错啦！里面有 ARM 除法指令，甚至还有两个呢！在这里，sdiv 和 udiv！」不好意思给您颇凉水啦，这些指令只可用于 ARMv7-R 和 ARMv7-M 配置（分别指实时和嵌入式环境 — 例如马达的微控制器和手表），iOS 设备用的 ARMv7-A 不支持，很抱歉！

GCC

GCC 生成的 ARM 代码质量之糟已不是秘密。在其他一些基于 ARM 的平台上，专业开发者使用 ARM 自家提供的工具链 — RVDS。不过，RVDS 不支持 OSX 用的 Mach-O 运行时，只支持 ELF 运行时，所以在 iOS 平台上没辙。但至少还有 GCC 的替代品，比如现在可以用 LLVM。虽然我没怎么测试，但是当使用 LLVM 的时候，至少看到了 64 位整数码的显著改进（这一点，GCC 在 ARM 上尤其弱）。假以时日，LLVM 全面超越 GCC 可以指望。

你瞧，现在你是更好的 iOS 开发者了！

[原文链接；作者： Pierre Lebeaupin]

据一些 iPhone 3G 用户的反馈，当升级至 iOS 4 后，手机的运行速度变得非常缓慢，几乎达到无法使用的程度。RoughlyDrafted Magazine 网站提供了一个解决的办法：执行一次深度重启。

也许多数用户认为，长按电源键，当屏幕出现红色滑槽时关机，然后再按安电源键启动手机，就算我们理解中的「冷启动」。其实不然，这么做对改善系统的性能无益，因为，这个过程有一点像「休眠」操作：关机后 iPhone 把下次启动所需的系统资源写入闪存，重启后，系统仍然维持关机前的状态。

因此，为了清除系统中多于的资源，必须同时按住电源键和 Home 键，持续约 10 秒钟的时间。此时系统直接杀掉所有进程，立刻重新启动手机。

因为不从闪存中恢复状态，深度重启需要消耗比平常更多的时间，iPhone 4 大约使用 30 秒，而在 iPhone 3G 上要超过 4 分钟（有读者反馈，第一次重启需要 2 分半钟，第二次重启为 2 分钟。）。

iPhone 3G 的处理器远逊于 iPhone 3GS，内存更只有 128MB，但经过深度重启后，速度可见显著的优化。

原文末的部分回复：

1、某些 iPhone 3G 速度并未降低，但经常遇到程序崩溃的现象，使用这种办法可以修复。

2、建议深度重启后继续按住电源键和 Home 键，然后手机会关机，此时再按电源键开机（未经证实，慎用）。

3、建议如果一次深度重启不管用，再做一次。

[原文链接；作者：Daniel Eran Dilger]

须再次说，原文有许多参考链接，有助理解内容。另外，原文的近 300 条评论值得一看，质量很高。我觉得，就正反方数量之比，Apple4us 的读者与 Ars Technica 的读者相差不大。

比以往更紧迫

哦，我知道你在想什么。你们这些 Cocoa 开发者定会认为我失去了理智。你们说：Cocoa 和 Objective-C 是苹果最叼的东西，才不是定时炸弹！而且，尽管源于 C 语言，但 Objective-C 提供了 Java 都还不支持的动态性能和语言特性，因此，说它「低级」是不公平的。还有啊，不要忘了垃圾回收机制，iOS 总有一天会支持。

无论如何，你认为，这一切都不重要。何况空谈不如实践：谁的程序更好？谁的用户体验最棒？谁赚的钱更多？而且苹果的桌面或移动平台的种种缺陷没有影响到什么嘛，看起来一切正常！

开发界有句老生常谈，在程序员中奉作经典，不妨援引：你习惯何种抽象层级的编程语言，那么这种语言就是最合适你的语言。视低级语言过于原始，高级语言臃肿耗能。在全行业抽象度愈加高耸的今日，仍是如此。

首先，如今写 C 的同学大概没人会用汇编了，但 C++ 虚表调度的速度还是太慢，难于采纳。接着，C++ 党也许会懊恼的追忆起当年是如何将他们半残的对象系统嵌入 C 中的，但他们却很鄙视 Java。再后来，Java 党开始嘲笑指针和手动内存管理，但 JavaScript 却被讽刺为玩具级的脚本语言，干一些验证网页表单的粗活。诸如此类…

在短期内，在当下，他们大多是正确的。但，这是条不归之路，而且，正指向愈加抽象的层次。下一次跨越何时到来，不妨观察业界的前缘。苹果通过 iPhone 的成功为自己争取到了一些时间，但以目前竞争之惨烈，这也许仅仅是一厢情愿。

转换之难

尽管「2010」危机没有到来，苹果最终仍需面对该问题。我关注这个问题的原因，无论在 5 年前，还是现在，都是一样的，即：开发平台很难改变。首先，选择或开发一门新语言，并为其打造一套新的 API 存在技术难题。优秀的 API 需要多年的发展和累积。Cocoa 就是个好例子。

不幸的是，寄望将现有的 API 导入新的高级语言和运行环境，并能正常工作，几无可能。转用高级语言能减少原 API 复杂度。例如：

NSInteger myCount = [[myDict objectForKey:@"count"] integerValue];
NSArray *myArray = [myString componentsSeparatedByString:@","];
myItem = [myArray objectAtIndex:i];

不可能在这样的语言环境（假设）中运行：

myCount = myDict["count"];
myArray = myString.split(",");
myItem = myArray[i];

只有新的 API 才能更好的匹配新的语言。但与下一个问题作比，这还算简单的，即：劝导开发者转向新的语言和 API 而不影响现有平台的势头。即便技术选择完全正确，开发者也愿意随你前行，平台的转换仍需花费时间与精力，无论是平台供应方，还是开发方。与此同时，竞争对手的现有平台正值壮年，它们无需为平台转移而苦恼。而且，当你正辛苦的切换平台之时，它们还能借此获得增长。

如果你只是一个普通的用户，恐怕难以理解我对此的恐慌。如果你是开发人员，就像本文开篇谈到的那样，你也许对我嗤之以鼻。没有关系。我也同意，我的诸多担忧是一种过激反应，但这恰是因为我真实的经历过 1990 年代那场伤筋通骨的 Copland 危机，并且，眼睁睁的看着苹果因此近乎覆灭。

无疑，苹果今非昔比。但是这类技术问题，无论多么艰巨，一旦无法解决或被完全忽视，那就只会引发危机。过去的十多年间，一旦苹果开始解决某个问题，它就会做的非常非常好。因此，我们有理由乐观。但并非完全如此。

了解而又热爱 Objective-C 和 Cocoa 的最大群体在苹果公司里。而这些人亦可能不那么热衷于推动新的语言和 API。再加上苹果的脾性 — 例如其对软件商店的态度 — 不管外界争议如何，只要认定是最佳做法，便会一意孤行。而且，有许多因素妨碍着苹果深入思考这个问题。

虽然微软近年来的产品线不够协调，但它有所预见并愿意解决其最深层的技术问题，值得嘉许。微软早在苹果意识到这个问题数年前就开始研究现代操作系统，因而避免了 Copland 式的危机。微软开发了 Windows NT，并通过数次更新，细细雕琢，才将 NT 推向消费级操作系统。（编者：即 Windows XP。）

即便如此，微软还是来迟了。当时 Java 已崭露头角，而微软还牢牢的固守在 C++ 阵营，但微软应变极快，投入了可观的人力与资源，推广其 .NET 虚拟机和 C# 语言以弥补差距。技术上不够自信的公司也许会选择另一条道路。它们会争辩：我的语言和 API 有其优势，没什么要改进的啦。换言之，「忽略问题，问题便会消失。」

你有多了解苹果对 Objective-C 和 Cocoa 的态度？以上这些情景会让你想起什么吗？

实际的检验，之二

再一次的，让我猜猜你的反应吧。「别用你对技术的担忧吓唬我们。」微软不是很用功吗？开发了一整套多语言运行环境，也没能帮助他获得多少移动市场的份额嘛，而且除 Windows/Office 之外，这套体系也没能助其开疆扩土嘛。说的没错。像微软这样成功解决了技术问题，并不能保证其他方面也成功，也不能保证从此稳坐泰山。

让我们回顾上一节末尾的问题：对于我们这些身在苹果之外的人，有谁真正了解苹果对 Objective-C 和 Cocoa 的态度，有谁知道他们对未来的规划？在我发表 Copland 一文不久之后，有关苹果参与 LLVM 计划的细节开始浮出水面。那么 LLVM，抑或，目前的 Clang，是苹果平台演进的长期策略吗？虽然，苹果的状况尚可，但是，为达到目标，要做的改进远比这些多得多。也许他们已经动手了，我们只是不知道罢了。

我曾经千思万想，希望苹果早日动手。如果我有具体的解决办法，相信我，定当竭力推进。但是，目前我所了解的，苹果用于保护其老旧平台技术的办法是…

你寻到 Web，他会给你自由

采用其他平台供应方的 API，就等于将命数交于他人之手，苹果不会这么做。苹果大概不能忍受自家平台构建在，由竞争对手主导开发或完全控制的程序语言之上。那么只剩两种选择：要么自己从头做起，要么寻找一个无供应方的解决方案 — 即不受任何单方的控制。

现观之，苹果似乎选择了后者，它开始大力投资 Web 技术。啊！是的，Web，无可争议的自由平台！苹果得到了 Webkit，成功打入浏览器引擎之战（至少在移动市场是这样。）并借此宣扬，这才是先进的网页标准。（尽管有时候做错了）此外，苹果在其新近的网页程序中使用了 SproutCore HTML5 程序框架，还有 PastryKit，这是苹果研发的数款网页框架之一，现已开始部署。

采用 Web 技术巧妙解决了苹果的许多潜在问题。无须推出震惊世界的程序语言和 API，苹果已将整个行业引入它的轨道中来。Web 不由任何一方控制，但苹果似乎比任何一家公司都更尽心竭力。

不幸是，这意味着，苹果仍无法掌控一切。此外，Web 技术离目前 GUI 程序的水准还有很长的距离。大多数有经验的 Cocoa 开发者非常清楚二者差距，但他们多少会觉得有些不安。

这便是，为何我认为 Web 技术只是苹果的防御手段 — 它的第二选择。但倘若我知道它的首选是什么，必定会宽慰许多。

自作自受

尽管苦闷挥之不去，Copland 2010 终究没有到来。虽如此，我仍觉得这个问题并未消失，而且随时间流逝愈加严重。当然，作为一个在 5 年前已经因此吓破胆的人，我对「紧迫」的定义很可能与你的不同。

写这些不是用来离间 Cocoa 开发者的，更遑论 Mac OS X 和 iOS 用户。我亦无心冷嘲热讽，好比说，这个平台要完蛋啦，或者这个平台就是低人一等，未来已经注定之类的。我写苹果已有多年，好处是，可以时而回顾多年前的预测，我也愿意担负责任。我最痛恨是，技术专家无挂无碍的将多年前他们的可怖禁言弃之脑后。

我也试着帮助苹果，不管是公司决策者能读到我写的文章也好，或间接鼓励开发者，让他们至少想想这个问题也罢 — 即便他们的理念与我不同。我想善意的提示所有当事人，包括苹果。即这个问题依然存在，只是潜藏而已。

最后，我得承认，我亦喜欢身处迷局。五年前，我不知苹果的未来语言和 API，今天仍是。在这样的一个世界里，我们多年的期盼一个个成为现实 — 新的操作系统、我们的苹果手机、我们神话般的平板 — 但语言和 API 继任者的问题仍顽固的存续着。这一回，我不再加入年份，但请放心，我仍将观守并等待。我只是希望我不是唯一的一个。

这是上篇，下篇将于明日发出。原文链接甚多，译文不便一一列出，见谅。

预测科技业的未来是件棘手的事情 — 不妨看看比尔·盖茨十五年前的预测结果 — 虽如此，预言的诱惑总是强烈的。我亦因此闻名。有时候我猜的挺准，2008 年时我说「苹果和 Adobe 之间只有战争。」含糊、幽默式夸张、不明确的时间表是成功预测的基本要素。

其他时候，我就没有这么幸运了。五年前，我写了题为《别在 2010 年重蹈 Copland 的覆辙》的系列文章，分三篇发出。但这一次，预测的内容既严肃又具体，而且标题中还有年份。换言之，想不失败都难了。好吧，2010 年已经来到——曾经的那个未来！——所以，是时候挨批了……或者，这可以算乌鸦嘴的胜利么？但重要的是，「Copland 2010」究竟说的是什么呢？

背景

苹果曾数次尝试开发新一代操作系统，Copland 是几个项目中最声名狼藉的一个。Copland 始于上世纪 90 年代，「新一代」是指支持内存保护和抢先式多任务，当时的 Mac OS 不支持这两项功能。从那时起，Copland 见证了苹果从近乎崩溃，到承认并及时解决其软件平台重大的技术差距。通过这次不可思议的收购 — 一款独立发展的现代操作系统、一个被驱逐的公司创始人 — 苹果得以留存下来。

在《别…》的第一部分，我提出了我的论点：Objective-C 语言和 Cocoa API 是Mac OS X 中最危险的部分，因为它们落后于竞争，而到 2010 年，苹果会发现自己面临着另一个 Copland 式的危机，因为它缺少内存托管语言和 API 。在第二部分，我详述了我的假设。分别是：

• 桌面操作系统的开发环境终将提供全自动内存管理功能。
• 到 2010 年，其他对手将会采用支持全自动内存管理的语言和 API。
• 而现有的技术（2005）与可能的演进，无法充分满足苹果对内存托管语言和 API 的需要。

这些假设受到了强烈的质疑。

在第三部分，我评述了那些有可能超越 Objective-C 和 Cocoa 的语言及 API。我也试着鼓励质疑「2010 年」的人们，观其大局。

毕竟，人人同意 Cocoa 和 Objective-C 总会过时。好吧，也许有人认为，这一天得等到 2050 年，但总有一天，对不对？用什么替代 Cocoa？有什么可以替代 Cocoa？苹果在编程语言和 API 之战中的新动向是什么？

在文章中，我认为支持垃圾收集机制的 Objective-C ，Java/JVM，C#/.NET/Mono，抑或之前苹果鲜为人知的尝试（例如 Dylan）皆因种种实际的、技术的或派系的原因，无法承此重任。那么，我认为，苹果便只能尽快并独辟蹊径的寻求或开创 Cocoa/Objective 的继任者了。

未来已至

那么，结果如何？若逐字对照，结论很明确：苹果并未经历 Copland 式的平台危机。虽然它或许处在另一类非常特殊的危机之中，不过，这是另一回事了。就华尔街的态度（以及苹果的资产负债表）而言，未来仍旧是光明的。

是我大错特错了吗？还是没有？不妨再看看我的假设。自动内存管理已经普及了吗？大多数 Mac OS X 开发者并不这么认为。Objective-C 确实加入了垃圾收集机制，苹果也很努力的推广。但是，五年前我提到的「二等公民问题」并未消散。大多数 Cocoa 开发者，包括苹果自己，在多数程序中，仍旧采用手控维持与释放式的内存管理。对时下的麦金塔开发者而言，垃圾收集并非上选，并可能危及性能。

微软在 .NET 框架和 C# 语言上使用默认的内存管理代码，其他的内存管理代码则视为存在风险，并以「unsafe」为关键字标注在源代码中。

尽管如此，开发者和用户并没有像 Copland 时代那样的恐慌。如果危机正待，那绝不是现在。这就是所谓「2010」。但仅此而已么？

未来未来

微软从十年前开始着手 .NET 的通用语言运行库。期间发布了四个主要的版本，显著拓展了 C# 的功能，亦提供了对动态语言，如 Python 和 Ruby 的支持。如果这是开发平台间的竞争，那么从技术上讲，苹果处下风。

尽管如此，开发者仍无动于衷。原因可概括为三个词：移动，移动，移动。iOS（原 iPhone OS）的崛起令人头晕目眩。在台式机上多年不见得配置重新出现：128 至 256MB 内存，1GHz 定序处理器，无虚拟内存。十几年来，苹果从没在台式机和笔记本电脑上用过这么小的内存，不支持虚拟内存？那是多遥远的事情啊（编者：1991 年 System 7 开始支持虚拟内存，作者意指，初代麦金塔不支持虚拟内存也就罢了，现在已经过去 26 年了还……）。哦，对了，iOS 不支持 Objective-C 的垃圾回收。

硬件受限，习惯了高级语言的苹果开发者必感不便，而 Objective-C 乃 C 的超集，趁此终可大显身手。当你的程序持续不断的收到系统发送的低内存警告；当你不得不与低级语言、字节级精度的指针与 C 结构打交道的时候，你怎么嗨的起来？

苹果夸大了移动设备用户界面响应能力的重要性。为维持直观流畅的用户界面，苹果无所不用其极，这招让 iPhone 脱颖而出。即使在今天，那滚动列表或划过屏幕的短暂延迟，虽然难以捉摸，却能显而易见的将 iPhone 与其他手机区分开来。内存受限，开发者虽无能为力，但似乎暗喻了畅快的界面与 iOS 原生 API 的底层特性之间的某种联系。（编者：苹果：赶快学习低级语言啦。）

实际的检验

还有一个问题。就像它在桌面端最大的竞争对手（编者：微软），苹果在移动市场中最强力的挑战者也提供了内存托管语言和 API。毫无疑问，Android 最新版的 Dalvik 虚拟机速度很快。（我曾预言寄存器型虚拟机将成主流，现在是不是能讨点赏了？）

更糟糕是，谷歌甚至利用了苹果开发多年的底层库，增强自家设备的性能，还在 Google IO 上用 Android 手机修理了一把看似无比强大的 iPad。是的，WebKit 是用 C++ 写的。这正是要点：提供高级 API 并不能阻碍高性能底层库的应用。

不仅是谷歌。微软也不出所料，推出移动 .NET 平台，并为 Windows Phone 7 增加了更高层级的语言和 API。即便不幸如 Palm，亦为开发者提供了更为抽象以及安全的开发环境。 这正是苹果所面临的竞争图景。

显然，在衡量成败方面，技术细节并非如此重要。即便 Mojo SDK 闪耀一时，也难以避免 Palm 的惨淡结局。但是，最能挑战苹果一枝独秀的用户界面的，仍然是 WebOS。谷歌仍然健在，当然，它不会好到哪去。而微软…嘿，你永远不会了解的，对不对？

个别竞争者的命运暂且不论。事实上，这些最危险的对手手中，都有领先苹果一世代的语言和 API，这才是最危险的信号。而且，这还是发生在内存食紧、处理器受限的移动世界。在桌面平台，苹果落后更多。

2010 终于来了。不管「未来」到达与否，开发者为了一个损坏的指针不断的遍历内存，多少是有些愚蠢的事情了。世界已经改变，苹果亦应顺势而为。

iOS 4 提供了应用程序文件夹管理、多任务处理和 iBooks 支持等诸多新功能，其中一个细节功能可能会影响到开发者对于其应用程序图标文件的处理。

跟 iPad 一样，iOS 4 开始允许用户自定义 iPhone 和 iPod touch 的「主屏幕背景图片」（并非锁定屏幕的图片），而在此之前 iPhone 和 iPod touch 的主屏幕背景一律是黑色的，无法更改——这也造成一些问题：许多开发者在设计自己的应用程序图标时，往往以黑色作为底色，且图标的形状并非标准的圆角正方形。

在 iOS 4 之前，这是一个很棒的办法，能够让自己的应用图标在黑色背景的 iPhone 主屏上看上去很特殊，「看上去」可以是自己想要的任何形状，「实际上」是自己想要的任何图形周围包裹着一个标准的黑色圆角正方框。

当用户自定义一张照片作为主屏幕背景，原本与黑色背景融为一体的黑色边框就凸显出来了，比如下图：

当然，这并不是最糟糕的情况，如果你的图标设计的够精致，在 iOS 4 上显示出来也顶多是一个有黑色边框的图标，就像上面的那样，也不错。

但还有不少开发者用的图标，与圆角正方形已经非常相近了，只不过仍有一些细微的差异，所以有开发者采取了「用黑色线条来压边」的办法。在 iOS 4 之前这些细节都不易被用户发现，但当用户用了自定义主屏幕图片，这些应用的图标边缘就会显现出一条明显的黑色线条，看上去不太舒服，比如下图是来自 iPad 的截图：

举例并无冒犯之意，供 iOS 开发者们参考 :)

Safari 5 主要改进如下：

Safari 阅读器：点击阅读器图标，一键将网页内容转换为简洁、整齐的文章。

性能改进：Safari 5 执行 JavaScript 速度较 Safari 4 提升 25% 。更好的页面缓存和 DNS 解析加速网页浏览。

支持必应(Bing)搜索选项：Safari 5 的搜索栏增加了微软的必应(Bing)搜索选项，此外还包括 Google 和 Yahoo! 搜索选项。

改进 HTML5 支持：Safari 5 支持 HTML5 的多种新功能，包括地点标记、全屏观看 HTML5 视频、关闭 HTML5 视频字幕、新的页面元素分割（包括 article 、aside 、footer 、header 、hgroup 、nav 、section ）、HTML5 AjAX 历史、EventSource 、WebSocket 、HTML5 托拽特性、HTML5 表格检查，以及 HTML5 Ruby 等。

Safari 开发者工具：网页检视功能增加了一个新的时间轴面板，它可以显示 Safari 浏览器如何与网页进行交互，并以最优化地方式先后识别页面的各个区域。新的快捷键使得面板间切换更容易。

此外 Safari 5 还包括以下细节改进：

智能地址栏：可自动匹配输入的文字与网页历史和书签 URL，只要与这些 URL 的任意部分相同即可识别并给出建议。

标签页设置：自动在新的标签页打开网页，而不是在新的独立窗口打开。

带日期的搜索历史：新的全历史搜索(Full History Search)增加了一个日期指示器，清晰标注该页面何时被浏览过。

Top Site 和浏览历史按钮：使得在Top Site 和全历史搜索间切换更容易。

隐身浏览按钮：点击按钮进入隐身浏览模式，智能地址栏上会有「隐身」提示。

DSN 解析：查询链接和载入网页速度更快。

改进页面缓存：缓存额外的网页样式，帮助网页更快载入。

XSS 监听：Safari 能侦测出潜在的 XSS 攻击恶意程序，提升安全性。

改进 JavaScript 支持：Safari 允许使用 JavaScript Object Notation(JSON)编写的网页应用更高速、安全的运行。

此外，据称苹果还将在 WWDC 上放出 Mac OS X 10.6.4 和 Xcode 4 。

-

WWDC 将于太平洋时间 7 日上午 10:00 由正式开幕，换算成北京时间是 8 日凌晨 1：00 钟开始，即今晚的凌晨 1：00 。一如既往 Apple4us 将直播该发布会，欢迎各位到时收看，今年的 WWDC 会给我们带来哪些惊喜。

尽管当前的 iPhone 已经可以在拍照时通过 GPS 或 Wi-Fi 记录照片的地理位置信息，但在 iPhone 上却无法查看这些信息，用户必须将其同步到桌面电脑程序，比如 Mac 上的 iPhoto 之后，通过这些程序的地点功能来查看照片的地理标签。

但在即将发布的 iPhone OS 4.0 中，用户已经可以直接在 iPhone 或 iPod touch 上查看照片的地理标签，照片将分散显示在地图的上，点击地图上的大头针将显示照片的缩略图。

而在之前发布的 iPhone OS 4 beta 3 中，苹果还暗示新的系统也将支持事件(Events)和面孔(Faces)功能，它们分别根据照片拍摄日期和人物面孔来管理照片。下图是 beta 3 照片功能底部标签的截图，但当时这些功能尚不可用。

但 iPhone OS 4 beta 4 中，「事件」和「地理标签」功能已经可以使用，「事件」功能必须在照片拍摄时间来自不同日期时才会自动启用。

但 beta 4 中的「面孔」功能却没有出现，考虑到 beta 4 仍是首次支持地理标签功能的版本，苹果可能是按顺序依次实现功能支持，这并不意味着「面孔」最终会被移除。iPhone OS 4.0 最终版本应该会支持「面孔」功能。

值得一提是，以上的地理标签、事件和面孔功能在 iPad 运行的 iPhone OS 3.2 版本中都已经实现支持，并且表现出色。此外，iPad 的照片功能还多了一个「缩放预览」(pinch to preview)功能，由于 iPhone 和 iPod touch 屏幕较小，可能暂时不会支持该功能。

[摘译自：AppleInsider]

上一个可用于麦金塔的 AutoCAD 是 R12，发布于 1992 年，目前最新的 AutoCAD 2011 已进化至 R25。AutoCAD 一贯鄙俗的命令行界面在 Mac 版上似乎有所改观，字体方面应该亦会修正 Windows 版多种字体陈杂的状态。模型（Model）与布局（Layout）之间切换标签从图纸上移到了右下角的工具栏里，我猜，是为了让图纸空间看起来更简洁，这些倒梯形标签亘古不变，丑陋至极，至少可以加个圆角改善吧。以下是安装截图。

更多截图点此。

当时这款应用的开发者格雷格·休斯(Greg Hughes)尚未向 App Store 提交该应用，经过两个星期 App Store 的审批结果出来了，杯具。雷格·休斯对 Engadget 解释了苹果拒绝理由：

尽管他们同意这个应用在技术上并没有违法 App Store 规则，但已经超出了 App Store 审批团队的审批权限。此外他还对应用的安全性表示担忧。

虽然目前无法登陆 App Store ，Wi-Fi Sync 仍然在 Cydia 上以 9.99 美元的价格销售，当然，只有越狱的 iPhone 或 iPod touch 用户可以尝鲜了。

本周三，苹果宣布推出全新测试版 MobileMe 电子邮件网页应用，邀请 MobileMe 用户试用该功能并提供反馈。 MobileMe 用户登录 me.com 后点击「获得邀请」即可收到苹果的邀请邮件，激活后即可使用全新测试版 MobileMe 电邮 。

新的测试版 MobileMe 电邮包含以下新功能：

宽屏视图和简洁视图

宽屏视图采用了与 iPad 横屏显示电子邮件时类似的设计，用户可同时看到收件箱、邮件列表和邮件内容三栏。简洁视图保留了传统的设计，用户可以看到更多的邮件内容。

邮件规则自动归类及同步

在用户创建邮件规则（或标签）后，MobileMe 会自动将符合规则的邮件归类到该标签，减少收件箱的杂乱。

MobileMe 电邮现在支持「服务器端」的邮件规则同步功能，一旦在 me.com 设置好之后，无论从 iPhone 、iPad 、iPod touch 、Mac 或 PC 访问，收件箱都会组织的井井有条。

一键归档

一键归档选中的邮件，以备日后参考。

版式工具栏

使用版式工具栏创建更好看的电子邮件，包括加粗、下划线、修改字体颜色、插入图片等功能。

性能改进

提升了电子邮件载入速度，操作更流畅。

安全性提升

采用 SSL 加密协议的  MobileMe 邮箱比以往更安全。