2018-03-12

新的一周来了，新的需求也赶上了日程，这周的主要是任务是给九霄发一版，因为之前1.3.0中给我们与九霄并没有进行一个良好的沟通，导致了双方的验证系统并不一致，导致最后要单独切出一个1.3.1的小版本为其服务。

今天修改了之前产品定下的需求，比如修改了shareView的文字，因为之前在截图时弹出的分享页面过于突兀并且文字提示非常不好，最终把“分享到钉钉”改为了“分享图片到钉钉”，且修复掉了上周自己瞎弄导致截图后都是出现了单一图片，导致这个问题的原因就出在，当初自己封装的PJTools中获取屏幕的方法被监听在了首页VC，而且也就只有首页VC设置了observer，这就导致了其实每次不管用户在哪个页面进行截图操作，实际上都会去调用首页VC的通知响应方法，然后这个方法中居然我又神奇的使用了错误的方法，这个方法的大致意思就是把当前的self.view转换成一个image，这样子错误的原因就出来了，每次截图都只能截图首页vc的view。😓

有多种解决办法，第一种，不要使用监听截屏的统一通知，而应该是使用监听用户在当前哪个VC下的进行截图办法，经调研，apple并没有提供这种神奇的做法。第二种，什么都不改，只不过应该把监听方法中的内容改为不是对当前VC，而是应该改为对当前“浮”在最上层的view进行视图保存，实际上通过window去做截图即可。第三种，每次用户截图完后，去相册去里取最新的一张照片po出来即可，但这种办法需要向用户索取相册权限，吃瓜群众很有可能就给你拒绝了。

我使用第二种方法，直接通过window去做drawViewHierarchyInRect比较省事，当然这也不是十全十美的方法，只是针对单一业务逻辑来说，这样的做法是可以的，这其中也有一些坑，因为和业务逻辑的耦合度较高，不便于讲解，给大家提供个思路，自己加油啦~

今天还做了件简单的事情，给通用浏览器加上了Progress展示，类似QQ、微信等的进度条。不管是给UIWebView还是WKWebView做Progress都比较方便，我们可以使用KVO的方式去监听的estimatedProgress的值变化，每次值发生变化时，都去更新Progress的进度即可，还有一些小细节比如必须要有请求的时候才进行Progress的显示，总不能本身是因为没有网的情况你还去做Progress的假加载，那这样就很没意思了。

晚饭过后还给北极星更新了一个版本，更新完了以后就GG了，产品把发版内容写错了，同时前同事却没有做升级通知，导致我之在做给北极星做升级提示的时候直接原封不动的把在滴滴数据中的代码copy了过来，我清晰的记得那天晚上我是在宿舍写的代码，估计也有可能是因为突然恍惚了一下导致了漏了个条件判断，同时也有可能是因为QA忘了测“立即升级”后的包是否能拿到，综上各种原因，导致了北极星上线后的GG。最终的解决办法，我挑了晚上11点左右的时间，去小助手上调换了升级模式，改为了“非强制升级”，这样就中了之前alertView下的button Tag，只要能够保证这次的包下载下来，以后不管是否为立即升级均可生效。不得不说，今天真是太惊现了，同时也给自己长了一个记性，做任何事情都不要想当然的认为这就是对的。

2018-03-13

今天九霄终于上线啦！从年前的需求拖到现在，上线了后真是大舒了一口气，这种前后端、两地联调的方式实在是太痛苦了，因为受限交流方式，两个团队一个在北京一个在杭州，并不能直接face to face，来来去去折腾了好久。而且最难受的是，上线之前居然又发现了九霄的一个问题，它跟我们不是一个权限系统，我们只能通过拼接URL的方式去带上ticket做有效验证，但是这个ticket在平常系统中的效果是，走一遍子系统验证，通过一个jumpto参数去做二次权限跳转，返回一个已经确定有权限的正确URL地址给webView做request即可，但是九霄不是这样的啊。😔。心累。完全不是一套东西，这就导致很有可能进九霄的时候，要再做一次登录，这真是非常尴尬的事情了。2333

不管怎么说，最终还是把九霄上了。上完了以后我又发现了一个问题，现在App的升级策略好像有很严重的问题！必须要把App从后台kill掉后再进来才能收到，而实际上正确的做法应该是每次从后台进入到前台时都要去判断一次是否有升级。思考了一下，干完了。。

2018-03-15

前天九霄上了，产品要配合做一波宣传，选择的做法是给发全员邮件通知和push消息，因为之前的push是另外以为实习生同学对接的，给我感觉吧，他总是给人一种疑问三不知的感觉，与他合作了小三个月的时间，他下周就要撤了，不知道为啥心里总有种解脱的感觉？？？我也不知道为啥他离开了我反而这么高兴，有可能是因为能够与更加优秀的同学一同共事吧，他嫌弃在这学不到什么东西，同时也想去更大的公司闯一闯，那我们就祝他好运吧！

因此，我开始捡起了他丢下的锅，重新过了一遍对接的友盟push，如果我没记错的话，这块的内容应该是在搬家之前就跟他说过了，那时应该是去年11月份吧，到现在也快三个月的工作日了呢，产品问了他如果要给某个固定用户发送push，是填手机号么？他回的牛头不对马嘴。

借此机会，我全部重新梳理了一遍有关pus的内容，对于push来说，我用做了这么个草稿示意图（不要嫌弃我字丑…）

这是一张相对比较抽象的图，其实重点就在用户设备的deviceToken，拿到这个deviceToken丢给APNS就能够让这个用户收到推送啦~而友盟则非常贴心的推出了一个“用户别名”的策略，允许我们对每一个用户设备做一个别名进行标识，以替代deviceToken这么难记而且没有规律的东西，总不能产品想对一个用户针对性推送，还去让产品背一串32位的deviceToken字符串吧，hhhhh。剩下的事情我们就按照友盟提供的文档去做就OK啦， 如果我们想要完成自己的推送服务，那就得再对接友盟提供的后端pushSDK了。

记录一个遗忘点：entitlements文件。entitlements其实是一个配置文件，对于一些要开启的app功能，需要使用entitlements文件来做配置。entitlements文件管三个东西：iCloud、push notification、App沙盒（ios下app沙盒是自动配置的，并不需要Entitlements，所以这里实际上是指mac下的app沙盒）

2018-03-16

今天周五了，我在疯狂的补文档，为了让后续接手的同学能够快速入门，不要再像我当初一样这么懵逼了，我的文档会写的非常非常仔细的，告诉大家每一步都有哪些坑，有哪些新功能做起来是比较有困难的，困难的点在哪里，同时也在此放一波招聘。

我所处的部门是滴滴的基础平台部-数据平台-数据系统组，如果大家对大数据方面有兴趣，同时也掌握了iOS/Android/web项目的流程，能够较好的处理一些棘手的bug，当然基本的思维逻辑和技术是肯定要有的啦如果大家有兴趣的话，可以联系我，一同愉快的来玩耍哟