记录遇到的小的知识点。

Tips

记录遇到的小的知识点。

frame/bounds/center/anchorPoint/position

一、view属性

1、 frame

相对父坐标系。

计算公式：

- (CGRect)frame
{
    float x = center.x - layer.anchorPoint.x * bounds.size.width;
    float y = center.y - layer.anchorPoint.y * bounds.size.height;
    float width = bounds.size.width;
    float height = bounds.size.height;
    return CGRectMake(x, y, width, height);
}

- (void)setFrame:(CGRect) rect
{
    center.x = rect.origin.x + layer.anchorPoint.x * rect.size.width;
    center.y = rect.origin.y + layer.anchorPoint.y * rect.size.height;
    bounds.size.width = rect.size.width;
    bounds.size.height = rect.size.height;
}

由此可见：

更改center、anchorPoint、bounds的值都会是frame的值发生对应改变；

更改frame的值会是bounds的值发生对应改变；

2、 bounds

相对本地坐标系。

2.1 origin

更改bounds的origin会改变当前view的子view的位置，具体原因见下图所示：

参考链接：http://www.xiaoyaoli.com/?p=1182

2.2 size

更改frame的时候会改变bounds的size，同样更改bounds的size的时候也会改变frame的size；

frame.size和bounds.size不一定能完全一致，比如在view旋转的时候，详情见下图：

参考链接：http://stackoverflow.com/questions/5361369/uiview-frame-bounds-and-center

3、 center

相对父坐标系。

更改frame的时候会改变center，同样更改center的时候也会改变frame的origin。

二、layer属性

1、 frame

对应view的frame

2、 bounds

对应view的bounds

3、 anchorPoint

默认值是(0.5，0.5);

是旋转、缩放等操作的中心点；

更改anchorPoint会改变frame的origin，但反过来更改frame不会改变anchorPoint的值。

4、 position

和center永远保持一致

字符编码

一、ASCLL

全称是American Standard Code for Information Interchange（美国信息交换标准代码）；

单字节编码，用一个字节（8个位）来表示一个字符，并保证最高位的取值永远为’0’；

最多表示2^7 =128个字符，这128个字符包括95个可打印的字符（涵盖了26个英文字母的大小写以及英文标点符号能）与33个控制字符（不可打印字符）；

二、中文编码

名称	GB2312	BIG5	GBK	GB18030
作用	国家简体中文字符集	统一繁体字符集	GB2312的扩展，加入对繁体的支持	中日韩文字编码
字节数	1字节-兼容ASCII 2字节-汉字	2字节	2字节	1字节-兼容ASCII 2字节，4字节
范围	7445个符号，包括6763个汉字	21886个符号	21886个符号	27484个符号
兼容性	00-7F范围内是1位，和ASCII兼容	兼容ASCII，但与GB2312冲突	兼容GB2312	兼容GB2312

三、Unicode

采用4个字节表示一个字符,这样理论上Unicode能表示的字符数就达到了2^31 = 2147483648 = 21 亿左右个字符，完全可以涵盖世界上一切语言所用的符号。

存在两个问题：

• Unicode对所有的字符编码均需要四个字节，而这对于拉丁字母或汉字来说是浪费的，其前面三个或两个字节均是0,这对信息存储来说是极大的浪费。

*另外一个问题就是，如何区分Unicode与其它编码，比如计算机怎么知道四个字节表示一个Unicode中的字符，还是分别表示四个ASCII的字符呢？

以上两个问题，让Unicode的推广上一直面临着困难。

四、UTF-8

UTF-8是Unicode的一种实现方式，而Unicode是一个统一标准规范，Unicode的实现方式除了UTF-8还有其它的，比如UTF-16等。

UTF-8在Unicode的基础上又两个基本规则：

• 对于单字节字符，字节的第一位为0，后7位为这个符号的Unicode码，所以对于拉丁字母，
  UTF-8与ASCII码是一致的。
• 对于n字节(n>1)的字符，第一个字节前n位都设为1，第n+1位为0，后面字节的前两位一律设为10，
  剩下没有提及的位，全部为这个符号的Unicode编码。

比如：

Unicode（十六进制）	UTF-8（二进制）
单字节：0000 0000-0000 007F	0xxxxxxx
双字节：0000 0080-0000 07FF	110xxxxx 10xxxxxx
三字节：0000 0800-0000 FFFF	1110xxxx 10xxxxxx 10xxxxxx
四字节：0001 0000-0010 FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

举例来说，’微’的Unicode是’\u5fae’，二进制表示是”00000000 00000000 01011111 10101110“，其取值就位于’0000 0800-0000 FFFF’之间，所以其UTF-8编码为’11100101 10111110 10101110’

需要注意的一点是Unicode(UTF-8)与GBK，GB2312这些汉字编码规则是完全不兼容的，也就是说这两者之间不能通过任何算法来进行转换,如需转换，一般通过GBK查表的方式来进行。

五、参考文档

• 字符编码常识及问题解析

ssh远程编译访问证书报User interaction is not allowed.错误解决方案

在编译前解锁keychain：

security show-keychain-info ~/Library/Keychains/login.keychain
if [[ $? != 0 ]]; then
    security unlock-keychain ~/Library/Keychains/login.keychain
    if [[ $? != 0 ]]; then
        echo
        echo "!!! unlock keychain failed"
        exit 4
    fi
fi

通常这就能解决问题了，如果还不行，就将keychain对应证书的访问权限改成下图所示：

参考链接：http://stackoverflow.com/questions/20205162/user-interaction-is-not-allowed-trying-to-sign-an-osx-app-using-codesign

Xcode Concepts

• Xcode Target

Target是project或者workspace中通过一系列文件去定义一个product的编译方式的最小单位。它将product的组成部分：源代码和编译说明文件组织在一起，以供编译器使用。一个project能包含若干个target，但是一个target只有一个product（编译结果）。

编译说明文件有两种形式：build settings 和 build phases（构建阶段）。Target的build settings是从 project中继承的，但是可以在target对应的build settings中重写那些继承项；但是build phases则是每个Target独有的。

每次只能通过Xcode scheme指定唯一一个活跃的target。

target之间可以相互关联，在同一个workspace中Xcode能自动处理target之间的依赖关系，这被称为隐式依赖；也可以指定target之间的显示依赖关系。

• Xcode Project

Xcode project包含了编译product所需的全部代码文件、资源文件、设置项。

Project可以包含若干个target。

Project会为所有Target指定一个默认的build settings选项。

• Xcode workspace

workspace可以包含若干个project以及 其它的文档。

• Xcode Scheme

Xcode scheme 是若干可编译的target、编译时的一些设置以及若干测试用例的集合。

scheme可以有很多个，但是只能有一个处于活跃状态。

scheme可以属于project，也可以属于workspace。

Apple关于deprecated方法的描述：

Deprecation does not mean the immediate deletion of an interface from a framework or library. It is simply a way to flag interfaces for which better alternatives exist. You can use deprecated APIs in your code. However, Apple recommends that you migrate to newer interfaces as soon as possible because deprecated APIs may be deleted from a future version of the OS. Check the header files or documentation of the deprecated API for information about any recommended replacement interfaces.

deprecated并不意味着该方法会立马被删除，而是它有了更好的替代方法。开发者需要尽快将标为deprecated的方法替换掉，因为Apple可能在将来的某个系统版本中会将其删除。

Base SDK and Deployment Target Settings

• Deployment Target

该设置项标识软件支持的最低系统版本。Deployment Target和比它早的系统的特性都可以无条件使用。

• Base SDK

标识应用能支持的最高系统版本。默认情况下Xcode会将该选项设置为当前最新的系统版本。

二者之间的关系如图所示：

PS:

• iOS或OS X 的SDK中的libraries仅仅用于链接，它们本身并不包含任何可执行文件。SDK只有和编译目标机器配合才能正常工作。
• 当使用Simulator SDKs编译的时候，生成的二进制文件只使用Base SDK指定的系统版本，即和Deployment Target指定的系统版本没有直接关系。

Mac，iOS界面中的坐标系

话说Mac,iOS中的各种坐标系总会让初学者摸不着头脑，一会儿这样一会儿那样。不过有一点是不变的，z轴的正方向总是指向观察者，也就是垂直屏幕平面向上。

1.NSView坐标系
在Mac中NSView的坐标系默认是右手坐标系（View其实是二维坐标系，但是为了方便我们可以假设其是三维坐标系，只是所有界面的变化都是在xy平面上），原点在左下角. NSView提供了一个可以用于覆盖的方法

- (BOOL)isFlipped;

此默认返回NO，当返回YES的时候，则坐标系变成左手坐标系，坐标原点变成左上角。

在Mac的AppKit中有很多界面组件本身就使用了Flipped Coordinate System(覆盖了上面的方法并返回YES)，如NSButton，NSTableview，NSSplitView 更详细的看这里 其中Cocoa Use of Flipped Coordinates 这一节 https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html

2.UIView坐标系
而在iOS的UIView中，则没有所谓的Flipped Coordinate的概念，统一使用左手坐标系，也就是坐标原点在左上角.

3.Quartz坐标系
Quartz（Core Graphics）坐标系使用的右手坐标系,原点在左下角,所以所有使用Core Graphics画图的坐标系都是右手坐标系，当使用CG的相关函数画图到UIView上的时候，需要注意CTM的Flip变换，要不然会出现界面上图形倒过来的现象。由于UIKit的提供的高层方法会自动处理CTM（比如UIImage的drawInRect方法），所以无需自己在CG的上下文中做处理。 参见Quartz 2D Coordinate Systems

4.CALayer坐标系
这个有些变态了，其坐标系和平台有关，在Mac中CALayer使用的是右手坐标系，其原点在左下角；iOS中使用的左手坐标系，其原点在左上角。 参见 Layer Coordinate System

引至：http://geeklu.com/2012/06/3d-coordinate-system/

hit-test

• 流程

hit-test使用的是逆序递归遍历法：

It implements it by searching the view hierarchy using reverse pre-order depth-first traversal algorithm.

比如window上先后添加了A、B、C三个view：

那么屏幕上任何一点发生触摸事件时都会按如下顺序遍历：

** C 如果在C上继续递归遍历C的subview，不在C上则遍历B
** B 如果在B上继续递归遍历B的subview，不在B上则遍历A
** A 如果在A上继续递归遍历A的subview，不在A上则遍历A的上一级

直到找到一个包含点击区域的最上层view。

• 关于多次调用hit-test

** iOS6 及之前系统会重复调用三次hit-test流程；
** iOS7 及之后系统会重复调用两次hit-test流程。

调用那么多次的原因不明。

• 关于UITabbarController

点击包含UITabBar、UIToolBar等控件上方40像素区域内时，多次hit-test的最后一次中point值会发生随机变化，point的Y值会被增大若干不等的像素。

原因未知。

参考链接： Hit-Testing in iOS

升级Xcode插件失效解决办法

• 查看Xcode对应版本的UUID：

tail -f /var/log/system.log

• 更新插件配置文件

得到UUID后执行命令：

find ~/Library/Application\ Support/Developer/Shared/Xcode/Plug-ins -name Info.plist -maxdepth 3 | xargs -I{} defaults write {} DVTPlugInCompatibilityUUIDs -array-add XCode_UUID

• 参考链接：

XCode升级后插件失效的原理与修复办法