长干行

在ios中调用lua脚本，本以为容易；孰料好事多磨——lua解释器在debug输出中抗议不断，拒不就范。后历经坎坷，笔者才让objc与lua在ios中成功牵线，喜结良缘。所用的方法较为悲催，但可行。

独上高楼，望尽天涯路。
      最初的想法是，把lua文件放到resource文件夹里，作为资源供objc调用。相关代码如下：

1 p_lua_stack_ = luaL_newstate(); 2 luaL_openlibs(p_lua_stack_); 3 FilePathManager *m = [FilePathManager sharedInstance]; 4 int r = luaL_loadfile(p_lua_stack_, [[m llkFacadeFilePath] UTF8String]); 5 int cr = lua_pcall(p_lua_stack_, 0, 0, 0); 6 DPRINT("%d", cr);

      运行的输出，cr为2，也就是lua脚本运行时错误。调用lua状态机中的错误信息，会得到：
The output is:...4-489C-4A40-8582-F734FAAC428D/APP.app/facade.lua:1: attempt to call global 'module' (a nil value)

衣带渐宽终不悔，为伊消得人憔悴。
      如此错误信息令笔者大惑不解——module明明是lua的库函数，怎成了“a nil value”？对此笔者只能说，他就是发生了，这是一个奇迹！不管你信不信，反正我是信了。
      解决方法倒也简单——反正facade.lua中的代码是面向C程序的门面类，不会被其他lua模块调用，不如把module去掉吧……
再次编译运行，依然runtime error……错误信息中，一串no file……——意即facade.lua中的require方法未能找到其他模块的路径，因为package.path中不包含app包的路径。
      于是，笔者尝试在iOS程序中修改package.path的值，赋值为app包的路径。具体的实现是通过lua状态机来交互。
      再次编译运行，依然runtime error……——facade.lua中的package.path确实发过来了，但是其他文件表示不受影响

蓦然回首，那人却在，灯火阑珊处。
      屡试不果，笔者终于想到了暴力的解决方案——在ios程序中直接修改lua代码。
      ios程序中，资源文件是只读的——要修改lua代码，需要把lua文件复制到document文件夹中，而后为每一个lua文件插入修改package.path的lua代码。
      这个操作并不复杂，却也需要设计，解耦。
      负责封装facade.lua的C++门面类显然懒于关心如此细节，它只须知道facade.lua的路径，来初始化lua状态机。于是要创建一个LuaFilesManager类来修改lua文件，关键代码如下：

 

1 void LuaFilesManager::PrepareLuaFiles() 2 { 3 ProgramRecordManager *prm = [ProgramRecordManager defaultManager]; 4 5 if (![prm luaFilesHasCopied]) { 6 CreateLuaFilesDirectory(); 7 CopyLuaFilesToDocument(); 8 9 [prm setLuaFilesHasCopiedOrNot:YES]; 10 } 11 12 if (![prm pathHasSetInLuaFiles]) { 13 SetLuaPackagePathInAllLuaFiles(); 14 15 [prm setPathHasSetInLuaFilesOrNot:YES]; 16 } 17 }

 

      把LuaFilesManager设计成了C++类是个失误，不如objc类简洁。ProgramRecordManager类用来管理程序的历史行为。具体代码就不细说了。
再次编译运行，lua_pcall的返回为0，即正常运行。
      百般推诿之后，lua还是从了objc，后人有诗为证：
同居长干里，两小无嫌猜。
十四为君妇，羞颜未尝开。
低头向暗壁，千唤不一回。
十五始展眉，愿同尘与灰。