2018-04-02

今天又中度污染,不过是可以穿短袖的一天,非常的舒服。

到了工位后又接着继续解决上周遗留下来的对接哈勃问题,不过周末这两天哈勃的RD写了个demo,去掉了用不到的依赖库。打开一看,嗯,确实是少了非常多,比起上周的一百多个现在只有不到三十个了。emmmm。😓。进入目录后直接pod install,等了一会还是上周的问题,如下所示:

第一张图片的问题出现是因为使用了滴滴的内部pod工具OneTool导致的,问了之前的RD,他说OneTool很麻烦的。😂。。他之前也只是用过一些,现在也不用了,所以并不能解决问题。第二张图片之前从未出现过,估计是因为podfile中指定的source太多,刚好这些source中都有对应的pod版本,就导致出现了多个版本库的警告。

刚开始特别懵逼,真的是搜遍了全网,SO、google、CSDN等国内外众多站点,大家遇到的问题跟我还不太相似,有极个别很类似的分析了一下也不太对,真的是第一次遇到了根本搜不到原因的问题。问了哈勃的RD,他说可以先不管,直接pod install能把依赖库down下来,build没问题就行,警告啥的不用管。😓。

执行了命令后,居然发现给的demo居然能够成功把依赖全都down下来,这也太奇怪了(那自己之前到底在琢磨啥子。。)玩了玩demo,感觉这次接的入口等级权限还挺高,居然能够调度全国的代驾司机,虽然有权限控制,但还是感觉非常的有意思,第一次这么近距离的感受到了实时调度平台系统,而且以后说不定还会有更多的数据平台甚至跟哈勃同等级或者更高的调度系统接入呢,想起来真的是太棒了。虽然搞来搞去还是写的业务代码和业务逻辑。但是这其中可以接触到大量的优秀内部工具和库,以后尽量一个星期剖析一个库吧,上次讲的ONEProgressHUD也不够好。

跑通了demo后,开始按照demo的格式把哈勃集成到主工程中,好了,苦逼的事情就这么开始了。细节就不展开了,因为真的太苦逼了,整个人差点又崩溃了。这种解决各种依赖问题和编译链接问题实在是太难受,就说几个值得注意的地方吧,

  1. Podfile文件格式一定要严格按照官方格式去写,我之所以现在这么苦逼,有一半是托之前写的Podfile格式不对,一个空格的原因导致整个依赖库down不下来,Podfile.lock文件都创建失败,差点以为是没给Xcode做好设置,改来改去发现都没问题,最后仔仔细细对照了给的demo格式,才发现是因为一个空格的原因。
  2. 开始着手写整个工程,或者对现有整个项目做重构之前,一定要对依赖的各个库做好严格的版本限制,就因为OneTool的整个链的依赖库是基于AF 2.x的,而升级小助手又是基于AF 3.x的,改来改去,协调来协调去,最终顾大局而舍弃小家,把升级小助手用源码的方式进行了集成,然后又把小助手中用到AF 3.x的地方手动改为AF 2.x。我是搞不懂为啥都是内部库怎么就没有创建一个内部库时的前置要求,比如统一要求好各个内部库基于的依赖库版本等。以源码方式集成时,以拖拽方式给Xcode添加文件引用时,千万记得一定要拖完整了,就算是command + A全选目录下文件拖拽进Xcode工程中,也千万要记得对比一下两者之间是不是真的全都拖进去了。要不然会有一定概率跟我一样居然只拖进了.h没拖进.m,真是迷。。。

2018-04-03

今天主要解决两个问题,哈勃因为在block中return出了UIViewController,然后需要在主工程中push进它,但问题就出在这个UIViewController上,之前自定义了NavigationBar,这就导致了UIViewController都需要手动的去加上,哈勃的第一个选择页面较为完整的解决了这个问题,但是确实没法统一到哈勃下的接着push进来的其它页面,除非让哈勃的RD引用我们这个VC拓展,很明显这是不可能的,因为哈勃还用在主App中呢,因此走入了第二步非常痛苦的重构之路。

怎么个重构法呢,梳理了一下。因为在哈勃的init方法中的success block丢出了一个UIViewController,哈勃的RD告诉我直接拿Navigation push进去就行。但是问题就出在了NavigationController这儿,之前直接hidden掉了,直接自定义NavigationView,上午想的还是对哈勃做的改造,但是后续仔细一想,woc,这样不行啊,如果单单针对哈勃做了改造,那以后再对接其它数据平台咋办,那还不得累死,因此,NavigationBar一定不能隐藏,而且还要copy成原来的样子。

其实我没搞懂为啥之前的RD会冒出自定义NavigationBar的思想,如果说是因为首页的异性headerView导致的,那完全可以针对首页把NavigationBar给hidden掉哇,搞得现在重构的话要做的事情比较啰嗦,之前我还以为最省事的办法就是直接hidden掉原生的NavigationBar,然后自己造,自从经历过iPhone X的适配后,就再也不这么想了。也算是在此给大家提个醒吧,如果能够原生控件解决的事情,就一定不要自造,因为你无法保证后续会出现什么操蛋的事情,刚来的时候我也觉得以后不会接入这么多其它数据平台,但是现在慢慢发现,自己真的是太天真了,现在开始慢慢的对整个项目架构有了比较严格的要求,一看到之前写横竖屏做了那么多的if-else简直想吐,这两天在好好整整NavigationBar的事情,退回原生,估计又能删掉一堆适配iPhone X的if-else了。

还有一大部分时间是在做HUD的替换,慢慢的发现的其它数据平台的产品都在直接使用ONEUIKit里的组件,比如HUD、Alert等等,如果我们主工程不用,那就很突兀,主工程一套UI设计,其它子系统又一套UI设计,所以我背着产品自己做了决定,实在是看不下去放着统一的UI设计不用,自己造。

2018-04-04

按照昨天的逻辑,今天要完成navigationController的定义,也就是走回原生,之前是给UIViewController写了个分类,我们无法保证其他类是否也能够保证使用这个拓展,最后想到了用RuntimeUIViewController做运行时替换,又想了一下Runtime是可以做运行时替换给系统类添加属性,但使用Runtime前提得是引入了这个分类啊!现在也只能做到是哈勃的首页VC做了运行时替换,但是除了其它VC并不没有引入这个分类啊。。。

纠结了几分钟,遂同样也抛弃了这种做法,又纠结了几分钟,最终决定!还是着手改造现有的VC吧,不用之前隐藏了navigationBar然后自定义的做法了,统统改回系统样式。“啪啪啪”的差不多十几分钟过去了,稍微封装了一下,写出了基类PJBaseViewController,想要改回系统样式的navigationBar,只需要继承自它即可,而且也都暴露出了对应的navigationItem、navigationBar属性,可以给后续提供更多的自定义,而且又防止后续PM有其它神奇的需求,比如点击固定的一个title为比如“AABB”的webView的back按钮,pop到某个VC上(真的是奇葩炸了,如果我是用户我一定会非常好奇为啥我从北京进的门,出门就是上海了),所以同样的也把left || rightBarButtonItem的点击action通通都暴露出来了。虽然有可能每次都写统一的leftBarButtonItem方法,但是这至少保证了可定制性。🙂

balabala又做了好久,中途因为更换了做法,导致横竖屏也出了问题,只能又继续苦逼的重构横竖屏部分代码,不得不说重构真的是一件非常的值得花心思的事情,花了大量的心思,花了又花。

弄中午的时候,woc,四月的北京居然下雪了,其它地方不下雪的时候,北京下了,其它地方下雪的时候,北京可以穿短袖,城市套路深。。。吧嗒吧嗒的又接着调啊调,横竖屏换了个场景居然要考虑的事情还挺多,因为很多监听通知的代码都可以移除掉了(因为用了原生控件),但是却又导致之前的联动性变得比较拘谨,写了一些不可言语的code,如果有幸被哪位学弟接手了我的代码,嘿嘿嘿,你一定会觉得非常的有意思🙂。

吃晚饭后本以为可以休息会儿,跑了iPhone X的模拟器后,整个人又不好了。如下,

cccccccccccc….万只草泥马飞过,这明明就是一张图片啊,而且就iPhone X出幺蛾子!还特么能整出这么神奇的分层效果,刚开始还以为是之前的navigationBar背景颜色忘了删,但是翻来覆去看了好几次,并没有啊!而且这还是完美的orange。🙄

以为是iPhone X的适配问题,一番搜索下来也还是找到思路,换了好几波关键词还是无果,关键词换着换着就想到了这么个事情,会不会是因为iPhone X的navigationBar太高了,超出了原始图片的高度,所以会不会是只展示了原始图片的高度,超过了就不展示了,但是也没法说明多出来的orange是为啥。重点是第一次遇到这种问题,不太会描述关键词😂。

搜了好几次,都不满意,始终都围绕着iPhone X展开,网上说的都是啥tableView啊等等这些的基本适配问题,差点都快放弃想直接用backgroundColor去做了,最后这么搜了一下“UIImage拉伸适配”,woc,中奖了。。做法还真的就是给把图片给拉伸展开,设置它的边距为0,尺寸模型为延伸,仔细一想,这好像就是当初做的聊天界面的气泡设置方法,😂。(之前学的全忘了。。emmm

1
[[UIImage imageNamed:@"nav_bg"] resizableImageWithCapInsets:UIEdgeInsetsZero resizingMode:UIImageResizingModeStretch]