如果从 13 年移动客户端大火开始算起，至今已经有八个年头了。现在移动端的形势也不需要太多的废话来描述，一句话总结就是：**“浪潮退去，谁在裸泳一看就清楚。”**我希望借助这篇文章来聊聊在我心目中，移动互联网的趋势和机会，以及我们 iOS 工程师能做哪些准备，实现自我提高。本文主观性的看法比较多，文笔也比较激进，仅供参考。
我们都知道价格会受到供需的影响，如果某项技能在市场上紧缺，那么掌握这门技能的工作者工资就会相对高一些，比如 14 年前前后能写好 UITableView 就能找到一个相对不错的工作了。在我看来，现在的移动互联网现状就是**“一个过剩，两个不足”**，我会逐个分析并试着给出一些建议。
UI 工程师过剩
这一点是我老生常谈的了，首先要注意的是避免成为 API 调用工程师，因为这些 UI 方面的知识对个人价值的增长不是线性的，如果你还记得高中数学，请回忆一下 y = ln(x) 这个函数的曲线。从零到写好 UITableView 给一个工程师带来的收益，远远不是从写好 UITableView 到写好 UIStackView 能比得上的。
就以 UIStackView 为例吧，就说它提供的功能，虽然简化了已有场景，但这个功能完全可以通过封装已有的组件来实现，相信很多大型项目都有，为什么还要费力气去兼容版本，以及再学习一个新的 API 呢？人的精力是有限的，如果你总是追着苹果的脚步，每年补 WWDC 上那些新坑和老债，那么视野就永远只能停留在 iOS 中了。
我拒绝追随 WWDC 的另一个原因是把自己的职业生涯押注在一个平台或者公司上，是极度不明智，也是极度危险的，即使这是苹果。上半年的时候我们小组招聘，我负责筛选了一批简历，其中有一位已经三十多岁，十年经验的程序员，他的简历让我感触良多。他本科毕业后就在诺基亚负责塞班系统的研发，大概相当于今天的苹果公司负责写 iOS 系统，看起来光环非常明显了，后来先后去过两家生产安卓手机的大厂，现在又申请 iOS 的程序员职位。在他的简历里，我看不到一个十年程序员该有的技术和思维深度，只有一个又一个古老名词的堆砌。因此，我衷心的建议各位读者，在你学习一个新技术以前，不妨先花十秒钟猜测一下，这个技术三年后，五年后，十年后会是什么样？猜不准没问题，如果有了明确的答案，还往坑里踩，就只能怪自己了。
当然，我并不是全盘否定 UI 的技术，毕竟程序员拿工资是因为你能为公司创造效益，所以该做的需求还是要 100% 高质量的完成，也就是说该学的还是要学。但如果是业余时间的自我提高就另说了，我的建议是找一个 UI 组件认真学习下，把官方文档读一遍，自己写个 Demo 理清楚知识脉络。我并不指望这个组件能真的帮上什么忙，但一个合格的程序员，也从来不应该只做自己会做的事。合格的程序员应该要有举一反三，快速学习的能力，所以只要找一个组件熟悉一下整个学习流程就可以了。了解一个 UIStackView 的前因后果以及如何兼容低版本是一个程序员好学的体现，但如果一个程序员只是每年学习新的控件，又不能在项目中取得较大的收益，就只能说是学习方法有问题了。
从技术角度来说，苹果的 UI 布局是我见过最落后的方式，无论是前端的 HTML 还是安卓的 XML 都要比 iOS 先进。这主要是因为把布局信息耦合进二进制代码非常不合理，而且一定程度上损失了动态化和解耦的能力。如果 iOS 的布局方案将来有较大幅度的优化，我可以断言绝对不是 Autolayout 这样的鸡肋工具，或者 Storyboard 这种傻瓜工具。相比之下我更看好一种统一的，能够跨端布局技术，比如 flexbox 规范。
#专业技能人才不足 这里的专业技能指的是移动端这个大话题中里比较垂直的知识领域，大概包含以下几个方面：
图像／视频处理
随着网络基础设施的普及，以及流量费用的大幅度降低，4G 已经全面商用了，就目前而言用户对高质量图片和视频的要求会日益增长。
由于我对这个领域并不了解，所以能够推荐的并不多，在我印象中，OpenGL 这种跨平台的引擎，计算机图形学的知识，视频编码与协议都是可以花时间研究的，现在有很多优秀的创业公司也急需这类人才。严格来说这些知识都不算移动互联网方面的知识了，所以门槛较高，但门槛这东西是个双刃剑。它会增加你的学习难度，但一旦你掌握了这门知识，门槛又会变成你个人价值的护城河。
我格外想要声明的是，CoreAnimation 这类的东西如果不是工作中强制要用，一般就别碰了，就像没人会傻到用 SpriteKit/SceneKit 去写游戏一样，这种 API 密集型，又不能跨端的库是没有前途的，真正有价值的动画一定是用一套统一的 DSL（领域特定语言）去实现，然后导出到各个平台上，所以开发者一定要多在动画的原理上下功夫，比如了解矩阵变换，线性代数这些，而不是把时间浪费在阅读官方文档上。
把事情搞定
在任何时候，一个靠谱的，能把事情搞定的工程师一定是受到欢迎的。靠谱是一个很虚的概念，我以最近的观察简单的举两个例子。
当项目比较大了以后，随着参与开发的人数越来越多，与技术无关的事情也会占据越来越大的比重。比如协调和沟通，测试，后端的人力什么时候到位，某个 Bug 如何追查复现并定位，新版本的需求哪些可以做，哪些缓一缓，能做的需求什么时候提测，什么时候灰度，什么时候正式发版？这些事情很琐碎，需要很强的责任心，而且在求职的时候比较难体现出来（除非有知名的 app 背书），但相应的好处是绩效一般会比较不错，而且在领导心目中的印象会比较好。技术不敏感的同学也可以考虑这条路线。
虽然我一向对 UI 开发很不屑，但事实是如果一个 iOS 工程师能把各个系统控件玩得很溜，而且有自己对控件的积累和封装，再了解一些性能优化方面的知识，找到一个相当满意的 iOS 职位也不会太难。如果你走的是这种传统的 iOS 开发路线，不妨问问自己，每年的 WWDC 都看完了没，移动开发的各种工具是否都能熟练使用（比如 Reveal，Charles 等），能不能熟练到任何复杂的页面，都能通过自己积累的组件在短时间内实现？然而根据我的观察，绝大多数应聘者的简历里博客都很少，更别提 Github 上面有持续迭代的代码了。这条路线的缺点是职业生涯天花板相对比较低，基本上到高级 iOS 工程师就为止了。
逆向工程
研究逆向工程的作用不仅仅是破解 app，在我看来更多是学习底层的操作系统。在开发 app 的过程中，我们使用系统提供的库，调用 API 就可以实现需求，其中的过程完全是黑盒。而逆向工程的目的就是要开盒子，利用一些工具从二进制层面入手，反过来推测应用开发者的代码和逻辑。这其中会涉及到很多 C 语言，操作系统，编译原理方面的东西**，相对来说门槛很高。逆向工程对企业对价值也很大， 因为大家都不希望自己被竞争对手一眼看穿，又对竞争对手对秘密颇感兴趣。**
小结
以上是几个我目前能想到的，可以花时间研究的专业知识。这些知识大多是自成体系的，没有较长时间的积累，很难入门。这一点非常重要，因为很多知识看起来非常专业，门槛也很高，你学习的知识是一个知识点还是一个体系，如果你学习的只是知识点， 那么它只能是整个知识树上的枝枝丫丫，边边角角；如果你学习的是知识体系，就具备了衍生知识点的能力，也就是我反复强调的举一反三的能力。
上面举的三个例子都是我认为不容易遭到时间的淘汰，比较值得研究的话题。在这些领域上的投入可以理解为线性的，也就是一分耕耘，一分收获。