原生应用 vs HTML 5

标签:HTML, JavaScript, iOS开发

这几个月都在开发知乎日报的后端,让我对移动应用的开发有了更多的认识。

简单来说,我以前一直都认为原生应用才是王道,现在则觉得 HTML 5 才是未来。

为UIWebView实现离线浏览

标签:Objective-C, iOS开发

智能手机的流行让移动运营商们大赚了一笔,然而消费者们却不得不面对可怕的数据流量账单。因为在线看部电影可能要上千块通讯费,比起电影院什么的简直太坑爹了。
所以为了减少流量开销,离线浏览也就成了很关键的功能,而UIWebView这个让人又爱又恨的玩意弱爆了,居然只在Mac OS X上提供webView:resource:willSendRequest:redirectResponse:fromDataSource:这个方法,于是只好自己动手实现了。

原理就是SDK里绝大部分的网络请求都会访问[NSURLCache sharedURLCache]这个对象,它的cachedResponseForRequest:方法会返回一个NSCachedURLResponse对象。如果这个NSCachedURLResponse对象不为nil,且没有过期,那么就使用这个缓存的响应,否则就发起一个不访问缓存的请求。
要注意的是NSCachedURLResponse对象不能被提前释放,除非UIWebView去调用NSURLCache的removeCachedResponseForRequest:方法,原因貌似是UIWebView并不retain这个响应。而这个问题又很头疼,因为UIWebView有内存泄露的嫌疑,即使它被释放了,也很可能不去调用上述方法,于是内存就一直占用着了。

顺便说下NSURLRequest对象,它有个cachePolicy属性,只要其值为NSURLRequestReloadIgnoringLocalCacheData的话,就不会访问缓存。可喜的是这种情况貌似只有在缓存里没取到,或是强制刷新时才可能出现。
实际上NSURLCache本身就有磁盘缓存功能,然而在iOS上,NSCachedURLResponse却被限制为不能缓存到磁盘(NSURLCacheStorageAllowed被视为NSURLCacheStorageAllowedInMemoryOnly)。
不过既然知道了原理,那么只要自己实现一个NSURLCache的子类,然后改写cachedResponseForRequest:方法,让它从硬盘读取缓存即可。

获取iOS设备的内存状况

标签:iOS开发

由于iPhone这类移动设备内存有限,而又不能使用交换区,为了不至于导致内存不足而引起运行效率降低或应用崩溃,有时候需要获取当前的内存状况,以决定采用的缓存策略。
不过iOS SDK文档里并没有提及这种底层的API,于是我搜了一番,找到了host_statistics()这个函数。

自定义iPhone的状态栏

标签:Objective-C, iOS开发

用过Reeder的应该都会发现,在进行同步时,右上角会出现一个自定义的图标。而在点击它时,就会向左扩张覆盖住原状态栏,并显示同步状态。
这个设计非常巧妙,因为传统的设计在显示状态时,往往会占用掉几十像素;而在阅读时,用户非常希望主要内容能占据更多的空间。
那么这个设计是怎么实现的呢?下面就来模拟一下。

关于Core Animation的一些初步探索

标签:Objective-C, iOS开发

所谓Core Animation,顾名思义就是用来做动画的,它包含了一些Objective-C类,这些类都在Quartz Core框架中。
用它的原因也无需多说,首先是性能很好,使用了GPU硬件加速;其次是接口易用,毕竟是Objective-C,不需要像OpenGL ES一样完全和C打交道。
不过要掌握它也很费劲,这2天就遇到了不少问题,于是记录在此。

让ASIHTTPRequest不占用主线程

标签:Objective-C, iOS开发

ASIHTTPRequest是个很易用的iOS / Mac OS X平台的HTTP库,比NSURLRequest好用多了,所以我一直在用它。
不过使用中我发现,当下载线程数超过2时,就会影响到主线程响应用户请求的速度了。好奇之余我测试了一下completionBlock,发现它总是在主线程调用,而NSOperation的文档中却说一般会在子线程中执行。

优化UITableView性能

标签:Objective-C, iOS开发

在iOS应用中,UITableView应该是使用率最高的视图之一了。iPod、时钟、日历、备忘录、Mail、天气、照片、电话、短信、Safari、App Store、iTunes、Game Center⋯几乎所有自带的应用中都能看到它的身影,可见它的重要性。
然而在使用第三方应用时,却经常遇到性能上的问题,普遍表现在滚动时比较卡,特别是table cell中包含图片的情况时。
实际上只要针对性地优化一下,这种问题就不会有了。有兴趣的可以看看LazyTableImages这个官方的例子程序,虽然也要从网上下载图片并显示,但滚动时丝毫不卡。
下面就说说我对UITableView的了解。不过由于我也是初学者,或许会说错或遗漏一些,因此仅供参考。

利用预渲染加速iOS设备的图像显示

标签:Objective-C, iOS开发

最近在做一个UITableView的例子,发现滚动时的性能还不错。但来回滚动时,第一次显示的图像不如再次显示的图像流畅,出现前会有稍许的停顿感。
于是我猜想显示过的图像肯定是被缓存起来了,查了下文档后发现果然如此。
后来在《Improving Image Drawing Performance on iOS》一文中找到了一些提示:原来在显示图像时,解压和重采样会消耗很多CPU时间;而如果预先在一个bitmap context里画出图像,再缓存这个图像,就能省去这些繁重的工作了。

iOS开发之免改hosts翻墙

标签:Objective-C, iOS开发, GFW

在开发iOS的web应用时,不可避免地会遇到一些被墙的网站。使用VPN或代理服务器自然是可以解决的,不过成本比较高。而Google的大部分服务都有很多IP,可以通过修改hosts文件来翻墙访问,但在iOS设备上却需要用户去越狱才能修改,显得颇为不便。
好在HTTP请求其实也是使用socket,在请求前要用socket连接服务器,提供域名/IP和端口,这里只要改成可用的IP就能连上了。在连接之后,还要提供访问方法、路径、Host等其他头字段,这里只要把Host改成原本的域名即可。

« 看看还有什么好玩意