Fusion Drive组建及Bootcamp安装

本教程将涉及

  • 硬件安装
  • 系统安装，Fusion Drive创建，及保留Recovery分区
  • Fusion Drive以后如何Bootcamp装Windows

安装硬件

硬件选购参考（购于Taobao）

Plextor m5s 256G：这个不用说吧，1.0.3固件，东芝颗粒，速度快，便宜。

光驱位硬盘托架 佳翼H125 ：做工一般般，不过这个价格也找不出做工好的，需要高质量的去买OWC Data Doubler

光驱盒替代品：这个小玩意跟上面那个光驱托架一起买只要9.9，特便宜，相对来讲那个光驱盒目测质量不敢恭维，买个这个凑合一下，反正光驱也不常用。另外有一点要注意，拆下来的光驱在读盘的时候会从各种缝隙漏出激光，直射眼睛可能会造成伤害，尤其是刻录的时候，要知道DVD刻录光驱的激光是可以点烟的，所以如果常用光驱还是建议买一下光驱盒

关于SSD，HDD分别放在哪些位置

注意事项：

（其中没有实际测试过的，不能保证100%的正确性）

速度方面：
  • 2011年以后的机器硬盘位支持SATA III 6Gb/s
  • 2012年以后的机器光驱位支持SATA III 6Gb/s
  • 2011年春季的机器光驱位有部分“看起来”支持SATA III 6Gb/s 部分支持SATA II 3Gb/s
  • 2011年秋季的机器光驱位全部“看起来”支持SATA III 6Gb/s
  • 可以在”系统报告/串行ATA/链接速度” 查看是否“看起来”支持SATA III 6Gb/s
  • 2011年光驱位看起来支持SATA III 6Gb/s的机器，将支持SATA III的SSD放入光驱位会有问题，传说Intel的SSD没有问题，具体见这里最后一楼和这里的讨论。再次强调，Intel的SSD没有经过测试，其他厂商SSD放在光驱位几乎可以肯定会出问题。
  • SATA III的设备安装在
  • 一些机械硬盘是SATA III 6Gb/s的，这种情况下将机械硬盘放到有问题的光驱位也可能有问题。
  • SATA III的设备理论上是兼容SATA II的，所以只要不是2011年有问题的机器，
安全方面：
  • HDD位有移动感应，据说可以在检测出电脑移动的时候让硬盘磁头跟盘面分离。
  • 视不同的硬盘，有些硬盘内建重力感应，也就是说自带一定减震效果

根据以上条件：

  • 如果你的设备为2011年，光驱位“看起来”支持SATA III的机器，又购买了非Intel的SSD，那么SSD只能放到HDD位，光驱位放原来的硬盘。
  • 如果没有上述问题，尽量将SSD放到光驱位，硬盘放在硬盘位，既保证硬盘的安全，同时硬盘噪音会小很多。

实测“伪”SATA III装SATA III SSD后的问题：

  • 向SSD写数据，会间歇性暂停传输，传输速度为0，如果系统安装在上面就会出现系统间歇性卡顿，难以使用
  • 写入数据速度最高仅200MB/s，正常应达到360MB以上
  • 有时会直接无法写入

拆机

根据上一部分的判断，选择性拆光驱、硬盘。建议先看一下王自如拆机组RAID的视频，做到心里有数，拆的时候不要心急。

以2011 late Macbook Pro（MD318/MD322）为例：

拆光驱（如图所示）:

  1. 背盖
  2. 拆绿色部分，顺序无所谓
  3. 紫色部分，撕开与光驱相连的黑色胶布
  4. 蓝色部分，顺序无所谓

一些说明：

  • 红色部分的线跟视频中位置不同，如图所示情况下不需要拆，实际只要不会影响取出光驱就没必要拆这根线，而且这根也较难拆
  • 蓝色部分除7之外，所有的都是6角螺丝，需要特殊的螺丝刀
  • 绿色部分除1之外，所有的都是十字螺丝
  • 蓝4，在红色部分线下面，需要将红线移开一些才能接触到
  • 蓝5，需要拿开上面的黑色塑料模块才能看到

拆硬盘

  • 跟视频中的方法一样，注意排线。

安装OSX

本文创作时，OSX最新版本为10.8.3，一切内容均以此版本为基准。

安装OSX 10.8.3 Mountain Lion

安装流程：

WARNING

以下操作会清空所有数据，切记在执行前备份重要数据！

  1. 制作安装光盘/U盘，
  2. 重启，安装盘引导，查看磁盘列表 
     diskutil list
  3. 创建逻辑卷组（Logical volume group）。其中，cs为coreStorage简写；FusionDrive为卷组名字，随便起；disk0为SSD，disk1为HDD，根据上一步的结果自行修改为合适的值 
     diskutil cs create FusionDrive disk0 disk1
  4. 查看创建结果,复制逻辑卷组的UUID（eg. “+– Logical Volume Group 2B4EDB74-5842-40E4-8398-1567CD879127″，这一行最后一串数字字母） 
     diskutil cs list
  5. 创建卷。后面2B4…127为之前复制的UUID，FusionDrive为名字，100%为容量 
     diskutil coreStorage createVolume 2B4EDB74-5842-40E4-8398-1567CD879127 jhfs+ FusionDrive 100%
  6. 在Fusion Drive上安装系统
  7. 装好系统想着开启Trim：方法（适用于10.8.3，其他未测试）

参考链接：

关于Recovery HD问题

虽说按上面教程安装后用开机按option看不到Recovery分区，但开机按Command + R还是可以进入Recovery的。

这个链接 DIY Fusion Drive: Adding Recovery HD to a CoreStorage Volume Group里有创建Recovery分区的方法，实测@robmathers的方案在开机Option中还是看不到Recovery，也可能是我操作有问题。

Bootcamp

几点说明：

  • Macbook Pro通过Bootcamp安装Windows需要内置光驱，外置以及USB引导安装盘都无解
  • Fusion Drive后，Bootcamp分区是从HDD上分割出来的，不会用到SSD
  • 在Bootcamp 5下，光驱位HDD上的Windows是可以引导的（有传言不能引导）

准备工作：

  • Virtualbox，虚拟机，用于制作Windows磁盘镜像。
  • Windows 7 64bit，或Win 8 64bit 安装镜像。32位Bootcamp说不支持，未测试。
  • Winclone，用于将磁盘镜像写入Bootcamp分区

安装

创建虚拟磁盘

  1. VirtualBox新建虚拟机，命名为“Windows”，磁盘文件类型VDI，动态分配，大小10G（不要给大，影响后面转换的速度）。
  2. 虚拟机设置里面设置好Windows安装光盘镜像
  3. 启动进入安装界面，Shift+F12打开CMD，输入下面命令，手动创建分区，避免Windows自动创建100MB分区 
     diskpart select disk 0 create partition primary exit exit
  4. 开始安装，选择刚才创建的分区，继续
  5. 第一次重启的时候关闭虚拟机，注意是关闭不是暂停
  6. VirtualBox菜单/管理/虚拟介质管理，选择“Windows.vdi”，复制，文件格式选择vdi，固定大小，命名为“Windows_copy”
  7. 上一步复制完成后，打开终端，进入复制后文件所在目录，输入下面内容，转换虚拟磁盘： 
     sudo VBoxManage internalcommands converttoraw Windows_copy.vdi Windows.raw
  8. 转换结束后，终端接着输入下面内容，挂载虚拟磁盘： 
     sudo hdiutil attach -imagekey diskimage-class=CRawDiskImage Windows.raw

创建Bootcamp分区

  • 使用Bootcamp助理创建Bootcamp分区（需要Windows安装光盘，据说加载个镜像就可以，未测试，我用的是Bootcamp助理制作的USB安装盘）
  • 关于如何通过Bootcamp助理制作USB Windos安装盘（适用于Bootcamp 5）：
    • Finder 找到 /应用程序/实用工具/Boot Camp 助理，显示包内容
    • 复制Contens/Info.plist到桌面，修改“PreUSBBootSupportedModels”下面的“MacBookPro8,3”为“MacBookPro7,3”，移动回原来的位置，替换。
    • 重启Bootcamp助理，可以看到制作USB Windos安装盘的选项
  • 创建Bootcamp分区后记得重启，你可以尝试不重启，但是可能会有个小问题，导致下面的步骤报错，重启能简单解决。

将虚拟磁盘镜像写入Bootcamp分区

  • 打开Winclone，应该可以看到一个Untitled，一个Bootcamp
  • 选择Untitled，写映像…，一切操作选择默认选项
  • 上一步完成后，选择创建好的winclone文件，选择Bootcamp分区为目的磁盘，恢复…，一切操作选择默认选项
  • 系统偏好设置，选择启动磁盘为windows
  • 重启进入Windows，继续安装，完成

参考链接：

[iOS]Learning iOS，the Beginner’s Guide

开篇扯淡是惯例（其实这个博客是一个AI维护的你信么？）， 又是一个多月没写东西，折腾各种东西，写不出来什么有营养的，也就放着了。本文虽然谋划已久，但一直都没动手写，在iOS这块，虽然坚持2年了，但还是担心会误导别人，不敢写这种类型的东西。最近要集中点别的技能点，iOS会放缓，先把这篇放出来吧，供大家参考，为了方便搜索，给本文起个中文标题：学习iOS，从菜鸟到小强。

啰嗦版

先说下我开始折腾iOS这块之前的知识背景，“碰过“C/C++，“看过”Java，“碰过”Android，当然这些都是比较保守的说法，不过也基本可以认为就是大菜的水平，认为什么都不会也可以，但是有过几个较完整的项目经验（比如我写过俩android小破项目）。

开始的时候，我的路线是在基本什么都不会的情况下，以一个不大不小的项目驱动，快速产出，这里最重要的一点就是学会如何在什么也不懂的情况下搜索到你想要实现的那些东西的代码，或者是相似的代码，然后就是如何照猫画虎把别人写的几块东西改改，用胶水代码沾一起，形成一些“能用的”东西，快速的产出有助增强信心，有效避免半途而废，同时一旦开始写代码了，所学到的知识就自然而然记牢了，不会发生看一遍忘一遍这种情况。

当然如果我这么建议别人，一些大神就会喷了（比如这个：【豆瓣校招-面试官发声】近期面试感受），说这种搜索式学习方式会打下不好的基础，因为你接触到的都是二手，三手以上的信息（这里定义一下，一手信息为文档，质量最高，二手信息可以认为是StackOverflow这类，也很不错了，三手就是这个链接里所表达的那个“二手”），对这些信息就要比较谨慎，有些东西可能太过技巧，不是一种好的解决方法，另外就是难免有错误，而且这个错误可能会被你继承很久，因为是新手，你会倾向于相信所有“好使“的代码。

这些弊端确实存在，不过恭喜你学习的是iOS，只要将你寻找问题解决方法的搜索范围限定在官方文档，WWDC视频，StackOverFlow上就可以了，这些都是一手二手的信息，而且一手信息占了绝大多数，基本可以保证信息的优质性，同时也完全足够解决问题了。当然多看看其他人写的东西也是有好处的，学习不要死板，这里的限制只是在避免上一段提到的问题，搜索式学习虽有弊端，但还是要比啃一手资料快很多，对于优先实现功能是很有必要的，关键就是要和一手资料结合着用，如何掌握之间的度就靠自己来衡量吧。

这里不得不提一下文档，苹果的文档是我见过的最好的文档（MSDN的也很牛，但是我没做过windows那方面的开发，所以没什么了解），这里不仅仅有对类、方法的详细说明，还有非常多的XXX Programming Guide，这种导引性的文章，从一定程度上来说，有了文档我们甚至已经不再需要StackOverflow，其实在StackOverflow搜索问题的时候，很多回答就是一个指向官方文档的链接。同时，文档中包含了大量Sample Project，这些Sample都很有针对性，清晰地展示了各种实现方法，同时Sample的代码都是高手写的，多看看Sample Project对编程能力的提升也有很高价值。额外说一句，如果你认为英文的文档太难读懂，那就只能查着字典啃，如果还是不行，你去学英文吧，要么就别搞这一行，文档的英文要求已经很低了。

WWDC视频，也是快速解决问题的必备，在接触比较陌生的一块比如音频处理的时候，先看一看WWDC相关视频，就能大概了解一下相应的实现方法，对这一块有一个比较清晰全面的认识，这时候再借助文档的XXX Programming Guide，基本就可以非常深入地学习到你需要的知识。

前面一直都没提到，书–这一重要学习工具，在我看来买书基本上完全没有必要，有文档在看什么书啊，那种讲语言，讲SDK的书没有必要买，根本比不上文档，时效性也差。当然还是有些好书值得买来看看，比如Apress的iPhone Cool Projects，和More iPhone Cool Projects，虽然比较旧，但是里面那几个项目还是很有参考价值的。

面对iOS这一快速更新的系统，新手面临的一个常见问题就是该从哪个SDK版本入手。SDK版本对于新手老手都是个问题，要想要新功能，就要高版本的SDK，要想兼容旧设备，就要放弃新功能，或者自己实现新功能，选择低版本的SDK。这里根据我的经验，如果你是一个纯新手，不着急开发产品，就从最新的SDK版本入手，因为等你出师了，当时入门的SDK版本已经是旧版了，兼容旧设备的问题就不存在了。如果要快速出产品，那就只能从低版本SDK入手了，当然有些新API就用不了了，作为新手一个能用新API很方便实现的功能却要为了兼容用很复杂的方法实现还是有些不爽的。选择SDK要注意的一点就是，在iOS 4.0以后，引入了Auto Reference Counting（ARC）这一技术，个人感觉使用ARC虽然方便了内存管理，但是对于新手来说缺少了手动管理内存的历练，这里欠下的债，将来一定要还的。所以还是推荐先看文档学习一下内存管理方法，并在此后一段时间内关掉ARC实践手动管理内存，记得用Instruments测一下内存泄露，等到基本掌握了手动内存管理，就可以开ARC了。当然，我在折腾内存管理的时候还没有ARC，所以这部分建议可能存在一点主观因素，虽然不一定是最好的路线，但总不是错误的路线。

工欲善其事，必先利其器，XCode的熟练使用，对于提高效率至关重要，关于怎么使用XCode请搜索我以前的文章，关键词“XCode”，懒，不发链接了。

以上都是以项目驱动为前提，至于这个项目，规模不要太大也不要太小，有一定升级空间，最好是没有时间限制的长期项目，这样就有充足的时间来深入研究某一部分知识点，第一个版本功能实现了，但是代码不够漂亮，效率不够高，推到重来是一个非常好的选择，反复迭代几次，大有益处。

我的入门项目就是HIT Mobile（在关于页面里面有链接，现在也基本停止维护了，实际上也没什么人用）。这个项目我和一个队友分别负责不同的功能，持续时间将近一年（当然有上课考试等因素干扰），为了代码整洁或者效率等问题，每个功能都反复写了2、3遍，这几遍推到重来对能力的提升是非常大的。

虽然做单一的项目可能接触的不够全面，但如果你是一个渴求知识的人，必然会在做主线任务的同时，走一些分支路线，接触到其他方面的知识，另外一点就是，iOS虽然是个手机上的OS，但不要忘了这是基于Mac OS做出来的系统，Mac OS这么多年历史岂是我等弱菜一两年就能接触全面的，专注一两个点深入学习下去也是一种很好的选择。

我们还没有说github，github的重要性其实根本不必多提，开源的framework，控件什么的基本都在上面。其他网站比如，CocoaControls，有很多开源的UI控件，建议订阅个RSS。此外cocoanetics，Cocoa is my girlfriend等博客类型的网站也经常会发布一些非常优秀的文章。

总之想“精通”iOS，绝对不是短时间可以做到的，贵在坚持不断学习。

精简版：

  • 项目驱动
  • 寻找帮助
    • 文档
    • WWDC视频
    • StackOverflow
    • Google
  • 书，不是很必要
  • 学习XCode使用
  • 手动管理内存，熟练以后再开启ARC
  • 找代码，开源库：github， CocoaControls
  • 好文章：
    • cocoanetics
    • Cocoa is my girlfriend
    • 等等

补充：

一些非常好的资源：

  • RAYWENDERLICH   |  简单高质量的Tutorial，涵盖iOS Mac Cocos2D Unity等内容

 

–以上–

[iOS]iPhone 5 图片解压缩测试

继之前翻译的两篇[iOS]如何避免图像解压缩的时间开销，iPad 3 图片解压缩测试，Cocoanetics又在iPhone 5发布后测试了一下iPhone 5的图片解压缩能力：iPhone 5 Image Decompression Benchmarked。这次还是挑重点翻译一下，以后的文章如果没什么技术因素只是单纯跑分的话就不继续翻译了，大家自行到Cocoanetics上看数据就行了，这些数据对我们评估应用的性能还是很有帮助的。

以下为译文：

我们希望在水果每个新的CPU的重复我们的benchmark，这次测试中，我们对benchmark进行了一些改进，将之前打印log的NSLog替换成了CFAbsoluteTime，NSLog本身每次都要消耗多大50ms的时间，新的方法更加精确，不会包含打印log本身的时间。

测试结果：iPhone 5 是上代处理器性能的2倍

我们之前在较早的iOS设备上运行benchmark的结果已经表明GPU性能的提升并不影响我们的测试结果，同时，渲染速度的提升看起来完全是CPU的功劳，这一点也也被一个在WWDC的苹果工程师证实，这位工程师告诉我所有的UIKit图片解压缩都依靠CPU完成。

唯一一个让图片解压缩由GPU完成的方法是使用CoreImage，但问题时虽然解压缩更快了，但将解压缩侯的图片传递到CALayer上并进入渲染树（render tree，这个概念文档和WWDC里都讲过，CALayer部分，不清楚的可以看看，基本就是字面意思）仍是一个瓶颈。所以通过CoreImage解压图片仅当你能够将它们保持在GPU的时候才有效果，比如视频处理以及使用作为3D纹理使用。

虽然我们的benchmark只关注CPU，但是我们仍认为这是一个评估每代CPU性能的一个有效方法。

iPhone 5 测试结果：

128x96

 

256x192

 

512x384

 

1024x768

 

2048x1536

 

iPhone 5对PNG的解压缩能力提升明显，优化过（crushed）的处理时间仅仅比未优化的（uncrushed）快一点，差距很小。但对于较早的设备来说，二者差距很明显。

总结：

A6处理器支持VFPv4，一个特殊的并行浮点操作指令集，VFP是“Vector Floating Point”的缩写，就是这个指令集的出现让Anandtech得出结论：A6是水果第一个完全自家设计的SoC（The iPhone 5's A6 SoC: Not A15 or A9, a Custom Apple Core Instead），虽然基于ARM 7。

如果我理解正确，那么VFP性能提升来自其中的32个寄存器（比VFPv3多一倍），这意味着可以同时处理两倍的浮点数，从而揭示了A6两倍浮点性能的提升，这同时也对降低电量消耗有帮助。

水果为iPhone 5自主设计的硅片让它以2倍的性能轻松战胜了前代设备。

–以上–

Mountain Lion 使用感受

距离上次公告已经一个多月了，最近也不怎么太忙了，前一阵也改进了下GSBookShelf，有需要的可以看看。好久没写东西了，这篇热热身吧，没什么营养，纯吐槽，图个乐呵。

话说ML在Store上发布没多久我就升级了，应该说是全新安装了，Lion不知道是系统问题还是我折腾的问题（其实我基本没折腾什么），各种操作都异常的慢，也忍受了好久了，就等ML出来全新安装一下，所以对于Lion -> ML的升级我没什么评价的，根据周围人的情况来看，基本可以放心升级，开发环境有些要重新配置。

下面进入正题（OS X 10.8.1）：

Safari：

  • 貌似网页加载速度快了很多，但实际可能是水果用了视觉上的效果让我们感觉快了，而不是真正快了多少，这从跑分上也能体现出来。
  • 搜索和地址栏统一，对chrome用户似乎不错，但有时候如果想查找一个东西却被自动补全成网页还是有些麻烦，比如搜索apple然后自动补全成了apple.com
  • 离线阅读列表在没网的情况下还是挺实用的，打发时间利器，而且也有个类似进度条的东西显示iCloud同步进度。
  • 终于有密码保存了
  • RSS功能被阉了，曾经有这么一个nb的功能我没有珍惜，直到失去的时候才后悔莫及，世间最痛苦的事情莫过于此，如果上天给我一次参观水果的机会，我一定会去问候Safari组的PM。以上纯属调侃，不知道各位都用不用RSS，实际上这个功能让我们不用在一个页面满地寻找RSS标志，而是极其自然地点击地址栏右边那个蓝色的RSS按钮，一键订阅，自然到让我一直认为在blog上面加上一个RSS按钮是一件多此一举的事情（可以看到我现在在右上角加上了这个按钮）。幸好有网友编写了插件（Subscribe To Feed Safari Extension）也算一定程度上挽救了这个功能，但是这个插件对一个页面有多个feed的情况支持还不是很好，比如本Blog，Safari 5可以识别出一个文章feed，一个评论feed，而这个插件（1.0b4）只能识别出正文那个，1.0b3在有些情况下还只识别出评论的feed，1.0b4我刚装上还没怎么用，总之就是不如原来的好用。
  • 现在终于不转菊花了，改成直接崩溃，连反馈都没有，有时一天多达数次

Mail

  • 跟Safari一起被阉掉了RSS功能，替代品选择了Reeder，不能说Reeder不好，只是Mail用习惯了用这个有些不顺手，4.99刀价格还可以，就怕那天Google Reader被局域网干掉了，每天看个新闻也要麻烦了。
  • 检查新邮件那个按钮点击后不能转圈了，应该是开发偷懒了。
  • 来往邮件终于不分开显示了，以前在收件箱里看不到自己发的，发件箱里看不到对方发的，处理Google Groups那种邮件特别费劲。

字体

  • 默认中文字体改了，可能是为了适应retina吧，用一阵儿也就习惯了

XCode 4.4

  • 速度快了不少，尤其编译到模拟器的时候，顺秒，超爽，当然你可以说：“哦漏，休息时间变少了”。
  • 稳定性应该有一定提升
  • 新特性不少，相信搞开发的都看过了，我就不多说了，总之这是一个不错的版本，强烈建议升级。

总结

iCloud覆盖更全了，配合iOS 6一起用方便不少，与Lion对比实际没有很多的升级，19.99刀价格也可以接受，升级还是值得的，哪怕仅仅为了XCode 4.4。

–以上–

[iOS]关于Audio Queue Audio Unit Audio Converter以及一个Music Visualizer Demo

事先声明：

  1. 能用傻瓜式的API还是去用傻瓜式吧，MediaPlayerFramework基本都能满足正常的音频播放需求。本文所涉及的内容用这些是实现不了的。

  2. 如果你指望本文是一个关于标题中提到的东西的教程，那我建议你还是关掉这个标签去翻文档吧，我看过的几个市面上容量仅有一篇博文那么多的关于这些方面的教程都没有什么实际意义，真的想学就踏踏实实去看文档，没有比文档对这方面讲的更清楚的了。除了文档建议补一下WWDC 2010 2011的相关Session，此外就是几个官方Sample。遇到问题了尤其是设计底层的API时，基本只有一个地方回答的比较靠谱，就是Apple Mailing List，另外StackOverflow也不错。本文仅仅回提供一些思路和链接，给后来的人指一个大概的方向。

以下进入正文：

记得小时候mp3刚开始流行那阵，那时候WINAMP称霸一时，虽然当时对音乐还没有什么感觉，但对WINAMP自带的众多可视化效果甚是着迷，直到今天终于有能力自己实现一个了，做了个Demo录了个视频发出来，效果较挫，嫌弃不好的就当听歌了，原曲来自niconico，sm18028378。youku视频如下：（也有u2b，新浪）

想实现视频中的效果有一种简单的方法和一种困难的方法

先说简单的：首先你要有音频的源文件（这不是废话么），压缩非压缩均可，格式要在iOS设备支持的范围内，另外就是对AudioQueue工作方式比较熟悉，如果你能成功用AudioQueue播放音频的话基本就成功一半了，其实从一定程度上来说AudioQueue也算是半傻瓜式的API，接下来就是获取level meter，这里提示点关键东西，自己看下就明白了：

  • AudioQueueGetProperty, kAudioQueueProperty_CurrentLevelMeterDB
  • Sample Code, Speak Here，MeterTable.h

这样就可以在每次OpenGL刷新的时候获取level meter值，
关于最后的OpenGL展示集中在后面讲

比较困难的方法就是用Audio Unit了，说困难其实不是API多么难用，而是越到底层我们做的工作就越多，真的要实现一个播放器的话我们就要人工处理音乐播放器的各种逻辑，时间控制，播放列表控制等等，实现功能以后还有一段很长的路要走。

进入正题，要求音频文件最好是liner PCM，也就是无损无压缩的，因为Audio Unit只能接受liner PCM的数据，如果是压缩格式还需要转换，转换格式可能就需要用到ExtAudioFile，或者AudioFile＋AudioConverter，前者比较方便，后者相当复杂，尤其是要考虑对各种格式的兼容问题，需要很多判断，很多分支，对音频格式的知识要求也相当高，参考Sample Code，ConvertFile，这是一个控制台应用，代码很多，耐心看。如果格式的问题回避或解决了，就可以进入AudioUnit部分了，这部分其实也不难，基本就是设置一大堆属性，然后在回调函数里面提供数据就可以了，看官方文档会对你有很大帮助。至于获取level meter，可以让音频数据通过一次MultiChannleMixer Unit（这个AudioUnit的使用可以参考下Sample Code，Mixer Host），不过我们只用一个输入口，不真正mix，只是为了借用其kMultiChannelMixerParam_PostAveragePower，获取和kAudioQueueProperty_CurrentLevelMeterDB相同的东西，然后沿用MeterTable.h，转换成更直观的数据，最后显示出来。

如果做更复杂显示效果，可能就需要fft了，也就是将时域转换成频域，根据频率数据来实现比如做那种频谱图（Spectrometer），可参考的资料：

FFT部分：

  • 理论基础，随便找个教程看吧，这方面有很多
  • 实际一点的看下Create a FFT Analyzer这个系列的前半部分，这个系列从头到尾讲了下Mac上一个显示频谱的AudioUnit的实现，但是iOS目前（5.x.x）并不支持自制的Audio Unit，所以即使你照着这个教程做出来东西也不能用到iOS平台上，不过对实现过程还是能有一个比较清晰的认识的。另外该教程也对学习路线有一明确指引。

AudioUnit部分：

  • Sample Code, AurioTouch2, Aurio Touch；前者用了AccelerateFramework，这个Framework里面有个硬件加速版的FFT，以及一些iOS 5才出现的API，但仅仅FFT部分还是能支持到iOS 4的，至于后者是纯用CPU算FFT，可以兼容iOS 4之前的系统。

接下来是显示部分：

这部分实在没什么可说的，对OpenGL ES我还是个小白，现在只是用了一个现成的Particle System，在每次draw view之前根据level meter改变了下各点的尺寸，然后就没有然手了。我也跪求高手指导如何才能做出漂亮的效果。

最后说下我的学习路线：

  1. WWDC 2010 2011关于Audio的所有Session，对Audio部分有一个直观的认识，
  2. 官方文档，从Multimedia Programming Guide开始，所有关于Audio的分支文档，从表层到底层都有个了解，明确实现某种功能需要从哪一层入手，这部分内容很多，拖拖拉拉看至少4天吧。
  3. 期间参杂之前提到的所有Sample Code，文章，以及StackOverflow，Mailing list中的各种问题。

其实有一些关于CoreAudio的书也不错，但是太大部头了，短期纯为了实现功能看书太慢了。

本文Demo的代码我就不放出来了，没有太大价值，只能起到急功近利的效果，对学习没有什么帮助，另外就是代码都是拼凑了，结构混乱，还是不要拿出来让人喷了。

PS.题外话，关于Mac向Youku，新浪传视频，Mac下的转码软件基本都是个悲剧，前面用的视频是用Video Converter－Clone2Go这个转换的，这个软件虽然UI非常悲剧，但至少能设置下音频，视频的bit率，这对于要保证音频质量来说是必不可少的（youku没爆音真是很幸运）。另外就是对比新浪和youku，新浪的审核转码都比youku快不少，音质也明显比youku高，至于u2b各方面都非常好，也就是对于我们这些国内的人上传超费劲。

祝各位玩得愉快。

–以上–

WWDC 2012 小结

低清晰度的keynote刚看完，高清1080p那个7G下了个开头就放弃了，作为一个iOS开发者简要谈下体会。

Retina MacBook Pro

之前就预测过Retina Mac几乎没有可能出现，理由就是市面上所有显卡包括台式机显卡，支持的单屏最高分辨率为2560×1600，也就是13寸MBP分辨率的Retina版，15寸的2880×1800想都不要想。可惜失算了，不知道什么时候nVidia的GTX 600M系列最高分辨率居然支持到了3840×2160，也就是Full HD的Retina版，更奇葩的是nVidia的台式机最强显卡最高分辨率依旧为2560×1600，因此不得不怀疑苹果跟nVidia在私下又合作了一次。另外最近又有新闻说iMac和Mac Pro要在明年有重大更新，在此也可以大胆预测一下，21.5寸iMac（1920×1080）上Retina从目前技术角度上来看是可能的，27寸（2560×1440）没戏，最终能否实现主要靠那两家做显卡的。

还有一点疑虑就是Reina MBP集成个Intel的显卡到底有什么用，分辨率的问题导致其不能驱动主屏幕，双屏或三屏的时候正常也是靠独显支持的，希望有条件的人去拿gfxCardStatus切换下试试，如果真的支持2880的分辨率，上面那一段就当我没说把。
如果Intel的显卡不能驱动主屏幕，那也可以看出Air和13寸MBP在以后的一两代内也不可能支持Retina，除非苹果给上独显，就算是Intel的下一代集成显卡支持高分辨率，性能上估计也很难达到要求。

Moutain Lion

Lion如其名可以算是我用过的最烂的操作系统，烂在慢，烂在各种Bug，跟SL比起来简直不在一个层面上，相信SL用户都能感受出来，都到了第四个版本了，虽然修复了很多问题，但是遗留的东西依旧不少。个人感觉，之所以没有太多人喷，是因为对于不少人来说Lion是他们用过的第一个Mac操作系统，另外Air的SSD也很大程度上掩盖了慢的缺点。综合Lion的悲剧表现我对于ML就比较期待，但以苹果最近的情况来看实在不赶抱太大希望，至于介绍的那几个新功能真正有很大用处的就是那个Power Nap了。 Game Center以但前iOS平台的游戏水准来说就是个笑话，那几个iOS游戏也就能在手机平台拿来耍耍，桌面系统玩这种级别的东西不感觉可悲么。至于未来能有什么发展就不是我等屁民可以预测的了。iCloud等附属的一系列软件还是不错的，对于用户来说只需设置个帐号，其他工作都是自动完成的，透明性非常好，但这些难道不应该在Lion中就附带么，由此可见Lion就是一个纯粹的过渡产品。

iOS 6

从升级幅度上看，iOS 6也就是iOS 5.3－5.4这个级别的，估计Bug不能多，所以很放心地升级了，主要功能新闻里都提了，我就主要谈一下他们没涉及的部分吧。

系统的整体UI有一定变化，Navigation Bar和Tool Bar的渐变方式有了改变，不算好看也不算难看，换个样子总还是有些新意的。

系统自带软件比如两个商店UI大幅改变，更美观了，自带的TODO也多了一些内容，值得一提的是Music/iPod，UI向iPad版靠拢，Cover Flow流畅了许多。

新地图对于中国区来说简直是个悲剧，AutoNavi的数据从各方面都不及Google Map，而且没有国外数据，卫星模式下全世界只有一个国家以及一个大大的红五星边上写着帝都。想用TomTom的数据对于iPhone来说也很麻烦，关键就是要开启飞行模式防止基站定位，另外一个国外的ip可能也是必要的，如果还是不行就用XCode模拟个米国地址调试一下。3D地图没条件测试，从keynote里的演示看还是很赞的，

Safai的分享按钮点击后弹出来一堆图标我就忍了，“添加到阅读列表”这个选项居然到了第二页这不是有病么？

设置>>开发者 这里多了一些内容，其中Network Link Conditioner真是相见恨晚啊，使用这个功能就可以模拟多种网络情况比如100%丢包等等，前一阵子还考虑要不要写一个这方面的程序来方便调试，iOS 6就实现了。

总结：Mac和iOS融合得好了，苹果的生态系统也更加完善了。Google和微软未来的道路又会如何呢？Google的眼镜能带来怎样的变革呢？至于iOS 6，Moutain Lion到底能带来多大变化还要看WWDC的Session才知道。

ps. 一开头Siri同学将用那蛋疼的发音讲了几个冷笑话，我是多么希望能换成GLaDOS啊！

–以上–

关于C++和Objective-C混编

Objective-C在大部分情况下足够满足我们的需求，但是还是会有一些情况必须要使用C++，比如：

  1. 使用C++的库
  2. 当Objective-C不够快的时候

第一点自然不必多说，至于第二点，Objective-C的消息机制比起函数调用还是比较慢的，当对性能有极高要求的时候，就需要C/C++来替代。

C++与Objective-C混编只要注意将包含C++代码的.m文件改为.mm即可，XCode就会自动判断该使用何种编译器来编译。

这看起来简单，但实际操作中还是很容易出现令人费解的编译问题，比如最经典的"Unknow type name ‘class’; did you mean ‘Class’?“。究其原因就是我们没有遵守这两条规则：

  • .m文件不能含有C++代码
  • .m文件所import或include的.h文件中不能直接或间接包含C++代码

在保证你的C++代码是正确前提下，如果发现相关编译错误可以通过如下几个方法修复

  1. 将.h文件中的c++代码转移到其他地方
  2. 阻段include或import链
  3. 将相关的.m文件后缀改成.mm

显然第三种方法相对于前两种实施起来更方便，但如果你使用XCode 4以及之后的版本所包含的模板建立项目的话有可能会忽视一个问题：

当你在AppDelegate.h中include或import一个C++的头文件时，当然你一定不会忘记修改AppDelegate.m为AppDelegate.mm，如果只做了这点儿还不够，我们还忽略了隐藏在Supporting Files组内的一个文件的存在–main.m

在以前的XCode模板中main.m默认是这样的

#import <UIKit/UIKit.h>;
 
int main(int argc, char *argv[]) {
 
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];
    return retVal;
}

而新的模板是这样的：

#import <UIKit/UIKit.h>;
 
#import "AppDelegate.h"
 
int main(int argc, char *argv[])
{
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

看出问题来了吧，main.m新增了#import “AppDelegate.h"，这就导致了main.m作为一个Objective-C源文件却引入了C++代码，而Xocde会使用Objective-C的编译器进行编译，从而产生编译错误，因此我们还需要将main.m的后缀改成.mm。

总结＋吐槽：我在发现main.m这个问题之前对编译错误纠结了好久，一度修改代码，也一度怀疑是XCode本身的问题（XCode 4出奇的不稳定让人不得不对其产生质疑，虽然这次是我错了），希望同样使用Objective-C++的同学不要像我一样栽在main.m上。

–以上–

[iOS]开源控件GSBookShelf–iBooks风格书架实现

GSBookShelf是我参照iBooks的操控实现的一个书架界面（或者说是控件）。项目放在github上了，大家可以去参考。

由于前两天GSBookShelf被Cocoa Controls收录了（不知道谁给我提交上去了，或者他们编辑自己发现的），而且还获得了Control of the week称号，所以有必要提供一个github之外的反馈平台吧。

演示：

效果图（图片比较大，请耐心等待）：

imageimageimage

视频演示（感谢Cocoa Controls制作）：

u2b

简介：

看过上面效果图并且用过iBooks的同学应该清楚这个控件的基本功能了吧，就是实现书籍拖拽（支持拖拽的同时ScrollView滚动），批量添加，批量删除，以及这些动作的相应动画。

部分功能实现细节：

  • 整体采用了类似UITableView的cell，重用等机制
  • 在拖拽的同时ScrollView滚动是通过NSTimer每隔0.xx秒触发，让ScrollView的contentOffset加1实现的，这种方法看起来可能不太靠谱，但实测性能上没有问题，2代touch上滚动速度略慢。

其他说明：

  • 别忘了开ARC
  • demo中的“书”（bookView）是UIButton，可以替换成任意UIView，只要你别拦截长按手势。
  • 为你自定义的bookView，和cell添加GSBookView和GSBookShelfCell协议来支持重用，这个对性能很重要。
  • 超出书架拖动范围，在书架顶部之上可以添加一个自定义的UIView来实现ibooks中那个苹果图表的效果，在书架底部之下也可以添加一个自定义的UIView来显示出更多层，防止直接显示scrollview的背景的突兀。
  • 在书架顶部可以加一个自定义UIView，demo中我添加了一个UISearchView，可以用来查询
  • “书”（bookView）的尺寸是固定的，如果你希望有所变化，可以把一个透明的UIView设置成bookView，然后在这个view之上添加你的内容，但是手势识别仍旧以透明的UIView的范围为基准，这个问题主要是为了权衡bookView的可定制性，以及实现的难度所做出的妥协。
  • 横屏的图片我没做，原因一是比较懒，二是如果你用这个控件应该会自己作图，三是考虑到下面TODO中提到的内容。

TODO：

  • 在之前一版的demo中虽然支持了横竖屏切换，但是只是简单地reload了一次，而且跳到了书架顶部，细节不太完美，而iBooks在旋转过程中还有一些动画等细节功能，这个会在以后添加，但肯定不是最近（目前比较忙）。

总结：

感谢Cocoa Controls收录，欢迎各位批评指正，如有问题请回复或者通过各种可能的方式联系我。

PS：我无节操地在github项目那里加了个Donate，欢迎支持！

–以上–

[iOS]分享最近发现的一些好东西(120311)

好久没更新了，最近在鼓捣一些Core Audio的有关内容，加上各种事儿，没有时间写东西，先把最近发现的一些好东西分享出来吧。

文章

项目

[iOS]借助VoiceOver来破解优秀App的实现方式

为了开发出更好的iOS App，我们经常会去破解（我更喜欢叫Hack）优秀的App的实现方式，一般我们做的无非就是拆了ipa包浏览一下App所用到的图片资源，找个抓包工具看看都访问了那些网络资源，更虎点的就是去反编译，当然最基础的就是把玩一下各个功能，凭经验看出实现方法。

今天就介绍一个比较另类的Hack方式——VoiceOver，估计大部分人都没在自己的iOS设备上打开过这个功能，我就简单说一下效果吧，更细节的东西还是要各位亲身体验一下。

VoiceOver需要在：通用 >> 辅助功能 >> VoiceOver 页面里开启，打开后会进入一个相对比较难操作的环境，随着手指在屏幕上移动，会有一个黑框附着在手指附近的UI元素上面，同时随着黑框的移动，iOS设备会自动朗读UI元素的内容，不难发现VoiceOver这个黑框具有以下几个特性：

  1. 黑框所在位置就是当前UI元素的真实边框
  2. 对于一些元素比如UIButton，当黑框附着在起上面时，系统就会朗读“xxxxx按钮”，对于UITableView更是可以朗读出当前所在行号，以及一共有多少行。朗读的内容通常包含了这些UI元素的独有特性。
  3. 由于大部分的App都不会对“辅助功能”有所支持，有些没有文字的UI元素系统甚至会朗读其变量名，这跟反编译已经比较相似了。

借助第一个特性我们可以破解App的UI布局，借助第二个特性我们可以找出一些UI元素的实现方式，比如有些Gird View就是用UITableView实现的，如果系统朗读了行号等UITableView所具有的特征内容，我们就可以基本确定这个Gird View就是用TableView来实现的，TabBar之类的也是如此。借助第三条特性，我们可以通过其变量名判断其功能和实现方法。此外对于那些开源应用，变量名也可以方便我们更快地研究开源代码。

相对的，如果我们想避免App的关键实现细节被破解，就要在代码中加入防止VoiceOver响应的代码。

综上，虽然VoiceOver属于辅助功能范畴，但其一些特性为我们Hack App提供了方便。在一般的应用中加入Accessibility支持可能会使开发成本有所提高，但对于某些领域的应用，Accessibility支持无疑会成为应用的一大两点，在此也推荐大家看一下 WWDC 2011 Session 127 – Design Patterns to Simplify Mac Accessibility，真的挺有爱的。

–以上—