大家好呀，我是来自春天的掘金酱。
又到了一年的金三银四，想要换工作的同学自然不能错过。面试和笔试的准备也要提上日程啦。在最近的一份工作报告中显示，开发者的热门选择依然是阿里、腾讯、百度、字节跳动、美团等各个知名大厂。
当“面向对象编程”变成了“面向大厂编程”，想要进入大厂，除了专业知识准备充分之余，如果可以了解内部的技术，显然可以因地制宜，有针对性地进行准备和学习，知己知彼，方能百战不殆。同时，了解大厂的技术动向，也可以拓宽自己的技术眼界，对最新的技术保持敏感度。
掘金酱已经整理好了各个大厂的技术分享，方便你一次性阅读。
字节跳动
我们知道，Android 低版本（4.X 及以下，SDK < 21）的设备，采用的 Java 运行环境是 Dalvik 虚拟机。它相比于高版本，最大的问题就是在安装或者升级更新之后，首次冷启动的耗时漫长。这常常需要花费几十秒甚至几分钟，用户不得不面对一片黑屏，熬过这段时间才能正常使用 APP。这是非常影响用户的使用体验的。
问题根本原因就在于，安装或者升级后首次 MultiDex 花费的时间过于漫长。为了解决这个问题，我们挖掘了 Dalvik 虚拟机的底层系统机制，对 DEX 相关处理逻辑进行了重新设计，最终推出了 BoostMultiDex 方案，它能够减少 80%以上的黑屏等待时间，挽救低版本 Android 用户的升级安装体验。
传统前端业务通常会根据业务线集成在一个站点上，随着业务复杂度上升，包体积会迅速变的过大。为了适应这个变化往往需要更多的开发者、更细粒度的团队组织。分组开发时大家的模块解耦到各自完成，上线时糅合在一起运行，产生出层出不穷的分支合并、代码回滚，都会造成合作效率的骤降。这正是头条号平台在 17 年时面临的问题。
本文讨论了微前端在字节跳动的应用情况，内容主要分析了微前端具体落地的步骤和两年来的使用情况。其中分析的部分主要讲到一些实际问题和我们的应对，落地情况强调了实现的过程。特别讲到很多在我们观念里面务必要提供的微前端基石，这些方面作为基础设施几乎是使用微前端的必要和前提条件。
腾讯
本文内容整理自腾讯 Serverless 技术专家王俊杰在 GMTC 2019 深圳站的演讲。 Serverless 是当下炙手可热的技术，被认为是云计算发展的未来方向，拥有免运维、降低开发成本、按需自动扩展等诸多优点。尤其是在前端研发领域，使用 Node 开发云函数，可以让前端工程师更加专注于业务逻辑，实现全栈工程师的角色转变。
但现有的开发模式、工具、脚手架已经标准化、流程化，存量业务正在线上稳定运行，如何将 Serverless 融入到现有开发模式和工具中？如何将 Serverless 和当前的业务进行结合落地？本文将尝试给出解答。
我们了解到flutter提供一种机制，可以将native的纹理共享给flutter来进行渲染。但是，由于flutter获取native纹理的数据类型是CVPixelBuffer，导致native纹理需要经过GPU->CPU->GPU的转换过程消耗额外性能，这对于需要实时渲染的音视频类需求，是不可接受的。
闲鱼这边的解决方案是修改了flutter engine的代码，将flutter的gl环境和native的gl环境通过ShareGroup来联通，避免2个环境的纹理传递还要去cpu内存绕一圈。此方案能够解决内存拷贝的性能问题，但暴露flutter的gl环境，毕竟是一个存在风险的操作，给以后的flutter渲染问题定位也增加了复杂度。所以，有没有一个完美、简便的方案呢？答案就是利用CVPixelBuffer的共享内存机制。
美团
微前端是一种利用微件拆分来达到工程拆分治理的方案，可以解决工程膨胀、开发维护困难等问题。随着前端业务场景越来越复杂，微前端这个概念最近被提起得越来越多，业界也有很多团队开始探索实践并在业务中进行了落地。可以看到，很多团队也遇到了各种各样的问题，但各自也都有着不同的处理方案。诚然，任何技术的实现都要依托业务场景才会变得有意义，所以在阐述美团外卖广告团队的微前端实践之前，我们先来简单介绍一下外卖商家广告端的业务形态。目前，我们开发和维护的系统主要包括三端。
美团外卖自2013年创建以来，业务一直在高速发展，目前日订单量已突破3000万单，已成为美团点评最重要的业务之一。美团外卖所承载的业务，从早期单一的美食业务发展成为了外卖平台业务。目前除餐饮业务外，闪购、跑腿、闪付、营销、广告等产品形态的业务也陆续在外卖平台上线。参与到美团外卖平台的业务团队，也从早期的单一的外卖团队发展成为多业务团队。每个业务团队虽然都有不同的业务形态，但是几乎都有相同的诉求：需求能不能尽快地上线？
然而，Native应用的发布依赖于应用市场的更新，周期非常长，非常不利于产品的快速迭代、快速试错。同时，作为平台方，我们需要考虑到各个业务团队的诉求，统筹考虑如何建立怎么样的模型、配套什么样的技术手段，才能实现最佳的状态，满足各业务更短周期、高质量的交付业务的诉求。本文会首先回顾美团外卖从早期的月交付，逐渐演变成双周交付，再从双周交付演变成双周版本交付配合周动态交付的过程。然后从外卖的历史实践中，浅谈一个好的持续交付需要综合考虑哪些关键因素，希望对大家有所帮助或启发。
百度
网络优化是客户端几大技术方向中公认的一个深度领域，所以百度App给大家带来网络深度优化系列文章，其中包含系列《一》DNS优化，系列《二》连接优化，系列《三》弱网优化，希望对大家在网络方向的学习和实践有所帮助。
百度起家于搜索，整个公司的网络架构和部署都是基于标准的internet协议，目前已经是全栈HTTPS，来到移动互联网时代后，总的基础架构不变，但在客户端上需要做很多优化工作。
百度App在17年的版本中实现2个子view嵌套滚动，用于Feed落地页(webview呈现文章详情 + recycle呈现Native评论)。原理是在外层提供一个UI容器（我们称之为”联动容器”）处理WebView和Recyclerview连贯嵌套滚动。
当时的联动容器对子view限制比较大，仅支持WebView和Recyclerview进行联动滚动，数量也只支持2个子View。 随着组件化进程的推进，为方便各业务解耦，对联动容器提出了更高的要求，需要支持任意类型、任意数量的子view进行联动滚动，也就是本文要阐述的多子view嵌套滚动通用解决方案。
京东
时光如梭，白驹过隙，2019年转瞬即逝。这一年对于 PLUS 会员项目前端同学来说是坎坷和充实的，如白岩松所说，痛并快乐着。回首望去，异业合作权益的陆续接入，6.18大促和双11活动的需求扎堆，中间穿插部分机型首屏白页等问题的困扰，在一阵慌乱之后，我们逐渐稳住了阵脚。在完成日常需求的同时，基于原有框架，对项目的稳定性、加载、体验、开发效率等方面做了更多夯实。
2019年，累计支持了近90多个大小需求。主要分为四类：产品升级、异业合作、促销活动、紧急需求。在这些需求中包含了经典卡新增用户权益的需求，如健康、读书、快递券、95折商品权益。也大大扩展了和其他异业的联合，如腾讯视频、携程旅游、酷狗音乐等。此外还有研发侧发起的性能优化、用户体验优化等。
京东微信购物首页（以下简称微信首页）曾经作为微信购物一级入口（目前替换为京喜小程序）一直对性能有着极高的要求，本文将介绍微信首页的一些优化经验。
一般来说产品是按以下方式进行迭代的，我认为循环的起点应该是「收集用户反馈」，我们对页面的优化依据和目标一个重要来源就是用户的反馈，因此说网页优化我们先从网页监控开始聊起。
京东前端监控涉及的系统主要有两个：测速系统和智能监控平台。
阿里
如今，阿里巴巴内部维护了数十个大规模的 K8s 集群，其中最大的集群约 1 万个节点，每个集群会服务上万个应用； Kubernetes 服务 ACK 上，我们还维护了上万个用户的 K8s 集群。我们在一定程度上解决了规模和稳定性问题之后，发现其实在 K8s 上管理应用还有很大的挑战等着我们。
今天我们主要讨论这两个方面的挑战：
- 对应用研发而言，K8s API 针对简单应用过于复杂，针对复杂应用难以上手；
- 对应用运维而言，K8s 的扩展能力难以管理；K8s 原生的 API 没有对云资源全部涵盖。 总体而言，我们面临的挑战就是：如何基于 K8s 提供真正意义上的应用管理平台，让研发和运维只需关注到应用本身。
闲鱼目前实际生产部署环境越来越复杂，横向依赖各种服务盘宗错节，纵向依赖的运行环境也越来越复杂。当服务出现问题的时候，能否及时在海量的数据中定位到问题根因，成为考验闲鱼服务能力的一个严峻挑战。
线上出现问题时常常需要十多分钟，甚至更长时间才能找到问题原因，因此一个能够快速进行自动诊断的系统需求就应用而生，而快速诊断的基础是一个高性能的实时数据处理系统。
这个实时数据处理系统需要具备如下的能力：1、数据实时采集、实时分析、复杂计算、分析结果持久化。2、可以处理多种多样的数据。包含应用日志、主机性能监控指标、调用链路图。3、高可靠性。系统不出问题且数据不能丢。4、高性能，底延时。数据处理的延时不超过3秒，支持每秒千万级的数据处理。 本文不涉及问题自动诊断的具体分析模型，只讨论整体实时数据处理链路的设计。
看完这些了大厂的技术文章，希望可以拓宽大家的技术视野，对掘友们的面试有一些帮助。你也可以把自己去大厂面试的过程记录下来，分享给有需要的掘友们，一起交流共进。
同时，掘金酱跟大家预告一下，在面试季期间，掘金社区也会陆续持续推出与面试主题相关的活动，大家可以准备摩拳擦掌，踊跃参加啦。
最后，预祝大家都可以面试顺利，成功进入自己心仪的公司。