问：canvas.drawText("3", x, y, paint); x和y是指画得时候数字3中心的坐标吗？还是左上角的坐标？
x答：默认是‘3’这个字符的左边在屏幕的位置，如果设置了paint.setTextAlign(Paint.Align.CENTER);那就是字符的中心，y是指定这个字符baseline在屏幕上的位置。
public void drawText (String text, float x, float y, Paint paint)
Since: API Level 1 Draw the text, with origin at (x,y), using the specified paint.
The origin is interpreted based on the Align setting in the paint.
Parameters
text The text to be drawn
x The x-coordinate of the origin of the text being drawn
y The y-coordinate of the origin of the text being drawn
paint The paint used for the text (e.g. color, size, style)
Key-Value Observing (简写为KVO)：当指定的对象的属性被修改了，允许对象接受到通知的机制。每次指定的被观察对象的属性被修改的时候，KVO都会自动的去通知相应的观察者。
因为KVO模式本身获得了框架级别的支持，所以开发人员不需要自己设计观察者模式，不用添加额外的代码，使用方便。
KVO模式的工作原理:
如果A对象希望在B对象的一个特定属性改变时，获得通知消息，就需要使用 addObserver:forKeyPath:options:context进行注册。
addObserver:forKeyPath:options:context:”方法在指定对象实例之间建立了一个连接。这个连接不是两个类之间建立的，而是两个对象实例之间建立的连接。
同时，为了能够响应消息，对象A必须实现“observeValueForKeyPath:ofObject:change:context:”方法。这个方法实现如何响应变化的消息。在这个方法里面我们可以跟自己的情况，去实现应对被观察对象属性变动的相应逻辑。
这样当对象B的特定属性改变时，就会回调对象A中observeValueForKeyPath:ofObject:change:context方法里面的逻辑, 实现了KVO模式过程。
示例代码如下:
- (void)viewDidLoad
{
[super viewDidLoad];
_label = [[UILabel alloc] initWithFrame:CGRectMake(20, 50, 50, 30)];
_label.textAlignment = NSTextAlignmentCenter;
_label.font = [UIFont systemFontOfSize:20];
[self.view addSubview:_label];
[self addObserver:self forKeyPath:@"textvalue" options:0 context:nil]; //注册
[self setValue:[NSNumber numberWithInt:2] forKey:@"textvalue"];
}
// 监听回调
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
if ([keyPath isEqualToString:@"textvalue"]){
NSNumber* num = [self valueForKey:@"textvalue"];
_label.text = [NSString stringWithFormat:@"%d",[num integerValue]];
}
}
有一些我曾经共事过的程序员，他们极其的聪明，但也极端的古怪离奇。
“古怪离奇”也许用来形容一个事件或一个观点更合适。也许称这类型的人为书呆子更合适。但不管怎样，我的印象中，大多数时候，他们并不会带来太大的麻烦。
并不是他们的脑瓜不灵。很多时候，这些“优秀”的程序员往往是团队中最有能力的。他们的智商和解决问题的能力都是其他人无法企及的。
很多时候，他们是公司里能够解决那些将会让公司损失百万美元问题的唯一的人。当然，大多数情况是因为最初他们参与了开发设计或给了最初的指导。
如果是他们自己故意制造了这将要到来的灾难，我一定都不会吃惊，这样一来他们就能成为救世的英雄。
不幸的是，在众多的IT企业文化中，英雄崇拜是普遍现象。一个明显不合群的程序员但却会被经理们高捧在众人之上。
管理者们需要在意这样的程序员吗？我曾在以前的文章里谈到过这样恃才放旷的程序员，比如Tyler——无视规定，破坏团队建设。是的，我相信管理者绝对应该重视他们，因为他们会影响到团队其他人员，影响到整个团队，他们会给团队带来长久的不确定的风险。
可问题是，管理者们喜欢依赖于这样的有才华的程序员，把他们当作中流砥柱。
我以前也这样过，现在想起来内心有愧。你很容易陷入这种境地，你会因此悔断肠子，因为他们会让你丢掉工作。
这些年来，我曾和很多种这样极富挑战型性格的人共事过。我这里选一个有代表性的例子：我向你保证，乔希绝对是一个真实存在的人；但我给他起了另外一个名，以免他发癫到我家来找我。
我第一次见到他是在我新上任第一天处理一个危机的时候。乔希在我之前很多年就来了这个公司。我们的团队的任务是解决公司的软件产品中的各种问题。
我们当时都在会议室里，免提电话里传来客户的咆哮。他已经受够我们的产品环境中的一个迟迟不能解决的问题，威胁要取消订单。
于是我把乔希叫了进来，他就是产生这个问题的程序的开发者——更像是个主谋。一般情况下，没有人会把乔希带到客户面前，因为他的外表，怎么说呢，让人想起Charlie Brown卡通中邋遢的Pigpen。
我知道这不是可视电话(也不会传导气味)，所以应该没问题。而且毫无意外，乔希一个小时内就解决了这个问题。客户得到了安抚，我也松了口气，避免了在我的管理下丢失客户。
我问技术支持小组的技术负责人，问什么乔希一个小时解决了这个问题，而我们的团队花了两天时间都解决不了？回答让我震惊。
他说“我昨天问了乔希，向他求助，但他笑我。他说如果我们没有能力解决这个问题，那我就不配待在这里。”
我的这个技术负责人继续解释说，尽管他翻遍了所有产生错误的程序代码，问题实在让人费解，他查不出问题出在哪。我问程序的文档在哪，他转着眼珠，不自然的傻笑，“什么文档？”
先对乔希的背景做一下介绍。他有时会穿印有挑衅性标语的T恤。上班时你有时会找不到他，甚至好几天。
不止一次我身边的女同事说他在她们面前说脏话。然而，他仍然在这个公司里，而且是拿的薪水最高的程序员。
我决定跟乔希聊一聊。当走进他的办公室时(他是唯一一个有私人办公室的程序员)，我感觉需要拿着一个手电筒，因为太黑了。更像是个洞穴，而不是办公室。
宁愿找个衣服夹夹住我的鼻子。
我记不清确切的说了哪些话，但过程大概是这样的。
“你好，乔希”，我说，声音尽量轻松高兴。
静悄悄。
乔希依旧狂暴的敲着他的键盘。我继续说，“嗯，乔希，我能占用你一分钟时间谈谈客户发现的那个问题吗？”
他没有停下来，嘴动了一下，“你说。”
“我想说的是谢谢你解决了那个问题，但我也知道，昨天我的团队向你求助时，你不肯帮他们。”
乔希，注意力并没有从键盘上移开，支吾了一句“怎了？”
“我想知道，你为什么不肯帮他们？”
“我很忙，”他爱理不理的说。
“我知道，但如果你能帮一下….”
他打断我，语气中带着轻蔑的说“帮他，让我去向那个白痴去解释如何做他的工作？我写我的代码。我的代码好用。over。”
我不知道这次谈话怎么结束的，而且，这不太像是一次谈话。我决定找乔希的经理谈一谈。
我一提起这个话题，他的经理噌的站起来去关上了她办公室的门。
她说，“小心，你应该放弃这个念头。这是乔希。他喜怒无常，如果我不全力支持他，他随时都会拍屁股走人。他写代码的速度比团队里任何一个人都快。”
我试图向她解释，乔希应该融进团队中，写的程序也应该有文档。她的回答是，有能力的程序员都不需要文档。
“代码”就是文档。她根本无视整个“团队”的抱怨。
随后她笑了，说，“我直说吧，如果没了乔希，我们就不能按时完成下一次的发布，我也就不能坐在这里了。over。”
一天内两次“over”。可是，这事儿没这么就over了。当有更多的客户方面的问题出现后，CEO出面并强行解决了这个问题。
你猜在CEO和乔希的谈话后发生了什么？第二天他没来上班。他走时甚至没有拿走留在办公室里的东西。
他就这样….失踪了。
跟着他走的还有他掌握的对那些复杂(杰出)的代码的理解。一大群优秀的和“水平一般”的程序员最终把这留下的烂摊子整理清楚，但公司为此耗费了大量的时间和金钱。
我们可以称乔希这样的程序员为怪胎，疯子，或蛮不讲理，可毫无疑问，他们的智商是高人一等的。但是，如果你一直任着他们这样下去，他们迟早会成为你公司，团队或事业上的定时炸弹。