极致(Acme)-CG素材基地

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
热搜: 活动 交友 discuz

Unity自动构建(2)|iOS编译遇过的依赖库、签名、第三方SDK的麻烦

2018-8-14 10:41| 发布者: admin| 查看: 114| 评论: 0

摘要: 做软件开发几年了,随着经验的增长,你会发现,很多时候遇到一些抓狂的问题,他并不是来源于技术本身的,而是来源于技术以外的一些周边。比如说运维、安全、流程、自动化、编译构建啊等等。我上一篇文章《Unity自动 ...

做软件开发几年了,随着经验的增长,你会发现,很多时候遇到一些抓狂的问题,他并不是来源于技术本身的,而是来源于技术以外的一些周边。

比如说运维、安全、流程、自动化、编译构建啊等等。

我上一篇文章《Unity自动构建思考(1)|自动构建机器的选择经验和思考》中,提及了自动构建这件事情。在几年的Unity游戏开发工作中,其中一个让我非常抓狂的地方,就是使用Unity引擎进行iOS编译出包。

为什么说使用Unity编译iOS会很麻烦?

我们都知道,Unity游戏引擎,使用了Mono引擎作为它的脚本语言引擎,而苹果iOS开发的官方语言是Objective-C和Swift(或其它方式编译出来的静态库.a),编译工作,必须是在Xcode工程上进行的。

所以,要进行Unity的苹果编译,本质上,首先要把Unity的工程,包括脚本、资源等等,转换成Xcode工程。




(Unity编译iOS,实质是转换成Xcode工程)

这,就是麻烦的开始。

因为生成出的是Xcode工程,编译的Xcode工程,也就是说,你在Unity上的一些开发知识,就变得不再有用了,你进入了iOS开发领域。

来到iOS开发领域,就要接受iOS工程编译的洗礼,常见的坑有依赖库、签名、第三方插件集成几个问题。

依赖库,需要外挂脚本处理

在Unity5以前,比如Unity4,Unity有一个很蛋痛的设计,就是,它生成的那个Xcode工程,是不会帮你处理依赖的Framework的。

怎么理解这件事呢?

你比如说,游戏里面引用了一个第三方的库插件(比如极光推送),这个插件需要引用了一个iOS静态库(jpush.a文件),但是问题是,这个.a库可能依赖了一个UserNotifications.framework,Unity是并不知道你的.a静态库会对Framework有依赖的。

所以,生成出来的这一个Xcode工程,根本编译不过,在编译的阶段,它就会告诉你,缺少了对某个Framework的依赖。

那这事怎么办呢?一般来说,常见的解决方法是使用一些开源的Xcode工程修改工具,在Xcode编译工程出来以后,对这个Xcode工程进行依赖库的修改和补充。

比如我喜欢用Python写成的mod-pbxproj;有的人喜欢Ruby写成的XcodeProj,功能更强大。

一般自动化的Unity编译,使用BuidPipeline.BuildPlayer命令后,这些工具就会出场,对Xcode进行工程层面的一些修改。

常见的操作就是诸如对一些依赖库(Framework、Library)和iOS功能(比如GameCenter/In-App-Purchase等)进行添加、修改,尽可能做到Unity生成的工程,在经过脚本修改后,直接就编译成功,减少人工干预。

签名,各种小问题

苹果对安全的投入是非常大的,从它的签名机制就能看出来了——太tm麻烦了。




(Xcode 8中“自动管理签名"功能)

其中有一次,Xcode 7升级到Xcode 8,增加了“自动管理签名”的功能。在官方看来,他在这一个签名流程进行了一些改进,还有优化简化了这件事情。

但是对于当时我来说,还有公司的其他小伙伴来说,简直崩溃。因为之前的手动签名流程,都不再有效了。

这个“自动管理签名”的功能,要求使用者,在iOS Developer登录后,就能方便地进行Xcode的打包签名管理。

问题是,实际的公司作业流程中,iOS证书一般是由发行方(运营商)进行颁发,并把证书文件发往研发方(游戏研发)。出于发行方的保密,研发方在打包iOS最终包时,使用的是具体的证书参数设置,而没有具体的iOS Developer登录权限。

对于这种流程,“自动管理签名”这个功能,其实是没啥作用的。你需要把它关闭掉,并且手动设置。起初为了达到这功能,我把mod-pbxproj也进行了一点修改,以达到“关闭自动管理签名”这个功能。

(iOS签名这件事,有挺不简单的一整套安全体系,刚开始挺折腾的,你可以上网去搜索更多关于iOS签名的内部实现机制)

第三方SDK

Unity游戏开发,往往是多个渠道方同时发布的。比如说,我们的游戏在5个国家有语言版本,在5个国家有独立合作的发行商,对应着5个发行商SDK...

游戏开发时,发行商SDK接入是一件非常的麻烦吃力不讨好的事情,十分的折腾。所以这时候就有很多的“中介式SDK”的出现,比如我用过的有棱镜西瓜sdk,简单来说,就是只要接入一次SDK,剩下的无数其它SDK接入的问题,都可以交由它们进行自动处理,节省成本。

尽管如此,但是有时候,也避免不了,需要对Xcode工程的Objective-C代码进行修改或依赖库处理。

比方说,上一个游戏,就需要加一个Facebook分享的功能。这个功能,“中介SDK”并没有提供,那就只能自己对Xcode工程的部分Obj-C代码进行定制了。

我们知道,Unity编译iOS的本质,是生成一个Xcode工程。那就是说,每一次的Unity编译,都会生成一个Xcode工程。

同样就是说,你对一个Xcode工程进行部分代码定制后,再进行一次Unity编译,这些部分代码定制就会消失。

像前面所说,在Unity编译后,mod-pbxproj这些Xcode工程修改工具,就会出场,对Xcode工程进行自动化的匹配修改。但是一些第三方SDK的接入,可就不是修改依赖库那么简单了,它们经常需要对Objective-C语言的文件进行修改,添加一些Objective-C代码。

这时候我一般的做法是,使用Python脚本,进行代码的“搜索-替换”......

后记

其实在Unity 5新版中,对iOS依赖库的处理能在Unity编辑器进行,Unity引擎在iOS编译这方面其实还是一直有进步的。

之所以觉得Unity的iOS编译麻烦,可能是因为我自己比较强调自动构建的全自动化,我发现有不少的其他项目组,一般是打出Xcode工程后,安排人手进行一些手动的操作,比如插代码、处理依赖库、接入第三方SDK、导出IPA等,都是通过在mac系统里的鼠标人为操作实现的。

虽然我所在的项目实现了全自动产出IPA,但是经常有一些外部因素会影响到最终的IPA文件生成,比如说....iOS签名过期、系统版本更新、第三方SDK版本更新,都会影响到最终IPA的全自动产出。

这些外部因素影响到自动构建的特殊情况,有时确实无可奈何。要不就追加自动化的处理代码,要不就放弃这部分,进行人工操作呗。


鲜花

握手

雷人

路过

鸡蛋

最新评论

QQ|Archiver|手机版|小黑屋|www.cgacme.com ( 蜀ICP备18003526号 )

GMT+8, 2021-2-27 20:03 , Processed in 0.474821 second(s), 18 queries .

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

返回顶部