标签归档:Mac

macOS 下 Unity 执行子进程调用时无法读取到系统环境变量问题修复备忘

发现问题

由于我们的游戏工程中集成了多个渠道的 Android 版本的 SDK,而不同的 SDK 依赖的一些库多少有些区别,而且不同的 SDK 通常都有着各种不同的需求,最终我们的处理方式是针对不同的 SDK 做不同的打包预处理,这样就可以在打不同的渠道包的时候,按照不同的 SDK 的需求做相应的处理,确保不同的 SDK 的渠道包里头包含的库文件和资源文件不同。

这样我们就在打包执行先执行了一个 Gradle 的 build 脚本,通过 Gradle 的脚本中不同的任务来完成针对不同 SDK 的 Android 工程的编译以及资源文件的删除和拷贝等等。

但是在我们的 Jenkins 打包服务器上打包出来的 APK 文件安装到手机上,启动游戏之后总是提示丢失了类文件,直接就闪退了,这说明打包的过程中出现了问题。一步步排查,最后发现在打包预处理的 Gradle 脚本执行的时候抛出了异常,异常的提示信息也非常的明确,就是 Gradle 在执行 Android 工程的 build 时缺少 ANDROID_HOME 系统环境变量或者在 Gradle 工程的 local.properties 中缺少了 sdk.dir 的设置项,导致 Gradle 在编译 Android 工程时无法正确地引用 Android SDK 进行编译,最终导致 Unity 打包出来的 APK 中缺少了类最终造成了启动就闪退的问题。

解决方案

那么最简单的方法当然是通过添加 local.properties 文件来解决这个问题,可是我看了一眼 Android Studio 生成的 local.properties 文件的内容:

## This file is automatically generated by Android Studio.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must *NOT* be checked into Version Control Systems,
# as it contains information specific to your local configuration.
#
# Location of the SDK. This is only used by Gradle.
# For customization when using a Version Control System, please read the
# header note.
#Thu Mar 22 17:12:39 CST 2018
ndk.dir=/Users/helihua/Library/Android/sdk/ndk-bundle
sdk.dir=/Users/helihua/Library/Android/sdk

这货原本就是 Android Studio 创建 Android 工程时或者说是打开工程时根据当前的系统变量自行生成或者设置的,而且明确告知别把这个文件放到 git 等版本管理控制中去,也就是说别把你本地的一个配置给推送到服务器上去,防止别人从服务器上拉取下来你这个本地配置,这样就可能导致团队中其他的小伙伴在编译的过程中出错。

那么我们自然也不能选择这种方式了,而且 Android Studio 这货非常省心地帮你把这个文件都给放到了工程的 .gitignore 中去了,如下:

*.iml
.gradle
/local.properties
/.idea/workspace.xml
/.idea/libraries
.DS_Store
/build
/captures
.externalNativeBuild

看,人家都不给你犯错误的机会呢,所以说我们还是找别的方法吧。

由于我们的项目中执行 Gradle 脚本是通过 C# 提供的执行子进程的方式来完成的,那么找不到 ANDROID_HOME 这个环境变量的进程实际上就是我们执行预处理的那个 C# 进程了。那么有没有可能单独针对这个进程设置系统变量呢,一查文档还真有,那么就可以简单的这么处理了:

gradleProcess.StartInfo.EnvironmentVariables["ANDROID_HOME"] = EditorSetup.AndroidSdkRoot;

这样一来问题自然就得到解决了,EditorSetup.AndroidSdkRoot 这个变量返回的是我们在 Unity Editor 中设置的 Android SDK 的路径,当然具体要不要用这个变量就看自己的选择了,通常来说如果我们想要正常打包 Android 的包的话,这个变量肯定是正确的 Android SDK 的路径了。

延伸思考

这个问题越想越让人觉得奇怪,你说我作为一个前 Android 开发者,怎么可能会没有配置 macOS 的系统环境变量呢,电脑上 ~/.profile 文件中早都配置好了 ANDROID_HOME 等等环境变量的啊。那么为什么现在才暴露出来呢?

  1. Android Studio 等 IDE 在 macOS 上不只是会读取 macOS 的环境变量,还会尝试去读取 ~/.profile 和 ~/.bash_rc 等等文件中设置的环境变量,所以 Android Studio 等 IDE 在启动的时候就能正确检测到我们已经在 ~/.profile 等文件中配置好的 ANDROID_HOME 变量了;
  2. Unity Editor 并不会尝试去读取 ~/.profile 等文件中设置的环境变量,而只是从其父进程 launchd 中继承了已设置的环境变量,而这些环境变量中并没有 ~/.profile 中我们通过 export 设置的各种环境变量,平时我们执行很多 Gradle 命令的时候,通常都是直接从终端中执行的,而终端程序除了会从 launchd 进程中继承已有的环境变量还会加载 ~/.profile 等文件中的环境变量的,所以导致了实际上这个问题是一直存在的只是没有暴露出来。

最终问题的根源找到了,是因为 Unity Editor 这个进程中的环境变量中缺失了 ANDROID_HOME 这个变量,那么最终需要做的就是让 Unity Editor 这样的程序的环境变量中有 ANDROID_HOME 这个变量,在杨威同学和 Google 的帮助下,最终确定的方法就是通过创建一个交给 launchctl 加载的 plist 文件,在 plist 文件中声明我们需要执行的命令 launchctl setenv 和对应的参数,让系统在启动的时候自行通过 launchctl setenv 命令将 ANDROID_HOME 等环境变量设置到 launchd 这个牛逼的父进程中去。

我们可以先看一下 macOS 系统上进程的层级关系:

我们可以看到所有进程实际上都是由 kernel_task -> launchd 这样一路 fork 出来的,看看进程 ID 也能明白得差不多了。废话少说,怎么做呢?

好吧,我参考了这篇文章

大体的流程就是这样的:

  1. 创建一个用于 launchctl 在系统启动的时候自动加载的 plist 文件,在该 plist 文件中调用 launchctl setenv 命令设置参数;
  2. 将 plist 文件放到 ~/Library/LaunchAgents 目录下去,然后重启系统即可,当然如果你现在不想重启系统,可以执行 launchctl load -w ~/Library/LaunchAgents/[com.laputa.SetAndroidEnviroment.plist] 命令(替换方括号中的 plist 文件名)来主动加载该 plist 文件,加载成功后,重新启动 Unity Editor,在 plist 文件中设置的环境变量在 Unity Editor 进程中就生效了。

把我的 plist 文件贴上来:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
    <key>Label</key>
    <string>setenv.Android</string>
    <key>ProgramArguments</key>
    <array>
      <string>/bin/launchctl</string>
      <string>setenv</string>
      <string>ANDROID_HOME</string>
      <string>/Users/helihua/Library/Android/sdk</string>
      <string>ANDROID_NDK_HOME</string>
      <string>/Users/helihua/Library/Android/sdk/ndk-bundle</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

注意事项:plist 文件如果向上文提到的那个链接中的文章中放在 /Library/LaunchDaemons 目录下的话,重启之后貌似就不会生效,而放到 ~/Library/LaunchAgents 目录下在重启之后是可以生效的,我是在 macOS High Sierra 10.13.3 上测试的。

如何在 OSX 10.11 EI Capitan 中给移动硬盘分区并支持 NTFS

趁着这几天京东白条免息,买了一个新的移动硬盘,想着给自己服役快5年的老移动硬盘做个备胎来着,上午的单下午送到公司,拿过来那就先分一下区呗,想着布局应该是这样的,两个分区为 OSX Extended (Journaled) 格式,一个用来备份一些重要数据,一个用来做 Time Machine 备份用,剩下的那个分区就留作共享的 NTFS 分区吧,偶尔还是会用到这个 Windows 的,家人同事偶尔用用的话,这个 NTFS 还是比较有必要的,否则空有个硬盘完全无法用上也是件蛮悲剧的事情呢。

好,名字我都起好了,就分三个盘:

  1. Data-OSX
  2. Backup-OSX
  3. Data-NTFS

感觉棒棒哒,那么开始吧。打开 Disk Utility 开始吧,然后碰到了各种奇怪的问题,这儿我就不多说了,后面一步步来吧,碰到问题的地方,我都会一一吐槽的。

第一步,格式化整个硬盘

QQ20151110-2

从左侧列表中,选择 External 下的 HGST TOUR S Media (这个自己要加小心啊,别选错了,一定要选外接的自己要格式化的硬盘),选中硬盘了之后,点击工具栏上面的那个 Erase 按钮(中文应该是擦除吧),这时会弹出一个提示框,然后我们就可以输入各种参数了。

  • Name,名字随便起吧;
  • Format,看上我们可以选择的有 OS X Extended (Journaled) 系列格式、MS-DOS (FAT) 和 ExFAT 三个格式可以选择,然而实际经验告诉我们如果你想分区的话,实际上最终只有 OS X Extended (Journaled) 格式可以选择,相信我吧,不会错的;
  • Scheme,看上我们又有得选择噢,有 GUID Partition Map、Master Boot Record(俗称 MBR)和 Apple Partition Map 这三个选项,Apple Partition Map 我压根就没有试过,我想 MS 肯定是不会支持这个鬼的(其实我希望我错了),然后我尝试了一个我听得比较耳熟的 MBR,实际证明我又错了,最终的结论就是如果我想让这块硬盘能分区,我能选择的就是 GUI Partition Map。

综上,请按照上图所示的选项进行设定,也就是 Format 必须是OS X Extended (Journaled),Scheme 必须是 GUID Partition Map,然后点击 Erase,稍微等一会儿,整个硬盘格式化就完成了。

第二步,新建分区

Mac OSX 下面显示硬盘是这样的,一个物理硬盘下多个逻辑分区,那么我们分区是针对物理硬盘来进行操作的,所以还是先选中 External 下的 HGST TOUR S Media 物理硬盘,然后点击工具栏上的 Partition(分区)按钮,这时候我们会看到一个这样的弹出面板:

QQ20151110-3

这个弹出面板描述的内容就是,目前这个物理硬盘上就有一个名为 Laputa-HGST 的逻辑分区,分区格式是 OS X Extended (Journaled),容量大小是 999.861 GB。

这个时候,我们点击左侧蓝色圆饼下面的加号按钮,新建一个分区,用鼠标点击圆饼中你想要的那个分区,那个小白点是可以用来拖动调整磁盘大小的(当然通常我们数学都还蛮好的,还是键盘输入更妙一些):

QQ20151110-4

然后给分区命名为 Data-OSX,设定文件格式为 OS X Extended (Journaled),设定其大小为 300 GB。

依次再创建一个名为 Backup-OSX 的分区,文件格式为 OS X Extended (Journaled),设定其大小为 350 GB:

QQ20151110-6

现在一个饼实际上已经分成三块了,那么剩下的那个分区就是我们要的那个用来做 NTFS 格式的分区了,用鼠标选中之后,设置分区名为 Data-NTFS,调整分区格式为 MS-DOS (FAT):

QQ20151110-7

这下三个分区都设定好了之后,点击 Apply(应用)按钮,等一会儿就 OK 了,由于 Mac OS µX 自身并不支持 NTFS 文件的写入(但是支持读),所以也没有将磁盘格式化为 NTFS 的功能。Mac OS X 上有一个付费的 NTFS for Mac OS X 软件很好用,装上之后,读写 NTFS 硬盘文件就全无障碍了,他们家还有 ExtFS for Mac OSX (用在 Mac OS X 上访问 Linux 系统下常用的文件格式 Ext 系列格式的磁盘),还有一个 HFS+ for Windows (用在 Windows 系统下访问 OS X Journaled 系列格式的磁盘)。

那么接下来格式化 NTFS 盘的这一步,我们就得自己把硬盘插到 Windows 电脑上再格式化一下就好了。


这次格式化硬盘碰到的问题就是 Disk Utility 这货跟之前版本的 OS X 中的不一样了,然后碰到了一些隐性的设定,来回折腾了好些工夫,而网络上能找到的都是早些时候版本的 OS X 下的移动硬盘格式化的教程,既然自己遭罪了,我想可能也会有人碰到跟我一样的问题,那么就纪录一下吧。