1. 背景

我们项目为ARPG手游（也没啥见不得人的，就叫暗黑血统手游，后期不少坑钱活动的实现出自我手，轻拍。。。）。我们的服务器框架设计源于某大厂，c/c++和luajit的实现，这次要说的是项目上线时（2014年11月左右）的一次luajit对象内存泄漏（废弃的数据没删，我们都叫泄漏）和由此产生的luajit的表记录监控工具。

2. 问题表现

内存增长，速率大概为200～300MB/天。

我们日志会周期性打印Tcmalloc内存（Tcmalloc分享另见同事Wallen的博客TCMalloc解密）和lua部分内存。获取方法如下：

1
2
3
4
5
6

//tc malloc部分
size_t tc_memory = 0;
MallocExtension::instance()->GetNumericProperty( "generic.current_allocated_bytes", &tc_memory );

//luajit部分
int lua_memory = lua_gc( _L, LUA_GCCOUNT, 0 );

• 通过日志发现在线人数相似时，lua部分内存和总内存在同步增长，c/c++部分内存（即上两个部分差值，主要是网络库、对象体系对象和World部分的内存）基本稳定。
• 日志显示lua的gc正常。

3. 分析

• c/c++部分没有泄漏，player/monster等对象释放没有问题，c层对象析构基本由lua层触发，lua层对应的对象内存释放也是没有问题的。
• 通过日志显示，场景/副本管理的释放也是没有问题的，日志监控的数据也都正常。
• 最后怀疑是一些非主要的lua对象，存在表里没清除。因为lua的代码中，我们没有太复杂的表结构，因此这些泄漏的内存会扁平地存在少量的几个表里。因此，只要能知道各个表的记录数，结合在线人数推算其最大可能数，二者相比较，就能找出泄漏的表，在检查表的增删逻辑，就可以找到泄漏的逻辑。

4. lua表记录数告警方案

如前述，测试发现如果直接用lua全遍历_G下所有表（因为table的值也可能是table，实际上要遍历一棵树），是分钟级别的。按泄漏的速度，内存可以撑到下一次维护，所以，先不慌，看看有没有更好的办法。

然后看看c层luajit表的相关操作，看看有没有更有效率的获取方法（我们c层代码不热更，改c层代码需要等维护重启后才能生效，按泄漏速度，可以接受）。

代码里主要关注的是lua table的增加和删除记录。然后看到lua table的resize（下面luajit相关代码都是luajit2.1分支代码，和1会长得有些不一样，我们已升luajit2.1，将就一下）

1
2
3
4
5

/* Resize a table to fit the new array/hash part sizes. */
void lj_tab_resize(lua_State *L, GCtab *t, uint32_t asize, uint32_t hbits)
{
...
}

逻辑其实就是数组段或者哈希段每次超过2的n次幂，会重新分配内存。

我们不需要精确的数值，其实只要在他每次resize的时候打条日志就能知道这个table大概的记录数，比如上一条日志是1024->2048，那么记录数在1024～2048之间。日志的优化见工程化部分。

怎么确定是哪个table？这里我们能取到的是table的地址，取不到table的名字。这里我们曲线救国，既然能拿到lua_State，可以把lua的堆栈打出来，根据文件名和行号可以定位到代码行号，一行代码没几个table，这样就能确定下来了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

//打印lua层堆栈，编译lua加上调试信息
int32_t c_bt( lua_State* _L )
{	
 	lua_Debug ldb;
	LOG("[LUAWRAPPER](lua_stack) begin .......... ");
    for(int32_t i = 0; lua_getstack( _L, i, &ldb)==1; i++)
    {
        lua_getinfo(_L, "Slnu", &ldb);
        const char * name = ldb.name;
        if (!name)
            name = "";
        const char * filename = ldb.source;

		LOG("[LUAWRAPPER](bt) #%d: %s:'%s', '%s' line %d", i, ldb.what, name, filename, ldb.currentline );
	}
	LOG("[LUAWRAPPER](lua_stack) end .......... ");
	return 0;
}

到此，表中的数据量我们能拿到个粗略的值，也知道是哪张表了，每张表最大的数值可以根据在线人数估计（大部分表记录数约等于在线人数+暂时断线人数+跨服人数，Buff之类的可以乘以一个最大倍数）。二者的比较就由人工比较了，随着时间的增长，有问题的表二者的数据会相差得越来越大。人工过滤存在嫌疑的表，再分析增删逻辑就能找到哪些逻辑忘了清数据了。

5. 工程化

前面讲的只是方案，真正应用的时候，需要减少日志的条数，以减轻分析的工作量。减少日志通过下面两种方式：

• 超过一定大小，才打日志，我们一个服在线是3k左右，阀值取4096。
• 实践发现，如果表在2的n次幂边界发生频繁切换时，resize日志会重复打，所以给lua的表结构加了两个阀值，实现每个边界只打一次。

所以，如果漏的不严重（<4096），随时间增长的很慢，一个维护周期都没到4096，是查不出来的，这种就算了。
有些配置文件很大，这种就选择忽视了，没做特别处理。

5.1. lua table表结构的修改

1
2
3
4
5
6
7
8

typedef struct GCtab {
  ...

  //extended by ludong
  int32_t max_sizearray;
  int32_t max_sizeobj;
} GCtab;

5.2. 初始化(luajit1的数值是不一样的)

1
2
3
4
5
6
7
8
9

/* Create a new table. Note: the slots are not initialized (yet). */
static GCtab *newtab(lua_State *L, uint32_t asize, uint32_t hbits)
{
  ...

  t->max_sizearray = 4096;
  t->max_sizeobj = 4096;
  return t;
}

5.3. 写日志

为了解决库编译依赖的问题，将上层日志函数定义为一个函数变量，进程启动时注册赋值。函数实现赋值就不贴了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

/* -- Table resizing ------------------------------------------------------ */

typedef void (*lua_large_table_warn_func)( lua_State *L, char* fmt, ... );
lua_large_table_warn_func g_lua_large_table_warn = NULL;

/* Resize a table to fit the new array/hash part sizes. */
void lj_tab_resize(lua_State *L, GCtab *t, uint32_t asize, uint32_t hbits)
{
   ...

  //--------------------------------------------------
  // by ludong
  // check resize time
  if (t->asize > t->max_sizearray || t->hmask > t->max_sizeobj) {
      int32_t old_max_sizearray = t->max_sizearray;
      int32_t old_max_sizeobj = t->max_sizeobj;
      t->max_sizearray = (t->asize > t->max_sizearray) ? t->asize : t->max_sizearray;
      t->max_sizeobj = (t->hmask > t->max_sizeobj) ? t->hmask : t->max_sizeobj;
      if (g_lua_large_table_warn) {
          g_lua_large_table_warn( L, "[ltable.c](resize) table:0x%x, array check size:%d, now:%d, node check size:%d, now:%d",
            (size_t)t,
            old_max_sizearray, t->asize,
            old_max_sizeobj, t->hmask);
      }
  }

}

5.4. 性能影响

每个表多8字节（我们64位了，对齐后一样的，32位自己抠一抠），对大部分表多两个逻辑判断，对大表每次日志边界打一条日志和lua堆栈，内存和cpu基本都没没感觉。

6. 后记

这个方案做好之后基本是我们项目上线必检查的日志了，总会有一些不小心就没删的。

1. 概述

本文出自Unity一键导出iOS安装包工具的说明文档容。最最重要的是证书的权限设置，其他根据本文指引和Google，可以毫无障碍地实现此功能。当然，捷径也是有的：
IpaExporter in Unity Asset Store.

如题所述，本文的目的是一键导出iOS安装包。只要提供了证书文件，不需要Apple账号和密码，就可以同时导出ad-hoc和ios store的安装包。工具里提供了一个简单的证书解析器，所以打包的信息均从证书中提取，不需要额外配置，易于维护，省时省心。工具内包含所有脚本，可按需修改。

2. 怎么做

2.1. 准备工作

• 有效的Apple证书
• 证书的App ID不包含通配符. （如前述，导出Apple工程的APP ID用的是证书里的App ID，如果要包含通配符，你得把App ID hard code一下）

2.2. 导入证书并开放访问权限

每次更新证书（私钥），都得重做步骤2.2.2至2.2.3。如果App签名失败，你得重新检查/重做这些步骤。

开放证书权限会导致任何应用都可以使用其进行签名，目前来看也不能拿他去干什么坏事情。

2.2.1 导入私钥和证书

鼠标双击文件即可。

私钥如果是p12文件会需要密码，找私钥提供者提供。如果私钥有更新，可能需要删除原导入的证书后，再导入新的证书。

如果仅更新证书，直接替换原证书文件双击即可。

更多的证书相关知识网上很多，请自行科普了。

2.2.2 开放证书权限（非常重要）

因为在工具里，我们是用bash脚本进行签名的，所以不会弹出窗口请求证书权限，所以我们需要设置证书的权限为”allow all…”。所有步骤见下图（中文版请自行人工智能匹配）。

对每一个证书，你需要检查/重做步骤6-10。

2.2.3 Copy证书进工程

如前所诉，工具里包含了一个简单的证书解析工具，我们可以将证书Copy进工程，当配置文件用。

Copy文件 *.mobileprovision 到工程相对目录 Assets/IpaExporter/IosProvisioningProfile/ .

如果你的工程像我的一样，有几个App Id，那么我建议把同一个App Id的证书文件放到一个这个APP Id命名的目录下。看起来路径像是这样子： Assets/IpaExporter/IosProvisioningProfile/[bundleid]/*.mobileprovision.

目录下仅需要保留最新的证书文件，删掉旧的文件。一旦新的证书在苹果页面上生成，旧的就没用了，所以也没必要保留他。如果新旧文件放在一起，工具没区分，会用错证书。

2.3. 简要的一键打包页面

在工具里可以通过菜单路径打开一键打包页面： IpaExproter -> Build Ipa Window。

下面是每一项的说明：

1. 证书目录的全路径。
2. 版本号。
3. 导出Apk的bundle id。
4. 如果第三项导出Apk的bundle id对应的证书找不到，会有一个错误提示。然后下面会列出当前证书目录下证书所含的所有bundle id。你可以选择一个，然后第三项的内容会被修正。证书文件被更新或者工程被重新编译，缓存数据被清除，请点击刷新按钮重新解析证书导入缓存。
5. 当前证书目录下证书所含的所有bundle id。可以选择1个，第三项的bundle id会随之改变。
6. Xcode的bitcode选项。万恶之源，请保持他勾上，不如会导致时间变得很长，这里是演示怎么控制导出的Xcode工程的选项。
7. 勾上此选项，会在出包时加上BuildOptions.Development | BuildOptions.ConnectWithProfiler | BuildOptions.AllowDebugging。
8. 工具里包含一个空场景，勾上时会只包含这个空场景，否则包含Player Settings下的场景。
   9.如果一切顺利，点击此按钮回生成Apk包。Apk包生成后, 会弹出其所在目录。如果失败，参考3.3获取失败日志。

3. 工具详述

3.1. 目录结构

以下文件路径均相对于IpaExporter，各文件说明如下：

3.2. 打包步骤

点击Build按钮，会触发开始打包。打包的逻辑在文件 IpaExporter.cs里。步骤如下：

• 步骤 1: 准备打包环境。打包UI上的配置会从文件反序列化，并不依赖UI。这样方便从Unity命令行启动打包，方便日常的Daily Build。
• 步骤 2: 导出XCode工程。导出工程时优先选择开发证书，方便打开XCode工程时调试。如果没有开发证书，会选择逻辑上的第一个证书（天知道是哪个，不重要，最后导出的IPA包由脚本指定）。
• 步骤 3: 根据需要修改XCode工程。Unity5以后提供了接口，工具中把Bitcode选项禁用了。你可以加其他的capability，如推送之类的。
• 步骤 4: XCode工程里，苹果把导出IPA文件分成了两步，分别是archive和export。这一步里工具会生成两类bash脚本，一类脚本名字为archive.sh，就一个，用来编译并生成release版的无签名archive文件；另一类脚本叫export_xxx.sh，用来生成各个Provisioning Profile对应的IPA。需要注意的是，Development Provisioning Profile没有生成对应的脚本，因为测试发现Development Provisioning Profile里的team名字可能和私钥对不上。如果你一定要生成Development版的IPA，你可能需要hard code组名（可能还有其他信息），不过大多数时候我们只生成app-store版和adhoc版的证书。
• 步骤 5: 执行步骤4里生成的脚本。

3.3. Logs

失败的时候，你可以到下面的地方查找日志：

• 首先检查Unity Editor里的控制台窗口，打包步骤里1-4步如果有错误，会输出到这里。
• 打包步骤里第五步执行脚本的日志会被输出到下面的日志文件： [TheProjectPath]/OsxCmd/cmd.log

4. 联系方式

任何问题 Email: noodle1983@126.com.

1. 简介

这是Unity Android APP il2cpp热更解决方案的Demo（Git地址）的说明。

和现有的热更解决方案不同的是，他不会引入多余的语言（只是UnityScript，c#…），对Unity程序设计和编码没有任何限制。你可以在预置和场景里的GameObject上添加任何的Compnents组件，需要序列化的和不需要序列化的，他们都是可以热更的，也不需要做额外的标记处理。简而言之，在此方案下，Unity的所有资源和脚本，都是可以热更的。

本文接下来将介绍如何去制作热更文件和如何应用这些热更文件。为了简化Demo的设计，Demo包含的热更文件会事先以全量更新的方式制作好，一起打到了Apk里面。具体到项目中热更文件得放服务器，正式上线得放CDN，以增量更新的方式捣鼓出和文中一样的目录结构就OK了。

2. 方案总览

Unity在以il2cpp方式导出Android工程（或者Apk文件）的时候，代码会被编译成libil2cpp，而相关的资源、配置和序列化数据会以他们各自的格式导出到android的assets目录（assets/bin/Data）。这两部分，libil2cpp和assets目录，必须匹配（即需要在同一次打包中提取，可能有的变了，有的没变，增量方式只提取变化的部分）才能正常工作，不然Unity会在启动时崩溃。本方案就是热更这两部分。

热更的正式流程如下图.

流程说明：

• 步骤1，在Unity的逻辑之前，libbootstrap会检查本地是否有Patch. Apk安装后，没应用过任何热更，本地是不会有Patch文件的，走no流程。如果热更过，则会有Patch目录，走yes流程。Patch目录如何准备，后面会将到。

• 步骤2，加载Patch目录对应架构（arm/x86）的libil2cpp库，并应用assets目录的更新文件。

• 步骤3，开始Unity的流程，进入Unity第一个场景，并执行相关的Unity Script，一般是C#，我们都以C#举例。

• 步骤4，检查服务端是否有新的patch，这步demo没有演示，需要自己实现。

• 步骤5，下载新的patch，这步demo也没有演示，需要自己实现

• 步骤6，根据规则准备patch目录，详细规则会在后面描述。在Demo中只是将全量更新包解压，全量更新包打包的时候目录结构就是对的，所以不需要做其他的处理。

• 步骤7，调用libbootstrap的接口设置patch目录，因为libil2cpp已经加载进进程，所以需要重启APP，从新的patch目录加载patch。这步Demo中有设置patch目录的例子。

• 步骤8，重启APP，Demo提供了纯C#代码。

• 步骤9，没有新的Patch，就正常进入游戏了。

流程里更详细的描述和如何生成Patch文件，见第三章。

3. Demo详述

3.1. Demo目录结构

工程所有文件均置于AndroidIl2cppPatchDemo目录下。各文件目录说明如下表。

所有文件就这么多，项目用git管理，master分支为母包分支，version1和version2分支为热更1和热更2分支，分支间会有些细微的差别，version1主要测试序列化数据，version2添加了新场景和新脚本，具体可以diff查看。下面会详细描述打包过程和如何应用热更文件。

3.2. 打包过程

所有的打包逻辑在文件Editor\AndroidBuilder.cs里。展开主菜单AndroidBuilder, 可以看到有5步，为了和热更启动流程区分，我们就叫他过程。

• 过程1：以il2cpp的方式，导出Gradle Android工程。选择Gradle Android工程，而不是ADT Android工程，只是因为Unity2018不再支持ADT方式。Demo并不依赖AndroidStudio，只是导出的Android工程目录结构是以Gradle的方式注释，之后的构建步骤都是调用原始JDK/SDK的方式。Demo这部分的代码可以复用，但需要根据项目需求做一些修改。

• 过程2：需要修改一下Android工程，因为libbootstrap需要在进入Unity的帧循环前，检查加载本地准备好的patch。大多数情况，你可以复用这个步骤的代码。但是如果你的项目修改了Unity Java的继承体系，你需要检查一下这块代码是否有调用到。如果没有调用到，后面Unity帧循环中的逻辑和资源，用的都是Apk内的相应文件。

• 过程3：生成热更文件。如在第二章所述，patch分为两部分，il2cpp库和assets/bin/Data目录。具体做法代码均有提供，需要注意的是必须遵守各个文件的命名方式和相对路径。各个文件均有压缩，对于增量包，如果压缩前的文件和之前相比没有变化，则不需要制作对应的压缩文件。这部分制作压缩部分的代码可复用，增量部分需要自己实现，热更文件最好也加进版本管理（svn/git/…）中。

• 过程4: 生成打包的windows脚本。脚本仅依赖JDK/SDK命令，可复用。生成脚本后，Android工程就不依赖Unity了，可以随意替换文件，再次调用脚本生成新的Apk。需要注意的是，打包用的so动态库，是pkg_raw目录下的so文件，替换时请注意。首次会在Unity目录下生成keystore目录和相应的签名文件，可以将此签名替换，并修改导出脚本中的签名密码。

• 过程5: 执行过程4中的脚本，生成Apk安装文件，可复用。

主菜单AndroidBuilder下还提供了菜单“Running Step 1, 2, 4, 5 for the base version”，这是一键构建母包版本用的，母包不需要制作patch文件，所以少了过程3；和菜单“Runnnig Step 1-4 for patch versions”，这是一键构建Patch用的，因为在demo里，不需要导出Apk文件。

关于打包这里得多说两句。 如果没有采用AssetBundle的方式打包，Unity会按各自格式，将所有场景和依赖输出到assets/bin/Data目录，这样子也是可以热更的。但是，不要这么做，因为这样做微小的改动会影响到多个文件，导致热更文件过大。最好是自己用AssetBundle的方式将资源做一个清晰的划分，打包好的AssetBundle放在assets下的其他目录。需要注意和libil2cpp库和assets/bin/Data的文件向匹配（保证是同一个版本的输出）。运行时可以重写AssetBundleManager.overrideBaseDownloadingURL加载最新的AssetBundle。

3.3. 运行时应用热更文件

我们回顾一下第二章的流程图，结合打包过程和Demo的代码，做进一步的说明.

打包过程2里，在Unity的游戏逻辑之前，插入了三行Java代码。

1
2
3
4

+        System.loadLibrary("main");
+        System.loadLibrary("unity");
+        System.loadLibrary("bootstrap");
        mUnityPlayer = new UnityPlayer(this);

这三行代码保证了上图中步骤1-2能在步骤3之前执行，下一行mUnityPlayer的代码即开始了步骤3的执行。步骤3之后所有的逻辑，都是已热更过的il2cpp库里的Unity Script（c#，…）了。热更部分的逻辑如果有修改，会在热更后体现，如果这部分的bug不影响下次热更，则可以通过热更修复，否则应指引用户清除本地数据，以母包热更逻辑更新到最新。所以，在方案的应用中，仍需尽量保证热更部分的代码稳定，不能随意更改。

如前所述，Demo里没有步骤4和步骤5的相关逻辑，步骤6中Patch的准备，Demo只是简单地将全量压缩包解压，相关逻辑在Script/VersionSettor.cs文件中。准备更新目录时，应保证libil2cpp部分被解压，命名方式和Demo保持一致，而assets_bin_Data下的文件不需要解压，应保证目录结构和Demo保持一致。如果是增量更新，Patch目录下的文件应该是相对于母包的修改文件。在持续热更中，应保证在步骤7前，本地当前Patch目录的完整性（保证运行中的App还能正常执行），新的Patch应新建目录，通过硬链接的形式从当前Patch目录中提取所需要的没变化的文件，准备好后执行步骤7，重启后将老Patch目录删除. 步骤7和步骤8的代码也在Script/VersionSettor.cs文件中，样子如下

1
2
3
4
5
6
7
8
9
10

//4. tell libboostrap.so to use the right patch after reboot
string error = Bootstrap.use_data_dir(runtimePatchPath);
if (!string.IsNullOrEmpty(error))
{
    messageBox.Show("use failed. path:" + zipLibil2cppPath + ", error:" + error, "ok", () => { messageBox.Close(); });
    yield break;
}

//5. reboot app
yield return StartCoroutine(Restart());

4. Verify 和 Build

4.1. Verify

安装预编译的Apk文件，点击按钮可以切换各个版本。

Apk链接

4.2. Build

依赖

• Unity (我用Unity2017/Unity2018)
• JDK.(我用JDK1.8)
• Android SDK.(我用Android SDK platform 23 和 build tools 26.0.2（低于26.0.2，Unity2018不支持），最好是这两个版本，不然得重新下载)
• Android NDK r13b. (Unity il2cpp原来只支持这个版本，现在不知道放开没，反正这个版本没问题)
• Git

Build指引

• 1. 在Unity中（Edit->Preference->External tools）设置好 JDK/SDK/NDK 路径，打包代码里会从Unity中读取。
• 2. 如果你的Android SDK的build tools版本不是26.0.2，需要修改代码 AndroidBuilder.cs，第14行.
• 3. 如果你使用的Android platform不是android-23，修改代码 AndroidBuilder.cs，第15行.
• 4. 出母包，执行菜单 AndroidBuilder->Run Step 1, 2, 4, 5 for base version, 成功后会弹出文件管理器显示apk所在的目录.
• 5. 一般来说你不需要打Patch文件，如果要打，用git checkout version1或version2，执行菜单 AndroidBuilder->Run Step 1-4 for Patch Version。PrebuildPatches目录下的相应文件会被更新。

5. 剩下的工作和建议

打包部分

• 设置部分需要根据项目实际做修改。
• 热更文件的增量版本化管理。

运行时部分

• 检查新版本和下载热更文件。
• 持续增量更新的Patch目录的准备。
• 用Asset Bundle管理资源。

另外，打包的工作尽量自动的一键化，一次化，除非你想在打包当晚集体晒月亮。另外，低成本的打包流程，大家都愿意在真机上看结果，利于产品的稳定。Demo其实提供了一套自动化的框架和脚本，理解透，化为己用，也是幸事一件。如果有更好的方式，欢迎讨论。

Restart Android App In Unity Pure C#

So far so good

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

using (AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"))
{
    AndroidJavaObject currentActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity");

    AndroidJavaObject pm = currentActivity.Call<AndroidJavaObject>("getPackageManager");
    AndroidJavaObject intent = pm.Call<AndroidJavaObject>("getLaunchIntentForPackage", Application.identifier);
    intent.Call<AndroidJavaObject>("setFlags", 0x20000000);//Intent.FLAG_ACTIVITY_SINGLE_TOP

    AndroidJavaClass pendingIntent = new AndroidJavaClass("android.app.PendingIntent");
    AndroidJavaObject contentIntent = pendingIntent.CallStatic<AndroidJavaObject>("getActivity", currentActivity, 0, intent, 0x8000000); //PendingIntent.FLAG_UPDATE_CURRENT = 134217728 [0x8000000]
    AndroidJavaObject alarmManager = currentActivity.Call<AndroidJavaObject>("getSystemService", "alarm");
    AndroidJavaClass system = new AndroidJavaClass("java.lang.System");
    long currentTime = system.CallStatic<long>("currentTimeMillis");
    alarmManager.Call("set", 1, currentTime + 1000, contentIntent); // android.app.AlarmManager.RTC = 1 [0x1]

    Debug.LogError("alarm_manager set time " + currentTime + 1000);
    currentActivity.Call("finish");

    AndroidJavaClass process = new AndroidJavaClass("android.os.Process");
    int pid = process.CallStatic<int>("myPid");
    process.CallStatic("killProcess", pid);
}

最近所在的公司清算了，在家休息，陪陪儿子。在游戏圈子多年995，一直没好好陪他玩，刚好有个航展，男孩子嘛，应该都喜欢的，和老婆商量一下，就这么定了。那娃听说去看飞机，懵懵懂懂就个好字。然后上网找攻略，才发现少得可怜，只能按官方说明去安排，有些东西得堵一堵运气。

• 方案

刚开始心大，想着先到长隆住一宿，玩两天，再到珠海城里接驳车附近住一宿，第二天搭接驳车进展馆。这样，避免场馆附近可能堵车，可以安排得比较从容。后来发现航展期间住宿普遍涨价，原来100多的房子去到了500左右（500块买100多的服务，顿时整个的就不好了），再加上长隆到市区，再到展馆的距离还挺远的，谈不上顺便，还不如把长隆的行程砍了，直接当日从广州长驱直入，花个100元停车费停接驳专用的停车场，专心看完航展下午5点就回。恩，就这么定了。航展公众日三天， 当然选工作日。

• 买票

因为儿子有身份证（他妈英明），买电子票，一般的，便宜，在淘宝更便宜。多说两句，另外一种贵一些的动态演示区套票，原来想买这种，以为这种看飞机视角更好，买票时看已经晚了，这类票还是提前得提交买。因为没买，具体效果不好说，但是就溜娃来说，一般的票就够了，表演区域够大，边上一点的地方可以躺下来，看飞机从头上空飞过。

• 路况和停车

家住翡翠绿洲，早上6点起床，吃早餐，6点半出发。直接导航到离机场最近的R1停车场，恩，碰运气，停不了再去下一个，反正这么大个活动，堵了一定会有交警疏导交通，这点还是挺好的。出发得早，一路顺畅。进机场大道后每个出口都有交警驻守，上面有就近停车场的指示牌。我们没理，一直开，接近机场会有些私人的停车场，一个P字停车牌，一问才知道是私人的，被迷惑了，继续开。直到一个T字路口，交警封主路，指引社会无出入证车辆右拐，随之发现这是个巨大的停车场，P5停车场。停车场只是稍微平整的一块红土地，没有进出的抬杆，最后证明是免费的。前一公里左右已停满车，一路顺着志愿者和交警指引，中途看好了接驳车位置，挺好车，和小摊贩买了墨镜片，直奔接驳车。中途夫人要上厕所，等了小会儿。这时人已很多，接泊车也很快，稍微排下队，上车，到展馆门口验票，安检，进馆，9点出头，远远看见表演已经开始了，可以说一路还是停顺的。

• 观展

先说说配套，可以带杯子食物，瓶装水不能外带，但是珠海人民还是挺良心的，矿泉水1.5一瓶，自动零售机有售，排队买水比较闹心，不能一次选多个商品，得一个一个买，也有不会用的，买两瓶水足足等了10分钟。也有人工售水的，应该会好些。午饭一律套餐40，中午餐区黑压压一片，要花点时间找位置，买餐KFC要排队，其他两个本土化的汉堡和赛百味不用，其他还有中餐。秩序还挺好。

然后就是观展了，先说室外的。静态展示有好大一片区域，中心是j10，运20，直10等一众网红，人多，大家都很自觉，排个照，走人，留给后面的人。边缘一些是民用的小轻型飞机，这块区域就是前面说的，可以躺下来，看飞机在头顶略过。稍微远一些，一条栏杆把展示区和起飞跑道隔开。当然，栏杆处都是人。恩，没找到动态展区在哪。。。早上的天气适宜，户外看，下午就热了，可以在航空航天馆叹着空调，隔着玻璃看。但是在室内看没有室外那种战机轰鸣的震撼，和在电脑上看没啥区别，不爽，我就带着儿子奔室外了，留夫人在室内看。飞机的表演，最震撼的是战斗机引擎的轰鸣声，有机会还是想听听j20拉音爆的轰鸣声，好羡慕四川的朋友。一路没怎么拍照，反正也没别人拍得好，不如好好地看，倒是儿子拿着最近给的5s，趁着新鲜劲在拍。比如这张，飞机不错吧。

室内的带娃的要注意了，有好些飞行模拟器可以体验，注意分配好时间。我儿子就在一个su27的模拟空战系统上挪不开脚。航空航天馆的分量最重，都是国字号和各大公司产品，图文并茂加视频，小朋友和大人都适合。国内网红全露脸了，算是这两年这个行业的成果展，养眼。国外的不多，随他。除了航空航天馆，还有陆上装备馆和无人机馆。时间和兴趣原因，陆上装备没细看，去看了无人机馆。无人机馆主要是民用的无人机，多，估计这一领域又是分为中国和其他国家的典范。

展馆5点闭馆，儿子脸就拉下来了，一问，原来还想再玩飞行模拟器。。。（现在还催着我上淘宝找）。好说歹说，才走。原路一路回广州，累，还是觉得值。和儿子相约，两年后再去。

to be continued…
未完待续…