石锅拌饭

Tag: iphone

忙碌的一周

by on May.24, 2009, under Uncategorized

预告过了, 这周主要参加了两个活动.

周四在上海的Ruby Conference China 2009, 可以说相当成功.

Matz 绝对是现场最耀眼的明星, 他的演讲非常有趣, 充满了程序员的智慧. 他提到编程语言应该有common sense, 程序员即使是在为生计编程, 也不应该放弃对fun的追求. 每个ruby程序员都知道这不是泛泛的说道, 因为我们都能确切的体验到这种common sense,以及ruby编程给我们带来的快乐. 以前听过Bjarne Stroustrup和James Goslin的演讲, 和这些编程语言之父面对面的交流总是让人有颇多的收获.

javaeye的Robbin Fan的演讲也非常精彩, 分享的内容是国内ruby/rails社区极为宝贵的经验. 有一个小插曲, Robbin演讲当中, 接到了一个网警要求删贴的电话, 不得不马上处理. 老大哥的无处不在让人啼笑皆非. 另外, 这次上海之行, 看到这样一个没有做太多宣传的活动, 一下就聚集了全国各地四百多人, 会上会下都以javaeye会员相称, 着实见识了一下javaeye的号召力.

借这次活动, 看到了ThoughtWorks的郑烨, 图灵的刘江老师, 杭州的ashchan, Kernel1983, 吕国宁等等很多神交已久的朋友, 也结识了象薄荷网的谢文威等等的新朋友, 可谓不虚此行.

今天下午在奇遇花园技术沙龙也不错, 来了不少人, 对iPhone感兴趣的人还不少. 因为Tinyfool告诉我最好不要超过二十分钟, 所以没有准备太多内容, 做开发的可能会觉得没啥意思, 不做开发的可能又觉得太偏技术,不过最后回答了一些大家的问题,也算有点补偿了. 其实技术沙龙就应该是这样, 上面讲的人只是抛砖引玉, 大家的交流才最关键. 我自己的体会也是这样, 每次奇遇花园的活动, 讲座不过是热个身, 后面的闲聊才是黄金时段. 这是今天演讲的文档, 内容不多, 有兴趣的可以下载来看看:
iPhone开发经验谈

5 Comments :, , , more...

MacWorld reviews BuddyFeed!

by on May.15, 2009, under Uncategorized

一直以来,都把在mac和iphone做cocoa编程当成业余爱好,是自己的20% projects。要做什么,首先肯定是自己要用的,能做到自己满意也就差不多了。

做BuddyFeed也是这样。觉得在iPod Touch上看完twitter,看完google reader,好像还想读点东西,FriendFeed刚好是个不错的选择,但是一直都不太喜欢FriendFeed以前的界面,就干脆自己为iphone/ipod touch做了这个客户端程序。界面设计上我也没有太多想法,第一版借鉴Twitterrific和Twittelator多一些,后来老用Tweetie,觉得它的界面更合理,第二版就更多借鉴了Tweeite的设计。

上周末新版通过审核发布了。昨天晚上,突然看到MacWorld的iPhone Central频道review了BuddyFeed 2.0,虽然以前在Marshable和其它一些blog也有过,但从来不会想到MacWorld,所以还是惊喜了一下。基本上一个业余cocoa coder的虚荣心已经完全得到满足了。

7 Comments :, more...

下周的两个活动

by on May.14, 2009, under Uncategorized

下周准备参加两个活动.

一个是五月二十一号在上海的Ruby Conference China 2009. 终于有人走出这第一步了. 很佩服javaeye和Shanghai Rails Group的勇气. 虽然我们并没有什么在技术性会议上做宣传的需求, 也没有太多的钱, 但还是希望能和大会组织者一起, 为国内Ruby社区尽一点点力. Louie和我会在二十号到达上海, 二十二号返回. 其实比起Matz, 更想见见南方ruby圈子里的朋友. 希望到时候可以见到大家.

第二个活动是beta技术沙龙第四期[iPhone开发入门]. beta技术沙龙是一个在奇遇花园每月一次的聚会,每次会有一个主题,几个主讲,但更主要的是大家互相之间的交流. 这次的主题是iPhone开发, 银杏的Tinyfool和我主持这次活动, 我们各作一个二十分钟左右的演讲, 然后大家可以一起聊一聊, 有什么感兴趣或者疑惑的问题可以现场切磋.

2 Comments :, , more...

小议iPhone OS 3.0

by on Mar.18, 2009, under Uncategorized

今天凌晨,苹果宣布了iPhone OS 3.0 。上午起来看了视频,又翻了翻文档。从开发者的角度,说说我比较感兴趣的几个更新。

Apple Push Notification Service

一直被当作后台运行程序的替代品。仍然不能有后台运行程序,解释的也很清楚了,是耗电量和待机时间不允许。但可以通过Push来唤醒应用程序。这种方式的特点是无触发不执行,执行是被动的。虽然不可能100%解决所有后台运行程序的需求,但也算提供了一种比较通用的模式。

基本原理如下图所示:
Remote Notif Simple.Jpg
先将消息推送给Apple的APNS,由它转发到相应的iPhone上,再由iPhone OS通知到相应的程序。

可以看到,所有的消息都不是通过网络直接发送到iPhone,而是通过苹果的APNS服务转发的。这将对APNS服务有很高的要求。这也是苹果一再推迟这一功能的原因。以往年苹果网络服务的经验来看,这个服务在推出以后也许要经过一段时间才会稳定。希望苹果这次是有备而来吧。

Accessory Support

我个人认为这个功能是这次升级的一个亮点,有极大的想像空间。附属外设可以通过30-pin连接头或者蓝牙接入。我大概看了下文档,和我想像的有些出入的地方是,附属设备必须预先支持iPhone,即使用蓝牙接入方式也一样。iPhone OS 3并没有象Mac OS X 10那样,提供一个完全的蓝牙API,而是做了更高层次的封装,只有符合协议(技术层协议)的设备才能接入。想通过iPhone OS 3直接读取Wii Balance Board 中的数据目前还不可行。

In App Purchase Support

商业模式上的扩展。SDK中新加入了Store Kit 。苹果还是挺狡猾的。这个事情,它不做,总有人会做,与其让别人做,不如自己先做了,还能再收个30%。对于最终用户,直接使用iTunes帐号付款也比再引入一个付款方式要简便,也许不少应用不得不因此屈尊交这笔苹果税了。

Peer to Peer Support

这一功能是以Game Kit的方式加入的,不过苹果一再声明完全可以用在非游戏的应用上。这一功能建立在蓝牙之上的,但同样做了封装,应用仍然无法直接和蓝牙接口打交道。连接服务以session的方式维护,一个应用可以这个P2P网络中扮演三种角色,server, client, 或者peer(server+client)。两个设备之间只能有一条蓝牙连接,但是在这一个连接上可以支持多个sessions的服务。传输内容并不受限制,可以自己定义。

Core Data

其实我们早就可以在iPhone中使用SQLite,不过到iPhone OS 3,才有了类似Mac OS X中的Core Data 。这意味着,对开发者来说,使用SQLite的门槛降低了。其他好像也没什么了。

2 Comments : more...

iPhone开发内存管理

by on Mar.03, 2009, under Uncategorized

开发iPhone 应用程序并不难,基本上就是三个词 – “memory, memory, memory” 。iPhone OS 对内存的要求很严格,有memory leak ,杀掉; 内存使用超限额,杀掉。一个经过测试的程序,在使用过程中90%以上的崩溃都是内存问题造成的。在这里简单总结一下Object-C 内存管理。

基本概念

Object-C 的内存管理基于引用计数(Reference Count)这种非常常用的技术。简单讲,如果要使用一个对象,并希望确保在使用期间对象不被释放,需要通过函数调用来取得“所有权”,使用结束后再调用函数释放“所有权”。“所有权”的获得和释放,对应引用计数的增加和减少,为正数时代表对象还有引用,为零时代表可以释放。

函数

获得所有权的函数包括

  • alloc – 创建对象是调用alloc,为对象分配内存,对象引用计数加一。
  • copy – 拷贝一个对象,返回新对象,引用计数加一。
  • retain – 引用计数加一,获得对象的所有权。

另外,名字中带有alloc, copy, retain 字串的函数也都认为会为引用计数加一。

释放所有权的函数包括

  • release – 引用计数减一,释放所有权。如果引用计数减到零,对象会被释放。
  • autorelease – 在未来某个时机释放。下面具体解释。

autorelease

在某些情况下,并不想取得所有权,又不希望对象被释放。例如在一个函数中生成了一个新对象并返回,函数本身并不希望取得所有权,因为取得后再没有机会释放(除非创造出新的调用规则,而调用规则是一切混乱的开始),又不可能在函数内释放,可以借助autorelease 。所谓autorelease , 可以理解为把所有权交给一个外在的系统(这个系统实际上叫autorelease pool),由它来管理该对象的释放。通常认为交给 autorelease 的对象在当前event loop 中都是有效的。也可以自己创建NSAutoreleasePool 来控制autorelease的过程。

据苹果的人说,autorelease效率不高,所以能自己release的地方,尽量自己release,不要随便交给autorelease来处理。

规则

引用计数系统有自己的引用规则,遵守规则就可以少出错:

  • 获得所有权的函数要和释放所有权的函数一一对应。
  • 保证只有带alloc, copy, retain 字串的函数才会让调用者获得所有权,也就是引用计数加一。
  • 在对象的 dealloc函数中释放对象所拥有的实例变量。
  • 永远不要直接调用dealloc来释放对象,完全依赖引用计数来完成对象的释放。

有很多类都提供“便利构造函数(convenience constructors)”,它们创建对象但并不增加引用计数,意味着不需要调用release来释放所有权。很好辨认,它们的名字中不会有alloc和copy。

只要遵守这些规则,基本上可以消除所有Intrument可以发现的内存泄露问题。

容器

类似NSArray, NSDictionary, NSSet 等类,会在对象加入后引用计数加一获得所有权,在对象被移除或者整个容器对象被释放的时候释放容器内对象的所有权。类似的情况还有UIView对subview的所有权关系,UINavigationController对其栈上的controller的所有权关系等等。

其他所有权的产生

还有一些用法会让系统拥有对象的所有权。比如NSObject 的performSelector:withObject:afterDelay 。如果有必要,需要显示的调用cancelPreviousPerformRequestsWithTarget:selector:object: ,否则有可能产生内存泄露。

因这种原因产生的泄露因为并不违反任何规则,是Intrument所无法发现的。

循环引用

所有的引用计数系统,都存在循环应用的问题。例如下面的引用关系:

  • 对象a创建并引用到了对象b.
  • 对象b创建并引用到了对象c.
  • 对象c创建并引用到了对象b.

这时候b和c的引用计数分别是2和1。当a不再使用b,调用release释放对b的所有权,因为c还引用了b,所以b的引用计数为1,b不会被释放。b不释放,c的引用计数就是1,c也不会被释放。从此,b和c永远留在内存中。

这种情况,必须打断循环引用,通过其他规则来维护引用关系。比如,我们常见的delegate往往是assign方式的属性而不是retain方式的属性,赋值不会增加引用计数,就是为了防止delegation两端产生不必要的循环引用。如果一个UITableViewController 对象a通过retain获取了UITableView对象b的所有权,这个UITableView对象b的delegate又是a, 如果这个delegate是retain方式的,那基本上就没有机会释放这两个对象了。自己在设计使用delegate模式时,也要注意这点。

因为循环引用而产生的内存泄露也是Instrument无法发现的,所以要特别小心。

一些和内存管理相关的有用内容:
Practical Memory Management
Reference counting

8 Comments :, more...

Search

Archives

Browse by tags

agile apple blog book design ecto extension firefox git google hack ichm iphone keyword life mac madfox movie nonsense opensource plugin pm ruby rubyonrails sns software startup wordpress work 财帮子