Unity平台能够提供非常强大的2D、3D特效，相比OpenGL而言，使用Unity` 意味着更低的开发成本，更便捷的可视化开发体验。
在常规的 Unity 开发中，与 Android 的联调通常使用 建立Unity项目 - 导出Android项目 - 编写并导出aar - 导入Unity再次编辑 - 再次导出apk 来实现，整体过于繁琐，无法满足在双平台的开发过程中，频繁修改、联调 的需求。
本文将针对两个平台如何快速验证功能的更新，进行简单的分析。
1. 实现步骤 & 验证
先说结论 ：Unity 内部就已经为 Android 导出项目提供了 增量更新 的支持，这意味着，你第一次导出Android项目后，如果追加了新的场景和资源，再次导出到该目录下时，其策略并非粗暴的强制覆盖，而是选择性的增量更新。
这里笔者做了简单的试验，首先，将 Unity 导出 Android 项目自动生成的 UnityPlayerActivity 进行了逻辑修改：
public class UnityPlayerActivity extends Activity implements IUnityPlayerLifecycleEvents {
//...
// 在Unity导出自动生成的类中，追加成员和方法，再次导出后这些代码仍然存在
private int count = 1;
public int increment(int value) {
count += value;
return count;
}
}其次，我们回到 Unity 工程中，手动修改已有的材质文件，并追加新的 C# 脚本：
一切准备就绪，重新将该 Unity 项目进行导出到原有的 Android 目录下。
为了让导出前后的文件变更更直观，笔者将导出项目加入了版本控制，导出成功后，我们在 AndroidStudio 的 git 工具中看一下，Android 导出项目前后的差异性：
由此可见，针对 Unity 项目中材质、脚本文件的变更，都在打包的过程中合并到了 assets 目录下对应的文件中。
而我们针对 UnityPlayerActivity 中追加的代码逻辑，也并不会随着导出而被暴力覆盖，经过编译运行，所有功能的更新都成功反映在手机 APP上。
2.项目的简单调整
在亲自进行了一些试验后，我们得知项目的导出并非暴力覆盖，因此可以针对现有的项目进行简单的调整：
这里笔者选择新建一个名为 unity-support 的 Module，保证所有业务相关的代码不涉及到 unityLibrary 的修改，后续平台间的桥接方法和事件通信相关代码，都放入到新建的 Module 中。
依赖关系我们选择从上到下的 launcher -> unity-support -> unityLibray:
-
launcher:APP壳工程，用于demo运行; -
unity-support: 业务模块，用于Android与Unity之间的业务通信，以及后续打包为aar文件，交给Maven管理； -
unityLibrary:Unity导出模块，用于保留Untiy资源的更新。
