Qian's Blog

如今Web Application（以下简称“WA”）大行其道，在使用这些Web Application的过程中，一种趋势渐渐形成，那就是将WA本地化，也就是转化成Native Application（以下简称“NA”）。转化的方式，就我看到的而言，有以下几种：

• 在NA中嵌入browser，然后根据获得的web信息进行layout调整，增强native的用户体验。典型的例子是：Mac的Fluid，Mozilla的Prism
• 在NA中调用WA提供的API，然后纯用native的GUI。经典的例子是：Twitter Clients for iPhone、PC、Mac，Facebook App for iPhone……

为什么在WA的大趋势下，还有这样可能被认为是“走回头路”的逆流呢？我认为，原因在于资源和用户体验。

首先，browser的资源消耗一直是个问题，就我现在写Blog的时候而言，Safari的内存消耗是175.72MB，这对小型的WA是不可接受的。试想，为了使用一个像Gmail这样WA，用户需要花费上百MB的内存，而笔者现在开着的Apple Mail（a mail client）消耗的内存是50.03MB，你会选择哪个？另外，为了展现WA的效果，browser不得不加载足够的信息，如HTML、XML、JavaScript、CSS，带来了不少额外的网络资源消耗，虽然对于使用宽带的普通PC or Mac用户不是问题，但是对于使用移动设备（如：手机、laptop无线上网等）的用户而言，这是一个不能回避的话题。与此同时，性能也是一个问题，即便现在各种browser都以提高JavaScript运行效率作为提高性能的重点，但是对于比较复杂的WA，操作延时也是用户可以感知到的。相对于在“完整的”browser上使用小型WA，NA不仅运行效率高，而且消耗资源小。

其次是用户体验。虽然WA可以随时修改用户体验而免去了部署的麻烦，但是不得不打开browser来实现操作也是有问题的。例如，现在我需要使用Google的Tasks服务，这个服务很小，仅需要显示一个To-do List就OK了，但是我却不得不打开一个占满屏幕的browser。Twitter也是这样，本来我只需要查看大家的tweets和简单的发送tweet而已，一个侧边栏足以完成任务，而我也得打开一个browser，这也是我不能接受的。在看到WA的弊端的同时，我们也要注意到NA的弊端，那就是每次修改用户体验都要重新发布新NA，这一点也很恼火，Twitter Clients的频繁更新也很让我“血沸”（方言，贬义词）。

所以，纵观WA和NA，各有优势。在强调lightweight时，我们不妨通过server提供的API，同时以NA来提高性能和用户体验；对于大型复杂的WA，我们可能只能靠browser来帮助我们完成。

Fluid和Prism是很好的一种尝试，是一种在WA和NA之间的tradeoff，既有NA的高效率，也有WA的灵活。我将在未来几天里尝试Fluid给我带来的新的用户体验。