为了便于其他人员体验最新完成的功能,会不定时的把功能完备的安装包上传到Https目录下。在该目录,配置了这个安装包的ID、icon等信息。
为了产品运营的需要,在操作的过程中会走一些捷径:比如说把这个安装包在包装成另一个安装包,也就是所谓的马甲包。马甲包也有被下载的需求,为了图省事,马甲包也放在了同一目录下。在做这个偷懒的决定之前,隐约觉得会出问题,果不其然,问题确实出现了,刚碰到这个问题时觉得实在诡异,采用猜想--验证的方式探索之后,总算理出了一点头绪。
在下文中,正常的安装包称为A包,马甲包称为B包。
偷懒思路:先安装A包,A包能正常使用;在同一台机器上安装B包,A包和B包也能正常使用。
经过试验和探索,发现实际情况如下:
先安装A包,A包能正常使用;在同一机器上安装B包,B包能正常使用,A包icon不显示,A包打开使用一会儿后会优雅的闪退,crash日志指向NSUserNotificationCenter。把A包和B包卸载后,单个安装能正常显示和使用。
出现问题,我们首先是查看代码的问题,确认代码没有问题。猜想可能是配置的问题,确认之后也没有问题。后知后觉,问题出在偷懒的做法上。这种做法为什么会有问题?我们的猜想是和苹果的安装机制有关:
Https配置了A包的相关信息,B包的相关信息却没有配置。单独安装A包没有问题,单独安装B包也正常,先安装B包再安装A包也没有问题。先安装A包再安装B包会导致A包的icon和功能异常。
A包和配置信息匹配,单独安装A包时没有问题。
B包和配置信息不匹配,单独安装B包时也没有问题。
先安装B包再安装A包是,B包正常;再安装A包时,未检查到A包相同配置的APP,A包正常安装。
先安装A包,A包是正常的;在安装B包时,检测到A包和Https的配置匹配,先删除A包显示的icon,同时把UNUserNotificationCenter从指向A包转而指向B包。继续执行接下来的指令。发现B包和Https的配置信息不一致,此时以B包的配置信息为准继续安装,对A包的破坏也到此为止。最终得到的结果是B包正常,A包icon的显示和功能受损。若A包和B包的配置信息一致时,B包会把A包覆盖。
由此得出猜想:在同一个Https的目录下安装APP,先以Https的配置信息为主导。在一定节点后,以安装包的配置信息为主导。