2019-03-20 iOS View的生命周期

看到网络层请求的时候，都比较关注什么时候取消请求，什么时候获取数据，又在什么时候去展示数据。这是很多开发者都比较关注的话题。在这里简单分享一下。

网上的资料很多，我们见到的最多的都是view的生命周期从一开始到最后销毁。但是很少有页面间的view生命周期是什么流程的。了解view的生命周期有助于我们选择更加合适的时机去进行view的 *** 作和网络的请求。

View 生命周期

第一个 ViewController 第二个SViewController 第三个TViewController

View的展示及销毁情况

第一个就是

initialize -->init --> viewDidLoad-->viewWillAppear-->viewWillLayoutSubviews-->viewDidLayoutSubviews-->viewDidAppear

然后进入第二个VC

initialize -->init --> viewDidLoad-->此时第一个VC viewWillDisappear-->viewWillAppear-->viewWillLayoutSubviews-->viewDidLayoutSubviews-->此时第一个VC viewDidDisappear-->viewDidAppear

具体的Log如下：

Method: +[SViewController initialize]

Method: -[SViewController init]

Method: -[SViewController viewDidLoad]

Method: -[ViewController viewWillDisappear:]

Method: -[SViewController viewWillAppear:]

Method: -[SViewController viewWillLayoutSubviews]

Method: -[SViewController viewDidLayoutSubviews]

Method: -[ViewController viewDidDisappear:]

Method: -[SViewController viewDidAppear:]

然后进入第三个VC

initialize -->init --> viewDidLoad-->此时第二个VC viewWillDisappear-->viewWillAppear-->viewWillLayoutSubviews-->viewDidLayoutSubviews-->此时第二个VC viewDidDisappear-->viewDidAppear

Method: +[TViewController initialize]

Method: -[TViewController init]

Method: -[TViewController viewDidLoad]

Method: -[SViewController viewWillDisappear:]

Method: -[TViewController viewWillAppear:]

Method: -[TViewController viewWillLayoutSubviews]

Method: -[TViewController viewDidLayoutSubviews]

Method: -[SViewController viewDidDisappear:]

Method: -[TViewController viewDidAppear:]

上面是View的开始，下面看一下view的依次释放。

返回上一个VC

首先是第三个VC（TViewController）调用viewWillDisappear

然后第二个VC（SViewController）即将展示view（viewWillAppear）

在第二个即将展示之后，第三个VC视图消失完成viewDidDisappear

在第三个消失之后，第二个VC展示完成viewDidAppear

最后进行第三个VC dealloc

Method: -[TViewController viewWillDisappear:]

Method: -[SViewController viewWillAppear:]

Method: -[TViewController viewDidDisappear:]

Method: -[SViewController viewDidAppear:]

Method: -[TViewController dealloc]

返回第一个VC

首先是第二个VC（SViewController）调用viewWillDisappear

然后第一个VC（ViewController）即将展示view（viewWillAppear）

在第一个即将展示之后，第二个VC视图消失完成viewDidDisappear

在第二个消失之后，第一个VC展示完成viewDidAppear

最后进行第二个VC dealloc

Method: -[SViewController viewWillDisappear:]

Method: -[ViewController viewWillAppear:]

Method: -[SViewController viewDidDisappear:]

Method: -[ViewController viewDidAppear:]

Method: -[SViewController dealloc]

最后再进行一次Push *** 作

我们再观察一下View的生命周期情况

Push

Method: -[SViewController init]

Method: -[SViewController viewDidLoad]

Method: -[ViewController viewWillDisappear:]

Method: -[SViewController viewWillAppear:]

Method: -[SViewController viewWillLayoutSubviews]

Method: -[SViewController viewDidLayoutSubviews]

Method: -[ViewController viewDidDisappear:]

Method: -[SViewController viewDidAppear:]

到此，差不多我们都有一个整体认识了，对view的生命周期有一个更加清晰的了解。Demo就不传了，很简单的，自己写一下方法，从新定义一下log什么都看到了。

有什么错误的地方欢迎各位大大指点与批评

在开发项目当中，由于有第三方SDK的需求又或者是项目服务端要求需要更改系统User-Agent的情况，应用中，对于一些H5需要使用添加个性化信息后的User-Agent，而另一些H5不希望使用更改后的User-Agent，所以本文将从H5应用中简单介绍一下。

User-Agent中文名为用户代理，简称UA，它是一个特殊的字符串头，是的服务器能够识别客户使用的 *** 作系统及版本，CPU类型，浏览器及版本，浏览器语言等。

这里我贴一下我自己手机的User-Agent：

苹果即将在2020年12月31号全面禁止使用UIWebView，所以本文仅对UIWebView获取User-Agent做简单介绍

UIWebView为同步的方式，可以直接获取到User-Agent。

WKWebView获取User-Agent为异步方式，所以如果需要在应用启动就要使用User-Agent的话，需要做好相应的处理。

获取到系统的User-Agent（通过上述方法获取到的UA都是系统最新的，假如在某一个刻修改过，这里获取到的也是修改过的UA，除非重新启动程序），进行字符串 *** 作添加上自定义信息然后重新写进系统，这样就达到了更改默认UA的目的。

修改全局系统User-Agent的生命周期会随着程序的生命周期，程序一旦杀死更改的User-Agent也会随即消失，如果希望保持更改User-Agent，则需要在每次应用启动时重新更改系统User-Agent

修改局部User-Agent的生命周期仅限在当前的WebView的生命周期内，一旦WebView销毁，更改的User-Agent信息就会随机消失。

由于苹果即将全面废弃UIWebView，以下总结仅针对WKWebView。

头一次写文章，就问你简单干练不，少点啰嗦，多点干货，是我们不懈努力奋斗的目标，同时如有疏漏或错误，欢迎指正，也欢迎大家点赞鼓励，我将会继续分享更多iOS 开发相关干货。

最近在做自己的framework静态库，需要用到支付宝和微信支付，支付回调又是在Appdelegate中拿到 所以想找一种替代或者说捕获Appdelegate声明周期的方法，苦寻之后发现有大神处理过类似的事情，所以就尝试了一下，首先感谢大神的文章。

文章地址：( >

第一阶段：假想阶段

在本阶段需要反复验证这个假想的可行性，成本，收益；如果行业内已有类似的可参考的软件那么就会简单一些，如果没有就只能利用一些模拟和预测的方法来帮忙了。在假想确定要实施的时候一定要组织一次启动会议，参会人员包括所有的利益相关方，由总裁级别的领导宣布这个项目的正式启动；目的就是给大家一个前进的方向和希望各方通力合作。

第二阶段：需求开发阶段

软件的5个特性中的易用性在本阶段要重点考虑。本阶段可能是争议最多的阶段，对于同一种业务功能需求会有多种解决方案，每一种解决方案会有一套详细的软件功能描述，不同的解决方案所需要的成本一定是不一样的，易用性也会不一样。如果站在业务部门的角度一定是易用性越好越满意，但是站在信息部门的角度如果成本超出了预算就不得不追加预算，如果不能批准就不得不和业务部门反复探讨协商了。信息部门各个方面的项目负责人一定要参与到这个阶段的讨论中，如果在某个方面的成本超出了预算一定要及时提出，包括开发方面，测试方面，硬件方面。通常见一些公司只有一个项目经理或者销售人员代表信息部门参与到这个阶段的讨论中，接受了很多成本远超出预算的业务需求，殊不知这一个人怎能精通各个方面，怎能准确地计算出成本。不知这些公司的上层领导们是怎样想的。如果是一个乙方公司这样不专业的做法通常的结果就是亏本买卖，唯一的解决办法就是不断压榨一线的技术人员。在国内这种不正常的现象很普遍。作为一个信息行业的从业人员真希望这种现象会尽快好转，多给技术人员一些尊重和成长的机会，最终形成良性循环。

通常在这个阶段一线的技术人员不会参与进来，对于参与的技术人员负责人要求比较高，他要熟悉公司的现有技术架构，使用或者复用时的成本；具有较强的沟通协调能力；对于公司财务部门，预算部门，采购部门的工作流程比较熟悉；所有的素质要求都是为了能够深刻理解和把握开篇提到的那个三角形标示出来的三个要素和高质量的标准。

站在整个项目的负责人的角度看平衡各方利害通常是很有挑战性的任务，作者曾经参加过竞越公司开办的一门叫做思维技术的课程，其中提到过从一个问题的多个解决方案中选出最适合各个利益相关方的的方法论。作者认为完全可以把这个方法论使用在本阶段争议比较多的焦点上。

如果本阶段没有争议是不正常的现象，本阶段的争议越多后面阶段的争议相对就少，站在整个项目的角度看成功率就相对高，总成本就相对低。

第三阶段：设计阶段

在上一个阶段的工作做得足够充分之后本阶段的工作才更加有意义和价值。本阶段的工作至关重要，承上启下。

软件方面：作者主张需求开发阶段参与的技术负责人，设计阶段的负责人，实现阶段的负责人，以及软件在运行期间的第三层运维支持负责人是同一个人。这四个负责人可以分开，但是要保证下一个阶段的负责人能够充分理解上一个阶段负责人的工作输出的想法并且是认可的。如果四个责任人分开会面临以下几个管理问题：

1由于上一个阶段的负责人并不继续向下负责，所以可能出现不认真或者输出结果不达标的问题；下一个阶段的负责人可能会出现同样的问题，以至于问题一直留到最后解决，甚至于无法解决，成本高到远远超出预算。

2知识传递的问题，如果下一个阶段的负责人不能理解上一个阶段的负责人的理念，那么就需要两位负责人在一起充分沟通达成共识，但是如果两位负责人不能达成共识又会引起另外的问题。

但是如果四个负责人都是同一个人，也许有人会质疑说一个人的精力有限，对于一个大项目来说一个人无法胜任。在这里作者必须声明作者是个敏捷开发主义者，实际工作过程中通常都是一个月或者两个月发布一次版本，测试通过就上线运行。这样一个人的精力有限问题就解决了，实际上也就是把在开篇提到的那个三角形中的范围因素设定为正好适合一个负责人能够胜任的界限。这种做法最大的好处不言而喻，项目成功率高，风险度低，也可以尽快实现软件的价值-为业务服务。也许还有人会质疑如果每一次发布的版本的新增功能太少，在架构设计方面可能会有偏差，会需要不断重新设计架构。作者一直以来的理解是软件的架构和软件的源代码是可以分开考虑的。举个形象的例子就是架构和源代码的关系就像书架和书的关系，可以在开始就准备一个大书架，然后一本一本添加书籍，很长时间都不需要换书架。如果开始准备的是一个小书架，书籍很快就会把书架填满，这时一个小书架就不够用了，解决办法可以增加一个小书架，也可以换成一个大书架。增加一个小书架就相当于增加一个子系统，换成一个大书架就相当于重新设计架构，然后增加新的模块。但是作者不能确定在开始是用一个小书架好还是用一个大书架好，如果一定要给一个观点，作者主张把书架设计成可以由一个人就能够灵活添加或者减少书架体积的模式。这时架构设计们的价值就明显地展示出来了。放书的工作就相对简单多了。

硬件方面和测试方面的道理应该是类似的。

第四阶段：实现阶段

有了质量标准，有了设计方案，接下来的工作就是加工实现了。在实现的过程中要不断检查质量是否达标，是否是按照设计方案来实现的。如果这个阶段的负责人是设计阶段的负责人和将来的第三层运维支持负责人，那么这两项检查工作会很顺利。软件方面一定要有一个源代码管理工具。硬件方面一定要有一个配置管理工具。

第五阶段：质量检查阶段

实现阶段的质量检查属于内检，本阶段的质量检查属于外检，换成专业的质量检查人员从另外的角度看问题，看是否能够达到质量标准。作者主张需求开发阶段参与的技术负责人，设计阶段的负责人，质量检查阶段的负责人和运维期间的重复质量检查负责人都由同一个人来担当。

本阶段还面临一个管理问题就是质量检查人员和开发人员之间的沟通问题，所以缺陷管理工具和完善的质量报告是很必要的。对于软件上线运行后出现的事故，调查事故原因如果是一个未发现的软件缺陷，如果一定要有惩罚措施，作者主张开发方面负责承担60%的责任，质量检查方面负责40%的责任。作者不主张奖惩措施，主张主人翁精神的培养。因为很多时候功与过实在是难以划定清楚，必然会引起不公平现象的出现；但是让大家明白公司业绩好了，奖金就会多，福利就会提升以及公司存在个人的工作就会存在这样的道理却很容易。但是主人翁精神的培养是个太过高级的话题，超出了作者的工作经历所覆盖的范围，只是有一点深刻体会就是公司要给予员工家的感觉，只要是一如既往全心全意为公司服务，那么公司就没有抛弃这位家人的理由，每年工资的提升至少不少于通货膨胀率。作者认为这样的家人应该会有比较强的主人翁精神的。

第六阶段：部署阶段

这个阶段实现了软件和硬件的结合。作者能够提到的几点就是：

1本阶段可以使用自动化部署工具。

2可以把软件的部署分为应用程序层和数据库层。

3如果使用的是Windows服务器和域管理，应用程序到数据库之间的连接一定要使用集成身份验证。

4应用程序池的账号一定要使用服务账号，密码要使用密码管理工具。

5服务账号只能用在应用程序池用来连接应用程序和数据库，不能远程登录服务器和使用在连接数据库的客户端软件上。

6如果不是域管理能够做到的，那么所有的密码都应该使用加密功能。

随着移动互联网流量红利的逐渐退去，iOS程序员正在面临开发岗位增速下降的现实问题，一方面App开发的热度在下降，另一方面大型互联网平台相继推出了自己的小程序生态，在这些因素的综合影响下，iOS程序员的岗位竞争压力将进一步加剧。

作为iOS程序员来说，如果想在技术研发的道路上走得更远，可以从以下几个方面入手：

第一：丰富自身的知识结构。 在当前大数据以及产业互联网的推动下，软件开发的功能边界在不断得到拓展，同时由于大量的互联网公司开始采用数据驱动的运营方式，所以开发团队小型化的趋势也比较明显，这就要求程序员要具备更丰富的知识结构，以适应不同的开发角色。iOS程序员可以进一步从岗位任务开始进行知识结构的拓展，比如进一步丰富前端开发知识就是不错的选择，iOS程序员也完全可以走全栈开发路线。

第二：跳出iOS的生态圈。 iOS的生态圈相对来说还是比较封闭的，而且iOS程序员自身可以发挥的空间也相对有限，主要原因是系统的封闭性所导致的。如果想综合提升自身的研发能力，可以考虑跳出iOS的生态圈。

第三：走研发级路线。 iOS程序员也完全可以走研发级路线，走研发级路线需要做好三件事，其一是选择一个主攻方向；其二是有扎实的基础知识储备；其三是能够不断完成岗位升级，从而获得更多的资源整合渠道。不少应用级程序员在发展的过程中会遇到较大的上升瓶颈，通过读研来完成岗位升级也是一个比较常见的选择。

如果有互联网、大数据、人工智能等方面的问题，或者是考研方面的问题，都可以在评论区留言！

微信适配夜间模式了吗？这就是例子，强者话语权，ios先天的系统优势就是一个市场的锚点，微信知道自己的命根子在哪，为硬件设备提供极致 *** 作的工具，例如Metal，无可匹敌，再说ios系统核心的源代码，与高端服务器os unix一脉相承，又有进一步的嵌入式 *** 作，核心api专业打磨，绝对不是开源系统能比的量级，说白了每个环节都是钱砸出来的，靠的都是工匠精神，核心源码是任何一个程序员的宝藏，不要认为玩过几个跨平台根本不考虑性能的js小技术就明白了一切，只要去过Google开发者大会的就知道，看看安卓程序员手里吃饭的家伙是啥，mac，顶上的叶子再多也要靠下面的根，乔布斯，一骑绝尘

去开发华为系统的APP，动作要快

转后端 Java PHP go py都学一波

我干过大概一年的iOS开发，后来又转回java了，说句实话，iOS对开发者确实友好，一切都很不错，开发工作也很愉快，但是后来工作不太好找，而且iOS开发的发展深度没有java深，java深入不仅仅是curd，还有架构、框架、微服务、分布式 等等。而且java到架构之后，薪资也比iOS要高很多，不过我不建议你学我，除非你有毅力学习java，因为我除了有iOS开发经验之外，还有五年的java经验，说转也就转了。

作为IT行业的从事多年的程序狗，我来解答下您的这个问题。

2015年到2017年可能是IOS最热的一段时间，大量的软件开发人员投入IOS的市场。现今随着苹果公司的销量不断受挫。IOS的市场也是不温不火。

IOS开发程序员，其实可以尝试这跳出这个生态舒适圈，软件这个行业是多向选择的，软件的开发思想、程序的设计思想都是大同小异的。对于一个精深IOS开发人员来说，对于别的语言多少都会掌握一些，这对于您跳出IOS的圈也是一大帮助。毕竟Java、Python现在是市场上的主流语言。

另一个方面就是很多资深程序员选择的，进入深层次领域的学习。走研发级的一些路线。研发级软件研发的职位生命周期长。工作压力会比程序员小很多，很适合大龄程序员的选择。

或者就是选择自己的一个主攻方向，做这个方向的专家，这也不失为一种选择。丰富自身的知识结构，向着全栈开发工程师不断的前进。

或者可以尝试这转行管理层，做一些技术经理、技术总监。当然任何一种选择都需要您结合自身的实际情况去抉择。谨慎考虑、然后在做选择。

希望回答对您有所帮助。

我本人从事多年互联网Java开发，感兴趣的朋友可以关注私聊，共同努力，共同进步。

谢谢！

我是8年iOS开发从业者，结合我自身情况以及我自己的职业规划，希望能够帮到你。

焦虑 今年已经三十岁了，对于iOS的现状和未来也时常感到焦虑，大龄程序员未来的出路在哪，我也会迷茫。

市场需求 移动开发需要iOS，安卓两端一起开发，耗费的时间成本是企业会考虑的，再加上html5、小程序、各种跨端方案的出现，市场对原生开发需求更少了。

案例 再分享一个之前做主管时我招聘C++开发的一个经历，杭州C++需求量不大，但是这位应聘者能力过硬，最终进了华为。

我们应该怎么做 上面的案例也印证了只要自身技术过硬，只要市场还有需求，过多的担心和焦虑是没有必要的，把大量的时间花在 探索 未来方向，不如沉下心来学习技术，努力提高自己，成为不可替代的人才。其实应对焦虑最好的方法是行动，目前市场更需要的是高端人才，只要有岗位需求，把自身能力提高上去之后，现在所担忧的问题都会迎刃而解。

希望我的回答对你有帮助，随时欢迎留言反馈。

flutter欢迎你

转其他语言，或者自己独立开发

我鼓捣flutter去了

以上就是关于2019-03-20 iOS View的生命周期全部的内容，包括:2019-03-20 iOS View的生命周期、iOS 正确的修改User-Agent、iOS SDK HOOK Appdelegate中的生命周期等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！