对比iOS中的四种数据存储

本文首发于InfoQ中文站

你是用什么方法来持久保存数据的?这是在几乎每一次关于iOS技术的交流或讨论都会被提到的问题,而且大家对这个问题的热情持续高涨。本文主要从概念上把“数据存储”这个问题进行剖析,并且结合各自特点和适用场景给大家提供一个选择的思路,并不详细介绍某一种方式的技术细节。

谈到数据储存,首先要明确区分两个概念,数据结构和储存方式。所谓数据结构就是数据存在的形式。除了基本的NSDictionary、NSArray和NSSet这些对象,还有更复杂的如:关系模型、对象图和属性列表多种结构。而存储方式则简单的分为两种:内存与闪存。内存存储是临时的,运行时有效的,但效率高,而闪存则是一种持久化存储,但产生I/O消耗,效率相对低。把内存数据转移到闪存中进行持久化的操作称成为归档。

二者结合起来才是完整的数据存储方案,我们最常谈起的那些:SQLite、CoreData、NSUserDefaults等都是数据存储方案。当然在这些框架提供的方案之外,我们自己也可以按照个性化需求订制方案。这些存储方案侧重不同,支持的形式和方式也各不相同,在不同的使用场景下表现也是各有优劣。但万变不离其宗,无论什么方案都可以用下图来解释。

图1,存储方案示意图

- 阅读剩余部分 -

对比iOS网络组件:AFNetworking VS ASIHTTPRequest

本文首发于 InfoQ中文站

在开发iOS应用过程中,如何高效的与服务端API进行数据交换,是一个常见问题。一般开发者都会选择一个第三方的网络组件作为服务,以提高开发效率和稳定性。这些组件把复杂的网络底层操作封装成友好的类和方法,并且加入异常处理等。

那么,大家最常用的组件是什么?这些组件是如何提升开发效率和稳定性的?哪一款组件适合自己,是 AFNetworking(AFN)还是 ASIHTTPRequest(ASI)?几乎每一个iOS互联网应用开发者都会面对这样的选择题,要从这两个最常用的组件里选出一个好的还真不是那么容易。

单单从两个控件版本提交的时间节点来看,AFN的第一个提交是2011年的1月1日,那个时候ASI早已是1.8+的版本了;而当AFN发布1.0版,2012年10月份的时候,ASI早早的已经停止更新了。这样看起来,AFN是ASI的继任者,似乎不存在之前提到的选择困难的问题,而事实并非如此。本文将从用法、功能、性能和原理几个方面对二者进行简单对比,看看二者之间到底存在着怎样的区别,到底应该如何选择。

- 阅读剩余部分 -

iOS应用2.0版怎么做

首发于InfoQ中文站

移动互联网如火如荼,iOS 应用+ Android 应用+ 手机站似乎成了所有互联网公司的标配,你的网站要是还没有个iOS 应用,似乎都不好意思跟人打招呼。

iOS 应用诞生毕竟才只有不到5年的时间,各个方面还都处在起步阶段。不管是出于团队缺乏经验,还是那个“唯快不破”的铁律,往往这些iOS 应用的第一个版本都比较简陋,尤其在技术架构上。这篇文章,我想跟大家探讨的就是这个问题,当你的iOS应用已经有一个版本在线的情况下,如何去构建一款可以支持高效迭代,快速响应的2.0版。 首先,应用的架构要层次清晰。把不依赖版本更新变化的,以来版本更新变化的,不需要变化的,业务逻辑,视图逻辑,工具,等这些内容梳理清楚,单独处理。


图1,应用整体架构

- 阅读剩余部分 -

善用iOS App中webview

iOS开发中webview和native code写这是一件纠结的事。我写这篇文章, 介绍一下我做iOS两年来总结的一些在webview和native code的配合上的一些经验和技巧,当然,都是基于互联网App的,希望对大家有所帮助。

首先提两句两者的优劣。webview与运维成本低, 更新几乎不依赖App的版本;但在交互和性能上与跟native code有很大差距。native code与之对应。

注,我这里不说HTML5,因为我认为,HTML5确实给web带入了一个新时代。这个时代是什么,web app。也就是说,只有脱离native的这个前提,在浏览器的环境下,HTML5的意义才能显现,而我们讨论iOS App的时候,HTML5显然没什么意义。

不管是用webview还是native code,我有两个原则:

1,用户体验不打折
2,运维成本低

注,为什么不提开发成本。因为做web开发和iOS开发根本就是两回事。当然,web开发发展了这么多年,对于某些功能实现是要比native app快。但多数情况,同一个功能,对于iOS开发者和web开发者,用各自擅长的方式开发成本都最低,所以说某个功能开发成本低,往往是一个伪命题。

刚刚说了,webview的优势在于更新不依赖版本,那么在一款App中,只有会频繁更新的界面考虑webview才有意义。那么哪些界面会频繁更新,这就要因App而异了,我只说两年来,我接触到的一些。

首页。首页资源可谓必争之地,内容一天一换是正常现象,一天几换也不稀奇。而如果仅仅是内容的更换,非要上个webview就显得有些激进了。而事实上首页的变化千奇百怪,逢年过节变个脸,特殊情况挂个公告,偶尔还要特批强推一把某个业务,等等。
此前,我在设计App首页的时候,把首页配置设计的非常复杂。App端要处理n种情况,n各参数,server端要记住n种规则,直到一天,我崩溃了,把首页完全换成webview,才豁然开朗。

活动页。做互联网都知道,活动,是一个最常见的运营手段。特点是,周期短,功能少,但基本不能复用。这些特点都标识了活动不适合做native,要用webview实现。
即使有人告诉你说,我的活动是一个长期活动而且形式不变,也不要相信他。因为在第二期,第三期,第四期他会分别加上一些非常诡异,却有很合理的小变更,而这些变更是你在那个版本根本无法实现的。

试水的新功能。这种界面,往往设计不成熟,需要在运行过程中不断收集用户反馈,更新升级,甚至决定去留。所以,只有webview才能hold住如此不稳定的功能。
切记在一个功能还没有确定之前,不要大张旗鼓单位开发native code,要知道,你写的这些代码,三天后就要改一遍,而且要发布上线。

富文本内容。这个不用多说了吧,按照HTML的常用标签做一个webtext可不是小工程。而且富文本的变化太多了,一点无法匹配,都会导致整个界面巨丑。

OK,上边说了我认为最该使用webview的4个界面,分别带有不同的特点,用这些特点去描述一个界面,如果符合了,那么别犹豫了,做成webview吧。说了哪些界面做成webviev,再说说怎么做webview才能避其短处。

刚刚说了,webview的交互是个短板,因此webview在一个App中,只能作为界面,不允许在界面中出现动作。

而一个webview的界面如何跟native code结合起来呢,我的答案是,超链接。在webview上点击超链接,会调用webview delegate的shouldload方法,自这里拦截请求,进行处理。这里附上这种方法的说明,此前的一文:http://pingguohe.net/2011/06/25/webview_to_nativeview/

由于webview的链接都是URL,因此我建议,把整个App的界面都用URL管理起来。从320框架对VC的管理中获得灵感,构建一个新的应用,总是先制定一套协议,封装一个方法,每一次VC的切换都通过URL。如此一来,server与App的交互就简单了许多,webview也如是。

最后就是长相问题,webview很难长成native的view。而我的方案是,长不成也要装成。在一些情况下,禁用webview滚动,使用滚动框架(iScroll不错)去实现。webview上下留出200pixel的空白背景,y从-200开始。否则大家知道,webview上下会有阴影的背景,不藏起来会很丑。等等,还有很多其他的方法去伪装webview,是要视情景而用。
目前,就想到这些,一定有很多纰漏,只求抛砖引玉,能让webview在App中发挥优势,有助于开发者。欢迎交流讨论,问题可移步http://segmentfault.com

蒙牛特仑苏与进口全脂奶的加热对比实验

本来今天下午闲着没事,做了这么一个小实验,就是想证明一下,蒙牛是不是真的有传说中的那么差劲,没有别的意思。顺手也拍了一些照片,传到微博上,结果引来了众多转发,其中不乏一些怀疑和不屑,甚至有为蒙牛辩护者。所以我决定仔细介绍一下,这个实验的背景和原理,叫个真。

- 阅读剩余部分 -