金九银十带来的不止是更多的招聘岗位，同时带来更多的可能是的职场中年危机！！！

Posted 2021-07-08 datian1234

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了金九银十带来的不止是更多的招聘岗位，同时带来更多的可能是的职场中年危机！！！相关的知识，希望对你有一定的参考价值。

前言

大家都知道每年的九月和十月都是互联网大厂疯狂招人的黄金期，也就是程序员的黄金跳槽器，所以被称为金九银十。首先每年的九月，十月是大量的毕业生涌进社会的一大波浪潮，大厂们会秉着培养新鲜血液的原则来储备人才。然而这个时间其实也是一个大量裁员的时机，一年已经过去了2/3，回想起老员工们一年的劳动成功，并没有给企业带来任何实质性的收益，这个时候老总们就会想着办法淘汰那些技术菜的，招收新的员工。谁会有理由拒绝一个拥有差不多技术，但是工资还要低，还有发展前景的年轻人的面试要求呢？

中年程序员面临的问题

1.来自年轻人的竟争，现在的年轻人，高学历，高智商，高产出，刚毕业的应届生和当年的程序员刚毕业的时候相比，强了大概有二倍吧。但待遇不及老人，此时，老人的价值何在？企业不养闲人，当你的产出没有年轻人高的时候，怎么办？

2.精力和体力的问题，人到中年，体力，精力，智力都不如年轻人了，因为他们没有家庭的纷扰，但有健康的身体，更有高智商的大脑，年轻人的产出，越来越高，一边是因为家庭或体力的原因，可支配工作时间越来越少，一边是精力旺盛，老人要拿什么拼呢？

3.个人价值体现，大公司下，30多岁，想混到团队中层，要看机会和缘份，每天和年轻人完成着各种业务改动，把代码合并着，抽离出去，抽离出去，再合并在一起，产品标题上打个标，图片加个圆角，退出时邀请用户五星好评，首页弹个框等一系列的功能，显得是那么的不值一提和没有意义，个人的理想和追求是什么呢？

如何破解危机

很多企业在招募人才时，明确规定年龄在 35 岁以下。如果你的年龄到了 35 岁却还在通过招聘网站投递简历不断跳槽的话，你就应该反省一下自己到底哪里做错了。

当然，根据我们的实践咨询经验来看，如果你真到了 35 岁甚至更高的年龄才去思考这个问题的时候，很有可能这个问题你已经无力解决了，很多现实的困难会让你有心无力，束手无策。

为了不让你 35 岁以后的职业生涯变得一塌糊涂，你至少应该在 30 岁就确立明确的目标，并利用 5 年的时间去追赶。

这可能是你成长的最后的最佳时机。错过了这个时机，你已不再年轻，社会也不会再以包容的心态去原谅你的年少轻狂。否则，你多走一步错路，就必定要在以后以十倍的代价补回来。

谈谈中年程序员未来的发展

35岁之后，你可能身为人夫、人父，同时还有老人要照顾。技术行业不断变化、更新，随着年龄增长，你的编程灵活性会下降，接受新技术的能力确实不如年轻人，这些都可能发生，都很正常。
但如果你如果从现在开始努力，35岁的时候，你已经拥有10年的行业从业经验，无论是在IT行业继续发展，还是像李开复一样进行投资，转战其他行业，都有很多选择。

当然，也一定会有概率，有一部分人被时代所淘汰，或者没有青春的时候那么“吃香”，这种情况就是这部分人，像流水线上的工人，完全没有思考和成长，随时可能会被替代，但这种情况每个行业都有，我反而认为，程序员行业会是概率很低的。
有没有“青春饭”这个概念，关键在于，你是不是在吃“青春"这碗饭！只要你从现在开始努力提升自己的技能，自然有路一直给你走下去。

对于现在的Android及移动互联网来说，我们需要掌握的技术，我做了一个清单：

泛型原理丶反射原理丶Java虚拟机原理丶线程池原理丶
注解原理丶注解原理丶序列化
Activity知识体系（Activity的生命周期丶Activity的任务栈丶Activity的启动模式丶View源码丶Fragment内核相关丶service原理等）
代码框架结构优化（数据结构丶排序算法丶设计模式）
APP性能优化（用户体验优化丶适配丶代码调优）
热修复丶热升级丶Hook技术丶IOC架构设计
NDK（c编程丶C++丶JNI丶LINUX）
如何提高开发效率？
MVC丶MVP丶MVVM
微信小程序
Hybrid
Flutter

1. android架构设计模式

MVC架构设计模式：MVC全名是Model View Controller，是模型(model)-视图(view)-控制器(controller)的缩写。
MVP架构设计模式：MVC全名是Model View Persenter，MVP由MVC演变而来，是现在主流的开发模式。
MVVM架构设计模式：MVVM全名是Model-View-ViewModel，它本质上就是MVC的改进版。

各种模型的**主要目的**都是是分离视图（View）和模型（Model），即将UI界面显示和业务逻辑进行分离。

1.1 架构设计模式-MVC

(1) 定义：

在android开发过程中，比较流行的开发框架曾经采用的是MVC框架模式。

M（Model）层：实体模型，处理业务逻辑。如：数据库操作，网络操作，I/O操作，复杂操作和耗时任务等。
V（View）层：处理数据显示。在Android开发中，它一般对应着xml布局文件。
C（Controller）层：处理用户交互。在Android开发中，它一般对应着Activity/Feagment。android中主要通过activity处理用户交互和业务逻辑，接受用户的输入并调用Model和View去完成用户的需求。

(2) 特点

低耦合
可重用易拓展
模块职责划分明确

(3) 实例

android本身的设计结构符合 MVC 模式。

(4) MVC优缺点

MVC的优点：MVC模式通过Controller来掌控全局，同时将View展示和Model的变化分离开
MVC也有局限性：

View层对应xml布局文件能做的事情非常有限，所以需要把大部分View相关的操作移到Controller层的activity中。导致activity相当于充当了2个角色(View层和Controller层)，不仅要处理业务逻辑，还要操作UI。一旦一个页面的业务繁多复杂的话，activity的代码就会越来越臃肿和复杂。

1.2 架构设计模式-MVP

MVP是从经典的MVC模式演变而来，它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。在Android开发中，MVP的具体实现流程是当Presenter接收到View的请求，便从Model层获取数据，将数据进行处理。处理好的数据再通过View层的接口回调给Activity或Fragment。这样MVP能够让Activity或Fragment成为真正的View，只做与UI相关的事而不处理其他业务流程。

(1) 定义

M（Model）层：实体模型，处理业务逻辑。如：数据库操作，网络操作，I/O操作，复杂操作和耗时任务等。
V（View）层：负责View的绘制以及与用户交互。在Android开发中，它一般对应着xml布局文件和Activity/Fragment。
P（Presenter）层：负责完成Model层和View层间的数据交互和业务逻辑。

(2) 实例

(3) MVC和MVP的区别

MVP中的View并不直接使用Model，它们之间的通信是通过Presenter来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不通过Controller

MVC和MVP的最大区别：MVC的Model层和View层能够直接交互；MVP的Model层和View层不能直接交互，需通过Presenter层来进行交互。
Activity职责不同：Activity在MVC中属于Controller层，在MVP中属于View层，这是MVC和MVP很主要的一个区别。可以说Android从MVC转向MVP开发也主要是优化Activity的代码，避免Activity的代码臃肿庞大。
View层不同：MVC的View层指的是XML布局文件（或用Java自定义的View）；MVP的View层是Activity（或Fragment）
控制层不同：MVC的控制层是Activity（或Fragment）；MVP的控制层是Presenter，里面没有很多的实际东西，主要负责Model层和View层的交互。

(4) MVP优缺点

MVP的优点如下:

模型与视图完全分离，我们可以修改视图而不影响模型；项目代码结构清晰，一看就知道什么类干什么事情；我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑，这个特性非常的有用，因为视图的变化总是比模型的变化更频繁；协同工作(例如在设计师没出图之前可以先写一些业务逻辑代码)

MVP也有不足之处:

接口过多，一定程度影响了编码效率。一定程度上导致Presenter的代码量过大。
为了降低Presenter中业务繁多的问题，Google又推出了MVVM，试图通过数据驱动来减少Presenter的代码量。

1.3 架构设计模式-MVVM

(1) 定义

M（Model）层：仍然是实体模型（但是不同于之前定义的Model层），主要负责数据获取、存储和变化，提供数据接口供 ViewModel 层调用。
V（View）层：对应Activity/Feagment 和xml布局文件，负责View的绘制以及与用户交互
说明：View层仅能操作UI（数据绑定来实现 UI 更新）；不能做任何和业务逻辑有关的数据操作
VM（ViewModel）层：负责完成Model层和View层间的数据交互和业务逻辑
说明：ViewModel层仅能做和业务逻辑有关的数据操作；不能做UI相关的操作

2. android插件化

插件化来由：随着业务的增多，业务逻辑代码越来越多，apk包也逐渐增大，不利于维护和升级。通过插件化开发可将功能模块解耦，不同的维护团队仅维护某模块的业务，同时当app升级时可仅对某功能模块进行升级而不需整体升级。

2.1 插件化要解决的问题—如何动态加载apk

(1) android类加载器及区别

类加载器作用：java字节码通过类加载器加载到java虚拟器。

PathClassLoader：仅能加载文件目录下的apk。
DexClassLoader：可以加载apk文件中的字节码(从dex实体jar文件中加载java字节码)。主要用于动态加载和代码热更新等。

(2)反射： java中的反射使我们在运行时获得这个类的属性、方法和class内部的信息机制，最重要的是我们可以在运行时实例化这个对象调用方法，这也是java反射的最大优点。
(3) 实现动态加载apk

什么是动态加载apk：android中有一个速度程序会主动到指定的sd卡中去加载apk，并通过代理activity去执行。

实现：需要一个代理activity去执行apk中的activity，主要通过反射去获得它的属性和方法，从而进行apk的调用。
实现原理：类加载器（加载类）+反射（获取属性和方法）+动态代理（执行）

如：

2.2 插件化要解决的问题—如何加载资源

通过android中ServiceManager类的隐藏方法来加载资源。

2.3 插件化要解决的问题—如何加载代码

使用java中的类加载机制，但是android和java也有一点不一样，android比java多了组件和生命周期，所以并不是类加载进来就能使用(不能管理生命周期)。

3. Android热更新(在线热修复技术)

(1) 热更新流程

检测到线上严重的crash（参考：app检测crash并发送日志到服务器的实现）
线上版本拉出bugfix分支并在分支上修复问题
jenkins构建及生成补丁
app在合适时机通过推送或主动拉取补丁文件
将bugfix代码合并到master上

(2) 热更新主流框架

Dexposed
AndFix
NuWa

(3) 热更新原理

Android类加载机制（类加载器）

PathClassLoader类：用来加载系统类
DexClassLoader：用来加载dex文件、jar文件包和apk包等

热修复机制（原理）

原理：在ClassLoader中创建一个dexElements数组，根据线上的crash定位找到对应的类文件，然后把这个类文件修复完成后打包成一个dex文件并放到dexElements数组的最前方。那么当ClassLoader遍历dexElements数组（加载数组中的dex文件）时，因为ClassLoader会优先加载最前方的dex文件，所以不会加载线上有crash的dex文件，只会加载修复完的dex文件，从而完成热修复过程。

4. Android进程保活

(1) 进程保活概念

进程保活：让进程在内存中永远存在且无法杀死，就算被杀死也能保活。
进程被杀死的原因：人为地调用kill；被第三方安全软件杀死。
进程保活并非是一种流氓手段，在很多场景下我们需要一个常驻进程来为用户提供服务，如：

接收屏幕开关的系统广播：因为广播接收者不支持静态注册，必须在进程中动态注册广播接收者来接收，如果没有常驻进程，那么锁屏应用无法为用户正常提供服务。
定位服务：需要在后台维护一个长连接，以便及时地将信息（推送的信息/定位信息等）传达给用户。

缺点：进程保活在内存，不管如何优化，或多或少都会增加性能的开销。所以需在进程保活和内存消耗之间寻找平衡点来为用户进程保活。

(2) android进程优先级和回收策略

android进程优先级：前台进程 > 可见进程 > 服务进程 > 后台进程 > 空进程
android进程的回收策略：主要依靠LMK ( Low Memory Killer )机制来完成。LMK机制通过 oom_adj 这个阀值来判断进程的优先级，oom_adj 的值越高，优先级越低，越容易被杀死。
拓展：LMK ( Low Memory Killer ) 机制基于Linux的OOM（Out Of Memery）机制，通过一些比较复杂的评分机制，对进程进行打分，将分数高的进程判定为bad进程，杀死并释放内存。LMS机制和OOM机制的不同之处在于：OOM只有当系统内存不足时才会启动检查，而LMS机制是定时进行检查。

(3) android进程保活方案

利用系统广播拉活

在发生系统事件时，系统会发出相对响应的广播(常用的广播事件如：开机、网络状态变化、文件或sd卡的卸载等)，我们可以在mainfest.xml文件中静态注册广播监听器
缺点（无法拉活的情形）：广播接收者被管理软件或系统软件通过自启动管理等功能禁用的场景下是无法接受广播的，从而无法自启动进行系统拉活；系统广播事件是不可控制的，只有在发生事件时才能进行拉活，无法保证进程被杀死后立即被拉活。

利用系统Service机制拉活

将Service中的onStartCommand()回调方法的返回值设为START_STICKY，就可以利用系统机制在Service挂掉后自动拉活。
拓展：onStartCommand()的返回值表明当Service由于系统内存不足而被系统杀掉之后，在未来的某个时间段内当系统内存足够的情况下，系统会尝试创建这个Service，一旦创建成功就又会回调onStartCommand()方法。
缺点（无法拉活的情形）：Service第一次被异常杀死后会在5s内重启，第二次会在10s内重启，第三次会在20s内重启，若Service在短时间内被杀死的次数超过3次以上系统就会不惊醒拉活；进程被取得root权限的管理工具或系统工具通过强制stop时，通过Service机制无法重启进程。

利用Native进程拉活

思想：利用Linux中的fork机制创建一个Native进程，在Native进程可以监控主进程的存活，当主进程挂掉之后，Native进程可以立即对主进程进行拉活。
在Native进程中如何监听主进程被杀死：可在Native进程中通过死循环或定时器，轮询地判断主进程被杀死，但是此方案会耗时耗资源；在主线程中创建一个监控文件，并且在主进程中持有文件锁，在拉活进程启动后申请文件锁将会被阻塞，一旦成功获取到锁说明主进程挂掉了。
如何在Native进程中拉活主进程：主要通过一个am命令即可拉活。
说明：android5.0后系统对Native进程加强了管理，利用Native进程拉活的方式已失效。

利用JobScheduler机制拉活

说明：android在5.0后提供了JobScheduler接口，这个接口能够监听主进程的存活，然后拉活进程。

利用账号同步机制拉活

说明：android系统的账号同步机制会定期同步账号信息，这个方案主要是利用账号同步机制进行进程拉活。不过最新的android版本对账号同步机制做了改动，该方法可能不再生效。

最后

对我们开发者来说，一定要打好基础，随时准备战斗，要把自己的技术做精做深。竞争越激烈，产品质量与留存就变得更加重要，我们进入了技术赋能业务的时代，所以提升自己才能面对一切危机。

这里给大家分享一些资料，有需要的可以【点击这里直达免费获取方式】。

一、Android部分：

1.第五大组件FragmentAndroid知识体系总结之Android部分之Fragment篇
2.对话框 & 弹框 & 通知 & 悬浮窗之 WMS 源码篇
3.Android UI控件篇高级自定义View, 主要是原理和手写实现
4.Android 系统架构篇
5.Android 通信篇
6.Android Framework 源码篇
7.Android 网络编程篇
8.原生音视频图片开发篇[非JNI]
9.Android 特殊知识点【不知道如何分类的知识点】
10.Android 必须掌握的轮子原理篇
11.Android 架构篇
12.Android 优化篇
13.Android 职业方向篇(有正确的职业方向，才能不浪费自己的职业生涯)
14.Android 工作工具篇
15.Android 工作必备技能篇
16.Android 跨平台开发篇

二、Java部分：

1.JVM
2.static
3.final
4.String. StringBuffer. StringBuilder
5.异常处理
6.内部类
7.多态
8.抽象和接口
9.集合框架
10.反射
11.单例
12.多线程
13.volatile
14.synchronized
15.Lock
16.引用类型
17.动态代理
18.元注解