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 {
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 资源的更新。
关于我
Hello,我是 却把清梅嗅 ,如果您觉得文章对您有价值,欢迎 ??,也欢迎关注我的 博客 或者 GitHub。
|