DiDi（十二）

2018-03-06

今天的任务就一个，完成滴滴数据App的国际化！说到国际化，这是一个被炒烂了的实现，基本上大家都一样的做法，基本上没什么可说的，套路跟网上的一样。

不过，再次我想跟各位产品经理说一声，“能不能在产品开始之前就做好切实的需求分析！”，做完国际化眼睛都快瞎了，两个屏幕都不够看的，每个文件刷刷刷的过一遍，Xcode又没有AS那么智能，能够直接给你筛出所有中文。

如果有正在准备做App的大兄弟，一定千万记得要确定好这个产品是否支持多语言，要不然搞到最后RD会真的会提着刀子来找你的！过了好久，终于差不多替换完了，如果只是替换那就很简单了，但是语言切换完了以后，你需要去让相关页面进行字符串的刷新，刚开始我是不想用通知去做的，就去网上翻资料，发现真的是国内开发者脑洞打开，有给NSBundle做分类的，利用Runtime机制去做运行时替换；有对替换完了以后直接重新加载TabBar.rootViewController等等的做法，但是都没有一个合我心意，因为“太重了”，因为现在只是做各种生存周期还在的页面语言适配，还没到拉取后台数据的时候呢。

没办法，我最后选择了使用通知的方式给四大入口和挂载在相关入口上的组件发送语言切换通知的这种我觉得实在是太low的方式。在通知方法中，利用自己定义的PJLocationString(a)宏对各个控件进行重新赋值，到这也就结束了所有的静态页面国际化适配。

但是，实际上还有一个更加严重的问题，后台之前跟我们说，当切换完语言后，再重新修改各个API对应的语言参数重新请求一次数据，当时我内心就觉得不对劲，做完了静态页面的适配后才发现，真不应该这么做！之前在外包时做了一个家装类App，当时我是一脸懵逼的做完了，到现在自己设计、自己跟需求、自己负责实现了才发现当初后台把中英文数据一块返回才是最佳的。

从用户体验上来说，我只是换个语言你为什么要给我重新请求一次数据？而且位于四大入口上的数据本身都处于各大入口的主页面生命周期中的，只要你的App不退出、不杀死、不删除，这四大入口就一定会存在，数据源里的数据也就一定会存在，再加上动不动就跑用户流量，真的不怕被用户GG嘛？

2018-03-08

累。。。今天超累的。也有可能是因为昨晚有个ZZ舍友手机闹铃凌晨四点多响了四次！四次啊！本来昨晚就开了成员大会，心态亢奋了一天，好不容易睡着是个非常难得的事情，突然被他这么一闹，又折腾了好久才入睡。

到了公司后，发现了一个特别严重的问题，无缘无故需要了一个特殊的库OMGCrashResportSDK，这个库我们之前从未集成过，就昨天下午想给产品提测一版，在Jenkins上居然无法构建，被告知OMGCrashResportSDK这个库不支持bitcode选项构建？？？当时我整个人都不好了。

今天早上到了以后，立马在相关群里找到了Jenkins的负责人说了这个事情，不过一直没理我，抱着侥幸的心态，去了公司的iOS大群里@了基础服务号，没想到这个库还真的有负责的人！问了她，人家说只要是你集成了就会有，没集成就是没有。。。😓，我就说，这个产品之前完全没有集成过这个库，从来没有！没想到被甩锅让我去问Jenkins的负责人。。。

把这个消息告诉Jenkins的负责人后，接着完善我的国际化。上次做国际化漏了把tabBar也做了国际化，之前查了资料说是需要在切换完语言后，对整个App做一个更新，相当于是重新初始化一次，要不然数据刷不过去。

我就在想，想要重新初始化一次tabBar也不是不行，但是这么做的话那整个App的数据源就都得重新拉一次，那成本就上去了。本来我接手时再加上寒假一个多月没碰那位神奇的同事写的代码，各种地方乱串的网络请求搞得我心都累得不行了，再这么做是肯定不行的。

因此，我又想到了使用通知这个万花油！刚开始，我是对了每个NavigationController做了addObserve，但是crash在了“发送的通知并未找到对应的处理方法”这个问题上，因此也是不行的，我又想到了把各个NavigationController做成全局变量，延长它们的生命周期，很显然，这样的做法也是一样的不行。

最后，我选择了通过从tabBar中取NavigationController，然后对tabItemTitle做宏赋值，这么做最后是可行的。

解决完了这个大问题，就睡了一觉。睡觉的过程中隐约听到钉钉上有人在叫我，感觉现在自己是不是都精神衰弱了，一听到点犀利的声音就心跳加速，😓。看了消息后，Jenkins的负责人终于理我了，她也发现了OMGCrashResportSDK的问题，我跟她说，这个库我们从未用过，负责人告诉我，Jenkins不管你有没有用过这个库，它只管你代码写的有没有错，不管是不是对的！

emmm…想起来好像是这么一回事，感觉自己被踢了皮球，只能找回之前负责这块的工程师问了，人家确实是老司机，跟我分析了一下，有可能是因为这其中是有其它库依赖于这个库，但是这个库又不支持bitcode，才导致了这个问题。

这么一说，看了看Podfile.lock里的库依赖，发现！woc，好吧，第一个AfantySDK也就是所谓的小笑脸（就是滴滴出行主App里的那个小笑脸啦）第一个依赖的库就是它。。😓，然后拿着截图就去问了AfantySDK的负责人。。

经过几轮的反反复复，最终确定了原因。原来是虽然我们本地的Podfile文件中写明了AfantySDK的tag是0.6.11，但是pod updata后找到的确实0.5.8！刚好0.5.8是又是小笑脸国际化时出错的tag。所以必须要提回到0.6.11的tag中。

最大的问题又来了，这也是让我身心俱疲的地方，都把整个pod依赖都删了，重新执行pod相关命令重新做了项目依赖，居然再次执行pod update找到的还是0.5.8。整个人都不好了，开始怀疑是不是公司发的Mac环境没配好，开始各种怀疑。。。

折腾来折腾去，吃了晚饭再接着弄，到最后都快下班了，还是没弄好，就在刚才回到实验室的时候用了自己的电脑执行了一次pod update，woc！！！居然也是索引到了0.5.8的库！！！换了三台Mac都是一样的问题，这就说明了与我一点无关！

2018-03-09

咳咳。因为昨晚回到实验室用了自己的Mac尝试了重新拉库，发现版本不对劲后，刚好今天是周五，遇到了上线了空档期，就励志在今天之内一定要把这个问题给解决！

• 我再次把项目工程中对pod的依赖所有相关内容全都删除，新建Podfile文件，再次执行pod update后，再次发现好吧还是0.5.8。又遇到死角了，我开始把这个问题仔仔细细的描述了一遍，丢入公司的iOS讨论群中并且还给之前负责这个产品的工程师也吐了苦水，可是人家都转组了好几个月了根本记不住当初是怎么做的了。这个时候有个群里有个大佬回了我，“版本号没变化有可能是因为podspec里版本号没更新”，刚开始我以为他说的是自己本地项目中的podspec文件里的版本信息，如下所示，

  Pod::Spec.new do |s|
    s.name             = "DiDiData"
    s.version          = "0.1.0"
    ......

  仔仔细细看了好几遍，发现并没有关于AfantySDK的任何东西呀，于是就去私聊了这位大佬，经过几轮的询问才发现，是AfantySDK里的podspec文件version版本号没有更新，导致每次pod update时索引到的也都只是0.5.8版本，但是因为AfantySDK使用打tag的方式去执行迭代，实际每次update时都是索引到了最新版本，但是这种看不见到底是不是真下载了最新版本库的感觉不太好。

  当我把这个情况告知AfantySDK相关负责人后，人家跟我说现在的更新方式都不更新version了，都是走tag的更新，而且只要你的tag没填错就一定不会错的！弄得人家小姐姐都不好意思的说，“那我以后还是同步更新version吧”。。。我跟她说，0.5.8的AfantySDK一集成就被Swarm缺少多语言服务的断言中止了，是不是因为缺少对应的多语言服务的问题，人家说，“那这我就不知道了，我们只是调用了他们的接口，至于是不是你得去问Swarm的人”。。。当时我内心都快哭出来了。

  没办法，我只能又去问了Swarm的负责人，一直都没有得到回复。。。但是我也不能干等着，虽然并不能看懂Swarm和AfantySDK之间有什么神奇的py交易，但是干等着时间也一点点流失了。

  开始重新构建，看断言中止之后的栈调用信息，慢慢发现了规律，确实是少了SwarmMutiLanguageService，但是怎么给Swarm这个宿主添加新的服务呢？这个时候记起来好像Swarm的负责人之前有给我发过集成文档的图片！！！年后公司居然把所以的wiki资料做了分级，实习生已经没有权限去看这种内部工具的配置文档了，真的很苦逼。

  对照着还算完整的文档集成图片和之前工程师写好的服务接入代码，一点一点的居然把多语言服务写出来了，本以为构建成功能给自己一个意外的惊喜，但还是不幸的又中了断言，这回被告知缺少的不是多语言服务，居然一个之前已经没问题的服务SwarmToggleService（根本不知道用来干啥的服务）被告知缺少！！！吓得我又全部撤回了。

  出师不捷，午饭之后困意上来了，看了一眼给Swarm负责人发的消息还是“未读”状态。眯了一下眼后，心里憋得慌，毕竟事情没做完，又继续再次仔仔细细的研究了一下相关方法调用，这个时候，Swarm的负责人终于回了我，但是好像他没搞懂我的意思，问了我“所以你的问题是？”，😂。。。我又再次精简的把问题再次描述了一遍，来来去去沟通了几轮，最后他还是推荐我自己再把Swarm的相关代码过一遍，实在不行再去另外一个办公区找他帮我看看。。。他说到这，我又想起了当初leader带着我们两个iOS实习生去线下debug的情况。。

  最后在过一遍代码的时候，发现了一个非常尴尬的情况！我居然在给Swarm配置多语言服务时忘了在“service”和“name”之间加逗号！！！

  没想到最后是Xcode的锅！JSON格式不对Xcode也不告知，而且还不渲染JSON！真的，Xcode成功的拿下最烂IDE称号！！！

• 今天还做了App名称国际化的事情，实际上做法跟App内容国际化是一样的，都是需要起一个string file文件，不过对文件的名称有严格的要求，如果你做的是对App内容国际化，那就是需要把文件名称限定为Localizable.strings，如果你做的App名称国际化，那就得把文件名称限定为InfoPlist.strings即可。

总之啊，今天可算是把困扰了我将近一个星期的问题给解决了，也学会了Swarm的那一套流程，还是赶在上线前，不亏！