越来越多的人在提“移动端的下半场”、“Android开发的焦虑”之类的，也有人在喊“技术天天在变，学也学不完”，“昨天Kotlin今天Flutter”。其实我却认为，如果你技术达到了一定程度，你无需太过在意这些。
移动端真正进入下半场了吗？于我看来并没有，最多说“Android技术的探索”进入了下半场，而整个市场还是乐观的。以前是BAT的天下，而近两年出来越来越多的独角兽：头条、抖音、拼多多、快手、小猿搜题等，这些公司的业务都在移动端上，他们需要招聘更多的移动端人才。如果真要说下半场，只能说很多小型创业公司在退出市场，这确实会导致很多入门工程师失业，但这也说明了这个行业在更加规范。
而且，对于Android工程师而言，这更是个好的时代。互联网下沉，那么下沉市场里的用户是使用Android多还是IOS多，大家都清楚。
那么，对于工程师而言需要做什么才能存活呢？很简单，要么转行，要么提高。我相信，一个技术不错的工程师，不但无需焦虑，而且在这个时代，能够拥有稳定的职业生涯和丰厚的收入。
要说下半场，我更愿意说是“Android技术的下半场”，随着这几年大量的工程师和公司投入研发，Android技术已经从最早的简单页面，到越来越复杂的交互，再到动态化、插件化等新技术和黑科技，这个领域的深度在不断加深。
如果想成为优秀、不担心淘汰的工程师，绝不是一味跟风新技术，今天学Kotlin、明天学Flutter，疲于奔命；而应该持续努力去完善自己的知识体系，保持一定的技术深度。
因此，本专栏希望在大家做UI、界面开发之余，分享一些Android架构方面的知识和技能。
希望且相信这些技能能够让读者真正摆脱技术焦虑，最终找到自己的方向和竞争力。
有的同学会问，我平常都在写业务代码、写页面、调用SDK，有必要去了解架构吗？答案很简单，业务是表，架构是里。变化万千的业务背后都是大同小异的架构。时代更迭，业务变迁，理解架构的技术人员可以处变不惊，而非疲于奔命。
因此，本人建议业务同学在繁重的业务开发之余，可以多去研究一些底层库原理，而非停留在花式调用SDK的阶段，这会让你具备更强的技术竞争力。
不少公司的架构同学和业务同学都存在一种矛盾：架构与业务互相独立，导致输出的技术总是不能很好的满足业务需求，导致的结果是：架构同学有心无力，业务同学有苦难言。
实际上，真正好的架构是从业务中孵化出来的，而且能服务于更广阔的业务形态。
举几个例子大家就清楚了。
大家都知道阿里主营电商业务，而电商是强运营的，所以对于动态化有非常强的需求，也就是希望App尽可能像网页一样，能够随时更新页面内容。于是，阿里内部孵化出了Weex，通过远程开发部署js代码，即可实时更新页面内容；
另外，手淘App对于整个阿里集团的战略意义非常大，它不仅是盈利怪兽，而且是整个集团的流量入口（手淘DAU自2015年即达1.1亿）。这也就是阿里曾提出的“航母策略”：手淘如一座航母，集团内各种业务形态如飞猪、闲鱼、天猫等都可坐落在其上。于是，Atlas诞生了，所有App都可以轻松集成到手淘上，享受流量滋养。
类似的例子还有很多，比如大家熟知的微信，需要保证消息在任何复杂网络下都能有最高的到达率。因此微信自研了一套跨平台长连接方案，提出智能心跳方案、多种弱网应对策略如多级超时等，最终推出了Mars，保证了全国各种网络环境下的用户都能稳定的收发消息。
有些同学可能了解阿里15年提出的“大中台，小前台战略”，搭建集团数据中台、技术中台，帮助各种前台业务快跑前进；这样的技术架构和组织架构帮助阿里快速孵化出各种新的业务，比如18年初的淘宝特价版，据朋友了解整个App从启动到上线只用了短短一个多月的时间。今年，腾讯组织架构调整，担任CTO的张志东就提到：“没有能帮助到公司级的数据中台建设，我个人也蛮遗憾。”，自此腾讯也正式启动了“中台架构”建设。
所以说，不同的业务形态，能孵化出特有的架构。
架构是根，扎得越深，业务才越能开枝散叶。
闲话说了不少，下面正式谈一谈本专栏会覆盖的一些技术点吧。这些技术点会基于本人日常的工作积累，同时结合各大厂开源的技术体系，（当然对于阿里闭源的会尽量规避掉，线下可以做一些技术探讨）。
下面，我把后面专栏会覆盖到的技术点列出来，当然在写作的过程中还会逐步调整。
动态化专题
省流专题
网络专题
监控与日志专题
安全专题
