【新智元导读】 正式官宣！美团收购光年之外全部权益，斥资20.65亿。****

官宣了！美团以20.65亿人民币收购光年之外。

就在刚刚，美团在港交所公告，已订立交易协议收购光年之外的全部权益。

总代价包括现金233,673,600美元；债务承担人民币366,924,000元；现金人民币1.00元。

于公告日期，光年之外的净现金总额约为285,035,563美元。转让协议交割完成后，美团将持有光年之外100%权益。

前几天，光年之外联合创始人王慧文因健康问题暂时离岗引发许多人的关注。

甚至，外界关心诸多的是他的停职对公司造成哪些影响。

美团在公告中对于并购的解释是，通过收购事项获得领先的AGI技术及人才，有机会加强其于快速增长的人工智能行业中的竞争力。

这次，美团出手，意味着光年之外在后续运营有了足够资金支持。

同时，对美团来说，大模型能对未来业务转型也将产生有利帮助。

美团拿下光年之外

其实，在外界看来，美团收购光年之外，就像是板凳钉钉的事。

从感性层面讲，王兴与王慧文是清华的室友，在创业路上并肩作战。王慧文入局大模型后，王兴紧接着应声跟进。

在大模型爆火后，美团CEO王兴也对此表示极大的关注，甚至，在3月份还投资光年之外。

当时，王兴表示「AI大模型让我既兴奋于即将创造出来的巨大生产力，又忧虑它未来对整个世界的冲击。老王和在创业路上同行近二十年，既然他决心拥抱这次大浪潮，那我必须支持。」

从理性层面讲，自2019年美团将战略升级为「零售+科技」后，不论是王兴本人，还是公司来讲，对AI也投入非常大的兴趣。

当前，大模型已经成为兵家必争之地，国内许多头部科技纷纷入局。

据「豹变」独家报道，美团做大模型，已经有2个多月，几乎是与王兴投资光年之外同步进行的。

据称，算法团队正积极扩招，甚至还在筹划成立单独的「平台部门」，帮助美团大模型通过具体的商业化形式落地。

对美团来讲，智能配送系统、外卖无人车等场景，都需要AI驱动。

收购光年之外后，美团能够将大模型的能力，与自家核心业务相结合，比如外卖、本地生活服务等等。

此外，还能够在客服、物流、产品体验等各种场景中实现应用，将大模型能力与场景深度融合。

美团方面表示，并购完成后，将支持光年团队继续在大模型领域进行探索和研究。

所以说，美团的未来还是值得期待的。

而前几日，王慧文病倒的消息，让外界猜测纷纷，比如融资不顺利，或团队组建困难。

有国内媒体澄清道，光年之外A轮融资已经完成一个月，融资到账实际金额远高于外部报道的2.3亿美元，网传的“融资不顺利”消息，属于谣言。

此次美团在港交所的公告，也证实了这一点。

而在人才组队上，光年之外也进展顺利。

在成立后不久，光年之外就以换股形式收购了一流科技，原核心技术团队被保留。

而在两个月内，光年之外的研发团队规模就已经在70人左右，团队在算法等领域，研发经验丰富。

这样一支已经组建成熟的团队，在当下的大模型之战中，无疑属于稀缺资源。

美团选择收购光年之外，显然也是经过深思熟虑。

VC平稳退出

光年之外在6月初刚刚完成了的这笔2.3亿美元的融资，由源码资本领投。

腾讯、五源资本和快手创始人宿华也参与了这次融资。

从港交所披露的信息来看，除了6月初的这轮融资，红杉中国也在前期对光年之外进行了投资。

当王慧文因病离开光年之外的领导岗位之后，这些前期投资的VC都因为这突发的黑天鹅事件，可能面临着投资打水漂的风险。

但是随着美团的出手收购，这些参与光年之外的投资至少能在一定程度上落袋为安。

不用再担心因为被投公司核心创始人离职给被投公司带来的巨大影响。

王慧文辞任董事

此前，大模型创业4个月，王慧文就因身体原因停职休养。

紧接着，美团在港交所公布，王慧文已提出辞去公司非执行董事、公司董事会提名委员会成员和公司授权代表职务，自6月26日起生效。

在王慧文卸任董事后，美团宣布，执行董事穆荣均已获委任为授权代表，自2023年6月26日起生效。

另外，提名委员会将由冷雪松先生和沈向洋博士组成，冷雪松继续担任提名委员会主席。

在另一份公告中，美团更新了董事会成员。王兴和穆荣均担任公司执行董事，沈南鹏为非执行董事，欧高敦、冷雪松、沈向洋是独立非执行董事。

参考资料：

www1.hkexnews.hk/listedco/li…

上一篇文章介绍了Midjourney实现副业变现的6种方式，也介绍了小红书壁纸的变现逻辑：第一种是开通店铺，吸引用户进行购买；第二种是引导用户在某个小程序下载图片，用户每下载一张，我们便会有0.3元左右的收益。这一篇开始介绍如何使用Midjourney制作小红书壁纸。

一、制作步骤

使用Midjourney制作小红书壁纸的步骤比较简单，分为5步，其中最关键的步骤就是画出用户喜欢的壁纸。

1、绘画壁纸

在开始绘画之前，我们首先要确定好壁纸类型，小红书的壁纸类型有多种，包括剪纸类型、花草类型、梵高类型（使用梵高的风格画各种夜景）、二次元类型等，确定壁纸类型有利于我们吸引垂类粉丝。

以二次元风格壁纸为例，在Midjourney中，输入/image指令，再输入提示词：cute cat swimming underwater,smiling,bright eyes,portrait,dream,a bright color --ar 9:16 --q 2 --niji 5 --v 5.1 --s 750，就可以得到一张好看的壁纸。 

2、添加边框

添加手机边框有两种方式：一种需要熟悉PS软件，使用PSD文件添加；另一种是通过醒图、美图秀秀等APP添加（搜索【手机边框】，找到合适的边框，进行添加）。这一步骤不是必须的，但添加之后，会有仪式感。 

3、发布作品

接下来就可以在小红书发布作品，标题填写【4K高清壁纸】，有利于用户搜索。如果会写文案，也可以进行文案的添加。需要说明的是，一开始不建议开通店铺，等用户数到达一定数量再开通（不会开通小红书店铺的读者，可以留言）。

4、上传图片

如果通过小程序进行变现，需要将生成的壁纸上传到小程序，以XX壁纸小程序为例，抖音搜索或者微信搜索都可以，之后注册，注册完成设置自己的口令，口令尽量以数字为主，这样用户下载起来比较方便。

5、进行引流

如果开通了商城，发布作品时，将商城添加到作品中即可；如果是小程序，需要进行引流，比如，进入粉丝群可以得到高清图片、三连击得到原图壁纸等。

二、发布逻辑

上述5个步骤实现了小红书壁纸的制作以及发布，如何源源不断的画出用户喜欢的壁纸，也是我们需要考虑的问题。

1、模仿

模仿点赞比较高的作品，火过的作品有可能再火一次。

2、创新

创新需要具备一定的审美能力，不过没有关系，多画画就有了。

3、追随实事

这和那些口播博主一样，追随社会热点事件，只不过我们追随的是节日氛围，比如在端午节发布和其相关的作品。

4、多发

做过自媒体的都知道，作品是否能火，多少有一点玄学，也就是概率事件。那对抗概率事件最好的武器就是数量和时间，也就是多发布作品，坚持一两个月。

以上四点是做自媒体的通用逻辑，就不再赘述。

三、案例

在小红书中，通过Midjourney制作壁纸变现超过5000元的大有人在，以下便是几个案例：

1、两个月，变现15000元。

2、两个月，变现28000元。

3、一个多月，变现8000元（包含80件商品）。

列举这几个案例，并不是说我们按照上述步骤就一定能达到这样的收入（赚钱本身就不是容易的事），而是想要表达两个意思：第一，在找对标账号的时候，我们就应该找这种变现能力强的账号，跟着他们学习，收获会很大。

第二，任何技术越早开始越好，AI已经是势不可挡，因为它的本质是生产力的提高，而且国家也在鼓励人工智能的发展，作为技术人员，我们有先发优势，当机会来临的时候，我们一定要抓住。

就像在掘金社区，有人是为了分享技术，但有人也是为了吸引粉丝，进行副业变现。当某个行业红利不在的时候，最好的方法是寻找下一个行业红利。

我是阿凯，一位不知名的Midjourney玩家，如果你有任何关于Midjourney的问题，可以进行留言。关注我，下一篇手把手教你使用Midjourney制作抖音壁纸，进行副业变现。
，

人在国企，身不由己！公司福利和薪资还可以，但有个难顶的组长就不可以，说走就走!如果把这个组长换了的话就另说了！

1.为什么突然想不干了？

1.奇葩的新组长

我的前组长辞职了，然后被安排到这个自研项目组，而这个新组长我之前得罪过，老天爷真爱开玩笑！

今年过年前，我主开发的平台要嵌入到他负责的项目里面，一切对接都很顺利，然而某天，有bug，我修复了，在群里面发消息让他合并分支更新一下。他可能没看到，然后我下班后一个小时半，我还在公司，在群里问有没有问题，没回应！

然后我就坐车回家，半路，产品经理组长、大组长和前组长一个个轮流call我，让我处理一下bug,我就很无语！然后我就荣获在家远程办公，发现根本没问题！然后发现是对方没更新的问题！后面我修复完直接私聊他merge分支更新，以免又这样大晚上烦人！
而类似的事情接连发生，第三次之后，我忍不住了，直接微信怼了他，他还委屈自己晚上辛苦加班，我就无语大晚有几个人用，晚上更新与第二天早上更新有什么区别？然后就这样彻底闹掰了！

我就觉得这人很奇葩，有什么问题不能直接跟我沟通，一定要找我的上级一个个间接联系我呢？而且，这更新流程就很有问题，我之前在别的组支援修bug，是大早上发布更新，一整天测试，保证不是晚上的时候出现要紧急处理的问题！

然后，我跟这人有矛盾后，我就没继续对接这个项目了，前组长安排了别人代替我！

结果兜兜转转，竟然调到他这里来！作孽啊！

2.项目组乱糟糟

新项目组可以看出新组长管理水平很糟糕！

新组长给自己的定位是什么都管！产品、前后端、测试、业务等，什么都往自己身上揽！他自己觉得很努力，但他不是那部分的专业人员，并不擅长，偏偏还没那个金刚钻揽一堆瓷器活！老爱提建议！

项目组就两个产品，其中一个是UI设计刚转，还没成长为专业的产品经理，而那个主要负责的产品经理根本忙不过来！

然后，他一个人搞不定，就开始了PUA大法，周会的时候就会说：“希望大家要把这个项目当成自己的事业来奋斗，一起想，更好地做这个产品！”

“这个项目集成了那么多的模块功能，如果大家能够做好，对自己有很大的历练和成长！”

“我们项目是团队的重点项目，好多领导都看好，开发不要仅限于开发，要锻炼产品思维……”

……

简而言之就是，除了本职工作也要搞点产品的工作！

然后建模师开始写市场调研文档，前后端开发除了要敲代码，还得疯狂想新功能。

整个组开始陷入搞新东西的奇怪旋涡！

某次需求评审的时候，因为涉及到大量的文件存储，我提出建议，使用minio,fastdfs，这样就不用每次部署的时候，整体文件还要迁移，结果对方一口拒绝，坚决使用本地存储，说什么不要用XX平台的思想来污染他这个项目，他这个项目就要不需要任何中间件都能部署。

就很无语！那个部署包又大又冗余，微服务都不用，必须要整包部署整套系统，只想要某几个功能模块都不行，还坚持说这样可以快速整包部署比较好！

一直搞新功能的问题就是版本更新频繁！一堆新功能都没测清楚就发布，导致产品质量出现严重问题，用户体验极差！终于用户积攒怨气爆发了，在使用群里面@了我们领导，产品质量问题终于被彻底揭开了遮羞布！

领导开始重视这个产品质量的问题，要求立即整改！

然后这个新组长开始新一轮搞事！

“大家保证新功能进度的同时，顺便测试旧功能，尽量不要出bug！”

意思就是你开发进度也要赶，测试也要搞！

就不能来点人间发言吗？

3.工作压力剧增

前组长是前端的，他带我入门3D可视化的，相处还算融洽！然而他辞职了，去当自由职业者了！

新组长是后端的，后端组长问题就是习惯以后端思维评估前端工作，给任务时间很紧。时间紧就算了，还要求多！

因为我之前主开发的项目是可视化平台，对方不太懂，但不妨碍他喜欢异想天开，加个这个，加个那个，他说一句话，就让你自行想象，研究竞品和评估开发时间！没人没资源，空手套白狼，我当时就很想爆他脑袋了！

我花一个星期集成了可视化平台的SDK，连接入文档都写好了，然后他验收的时候提出一堆动态配置的要求，那么大的可视化平台，他根本没考虑项目功能模块关联性和同步异步操作的问题，他只会提出问题，让你想解决方案！

然后上个月让我弄个web版的Excel表格，我看了好多开源项目，也尝试二开，增加几个功能，但效率真的好低！于是我就决定自己开发一个！

我开发了两个星期，他就问我搞定没？我说基本功能可以，复杂功能还在做！

更搞笑的是，我都开发两个星期了，对方突然中午吃饭的时候微信我，怕进度赶不上，建议我还是用开源的进行二开，因为开源有别人帮忙一起搞。

我就很无语，人家搞的功能又不是一定符合你的需求，开源不等于别人给你干活，大家都是各干各的，自己还得花精力查看别人代码，等价于没事找事，给自己增加工作量！别人开发的有隐藏问题，出现bug排查也很难搞，而自己开发的，代码熟悉，即便有问题也能及时处理！

我就说他要是觉得进度赶不上就派个人来帮忙，结果他说要我写方案文档，得到领导许可才能给人。

又要开发赶进度，又要写文档，哪有那么多时间！最终结果就是没资源，没人手，进度依旧要赶！

因为我主开发的那个可视化平台在公司里有点小名气，好多平台想要嵌入，然后，有别的平台找到他要加上这个可视化平台，但问题是我很忙，又要维护又要开发，哪搞得了那么多？还说这个很赶！赶你个头！明知道时间没有，就别答应啊！工作排期啊！

新组长不帮组员解决问题，反而把问题抛给组员，压榨组员就很让人反感！

2.思考逃离

基于以上种种！我觉得这里不是一个长久之地，于是想要逃离这里！

我联系了认识的其他团队的人，别人表示只要领导愿意放人，他们愿意接收我，然后我去咨询一些转团队的流程，那些转团队成功的同事告诉我，转团队最难的是领导放人这关，而且因为今年公司限制招聘，人手短缺，之前有人提出申请，被拒绝了！并且转团队的交接的一两个月内难免要承受一些脸色！有点麻烦！

我思虑再三，我放弃了转团队这条路，因为前组长走了之后，整个团队只剩下我一个搞3D开发的，估计走不掉！

3.提出辞职

忍了两个月，还是没忍住，工作最重要的是开开心心！赚钱是一回事，要是憋出个心理疾病就是大事了！于是我为了自己的身心健康，决定走人！拜拜了喂！老娘不奉陪了！

周一一大早，我就提交了辞职信，大组长表示很震惊，然后下午的时候，领导和大组长一起来跟我谈话，聊聊我为什么离职？问我有没有意愿当个组长之类的，我拒绝了，我只想好好搞技术！当然我不会那么笨去说别人的坏话得罪人！

我拿前组长当挡箭牌，说自己特别不习惯这个新组长的管理方式！前组长帮我扛着沟通之类的问题，我只要专心搞开发就好了！

最终，我意志坚定地挡住了领导和大组长的劝留谈话，并且开始刷面试题，投简历准备寻找新东家！

裸辞后真的很爽，很多同事得知消息都来关心我什么情况，我心里挺感动的！有人说我太冲动了，可以找好下家再走！但我其实想得很清楚，我没可能要求一个组长委屈自己来适应我，他有他的管理方式，我有我的骄傲！我不喜欢麻烦的事，更不喜欢委屈自己，一个月后走人是最快解决的方案！

4. 转机

其实我的离开带来了一点影响，然后加上新组长那个产品质量问题警醒了领导，然后新组长被调去负责别的项目了，换个人来负责现在的项目组，而这个人就是我之前支援过的项目组组长，挺熟悉的！

新新组长管理项目很有条理也很靠谱，之前支援的项目已经处于稳定运行的状态了，于是让他来接手这个项目！他特意找我谈话，劝我留下来，并且承诺以后我专心搞技术，他负责拖住领导催进度等问题！

我本来主要就是因为新组长的问题才走人的，现在换了个不错的组长！可以啊！还能苟苟！

5.反思

1. 其实整件事情中，我也有错，因为跟对方闹掰了，就拒绝沟通，所以导致很多问题的发生，如果我主动沟通去说明开发难度的问题，并且争取时间，就不至于让自己处于一个精神内耗的不快乐状态。
2. 发现问题后，我没有尝试去跟大组长反馈，让大组长去治治对方，或者让大组长帮忙处理这个矛盾，我真的太蠢了！
3. 我性格其实挺暴躁的，看不顺眼就直接怼，讨厌的人就懒得搭理，这样的为人处世挺不讨喜的，得改改这坏脾气！

本文将从以下两个层面解决iOS内存泄漏问题：

• 内存泄漏排查方法（工具）
• 内存泄漏原因分析（解决方案）

在正式开始前，我们先区分两个基本概念：

• 内存泄漏（memory leak）：是指申请的内存空间使用完毕之后未回收。 一次内存泄露危害可以忽略，但若一直泄漏，无论有多少内存，迟早都会被占用光，最终导致程序crash。（因此，开发中我们要尽量避免内存泄漏的出现）
• 内存溢出（out of memory）：是指程序在申请内存时，没有足够的内存空间供其使用。 通俗理解就是内存不够用了，通常在运行大型应用或游戏时，应用或游戏所需要的内存远远超出了你主机内安装的内存所承受大小，就叫内存溢出。最终导致机器重启或者程序crash。

简单来说：

一、排查方法

我们知道，iOS开发有“ARC机制”帮忙管理内存，但在实际开发中，如果处理不好堆空间上的内存还是会存在内存泄漏的问题。如果内存泄漏严重，最终会导致程序的崩溃。

首先，我们需要检查我们的App有没有内存泄漏，并且快速定位到内存泄漏的代码。目前比较常用的内存泄漏的排查方法有两种，都在Xcode中可以直接使用：

• 第一种：静态分析方法（Analyze）
• 第二种：动态分析方法（Instrument工具库里的Leaks）。一般推荐使用第二种。

1.1 静态内存泄漏分析方法：

• 第一步：通过Xcode打开项目，然后点击Product->Analyze，开始进入静态内存泄漏分析。 如下图所示：
  
  

• 第二步：等待分析结果。

• 第三步：根据分析的结果对可能造成内存泄漏的代码进行排查，如下图所示。
  
  

PS：静态内存泄漏分析能发现大部分问题，但只是静态分析，并且并不准确，只是有可能发生内存泄漏。一些动态内存分配的情形并没有分析。如果需要更精准一些，那就要用到下面要介绍的动态内存泄漏分析方法（Instruments工具中的Leaks方法）进行排查。

1.2 动态内存泄漏分析方法：

静态内存泄漏分析不能把所有的内存泄漏排查出来，因为有的内存泄漏发生在运行时，当用户做某些操作时才发生内存泄漏。这是就要使用动态内存泄漏检测方法了。

步骤如下：

• 第一步：通过Xcode打开项目，然后点击Product->Profile，如下图所示：
  
  
• 第二步：按上面操作，build成功后跳出Instruments工具，如上图右侧图所示。选择Leaks选项，点击右下角的【choose】按钮。如下图：
  
  
• 第三步：这时候项目程序也在模拟器或手机上运行起来了，在手机或模拟器上对程序进行操作，工具显示效果如下：
  
  

点击左上角的红色圆点，这时项目开始启动了，由于Leaks是动态监测，所以手动进行一系列操作，可检查项目中是否存在内存泄漏问题。如图所示，橙色矩形框中所示绿色为正常，如果出现如右侧红色矩形框中显示红色，则表示出现内存泄漏。

选中Leaks Checks,在Details所在栏中选择CallTree,并且在右下角勾选Invert Call Tree 和Hide System Libraries，会发现显示若干行代码，双击即可跳转到出现内存泄漏的地方，修改即可。

举个例子：

PS：AFHTTPSessionManager内存泄漏是一个很常见的问题：解决方法有两种：点击这里

二、内存泄漏的原因分析

目前，在ARC环境下，导致内存泄漏的根本原因是代码中存在循环引用，从而导致一些内存无法释放，最终导致dealloc()方法无法被调用。主要原因大概有一下几种类型：

2.1 ViewController中存在NSTimer

如果你的ViewController中有NSTimer，那么你就要注意了，因为当你调用

[NSTimer scheduledTimerWithTimeInterval:1.0 

                                 target:self 

                               selector:@selector(updateTime:) 

                               userInfo:nil 

                                repeats:YES];

• 理由：这时 target: self，增加了ViewController的retain count， 即self强引用timer，timer强引用self。造成循环引用。
• 解决方案：在恰当时机调用[timer invalidate]即可。

2.2 ViewController中的代理delegate

代理在一般情况下，需要使用weak修饰。如果你这个VC需要外部传某个delegate进来，通过delegate+protocol的方式传参数给其他对象，那么这个delegate一定不要强引用，尽量使用weak修饰，否则你的VC会持续持有这个delegate，直到代理自身被释放。

• 理由：如果代理用strong修饰，ViewController（self）会强引用View，View强引用delegate，delegate内部强引用ViewController（self）。造成内存泄漏。
• 解决方案：代理尽量使用weak修饰。

举个例子：代理一般用weak修饰，避免循环引用。

@class QiAnimationButton;

@protocol QiAnimationButtonDelegate <NSObject>



@optional

- (void)animationButton:(QiAnimationButton *)button willStartAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button didStartAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button willStopAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button didStopAnimationWithCircleView:(QiCircleAnimationView *)circleView;

- (void)animationButton:(QiAnimationButton *)button didRevisedAnimationWithCircleView:(QiCircleAnimationView *)circleView;



@end





@interface QiAnimationButton : UIButton



@property (nonatomic, weak) id <QiAnimationButtonDelegate> delegate;



- (void)startAnimation; //!< 开始动画

- (void)stopAnimation; //!< 结束动画

- (void)reverseAnimation; //!< 最后的修改动画

2.3 ViewController中Block

在我们日常开发中，如果block使用不当，很容易导致内存泄漏。

• 理由：如果block被当前ViewController（self）持有，这时，如果block内部再持有ViewController（self），就会造成循环引用。
• 解决方案：在block外部对弱化self，再在block内部强化已经弱化的weakSelf

For Example：

    __weak typeof(self) weakSelf = self;



    [self.operationQueue addOperationWithBlock:^{



        __strong typeof(weakSelf) strongSelf = weakSelf;



        if (completionHandler) {

            

            KTVHCLogDataStorage(@"serial reader async end, %@", request.URLString);

            

            completionHandler([strongSelf serialReaderWithRequest:request]);

        }

    }];

BubblePopup

气泡弹框，气泡提示框，可用于新手引导，功能提示。

在平时的开发中，通常新手引导页或功能提示页会出现气泡弹窗来做提示。如果遇到了这类功能通常需要花费一定的精力来写这么一个工具的，这里写了一个气泡弹窗工具，希望能帮你提升一些开发效率。

使用方法

• 从gitHub上下载代码到本地，代码地址：github.com/zhfei/Bubbl…
• 调用BubblePopupManager文件内的单例方法，在指定的页面上添加气泡提示。 普通文本气泡弹窗使用方式如下：

BubblePopupManager.shared.addPopup(toView: self.view, tips: "冒泡弹窗", popupType: .dotLine, positionType: .bottom, popupPoint: nil, linkPoint: CGPoint(x: sender.frame.midX, y: sender.frame.minY), maxWidth: 200.0)

自定义View气泡弹窗使用方式如下：

BubblePopupManager.shared.addPopup(toView: self.view, customContentView: MyContentView(), popupType: .triangle, positionType: .bottom, popupPoint: CGPoint(x: sender.frame.midX, y: sender.frame.minY), linkPoint: nil, maxWidth: 200.0)

注意：自定义内容View只能使用frame布局，不能使用约束。

设计模式

气泡弹窗View的结构设计采用的设计模式为组合模式

把气泡弹窗分为3个部分：气泡背景，气泡指示器，气泡提示内容。

在创建气泡弹窗时，根据子类的自定义实现，将这三部分分别创建并组装到一起。实现了功能的灵活插拔和自定义扩展。

气泡弹窗View类图

气泡弹窗生成算法采用的设计模式为模版方法模式

在气泡构建基类中设置好气泡的构建步骤，把必要的部分或者提供默认实现的部分在父类中提供默认的实现，对其他需要自定义实现的部分，只在父类中写了一个抽象方法，具体实现交给子类自己实现。

虚线气泡弹窗类图

三角形气泡弹窗类图

核心实现

• BubblePopupManager： 使用气泡弹窗工具的入口，通过它创建并添加一个气泡弹窗到指定的View上。

• BubblePopupBuilder： 气泡弹窗构建者基类，使用模版方法模式定义了气泡的构建流程，子类可以自定义各自的实现。

• DotLineBubblePopupBuilder： 虚线气泡弹窗基类，它是基类BubblePopupBuilder的子类，内部包含了虚线气泡弹窗生成时所需要的工具方法和必要属性，方便创建top,bottom,left,right虚线气泡弹窗。

• TriangleBubblePopupBuilder ： 三角形气泡弹窗基类，它是BubblePopupBuilder的子类，内部包含了三角形气泡弹窗生成时所需要的工具方法和必要属性，方便创建top,bottom,left,right三角形气泡弹窗

• BubblePopup： 气泡弹窗View，它内部使用组合模式将子部件组合起来，组成了一个气泡弹窗。

• BubbleViewFactory： 气泡弹窗子视图创建工程，用于创建气泡弹窗所需要的子视图,并将各个子视图组装成一个最终的气泡弹窗。

BubblePopupBuilder

BubblePopupBuilder是所有气泡弹窗的公共基类，对于里面定义的属性和方法的功能分别为

• 属性：属性里保存的是气泡弹窗公共的，必要的数据。
• 方法：在基类提供的方法中主要用于定义气泡的构建流程。 核心方法如下：

   func setupUI() {

        addBubbleContentView(to: bubblePopup)

        addBubbleBGView(to: bubblePopup)

        updateLayout(to: bubblePopup)

        addBubbleFlagView(to: bubblePopup)

    }

其中气泡内容展示视图和气泡背景视图有默认实现，子类可以直接使用默认样式。

而气泡标识View和气泡布局方法则需要子类自己实现，因为不同类型的气泡弹窗它们的气泡标识设布局方式是不一样的。

DotLineBubblePopupBuilder

虚线气泡基类DotLineBubblePopupBuilder，它继承自BubblePopupBuilder

• 属性：增加了虚线弹窗必要的linkPoint属性，即：虚线与气泡弹窗的连接点。 增加了一个坐标系转换懒加载属性，用于将用户设置的屏幕坐标点转成气泡内部的视图坐标系中的点。

• 重要方法说明：

getDrawDotLineLayerRectParams

用于虚线图层绘制：获取虚线绘制时所需要的绘制元素坐标，如：虚线的开始，结束坐标，连接点圆的直径等。

getDotLineLayerContainerViewFrame

更新虚线容器View的位置大小信息：获取不同情况下的虚线容器Frame。

layoutDotLineBubblePopupView

更新虚线气泡弹窗的frame。

updateBGBubbleViewFrame

更新气泡背景的frame。

这里提供的方法属于工具方法，子类可以通过传递自己的类型来得到对应的结果。这里按道理可以使用设计模式中策略模式来对算法进行封装，如：在基类定义一个抽象方法，将上面则4个工具方法分拆到各自的子类中，让子类在对应的自己的类中实现这个方法。

这里没有这样做原因是：这些方法在子类中的实现代码并不复杂，用一个方法根据条件集中返回是比较方便的，而分拆到不同类中反而很麻烦。所以选择在基类中以方法工具的形式统一放置了。

DotLineTopBubblePopupBuilder

top型虚线气泡弹窗DotLineTopBubblePopupBuilder，它继承自DotLineBubblePopupBuilder，属于一直具体的弹窗类型。

它里面只对下面两个方法进行了重写，根据自己的类型进行子类个性化实现。

override func updateLayout

override func addBubbleFlagView

具体实现如下：

class DotLineTopBubblePopupBuilder: DotLineBubblePopupBuilder {

     

    override func updateLayout(to bubblePopup: BubblePopup) {

        layoutDotLineBubblePopupView(bubblePopup: bubblePopup, positionType: .top)

    }

     

    override func addBubbleFlagView(to bubblePopup: BubblePopup) {

        assert(!self.targetPoint.equalTo(.zero), "气泡提示点无效")

         

        let flagFrame = getDotLineLayerContainerViewFrame(position: .top, targetPoint: self.targetPoint)

        let params = getDrawDotLineLayerRectParams(position: .top)

        let flagBubbleView = BubbleViewFactory.generateDotLineBubbleFlagView(flagFrame: flagFrame, position: .top, params: params)

        bubblePopup.bubbleFlagView = flagBubbleView

        bubblePopup.addSubview(flagBubbleView)

    }

     

}

其他bottom, left, right类型相似。

TriangleBubblePopupBuilder

三角形气泡基类TriangleBubblePopupBuilder，它继承自BubblePopupBuilder

• 属性：相对于基类增加了popupPoint属性，它是三角形顶点指向的坐标点 增加了一个坐标系转换懒加载属性，用于将用户设置的屏幕坐标点转成气泡内部的视图坐标系中的点。

• 重要方法说明：

getDrawTriangleLayeyRectParams

为三角形图层绘制提供不同气泡类型所需要的绘制元素坐标，如：三角形的三个顶点。

getTriangleLayerContainerViewFrame

获取不同情况下三角形图层容器的Frame，用于更新三角形图层容器View的位置大小。

layoutTriangleBubblePopupView

更新三角形气泡弹窗的frame。

updateTriangleBGBubbleView

更新气泡背景的frame。

三角形弹窗基类TriangleBubblePopupBuilder的设计方式和虚线弹窗基类是一样的。
这里的方法属于工具方法，子类可以通过传递自己的类型来得到对应的结果，通过牺牲一点开发模式的规范化来换取开发效率的提升。

在三角形气泡基类的下面同样有4个子类top,bottom,left ,right进行各种的自定义实现。

TriangleTopBubblePopupBuilder

top型三角形气泡弹窗DotLineTopBubblePopupBuilder，它继承自DotLineBubblePopupBuilder，属于一直具体的弹窗类型。

它里面只对下面这两个方法做了重写，根据自己的类型进行子类个性化实现。

override func updateLayout

override func addBubbleFlagView

具体实现如下：

class TriangleTopBubblePopupBuilder: TriangleBubblePopupBuilder {

    override func updateLayout(to bubblePopup: BubblePopup) {

        layoutTriangleBubblePopupView(bubblePopup: bubblePopup, positionType: .top)

    }

    override func addBubbleFlagView(to bubblePopup: BubblePopup) {

        assert(!self.targetPoint.equalTo(.zero), "气泡提示点无效")

         

        let flagFrame = getTriangleLayerContainerViewFrame(position: .top, targetPoint: self.targetPoint)

        let params = getDrawTriangleLayeyRectParams(position: .top)

        let flagBubbleView = BubbleViewFactory.generateTriangleBubbleFlagView(flagFrame: flagFrame, position: .top, params: params)

        bubblePopup.bubbleFlagView = flagBubbleView

        bubblePopup.addSubview(flagBubbleView)

    }

}

其他bottom, left, right类型相似。

弹窗效果展示

三角形气泡弹窗

虚线气泡弹窗

自定义气泡弹窗

上一篇我们介绍了移动开发常见的内存泄漏问题，见《百度工程师移动开发避坑指南——内存泄漏篇》。本篇我们将介绍Swift语言部分常见问题。

对于Swift开发者，Swift较于OC一个很大的不同就是引入了可选类型（Optional），刚接触Swift的开发者很容易在相关代码上踩坑。

本期我们带来与Swift可选类型相关的几个避坑指南：可选类型要判空；避免使用隐式解包可选类型；合理使用Objective-C标识符；谨慎使用强制类型转换。希望能对Swift开发者有所帮助。

一、可选类型（Optional）要判空

在Objective-C中，可以使用nil来表示对象为空，但是使用一个为nil的对象通常是不安全的，如果使用不慎会出现崩溃或者其它异常问题。在Swift中，开发者可以使用可选类型表示变量有值或者没有值，可以更加清晰的表达类型是否可以安全的使用。如果一个变量可能为空，那么在声明时可以使用?来表示，使用前需要进行解包。例如：

var optionalString: String?

在使用可选类型对象时，需要进行解包操作，有两种解包方式：强制解包与可选绑定。

强制解包使用 ! 修饰一个可选对象 ，相当于告诉编译器『我知道这是一个可选类型，但在这里我可以保证他不为空，编译时请忽略此处的可空校验』，例如：

let unwrappedString: String = optionalString!  // 运行时报错：Thread 1: Fatal error: Unexpectedly found nil while unwrapping an Optional value

这里使用 ! 进行了强制解包，如果optionalString为nil，将会产生运行时错误，发生崩溃。**因此，在使用 ! 进行强制解包时，必须保证变量不为nil，要对变量进行判空处理，**如下：

if optionalString != nil {

    let unwrappedString = optionalString!

}

相较于强制解包的不安全性，一般而言推荐另一种解包方式，即可选绑定。例如：

if let optionalString = optionalString {

    // 这里optionalString不为nil，是已经解包后的类型，可以直接使用

}

综上，在对可选类型进行解包时应尽量避免使用强制解包，采用可选绑定替代。如果一定要使用强制解包，那么必须在逻辑上完全保证类型不为空，并且做好注释工作，以增加后续代码的可维护性。

二、避免使用隐式解包可选类型（Implicitly Unwrapped Optionals）

由于可选类型每次使用之前都需要进行显式解包操作，有时变量在第一次赋值之后，就会一直有值，如果每次使用都显式解包，显得繁琐，Swift引入了隐式解包可选类型，隐式解包可选类型可以使用 ! 来表示，并且使用时不需要显式解包，可以直接使用，例如：

var implicitlyUnwrappedOptionalString: String! = "implicitlyUnwrappedOptionalString"

var implicitlyString: String = implicitlyUnwrappedOptionalString

上述例子的隐式解包，在编译和运行过程中都不会发生问题，但如果在两行代码中间插入一行 implicitlyUnwrappedOptionalString = nil将会产生运行时错误，发生崩溃。

在我们实际项目中，一个模块通常由多人维护，通常很难保证变量在第一次赋值之后一直不为nil或者只有在第一次正确赋值之后使用，从安全角度考虑，在使用隐式解包类型之前也要进行判空操作，但这样就和使用可选类型没有区别。对于可选类型（?），不经过解包直接使用编译器会报告错误，对于隐式解包类型，则可直接使用，编译器无法帮助我们做出是否为空的检查。因此，在实际项目中，不推荐使用隐式解包可选类型，如果一个变量是非空的，则选择非空类型，如果不能保证是非空的，则选择使用可选类型。

三、合理使用Objective-C标识符

与Swift不同的是，OC是一种动态类型语言，对于OC而言没有optional这个概念，无法在编译期间检查对象是否可空。苹果在 Xcode 6.3 中引入了一个 Objective-C 的新特性：Nullability Annotations，允许编码时使用nonnull、nullable、null_unspecified等标识符告诉编译器对象是否是可空或者非空的，各标识符含义如下：

nonnull，表示对象是非空的，有__nonnull和_Nonnull等价标识符。

nullable，表示对象可能是空的，有__nullable 和_Nullable等价标识符。

null_unspecified，不知道对象是否为空，有__null_unspecified等价标识符。

OC标识符标注的对象类型和Swift类型对应关系如下：

除了以上标识符外，现在通过Xcode创建的头文件默认被 NS_ASSUME_NONNULL_BEGIN 和 NS_ASSUME_NONNULL_END 包住，即在这之间声明的对象默认标识符是 nonnull 的。

在Swift与OC混编场景，编译器会根据OC标识符将OC的对象类型转换成Swift类型，如果没有显式的标识，默认是null_unspecified。例如：

@interface ExampleOCClass : NSObject

// 没有指定标识符，且没有被NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END包裹，标识符默认为null_unspecified

+ (ExampleOCClass *)getExampleObject; 

@end



@implementation ExampleOCClass

+ (ExampleOCClass *)getExampleObject {

    return nil; // OC代码直接返回nil

}

@end

class ViewController: UIViewController {

    override func viewDidLoad() {

        super.viewDidLoad()

        let _ = ExampleOCClass.getExampleObject().description // 报错：Thread 1: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value

    }

}

在上面例子中，Swift代码调用OC接口获取一个对象，编译器隐式的将OC接口返回的对象转换为隐式解包类型来处理。由于隐式解包类型可以不显式解包直接使用，使用者往往会忽略OC返回的是隐式解包类型，不通过判空而直接使用。但当代码执行时，由于OC接口返回了一个nil，导致Swift代码解包失败，发生运行时错误。

在实际编码中，推荐显式指定OC对象为nonnull或者nullable，针对上述代码进行修改后如下：

@interface ExampleOCClass : NSObject

/// 获取可空的对象

+ (nullable ExampleOCClass *)getOptionalExampleObject;

/// 获取不可空的对象

+ (nonnull ExampleOCClass *)getNonOptionalExampleObject;

@end



@implementation ExampleOCClass

+ (ExampleOCClass *)getOptionalExampleObject {

    return nil;

}

+ (ExampleOCClass *)getNonOptionalExampleObject {

    return [[ExampleOCClass alloc] init];

}

@end

class ViewController: UIViewController {

    override func viewDidLoad() {

        super.viewDidLoad()

        // 标注nullable后，编译器调用接口时，会强制加上 ?

        let _ = ExampleOCClass.getOptionalExampleObject()?.description 

        // 标注nonnull后，编译器将会把接口返回当做不可空来处理

        let _ = ExampleOCClass.getNonOptionalExampleObject().description 

    }

}

在OC对象加上nonnull或者nullable标识符后，相当于给OC代码增加了类似Swift的『静态类型语言的特性』，使得编译器可以对代码进行可空类型检测，有效的降低了混编时崩溃的风险。但这种『静态特性』并不对OC完全有效，例如以下代码，虽然声明返回类型是nonnull的，但是依然可以返回nil:

@implementation ExampleOCClass

+ (nonnull ExampleOCClass *)getNonOptionalExampleObject {

    return nil; // 接口声明不可空，但实际上返回一个空对象，可以通过编译，如果Swift当作非空对象使用，则会发生崩溃

}

@end

class ViewController: UIViewController {

    override func viewDidLoad() {

        super.viewDidLoad()

        ExampleOCClass.getNonOptionalExampleObject().description

    }

}

基于以上例子，依然会产生运行时错误。从安全性的角度上来说，似乎Swift最好在使用所有OC的接口时都进行判空处理。但实际上这将导致Swift的代码充斥着大量冗余的判空代码，大大降低代码的可维护性，同时也违背了『暴露问题，而非隐藏问题』的编码原则，并不推荐这么做，合理的做法是在OC侧做好安全校验，OC对返回类型应做好检验，保证返回类型的正确性，以及返回值和标识符能够对应。

综合来看，OC侧标识符最好遵循如下使用原则：

1、不推荐使用NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END，因为默认修饰符是nonnull的，在实际开发中很容易忽略返回的对象是否为空。返回空则会导致Swift运行时错误。推荐所有涉及混编的OC接口都需要显式使用相应的标识符修饰。

2、OC接口要谨慎使用 nonnull 修饰 ，必须确保返回值不可能是空的情况下使用，任何不能确定不可空的接口都需要标注为nullable。

3、为避免Swift侧不必要的类型、判空等校验（违背Swift设计理念），在理想状态下需在OC侧进行类型的校验，保证返回对象和标注的标识符完全正确，这样Swift则可以完全信赖OC返回的对象类型。

4、在Swift调用OC代码时，要关注OC返回的类型，尤其是返回隐式解包类型时，要做好判空处理。

5、在OC代码支持Swift调用前，提前对OC代码做好返回类型和标识符的检查，确保返回Swift的对象是安全的。

四、谨慎使用强制类型转换

GEEK TALK

Swift 作为强类型语言，禁止一切默认类型转换，这要求编码者需要明确定义每一个变量的类型，在需要类型转换时必须显式的进行类型转换。Swift可以使用as和as?运算符进行类型转换。

as运算符用于强制类型转换，在类型兼容情况下，可以将一个类型转换为另一个类型，例如：

var d = 3.0 // 默认推断为 Double 类型

var f: Float = 1.0 // 显式指定为 Float 类型

d = f // 编译器将报错“Cannot assign value of type 'Float' to type 'Double'”  

d = f as Double // 需要将Float类型转换为Double类型，才能赋值给f

除了以上列举的基本类型外，Swift还兼容基础类型与对应的OC类型的转换，比如NSArray/Array、NSString/String、NSDictionary/Dictionary。

如果类型转换失败，将会导致运行时错误。例如：

let string: Any = "string"

let array = string as Array // 运行时错误

这里string变量实际是一个String类型，尝试将String类型转换成Array类型，将导致运行时错误。

另一种类型转换的方式是使用as?运算符，如果转换成功，返回一个转换类型的可选类型，如果转换失败，返回nil。例如：

let string: Any = "string"

let array = string as? Array // 转换失败，不会产生运行时错误

这里由于无法将String类型转换为Array类型，因此转换失败，array变量的值为nil，但不会产生运行时错误。

综合来看，在进行类型转换时，需要注意以下几点：

1、类型转换只能在兼容的类型之间进行，例如Double和Float可以相互转换，但String和Array之间不能相互转换。

2、如果使用as进行强制类型转换，需要确保转换是安全的，否则将会导致运行时错误。如果不能确保转换类型之间是兼容的，则应该使用as?运算符，例如将网络数据解析成模型数据时，无法保证网络数据的类型，应该使用as?。

3、在使用as?运算符进行类型转换时，需要注意返回值可能为nil的情况。

----------  END  ----------

推荐阅读【技术加油站】系列：

百度工程师移动开发避坑指南——内存泄漏篇

百度程序员开发避坑指南（Go语言篇）

百度程序员开发避坑指南（3）

百度程序员开发避坑指南（移动端篇）

百度程序员开发避坑指南（前端篇）

1. 使用场景：

公司开会的时候有师兄问到为什么hooks定义一般都写在顶部，对于这个问题我以前总结过，这次看了
react新文档后我给出更加详细的解释并给出具体代码来解释为什么要放在顶部。

2.官网解释：

1.官网截图镇楼：

2.那我写在条件语句中会怎样

我给出一段代码：其中const [message, setMessage] = useState('');写在了条件语句里面

import { useState } from 'react';



export default function FeedbackForm() {

  const [isSent, setIsSent] = useState(false);

  if (isSent) {

    return <h1>Thank you!</h1>;

  } else {

    // eslint-disable-next-line

    const [message, setMessage] = useState('');

    return (

      <form onSubmit={e => {

        e.preventDefault();

        alert(`Sending: "${message}"`);

        setIsSent(true);

      }}>

        <textarea

          placeholder="Message"

          value={message}

          onChange={e => setMessage(e.target.value)}

        />

        <br />

        <button type="submit">Send</button>

      </form>

    );

  }

}

效果图：这是一个收集用户反馈的小表单。当反馈被提交时

 它应该显示一条感谢信息，当我点击确定时出现一条错误。

“渲染的 hooks 比预期的少”

3.那我不写在顶部可能会怎样

下方的const [message, setMessage] = useState('');并没有写在顶部

   import { useState } from 'react';



    export default function FeedbackForm() {

      const [isSent, setIsSent] = useState(false);

      if (isSent) {

        return <h1>Thank you!</h1>;

      }

        const [message, setMessage] = useState('');

        return (

          <form onSubmit={e => {

            e.preventDefault();

            alert(`Sending: "${message}"`);

            setIsSent(true);

          }}>

            <textarea

              placeholder="Message"

              value={message}

              onChange={e => setMessage(e.target.value)}

            />

            <br />

            <button type="submit">Send</button>

          </form>

        );

      }

    }

效果图：

 点击确认后：
同样出现这个错误：提前return导致后面一个hooks没有渲染。

4.原因分析

从源码的角度来说的话，React会在内部创建一个名为“Hooks”（中文为钩子）的数据结构来追踪每个组件的状态。

在函数组件中调用Hook时，React会根据Hook的类型将其添加到当前组件的Hooks链表中。然后，React会将这些Hooks存储在Fiber节点的“memoizedState”字段中，以便在下一次渲染时使用。

如果你在代码中多次调用同一个Hook，React会根据Hooks的顺序将其添加到当前组件的Hooks链表中。这样，React就可以确定哪个状态应该与哪个组件关联，并且能够正确地更新UI。

以下是一个示例代码片段：

import { useState, useEffect } from 'react';



function useCustomHook() {



const [count, setCount] = useState(0);



useEffect(() => {

document.title = `Count: ${count}`;

}, [count]);

return [count, setCount];

}



export default function MyComponent() {



const [count, setCount] = useCustomHook();

return (

<div>

<p>Count: {count}</p>

<button onClick={() => setCount(count + 1)}>Increment</button>

</div>

);

}

在上面的代码中，useCustomHook是一个自定义Hook，它使用useState和useEffectHook来管理状态。在MyComponent中，我们调用自定义Hook并使用返回值来渲染UI。

由于useCustomHook只能在函数组件或其他自定义Hooks的最顶层调用，我们不能将它嵌套在条件语句、循环或其他函数内部。如果这样做，React将无法正确追踪状态并更新UI，可能导致不可预测的结果。如果我们条件渲染中使用可能导致没有引入useCustomHook()，从而导致错误。

总结描述就是创建了一个链表，当在条件语句中使用hooks时可能会导致前后两次链表不同，从而导致错误，所以我们必须尽可能避免这种错误从而写在顶部。

前言

还有谁？刚上三天班就被公司公司的工作不适合我，叫我先提升一下。

后面我也向公司那边讨要了一个说法，我只能说他们那边的说辞让我有些不服气。

现在之所以把这件事在掘金上记录一下，一是记录一下自己的成长轨迹，二也是想问问大家的看法 

经过

我今年大三，在江西的一所普通大学。

今年三月份开始学的前端，然后到了八月底，自己手上也有了两个玩具项目，就开始背一背八股文，也尝试去体验一下面试的滋味。

一直陆陆续续的突然发现了这家公司A，因为听说A可以接受大三远程实习，所以我就很努力的开始准备这家的面试。

到了九月底，我记得我那个时候还在上课，突然那边打电话给我，问我现在是否能面试？因为这次比较突兀，所以那边也没问什么问题，就问了一些很基础的react hooks以及深浅拷贝。然后就说我的面试通过了，但正式上班之前他要布置一个任务给我，叫我去模仿一下一款小程序，只要实现里面一些页面和功能即可。他说这些天就相当于我的试用期，看我配不配他们给我的100元一天的薪水。

大概到了10月13号，他们说我仿写的项目达到了他们的预期，可以把我的一些身份信息交给他了，然后17号正式入职。讲真的那个时候我还是很开心的，毕竟要开始自己第一份工作了，虽然收入不高，但足以让我不用再向家里要生活费了，以及后面寒假和明年暑假的时候也可以更好面一些大厂的实习。

10月17号，这一天我都没开始写代码，因为他那边的项目我运行不起来，而且他们那边的代码是用了函数式组件和类式组件混用，以及一些taro的知识。他们就干脆叫我自己重写一下他们的项目，用h5开发即可。

10月18号，我在这一天写了一白天的代码，自我感觉还可以，晚上到了git提交阶段，问题出现了，还是大问题。因为在git操作这一块我不太熟悉，自己之前也都是在gitee上和vscode绑定进行代码的提交，指令没怎么用过。然后用我自己用http复制仓库连接这一步它总报错，说拒绝连接。为此我在网上搜了好多种方法都没有找到解决办法，最后实在不得已问了他们。反正那一个晚上确实弄了好久也没弄好把我心态也给搞崩了，也把他们问的有点烦了。这一块是我自己的问题。

10月19号，那天一从床上蹦起来，我又开始了上传提交工作，果然睡了一觉效率高了很多，花了半个小时终于完成了昨天我一个晚上的工作。然后我又开始了项目的还原工作。一直到了晚上我才开始问了一个问题，问题都还没叙述完，他那边就来电话了，说我暂时不适合这份工作。。

沟通

他也打电话和我沟通了一下，就是他认为：

首先我样式写的有问题。关于这一点我在入职之前就和他说了我这一块不太好，但是我觉得我自己写的样式虽然不好，但是也绝对不会很差的那种，最多就是写的不够优雅。

其次就是他觉得我和他沟通有问题。比如这个项目，他叫我在他给的基础上完善一些功能设置一些接口，然后我和他说要不我先把他给的项目先还原了，再在这个基础上再进行添加。他说了OK。结果我做完后他又认为我还原页面还是不行，说这样写后面还要再重新写过，等于没写。。。

最后也是让我特别不解的地方，他说我要转变心态，不能以学习的心态来做这份工作。这我能理解，公司招人当然是要人来干活的，但我每天只会问他一两个问题，而且我在问这些问题之前都至少自己思考过半个小时以上才来找他。对于这点我自己也感觉迷，因为我知道问多了问题肯定会很麻烦人家，但如果不问问题，全靠我自己解决，这样每天的产出又很少，而且他那边都没有给我布置过每日任务，那几天都是我准备干什么然后和他说一声。

虽然他最后也说了，他还要考虑考虑，下个礼拜一给我答复。但是我今天还是忍不住，自己也和他说了一些我的看法。

我全文大概是这么说的：

在你考虑留不留我之前我也想说几句话，我觉得成年人处理事情应该要严谨一点。拿你对我的要求举例吧，首先至于我的能力，没错，我的能力肯定是有问题的，在面试和入职之前我就把我的问题和你说了，你也说这是小事，后面可以学。然后我是在你这里通过了面试的，面试通过起码能说明你对我能力的一种认可吧。面试通过后你叫我去仿小程序，说是试用期的意思，好，我也认真完成了，你也说我可以交作业了。这难道不意味着我试用期也通过了吗？然后我们开始谈协议，叫我签三个月还是六个月，叫我交材料。我现在还没进入社会，我也不知道你这边的协议有没有法律效力，但我还是很信任你，所以没和你谈协议这边的严谨性和合法性。结果我等来的就是工作三天被你说不合适，我还是个学生，没有进入社会也不知道这样算不算毁约，因为我不懂，而且对我来说这也不是个重点，重要的是一个公司对他们自己承诺的一个态度。其次，就是你说我要换一种心态，不能以学习的心态来做这份工作，我能理解，公司招人当然是要人来干活的，你平常的工作很忙我知道，总这样问你问题肯定会让你很烦，但我每天真的就是只会问你一两个问题，而且我在问这些问题之前都至少自己思考过半个小时以上才来找你的。对于这一点我也感觉很委屈，我知道问多了问题会麻烦你，但如果不问问题，全靠我自己解决，这样每天的产出肯定又不达标，不等你来说我，我自己也过意不去。问又不是，不问又不是。害。。。最后我觉得按你的要求的话，你不应该去招一天100的实习生来帮你干这种活，应该招正式员工。

最后问他要三天薪水的时候还被他扣了两天，第一天说我没提交代码，他说他之前和我说过，但我看协议上根本就没有写，然后第三天那个又不算。。。
更离谱的是一天薪水还说要过几天给我。。。。

补一张协议

最后

自己肯定是也有问题的，自身的实力肯定有待提升，但他的说辞真的令我不满意。

远程实习我也有点怕了，难道每天问一两个问题都不行吗？

另外我在合同法律这一块应该也要认真严谨一点，当时是真的比较信任他，所以没怎么注意。

害，过去了的就让它过去吧，可惜少了一段实习经历，但我也多出来了很多时间去学一些新的东西，可以好好准备一下寒假实习。

方案一

double systemVersion = [UIDevice currentDevice].systemVersion.boolValue;



if (systemVersion >= 7.0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}



if (systemVersion >= 10.0) {

    // >= iOS 10.0

} else {

    // < iOS 10.0

}

如果只是大致判断是哪个系统版本，上面的方法是可行的，如果具体到某个版本，如 10.0.1，那就会有偏差。我们知道 systemVersion 依旧是10.0。

方案二

NSString *systemVersion = [UIDevice currentDevice].systemVersion;

NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1" options:NSNumericSearch];



if (comparisonResult == NSOrderedAscending) {

    // < iOS 10.0.1

} else if (comparisonResult == NSOrderedSame) {

    // = iOS 10.0.1

} else if (comparisonResult == NSOrderedDescending) {

    // > iOS 10.0.1

}



// 或者



if (comparisonResult != NSOrderedAscending) {

    // >= iOS 10.0.1

} else {

    // < iOS 10.0.1

}

有篇博客提到这种方法不靠谱。比如系统版本是 10.1.1，而我们提供的版本是 8.2，会返回NSOrderedAscending，即认为 10.1.1 < 8.2 。

其实，用这样的比较方式 NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1"]，的确会出现这种情况，因为默认是每个字符逐个比较，即 1(0.1.1) < 8(.2)，结果可想而知。但我是用 NSNumericSearch 方式比较的，即数值的比较，不是字符比较，也不需要转化成NSValue(NSNumber) 再去比较。

方案三

if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_7_0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}



// 或者



if (kCFCoreFoundationVersionNumber >= kCFCoreFoundationVersionNumber_iOS_7_0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}

这些宏定义是 Apple 预先定义好的，如下：

#if TARGET_OS_IPHONE

...

#define NSFoundationVersionNumber_iOS_9_4 1280.25

#define NSFoundationVersionNumber_iOS_9_x_Max 1299

#endif

细心的童靴可能已经发现问题了。Apple 没有提供 iOS 10 以后的宏？，我们要判断iOS10.0以后的版本该怎么做呢？
有篇博客中提到，iOS10.0以后版本号提供了，并且逐次降低了，并提供了依据。

#if TARGET_OS_MAC

#define NSFoundationVersionNumber10_1_1	425.00

#define NSFoundationVersionNumber10_1_2	425.00

#define NSFoundationVersionNumber10_1_3	425.00

#define NSFoundationVersionNumber10_1_4	425.00

...

#endif

我想这位童鞋可能没仔细看， 这两组宏是分别针对iPhone和macOS的，不能混为一谈的。

所以也只能像下面的方式来大致判断iOS 10.0， 但之前的iOS版本是可以准确判断的。

if (NSFoundationVersionNumber > floor(NSFoundationVersionNumber_iOS_9_x_Max)) {

    // > iOS 10.0

} else {

    // <= iOS 10.0

}

方案四

在iOS8.0中，Apple也提供了NSProcessInfo 这个类来检测版本问题。

@property (readonly) NSOperatingSystemVersion operatingSystemVersion NS_AVAILABLE(10_10, 8_0);

- (BOOL) isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion)version NS_AVAILABLE(10_10, 8_0);

所以这样检测：

if ([[NSProcessInfo processInfo] isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion){.majorVersion = 8, .minorVersion = 3, .patchVersion = 0}]) {

     // >= iOS 8.3

} else {

     // < iOS 8.3

}

用来判断iOS 10.0以上的各个版本也是没有问题的，唯一的缺点就是不能准确版本是哪个版本，当然这种情况很少。如果是这种情况，可以通过字符串的比较判断。

方案五

通过判断某种特定的类有没有被定义，或者类能不能响应哪个特定版本才有的方法。
比如，UIAlertController 是在iOS 8.0才被引进来的一个类，我们这个依据来判断版本

if (NSClassFromString(@"UIAlertController")) {

    // >= iOS 8.0

} else {

    // < iOS 8.0

}

说到这里，就顺便提一下在编译期间如何进行版本控制，依然用UIAlertController 来说明。

NS_CLASS_AVAILABLE_IOS(8_0) @interface UIAlertController : UIViewController

NS_CLASS_AVAILABLE_IOS(8_0) 这个宏说明，UIAlertController 是在iOS8.0才被引进来的API，那如果我们在iOS7.0上使用，应用程序就会挂掉，那么如何在iOS8.0及以后的版本使用UIAlertController ，而在iOS8.0以前的版本中仍然使用UIAlertView 呢？

这里我们会介绍一下在#import <AvailabilityInternal.h> 中的两个宏定义：

*__IPHONE_OS_VERSION_MIN_REQUIRED

*__IPHONE_OS_VERSION_MAX_ALLOWED

从字面意思就可以直到，__IPHONE_OS_VERSION_MIN_REQUIRED 表示iPhone支持最低的版本系统，__IPHONE_OS_VERSION_MAX_ALLOWED 表示iPhone允许最高的系统版本。

__IPHONE_OS_VERSION_MAX_ALLOWED 的取值来自iOS SDK的版本，比如我现在使用的是Xcode Version 8.2.1（8C1002），SDK版本是iOS 10.2，怎么看Xcode里SDK的iOS版本呢？

进入PROJECT，选择Build Setting，在Architectures中的Base SDK中可以查看当前的iOS SDK版本。

打印这个宏，可以看到它一直输出100200。

__IPHONE_OS_VERSION_MIN_REQUIRED 的取值来自项目TARGETS的Deployment Target，即APP愿意支持的最低版本。如果我们修改它为8.2，打印这个宏，会发现输出80200，默认为10.2。

通常，__IPHONE_OS_VERSION_MAX_ALLOWED 可以代表当前的SDK的版本，用来判断当前版本是否开始支持或具有某些功能。而__IPHONE_OS_VERSION_MIN_REQUIRED 则是当前SDK支持的最低版本，用来判断当前版本是否仍然支持或具有某些功能。

回到UIAlertController 使用的问题，我们就可以使用这些宏，添加版本检测判断，从而使我们的代码更健壮。

 - (void)showAlertView {

#if defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_9_0

    UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Title" message:@"message" delegate:nil cancelButtonTitle:@"Cancel" otherButtonTitles:@"OK", nil];

    [alertView show];

#else

    if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_8_0) {

        UIAlertController *alertViewController = [UIAlertController alertControllerWithTitle:@"Title" message:@"message" preferredStyle:UIAlertControllerStyleAlert];



        UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:@"Cancel" style:UIAlertActionStyleCancel handler:nil];

        UIAlertAction *otherAction = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault handler:nil];



        [alertViewController addAction:cancelAction];

        [alertViewController addAction:otherAction];



        [self presentViewController:alertViewController animated:YES completion:NULL];

    }

#endif

}

方案六

iOS 11.0 以后，Apple加入了新的API，以后我们就可以像在Swift中的那样，很方便的判断系统版本了。

if (@available(iOS 11.0, *)) {

	// iOS 11.0 及以后的版本

} else {

	// iOS 11.0 之前

}

参考链接

前言

首先声明，没有标题党哈！

以下我知道的国内知名react组件库全部都有这个bug，你们现在都能去复现，一个提pr的好机会就让给你们了，哈哈！复现组件库：

• 阿里系：ant design, fusion design，
• 字节系：arco design
• 腾讯：tdesign

本来字节还有一个semi design，结果我发现它没有Affix组件，也就是固钉组件，让他躲过一劫，他有这个组件我也觉得肯定会复现相同的bug。

Affix组件是什么，以及bug复现

Affix组件（固钉组件）能将页面元素钉在可视范围。如下图：

这个button组件，会在距离顶部80px的时候会固定在屏幕上（position: fixed）,如下图：

如何复现bug

你在这个button元素任意父元素上，加上以下任意style属性

• will-change: transform;
• will-change: filter;
• will-change: perspective;
• transform 不为none
• perspective不为none
• 非safari浏览器，filter属性不为none
• 非safari浏览器，backdrop-filter属性不为none
• 等等

都可以让这个固定组件失效，就是原本是距离顶部80px固定。

我的组件库没有这个bug，哈哈

mx-design

目前组件不是很多，还在努力迭代中，不知道凭借没有这个bug的小小优点，能不能从你手里取一个star，哈哈

bug原因

affix组件无非都是用了fixed布局，我是如何发现这个bug的呢，我的组件库动画系统用的framer-motion，我本来是想在react-router切换路由的时候整点动画的，动画效果就是给body元素加入例如transform的变化。

然后我再看我的固钉组件怎么失效了。。。后来仔细一想，才发现想起来fixed布局的一个坑就是，大家都以为fixed布局相对的父元素是window窗口，其实是错误的！

真正的规则如下（以下说的包含块就是fixed布局的定位父元素）：

1. 如果 position 属性是 absolute 或 fixed，包含块也可能是由满足以下条件的最近父级元素的内边距区的边缘组成的：

评论区有很多同学居然觉的这不是bug？

其实这个问题本质是定位错误，在这些组件库里，同样使用到定位的有，例如Tooltip，Select,Popuver等等，明显这些组件跟写Affix组件的不是一个人，其他组件这个bug是没有的，只有Affix组件出现了，所以你说这是不是bug。

还有，如果因为引用了Affix组件，这个固定元素的任一父元素都不能用以上的css属性，我作为使用者，我用了动画库，动画库使用transfrom做Gpu加速，你说不让我用了，因为引起Affix组件bug，我心里想凭啥啊，明明加两行代码就解决了。

最后，只要做过定位组件的同学，其复杂度在前端算是比较高的了，这也是为什么有些组件库直接用第三方定位组件库（floating-ui，@popper-js），而不是自己去实现，因为自己实现很容易出bug，这也是例如以上组件库Tooltip为什么能适应很多边界case而不出bug。

所以你想想，这仅仅是定位组件遇到的一个很小的问题，你这个都解决不了，什么都怪css，你觉得用户会这么想吗，一有css，你所有跟定位相关的组件全部都不能用了，你们还讲理不？

总之一句话，你不能把定位组件的复杂度高怪用户没好好用，建议去看看floating-ui的源码，或者之前我写的@popper-js定位组件的简要逻辑梳理，你就会意识到定位组件不简单。边界case多如牛毛。

解决方案

• 首先是找出要固定元素的定位元素（定位元素的判断逻辑上面写了），然后如果定位元素是window，那么跟目前所有组件库的逻辑一样，所以没有bug，如果不是window，就要求出相对定位父元素距离可视窗口顶部的top的值
• 然后在我们原本要定位的值，比如距离顶部80px的时候固定，此时80px再减去上面说的定位父元素距离可视窗口顶部的top的值，就没有bug了

具体代码如下：

• offsetParent固定元素的定位上下文，也就是相对定位的父元素
• fixedTop是我们要触发固定的值，比如距离可视窗口顶部80px就固定

affixDom.style.top = `${isHTMLElement(offsetParent) ? (fixedTop as number) - offsetParent.getBoundingClientRect().top : fixedTop}px`;

如何找出offsetParent，也就是定位上下文

export function getContainingBlock(element: Element) {

  let currentNode = element.parentElement;

  while (currentNode) {

    if (isContainingBlock(currentNode)) return currentNode;

    currentNode = currentNode.parentElement;

  }

  return null;

}

工具方法，isContainingBlock如下：

import { isSafari } from './isSafari';



export function isContainingBlock(element: Element): boolean {

  const safari = isSafari();

  const css = getComputedStyle(element);



  // https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block

  return (

    css.transform !== 'none' ||

    css.perspective !== 'none' ||

    (css.containerType ? css.containerType !== 'normal' : false) ||

    (!safari && (css.backdropFilter ? css.backdropFilter !== 'none' : false)) ||

    (!safari && (css.filter ? css.filter !== 'none' : false)) ||

    ['transform', 'perspective', 'filter'].some((value) => (css.willChange || '').includes(value)) ||

    ['paint', 'layout', 'strict', 'content'].some((value) => (css.contain || '').includes(value))

  );

}

本文完毕，求关注，求star!!!对于react组件库感兴趣的小伙伴，欢迎加群一起交流哦！

前言

相信这几天各大互联网应用首页置灰已经接踵而至，事情缘由我就不太赘述。毫无疑问，我司从30号当晚就收到紧急需求，我们要求1号必须紧急发版，除了常规的首页支持配置的动态置灰外，我们还要求另外一个需求就是，启动图也需要支持动态配置灰功能，经过几个同事的努力，于1号当晚顺利的发版了，第二天一早便成功上线，在此记录一下实现iOS启动图动态置灰的方案心得。

方案过程

实话说，当我接到此需求时，我负责的是实现iOS启动图动态置灰，当时我不太确认是否能实现，我能想到的是马上搜百度、谷歌、掘金等看是否有现成的轮子，答案肯定是有的，分别是

• BBADynamicLaunchImage

此方案非常轻量级，只有BBADynamicLaunchImage一个类，功能也只有一个，即查找系统缓存的启动图路径，使用我们提供的UIImage替换掉。其他版本控制本非必要需求我们自己代码控制即可。最终我也是直接采用了这个方案，其他控制由我代码自己编写核心方法如下。PS：（虽然提供iOS13之前的启动图路径查找，但是经过我实测一台iOS12的设备是不生效的，只有iOS13意思机型生效）

/// 系统启动图缓存路径



+ (NSString *)launchImageCacheDirectory {



NSString *bundleID = [NSBundle mainBundle].infoDictionary[@"CFBundleIdentifier"];



NSFileManager *fm = [NSFileManager defaultManager];



// iOS13之前



NSString *cachesDirectory = [NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) firstObject];



NSString *snapshotsPath = [[cachesDirectory stringByAppendingPathComponent:@"Snapshots"] stringByAppendingPathComponent:bundleID];



if ([fm fileExistsAtPath:snapshotsPath]) {



return snapshotsPath;



}



// iOS13



NSString *libraryDirectory = [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES) firstObject];



snapshotsPath = [NSString stringWithFormat:@"%@/SplashBoard/Snapshots/%@ - {DEFAULT GROUP}", libraryDirectory, bundleID];



if ([fm fileExistsAtPath:snapshotsPath]) {



return snapshotsPath;



}



return nil;



}

• LLDynamicLaunchScreen

稍微吐槽下这个库，此库也是我一开始使用的。它也是基于BBADynamicLaunchImage做了一些拓展。比如版本控制，但是它内置的版本控制有漏洞，它只支持CFBundleShortVersionString,也就是我们俗称的大版本，如果我build号改了版本号不变岂不是有问题？（这也是我打包后不生效调试了好久才发现的问题）而且要支持动态置灰，不发版恢复原图就更加有问题。最后也是弃用了，当然这个库支持暗黑模式下的启动图，但是我本身app就是不支持的这个功能就聊胜于无了，最终该用了上边的方案，动态控制由我自己处理。

启动图如何置灰

要实现启动图和原图一模一样只是变成灰白，这里就稍微要花一点点心思了。众所周知我们现在iOS启动图都是直接用LaunchScreen这个Storyborad生成的，那我们是否能加载这个LaunchScreen，然后截取UIView的图片，之后再通过bitmap转换成一张灰白图？答案是显而易见的，代码如下。

首先我们要给LaunchScreen定义一个id,因为默认没有人去加载它，它也没有id。

代码如下：

生成启动图原图或灰白图方法，注意此方法要在主线程跑。

+ (UIImage *)createLaunchScreenImage:(BOOL)isNeedGray {



UIStoryboard *sb = [UIStoryboard storyboardWithName:@"LaunchScreen" bundle:nil];



UIViewController *vc = [sb instantiateViewControllerWithIdentifier:@"LaunchScreen"];



[vc loadViewIfNeeded];



vc.view.frame = UIScreen.mainScreen.bounds;



UIImage *image = [vc.view snapshotImage];



if (isNeedGray) {



image = [image createGrayImage];



}



return image;



}

UIView截图

func snapshotImage() -> UIImage? {



UIGraphicsBeginImageContextWithOptions(self.bounds.size, self.isOpaque, 0);



self.layer.render(in: UIGraphicsGetCurrentContext()!)



let image = UIGraphicsGetImageFromCurrentImageContext()



UIGraphicsEndImageContext()



return image



}

生成灰白图方法，由于启动图必须size匹配，所以scale那些要处理好。

-(UIImage*)createGrayImage {



int width = self.size.width * self.scale;



int height = self.size.height * self.scale;



CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceGray();



CGContextRef context =CGBitmapContextCreate(nil,



width,



height,



8,// bits per component



0,



colorSpace,



kCGBitmapByteOrderDefault);



CGColorSpaceRelease(colorSpace);



if(context ==NULL) {



return nil;



}



CGContextDrawImage(context,



CGRectMake(0,0, width, height), self.CGImage);



UIImage*grayImage = [UIImage imageWithCGImage:CGBitmapContextCreateImage(context) scale:self.scale orientation:self.imageOrientation];



CGContextRelease(context);



return grayImage;



}