1. 发布前的测试
2. 企业内部自用软件，不需要发布到App Store

非正规的做法当然是“越狱”，但是更为正式的做法是使用Ad-Hoc。至于怎样创建Ad-Hoc provision文件，不在本文讨论的范围内。本文讨论的是怎样安装Ad-hoc发布的程序。通常的做法是:

1. 开发者将Xcode编译的Ad-Hoc程序.app文件压缩后与.mobileprovision一起传给用户。
2. 用户拖动.mobileprovision文件到iTunes下的资料库 → 应用程序中
3. 将压缩的.app文件解压，然后将整个.app文件夹拖动到iTunes下的资料库 → 应用程序中

通常这对于Mac用户没有什么问题，但有时Windows用户会遇到一些问题。所以更好的做法是将.app制作成.ipa与.mobileprovision文件一同寄给用户。下面是制作ipa的步骤：

mkdir Payload
cp -rp MyApplication.app Payload/
zip -r MyApplication.ipa iTunesArtwork Payload

需要注意的是这里使用的是zip命令而不是Find中“Compress”选项，因为它会添加一些额外的内容。另外iTunesArtwork是一个512×512的png文件（注意无后缀），它将在iTunes中增加一个图标，所以这并不是必需的。

使用Javascript检测是否正在使用iPhone 和 iPod

如果你的网页需要支持iPhone和iPod Touch，首先你必须检测到是否正在使用iPhone和iPod Touch，这样你才可能为其使用特定的代码或样页式。下列代码段使用Javascript来检测iPhone/iPod Touch的使用，从而将网页重定向iPhone相关的网页。

使用PHP检测是否正在使用 iPhone 和 iPod

有时在iPhone上，Javascript被禁止使用。为检测到iPhone/iPod Touch的使用，你需要使用下列PHP代码：

使用Objective C++提高iPhone应用程序的性能

我十分喜爱软件开发的一个原因是总是会遇到这样那样的问题，而总能找到相应的解决方法。在开发Spots时，我多次遇到了UI设计的问题。为 iPhone设计一个精简的用户界面是不容易的。比如，我应该提供一个提供者过滤器（指Hotspot）按钮或将其放在Settings.app中？关于这个问题，我至少改变了二十次主意？

本文不是关于用户界面设计而是有关编程与性能。本文并不是针对用户界面而是有关编程和性能。一个最大的难题是地图的绘制（屏幕下方的长方形）。经过几种方法的试用，我发现在绘制230，000个点时，只有使用OpenGL以及大量的旁门左道才能使绘图的性能勉强被接受。根据放大的级别以及可见点点数量，我最后使用了三种不同的技术。由于我需要地图交互动作（拖动和缩放）尽可能地平滑，理想情况下为60HZ，性能是最为重要的问题。

本文中我将分享一些能提高性能的技术。虽然它们都很简单和直接，但因为在Cocoa中很少见，所以我还是花了不少时间。例如，尽管C++和Objective C可以非常高效地混合使用，但我在Cocoa中并没有见到许多C++。当你的目标是高性能时，Objective C++是纯Cocoa的很好的扩展。而在iPhone上，性能是应该首先需要考虑到因素。

难题

对于分布在一个矩形区域包括230，000个热点位置的地图（麦卡托投影的世界地图 the world map in mercator projection），首先必须清楚当前地图矩形区域中有多少个可见点，因为此数值可以决定使用何种绘图技术。指标值必须归一，因此整个地图覆盖了一个{{0.0, 1.0}, {0.0, 1.0}}的矩形区域。通常情况下，程序使用的地图矩形是很小的：通常小于整个地图宽度和高度的百分之二。

但是我怎样有效地在数据库成千上万的点中找到可见点的数量？

我准备了一个XCode项目，它包括了这里讨论的所有代码。此示例项目并未包括了所有点的原始数据库。它仅包含了一些世界地图上的随机数据。虽然与真实情况有所区别，但它们的处理方法与我收集的原始数据的大同小异。

第一种方法: 普通Cocoa方法

第一种方法十分简单而且并没有采用十分高效的方法。使用Object C对象（@class Spot）来表示位置，它们以NSArrary的形式被保存在一个数据库对象中（@class SpotsDB1）。

@interface Spot : NSObject {
    CGPoint _position;
}
@property (nonatomic) CGPoint position;
@end

@interface SpotsDB1 : NSObject {
    NSArray* _spots;
}
- (NSUInteger)countSpotsInRect:(CGRect)rect;
@end

为进行一个指定CGRect内地位置计数，数据库对象简单地循环整个数组并检查各位置。

NSUInteger count = 0;
for (Spot* spot in _spots) {
if (CGRectContainsPoint(aRect, spot.position))
++count;
}

使用上述代码，在总数为230，000个点的区域上的任意一个{0.02, 0.02}矩形内进行计数大概需要250毫秒。太糟糕了，如果你的目标是刷新率60Hz，那么你只有16 ms绘制一帧。使得此方案过慢的原因不仅在于其缺乏聪明的算法，而且在循环中浪费了许多时间在调用了几个函数上。另一个对性能产生负面影响的因素是位置被保存在NSArray中的对象，这是由于对象占用了大量的内存以及数组指针的非直接性导致了处理器时间的增加。

第二种方法: 简单优化

为使同样的方案运行得更快，我们只需简单地将位置存储与一个更为紧凑的数据结构中：一个CGPoint结构的标准C数组。为使用方便，我们将C数组保存在一个NSMutableData 对象中。

_spotCount = [spots count];
_spotsData = [[NSMutableData alloc] init];
for (Spot* spot in spots) {
CGPoint p = spot.position;
[data appendBytes:&p length:sizeof(CGPoint)];
}

消除了循环内函数调用的负面影响，我们使得性能有四倍的提升：

CGFloat xMin = CGRectGetMinX(aRect);
CGFloat yMin = CGRectGetMinY(aRect);
CGFloat xMax = CGRectGetMaxX(aRect);
CGFloat yMax = CGRectGetMaxY(aRect);

CGPoint* begin = (CGPoint*)[_spotsData bytes];
CGPoint* end = begin + _spotCount;

NSUInteger count = 0;
for (CGPoint* i = begin; i != end; ++i) {
if (i->x > xMin && i->y > yMin && i->x < xMax && i->y < yMax)
++count;
}

在没有改变基本算法的基础上，点计数的计算现在只需55毫秒，这大概比原来方法快了四倍。另一个好处是现在使用的内存是原来版本的一半。

第三种方法：算法优化

当然，还有许多聪明的方法来优化平面地图点的查询。例如，你可以使用四边形树来保存这些点。在本例中我使用了一种比较简单的解决方案，所以没有涉及数据存储的方式。我使用了C++的内置功能所以甚至不需要写任何代码来处理数据的存储。

我的设想是将数组中的位置从左至右分类。这样做的好处是确定指定正方形的左右边界十分快速（见下图）。当数组中边界已知时，仅需要检查边界间的点。

所以此算法是有关快速寻找边界的。我们使用的是二进制搜索， 它适用于已排序的数组。它并不检查每个值以找到匹配的位置，而是直接跳到数组的中点，检查其值是小于还是大于给点值，然后跳到剩余部分的中心点，重复以上步骤。使用这种方法，二进制搜索需要 log2(n)的时间来查找最佳元素。对于一个拥有230，000个位置的数组，只需22次搜索！回到代码，我们发现上述算法的实现是很简单的。当然，我们必须为数据库排序：

// comparison function for array sorting
NSInteger leftToRight(Spot* a, Spot* b, void* context) {
    CGFloat xa = a.position.x;
    CGFloat xb = b.position.x;
    if (xa < xb)
        return NSOrderedAscending;
    return xa > xb ? NSOrderedDescending : NSOrderedSame;
}

...

spots = [spots sortedArrayUsingFunction:leftToRight context:NULL];

现在是有趣的部分：使用C++进行二进制搜索。我们使用了#include <algorithm>中的库函数 std::lower_bound。它需要一个起点，终点，要查找的值以及比较函数。它返回比较为false的第一个值。起点和终点可以是简单的指向数组的C指针。

#include <algorithm>
…

bool cmpX(const CGPoint& a, const CGPoint& b) {
return a.x < b.x;
}
…

CGFloat yMin = CGRectGetMinY(aRect);
CGFloat yMax = CGRectGetMaxY(aRect);

CGPoint* begin = (CGPoint*)[_spotsData bytes];
CGPoint* end = begin + _spotCount;

CGPoint leftMargin = aRect.origin;
CGPoint rightMargin;
rightMargin.x = CGRectGetMaxX(aRect);

CGPoint* left  = std::lower_bound(begin, end, leftMargin, cmpX);
CGPoint* right = std::lower_bound(left, end, rightMargin, cmpX);

NSUInteger count = 0;
for (CGPoint* i = left; i != right; ++i) {
if (i->y > yMin && i->y < yMax)
++count;
}

注意第二个二进制搜索，它仅从左边界而不是整个数组查找右边界。另一个优化是从循环中移除X-轴的检查，这是因为已经通过指定边界完成了这部分工作。

通过这些优化，只需要1毫秒来对长方形进行计数。这是第一个版本的200倍。

结果

下面是运行在三种不同设备上的示例项目的输出。如果你需要运行在你自己的设备上，你只需将目标设定中将代码签名标识符改为自己的。如果你不希望用在通用标识符的程序上，你还需要更改Info.plist中的包标识符（Bundle Identifier）。

iPhone 3G：

SpotsDB1 needed 3.2 seconds to count spots in 13 rects
that's 244.423 ms per rect
SpotsDB2 needed 3.0 seconds to count spots in 55 rects
that's 55.230 ms per rect
SpotsDB3 needed 3.0 seconds to count spots in 2988 rects
that's 1.004 ms per rect

第二代iPod Touch：

SpotsDB1 needed 3.1 seconds to count spots in 16 rects
that's 194.756 ms per rect
SpotsDB2 needed 3.0 seconds to count spots in 65 rects
that's 46.450 ms per rect
SpotsDB3 needed 3.0 seconds to count spots in 3399 rects
that's 0.883 ms per rect

运行在Mac Pro之上的模拟器：

SpotsDB1 needed 3.0 seconds to count spots in 687 rects
that's 4.372 ms per rect
SpotsDB2 needed 3.0 seconds to count spots in 2687 rects
that's 1.117 ms per rect
SpotsDB3 needed 3.0 seconds to count spots in 187276 rects
that's 0.016 ms per rect

结论

观察结果我们可以看出在桌面电脑和iPhone上性能有显著的区别。有一个金科玉律是：在Mac上只需一秒的操作在iPhone上要一分钟。或者有一个更悲观的说法：Mac上60Hz的刷新率在iPhone上每秒钟只能更新一次。

所以显而易见在iPhone上进行优化是完全必须的。本文中我展示了几种方法来减小Object C的开销以及怎样使用C++来获得最大的性能。当然找到性能的瓶颈并转而使用数据结构使代码性能提升并不总是很容易的事情。但是在设计一个使用大量数据的程序时，绝对有必要考虑使用非Cocoa的方法。

原文见：My iPhone is not a Mac Pro

所以我阅读了他寄给我的代码片段，我注意到：

啊哈! 这可能就是你问题的根源！除非你真正需要，alBufferDataStatic应该完全被避免。你怎样才知道你需要使用它？有一条金桂玉律：如果你不知道这个问题的答案，那么你就不需要它。

（我不希望看上去对Ken太过严苛，这个问题很普遍，所以我决定写这篇文章（类似于我呼吁绝不要使用随Apple发布的示例代码一样））

那我为什么会认为要避免使用它？我相信你一定听说过要获得更好的性能，你应该使用alBufferDataStatic()，对吗？不！

那好，alBufferDataStatic()是什么？alBufferDataStatic将所有缓存数据的内存管理责任完全推给了你的代码。

我重复一遍：当使用alBufferDataStatic()时，你应该对所有内存管理负责。

这就是所谓的性能提升。

等等！真的吗？这就是alBufferDataStatic的所作所为吗？

是的。

iPhone是共享内存空间的，它处理内存的方式以及当你的程序使用过多的内存时而被抛弃的方式是十分特殊的。它要求你密切注意及处理你使用的内存。那意味着如果你希望使你的第一人称射击游戏可以稳定地保持在30FPS，你必须从iPhone榨取最后一个字节内存，因此你可能需要花费几个星期来调整你的声音代码使得你可以随时密切控制内存使用情况。

对于其他 %99.9999可能需要使用OpenAL的程序（即使你使用了大量的音效），使用alBufferDataStatic()只不过是给你带来额外的麻烦而已。这里有另一条规则：如果你不打算专门雇佣一个全职开发者处理音效代码，那么你不需要使用alBufferDataStatic()。

快速阅读一下有关alBufferDataStatic()的技术文档。

这是什么意思？

意思是: 当你使用alBufferData()时，你将加载声音数据到局部缓存（你使用malloc建立的缓存），当你调用alBufferData()时， OpenAL 将复制所有字节到它自己的缓存区。然后，你要释放局部缓存，OpenGL现在拥有自己的缓存。其缺点是：在很短的一段时间内，你将拥有两份声音数据在内存中。优点是：内存管理非常非常容易。

如果你的程序在缓存复制时崩溃，那么你可能需要alBufferDataStatic()。但是更有可能的是你的内存管理机制在什么地方十分糟糕。（另外需要注意如果你加载一个很大的声音数据到内存中，那么我可以告诉你，这是错误的，你应该采用数据流来加载数据）。

好了，你已经绝对地肯定你要管理你自己的声音内存？可能需要使用alBufferDataStatic()，但是首先：这里有另一条金桂玉律：如果你正在读我这篇文章来决定是否使用它；那么不要使用。赶快找到这条代码，赶快删除它。直接删除。

很明显，我在用一种夸张的方式试图说明我的观点。我不知道你的代码，但这里有一些我在我的代码中经常出现的bug：

忘记释放对象导致内存泄漏，最终导致程序崩溃。

不小心释放了一个自动释放对象，引起崩溃。

不小心释放了一个从属于其他对象的对象，使程序随后（很久很久以后）崩溃。

malloc了一些内存，忘记free，引起泄漏，最终崩溃。

free了一些 malloc的内存，然后试图再使用，引起程序完全疯狂。

这个列表还可以继续。但是你看到一个共同点没有？内存。为什么我在不必要的情况下还要承担更多内存管理的责任？为什么开发者还要一如既往地使他们的生活变得更糟糕？

这里有些陈词滥调：

更少的代码 == 更少的bug  更多的代码== 更多的bug。 因此代码越少越好。

不要添加你现在不需要的代码。（这很常见，你可能会想：我可能以后做X时会需要一个方法，所以我现在就写出来，不必等到用时在写。）错！“未来”当你需要时，你需要的是Y，而不是X，你还是需要重写。或者更有可能是你永远也不需要用到X，你只是浪费了时间在不必要的代码上。

不要过早地进行优化。使代码可以工作为先。然后再找到你需要优化的地方。如果试图过早优化，那么最终的结果是你花费了所有的时间在使一个方法十分伟大（直到后来才知道此方法仅仅几秒钟才被调用一次，所以这是一段最缺乏效率的代码而且没有人会注意到它。）

所以，使用alBufferDataStatic()将打破我可爱的全部三条陈词滥调。

不要这样做。

你只会让你自己图添悲伤而且你的代码会问题多多。请使用alBufferData()。它可以工作。它很容易。资深的使用OpenAL的工程师保证使用alBufferData()没有内存问题。如果你打算移植你的代码，alBufferData()还是可以工作！alBufferData() 使你呼吸更新鲜！

我已经在6个程序中使用了OpenAL代码。一些是游戏，一些是实用程序。一个没有使用alBufferDataStatic()的“音板”式程序同时播放32个声音（这是目前允许的最大数目，可能以后仍然是），它能够处理庞大的声音文件（通过数据流）。是不是这个超级疯狂代码实现的超难任务可以算是一种技能？

不。恰恰相反。我尽量使我的程序保存简单。

保持代码简单，不要使用不需要的东西。

原文见：alBufferDataStatic: why you should avoid it

你的iPhone程序应该把一件事做好

原文见：Seven things all iPhone apps need 作者：Danny Gorog

我们当然可以修改此文件。但每次Xcode升级后，此信息就会丢失。我在一本有关Xcode的书中找到一个方法：

另一种方法是通过双击~/Library/Preferences下com.apple.Xcode.plist来修改。

NSLog()是一个很好的工具，它能为调试带来很大帮助。但不幸的是，它过于昂贵，特别是在iPhone上，而且根据你是怎样使用它或你用它来记录什么，它有可能泄露一些敏感和私有信息。网上有些不同的方法在发行版中去除NSLog的方法。我在这里将其汇总。

首先在Xcode中打开<AppName>_Prefix.pch文件，加入：

右击你的目标（target）点击 Get Info。选择 Build 一栏。将Configuration 设定为Debug。在Other C Flags 下加入-DDEBUG。

就这样。当你想在调试版下进行日志记录时使用 DLog()。而在发行版下DLog()被编译为空。使用 ALog()可在调试和发行版下进行记录。(A 代表 always。)

如果你希望用DLog替换源代码中的NSLog，这里有一个终端命令可以使用：

$ sed -i “.bak” ’s/NSLog/DLog/’ *.m

此命令会将所有.m文件备份为.bak。

下载：Logging Sample Application