http://pttrns.com/

http://www.patternsofdesign.co.uk/

http://mobile-patterns.com/

专注iPhone的UI分享：

http://tapfancy.com

http://www.tappgala.com/

http://wellplacedpixels.com/

http://www.lovelyui.com/

http://buildingiphoneapps.posterous.com/

专注于iPad UI分享：

http://landingpad.org/

http://stylishipadapps.tumblr.com/

这个网站有一个iPad客户端，设计很精美：http://itunes.apple.com/us/app/stylapps/id444930066

专注于App网站设计的分享：

http://www.appsites.com/

最后推荐一个包括了图标、界面、App网站和设计资源的整合型：

http://iosinspires.me/

ps. 若上面的链接有的打不开，请自备梯子。

• app store：http://itunes.apple.com/cn/app//id495609535?mt=8
• 官网：http://www.qairapp.com/cn/

Q Air空气监测站是我年前开发的最后一个项目，也是Sumi第一个上架销售的app。经过一个多月的制作，终于赶在兔年的最后一天与大家见面了。经过短短不到一周的时间，拿下了中国区天气榜第一的好成绩。很高兴Q Air受到了用户的欢迎，这也说明我们切入的环境指数热点正是大家都非常关心的问题。我们希望把这款软件献给每个热爱生活的人，更希望中国的环境问题能够逐步得到改善。第一步当然是要督促政府从pm2.5信息公开开始做起。一旦有更多的pm2.5数据放出，我们将第一时间更新到Q Air。

附上xcode截图一张：

在此之前，我又好好读了一遍自己写的2010总结。感叹是计划不如变化，但好歹今年没有浪费时间，还是做了一点事的。

上半年大部分时间还是在上海过着深居简出的日子，一边做些小活一边学习iOS开发。期间发了一些博文，把之前积累的一些AS经验都整理了出来。这种状态一直持续到回厦门之前。我在朋友介绍下接了一个上海车展用的急活。在高强度的十几天里把一个iOS项目做完，让我又回到刚毕业时候的打鸡血状态。这个项目的完成让我消除了对iOS开发的恐惧感，并且开始享受掌握另一种面向对象语言所带来的冲击和融合。还好因为去年深入研究AS打下的基础，让我产生了一些融汇贯通的美妙感受。所以接下来我慢慢的把更多的注意力投入到这个方面。回想去年订下的HTML5为主、Objective-C为辅的计划，不禁觉得好笑。事实刚好相反，一切还是以机缘为导向。我想HTML5更多的还是大公司或者牛人的玩具，而iOS开发正是很多人赖以吃饭的技术，至少短期内如此。

下半年除开接了一个Flash开发的项目花了两三个月工作时间，其余时间都泡在Xcode里面。iOS5发布了，新的api随之而来，还有WWDC的各种技术视频，Apple这个创新的公司一点也没让开发者们闲着。再有些空余时间我就继续关注Flash平台的各种口水战。我对Adobe的3D游戏导向的相关技术没太大兴趣，对webgl和canvas绘图的各种实验性作品仍然处于仰慕的阶段。我也很喜欢这些“玩具”，可惜暂时无缘吧。

最后两个月前终于把各个freelance项目都结束了，于是有心思开始折腾自己的东西。和朋友合作了一款天气类的创意app，经过了漫长的设计和开发过程，现在也提交了第一版。这算是给自己做产品的尝试开了一个头，明年还会继续再这上面投入精力。

一直想着要正式跨过freelance，向前迈前一步。终于在2012到来的第一天，把工作室的地儿给定下来。地址选在小资到爆的中山公园一带，与众多文艺青年为伍。名字么就叫Sumi（取我名字的谐音）。明年的基调就定好是在这里奋斗着奔三。我对工作室的想法是做互动，要做慢、做精。做得像厦门的乌糖沙茶面那么跩，就开半天，卖完了关门。在这里也邀请同道中人共襄盛举：），外地的还是本地都没有关系，我向往的是依托于网络协作平台建立的轻公司模式。

在自我管理上，今年丢了两个好习惯：一个是写晨间日记，一个是记账。都因为环境变动的原因没有坚持下来，在2012要重新恢复。5月份买了iPad以来，获取信息的方式有了很大的变化。现在基本上阅读新闻和RSS都会在iPad上，因此连去看FWA的时间都减少了。根据工作和兴趣不断调整工作方式一直是我长期笃信的原则。经过大半年的调整期，终于在新年前把新的学习系统建立起来。希望2012会是更有效率的一年。

噢，其实前面说了这么多事儿都是我今年的副产品。2011年最大的项目成果是11月16日老婆帮我生的一个胖女娃：名叫曹语荞。希望她能快乐健康的成长。

最后祝各位龙年大吉，龙腾虎跃，龙马精神！继续关注Kevin Cao和Sumi^_^

• 类型：体验型
• 创意：4
• 设计：4
• 交互：4

Volvo S60（App Store下载地址）

• 类型：体验型
• 创意：4
• 设计：4
• 交互：4

这是一款产品介绍app，和同门的S80基本是一样的，都支持iPhone。在本次review中，这是唯一一个拥有加载进度条设计的app。可能是为了保障后续内容顺畅运行的原因，但我觉得在互动网站上常见的进度条在这里出现总是不太和谐。好在加载一次以后再重复打开相同的版块就不用再加载一遍，应该是做了缓存。

这堆图片是可以用多点触摸手势任意排列、缩放和旋转的，增加了可玩性。

展开文字内容后，图片自动弹开。

360度展示在交互上做出了新意：双指放大可以从相同角度切进内饰，双指缩小则切回外观。用这种更加直觉的切换方式把内外的展示结合在一起，体验上升了一个等级。

其他产品介绍走的是科技感的路线。

内置的新闻模块，需要连接网络加载，排版向iPad上的阅读软件靠齐。

经销商查询用了世界地图的呈现方式，用户要找到所需的信息非常方便。

VW Magazine（App Store下载地址）

• 类型：杂志型
• 创意：3
• 设计：4
• 交互：2

这是VW推出了一款多媒体杂志，每期会更新不同的内容。

主页完全是杂志化风格。

导航设计：

页面设计：

值得一提的是这个无网络连接的提示画面设计也很用心。

ps.本作在成文后又有所更新，可能有部分内容与截图不符。

Think Blue（App Store下载地址）

• 类型：体验型
• 创意：5
• 设计：5
• 交互：4

这是VW宣传Think Blue品牌战略的一款很有意思的app。主要用了矢量2D图形结合3D视角的设计手法，配合活泼的背景音乐，有效的传达了品牌信息。

镜头的移动用手指拨动来控制，但是程序又做了些限制，确保焦点不离开画面，操作的手感很舒服。探索到的地方2D图形会跳动着竖起来。

结语：

本次review精心挑选了App Store上各大汽车品牌的应用，从创意、设计和交互角度分析了每个应用的特点。我们看到无论是杂志型还是体验型的应用，素质都在逐步提升。随着品牌投入力度的加大，未来肯定还有更多优秀的作品诞生。虽然本次review的主要对象是国外的应用，我也顺便关注了一下国内的情况。虽然整体水平还比较落后，但是也欣喜的发现了一些有诚意的作品。目前在App Store上，来自中国的开发者数量很庞大。我期望在这个平台上看到中国互动力量的雄起。

回到设计本身，在iPhone第一代就伴随的UI标准虽然已经非常完美，但是发展到了今天难免有点过时。特别是在以设计为卖点的app上，将来一定是各种风格的UI百花齐放。Apple也一定认识到这点，为此iOS5专门升级了一系列UI外观定制的api。而在交互开发上，我更加希望看到专门为触屏设计过的体验。不要再把用鼠标的思路带过来，更多的去思考直觉化操作的方式。

最后为大家整理一下按照评分高低顺序排列的app列表，方便没时间的朋友挑选下载和研究。

• 15 CLS（下载）
• 14 A1 eCatalogue（下载）
• 14 BMW Magazine （下载 1、下载2）
• 14 Think Blue（下载）
• 13 A7 Sportback（下载）
• 12 Mercedes-Benz Magazine（下载）
• 12 Chrysler 300 （下载）
• 12 Nissan GT-R（下载）
• 12 Volvo S60（下载）
• 11 Audi 2010 Annual Report（下载）
• 11 Infiniti Models（下载）
• 10 Pure Bentley（下载）
• 10 Dodge Charger （下载）
• 10 Honda CR-Z
• 9 Mercedes-Benz 2012 CLS（下载）
• 9 BMW X3（下载）
• 9 VW Magazine（下载）
• 8 Infiniti杂志（下载）

最后的最后再把本次review所做的233张截图打包供大家下载，欢迎取用。

• 类型：体验型
• 创意：4
• 设计：4
• 交互：4

Dodge Charger（App Store下载地址）

• 类型：体验型
• 创意：3
• 设计：4
• 交互：3

本作与前一个Chrysler 300皆出自同一制作公司，所以大致的结构和一些元素的设计上都是类似的。Dodge这款车主打鲜艳的红色，一开始用了一段启动汽车的动感视频来做Intro。然后就直接进入了外观360的部分，并且把主导航直接放在了车身的对应部分。

产品点的演示和说明还是很详细的。

产品图库设计为一面红色的砖墙，呼应了这款车的整体调性。

Honda CR-Z（已下架）

这种浏览方式对画面的衔接设计提出了更高的要求。用一些标题文字来作为点缀元素成为主要的解决方式，特别是随着滚动位置而改变的文字光影效果更是出彩。

进入车内的视角时做了画面的放大处理，与水平滑动的主体感觉有些区别，但是个人感觉还是有点突兀。

Infiniti杂志（App Store下载地址）

Infiniti Models（App Store下载地址）

• 类型：杂志型
• 创意：3
• 设计：4
• 交互：4

一款介绍Infiniti全系车型的app，采用杂志式的信息组织方式，设计简洁，交互有些亮点。

导航和搜索功能：

信息展示设计：

在展示品牌书法符号的页面提供了一个书法模拟工具：

对于笔触的模拟还是挺真实的。

在撰写此文的时候BMW Magazine一共有四期，从一开始的类PDF式的简单阅读体验，一直到包含了诸多交互细节的2011夏日版。这个系列可以看成是一个新平台互动设计的发展历程，很有学习和分析的价值。同为杂志类应用，大家也可以和上一篇介绍过的Mercedes-Benz Magazine做个对比。

• 类型：杂志型
• 创意：5
• 设计：5
• 交互：4

*此分数为四期的总评分

第一期(已下架)

第一期实现了杂志浏览的基本功能：左右滑动换页和一个页面列表导航。

主浏览方向为竖向，在横向模式下，页面自动放大为屏幕等宽。同时取消了分页，把内容纵向组织在一起成为一个很长的滚动视图。但是由于内容其实都是纵向尺寸下的标准图片，放大后就会变得模糊。

我们看到这一版可以说是非常简陋的，但是它定下了这一系列的基调。在后文中我将带领大家一起感受设计的进化。

在此特别提一下：是否支持四个方向的浏览，在我看来是杂志类应用里面最考设计功夫的地方。设计者应当考虑，除了排版的区别以外，在不同版面下是否可以重新组织内容？是否还能给浏览者意想不到的惊喜？我们将在后面的介绍里找到答案和灵感。

第二期(已下架)

新的缩略图导航，包括了文字简介。可以看到，分享功能也加进来了。

我们通过第二页的操作说明可以了解到：这一版在架构上与前作有着本质不同。除了左右换页以外，新增加了上下翻页的维度。这样组织内容的好处是用户可以自由选择感兴趣的主题深入阅读。别小看这一点点改进，新的维度打破了我们传统阅读纸质杂志的习惯，同时又让我们很自然的适应和依赖电子杂志带来的便捷。我在很多其他的杂志类应用上也看到了这样的设计。

纵向翻页带来了一个问题是：用户不能确定当前页面是否有纵向内容。对此本作的设计师采用了纵向页码的方式来提示用户。当然用一些明显的指向性箭头或者其他提示也是可以的。

这版杂志的程序对不同方向的浏览做了改进：除了设计不同的排版之外，还用一些提示图标引导用户进行旋转查看。

我们再来看看交互细节的设计：

必备的360浏览。

在车身上涂抹彩色线条，笔刷遮罩的细节处理的很不错。

还包括一个物理引擎制作的简单互动：晃动iPad让画面上的物体相互碰撞。

这一版杂志实现了一个多媒体杂志的基本要素，并且用一些精致的互动细节提升了用户体验。但是，设计者并没有止步不前，我们继续来看新一期的创作。

第三期（BMW Magazine 1/2011）

在第二期中我们分析了改进过的页面组织方式带来的好处。但是缩略图导航并没有升级过，反应的还只是一个维度的信息。设计者意识到了这个问题，所以这一次他们进行了改进。于是我们看到了一个能够反应两个维度的页面组织方式的导航系统。

经过这次改进，导航已经能够直观的覆盖到杂志所有内容。

在这个版本中，设计者重新思考了两种方向下的内容组织方式。除了我们前面看到过的版式区别以外，甚至有些内容也分为了两套。一般来说，横屏模式用于欣赏大图，或者是一些交互体验的内容（电脑桌面模式），而竖屏更多用于展现长文本（书籍阅读模式）。不同的内容设计诱使用户在浏览过程中不断地旋转设备进行探索，成为iPad阅读的一种独特的乐趣。

横屏下是一个照片堆叠的交互场景。

竖屏下变为图文混排的页面。

内容的错层滚动也是本作在设计上的一大亮点。具体做法是把原本一整块的内容摆放到不同的关联视图中。滚动其中一块，另外一块也会跟着移动，但是滚动的速度不同，甚至滚动方向完全相反。这样就营造出了有层次的滚动效果。

双错层滚动

三错层滚动

反向错层滚动

和前文在Audi A1中看到的假景深滚动一样，错层滚动也成功的抓住了浏览者的眼球，提升了阅读体验。对设计者来说，滚动视图是个可玩性很高的工具。在iPad上用手指拨动实在是再自然不过的交互手势，如何把这轻轻一拨玩得出彩，就要靠大家多多发挥创意了。

第四期（BMW Magazine Summer 2011）

前一期的框架结构已经相当成熟了，这一期主要在内容上继续加以丰富：更多视频的应用、新增的产品点交互，甚至还内嵌了一个小型的游戏。

本作继续在滚动视图上大作文章，出现了四错层滚动的设计。

另外还有视频和图片为背景的滚动内容。

产品功能点的介绍做得比较精美，也运用了滚动视图来查看长内容。

拖拉操作的图片遮罩

一个加速计控制的赛车游戏。

BMW X3（App Store下载地址）

• 类型：杂志型
• 创意：3
• 设计：3
• 交互：3

BMW X3是以介绍产品为主的杂志型App，提供了基本的缩略图导航和分享等功能。 最大的特点是文字和图片采用了错层滚动的方式。

在竖屏下，原来的横屏内容等比缩小，下面的区域用缩略图导航来填充。如果不能做重新排版，也可以把这种方式作为一种不错的解决方案。

• 类型：体验型
• 创意：5
• 设计：5
• 交互：5

与其他汽车App相比，CTS非常特别。它用了一个叙述故事的方式来体验产品。从这点上看，这个App很像爱丽丝梦游仙境、玩具总动员那种类型的互动故事书：在以文字为主体的阅读体验上加入了大量精心设计过的交互内容。

不仅如此，它还引入了在互动网站上非常流行的个性化定制体验的创意，提升用户的参与感。再加上风格化的插画和流畅酷炫的动画转场，使得这个App成为本次Review中唯一一个全满分的案例。

故事开始的时候，用户可以自己定制男女主角的名字、造型等。甚至还可以用自己的相片来设定形象。这个概念大家是否很熟悉呢？这些定制的数据怎么在故事中产生作用，我们拭目以待。

故事正式开始。画面风格是真实风格的车+插画风格的背景元素。

向右拨动进入下一段场景。场景之间用一段Motion动画衔接。转场动画的制作十分精良。比方说当前场景中的某个关键元素会分离出来，或动画或变形，引领镜头快速运动过渡到下一个场景。在给观众带来视觉享受的同时，还能让用户认知到场景的关联性，从而更顺畅的阅读完整个故事。

大部分场景都包含有互动细节。这个场景用到了iPad的重力感应：左右摇动让画面上的听众们左右摇摆。还有很多场景也用到了这一特性，比如下面这个：

前后摇动iPad让路面上的易拉罐滚动起来。

这个场景则用到了声音交互，发出声响让黄色的布带飘动。

有些场景只是做了简单的点击交互，为静态的画面引入一点生动的元素。比如上图中池塘里的鱼。

前面定制的个人信息在这个场景上得到了体现，应该说还是比较初级的。我们已经在互动网站上看过很多牛B的应用，相信更酷的定制创意来到iPad平台只是一个时间问题。

Mercedes-Benz 2012 CLS（App Store下载地址）

• 类型：体验型
• 创意：3
• 设计：3
• 交互：3

这个系列的App包括了很多奔驰车型，结构和设计都差不多，所以在此我就只挑一个作为代表。

大家可以注意一下它的导航设计，用的是环车的一圈图片墙来表现，选中的时候有一个模拟镜头推近的效果。

Mercedes-Benz Magazine（App Store下载地址）

• 类型：杂志型
• 创意：4
• 设计：4
• 交互：4

Mercedes-Benz Magazine在杂志型App里算是功能比较丰富的：各方向浏览、导航、书签、分享功能一应俱全，甚至还带有一个音乐播放器。从内容上看，有视频、图片、360浏览等多媒体元素，可以看做是品牌多媒体杂志的范本之作。

缩略图导航。

奔驰自己的Mixed tape音乐播放面板。

章节的主页，可以清楚的看到后续提供了哪些内容。

简洁的360度浏览。

横竖浏览方式下的排版设计。

产品点交互。

Pure Bentley（App Store下载地址）

• 类型：杂志型
• 创意：3
• 设计：4
• 交互：3

这个是Mobile FWA上推荐过的案例，特点是设计简洁、大气。交互没什么亮点，但是内容很丰富。

导航设计。

多处用到了“拖动”的交互方式。

浮层设计。

我们知道在广告公司的熏陶下，汽车类的客户一直站在互动行业的潮流尖端。对于当下日益壮大的智能手机和平板电脑群体，客户自然不会视而不见。厂商的重视促进了品牌内容在这些新生平台上的迅速发展。

这次我为大家搜罗了一些在iPad上具有代表性的汽车品牌App，从创意、设计和交互等角度进行分析。希望能够对有志于开发这块市场的个人或公司有所启发，共同提高App的创意水平和执行质量。由于搜集的内容比较多，撰文需要时间，我将分几次发布，欢迎同学们持续关注。

按照字母先后顺序，今天我们先来看看德国三大汽车品牌之一的——Audi奥迪。

A1 eCatalogue（App Store下载地址）

• 类型：杂志型
• 创意：4
• 设计：5
• 交互：5

Audi A1 eCatalogue这个案例主体的内容组织方式是类似杂志式的翻页浏览。但是与一般的翻页滚动效果不同的是，设计者运用了现在非常流行的平行滚动效果。在很多页面上都把素材分出了不同的景别，制造了滚动时的立体效果。

导航上设计了缩略图和文字列表关联滚动，营造出很好的操作手感。另外还提供了一个关键词检索功能。

不管是设计还是程序，圆环菜单都是很考功夫的。做得好不好，看切换的动态效果就知道了。

内嵌了一个3D驾驶体验，用iPad的重力感应来操作，牛的不多说了。

在编排图文内容的时候，如何让文字区域的大小便于阅读又不会遮挡图片是设计者常常要面对的问题。我们在鼠标交互上常用的一种处理方法是设计一个折叠的区域，当用户（1）点击查看更多按钮的时候，（2）鼠标划过热区的时候，再去放大文字区域。然而在触摸设备上是否有更加自然的方式呢？

我们知道用户在触摸设备上拨动手指以滑动内容是一个很基本的操作，这个案例中的巧妙之处就是仅仅利用这样一个基本操作就实现了文本区域展开和关闭的功能：文本区域一开始是缩在角落（图片最大化），当用户想要去阅读更多文字，很自然的就会想要去滚动这块区域。这个时候就看到这块区域向上展开了（文本区域最大化），感觉就像是把一整张纸片抽出来进行阅读一样。整个操作符合用户习惯，过程行云流水，没有让用户思考，也不需要多余的一次点击。

在这里为这么一个小交互多费那么多笔墨，目的是希望各位交互设计师重视不同的平台特性的区别，在设计自然优雅的交互方式上多花点心思。

大灯的交互设计，很简单但很酷，要是能配上震撼的音效就更好了。

双指放大内饰显示出细节产品点。

让用户体验实际操作。

配置表的设计，非常详尽。此处还有一处值得称道的细节。我们知道iOS系统的滚动视图内置了一个闪动滑块的功能，用于提示可滚动的内容。这个案例设计了另一个异曲同工的方法：默认将初始位置置于底端，然后用一段动画回滚到顶部。

越来越多的App都开始设计这样的一个帮助说明，引导用户熟悉操作。对这个主题感兴趣的可以看看这里的一篇引导页面设计技巧总结。

A7 Sportback（App Store下载地址）

• 类型：体验型
• 创意：4
• 设计：5
• 交互：4

几个大的页面层级用一叠纸的方式来呈现，配合手势的翻页效果很好地运用了触摸设备的交互特点。

在用于展示产品功能的下一层级上，设计者用了类似地图的方式来组织信息，并且在一开始就用了一段Intro视频来向用户展示 “产品地图”的全局观。

与一般的查看图片不同的加入了一点交互的元素，玩起来的感觉像是翻看一叠散落在桌上的照片。

这里是一个表现设计线条的小互动：一个定制的画板程序。细节匠心可圈可点。

当画面下方这只壁虎活灵活现的爬进来的时候，我惊艳了。在一个相对静态的浏览体验中精心安排的动态内容，往往会给用户留下深刻的印象。当然我们也不要为了追求效果而生硬的编排动态效果，而是要有理有据：熟悉奥迪品牌的都知道这只壁虎代表的是奥迪看家的quattro技术。

此处还有一处交互也颇具心思。当我们用手指在虚拟的纸张区域拨动的时候，会产生把纸张揉起来的效果。之所以设计这样的交互点，我想是借壁虎在不平整表面的爬行来比喻quattro技术对车身平衡的作用。

Audi 2010 Annual Report（App Store下载地址）

• 类型：体验型
• 创意：4
• 设计：3
• 交互：4

这是一个奥迪品牌的年度报告案例，内容的组织方式比较接近我们在一般的互动网站上所看到的。表现形式上则是采用了程序驱动的大量粒子为主要元素。

一段绚酷的开场视频过后，我们进入这样一个场景。画面上粒子在无序运动。主导航就隐藏在这个空间内。

在屏幕上按下手指，立即对周围的粒子制造了一个吸引力效果。当能量槽蓄满以后，就进入了对应的版块。

第二级页面上，粒子按照新的方式排列，并做环绕运动。再点击画面上的文字则进入了第三级的内容页。以上过程就是本例中最具特色的交互导航方式。

以下是内容页的设计，只能说是中规中矩。

奥迪品牌在iPad上的App还有不少，今天介绍了这三个是我浏览下来觉得不错的。觉得意犹未尽的同学还可以看看奥迪A8L体验，算是国内出品的诚意之作。

Title : KON App
Client : KON Brand
Date : 2011.9.30

Design : KON Brand
Develop : Kevin Cao

Note：App基于之前开发Mooca时所写的框架开发，随着iOS经验值的增长，改进了许多原先设计不够合理的细节。整体执行效率也有所提升。

擦去迷雾来看俊男美女的洗浴时刻，还能上传头像给好友制造惊喜，赶快下载来体验吧。

App Store下载地址

Title : 智造喜悦 App
Client : Siemens 西门子
Agency : MediaV Shanghai
Date : 2011.8.25

Design : MediaV
Develop : Kevin Cao, Lee

说明：有一些图片不能直接缩小，为了追求UI设计像素级精确的美感，设计师应该做好两套Layout。

我们从设计师处拿到的PSD文件通常是这样的：

首先要做些必要的处理，该删除的删除，合并的合并。然后给每个将要导出的图层取好名字。整理完成后的PSD如下：

一层一层裁切导出太麻烦，自动化才是王道。接下来我们执行Files>Scripts>Export Layers to Files...命令，打开如下窗口：

由上至下分别设定几处设置：选择输出的目标文件夹。文件名前缀留空。只输出可见的图层。输出为PNG24格式。最重要的是保持透明区域和裁切图层选项。

注意：经测试，在图层群组内的图层不能正确裁切到图层的实际大小。所以在准备输出之前，要把图层从群组中移出，或者干脆删除群组。

点击Run按钮后我们就得到裁切好的PNG图片。

接下来我们要把图片名字前面的前缀处理掉。这里我用的是Mac上强大的改名工具A Better Finder Rename。设置如下：删除前6个字符。

现在我们得到的图片都是2倍版本，后面将把它缩小一半。在此我们要对每张图片检查一遍，确保裁切出来的尺寸是偶数。这一步我没有找到智能化的处理办法。还是要麻烦PS，手工改canvas大小。

最后一步，选中所有图片文件，执行iOS PNG服务。

缩小一倍，加@2x命名，一次搞定。

等等……为什么我的服务菜单下没有iOS PNG呢？呃，当然没有，因为这个服务你得自己创建。接下来我们有请Mac下自带的Automator工具登场。

选择创建一个服务（我选择服务是因为可以直接在菜单下运行，其他也可以的）：

Automator很强大，也很简单。左边是系统提供的一些操作，我们把这些操作一个个安排到右边的工作区，就能创建我们想要的工作流程。Automator的操作是线性的，上一步操作执行后的结果输入到下一步。

iOS PNG的工作流程设计如下：

首先选择服务的输入源为图像文件。然后执行一个改名操作，把@2x添加到文件名后面。接下来执行复制命令，我们将会得到一个filename@2x副本.png文件。

从左边的照片分类下找到缩放图像的操作拖过来，设置按百分比缩放的参数为50，得到一个缩小后的副本。最后再把文件名改回来。工作流程就结束了。

最后保存这个服务，今后在任何地方选中图像文件，就能使用，是不是很方便呢。大家还可以发挥想象力，看看如何改进更适合自己的工作方式。

如果你在切图上也有什么妙招，欢迎留言探讨。

Update：

适用于Lion的服务文件下载，解压后放到/Users/[Your name]/Library/Services就可以了。

首先我们需要观察症状，也就是内存的使用曲线。排查的方法是反复执行一些创建和删除对象的方法、反复加载和卸载子文件。如果内存曲线一路飙升、或者是居高不下，都表明发生了内存泄漏问题。观察内存占用可以直接求助于操作系统的资源管理器，也可以用Hi-ReS-Stats这个类。

第二个需要观察的地方，是Player输出的load和unload信息。加载和卸载外部文件，是内存泄漏问题的重灾区。在调试阶段，我一般会在主文件加一个执行System.gc()语句的按钮。一旦卸载了一个子文件，就手动触发若干次GC。如果没有输出子文件的卸载信息，那么就说明出现泄漏了。

第三个可以帮助我们排查问题的地方是Profiler工具，当你删除了对象引用，并手动触发GC以后，可以观察这个对象是否还存在内存中。Profiler可以说是排查内存泄漏问题的终极工具，唯一的问题就是会拖慢整体的运行速度，比较慢。

观察到问题现象以后我们得顺藤摸瓜，找出到底是那个对象占着内存不放，然后对症下药。下面我们就来分析几个内存泄漏的疑难杂症。

病例一：小心loaderContext和applicationDomain

ActionScript 3的Loader对象远没有我们想象中那么简单，内存泄漏问题有很大一部分是由于不当的加载和卸载操作引起的。我在研究Gaia框架的内存泄漏问题的时候发现了一处由于没有删除LoaderContext的引用而造成的卸载失败问题，其实就是没有释放应用程序域所造成的。应用程序域是一个需要被重视的对象，它对加载和卸载的影响有如下两点：

• 如果子SWF文件是加载到主应用程序域里的，那么这个文件是不能卸载的（前提是子SWF文件内的类定义没有被主应用程序域里定义所覆盖）。
• 如果子SWF文件是加载到子应用程序域内（Loader的默认方式），那么这个文件是一定能够被卸载的。

关于应用程序域的知识可以看我以前翻译的文章。根据类定义在主应用程序域里的向下覆盖原则，我们还可以考虑以下情况：如果再次加载相同的子SWF文件到主应用程序域，子文件里所包含的类定义将全部忽略，并不会注册到主应用程序域中。这次加载的SWF文件则是可以被卸载的。换句话说，一旦类定义被加入到主应用程序域里就不能够被删除。而没有加载到主应用程序域内的对象如果不能卸载就肯定是内存泄漏。

实际开发中除了一些确实不需要卸载的模块代码需要加载到主应用程序域中，一般我们还是将对象加载到子应用程序域中去的。

病例二：小心静态类

症状还是某个子文件加载后不能卸载，但是当我们再次加载这个子文件的时候，能从log看到之前的子文件被释放了。这是一个轻度内存泄漏的例子，一般不会引起内存飙升直到引起crash等强烈后果，但是我们也不能掉以轻心。

根据之前的经验：不能卸载一定是某个对象被占住了，后续再次加载又能卸载之前的实例，说明前面文件中被占住的资源又被释放了。我们先通过Profiler查看到底是那个对象被占住，然而分析下来看到居然是子文件中创建的所有实例都已经释放了。那么，到底是什么原因呢？

既然实例都已经被释放了，那么只有可能是类定义被占住了。我在这个子文件中用到了Greensock类库的ImageLoader。通过研究它的源码发现这个加载类库采用了与TweenMax类似的插件机制。当我第一次引用ImageLoader定义的时候，它会自动向LoaderMax类注册。也就是说LoaderMax类的静态成员持有ImageLoader定义的引用。

如果这两个类定义都在子应用程序域中，那么随着子文件的卸载，这两个静态类也会被销毁了。但是我在主文件中也包含了LoaderMax类，这个定义会覆盖掉我在子文件中的定义。于是造成的情况就是：一个主应用程序域中的LoaderMax类持有子应用程序域中的ImageLoader类的引用。这就是子文件无法卸载的原因！

解决方法很简单：要么在主文件中也包含ImageLoader类的定义，要么在主文件中删去LoaderMax类。这样我们就解决了一个由于跨域的静态类引用造成的内存泄漏问题。

从这个例子我们还可以总结一下在ActionScript中静态类、静态变量及其衍生的单例的注意事项，这也是和其他编程语言不同的地方：

• 只要静态类的定义是在子应用程序域里的，那么是可以被卸载的。
• 静态类、单例的只能保证在同一个应用程序域里的唯一性。也就是说有可能单例不单。
• 真正保证静态类和单例的唯一性的方法是把它们的定义加入到主应用程序域。

这种静态类之间引用的问题也是唯一让Profiler束手无策的情况，如果以后能在Profiler中直接看到类定义来自哪个应用程序域就更好了。

除此之外还要小心的是静态类的方法可能造成的对象引用问题，比如：Flash组件的FocusManager.setFocus()，以及Flex框架中的StyleManager的样式注册等等。这篇文章详细讨论了Flex模块的卸载问题。

病例三：延时删除

这个无法卸载的问题来自于我的一个使用Robotlegs和模块插件开发的子文件。为了让所有mediator执行自己的onRemove()方法，我在ShutdownCommand中将所有视图从contextView上移除，此外还进行了model和service自己的清理工作。这通常运行良好，能够正确的将模块卸载。但是我却遇到了一个问题，严格来说，这并不是一个GC的问题。因为我通过trace发现mediator的onRemove()方法并没有执行！

没有执行清理当然就有可能造成内存泄漏，那么到底是什么原因，让我从contextView上移除视图的时候没有触发对应mediator的onRemove()方法呢？

答案是Robotlegs的延时机制。为了兼容Flex框架，mediator的onRemove方法并不是在视图的REMOVED_FROM_STAGE事件监听里执行的，而是延迟了一帧（查看代码）。这样在真正的移除代码执行以前我的视图就已经从stage上移除了，也就过不了330行那个检查。

于是我就只好迁就一下Robotlegs，把子文件从显示列表上移除的时间也延迟了一帧，这样问题就解决了。

从这几个例子我们可以看出，内存泄漏的病因可能千奇百怪，但归根结底肯定都是某种引用没有被释放的问题。在实际项目中，建议大家一边开发一边就要测试内存泄漏。不要到了项目的最后阶段再来排查，那样复杂度太高。此外，在引入第三方类库的时候，也要特别注意是否会引起内存泄漏。

本文总结了排查内存泄漏的方法，分析了若干可能引起内存泄漏的代码问题。希望对大家有所帮助。如果同学们在自己的项目中也遇到过一些疑难杂症，欢迎留言一起探讨。

网上相关主题文章：

• http://ticore.blogspot.com/2010/11/as3-loader-object-gc-behavior-1.html
• http://ticore.blogspot.com/2010/11/as3-loader-object-gc-behavior-2.html
• http://blog.onthewings.net/2010/10/18/how-to-know-objects-are-really-gced-in-flash-as3/
• http://www.gskinner.com/blog/archives/2006/07/as3_weakly_refe.html

在ActionScript中，我们没有API可以直接删除一个对象，也不能控制Player进行GC。但是GC的行为是可以预估的，作为开发者，我们需要了解的是GC执行的时机是发生在需要向操作系统请求分配内存的时候。

从上面的模拟图我们可以看到：

• Player以块的方式请求和释放内存。GC的结果不一定就是更少的内存占用，也有可能是从操作系统获得更多的可用内存。
• Player会在某些GC过程中把内存中未使用部分组合成可以释放的块还给操作系统。
• 此外还要注意的是Player为了避免占用太多的CPU资源，会将一些GC操作分到不同的时间片中运行，所以一次GC过程并不一定清理完所有可回收资源。

一次GC过程（GC Pass）分为以下两个步骤：

Reference Counting

统计所有对象的引用计数，如果某个对象没有任何引用，就标记为可回收。

这个操作很好理解，需要强调的是weak reference（弱引用）是不参与计算的。引用计数是一个相对省CPU的操作，能够筛选出大部分可回收资源，但是对一些循环引用的情况就无能为力了。在下图中，标记为绿色的对象每个的引用数都为1，但它们明显是应该被回收的。

所以GC需要进行第二个步骤：

Mark Sweeping

这个步骤是从根对象（Root）开始轮询对象的引用。所谓的根对象包括：

• Stage对象
• 静态变量
• 局部变量

这种方式足够精确，能够成功筛选出上图中绿色标记的对象，而它的代价就是较大的计算开销。

为了帮助GC过程更高效的执行，最好是能在第一步引用计数中就把需要回收的对象都标记出来。具体的做法就是把所有不需要的对象引用全部清空，包括：

• 删除成员变量的引用
• 从可视对象列表上移除对象
• 移除事件监听

难点：事件监听是否会造成对象不能回收？这个问题要具体分析，有些情况可以，有些情况却不可以。归根结底还是引用关系的问题。来看下面这个例子：

Foo.as:
 
public class Foo extends Sprite
{
	private var bar:Sprite;
	public function Foo()
	{
		bar = new Sprite();
		//...
 
		//监听bar发出的事件。可以看作是bar引用了foo，因为foo的引用被保存在bar的监听者数组里。
		bar.addEventListener(MouseEvent.CLICK, clickHandler);
		addChild(bar);
	}
 
	private function clickHandler(event:MouseEvent):void
	{
		...
	}
}

Main.as：
 
// 创建foo实例
var foo:Foo = new Foo();
addChild(foo);
 
// do something with foo...
 
// 清除foo的引用
removeChild(foo);
foo = null;

我们看到foo引用了bar，而bar又通过事件监听的联系引用了foo，这就构成了一个循环引用。根据前文对GC步骤的分析，这两个对象都必须到第二步mark and sweep才能被标记出来。

如果我们对事件监听用弱引用的方式：

bar.addEventListener(MouseEvent.CLICK, clickHandler, false, 0, true);

由于弱引用不计入引用计数，所以现在foo的引用数为0。GC在第一步操作中就能把foo标记出来，从而减少了一些运算开销。这也是为什么Grant Skinner呼吁把弱引用作为事件监听的默认方式的原因。

但是作为最佳实践，我们还是提倡要手动移除事件监听。以下代码添加一个destroy()方法（也有习惯命名为dispose()或kill()等）到Foo对象中：

public function destroy():void
{
	bar.removeEventListener(MouseEvent.CLICK, clickHandler);
	removeChild(bar);
	bar = null;
}

在清除foo的引用之前执行destroy()方法：

foo.destroy();
removeChild(foo);
foo = null;

经过我们如此处理，两个对象的引用数全都为0。GC只需第一步处理就完成任务，我们节约了更多的运算开销！

从上例可以看出在一般情况下，监听子对象的事件不会影响GC。不管是弱引用方式的监听，还是显式移除监听，都只是帮助GC更高效运行的手段，而不会影响GC的结果。但是如果事件监听造成的是对象以外的引用关系，情况就不同了，并且很有可能造成回收失败。一个常见的错误例子是监听Stage对象的RESIZE事件，如果没有显式移除这个监听或者是没有采用弱引用方式，那么这个对象就不会被GC回收的。所以我建议大家还是要尽可能的显式移除监听，切断引用关系。

我们现在已经用对GC最友好的方式做好了清理准备，但是对象还没有从内存中删除。在等待GC执行的这段时间，对象内的代码还在继续执行。比如加在对象上的ENTER_FRAME事件监听处理还在继续执行，对象内的MovieClip或Sound都还在继续播放。我们一定要避免这种情况的发生，所以在切断引用之前，我们还要在destroy()方法中做些清理工作。我们要做的工作包括：

• clearInterval(),clearTimeout()
• timer.stop()
• loader.unload()/loader.unloadAndStop()
• movieclip.stop() 如果有子MC的，也要停止播放
• bitmapData.dispose()
• 关闭LocalConnection,NetConnection,NetStream
• 停止音频和视频的播放
• 删除Camera和Microphone对象的引用
• 调用子对象的destroy()方法，如果有的话

其实这些都是在开发中管理资源的基本常识，归结为一句话就是：谁创建了对象，谁就要负责清理该对象。

下面就以一些我在实际项目中开发的destroy()方法为例，看代码说话：

public function destroy():void
{
	// List是一个继承自Sprite的自定义子类
 
	// 移除list的事件监听
	list.removeEventListener.remove(MouseEvent.CLICK, clickHandler);
 
	// 我们创建了list实例，也要负责清理
	// 调用list对象自己的destroy()方法
	list.destroy();
 
	// 将list从显示列表移除
	// 这一步并非必须的步骤，原因是list的父对象会被移除，这样list和stage就没有联系了。
	// 但是在我的代码中，list还有可能会被添加到外部的容器中（比如stage），那么这一步就是必须的了。
	list.parent.removeChild(list);
	list = null;
 
	// --------------------
	// loader是一个来自tweenmax类库中的ImageLoader实例
 
	// 如果loader已经创建
	if(loader)
	{
		// 调用loader的dispose()方法，优秀的第三方类库都应该有良好的资源管理机制。
		// 参数true表示把加载的内容从显示列表上移除，帮我们节约了代码。
		loader.dispose(true);
		loader = null;
	}
 
	// --------------------
	// lightbox实例变量保存了一个外部引用
	// 根据谁创建谁清理的原则，我们在这里不需要负责该对象的清理，只要删除引用就可以了。
	lightbox = null;
}

另一个示例的destroy()方法演示了对数组中对象的处理方法：

public function destroy():void
{
	// cells是一个数组，包含了一组子对象
	var i : int, n : int;
	n = cells.length;
	for(i = 0; i < n; i++)
	{
		// 执行每一个子对象的destroy()方法
		cells[i].destroy();
		// 删除子对象的引用
		cells[i] = null;
	}
 
	// 删除数组自身的引用
	cells = null;
 
	// 如果不需要得到每一个子对象的引用，我们也可以简单的用以下代码来清理数组：
	//cells.length = 0;
	//cells = null;
}

在结构更复杂的项目里，我们还可以抽象出一个IDestroyable接口，让需要执行清理的自定义对象实现这个接口。这样我们的清理代码可以写为：

var n:int = this.numChildren;
for(var i:int = n-1; i >= 0; i--)
{
	if(this.getChildAt(i) is IDestroyable)
	{
		IDestroyable(this.getChildAt(i)).destroy();
		this.removeChildAt(i);
	}
}

总结：GC好比是ActionScript城市的环卫工人，我们的每个类都是从事劳动生产的市民。优秀的市民会把生产垃圾分类安放到回收点，而不文明的市民则把垃圾丢得到处都是。你说那种做法让城市的清扫工作变得更加高效？所以请大家谨记“谁创建谁清理”的原则，做一位ActionScript好市民。

本文回顾了GC的一些基本知识和最佳实践。在下一篇中我将结合一些具体问题，为大家把脉GC的疑难杂症。敬请期待。

继续阅读：

谈谈ActionScript垃圾回收（下）

参考资料：

• http://gskinner.com/blog/archives/2006/06/as3_resource_ma.html
• http://www.gskinner.com/talks/resource-management/
• http://active.tutsplus.com/tutorials/workflow/quick-tip-understanding-garbage-collection-in-as3/
• http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html

最近在项目中遇到一个问题。某个从SWC库中实例化的symbol总是引起crash，检查了一下发现如果存为CS5的版本发布就没有问题。于是就顺藤摸瓜发现了CS5.5的一个小问题。新的属性面板(下图)包含了一个设置visible的参数，方便我们不需要写AS代码就可以设置这个常用的参数。引起crash的symbol正是用了这个小功能。如果像我那样发布出SWC再用SDK编译，可能就会在实例化的时候没有任何报错地直接crash。

分析使用了这个功能的swf文件，发现并没有生成任何AS代码。那么应该是Flash IDE隐藏的工作吧，只是不知道这个功能的内部实现机制是什么。虽然这个功能很贴心，但是使用SWC工作流程的同学们还是暂时无视吧。

mediatorMap.mapView(IModule, ModulePageMediator, IModule);

在新版的Robotlegs下并不会生成对应的Mediator。经过一番研究后发现要改写MediatorMap才行，幸好已经有人开发出了ViewInterfaceMediatorMap插件，省了我很多工作。这个插件使用很简单。用以下代码来覆盖掉默认的mediatorMap就可以支持视图的接口注入了：

override protected function get mediatorMap():IMediatorMap
{
	return _mediatorMap ||= new ViewInterfaceMediatorMap(contextView, createChildInjector(), reflector);
}

我已经将该插件包含到RobotGaiaAnt 0.7的更新中，同时提供了一个简单的例子来演示这套框架的运行情况：RGADemo。

这个例子包含了两个页面Home和Member。其中Home是一个通常的简单页面，而Member页面继承了ModulePage，是作为一个Robotlegs模块存在，包含独立的MemberContext。

override public function set parentInjector(value : IInjector) : void
{
	super.parentInjector = value;
 
	context = new MemberContext(this, false, value, loaderInfo.applicationDomain);
}

我们可以在初始化的时候就自动启动Context。也可以选择在transitionIn()函数执行的时候再启动，这样能够引用到这个页面下包含的各项资源。但是在本例中两种启动时机都可以。

从项目的类包结构可以看到member包下的结构与根包及其相似，也包含了自己的服务、视图、控制器等等。

本例中的AppModel是在项目范围内共用的模型，保存了会员的信息。Member页面则提供了登录和显示会员信息的功能。

以下Member页面登录完成时所执行的LoginSuccessCommand命令，我们可以看到在子模块中引用主环境的Model的方法。

public class LoginSuccessCommand extends Command
{
	[Inject]
	public var member : MemberVO;
 
	[Inject]
	public var model : IAppModel;
 
	override public function execute() : void
	{
		// save to model
		model.member = member;
 
		// remove login view
		contextView.removeChild(contextView.getChildByName("LoginView"));
 
		contextView.addChild(new MemberView());
	}
}

模块化的程序要特别注意加载和卸载的内存问题。我已经在基类ModulePage中写好了dispose()方法，配合ModulePageMediator在onRemove时自动执行。经测试能够正确的卸载。你也可以通过这个示例验证一下内存曲线。

如果你在子模块中生成的其他实例影响了内存回收。可以监听ContextEvent.SHUTDOWN事件来做清理工作。我一般会写一个ShutdownCommand：

commandMap.mapEvent(ContextEvent.SHUTDOWN, ShutdownCommand, ContextEvent, true);

如果你对这个示例有任何疑问，欢迎留言与我探讨。