2013年12月16日星期一

iOS各版本加入的Frameworks一览

Device frameworks - (摘自iOS Technology Overview - Appendix B)

Name
First available
Prefixes
Description
Accelerate.framework
4.0
cblas, vDSP
Contains accelerated math and DSP functions. See “Accelerate Framework.”
Accounts.framework
5.0
AC
Contains interfaces for managing access to a user’s system accounts. See “Accounts Framework.”
AddressBook.framework
2.0
AB
Contains functions for accessing the user’s contacts database directly. See “Address Book Framework.”
AddressBookUI.framework
2.0
AB
Contains classes for displaying the system-defined people picker and editor interfaces. See “Address Book UI Framework.”
AdSupport.framework
6.0
AS
Contains a class for gathering analytics. See “Ad Support Framework.”
AssetsLibrary.framework
4.0
AL
Contains classes for accessing the user’s photos and videos. See “Assets Library Framework.”
AudioToolbox.framework
2.0
AU, Audio
Contains the interfaces for handling audio stream data and for playing and recording audio. See “Core Audio.”
AudioUnit.framework
2.0
AU, Audio
Contains the interfaces for loading and using audio units. See “Core Audio.”
AVFoundation.framework
2.2
AV
Contains Objective-C interfaces for playing and recording audio and video. See “AV Foundation Framework.”
CFNetwork.framework
2.0
CF
Contains interfaces for accessing the network via Wi-Fi and cellular radios. See “CFNetwork Framework.”
CoreAudio.framework
2.0
Audio
Provides the data types used throughout Core Audio. See “Core Audio.”
CoreBluetooth.framework
5.0
CB
Provides access to low-power Bluetooth hardware. See “Core Bluetooth Framework.”
CoreData.framework
3.0
NS
Contains interfaces for managing your application’s data model. See “Core Data Framework.”
CoreFoundation.framework
2.0
CF
Provides fundamental software services, including abstractions for common data types, string utilities, collection utilities, resource management, and preferences. See “Core Foundation Framework.”
CoreGraphics.framework
2.0
CG
Contains the interfaces for Quartz 2D. See “Core Graphics Framework.”
CoreImage.framework
5.0
CI
Contains interfaces for manipulating video and still images. See “Core Image Framework.”
CoreLocation.framework
2.0
CL
Contains the interfaces for determining a user’s location. See “Core Location Framework.”
CoreMedia.framework
4.0
CM
Contains low-level routines for manipulating audio and video. See “Core Media Framework.”
CoreMIDI.framework
4.2
MIDI
Contains low-level routines for handling MIDI data. See “Core Audio.”
CoreMotion.framework
4.0
CM
Contains interfaces for accessing accelerometer and gyro data. See “Core Motion Framework.”
CoreTelephony.framework
4.0
CT
Contains routines for accessing telephony-related information. See “Core Telephony Framework.”
CoreText.framework
3.2
CT
Contains a text layout and rendering engine. See “Core Text Framework.”
CoreVideo.framework
4.0
CV
Contains low-level routines for manipulating audio and video. Do not use this framework directly.
EventKit.framework
4.0
EK
Contains interfaces for accessing a user’s calendar event data. See “Event Kit Framework.”
EventKitUI.framework
4.0
EK
Contains classes for displaying the standard system calendar interfaces. See “Event Kit UI Framework.”
ExternalAccessory.framework
3.0
EA
Contains interfaces for communicating with attached hardware accessories. See “External Accessory Framework.”
Foundation.framework
2.0
NS
Contains interfaces for managing strings, collections, and other low-level data types. See “Foundation Framework.”
GameController.framework
7.0
GC
Contains interfaces for communicating with game-related hardware. See “Game Controller Framework.”
GameKit.framework
3.0
GK
Contains interfaces for managing peer-to-peer connectivity. See “Game Kit Framework.”
GLKit.framework
5.0
GLK
Contains Objective-C utility classes for building complex OpenGL ES applications. See “GLKit Framework.”
GSS.framework
5.0
gss
Provides a standard set of security-related services.
iAd.framework
4.0
AD
Contains classes for displaying advertisements in your application. See “iAd Framework.”
ImageIO.framework
4.0
CG
Contains classes for reading and writing image data. See “Image I/O Framework.”
IOKit.framework
2.0
N/A
Contains interfaces used by the device. Do not use this framework directly.
JavaScriptCore
7.0
JS
Contains Objective-C wrappers for evaluating JavaScript code and parsing JSON. See “JavaScript Core Framework.”
MapKit.framework
3.0
MK
Contains classes for embedding a map interface into your application and for reverse-geocoding coordinates. See “Map Kit Framework.”
MediaAccessibility.framework
7.0
MA
Manages the presentation of closed-caption content in media files. See “Media Accessibility Framework.”
MediaPlayer.framework
2.0
MP
Contains interfaces for playing full-screen video. See “Media Player Framework.”
MediaToolbox.framework
6.0
MT
Contains interfaces for playing audio content.
MessageUI.framework
3.0
MF
Contains interfaces for composing and queuing email messages. See “Message UI Framework.”
MobileCoreServices.framework
3.0
UT
Defines the uniform type identifiers (UTIs) supported by the system. See “Mobile Core Services Framework.”
MultipeerConnectivity.framework
7.0
MC
Provides interfaces for implementing peer-to-peer networking between devices. See “Multipeer Connectivity Framework.”
NewsstandKit.framework
5.0
NK
Provides interfaces for downloading magazine and newspaper content in the background. See “Newsstand Kit Framework.”
OpenAL.framework
2.0
AL
Contains the interfaces for OpenAL, a cross-platform positional audio library. See “OpenAL Framework.”
OpenGLES.framework
2.0
EAGL, GL
Contains the interfaces for OpenGL ES, which is an embedded version of the OpenGL cross-platform 2D and 3D graphics rendering library. See “OpenGL ES Framework.”
PassKit.framework
6.0
PK
Contains interfaces for creating digital passes to replace things like tickets, boarding passes, member cards, and more. See “Pass Kit Framework.”
QuartzCore.framework
2.0
CA
Contains the Core Animation interfaces. See “Quartz Core Framework.”
QuickLook.framework
4.0
QL
Contains interfaces for previewing files. See “Quick Look Framework.”
SafariServices.framework
7.0
SS
Supports the creation of reading list items in Safari. See “Safari Services Framework.”
Security.framework
2.0
CSSM, Sec
Contains interfaces for managing certificates, public and private keys, and trust policies. See “Security Framework.”
Social.framework
6.0
SL
Contains interfaces for interacting with social media accounts. See “Social Framework.”
SpriteKit.framework
7.0
SK
Facilitates the creation of sprite-based animations and rendering. See “Sprite Kit Framework.”
StoreKit.framework
3.0
SK
Contains interfaces for handling the financial transactions associated with in-app purchases. See “Store Kit Framework.”
SystemConfiguration.framework
2.0
SC
Contains interfaces for determining the network configuration of a device. See “System Configuration Framework.”
Twitter.framework
5.0
TW
Contains interfaces for sending tweets via the Twitter service. See “Twitter Framework.”
UIKit.framework
2.0
UI
Contains classes and methods for the iOS application user interface layer. See “UIKit Framework.”
VideoToolbox.framework
6.0
N/A
Contains interfaces used by the device. Do not include this framework directly.

2013年7月19日星期五

XCode 一直停留在“Attaching to (app name)”的故障解决

普通的解决方法有:

  1. 重启模拟器 、重启XCode、重启电脑
  2. 模拟器Reset Content and Settings
  3. XCode > Project > Clean
  4. XCode > Project > Edit Schemes > Run, 将  Debugger 从LLDB 修改为GDB
  5. 进入工程目录 ProjectName.xcodeproj/ 删除 xcuserdata
  6. XCode > Window > Organize > Projects > 左侧选择Project Name > 右侧删除 Derived Data

如果上面的方法都没有解决,有一张特殊情况:

/etc/hosts 文件是否修改过?导致localhost 无法解析,在命令行下 
ping localhost
ping: cannot resolve localhost: Unknown host
则需要重新修改/etc/hosts文件
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
现在使用ping命令应该是这样的
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.028 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms
...
然后重新启动启动XCode > Run ,是不是发现问题解决了?

2012年6月13日星期三

再看看iOS应用程序的目录系统

安装一个iOS程序程序时,安装程序代码创建一个应用程序的主目录,该目录中的应用程序,并创建其他一些关键的目录。每个iOS应用程序被限制只能操作自身主目录下的文件。一个应用程序通常禁止在其主目录之外的目录访问或创建文件,只能通过系统接口来访问一些外部内容(如联系人、音乐、图片等)。


iOS程序主目录下有下面几个标准目录

<Application_Home>/AppName.app  
       这个是应用程序自身
<Application_Home>/Documents/    
       使用这个目录来存储用户的文件和应用程序数据文件。关键数据是任何不能重新创建你的应用程序的数据,如用户生成的内容。此目录的内容,可以提供给用户通过文件共享。(此目录的内容在iTunes备份程序时会被备份。)
<Application_Home>/Documents/Inbox
        使用这个目录来访问外部程序传入的文件。(如果应用程序注册了特定的文件格式,在其他程序中的特定文件可以传于此应用程序打开)
<Application_Home>/Library/
<Application_Home>/Library/Application Support
       使用这个目录来存储应用程序的数据文件(应用程序创建的数据文件,配置文件,模板等)。(这个目录会被iTunes备份。)
<Application_Home>/Library/Caches
       使用这个目录保存应用程序的支持文件,这些文件会被重新创建。应用程序负责管理这个目录的内容,并根据需要添加和删除文件。此目录不会被iTunes备份,且在设备恢复时此目录会被删除。iOS 5以前该目录一般不会被删除。但在iOS 5及以后版本中,系统可能会在特定情况下删除此目录(如磁盘空间低时)
<Application_Home>/Library/Frameworks
       iOS程序基本不使用
<Application_Home>/Library/Preferences
       使用NSUserDefaults配置时,存储在该目录。(这个目录会被iTunes备份。)
<Application_Home>/tmp/
       临时文件目录,可以存储临时文件。应用程序负责管理这个目录的内容,不使用里面的文件时,需要负责删除。特定情况下会被系统删除。

到底该如何保存文件

  Documents目录
       一般来说Documents目录用来存储永久性数据,当iCloud出现后往Documents目录存数据变得很不一般, Documents目录下的所有文件都会被iCloud存储,通过iTunes下载的音乐、电影、铃声,通过APP Store下载的程序,电子书,iAp下载的付费内容也被存到iCloud。为了减少备份的数据大小,应用程序下载的且可以重新创建的内容就不建议放在documents目录。否则程序提交测试时就会因为这个原因被拒绝:“We found that your app does not follow the iOS Data Storage Guidelines, which is required per the App Store Review Guidelines.” 所以document目录下,我们只能用来存储用户生成的,无法被重建的文件。(比如用户书签、历史纪录等)
 /Library/Caches目录
       该目录不被Itunes和iCloud备份,所以一般程序下载的内容放置到该目录中(如电子书、图片等,QQ阅读下载的epub文件就放置到此目录中)。需要注意的是,当用户磁盘空间告急的时候,系统会删除该目录下的数据 。但是当软件版本升级时该目录会被保存。
 /Tmp 目录
      存放临时文件,当不使用时,程序需要负责删除。

       如果非要存储到documents目录,可以设置do not back up属性,但是只在iOS 5.0.1后有效。如果需要支持iOS5及以前的系统,下载的文件还是乖乖的放到/Library/Caches中吧。

升级程序时的文件处理

当用户下载一个App的升级时,iTunes会生成一个新的App目录并安装,然后移动原App下的用户数据到新的目录。移动完成后删除旧的App。以下两个目录下的文件保证会在更新的操作过程中移动:
<Application_Home>/Documents
<Application_Home>/Library
尽管App下的其他目录也许会被移动,但是不要做这个保证。

(说明:Documents、Library目录下的文件,在几率很低的有些情况下升级的时候也会丢失。原因不明。如果有清楚的,请告知。)

参考

  • https://developer.apple.com/icloud/documentation/data-storage/ (iOS Data Storage Guidelines)
  • https://developer.apple.com/library/ios/#qa/qa1719/_index.html (Technical Q&A QA1719 How do I prevent files from being backed up to iCloud and iTunes?)
  • http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html (File System Programming Guide)
  • http://www.marco.org/2011/10/13/ios5-caches-cleaning
  • https://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/PerformanceTuning/PerformanceTuning.html#//apple_ref/doc/uid/TP40007072-CH8-SW8


如何检查程序iCloud中备份的大小
- Install and launch your app
- Go to Settings > iCloud > Storage & Backup > Manage Storage
- If necessary, tap "Show all apps"
- Check your app's storage

2011年9月6日星期二

调试安装到设备的ios程序

程序真机上崩溃以后通常会留下一个.crash的日志文件,可以通过这个crash文件迅速查找到哪里崩溃了,当然仅仅这个crash日志文件是不够的,还需要一个.dsym文件,该文件保存了些调试需要的信息。 xode默认是设置编译时生成.dsym文件的,编译程序时,会在app的同级目录生成该文件。同时应该明确一个事情,每个dsym文件只和同时编译的app匹配。

1.生成.dsym

Xcode's "Archive" command makes it easy keeping the matching binary and the .dSYM. When you use the "Archive" command (by choosing "Archive" from the "Product" menu or by pressing Shift+Command+B), Xcode will gather the application binary and the .dSYM containing symbol information together and store them in a location in your home folder. You can find all of your archived applications in the Xcode Organizer under the "Archived" section. Xcode will automatically search archived applications when symbolicating crash reports, and you can submit archived applications directly to iTunes Connect ensuring that the application and .dSYM that you have archived match what you release.
Xcode will automatically symbolicate all crash reports that it encounters, if it has the .dSYM and application binary that produced the crash report. Given a crash report, the matching binary, and its .dSYM file, all you need to do for symbolication is to add the crash report to the Xcode Organizer. Open the Xcode Organizer, select the “Devices” tab, select “Device Logs” under “LIBRARY” on the top of the sidebar, click the "Import" button and select the .crash file. When it's done, Xcode will automatically symbolicate the crash report and display the results.

2.获取设备中的crash日志


当用itunes同步设备后,crash日志会被拷贝到一下目录  Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
Windows XP: C:\Documents and Settings\<USERNAME>\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>
Windows Vista or 7: C:\Users\<USERNAME>\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>

3.使用工具symbolicatecrash 获取crash日志中的具体内容,将错误日志中的崩溃的函数地址转换为实际的函数名称


$ sudo cp /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash /usr/local/bin/

$ symbolicatecrash report.crash MobileLines.app.dSYM > report-with-symbols.crash

更多资料可参考:

  • http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/      IPhone Crash Logs
  • http://kbase.wincent.com/old/knowledge-base/DWARF_with_dSYM_debug_information.html       DWARF with dSYM debug information
  • http://www.cimgf.com/2009/12/23/automatically-save-the-dsym-files/    Automatically save the dSYM files.
  • http://developer.apple.com/library/ios/#technotes/tn2151/_index.html   Understanding and Analyzing iPhone OS Application Crash Reports
=====================

Extracting the Debugging Information to a Separate File

http://developer.apple.com/tools/xcode/symbolizingcrashdumps.html



     It should be obvious by now that you need a build process that strips the final executable file of all debugging information while simultaneously saving that information for future debugging. Instead of merely stripping the debug information from the final executable, a better solution is to extract the debugging information and save it to a separate location. The application is built only once, and the extracted debugging information is available to the developer but is no longer embedded in the final product.

    Beginning with version 2.4, Xcode supports the Debugging with Attributed Record Formats (DWARF) with dSYM file format. Setting the Debug Information Format to DWARF with dSYM causes the linker to produce a separate file package, with the dSYM extension, that contains a copy of the symbol information in the executable. A small reference is added to the executable so that debugging tools know that a dSYM file for the program was produced.
    
    The embedded debug information can now be safely stripped from the executable. When loading a stripped executable, the GNU debugger will check for its companion dSYM file. If present, it will automatically use the DWARF debugging information contained therein. A dSYM file must be in the same directory as the product (simple executable or application bundle) for this to occur.

    In the Release configuration of the application target, enable dSYM-style debugging information, as Table 3 shows.


  • Build Setting Value
  • Generate Debug Symbols YES
  • Debug Information Format DWARF with dSYM File
Table 3: Target Build Settings in the Release Configuration

   
    Note that the dSYM file format can’t be used with ZeroLink and is generally useful only for producing a stripped product while retaining a copy of the debugging information. In your development build configurations, continue to use the regular stabs or DWARF formats.

   And, like the previous solution, enable stripping of the final executable in the project build settings, as Table 4 shows.


  • Build Setting Value
  • Deployment Postprocessing YES
  • Strip Linked Product YES
  • Use Separate Strip YES
  • Strip Debug Symbols During Copy NO
Table 4: Project Build Settings in the Release Configuration


    This solution meets the first and second goals and is easy to maintain. You can archive the finished application for future debugging simply by preserving the dSYM file. You can debug the release build of the application without any special steps; simply start the debugging session with the dSYM file present. The application, sans the dSYM file, can be freely distributed and contains no symbol information.

A Note About Debugging Optimized Code



     Be aware that you could encounter subtle problems when trying to debug optimized code. During debugging, code generally isn’t optimized because optimization can destroy the one-to-one relationship between the source code and the compiled object code, which could make it impossible to correlate an execution address with a line of code in the original source (or vice versa). Another artifact might be unexpected order of execution (i.e., the statement on line 9 executes before the statement on line 8). This behavior sometimes makes it difficult to set breakpoints or control execution in the debugger.

    There’s no real solution to this problem. The very nature of optimizers means that the compiler might rewrite code expressed in source code for better performance.

 Symbolizing Crash Dumps



Should your application crash, the system crash reporter facility creates a crash log. This crash log contains a stack trace annotated with whatever program symbol information was found in the application and frameworks. The standard system frameworks contain basic symbol information, but if the application has been stripped of its debugging information, no useful information about the application’s stack will be logged. Listing 2 shows a portion of the TempConverter.crash.log.


Thread 0 Crashed:


0 com.yourcompany.TempConverter 0x00002b84 0×1000 + 7044


1 com.apple.Foundation 0x929ea9c8 _NSSetObjectValueAndNotify + 136


2 com.apple.Foundation 0x929ea6f4 -[NSObject(NSKeyValueCoding) setValue:forKeyPath:] + 180





27 com.apple.AppKit 0x937f887c NSApplicationMain + 452


28 com.yourcompany.TempConverter 0x000029dc 0×1000 + 6620


29 com.yourcompany.TempConverter 0x000026e0 0×1000 + 5856


Listing 2: Excerpt from TempConverter.crash.log


Because the TempConverter executable has no symbol information, program locations in the TempConverter code segment are listed as hexadecimal offsets. You can use the atos (“address to symbol”) tool to convert these addresses back to their symbolic names. If enough debugging information is available, the tool also supplies the source file name and line number for the address. Open a Terminal window, and set the current directory to the TempConverter D/build/Release folder. Then, issue the command that Listing 3 shows.


atos -o Debug/TempConverter.app/Contents/MacOS/TempConverter 0x00002b84


-[ConverterApplicationDelegate setCentigradeTemperature:] (in TempConverter) (ConverterApplicationDelegate.m:42)


Listing 3: Using atos to Translate Memory Address to Symbol


The atos tool reads the symbols contained in the TempConverter executable file and uses that information to convert the address 0x00002b84 to its symbolic equivalent, complete with source file name and line number. If you’re using DWARF dSYM files, you must be using the version of atos included in Xcode 3 (Mac OS X version 10.5).

The atos command accepts multiple address arguments or can read a list of addresses from stdin. While useful enough for converting a few addresses, atos becomes cumbersome for large stack traces or multiple crash logs. Fortunately, you can automate the process with a script like the one Listing 4 shows.



#!/bin/bash

AWK_SCRIPT=/tmp/symbolizecrashlog_$.awk
SH_SCRIPT=/tmp/symbolizecrashlog_$.sh
if [[ $# < 2 ]]
then
echo “Usage: $0 [ -arch ] symbol-file [ crash.log, ... ]”
exit 1
fi

ARCH_PARAMS=”

if [[ "${1}" == '-arch' ]]

then

ARCH_PARAMS=”-arch ${2}”

shift 2

fi

SYMBOL_FILE=”${1}”

shift

cat > “${AWK_SCRIPT}” < < _END


/^[0-9]+ +[-._a-zA-Z0-9]+ *\t0x[0-9a-fA-F]+ / {


addr_index = index(\$0,\$3);


end_index = addr_index+length(\$3);


line_legnth = length;


printf("echo '%s'\"\$(symbolize %s '%s')\"\n",substr(\$0,1,end_index),


\$3,substr(\$0,end_index+1,line_legnth-end_index));


next;


}


{ gsub(/'/,"'\\\\''"); printf("echo '%s'\n",\$0); }


_END


function symbolize()
{
# Translate the address using atos
SYMBOL=$(atos -o "${SYMBOL_FILE}" ${ARCH_PARAMS} "${1}" 2>/dev/null)
# If successful, output the translated symbol. If atos returns an address, output the original symbol
if [[ "${SYMBOL##0x[0-9a-fA-F]*}” ]]
then
echo -n “${SYMBOL}”
else
echo -n “${2}”
fi
}

awk -f “${AWK_SCRIPT}” $* > “${SH_SCRIPT}”

. “${SH_SCRIPT}”

rm -f “${AWK_SCRIPT}” “${SH_SCRIPT}”


Listing 4: The symbolizecrashlog Script


Obtain a crash log from the TempConverter without symbol information and a copy of the executable file that includes its debugging information. Invoke the script with the command Listing 5 shows. (This command assumes that all three files are in the current directory.)


./symbolizecrashlog TempConverter TempConverter.crash.log > TempConverter.symbolized.log


Listing 5: Running the symbolizecrashlog Tool


The symbolizecrashlog script takes as input one or more crash logs and uses the debugging information found in the first argument to translate all stack trace addresses to their symbolic equivalents. Addresses that can’t be translated are left unaltered. If no crash log files are given, the script reads the crash log from stdin.


Crash Processor Architecture


Universal binaries contain the executable for multiple processor architectures. Both the atos tool and the symbolizecrashlog script assume that the addresses being converted are for the architecture of the computer on which they’re running. For example, symbolizing a crash log that occurred on a Power Mac (PowerPC) using a Power Mac Pro (Intel) produces invalid results, because atosassumes that addresses apply to the Intel executable. You must tell atos to use the debugging symbols information that belongs to the “ppc” executable, instead. Both atos and symbolizecrashlog accept an -arch option to specify the architecture of the system that should be used to interpret the addresses. Listing 6 shows some examples.


atos -arch ppc TempConverter 0x00002b84


symbolizecrashlog -arch i386 TempConverter TempConverter.crash.log > TempConverter.symbolized.log


Listing 6: Specifying the Architecture when Using atos and symbolizecrashlog

2011年6月28日星期二

xcode instruments Allocations & Leaks

Allocations

The Allocations instrument tracks memory allocation for an application. This instrument requires that you launch a single process so that it can gather data from the start of the process.

This instrument captures the following information:

Category - typically a Core Foundation object, an Objective-C class, or a raw block of memory.
Net Bytes - the number of bytes of this type currently allocated but not yet released.
# Net - the number of objects or memory blocks of this type currently allocated but not yet released.
Overall Bytes - the total number of bytes of this type that have been allocated, including those that have been released.
# Overall - the total number of objects or memory blocks of this type that have been allocated, including those that have been released.
# Allocations (Net / Overall) - A histogram of the current and total counts. The bars are normally shades of blue. They are colored shades of yellow when the ratio between the total number of objects and the peak, or the ratio between the peak and the current number, is 1/3 or less. The bars are shades of red when the ratio is 1/10 or less.
Although the ratios displayed aren't necessarily bad (often, they're normal over the long run of an application), Instruments colors them to point out allocation patterns that may deserve a further look. If you see categories where the color is red or yellow, you might try to eliminate unnecessary temporary allocations of the given type in your application. Similarly, you might simply try to eliminate the high-water mark in the number of objects.

The data table in the details pane contains a Graph column, which contains a checkbox for each row in the table. When the checkbox for a given category is enabled, the instrument displays the graph for that particular category type in the Track pane. Instruments automatically assigns a color to each graphed category.

When you mouse over category names in the details pane, a more Info button appears next to the category name. Clicking this button displays detailed information about the objects in that category, including the following attributes:

The address of the block.
The function call or class that generated the allocation event. For example, you can see which method in a class retained an object.
The creation time of the object.
The library responsible for creating the object.
For any of these events, you can open the Extended Detail pane to see the stack trace for each object allocation, including the type of allocation and the time at which the event occurred.

For specific instances of an object (or memory block), you can click the more info button in the Object Address column to see the allocation events associated with that object. For each allocation event, this instrument displays the following information:

The category of the object (its type)
The event type.
The timestamp for each event.
The address of the block
The size of the block
The library responsible for allocating the block.
The function that caused the allocation event.
For any allocation event, you can open the Extended Detail pane to see the stack trace, as well as any available event information and the time at which the event occurred.

To further filter information in the Detail pane, you can configure the Allocation Lifespan options. These options let you filter the allocation events based on the following criteria:

All Objects Created - display all objects, regardless of whether they have been deallocated.
Created & Still Living - display only objects that existed in memory when you stopped recording data..
The inspector for the Allocations instrument lets you configure the way the instrument tracks information. From the inspector, you can set the following options:

Record reference counts. Use this option to track the reference count of each object.
Discard unrecorded data on stop. Use this option to discard any data that has been gathered but not yet processed by the Allocations instrument.
For additional information about the Allocations instrument, see “Analyzing Data with the Allocations Instrument.”

Leaks

The Leaks instrument examines a process’s heap for leaked memory. You can use this instrument together with the Allocations instrument to get memory address histories. This instrument requires that you launch a single process so that it can gather data from the start of the process.

This instrument captures the following information:

The number of leaks
The size of each leak
Address of the leaked block
Type of the leaked object
Each view mode in the Detail pane shows the leak data in a slightly different way. In table mode, this instrument shows the individual leaks along with the percentage that each individual leak contributes to the total amount of leaked memory discovered. In outline mode, the data is reorganized so that you can see how much memory is leaked from within a given symbol. For entries in either mode, the Extended Detail pane displays a heavy stack trace showing from where the leak originated.

For additional information about the Leaks instrument, see “Looking for Memory Leaks.”

2011年5月23日星期一

ios后台播放音乐


1. //后台播放
AVAudioSession *session = [AVAudioSession sharedInstance];
[session setActive:YES error:nil];
[session setCategory:AVAudioSessionCategoryPlayback error:nil];

2. 让后台可以处理多媒体的事件
[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];

Remote-control events originate as commands issued by headsets and external accessories that are intended to control multimedia presented by an application. To stop the reception of remote-control events, you must call endReceivingRemoteControlEvents.

3.系统进入后台运行时,让程序可以运行一段时间。使用此方法争取一定的时间,在程序进入后台后处理一些事情。
- (UIBackgroundTaskIdentifier)beginBackgroundTaskWithExpirationHandler:(void(^)(void))handler
This method lets your application continue to run for a period of time after it transitions to the background.
your application could call this method to ensure that had enough time to transfer an important file to a remote server or at least attempt to make the transfer and note any errors. You should not use this method simply to keep your application running after it moves to the background.

2011年4月16日星期六

uiimage 转换为像素数据 以及从像素数据生成为uiimage

生成RGBABitmapContext 

CGContextRef CreateRGBABitmapContext (CGImageRef inImage){
CGContextRef context = NULL; CGColorSpaceRef colorSpace;
void *bitmapData;
int bitmapByteCount;
int bitmapBytesPerRow;
size_t pixelsWide = CGImageGetWidth(inImage);
size_t pixelsHigh = CGImageGetHeight(inImage);
bitmapBytesPerRow = (pixelsWide * 4);
bitmapByteCount = (bitmapBytesPerRow * pixelsHigh);
colorSpace = CGColorSpaceCreateDeviceRGB();  if (colorSpace == NULL){
fprintf(stderr, "Error allocating color space");
return NULL;
}

// allocate the bitmap & create context
bitmapData = malloc( bitmapByteCount );
if (bitmapData == NULL){
printf (stderr, "Memory not allocated!");
CGColorSpaceRelease( colorSpace );
return NULL;
}

context = CGBitmapContextCreate (bitmapData,
pixelsWide,
pixelsHigh,
8,
bitmapBytesPerRow,
colorSpace,
kCGImageAlphaPremultipliedLast);

if (context == NULL){
    free (bitmapData);
    fprintf (stderr, "Context not created!");
 }

CGColorSpaceRelease( colorSpace );

 return context;

生成图片的像素数据

// Return Image Pixel data as an RGBA bitmap
unsigned char *RequestImagePixelData(UIImage *inImage) {

CGImageRef img = [inImage CGImage];
CGSize size = [inImage size];
CGContextRef cgctx = CreateRGBABitmapContext(img);
if (cgctx == NULL)
return NULL;

CGRect rect = {{0,0},{size.width, size.height}};
CGContextDrawImage(cgctx, rect, img);
unsigned char *data = CGBitmapContextGetData (cgctx);
CGContextRelease(cgctx);
return data;
}