大家好呀，我是來(lái)自春天的掘金醬。
又到了一年的金三銀四，想要換工作的同學(xué)自然不能錯(cuò)過(guò)。面試和筆試的準(zhǔn)備也要提上日程啦。在最近的一份工作報(bào)告中顯示，開(kāi)發(fā)者的熱門選擇依然是阿里、騰訊、百度、字節(jié)跳動(dòng)、美團(tuán)等各個(gè)知名大廠。
當(dāng)“面向?qū)ο缶幊獭弊兂闪恕懊嫦虼髲S編程”，想要進(jìn)入大廠，除了專業(yè)知識(shí)準(zhǔn)備充分之余，如果可以了解內(nèi)部的技術(shù)，顯然可以因地制宜，有針對(duì)性地進(jìn)行準(zhǔn)備和學(xué)習(xí)，知己知彼，方能百戰(zhàn)不殆。同時(shí)，了解大廠的技術(shù)動(dòng)向，也可以拓寬自己的技術(shù)眼界，對(duì)最新的技術(shù)保持敏感度。
掘金醬已經(jīng)整理好了各個(gè)大廠的技術(shù)分享，方便你一次性閱讀。
字節(jié)跳動(dòng)
我們知道，Android 低版本（4.X 及以下，SDK < 21）的設(shè)備，采用的 Java 運(yùn)行環(huán)境是 Dalvik 虛擬機(jī)。它相比于高版本，最大的問(wèn)題就是在安裝或者升級(jí)更新之后，首次冷啟動(dòng)的耗時(shí)漫長(zhǎng)。這常常需要花費(fèi)幾十秒甚至幾分鐘，用戶不得不面對(duì)一片黑屏，熬過(guò)這段時(shí)間才能正常使用 APP。這是非常影響用戶的使用體驗(yàn)的。
問(wèn)題根本原因就在于，安裝或者升級(jí)后首次 MultiDex 花費(fèi)的時(shí)間過(guò)于漫長(zhǎng)。為了解決這個(gè)問(wèn)題，我們挖掘了 Dalvik 虛擬機(jī)的底層系統(tǒng)機(jī)制，對(duì) DEX 相關(guān)處理邏輯進(jìn)行了重新設(shè)計(jì)，最終推出了 BoostMultiDex 方案，它能夠減少 80%以上的黑屏等待時(shí)間，挽救低版本 Android 用戶的升級(jí)安裝體驗(yàn)。
傳統(tǒng)前端業(yè)務(wù)通常會(huì)根據(jù)業(yè)務(wù)線集成在一個(gè)站點(diǎn)上，隨著業(yè)務(wù)復(fù)雜度上升，包體積會(huì)迅速變的過(guò)大。為了適應(yīng)這個(gè)變化往往需要更多的開(kāi)發(fā)者、更細(xì)粒度的團(tuán)隊(duì)組織。分組開(kāi)發(fā)時(shí)大家的模塊解耦到各自完成，上線時(shí)糅合在一起運(yùn)行，產(chǎn)生出層出不窮的分支合并、代碼回滾，都會(huì)造成合作效率的驟降。這正是頭條號(hào)平臺(tái)在 17 年時(shí)面臨的問(wèn)題。
本文討論了微前端在字節(jié)跳動(dòng)的應(yīng)用情況，內(nèi)容主要分析了微前端具體落地的步驟和兩年來(lái)的使用情況。其中分析的部分主要講到一些實(shí)際問(wèn)題和我們的應(yīng)對(duì)，落地情況強(qiáng)調(diào)了實(shí)現(xiàn)的過(guò)程。特別講到很多在我們觀念里面務(wù)必要提供的微前端基石，這些方面作為基礎(chǔ)設(shè)施幾乎是使用微前端的必要和前提條件。
騰訊
本文內(nèi)容整理自騰訊 Serverless 技術(shù)專家王俊杰在 GMTC 2019 深圳站的演講。 Serverless 是當(dāng)下炙手可熱的技術(shù)，被認(rèn)為是云計(jì)算發(fā)展的未來(lái)方向，擁有免運(yùn)維、降低開(kāi)發(fā)成本、按需自動(dòng)擴(kuò)展等諸多優(yōu)點(diǎn)。尤其是在前端研發(fā)領(lǐng)域，使用 Node 開(kāi)發(fā)云函數(shù)，可以讓前端工程師更加專注于業(yè)務(wù)邏輯，實(shí)現(xiàn)全棧工程師的角色轉(zhuǎn)變。
但現(xiàn)有的開(kāi)發(fā)模式、工具、腳手架已經(jīng)標(biāo)準(zhǔn)化、流程化，存量業(yè)務(wù)正在線上穩(wěn)定運(yùn)行，如何將 Serverless 融入到現(xiàn)有開(kāi)發(fā)模式和工具中？如何將 Serverless 和當(dāng)前的業(yè)務(wù)進(jìn)行結(jié)合落地？本文將嘗試給出解答。
我們了解到flutter提供一種機(jī)制，可以將native的紋理共享給flutter來(lái)進(jìn)行渲染。但是，由于flutter獲取native紋理的數(shù)據(jù)類型是CVPixelBuffer，導(dǎo)致native紋理需要經(jīng)過(guò)GPU->CPU->GPU的轉(zhuǎn)換過(guò)程消耗額外性能，這對(duì)于需要實(shí)時(shí)渲染的音視頻類需求，是不可接受的。
閑魚(yú)這邊的解決方案是修改了flutter engine的代碼，將flutter的gl環(huán)境和native的gl環(huán)境通過(guò)ShareGroup來(lái)聯(lián)通，避免2個(gè)環(huán)境的紋理傳遞還要去cpu內(nèi)存繞一圈。此方案能夠解決內(nèi)存拷貝的性能問(wèn)題，但暴露flutter的gl環(huán)境，畢竟是一個(gè)存在風(fēng)險(xiǎn)的操作，給以后的flutter渲染問(wèn)題定位也增加了復(fù)雜度。所以，有沒(méi)有一個(gè)完美、簡(jiǎn)便的方案呢？答案就是利用CVPixelBuffer的共享內(nèi)存機(jī)制。
美團(tuán)
微前端是一種利用微件拆分來(lái)達(dá)到工程拆分治理的方案，可以解決工程膨脹、開(kāi)發(fā)維護(hù)困難等問(wèn)題。隨著前端業(yè)務(wù)場(chǎng)景越來(lái)越復(fù)雜，微前端這個(gè)概念最近被提起得越來(lái)越多，業(yè)界也有很多團(tuán)隊(duì)開(kāi)始探索實(shí)踐并在業(yè)務(wù)中進(jìn)行了落地。可以看到，很多團(tuán)隊(duì)也遇到了各種各樣的問(wèn)題，但各自也都有著不同的處理方案。誠(chéng)然，任何技術(shù)的實(shí)現(xiàn)都要依托業(yè)務(wù)場(chǎng)景才會(huì)變得有意義，所以在闡述美團(tuán)外賣廣告團(tuán)隊(duì)的微前端實(shí)踐之前，我們先來(lái)簡(jiǎn)單介紹一下外賣商家廣告端的業(yè)務(wù)形態(tài)。目前，我們開(kāi)發(fā)和維護(hù)的系統(tǒng)主要包括三端。
美團(tuán)外賣自2013年創(chuàng)建以來(lái)，業(yè)務(wù)一直在高速發(fā)展，目前日訂單量已突破3000萬(wàn)單，已成為美團(tuán)點(diǎn)評(píng)最重要的業(yè)務(wù)之一。美團(tuán)外賣所承載的業(yè)務(wù)，從早期單一的美食業(yè)務(wù)發(fā)展成為了外賣平臺(tái)業(yè)務(wù)。目前除餐飲業(yè)務(wù)外，閃購(gòu)、跑腿、閃付、營(yíng)銷、廣告等產(chǎn)品形態(tài)的業(yè)務(wù)也陸續(xù)在外賣平臺(tái)上線。參與到美團(tuán)外賣平臺(tái)的業(yè)務(wù)團(tuán)隊(duì)，也從早期的單一的外賣團(tuán)隊(duì)發(fā)展成為多業(yè)務(wù)團(tuán)隊(duì)。每個(gè)業(yè)務(wù)團(tuán)隊(duì)雖然都有不同的業(yè)務(wù)形態(tài)，但是幾乎都有相同的訴求：需求能不能盡快地上線？
然而，Native應(yīng)用的發(fā)布依賴于應(yīng)用市場(chǎng)的更新，周期非常長(zhǎng)，非常不利于產(chǎn)品的快速迭代、快速試錯(cuò)。同時(shí)，作為平臺(tái)方，我們需要考慮到各個(gè)業(yè)務(wù)團(tuán)隊(duì)的訴求，統(tǒng)籌考慮如何建立怎么樣的模型、配套什么樣的技術(shù)手段，才能實(shí)現(xiàn)最佳的狀態(tài)，滿足各業(yè)務(wù)更短周期、高質(zhì)量的交付業(yè)務(wù)的訴求。本文會(huì)首先回顧美團(tuán)外賣從早期的月交付，逐漸演變成雙周交付，再?gòu)碾p周交付演變成雙周版本交付配合周動(dòng)態(tài)交付的過(guò)程。然后從外賣的歷史實(shí)踐中，淺談一個(gè)好的持續(xù)交付需要綜合考慮哪些關(guān)鍵因素，希望對(duì)大家有所幫助或啟發(fā)。
百度
網(wǎng)絡(luò)優(yōu)化是客戶端幾大技術(shù)方向中公認(rèn)的一個(gè)深度領(lǐng)域，所以百度App給大家?guī)?lái)網(wǎng)絡(luò)深度優(yōu)化系列文章，其中包含系列《一》DNS優(yōu)化，系列《二》連接優(yōu)化，系列《三》弱網(wǎng)優(yōu)化，希望對(duì)大家在網(wǎng)絡(luò)方向的學(xué)習(xí)和實(shí)踐有所幫助。
百度起家于搜索，整個(gè)公司的網(wǎng)絡(luò)架構(gòu)和部署都是基于標(biāo)準(zhǔn)的internet協(xié)議，目前已經(jīng)是全棧HTTPS，來(lái)到移動(dòng)互聯(lián)網(wǎng)時(shí)代后，總的基礎(chǔ)架構(gòu)不變，但在客戶端上需要做很多優(yōu)化工作。
百度App在17年的版本中實(shí)現(xiàn)2個(gè)子view嵌套滾動(dòng)，用于Feed落地頁(yè)(webview呈現(xiàn)文章詳情 + recycle呈現(xiàn)Native評(píng)論)。原理是在外層提供一個(gè)UI容器（我們稱之為”聯(lián)動(dòng)容器”）處理WebView和Recyclerview連貫嵌套滾動(dòng)。
當(dāng)時(shí)的聯(lián)動(dòng)容器對(duì)子view限制比較大，僅支持WebView和Recyclerview進(jìn)行聯(lián)動(dòng)滾動(dòng)，數(shù)量也只支持2個(gè)子View。 隨著組件化進(jìn)程的推進(jìn)，為方便各業(yè)務(wù)解耦，對(duì)聯(lián)動(dòng)容器提出了更高的要求，需要支持任意類型、任意數(shù)量的子view進(jìn)行聯(lián)動(dòng)滾動(dòng)，也就是本文要闡述的多子view嵌套滾動(dòng)通用解決方案。
京東
時(shí)光如梭，白駒過(guò)隙，2019年轉(zhuǎn)瞬即逝。這一年對(duì)于 PLUS 會(huì)員項(xiàng)目前端同學(xué)來(lái)說(shuō)是坎坷和充實(shí)的，如白巖松所說(shuō)，痛并快樂(lè)著。回首望去，異業(yè)合作權(quán)益的陸續(xù)接入，6.18大促和雙11活動(dòng)的需求扎堆，中間穿插部分機(jī)型首屏白頁(yè)等問(wèn)題的困擾，在一陣慌亂之后，我們逐漸穩(wěn)住了陣腳。在完成日常需求的同時(shí)，基于原有框架，對(duì)項(xiàng)目的穩(wěn)定性、加載、體驗(yàn)、開(kāi)發(fā)效率等方面做了更多夯實(shí)。
2019年，累計(jì)支持了近90多個(gè)大小需求。主要分為四類：產(chǎn)品升級(jí)、異業(yè)合作、促銷活動(dòng)、緊急需求。在這些需求中包含了經(jīng)典卡新增用戶權(quán)益的需求，如健康、讀書(shū)、快遞券、95折商品權(quán)益。也大大擴(kuò)展了和其他異業(yè)的聯(lián)合，如騰訊視頻、攜程旅游、酷狗音樂(lè)等。此外還有研發(fā)側(cè)發(fā)起的性能優(yōu)化、用戶體驗(yàn)優(yōu)化等。
京東微信購(gòu)物首頁(yè)（以下簡(jiǎn)稱微信首頁(yè)）曾經(jīng)作為微信購(gòu)物一級(jí)入口（目前替換為京喜小程序）一直對(duì)性能有著極高的要求，本文將介紹微信首頁(yè)的一些優(yōu)化經(jīng)驗(yàn)。
一般來(lái)說(shuō)產(chǎn)品是按以下方式進(jìn)行迭代的，我認(rèn)為循環(huán)的起點(diǎn)應(yīng)該是「收集用戶反饋」，我們對(duì)頁(yè)面的優(yōu)化依據(jù)和目標(biāo)一個(gè)重要來(lái)源就是用戶的反饋，因此說(shuō)網(wǎng)頁(yè)優(yōu)化我們先從網(wǎng)頁(yè)監(jiān)控開(kāi)始聊起。
京東前端監(jiān)控涉及的系統(tǒng)主要有兩個(gè)：測(cè)速系統(tǒng)和智能監(jiān)控平臺(tái)。
阿里
如今，阿里巴巴內(nèi)部維護(hù)了數(shù)十個(gè)大規(guī)模的 K8s 集群，其中最大的集群約 1 萬(wàn)個(gè)節(jié)點(diǎn)，每個(gè)集群會(huì)服務(wù)上萬(wàn)個(gè)應(yīng)用； Kubernetes 服務(wù) ACK 上，我們還維護(hù)了上萬(wàn)個(gè)用戶的 K8s 集群。我們?cè)谝欢ǔ潭壬辖鉀Q了規(guī)模和穩(wěn)定性問(wèn)題之后，發(fā)現(xiàn)其實(shí)在 K8s 上管理應(yīng)用還有很大的挑戰(zhàn)等著我們。
今天我們主要討論這兩個(gè)方面的挑戰(zhàn)：
- 對(duì)應(yīng)用研發(fā)而言，K8s API 針對(duì)簡(jiǎn)單應(yīng)用過(guò)于復(fù)雜，針對(duì)復(fù)雜應(yīng)用難以上手；
- 對(duì)應(yīng)用運(yùn)維而言，K8s 的擴(kuò)展能力難以管理；K8s 原生的 API 沒(méi)有對(duì)云資源全部涵蓋。 總體而言，我們面臨的挑戰(zhàn)就是：如何基于 K8s 提供真正意義上的應(yīng)用管理平臺(tái)，讓研發(fā)和運(yùn)維只需關(guān)注到應(yīng)用本身。
閑魚(yú)目前實(shí)際生產(chǎn)部署環(huán)境越來(lái)越復(fù)雜，橫向依賴各種服務(wù)盤宗錯(cuò)節(jié)，縱向依賴的運(yùn)行環(huán)境也越來(lái)越復(fù)雜。當(dāng)服務(wù)出現(xiàn)問(wèn)題的時(shí)候，能否及時(shí)在海量的數(shù)據(jù)中定位到問(wèn)題根因，成為考驗(yàn)閑魚(yú)服務(wù)能力的一個(gè)嚴(yán)峻挑戰(zhàn)。
線上出現(xiàn)問(wèn)題時(shí)常常需要十多分鐘，甚至更長(zhǎng)時(shí)間才能找到問(wèn)題原因，因此一個(gè)能夠快速進(jìn)行自動(dòng)診斷的系統(tǒng)需求就應(yīng)用而生，而快速診斷的基礎(chǔ)是一個(gè)高性能的實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)。
這個(gè)實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)需要具備如下的能力：1、數(shù)據(jù)實(shí)時(shí)采集、實(shí)時(shí)分析、復(fù)雜計(jì)算、分析結(jié)果持久化。2、可以處理多種多樣的數(shù)據(jù)。包含應(yīng)用日志、主機(jī)性能監(jiān)控指標(biāo)、調(diào)用鏈路圖。3、高可靠性。系統(tǒng)不出問(wèn)題且數(shù)據(jù)不能丟。4、高性能，底延時(shí)。數(shù)據(jù)處理的延時(shí)不超過(guò)3秒，支持每秒千萬(wàn)級(jí)的數(shù)據(jù)處理。 本文不涉及問(wèn)題自動(dòng)診斷的具體分析模型，只討論整體實(shí)時(shí)數(shù)據(jù)處理鏈路的設(shè)計(jì)。
看完這些了大廠的技術(shù)文章，希望可以拓寬大家的技術(shù)視野，對(duì)掘友們的面試有一些幫助。你也可以把自己去大廠面試的過(guò)程記錄下來(lái)，分享給有需要的掘友們，一起交流共進(jìn)。
同時(shí)，掘金醬跟大家預(yù)告一下，在面試季期間，掘金社區(qū)也會(huì)陸續(xù)持續(xù)推出與面試主題相關(guān)的活動(dòng)，大家可以準(zhǔn)備摩拳擦掌，踴躍參加啦。
最后，預(yù)祝大家都可以面試順利，成功進(jìn)入自己心儀的公司。
作者：掘金醬
鏈接：https://juejin.im/post/5e65e5cd518825492442dbb1
來(lái)源：掘金
