朋友,在准备大厂面试吗,内部技术了解一下

大家好呀,我是来自春天的掘金酱。

又到了一年的金三银四,想要换工作的同学自然不能错过。面试和笔试的准备也要提上日程啦。在最近的一份工作报告中显示,开发者的热门选择依然是阿里、腾讯、百度、字节跳动、美团等各个知名大厂。

当“面向对象编程”变成了“面向大厂编程”,想要进入大厂,除了专业知识准备充分之余,如果可以了解内部的技术,显然可以因地制宜,有针对性地进行准备和学习,知己知彼,方能百战不殆。同时,了解大厂的技术动向,也可以拓宽自己的技术眼界,对最新的技术保持敏感度。

掘金酱已经整理好了各个大厂的技术分享,方便你一次性阅读。


字节跳动

  • 抖音BoostMultiDex优化实践:Android低版本上APP首次启动时间减少80%

我们知道,Android 低版本(4.X 及以下,SDK < 21)的设备,采用的 Java 运行环境是 Dalvik 虚拟机。它相比于高版本,最大的问题就是在安装或者升级更新之后,首次冷启动的耗时漫长。这常常需要花费几十秒甚至几分钟,用户不得不面对一片黑屏,熬过这段时间才能正常使用 APP。这是非常影响用户的使用体验的。

问题根本原因就在于,安装或者升级后首次 MultiDex 花费的时间过于漫长。为了解决这个问题,我们挖掘了 Dalvik 虚拟机的底层系统机制,对 DEX 相关处理逻辑进行了重新设计,最终推出了 BoostMultiDex 方案,它能够减少 80%以上的黑屏等待时间,挽救低版本 Android 用户的升级安装体验。

  • 前端微服务在字节跳动的打磨与应用

传统前端业务通常会根据业务线集成在一个站点上,随着业务复杂度上升,包体积会迅速变的过大。为了适应这个变化往往需要更多的开发者、更细粒度的团队组织。分组开发时大家的模块解耦到各自完成,上线时糅合在一起运行,产生出层出不穷的分支合并、代码回滚,都会造成合作效率的骤降。这正是头条号平台在 17 年时面临的问题。

本文讨论了微前端在字节跳动的应用情况,内容主要分析了微前端具体落地的步骤和两年来的使用情况。其中分析的部分主要讲到一些实际问题和我们的应对,落地情况强调了实现的过程。特别讲到很多在我们观念里面务必要提供的微前端基石,这些方面作为基础设施几乎是使用微前端的必要和前提条件。

腾讯

  • 前端如何真正晋级成全栈:腾讯 Serverless 前端落地与实践

本文内容整理自腾讯 Serverless 技术专家王俊杰在 GMTC 2019 深圳站的演讲。 Serverless 是当下炙手可热的技术,被认为是云计算发展的未来方向,拥有免运维、降低开发成本、按需自动扩展等诸多优点。尤其是在前端研发领域,使用 Node 开发云函数,可以让前端工程师更加专注于业务逻辑,实现全栈工程师的角色转变。

但现有的开发模式、工具、脚手架已经标准化、流程化,存量业务正在线上稳定运行,如何将 Serverless 融入到现有开发模式和工具中?如何将 Serverless 和当前的业务进行结合落地?本文将尝试给出解答。

  • 实时渲染不是梦:通过共享内存优化Flutter外接纹理的渲染性能

我们了解到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优化

网络优化是客户端几大技术方向中公认的一个深度领域,所以百度App给大家带来网络深度优化系列文章,其中包含系列《一》DNS优化,系列《二》连接优化,系列《三》弱网优化,希望对大家在网络方向的学习和实践有所帮助。

百度起家于搜索,整个公司的网络架构和部署都是基于标准的internet协议,目前已经是全栈HTTPS,来到移动互联网时代后,总的基础架构不变,但在客户端上需要做很多优化工作。

  • UI系列一Android多子view嵌套通用解决方案

百度App在17年的版本中实现2个子view嵌套滚动,用于Feed落地页(webview呈现文章详情 + recycle呈现Native评论)。原理是在外层提供一个UI容器(我们称之为”联动容器”)处理WebView和Recyclerview连贯嵌套滚动。

当时的联动容器对子view限制比较大,仅支持WebView和Recyclerview进行联动滚动,数量也只支持2个子View。 随着组件化进程的推进,为方便各业务解耦,对联动容器提出了更高的要求,需要支持任意类型、任意数量的子view进行联动滚动,也就是本文要阐述的多子view嵌套滚动通用解决方案。

京东

  • 2019年京东PLUS会员前端开发之路

时光如梭,白驹过隙,2019年转瞬即逝。这一年对于 PLUS 会员项目前端同学来说是坎坷和充实的,如白岩松所说,痛并快乐着。回首望去,异业合作权益的陆续接入,6.18大促和双11活动的需求扎堆,中间穿插部分机型首屏白页等问题的困扰,在一阵慌乱之后,我们逐渐稳住了阵脚。在完成日常需求的同时,基于原有框架,对项目的稳定性、加载、体验、开发效率等方面做了更多夯实。

2019年,累计支持了近90多个大小需求。主要分为四类:产品升级、异业合作、促销活动、紧急需求。在这些需求中包含了经典卡新增用户权益的需求,如健康、读书、快递券、95折商品权益。也大大扩展了和其他异业的联合,如腾讯视频、携程旅游、酷狗音乐等。此外还有研发侧发起的性能优化、用户体验优化等。

  • 京东微信购物首页性能优化实践

京东微信购物首页(以下简称微信首页)曾经作为微信购物一级入口(目前替换为京喜小程序)一直对性能有着极高的要求,本文将介绍微信首页的一些优化经验。

一般来说产品是按以下方式进行迭代的,我认为循环的起点应该是「收集用户反馈」,我们对页面的优化依据和目标一个重要来源就是用户的反馈,因此说网页优化我们先从网页监控开始聊起。

京东前端监控涉及的系统主要有两个:测速系统和智能监控平台。

阿里

  • 阿里巴巴的 Kubernetes 应用管理实践经验与教训

如今,阿里巴巴内部维护了数十个大规模的 K8s 集群,其中最大的集群约 1 万个节点,每个集群会服务上万个应用; Kubernetes 服务 ACK 上,我们还维护了上万个用户的 K8s 集群。我们在一定程度上解决了规模和稳定性问题之后,发现其实在 K8s 上管理应用还有很大的挑战等着我们。

今天我们主要讨论这两个方面的挑战:

  • 对应用研发而言,K8s API 针对简单应用过于复杂,针对复杂应用难以上手;
  • 对应用运维而言,K8s 的扩展能力难以管理;K8s 原生的 API 没有对云资源全部涵盖。 总体而言,我们面临的挑战就是:如何基于 K8s 提供真正意义上的应用管理平台,让研发和运维只需关注到应用本身。
  • 闲鱼揭秘|每秒千万级的实时数据处理是怎么实现的?

闲鱼目前实际生产部署环境越来越复杂,横向依赖各种服务盘宗错节,纵向依赖的运行环境也越来越复杂。当服务出现问题的时候,能否及时在海量的数据中定位到问题根因,成为考验闲鱼服务能力的一个严峻挑战。

线上出现问题时常常需要十多分钟,甚至更长时间才能找到问题原因,因此一个能够快速进行自动诊断的系统需求就应用而生,而快速诊断的基础是一个高性能的实时数据处理系统。

这个实时数据处理系统需要具备如下的能力:1、数据实时采集、实时分析、复杂计算、分析结果持久化。2、可以处理多种多样的数据。包含应用日志、主机性能监控指标、调用链路图。3、高可靠性。系统不出问题且数据不能丢。4、高性能,底延时。数据处理的延时不超过3秒,支持每秒千万级的数据处理。 本文不涉及问题自动诊断的具体分析模型,只讨论整体实时数据处理链路的设计。

看完这些了大厂的技术文章,希望可以拓宽大家的技术视野,对掘友们的面试有一些帮助。你也可以把自己去大厂面试的过程记录下来,分享给有需要的掘友们,一起交流共进。

同时,掘金酱跟大家预告一下,在面试季期间,掘金社区也会陆续持续推出与面试主题相关的活动,大家可以准备摩拳擦掌,踊跃参加啦。

最后,预祝大家都可以面试顺利,成功进入自己心仪的公司。

作者:掘金酱
链接:https://juejin.im/post/5e65e5cd518825492442dbb1
来源:掘金

你可能感兴趣的:(朋友,在准备大厂面试吗,内部技术了解一下)