影院建设项目在筹备后，进入设计施工期，由施工方代为设计电影院，或者进行设计招标，而电影院设计就是整个影院建设的关键部分，它一般的住宅设计不同，因为电影院建成后五到十年内不会更换装修风格，要保持该阶段内的时尚新颖感。

影院设计构成

通用的电影院设计结构包括等候大厅、票房、卖品部、检票口、过道走廊、影厅、放映室、厕所，有条件的还要建设贵宾室、吸烟区、贵宾厅、员工休息室、办公区等。

影院元素

影院设计。影院元素包括几个系统：等候大厅主题系统、售票系统、卖品系统、影务系统、电影放映系统、影厅、厕所、影院文化系统、影讯发布系统、影院辅助系统等。 售票系统是指由卖票柜台和电子售票系统组成的设备设施，包括售票柜台、选座电脑显示屏、会员通道、Led大屏幕等。 卖品系统是指由卖品柜台、卖品销售系统、各种可乐机、饮料柜员机、爆米花机、各种冰柜、卖品库房、卖品制作间等组成。 影务系统是指由检票口票台、进场时钟组成。

电影放映系统是指放映室内设施和各种放映设备、放映工作区、停片区、倒片区、捡片区等组成。

影厅由厅号、隔音幕墙、阶梯座位、放映窗口、控制台、温湿度仪、银幕及辅助设施、环绕立体声音箱、清洁灯、测光等、散场灯、地角灯、其他各种修饰灯，一级出入场通道组成。

影院文化系统主要是指在一些等候区域和谐的融入一些电影院特色的文化宣传图片或文化墙，还包括影城大厅主题海报灯箱、国道走廊海报灯箱等。

影讯发布系统是指电影院大厅、厕所、吸烟区的各种电视墙和电视。

大厅主题系统包括大厅雕饰、大厅四周高层相应象征物件和各种效果的灯组。

影院的设计风格和色彩

影院设计。电影院的设计风格除了时尚、三五年不落伍之外，一般都要与国际接轨。电影院的风格要融入当地的文化特色，在色彩方面惯用蓝色主题、红色主题和黄色主题，凸显现代影院娱乐功能，因此颜色鲜艳明快，同时又有一定的厚重感，不张扬。大厅、走廊装饰凸显层次。

项目施工

项目施工是在现有电影院设计图纸的基础上进行的，对一些图纸未提及文化，要进行重新创意设计。

项目施工期从原材料送达之日起算起，一般需要3个月（90天）时间，先从框架结构做起，分离出等候大厅、影厅区、放映去、办公区，然后再进行影厅拆分、座位钢结构搭建、再到天花板、各种空灯、幕墙、座椅、地毯安装，最后是立体声系统安装、银幕安装和地角灯的安装调试。最后是影城票房、卖品部进驻和大厅施工。

影城施工通常由4～5个施工队伍同时施工，包括钢结构施工队、幕墙施工队、地砖施工队、地毯座椅施工队和造景施工队组成，一级强电、弱电等。

城市中越来越多的购物中心出现，电影院几乎成了其标配之一。但就像是购物中心的服饰品牌、餐饮种类大同小异，电影院的空间设计也罕有新意。

4D动感影院介绍

4D动感影院，由三维立体电影和周围的环境模拟组成的四维空间，它是在3d立体电影的基础上加环境特效、模拟仿真而组成的新型影视产品，通过给观众以电影内容联动的物理刺激，来增强临场感的效果。随着影院娱乐技术的发展和娱乐市场的需求，人们不仅将震动、坠落、吹风、喷水、挠痒等特技引入3D影院，还根据影片的情景精心设计出烟雾、雨、光电、气泡等效果，形成了一种独特的体验，这就是当今十分流行的4D影院。

4D动感影院组成

4D动感影院整体系统由专业级、震撼的立体投影，银幕， 4D座椅，环境特效， 数码音响，影院总控制系统等组成。其相比较于其他类型影院，具有主题突出、科技含量高、效果逼真、娱乐性强等特点和优势。

动感影院环境特效

广州全影汇VR“4D动感影院”可以添加刮风，下雨，下雪，闪电，烟雾，泡泡等特效，观影时影片里会出现风，雨，电，烟雾，泡泡等自然现象时，特效设备也将同步出现这些自然现象，让体验者感受到近乎极致和身临其境的参与感与互动性！

系统框架结构图

4D动感影院与4D游戏采用相同的工作原理，是利用专业的3D开发引擎，借助3D立体电视、投影器等显示设备、立体眼镜等接收设备，通过两部具有一定视觉差的影像（即模拟人体双眼的立体成像功能所塑造的影像）组合，在观众或玩家参与过程体现出较强互动性的效果。

4D动感座椅特效

全影汇VR4D动感平台可以精准模拟前倾、后仰、左倾、右倾、坠落、颠簸、吹风、喷水、扫腿、捅背、震股等动作。当影片出现以下场景时，你会体验到相对应的特效。例如：影片情节里摩托向左或向右拐弯时，座椅会做出相应的动作；影片情节里从高空向下坠落时，座椅会模拟快速向下。这一系列电影情节动感座椅都能模拟并且完全同步！

多款连排动感座椅

4D动感座椅是建立4D动感影院必不可少的构成元素之一，4D动感座椅可以根据4D动感影院中特效座椅的布置故事情节的不同而由计算机控制做出不同的特技效果来，例如，坠落，震荡，喷风，喷雨等等，再配上精心设计出来的烟雾、雨、光电、气泡、气味等，从而营造一种与影片内容相一致的全感知环境。

4D动感影院施工案例

环幕4D动感影院不同于一般的电影屏幕，采用柱面环幕投影显示方式，将观赏着围绕在中心。屏幕上的超长跨度的广阔画面充满观赏者的视野，全方位立体声与影片情节相辅相成、完美配合，演绎精彩绝伦的沉浸式视听享受。柱面投影屏幕的弧度有360度、270度、180度等多种选择，可根据场地具体情况进行个性化设计和施工，保证4D环幕动感影院效果。

4D动感影院成功案例

全影汇VR科技贵州遵义动感影院成功案例等采用立体投影系统，结合拥有自主知识产权的动感设备、环境特效、灯光特效系统， 将从视觉、听觉、嗅觉、感觉等方面，为观众带来身临其境前所未有的刺激体验。

全影汇：http://www.chinavrway.com

来源：MRRiddler ，

blog.mrriddler.com/2017/02/10/计算机体系-编译体系漫游/

要想让代码乖乖运行，自然代码要先经过编译，这篇文章就来聊聊编译体系。

代码的编译过程分为四个阶段，预处理、编译、汇编、链接。而编译阶段是整个过程中最复杂的阶段，编译阶段还可以分为词法分析、语法分析、语义分析。

在一头扎进这四个阶段之间，先聊一下语法、语义。人类之所以能在进化的历史长河中，成为动物中的佼佼者，进化出的复杂的沟通机制—语言功不可没。假如，我说出这句话：你个产品狗还在改需求！那么语法是啥呢？简单说就是构成这句话的顺序，假如顺序错乱意思就不同了。那么语义是啥呢？就是语境，根据我说这句话的情景，才能解释出你指的是谁。语法在编程语言中，表现出来的就是语法结构和结合律。语义表现出来的就是上下文(context)。

编译历史

编译的历史基本就是计算机的进化史，是很有趣的一段故事。Long time ago… 程序员写程序都是用纸带，那时候还在写0、1机器码。纸带上打孔就是0，不打孔就是1。然后计算机读取纸带就是读取指令。但是就像互联网本质就是提高效率一样，这样写程序的效率怎能接受？并且，写程序如果犯了错误怎么办？重新从头到尾再用新纸带搞一遍？程序员们机智的开始想办法了，先是这样搞：

将指带有误的地方，用黑黑的小贴纸填上去，这样将0改成1了。这也是Patch名字的由来。但是这样写指令效率还是太低，程序员们再机智的想办法。后来将指令进行符号化(Symbol)，抽象出指令集，这时就出现了汇编，程序员的效率上了一个档次。但是新的问题又出现了。在写过程调用的时候，要写jmp 具体的函数地址。如果后来要在被调用的函数前面添加指令，那么函数地址也要跟着改。这样牵一发动全身的感觉可不好，为了让影响(impact)缩减到最小，不如将函数地址也符号化。凡是写过程调用先写成jmp func，等到程序生成机器码的时候，再将func换成真正的函数地址，这一步也就是将程序员手动修正交由汇编器修正。

随着生产力的提升，程序的规模越来越大，新的问题出现了，程序膨胀到难以维护和阅读了。程序员们就将程序模块化、层次化。这样也使编译的单位更小粒度化。编译的时候，不同编译单位之间的细节是互相隔离的。比如，对于C语言系，一个.h和一个.m就构成了一个编译单位。.m汇编时，是不知道其他.m的全局变量、函数地址的，而调用的时候就只能用符号进行调用，等到最后所有.m都生成机器码后再进行统一的修正。而负责这一步的就是链接器(Linker)，这一步也叫重定位(Relocation)。

目标文件

经过汇编这一阶段后，就会生成目标文件。目标文件和可执行文件已经非常相近了，只是有些符号还未修正，结构上会进行调整。Windows平台下为PE(Portable Executable)，Linux平台下为ELF(Executable Linkable Format)，Mac平台下为Mach-O。虽然不同平台都有自己的格式，但是它们实际上都大同小异。下面大体聊一下文件的实际字段，这些知识会为后面我们搞一些符号重绑定做铺垫。

section

首先，文件分段(section)。不同的Section放置不同的信息，文件还有一个section header table放置控制信息。实际上，就类似图片格式和mutipart的HTTP报文。以下是一个ELF目标文件的常见section：

—— —— —— —— —— —— ——

|header | -----> 文件头

|—— —— —— —— —— —— ——|

|.text | -----> 代码段

|—— —— —— —— —— —— ——|

|.data | -----> 已初始化全局变量、静态变量

|—— —— —— —— —— —— ——|

|.bss | -----> 未初始化全局变量、静态变量

|—— —— —— —— —— —— ——|

|other sections... |

|—— —— —— —— —— —— ——|

|section header table| -----> section控制信息表

|—— —— —— —— —— —— ——|

|.strtab | -----> 字符串表

|—— —— —— —— —— —— ——|

|.symtab | -----> 符号表

|—— —— —— —— —— —— ——|

|..... |

—— —— —— —— —— —— —— —

.text放置代码，.data放置已初始化的全局变量和静态变量，.bss放置未初始化的全局变量和静态变量。为什么代码和全局变量、静态变量要分开放？实际上，这就是个等同性问题。代码段就是可读的数据，而全局变量、静态变量是可读可写的数据。如果有多个进程进行同一份代码，这些代码都是等同的，不需要各自复制一份。而全局变量、静态变量是不等同的，需要各自复制一份。而分什么又要分已初始化、未初始化呢？目标文件未初始化的全局、静态变量只需要放置一个占位符，代表其在.bss。而.bss在链接阶段，变量不占空间，在装载时由操作系统再分配空间。可以看到，既然是文件格式，不管怎么设计，主要的目的就是占更少的空间。

header有很多文件控制信息，就不一一表述了，其中最重要的就是记录了section header table的起始地址。而section header table记录了所有section的名字、类型、长度、在文件中的偏移量(offset)等。如果想要寻址到任意section都要通过这个header table。section header table实际上是由struct构成的数组。

.strtab放置section名、变量名，包括符号名的字符串。由于在整个结构中，字符串的长度是不定的，一般将这些字符串统一放置在一个table中，然后存储table中的offset，最后寻址到字符串。比如，在下表中，我想找到girlfriend一词，我只要拿到.strtab的base地址，加上girlfriend的offset 9就可以找到这个字符串。

0 1 2 3 4 5 6 7 8

i 0 w a n t 0 a 0

g i r l f r i e n

d

.symtab就是大名鼎鼎的符号表。每个目标文件都有自己的符号表，符号表记录符号的映射，符号可以这样分：文件外符号和文件内符号，文件外符号就是使用在其他文件定义的符号，文件内符号除了在文件内定义给其他文件使用的符号，还包括每个section符号，在文件内定义光是文件内使用的符号。光文件内使用的符号，对链接没有帮助，主要为了崩溃后分析而存在。符号表也是一个由struct构成的数组。ELF的32位符号sturct：

typedef struct {

int32_t st_name;

uint32_t st_value;

int32_t st_size;

unsigned char st_info;

unsigned char st_other;

uint16_t st_shndx;

} ELF32_Sym;

st_name字段就是符号的名字，表示为在.strtab中的字符串offset。st_info表示是局部符号、全局符号还是弱符号。符号也可以分为强符号(Strong Symbol)、弱符号(Weak Symbol)，顾名思义，强符号有唯一性，弱符号没有唯一性，一个强符号可以和多个弱符号共存，多个重复的强符号不可以共存，链接器会报出duplicate dymbol，可以用attribute((weak))指明弱符号。相对的，符号也有强引用(Strong Reference)、弱引用(Weak Reference)，在链接进行符号修正的时候，强引用必须修正，而弱引用可以不修正，可以用attribute((weakref))指明符号弱引用。

st_shndx字段指明了符号是文件外符号，还是文件内符号。如果是文件外符号就为SHN_UNDEF。如果是文件内符号包括给其他文件使用的、光自己使用的、section符号，就为所在section的索引号，而st_value表示所在section的offset。等到链接过后，不管是文件外符号还是文件内符号，st_value指明实际地址。

符号修饰(Symbol-Decoration)与函数签名(Function-Signature)

机智的同学已经发现了，如果光按上面聊的方式进行符号链接是有问题的，假如目标文件有个func符号又引用了其他文件同名的func符号，那符号不就出现冲突了？这里就需要引入函数签名，函数签名是一个函数的名字、参数类型、所在类名组成的字符串，不同语言、不同编译器对同一个函数生成的函数签名是不一样的，比如OC中函数签名还要加上返回变量类型，C++中还要加上NameSpace。在链接的时候，过程调用符号不光是函数名，是对函数签名处理后的结果，全局变量符号也是经过类似用函数签名处理后的结果。这一处理过程就是符号修饰。

fishhook

fishhook是facebook开源的重绑定Mach-O符号的库，最常用来hook C语言函数，而且实际上只能重新绑定C符号，因为符号修饰这一步只去掉了”_”，相当于只针对C语言做了符号修饰。在了解了目标文件后，重绑定就不是那么困难了。最基本的思路就是先拿到header，然后通过header拿到section header table，再找到.hash，.hash是一个用于加快访问.symtab的哈希结构，再索引到.symtab，详见这里，通过name去.strtab比对符号名，如果匹配就置换value。

https://docs.oracle.com/cd/E2382401/html/819-0690/chapter6-48031.html

fishhook大体实现原理就是这样，只不过对Mach-O平台特性改进一下方案就行。在Mach-O中类似于section header table的段叫做load commands。并且Mach-O中使用二级命名空间，先分segment，就相当于上文中的section，然后再在同一segment中区分section。

先拿到header，通过header中的ncmds(segment的个数)和cmdsize(segment的大小)字段就可以找到所有的segment。然后找到.strtab、.symtab、indirect symbol table。这个indirect symbol table是一个uint32_t的数组。它就是nl_symbol_ptr(non-lazy)和la_symbol_ptr(lazy )对应的.symtab struct数组的索引。nl_symbol_ptr和la_symbol_ptr section section中的reserved1字段指明对应的indirect symbol table起始offset。只要从这两个section对应的indirect symbol table起始表项再跳到.symtab去匹配、置换就可以了。

下面是32位下.symtab的struct，可以看到和上段文章讲的几乎一致：

struct nlist {

union {

char *n_name; /* for use when in-core */

uint32_t n_strx; /* index into the string table */

} n_un;

uint8_t n_type; /* type flag, see below */

uint8_t n_sect; /* section number or NO_SECT */

int16_t n_desc; /* see <mach-o/stab.h> */

uint32_t n_value; /* value of this symbol (or stab offset) */

};

上文提到的Mach-O格式如下：

—— —— —— —— —— —— ——

|header |

|—— —— —— —— —— —— ——|

|load commands |

|—— —— —— —— —— —— ——|

|__Text |

|—— —— —— —— —— —— ——| —— __nl_symbol_ptr

|__Data | -----> |

|—— —— —— —— —— —— ——| —— __la_symbol_ptr

|other sections... |

|—— —— —— —— —— —— ——|

|.strtab |

|—— —— —— —— —— —— ——|

|.dynsym | -----> indirect symbol table

|—— —— —— —— —— —— ——|

|..... |

—— —— —— —— —— —— —— —

更加详细的格式，推荐这篇文章。

http://turingh.github.io/2016/03/07/mach-o文件格式分析/

链接

上面聊了这么多 ，那静态链接到底是如何将多个目标文件链接成一个可执行文件的呢？

静态链接分为两阶段(Two-pass Linking)，第一阶段先扫描所有目标文件，调整结构。将所有目标文件相同section合并，包括.symtab合并成全局.symtab，然后为每个section分配虚拟地址，再将全局.symtab中的符号进行置换成虚拟地址。

这里如何将全局.symtab中的符号置换成虚拟地址呢？实际上，在分配section虚拟地址后，符号的虚拟地址按所在section虚拟地址加offset就可以计算出了。

第二阶段将所有符号进行修正。通过重定位表找到所有section中需要被修正的符号位置，然后从全局.symtab查询出虚拟地址置换。

每个section都会对应一个重定位段，这些重定位段组成一个重定位表。每个重定位表项叫做重定位入口(Relocation Entry)，它记录了所需重定向符号所在段的offset。

静态链接库

静态链接库就是一组目标文件，经过压缩、索引而成的一个文件形式。当我们平时在使用静态链接库的时候，实际上链接器会根据所需的符号，在库中搜索到相应的目标文件，并将其链接入最终可执行文件。

动态链接

随着静态链接慢慢发展起来，静态链接也暴露出了问题。静态链接将链接与被链接的目标文件结合的太紧密了，导致如果多个目标文件要链接同一个目标文件，那这个被链接的目标文件相当于要被复制多份，每个可执行文件都要包含这个被链接的目标文件的内容，这样会占太多冗余空间。那怎么办？将链接与被链接的目标文件先隔离开，将链接的时机往后推移，等到装载的时候再进行链接。这样，让被链接的目标文件只占一份空间就好。

既然动态链接隔离开了链接、被链接目标文件，链接目标文件需动态链接的符号，就需要先做个动态链接占位符。这也就是说，在目标文件链接成可执行文件时，即使是用作动态链接的目标文件也要作为动态链接库输入到链接阶段，以供目标文件识别哪些符号是动态符号。

动态链接重定位

上面已经聊完了在链接阶段对静态链接进行重定位，根据符号所在section的虚拟地址和所在section的offset。而动态链接可以这样重定位吗？不行，这时动态链接库的地址还没有确定，必须等到装载以后操作系统分配。那可以等到装载以后，确定地址后再直接进行重定位吗？不行，假如动态链接库被多个进程引用，装载时动态链接库进行重定位，动态链接库映射到每个进程中的虚拟地址都不一样，动态链接库只能对一个进程重定位，那么动态链接库就不是共享的了。那怎么搞？

通过.got(global offset table)，.got就是一个指针数组，.got存储引用符号的实际地址。而代码段引用符号直接更改为引用.got项的位移，这在链接阶段以后就不会再改变了。然后将.got分配在.data section，装载时每个进程复制一份并修正。实际上，动态链接重定位指的就是在装载的时候，根据全局符号表修正.got表项。动态链接库使用全局变量、静态变量、引用文件外过程调用都要经过.got。.got就像indirection table一样，解决多进程共享动态链接库。

这样，动态链接库虽然在不同进程中有不同的映射虚拟空间，但物理空间上共享。.got在不同进程中，虚拟空间和物理空间都不共享。如下图所示：

virtual address -> physical address

—— —— —— —— —— —— ——

|processA |

|—— —— —— —— —— —— ——|

|..... |

|—— —— —— —— —— —— ——|

|dynamic libiraries |----------

|—— —— —— —— —— —— ——| |

|..... | | |..... |

|—— —— —— —— —— —— ——| | |—— —— —— —— —— —— ——|

|.got |---------|---------->|.got |

|—— —— —— —— —— —— ——| | |—— —— —— —— —— —— ——|

|..... | | |..... |

|—— —— —— —— —— —— ——| | |—— —— —— —— —— —— ——|

----------->|dynamic libiraries |

—— —— —— —— —— —— —— | |—— —— —— —— —— —— ——|

|processB | | |..... |

|—— —— —— —— —— —— ——| | |—— —— —— —— —— —— ——|

|..... | | ------>|.got |

|—— —— —— —— —— —— ——| | | |—— —— —— —— —— —— ——|

|dynamic libiraries |---------- | |..... |

|—— —— —— —— —— —— ——| |

|..... | |

|—— —— —— —— —— —— ——| |

|.got |---------------

|—— —— —— —— —— —— ——|

|..... |

|—— —— —— —— —— —— ——|

动态链接库文件外符号重定位用.got就搞定了，那动态链接库文件内符号呢？静态链接同样是在链接阶段重定位就搞定了。动态链接将绝对寻址指令更换成相对寻址指令，只要指令的offset不变，相对寻址指令就可根据当前地址和offset得到正确的地址，这样文件内符号根本不需要重定位了。基于以上两点的处理，代码段在链接后就不需要更改了，这样的代码段也叫做地址无关码(PIC)，也就是说代码段和装载后的地址无关。

延迟绑定(PLT)

由于要跳过.got引用动态链接库的符号，动态链接库比静态链接库慢5%左右，但相比于节省的大量空间还是很划算的。除此之外，动态链接还会有其他的问题，装载时需要进行重定位，会导致性能下降。不如，直接延迟绑定，等到过程调用符号运行时被用到再进行重定位。

整个过程强烈推荐这篇文章，要想理解动态链接重定位，没有比追汇编更好的方法了。动态链接和延迟绑定整个过程都是由动态链接器帮我们完成的。当引用符号(callq)时，先jmpq去plt结构，使用了PLT，引用符号就要先jmpq去plt结构。如果没找到相应的地址，然后再jmpq去.got.plt或.got中。再把符号相应.rela.plt表中的索引和.got.plt相应的表项，pushq入栈，rela.plt中有符号的类型和名字。再jmp到动态链接库中(_dl_fixup)，去全局符号表中找到符号相应的地址。再将地址reloc到.got.plt或.got相应表项。然后就完成了延迟绑定，下次引用同样的符号就可以jmpq去plt结构找到地址。

http://sysfork.com/post/linux-dynamic-lib-lazy-load/

引用

关注「ImportNew」，看技术干货