写js时碰到一个坑，查了半天简化后问题是这样的：

<script>
  alert(document) //[object HTMLDocument]
  var document
</script>

<script>
  (function(){
    alert(document) //undefined
    var document
  })()
</script>

在全局作用域上document没变，但在函数作用域上执行后document变undefined了。来看看这两种情况下都发生了什么事。

函数作用域

在函数作用域上这样的结果虽然难发现，但容易理解，var是声明局部变量，js在函数执行之前会把作用域内所有用var声明抽到头部统一生成，就是说

(function(){
  alert(document)
  var document
})
//等价于
(function(){
  var document
  alert(document)
})

在执行alert(document)访问document变量时，先从当前作用域寻找这个变量，如果当前作用域没有这个变量，会通过作用域链一层层往上寻找。若没有var document，就会找到上层的window.document。在这里当前作用域声明了document这个变量，优先访问这个变量，因为这个变量只声明未赋值，此时document==undefined。

在函数作用域下是这样的，但全局作用域下就不同了。

对象作用域

先看看raphelguo提供的的例子：

var obj = {a : 1}
with (obj) {
  var a = 2
}
alert(obj.a) //2
with (obj) {
  a = 5
}
alert(obj.a) //5

可以看到在obj作用域下，var变量声明已经失去了作用，无论有没有用var声明变量，对变量赋值都是等价于对当前obj的属性赋值。换句话说var是用来声明局部变量的，但在对象作用域内并没有地方存储局部变量，所以var是无效的。

再回来看看最初的例子，就很容易理解了，浏览器上在全局作用域下等价于在window这个对象下执行代码：

with(window) {
  alert(document)
  var document
}

这时var document完全无作用，alert出来的自然是window.document了。

看来，js的变量不是存在函数里，就是存在对象（包括宿主对象如window）里，要区分这两种情况的不同避免遇到坑。

刚接触到RPC（远程过程调用），就是可以在本地调用远程机子上的程序的方法，看到一个简单的nodejs实现，用来学习RPC的原理很不错：nodejs light_rpc

使用示例：

//服务端
var light_rpc = require('./index.js');
var port = 5556;
var rpc = new light_rpc({
    combine: function(a, b, callback){
        callback(a + b);
    },
    multiply: function(t, cb){
        cb(t*2);
    }
}).listen(port);
Sample client:

//客户端
rpc.connect(5556, 'localhost', function(remote, conn){
    remote.combine(1, 2, function(res){
        if(res != 3){
            console.log('ERROR', res);
        }
    });
});

（更多…）

看了everyauth源码，第一次看解决异步流程问题的实现方法，感到很惊讶，为了更好地学习，实现了这个流程的简化版。

例子

先看看这段代码，功能是从本地文件读到一个url—请求这个url—把结果写入另一个文件。

var fs = require('fs'),
http = require('http');

fs.readFile('./url.txt', 'utf8', function (err,data) {
  http.get(data, function(res){
    var body = '';
    res.on('data', function(c){
      body += c;
    }).on('end', function(){
      fs.writeFile('./fetchResult', data + body, function(e) {
        if (e) console.log('error', e);
        else console.log('done');
      });
    });
  }).on('error', function(e){
    console.log(e);
  });
});

这段代码包括了三个步骤三个功能，但耦合在一起，可读性差，难以修改，对任意一部分修改或增加都要看完整坨代码才能找到，即时把每个callback都抽成一个变量，这一整个流程也是无法分离的。

改进版

对这种情况，everyauth使用了一种方法，可以把整个流程的实现代码写成这样：

engine
  .do('fetchHtml')
    .step('readUrl')
      .accepts('')
      .promises('url')
    .step('getHtml')
      .accepts('url')
      .promises('html')
    .step('saveHtml')
      .accepts('url html')
      .promises(null)

  .readUrl(function(){
    //read url from file
    ...
  })
  .getHtml(function(url){
    //send http request
    ...
  })
  .saveHtml(function(url, html){
    //save to file
    ...
  })

  .start('fetchHtml')

do是一串流水方法的开始，step指定每一个步骤对应的方法名，promises表示此步骤返回的变量名，accepts表示此步骤接受的参数(由前面step的方法提供的变量)。接下来是链式地实现每一个step的方法。

整个过程很清晰，程序的自我描述很好，把一段异步的流程按同步的方式写出来了。若要修改其中某个步骤，直接定位到某个步骤对应的方法就行，无需把整个流程的代码通读。若要增加步骤，也只需要在那些step流程上插入新的step然后实现具体方法，可以获取前面step提供的任何参数。

how it works

实现它用到四个对象：promise/step/sequence/engine

promise是基础，相信很多人熟悉它的概念，简单来说就是把多个callback放到一个promise对象里，在适当的地方通过这个对象调用这些callback。在这里的作用是：当step执行结束时，通知队列执行下一个step。具体地说就是把下一个step的函数保存到前一个step的promise里，前一个step完成任务时，带着数据回调下一个step进入执行。

step负责执行一个步骤，传入对应参数，并把执行结果(return值)按指定的promises名保存起来，以供下一个step使用。

sequence管理step链，让注册的step可以一步步往下执行。

engine是提供对外接口的对象，管理保存每一个do请求里的step和sequence，通过configurable配置自身的可动态添加的方法。

具体看代码：https://gist.github.com/3930621

（更多…）

上个版本伊书支持TXT格式，免不了要做断章功能，粗略分享下断章的过程。

总体上的步骤很简单，只有两步：

1. 用正则找出所有包含“第X章”的位置，保存在一个数组
2. 循环处理这个数组，第i组的位置和第i+1组的位置之间就是这一章的内容，提取出来保存。

但有许多地方要处理和注意：

1. “第”字和“章”字之间的数字不能过多，否则可能是错误的匹配。
2. “第X章”这样的关键字有可能出现在正文，必须去除这样的匹配。（据测试QQ阅读没去掉这样的匹配）
3. 除了“章”字，还有其他关键字，如“卷”“节”“部”等。针对以上三条，最后使用的正则：@”\\s{1}第(.{1,5})(章|节|集|卷|部|篇)”
   前面的一个\\s{1}保证不匹配在正文里出现的“第X章”，中间限制1到5个字，达到中文计数的百位（如“一百二十一”），应该够了。最后收集了除了“章”之外的一些关键字，可能还不全。
4. 章节标题的提取。TXT上的章节标题可能是“第X章 XXX”这样，之前匹配的只是第X章，要把后面的字也作为章节标题提取。方法是在匹配到的第X章的位置找后面30个字符内的第一个换行符，匹配到这一行的文字就是章节标题。若30个字符内没换行，就以“第X章”为标题。
5. 开头结尾的特殊处理，匹配到的第一个“第X章”关键字要把这个位置之前的内容作为一章。匹配到的最后一章不再以下一个匹配的位置作结尾，而是全文最末为结尾。
6. 在无法匹配到章节内容时，采用普通分段方法，把全文按每章大概固定的字数分段。这样分段时在截取固定长度的字符串后向后查找最后一个换行符，以这个换行符的位置为点分段。目前使用普通分段的情况是匹配到的章节数小于4，或章节内容过长。

经过以上这些处理后，分章是有点靠谱了，但还有一些情况没考虑到，需要慢慢完善。

不知不觉做iOS客户端开发已经半年多了，了解到iOS客户端开发与Web前端开发的一些异同，写一下。

1. 版本升级。用户角度上看，客户端升级必须让用户手动下载整个新的安装包覆盖安装，而web的升级无需用户做任何事情。开发角度上看，如果客户端有个小bug需要紧急修复，需要修复完后打包一个完成的安装包，给一个版本号，发布给用户升级。而web只需要修改后台的某些文件，然后传到自己的服务器，用多快速的迭代开发方式都没问题。web没有版本兼容性问题，客户端这个问题就大了。
2. iOS客户端用编译语言，web用脚本语言。编译语言好处：很多错误编译期就知道，不用担心类似写错一个字母导致的问题。iOS客户端开发只能用XCode，无法选用自己喜欢的编辑器。使用脚本语言的web无论前端后端对编辑器的选择都很自由。
3. 客户端一碰到异常就崩溃，直接退出，web一个try catch可以把所有错误抓住，用户可以继续使用其他不受影响的功能，即使所有功能都受影响，刷新页面搞定一切。web上界面和程序实实在在地分离了，客户端再怎样都是粘合在一起的。
4. 发现HTML+CSS样式布局自动排列相当高级，客户端上一切都靠程序去指定大小位置以及排列的变化，可视化的XIB挺鸡肋。
5. 单线程的web很幸福，客户端要处理多线程，虽然强大，但很麻烦。web几乎不用考虑内存泄漏，客户端需要。客户端开发可以使用到很底层的接口和功能。web处于较上层，在浏览器的包裹下，好处是很多问题浏览器处理web不用管，坏处是功能受限。
6. web和客户端开发差不多都使用类似MVC的模式，数据通过控制器更新到各个视图。web多用callback，iOS多用delegate，虽然iOS也可以用block作为callback，但还是没js方便，还可能导致一些内存问题。

总的来说从开发普通应用来看，就算不谈跨平台，web开发也是好处多多，但这只是开发角度上看，实际上移动设备上webApp状况始终不好，与原生客户端差距很大，原因：

1. 网络不行，流量要钱。国内网络环境大家懂的，虽然HTML5有manifest,storage这些手段缓存webApp，但给人感觉就是不靠谱，打开它还是跟打开一个网页一样的感觉：耗流量，还有可能在网络不好的情况下打不开，没有像已经下载下来的原生APP踏实。
2. 动画/体验。一般的web在页面间切换或显示隐藏某个组件是没有动画的，大家也习惯了，iPhone带了个头，一切都要动画过渡，导致在移动设备上大家习惯了动画切换，受不了没有动画的应用，导致动画性能底下的webApp至今体验上远不如原生客户端。
3. 把webApp通过safari添加到主屏幕这样的习惯非常不普及，极少人知道，不过这个应该也不算问题，若没有上面两个大问题，这个习惯很容易普及的。

P.S 在开发普通应用（数据处理/交互）方面，web有很大的优势，在网络和性能问题解决后理应是首选开发方式。但在游戏领域我看不出web有什么优势，继续对有点热的HTML5游戏开发表示不解。

伊书是针对iOS的电子书WebApp，在web上排版不像原生APP有底层排版函数支持，限制很大，勉强实现了一些特性，在此分享。

内容左右对齐

给内容的DOM加上这个CSS属性即可：text-align:justify;
现代桌面浏览器几乎都支持，没详测。iOS5.0以上才开始支持这个属性，似乎若没有这个属性，左右对齐无解。

分页

web无法做到一页页定量渲染文字，分页需要一点hack才能做到。
我的做法是，一章的内容放在一个dom里，复制出一个一样的dom，限制显示一页范围的内容，根据页码调整显示位置。
一图声千言：

坏处是这样的形式要精确算准行高，就算字体大小不一样也要是跟正文一样的行高或是它倍数，一个算不准就会出现只显示半截文字的情况。也因为这样字体大小调整比较麻烦。

标点外挂

标点外挂是指一行中若第一个字符是标点符号，就把它移到上一行的末尾。具体实现方法是：

1. 给所有标点加标签，就是字符串替换，把。？等替换成<b>。</b> <b>？</b>
2. 遍历内容里的所有b标签，判断它们的位置是否在当前行的起始位置，若是则把它移到上一行末尾，具体代码：

$(".page_content b").each(function(i, b){
    if (b.offsetLeft == 0) {
        $(b).css({
            "position" : "absolute",
            "left": "256px",
            "top": b.offsetTop - lineHeight + "px"
        })
    }
});

内容缩进、信件落款左右对齐特殊处理

内容数据我是手工格式化后存到json里的，在这些特殊的地方加了标签，在显示时替换成dom按这些不同的类型给内容以不同的缩进/对齐。

注释

同上，在需要注释的地方用自定义的标签把内容包在标签里，在显示内容时把这个标签替换成dom，用js控制这个dom的touch事件显示内容就行了。需要判断这个注释的位置，以决定注释内容的显示位置。

src与demo：https://github.com/bang590/iOSPlayground/tree/master/TWebview

经常有这样的需求：需要给webview头部加个自定义view，这个view不是固定的而是要跟webview一起滚动。例如iMail里的读邮件页面，头部有收件人等信息，下面是一个webview。如浏览器，顶部的地址栏要随页面滚动。如阅读类软件，需要给正文上面加一个标题。

实现方法可以通过设webview里scrollView的contentInset，在头部留好自定义view的空间，再把view添加进来，随着webview的滚动缩放细调这个view的位置。这里把这些行为封装了起来做成一个扩展的UIWebView，主要解决的问题是：

1.直接通过设headerView和footerView完成头尾view的插入。
2.webView滚动和缩放时自动调整headerView和footerView的位置，使之看起来自然。
3.提供接口实现头部高度改变时进行动画

有个问题未解决：

设置contentInset后，webview顶点的Y坐标不是0，而是小于0的一个数(负的headerView的高度) 。
在webview跳转页面时，会自动滚动到(0,0)位置，也就是跳到webview内容的顶部，也就是这时候headerView被隐藏了。

从调用堆栈来看这次跳转是私有的UIWebDocumentView调起，无法截获阻止。只能在触发scrollViewDidScroll时让它跳回去。但还没找到方法判断什么时候该跳什么时候不该跳。

问题

UINavigationController顶部的返回按钮在切换视图时有左右滑动的动画(效果见iMail)，但在自定义了这个按钮后(通过设self.navigationItem.leftBarButtonItem自定义)，切换视图时按钮没有了动画。

最初解决方法

在每个viewController的viewWillAppear和viewDisappear方法上手动让按钮左右动。由于每个视图出现/消失的方向都有左/右两种，在这里难以判断，需要各种变量辅助，实现十分恶心，中间需要新加view时逻辑还要重新修改，被折腾。

最终解决方法

继承UINavigationController，重写pushViewController和popViewController方法，在这两个方法里面获取NavigationController里的view栈，因为push和pop总是操作最前面的View，所以可以从栈里知道哪两个view是要做动画的。调用这些view相应的方法使他们让自己的按钮动。这些方法可以写在UIViewController的扩展里，不用修改每一个viewController。

换言之，把下面的代码加入项目里，把项目里的UINavigationController换成下面的类，那些自定义的返回按钮就会自动做动画了。

代码

https://github.com/bang590/iOSPlayground/tree/master/NavigationButtonAnimate
（更多…）

做完了项目，想总结下，不知怎么写合适，只列出一些iOS开发的基础点，开发前因为不知道这些点，导致走了一些弯路，希望对初学者有帮助。

基础篇

为什么对一个变量release后还要设为nil

对一个变量release后，这个变量指向的内存释放了，但这个变量本身没变，仍指向原来的内存地址。若这个变量在释放后被访问，或者被重复release，就会导致应用崩溃。设为nil后这个变量指向0x00，可以保证程序以后访问不到原先的内存地址，对nil进行release也没任何问题。

使用类成员时，前面加不加self.有什么区别

不加self.调用的是成员本身，加self.后实际上调用了其成员的get set方法。
例:

//.h
@property (nonatomic, retain) NSString *name

//.m
name = @"bang";  //没有retain，随时会被释放
NSString *str = self.name  //等于NSString *str = [self name];
self.name = @"bang"; //等于[self setName:@"bang"]; 这时在set方法里retain了这个字符串

技巧篇

内存泄漏

可以通过xcode的编译工具Product-Analyze检查函数块范围内可能的泄漏点（外带会提示一些可能有的错误）。

用leaks工具监测出来的泄漏查找方法是跟踪其代码提示中出现的变量，经常这个变量是在提示的调用堆栈以外的地方泄漏的。若实在查不到，最终办法是重写这个变量的retain和release方法，debug，从调用堆栈看是谁retain了它而没有release。

要注意的是，用CFXXCreate(例如CFArrayCreate)生成的变量要用CFRelease释放。

数据存储

如无搜索需要，可以将一个数据对象直接序列化后存到sqlite，取出时直接反序列化为对象使用。序列化需要数据类实现NSCoding协议，实现encodeWithCoder和initWithCoder两个方法就行，若有多个数据对象，可以写个基类实现这两个方法，并在这里面利用反射枚举自身所有变量去encode和decode，一劳永逸，具体实现网上找找就有了。

组件篇

UINavigationController头尾显示隐藏

在用NavigationController去管理view的push和pop时，需要根据不同的view设置是否显示NavigationBar和ToolBar，一开始在错误的地方设置了，导致有时该显示NavigationBar和ToolBar时不显示的情况，后来发现在viewWillAppear上设置万无一失。别笑我土鳖，没好好去理解它整个流程，一直没发现。

- (void) viewWillAppear:(BOOL)animated{
    [super viewWillAppear:animated];
    [self.navigationController setToolbarHidden:NO];
    [self.navigationController setNavigationBarHidden:NO];
}

UITableView游标式渲染

tableView的机制大概是：先定好总行数，某一行滚入视图范围时，回调一个函数去取view出来显示。这一行滚出视图再滚入时仍会继续回调这一函数取view。有这样的机制就是说无论你table里的数据有多少，都可以全部放入table中不用分页，因为不用一次性把所有数据都取出来，只在需要显示的时候根据游标去取对应的数据就行了。

可能这是APP组件很自然的方式不用说明，但在web上页面上的数据和元素都是要一次性载入内存的，做久了web，一开始没想到它这样的实现机制，导致我们走了不少弯路。

UIWebView渲染范围

UIWebView不是根据可视范围决定每次的渲染范围，而是根据自身控件的frame大小决定。

曾尝试webview嵌在tableview里，为了让webview跟tableview一起滚动，把webview的大小设为webview里的内容大小，让webview不出滚动条，从而能跟着tableview的滚动条一起滚。这样做的后果是每次webview都一次性渲染整个页面，内存占用多性能很差，而且在放大缩小这个webview时，渲染放大的整个页面更吃力，出现不能忍受的性能。解决办法是让webview定住高度为一整屏iphone的高度，限制了webview每次的渲染范围为可视范围，性能大好。带来的问题是无法随tableview滚动，但可以以其他方式优化体验。最近看到新版的ZAKER也是这样做的。

个人感觉篇

界面布局调整非常麻烦，让人怀念web了。界面描述方法XIB感觉晦涩难学，至今不会，没有CSS+HTML来得方便。

有编译器把关，少了像写js时多写or写错一个字符查半天的问题。

Object-C写起来各种变量函数和变量调用很长，没有js的短小精悍来得爽。

第一次编写涉及手动内存管理的程序，挺有意思，没想象中难，但有些内存管理导致的bug很难查。

虽然APP不像web那样随时更新，但也不像传统PC客户端升级那么麻烦，用户更新意愿更强，还是适合快速迭代的。

细节是可以决定成败，但得看你把什么定成细节。

最后，0bug的程序不存在，极致是把最主要的事做好。done is better than perfect。

QQ邮箱iPhone版开发了几个月，多次延迟发布，过程十分艰辛。这是第一次尝试混搭的开发方式，即整个应用主要由web组成，APP给web套上一个壳并提供一些原生的接口，以达到更好的体验。我们使用了开源的PhoneGap框架，但其实到后来已经可以抛弃它了，没用它多少接口，自己实现一下也只是时间的问题。

总体

整个APP主要是以下三点：

1. APP由js驱动，与手机邮箱触屏版/ipad版使用同一套逻辑，同样的M层，架构一致。
2. 由APP客户端提供绘制头尾以及动画切换的接口，由js调用。
3. 使用HTML5的sqlite/localstorage缓存数据，applicationCache缓存静态文件和页面。

加上各种细节，就可以构建一个仿原生应用了。

问题

实际上说得简单，做起来难，碰到很多问题。

性能

DOM的性能差，渲染速度慢，最初在各个模块之间切换时速度不能忍受，经过各种优化后情况才好转。优化包括：去除所有高级CSS特性，例如阴影渐变等，减少list默认显示条数，缓存DOM，APP头尾控件缓存，APP动画拍照优化。即使经过很多优化，目前性能上还是跟原生APP有所差距。这种差距目前来看只能等待硬件升级。其实在未做任何优化前，在mac的模拟器上体验已经很好了，无性能问题，因为mac的硬件够好。

manifest

applicationCache的manifest是个令人头痛的东西，项目过程中几度出问题。它最大的不足在于不能清空缓存，一旦使用了它，将很难抛弃它，只能更新，不能抛弃。造成的问题是，manifest更新时，拉取新的资源文件，一旦主页面在后台输出的是个不正确的页面，被缓存起来了，就万劫不复，再也无法进入应用了，因为没有机会再次取拉正确的页面了。所以要使用它，需要强力保证主页面绝不会输出错误，最好是个静态页面。

此外用manifest还要非常细心。项目过程中有两次出现突然无法离线的情况。一次是manifest针对高清屏输出的文件有个地方没换行，导致缓存无效。很难看出它没换行，因为manifest文件是套模板的，模板上是有换行的，转完输出就没有了。只针对高清屏错误就导致模拟器和iphone3都没问题，只有iphone4有问题。折腾这个诡异的问题半天。另一次是写在APP里的启动网址参数里多了个’s’，导致打开的页面跟缓存的页面不一致，很难发现，也查了挺久。

JS-APP不同步

APP提供了绘制头部底部的接口，何时绘制以及绘制什么由JS控制。模块的切换会有动画效果，在js调用模块切换时，先拍照，再画头画底，再回调开始动画的事件，JS渲染自身的dom，动画切过去，整个流程挺简单挺清晰，但实际会有各种问题出现。

在初期经常出现APP头尾和模块内容不一致的问题，由各种原因导致，可能在切换模块整个流程没结束时马上又切换模块了，或者再调一次画头尾，会打乱流程。这通过APP那边把命令加入一个队列顺序执行，并且在动画过程不响应事件来解决。

登录问题

由于历史问题，登录没有使用ajax，整个应用不可避免地需要页面跳转，这会导致非常多的问题：
1.在某些网速非常慢的情况下，整个应用白屏无法避免，因为在跳转了页面并且页面还未载入时，必然会先出现一个空白页面。
2.登录的loading菊花卡住不转，因为跳转了页面本页面的无论是gif还是canvas都停止运行了。
3.一旦出现运营商劫持/wifi验证页面，整个应用就会调转到这个页面去，完蛋了。这个后来通过把表单提交到iframe解决。
所以，最好不要出现跳转页面的情况，必须整个应用在一个页面里。

沟通成本

本来一个iPhone APP的开发链就是，UI-客户端-后台，加入js后，多了js与客户端沟通的成本。而在这种开发模式不成熟的时候，这个沟通成本挺大。另外在APP出问题的时候，有时挺难判断是js的问题还是客户端的问题。

由于APP介入了表现层，进入JS的逻辑，所以必须对APP和JS两端都熟悉了解，才能掌握整个流程。之前不清楚为什么phoneGap不推出这个固定画头画底的接口，这是所有APP必备而在web上实现性能又很差的东西。现在知道这会使APP变复杂，phoneGap只提供功能接口，作为后台角色，其他全交给JS，不需要与APP进行过多的沟通。

webView/网络

出现了一些问题我们还没弄清除是不是webView的问题，例如，记住cookie的问题，登陆过后是设了cookie的，但如果这时马上退出，下次进来就不会有cookie，如果是隔个二三十秒过后再退出，cookie就能记住。非常奇怪的行为，对此我们只能打个补丁，把某些cookie存到localstorage，下次进来如果没有cookie就从localstorage里取，这个方案还依赖了mainifest。

另一个是APP环境改变时ajax的行为问题，在请求或者上传时，APP切换到后台，APP切换网络，APP切换到后台长时间不用再打开，APP终止webView的请求，都会由可能导致ajax卡死，无onsuccess或onerror的callback，有时还会导致JS被阻塞，接下来无法正常响应请求。这是我们框架的缘故，还是webView的缘故，还待查。

好处

与纯原生APP比，它是有带来一些好处的。

1. 云端升级：应用的某些升级无需通过AppStore，无需用户下载安装，可以快速迭代。
2. 代码复用：触屏版/ipad版的多数代码可以复用或者共用，降低开发成本，提高开发速度。
3. 跨平台：我们暂时没用到这个好处。若要跨平台，数据层没问题，VC层还是有很多的不同。

总结

混搭的开发方式，APP最好不要参与到表现层的东西，只提供必须的功能接口，否则js与APP一起管理整个表现，会导致复杂度增加，开发困难。但目前没办法，可能走得有点快，就目前来说，纯web的表现还与APP的差距甚大，必须借助APP的力量，像最基本的头尾固定，只能由APP来展现。

目前iOS5的浏览器支持了position:fixed属性，可以在屏幕上固定元素，支持-webkit-overflow-scrolling: touch，可以原生支持对区域滚动，就具备了使用纯web实现目前的体验的基础。等接口提供再加上硬件不断加强，性能上的差距也会缩小，等市面最低版本是iOS5了，硬件都升级了，web主导的这类应用估计会多些。