台湾独立开发者分享：Unity iOS与 Android App上架实战心得

这份心得主要是用来分享，我和伙伴使用Unity开发、上架App至双平台的过程中，在程序与项目管理上遇到的特殊状况与解法。

至于基本的做法，就请交给Google与翻译机吧！

首先说明一下开发背景吧！

这个案子是由我＆美术朋友「赫佐艾卡」共同发起的，分工上就是程序由我负责、美术由他负责，剩下的杂事谁擅长就交给谁。

原本我们想得很乐观，预计花两个月左右将它完成并上架（当时规划的内容很简单，就只有「点数计算」而已）。

根据不成文的「两倍工时预估法则」──「一个案子所花的时间，通常是预估的两倍」。

我估计核心功能大约需要一个月完成，然后加上一倍的时间作为测试、除错、上架之用，合计也就是两个月。

但我错了，「两倍工时」指的应该是那些不在估计之内的「意外」，必须保留多一倍的时间来应付它们，否则只要发生意外就一定会延迟。

最后我们花了多久呢？六个月！

自我检讨时，从日志统计出来的工时大约如下：

• 核心功能开发（一个月）
• 追加功能开发（一个月）
• 多种插件的研究＆使用、双平台商店设定＆反复送审上架（合计一个月）
• UI优化（两个月）
• 宣传等诸多杂事（零散地吃掉时间，难以计算）

也就是说，核心功能是如期完成没错，而且因为撰写时就做好完整测试、不欠技术债，原本估的测试除错时间几乎没花到。

而大量的时间，居然是花在优化UI上！

我们每修改出一个版本后，就会请人试用看看，并且在一旁观察使用者的反应，不给予任何提示。

我们藉此找出了不少UI问题，例如使用者在某些地方会疑惑，不晓得接下来该如何操作、不易分辨能否点击的对象，以及字太小、按钮太小等问题。

每次改进完毕后，就会去找另一批新的使用者测试，确保能够得到全新的测试反应，如此不断改进，终于让新的使用者也能够顺利使用，而不需要刻意教学了。

这是我们早期的UI，与现在相比显得阳春许多，操作起来也很容易误触。

优化过后不仅变得漂亮许多，能点击的物件也都更加凸显了。（感谢朋友「圣净之风」、「陈淯翔」、「TK」、「Zehe」提供的宝贵意见）

关于UI、UX的知识实在太多，这边先推荐一个网站，有兴趣的人可以自行上网找更多数据学习：Google Material Design

而关于我们在设计UI时，几个经朋友建议改善的点在于：

• 「凡是能操作的对象，尽量加上立体感（或阴影），形状也特别点，反之则平面化」；
• 「按钮之下的背景最好单纯点，以免太花而看不清按钮」；
• 「相同类型的对象，其风格、颜色和形状尽量统一」（这点我们其实做得还不够完美）；
• 「当用户可能疑惑，不知道下一步该点哪时，就应该要强调显示该按键（例如将「开始计算」和「返回」按键改为会闪烁」）

※太多闪烁对象的话会影响效能，因此用在刀口上就好。

而另一个吃掉大量时间的怪兽，就是求好心切（贪心不足），添加了许多不在当初「两个月」估计中的功能──让用户在计算点数时采用自定义规则，并且可以储存多组设定，快速切换。

例如是否允许食断、复合役满，还能够判断许多知名的地方役，如大车轮、八连庄、大七星等等。

因为每个玩家想采用的麻雀规则都可能不同，如天凤、雀龙门、麻雀格斗俱乐部……各有自己的一套规则，据我所见，目前市面上的所有麻雀计点App，都只采用自己一套写死的规则，所以我们相信这项功能，必定能为用户带来很大的方便。

除了「胡牌点数」之外，还能计算「所有听牌的种类与点数」。这也是比较少见的功能，可以帮助用户找出没发现的听牌，以及快速判断哪种听牌得点较高、是否足以逆转。

收集美少女图鉴功能（对，最初这款App是没有美少女的）。我们想让App也陪着用户一起成长，而不仅仅是用过就丢的计算器。而且用户只要看看影片就能取得金币，可以完全免费地计算点数、收集麻雀乙女。

四国语言切换，因为没有经费将翻译外包，故80%以上都是我自己查字典翻译的，后来两位赫佐艾卡的朋友（赛巴、真诚）也协助了一部分，感谢他们。

建立FB粉丝页代替官网，定期发文与粉丝互动。却碰到好几个变态外国人骚扰…

存盘格式的设计与加密，防外挂修改内存，程序代码混淆。

由于是单机版App，逻辑几乎都写在客户端了，所以不太可能完全防止破解，只是为了增加破解者的麻烦，延长版本寿命而已。

研究了八门、烧饼这种任何用户都能简单运用的内存修改工具之后，针对它做出了基本的内存修改防范（重要参数都不保存在内存里，每次都重新宣告）；也确认过我们的App被反组译后的结果，并将程序代码做过混淆，但遗憾的是，免费试用的混淆软件最后仍无法顺利运作就是了。

延伸阅读：

从开发者的角度谈游戏防弊（上）

从开发者的角度谈游戏防弊（下）

显示Android状态栏。

什么是状态栏呢？就是最上方的网络、电量、时间显示那一列了，我相信这对许多使用者来说是很在意的事。

iOS要办到很简单：

Player Settings>iOS Resolution>Status Bar Hidden取消勾选

Android在5.3版之后，此选项已被移除，必须用别的方法。

从网络上找到，我目前采用的做法

↓这边就是状态栏了↓

使用时需注意，别把↑NavigationBar（导航列）↑也开启了，否则在hTC等部分手机可能会发生如上问题，虚拟按键常驻而挡到了UI。（感谢阿智学长、我爸和五伯父特别告知此问题）

Android独有的「Escape」键，防连点Escape就是返回键，也就是上图左下方那个白色返回箭头。

我记得在Android的规范当中，有要求App的Escape键必须要有功能才行，但既然要做我就想做到好，所以先将所有UI之间的关联性列清楚，再设计成让用户每单击返回键，就会回到上一层的界面。

再来就是当画面中正在播放动画时，要禁止任何操作，包括点击返回键；

也要防止快速连点返回键或任何按钮（举例来说，像是快速连点了5次购物，应该只视为1次）。

使用了许多初次接触的插件（但真的很实用！）

Unity Analytics-资料分析后台

非常重要！若没有它的话，单机App对于用户在手机上的任何行为，几乎可以说是一无所知。

有了它，即使是完全不自架Server的单机App，也能够记录各种事件，作为未来的改良参考。

收集到的事件大约4~5小时后会回传到Unity的后台显示，例如DAU（每日活跃用户）、MAU（每月活跃用户）、新增用户数、留存率等等；还可以自定义事件，将自定义的内容也回传到后台。

当没有网络的时候发生事件，也会先暂存起来，等网络连上时再自动发送。

※据官方文件所述，自定义事件上限500个字符，并且最多包含十个参数，但官方未提及的是，每个参数也有上限100字（不论中英都只算1个字）。

我将自定义事件的参数名称取成日期+版号+平台（至少可容纳100字），这样一来就能自动将每天的Log，依平台及版本分类，而不是像预设的格式那样全部杂成一团。

就像这样，事件中包含超过100字的参数是无法传送的，仅仅剩下像是”Test110″这样的事件名称。

如果事件内包含字数超过500，则连事件本身都无法收到。

而100字当中，即使全是日文也没有问题，不会因为全角字就占两倍字数。

Unity Ads-影片广告插件

顾名思义，就是能在App中提供影片式广告，需注意仅限于iOS及Android平台中使用，于其他平台会Error。

分为两种类型：

1.奖励式广告（不可手动跳过，看完后可给予用户奖励）

2.可跳过广告（用户5秒后可手动跳过，不会触发奖励事件）

可以在Unity Ads的Dashboard动态改变设定，决定在播影片时是否静音，而不需要更新App。

iOS和Android平台分开设置。

我本身也很讨厌那种强制跳出的恼人广告，因此《麻雀点数计算乙女》是完全不采用这种的，只有在用户确定想看广告（看完可取得金币奖励）时才会播放。

在Unity Editor上观看测试广告时，点击操作画面会穿透点到底下的UI，要小心。

实机上没发生这种问题，但为了安全起见，还是加一块全屏幕半透明挡板（类似Loading效果），同时也可以让玩家在等待广告播放前，明确地感觉到有点击成功。

※似乎没有防止连点，所以要自己加上防连点判断。

技术上的提醒：

虽然预设Unity Ads会自动在Awake()加载游戏编号，但偶尔会发生没加载的情形，所以还是在Awake()帮它加载一次较好。

像这样：

广告Server会自动判断，每用户每24小时最多观看25次广告，如果想让用户看更多的话，只能再串接其他广告插件了。

至于广告能获得多少收入呢？这因国家而异。

不过用户看广告所获得的金币价值，通常是远大于我们实际得到的广告收益的，这么做还是为了让用户能够完全免费使用，而经济上有余裕的用户，也可以直接购买金币，而不需要看广告。

例如中国明明观看了最多次影片，结果一毛收入也没有；

反观欧美、日本的千次观看收益高上这么多。

虽然知道这点，但我们对海外的宣传真是十分不擅长，也不好意思去2ch之类聊天的地方打商业广告，顺其自然的结果就是这样Orz

明明是市面上最好的产品啊……

Unity IAP-应用内付费，验证付费是否造假

先填写iOS负责人、税务与银行帐户资料https://blog.mowd.tw/p/793、http://coderanch.net/138

然后建立iOS App设定售价与IAP项目

（建议透过Application Loader建立，接口更加人性化，亦可从文件批次上传）

http://www.jianshu.com/p/033086546126

串接方式请参照Unity官方教学，

https://unity3d.com/learn/tutorials/topics/ads-analytics/integrating-unity-iap-your-game

而当中的Purchaser.cs

要初始化某项IAP商品时，使用的是「产品ID」而非「Apple ID」。

builder.AddProduct(“产品ID”,ProductType.Consumable,new IDs

这其实不太会弄错，但是当功能一直试不过的时候，一个焦虑的工程师会开始测试修改所有能改的地方…

另外，由于Google Play的产品ID有特别规范，需由小写英文字母(a-z)、数字(0-9)、底线(_)和点号(.)组成，且开头必须是小写英文字母或数字，所以若想在两个平台使用相同产品ID，则必须遵守此规范。

※需注意，Google Play的产品ID一旦建立，即使删除也无法再次使用同样ID！

IAP验证

UnityIAP验证官方说明：Unity>Window>Unity IAP>Receipt Validation Obfuscator

将Google Play的授权密钥贴进去，按Obfuscate secrets，就会在项目中产生GooglePlayTangle与AppleTangle两个混淆过的档案。（不要去改它）

画面中涂黑处就是Google Play的授权密钥

同时也必须将密钥贴到Analytics的Dashboard，才能进行验证。

之后再按照Unity IAP官网的说明，将验证用的程序代码加入Purchaser.cs，即可在客户端付费时验证收据，避免用户在收据上造假。

※官网说明得不够清楚，要记得在Purchaser.cs最顶端加上这行，引用该函式库。

using UnityEngine.Purchasing.Security;

IAP商品上架

在Unity Editor测试购买IAP时，若设定一切正确，就会直接通过；但要在iOS和Android实机上测试购买时，还需要做下列准备。

【iOS】

必须先等App初次送审通过，否则在iTunes Connect会是「遗失元数据」的状态，在实机上购物会显示「验证失败」。

App送审通过之后，还必须将App内购买项目也送出审核（勾选要送审的项目后，网页右上角会有按钮亮起），下图是送审中的样子，要等它们通过才能进行测试购买，否则只会因为找不到商品而自动取消购买。

送审时，每个平台需提供屏幕快照，并且要足够说明App内容才行（我曾经因为只提供一张而被打回票）。只需要提供最大尺寸的版本快照，就可自动适用于其他较小的装置，也就是只需提供iPhone 6、以及iPad2大小的快照即可。

屏幕快照必须是JPG或PNG格式，且必须采用RGB色彩空间，72 DPI。

iPhone最大5.5吋＝纵向1242px*2208px或横向2208px*1242px

iPad最大12.9吋＝纵向2048px*2732px或横向2732px*2048px

iOS的App预览（也就是介绍影片，必须放在屏幕快照之前）：

格式：M4V、MP4或MOV

容量：不超过500 MB

长度：15~30秒

FPS：30以内

分辨率：

iPhone最大5.5吋＝纵向1080*1920或横向1920*1080

iPad最大12.9吋＝纵向1200*1600或横向1600*1200

编码：256kbps AAC

采样速率：44.1kHz或48kHz

必须为立体声，启用所有音轨

参考数据：

Apple App Store App预览影片准则翻译

测试装置列表

将测试装置的UDID加入开发人员装置列表中，装置的UDID可透过Xcode取得。

（Xcode>Windows>Divices>选择连接上的装置>Identifier）

但我从App Store直接更新Xcode时一直失败，最后是去下载打包好的版本，并且在解压缩时，还必须将MacOS更新才行。

注：经实测iPhone 4不能更新至iOS 8，而新版Xcode要求App最低只能支持到iOS 8，即使在Unity中设定支持到iOS 7也会被强制改高的，因此新的App都必须放弃支持iPhone 4了。

接着必须将测试人员加入名单中，

开发者账户本身也可以作为测试人员。

然后测试人员的信箱会收到一封信，要求去App Store下载TestFlight，

用它所下载安装的App来测试（记得使用测试人员账号登入App Store），

才能够在沙盒环境下测试付费。

※若是使用Xcode直接将App安装在手机上的话，

使用IAP购物会失败。当初在这边卡好久…

Unity现在有提供方法，不必购买iOS开发者帐户即可先在装置上测试App，这样会比较省钱，因为iOS开发者账户是在付费通过后就立刻开始计时，一年到期，等到要送审前一周再申请付费就好了。

完成付款步骤之后，再过几天就会开始计时了，

并非如网络上某篇文章所说，还要按一个按钮才开始计时。

iOS送审

这就是Archive后的画面，Validate和Export都在右上方

每次要更新版本时，Xcode>roduct>Archive，成功之后Validate让它先检查一遍，最后Export就可以输出成.ipa檔，然后强烈建议使用Application Loader上传！上传后大约需要等10分钟，就能在iTunes Connect中看到。

跨越了无数障碍，终于让这个建置版本的「+」号出现，

真是令人感慨哪。

使用Xcode提交很容易出问题，甚至还曾经卡住了数小时，原来是因为它的UI出问题，明明已经上传完成却不会刷新画面。其实上传只需要15分钟左右，之后再将Xcode窗口缩到最小再打开，就会刷新了。

什么鸟问题…多亏网络上这位仁兄分享，才得以解决这莫名其妙的Bug。

就是这画面让我等了数个小时！

但即使Xcode显示Upload Successful，等了数小时也仍然无法在iTunes Connect上找到刚上传的App。

最后改用Xcode>Open Developer Tool>Application Loader并且将IAP的叙述、审查信息的屏幕快照也都补上（这比在网页上输入IAP信息更加方便许多，推荐），否则在iTunes Connect的状态仍会显示为「遗失元数据」而非「准备提交」。

可是当递送数据时，等了足足10分钟才回传告诉我「商品叙述至少要10 bytes以上喔」

您下次可以早点讲吗大哥！！◢▆▅▄▃崩╰(〒皿〒)╯溃▃▄▅▇◣

iOS审核效率

我送审过多个版本，每次平均大约1~2天就审完（假日也照审不误），比起几年前动辄审上一周，苹果的动作真是迅速了非常多。※据我观察，他们常在台湾时间半夜2点左右开始审查。

若正在审查中，会显示在App状态上

建议先做好一个包含基本功能的版本就送审，及早发现问题及早修正，才不会临到要上架时却被连续打回票。

反正审过之后可以选择不要开放给用户下载，有什么次要功能，都可以等初版审过之后再追加。

iOS对上架的App有一套规范，开发前可以去查一下，就不太会触犯到他们的禁忌而被打回票，例如在App中提到竞争对手（例如Google）的名字等等。

我只被打回票过一两次，原因是Apple需要了解，IAP购买的金币在《麻雀点数计算乙女》中如何使用，我回复解释完，他们就继续审核了（不需要重新提交档案）。

另外还遇到几个Unity汇出到Xcode之后，需手动修正的设定：

即使在Unity设定过也没有用，

还是必须手动再设定一次，将此处改为None，

否则在部分手机上可能会安装失败。

这边则是Apple故意的，一定要手动重新设定权限，

才能使用相关功能。

【Google Play】

在此将App上架与设定：Google Play Console（开发者管理网址）

也必须先「审核」及「发布」APK（Alpha或Beta测试版皆可），否则会显示如下错误。

并且发布到Google Play的APK、与安装在测试机上的APK，两者的Version和Bundle Version Code必须相同，这点iOS应该也是一样。（未测试）（在File>Build Settings>layer Settings设定）

PlayerSettings设定

Product Name就是安装后显示在App Icon下的名称，iOS最多显示六个中文字、或12个英数+1个半角空格，超过的部分将会被以「…」的方式省略显示。

Android能显示的字数较长（依机型不同也有差异），故此处建议以iOS的六个字为准。

iOS会自动将Icon边缘裁成圆角，所以我们做了两种不同的Icon分别给不同平台使用。

Android的Icon支持透明色，但iOS不支持（会被周围像素自动延伸填满，甚至不允许使用），所以我们就把iOS会裁掉的部分用黑色填满。

Version最多三个数字，例如1.0.0，超过将不会被iOS所接受。

Target minimum iOS Version至少要设为8.0，否则也会被Xcode强制改高。

※只要上架审核通过了，下次上传的新版本，

Version、

Build(iOS)、

Bundle Vertion Code(Android)都必须比前一版大。

Android使用测试装置测试IAP购物须注意：

1)测试用的账号，不可与上架用的开发者账号相同。

2)测试用的装置，Google建议先「还原至原厂设定」，

然后要先以测试用的账号登入，才会让测试账号被设定为主账号。

「欲练神功，必先自宫」，

若不自宫，就不保证会成功啦，请自行尝试了。

3)将测试人员加入测试名单（仅限使用gmail账户），

让测试人员透过「选择接受网址」下载apk，再收验证信同意加入测试才行。

版本管理>应用程序版本>管理Beta版（或Alpha版亦可）>管理测试人员

4)在Google Play的App内测试购物是真的会付款，之后可以在「订单管理」退款

记得测试购物之后，一定要马上去退款！

像我有一次刷了一笔3000元，隔了半天才想起来，结果…

…就晚了半天才退款成功，吓自己一跳。

建议大家不要学我，如果等到信用卡账单都结算了才想退，搞不好就没办法了。

顺道一提，由于双平台都会抽取30%的费用，还要再扣除各国不同的税率，实际能从IAP得到的收入大约只有用户付出的一半金额甚至更少。

IDFA（广告ID）

以前要辨识不同用户时，通常会去取得装置的唯一编号，但后来iOS和Android政策都倾向保护用户个资，所以双平台最好一律改采用IDFA（广告ID）。

它跟用户装置的唯一编号差别在于，此广告ID是无法永久对应装置及用户身份的，仅用于此单一App，而且一旦移除App重新安装的话，又会改为新的广告ID（更新则不会变）。

而这项功能在每次iOS App送审时，都会被询问是否有使用，有使用的话才会开启此功能，当送审通过之后便能够产生用户的广告ID。

仅限在iOS平台取得广告ID：

UnityEngine.iOS.Device.advertisingIdentifier

iOS和Android平台取得广告ID（Windows不可）：

Application.RequestAdvertisingIdentifierAsync(

(string advertisingId,bool trackingEnabled,string error)=>

);

正式上架发布

Google Play会立即出现在商店上，iOS则大约会晚个半小时～一小时。

如果要做宣传的话，建议等确认出现在iOS商店上再做。

由于中国的网络长城，不翻墙的话只能连接iOS App Store，无法直接访问Google Play和Youtube，因此最好另外寻找中国用户可访问的空间。

影片我试了许多空间，有的甚至才刚上传，

就被系统以莫须有的罪名自动屏蔽了。

最后是找到bilibili可以成功上传，不过在这之前还需要回答一大堆问题就是了。

而存放apk，供中国用户自行下载安装的空间就难找了，现在因为实名制的关系，几乎全都要绑定中国手机、或者付费，只有腾讯微云免费又不绑手机，提供10G的免费空间，但连结只能维持一周。

所以最后我们也放弃了，如果有人知道在中国可用的免费空间的话，可以留言告诉我，我会再补充进文章里的，感谢您。

最后还有一些开发项目的心得，也顺便跟大家分享──

版本控管

很重要，很重要，很重要，所以要说三次。

在本项目中，Unity几乎只有我在使用，因此我跟伙伴之间没有同步项目的需求，版本管理起来算是很轻松。

但即使如此，将项目区分版本备份至云端依然非常重要，在开发期间内至少发生过四次，我把项目改坏了而非得还原不可的情形，幸好有做备份，只要几分钟就能救回来了，不然可是欲哭无泪。

先确认「最困难、最核心」的部分做得出来，并且要先做

例如我们做的这款App，目标是以「广告＋IAP（App内付费）」收费，提供「日本麻雀点数计算」和「抽签收集美少女图鉴」的单机服务，都是先确认过做得出来，项目才正式开跑的。

否则若等进行到一半才发现无法克服的瓶颈，会让项目承受毁灭性的打击。

再来就是从这些最核心、最难做的项目先开始进行，不仅是为了保险，更是因为成员的动力在一开始最强，若到了结尾的时候才来面对最困难的项目，会更容易产生逃避、草草了事的心态。

分工与奖惩要明确

三个和尚没水喝的道理大家都听过，多人合作时很忌讳权责不清、奖惩不明的问题，一件事「没人做」「出问题无人可追究负责」「做得好不知该归功奖励谁」都不是好事。

所以我们一开始就讲好职责及利润分配，确实遵守。并且一开始就在App中建立开发人员名单，根据实际工作内容更新，如此能够更直接地激发荣誉心、责任心。

※虽然职责区分明确，但我们做出重要决定时都还是会互相确认想法，常常因此将点子优化得更好，若犹豫不决时再由负责人做最后决定。

公布开发人员名单的做法，即便会让好的人才更容易被其他团队看上挖走，我也觉得这是每个人努力所应得的名声（反过来说，做不好的话也能从名单上找到是谁负责的）。

不过因为我们的案子并非上下雇佣关系，而是朋友间的合伙关系，所以就不采用奖惩的形式，而是各自承诺每项工作的完成期限。

定期了解彼此的成果，对双方都有激励作用；而若有成员的进度迟缓下来，也能够及早注意到，给予关心和协助；逾期的人也会自发地请个饮料什么的。

多亏彼此的这种「加分式」合作，才让这个案子持续六个月以来，即便已经远远超出当初预期的两个月，两人都还是不松懈地努力到正式上架的一刻。

博客地址：http://yawling.blogspot.com/2017/08/app.html