您好,登錄后才能下訂單哦!
面試時(shí)間:2019.12.29 1~3面、2020.1.03 4~6面、2020.1.06 HR面
面試部門 + 崗位:商業(yè)化 - 高級(jí) Android 開發(fā)工程師
面試感想:整體面得比較累,基礎(chǔ)面、交叉面、Boss面,前前后后對(duì)接了 6 個(gè)面試官 (離當(dāng)初給我說的 3面+HR面 貌似差得有點(diǎn)遠(yuǎn)¬_¬) 。算法到 Boss 面都還在寫,不過慶幸的是面試官?zèng)]有為難我 (老實(shí)交代了算法沒怎么準(zhǔn)備,哎...),算法都不太難。整體項(xiàng)目比基礎(chǔ)問得多。
面試建議:算法、基礎(chǔ)是敲門磚,項(xiàng)目是試金石,良好的面試形象是加分項(xiàng)。
簡(jiǎn)歷上列舉的項(xiàng)目多想想,為什么做這個(gè)項(xiàng)目?做這個(gè)項(xiàng)目的目標(biāo)是什么?我的方案是什么?相對(duì)其他方案我的方案優(yōu)勢(shì)是什么?項(xiàng)目的收益是什么?項(xiàng)目的架構(gòu)圖是否能畫出來?項(xiàng)目中使用的主要框架原理是否前前后后都清楚?(我大概就是項(xiàng)目拯救了自己,基礎(chǔ)準(zhǔn)備有點(diǎn)倉促T^T)。
如果是現(xiàn)場(chǎng)或視頻面試,良好的面試形象還是比較有必要的。在部門 TL 面的時(shí)候,就提到我相對(duì)很多其他面試者比較好的一點(diǎn)就是,整個(gè)人的形象狀態(tài)比較好,沒有讓人覺得很疲憊。
Android 目前穩(wěn)定高效的UI適配。方案、 今日頭條屏幕適配。方案 AndroidAutoSize、 今日頭條-通過反射修正系統(tǒng)的 density 值
- dpi:屏幕像素密度,指的是在 系統(tǒng)軟件上指定的單位尺寸的像素?cái)?shù)量,它往往是寫在系統(tǒng)出廠配置文件的一個(gè)固定值;
- ppi:也是屏幕像素密度,但這個(gè) 是物理上的概念,它是客觀存在的不會(huì)改變。dpi是軟件參考了物理像素密度后,人為指定的一個(gè)值,這樣保證了 某一個(gè)區(qū)間內(nèi)的物理像素密度在軟件上都使用同一個(gè)值;
- dp加上自適應(yīng)布局和weight比例布局能解決 90%的適配問題。因?yàn)椴⒉皇撬械?080P的手機(jī)dpi都是480,比如Google 的Pixel2(1920*1080)的dpi是420;
- 寬高限定符適配:窮舉市面上所有的Android手機(jī)的寬高像素值,設(shè)定一個(gè)基準(zhǔn)的分辨率,其他分辨率都根據(jù)這個(gè)基準(zhǔn)分辨率來計(jì)算,在不同的尺寸文件夾內(nèi)部,根據(jù)該尺寸編寫對(duì)應(yīng)的dimens文件。 但其有一個(gè)致命的缺陷,那就是需要精準(zhǔn)命中才能適配,App包體積也會(huì)變大
兩個(gè)值相等的 Integer 對(duì)象,== 比較,判斷是否相等?
Activity A 跳轉(zhuǎn)Activity B,Activity B再按back鍵回退,兩個(gè)過程各自的生命周期
子線程是否可以 context.startActivity() (如ApplicationContext), 會(huì)不會(huì)有什么問題?
寫 demo 試了下是可以的。但會(huì)有什么問題還沒弄清楚...
問題很細(xì),能準(zhǔn)備多詳細(xì)就準(zhǔn)備多詳細(xì)。人家自己封裝了一套 Handler 來避免內(nèi)存泄漏問題
自己做的一個(gè)項(xiàng)目,原理講清楚就行,講不清就畫圖
怎么計(jì)算一個(gè)View在屏幕可見部分的百分比?
ClassLoader 的雙親委派機(jī)制 -
簡(jiǎn)單介紹下 Https 的原理
什么情況會(huì)導(dǎo)致內(nèi)存泄漏,如何修復(fù)?
下載一張很大的圖,如何保證不 oom? -
有沒有做過UI方面的優(yōu)化,做過哪些?
- 調(diào)試GPU過度繪制,將Overdraw降低到合理范圍內(nèi);
- 減少嵌套層次及控件個(gè)數(shù),保持view的樹形結(jié)構(gòu)盡量扁平(使用Hierarchy Viewer可以方便的查看),同時(shí)移除所有不需要渲染的view;
- 使用GPU配置渲染工具,定位出問題發(fā)生在具體哪個(gè)步驟,使用TraceView精準(zhǔn)定位代碼;
- 使用標(biāo)簽,merge減少嵌套層次、viewStub延遲初始化、include布局重用 (與merge配合使用)
WebView 與 JS 交互方式,shouldOverrideUrlLoading、onJsPrompt使用有啥區(qū)別 -
Flutter、Kotlin接觸使用過沒有
其他項(xiàng)目相關(guān)問題
算法 - 二叉樹輸出第 k 層節(jié)點(diǎn)元素
Native、H5、RN頁面混合跳轉(zhuǎn)時(shí),頁面清棧的橋?qū)崿F(xiàn)
頁面混編框架的設(shè)計(jì)與難點(diǎn)
RN 通用容器的設(shè)計(jì)
用戶行為監(jiān)控方案設(shè)計(jì)
JS 錯(cuò)誤治理方案
RN 頁面對(duì)用戶行為的監(jiān)控與JS錯(cuò)誤治理,在問題發(fā)現(xiàn)有什么收獲、優(yōu)化點(diǎn)
美團(tuán) RN 相對(duì)于原生 RN 的有什么優(yōu)勢(shì)
你們公司 Picasso 有使用過沒,介紹下
Picasso 單引擎,在多 Bundle 的情況下怎么保證數(shù)據(jù)隔離的?
美團(tuán) RN 與 Picasso 的區(qū)別
4.省略若干項(xiàng)目相關(guān)問題...
RN 的頁面追蹤埋點(diǎn)如何實(shí)現(xiàn)的
美團(tuán)首頁是否是 RN 頁面,MTFlexBox 原理
synchronized 修飾 static 方法、普通方法、類、方法塊區(qū)別
synchronized 底層實(shí)現(xiàn)原理
volatile 的作用和原理
一個(gè) int 變量用 volatile 修飾,多線程去操作 i++,是否線程安全?如何保證 i++ 線程安全?AtomicInteger 的底層實(shí)現(xiàn)原理?
使用 AtomicInteger 可以使 i++ 線程安全
說下對(duì)線程池的理解,以及創(chuàng)建線程池的幾個(gè)關(guān)鍵參數(shù)
Handler 機(jī)制又問了一遍...
介紹下 Binder 機(jī)制,與內(nèi)存共享機(jī)制有什么區(qū)別?
Java 集合,介紹下ArrayList 和 HashMap 的使用場(chǎng)景,底層實(shí)現(xiàn)原理
ArrayList 與 LinkedList 的區(qū)別
算法 - 兩個(gè)有序的鏈表的合并
算法 - 輸入一個(gè)字符串(不含 和.)、正則(字母、和.任意組合),判斷字符串是否合法
簡(jiǎn)單介紹下,項(xiàng)目中遇到的一些技術(shù)難點(diǎn)
- 考點(diǎn):Java 值傳遞 (第 2 題相同)。編寫代碼測(cè)試,在 changeValue() 方法中修改入?yún)?,?不會(huì)改變之前的值;
- 原理 : Java 程序設(shè)計(jì)語言總是采用按值調(diào)用,方法得到的是所有參數(shù)值的一個(gè)拷貝,即方法 不能修改傳遞給它的任何參數(shù)變量的內(nèi)容?;绢愋蛥?shù)傳遞的是參數(shù)副本,對(duì)象類型參數(shù)傳遞的是 對(duì)象地址的副本;
- 題解:在 changeValue() 中,對(duì)于對(duì)象類型參數(shù),直接修改的是 對(duì)象地址副本的值,所以之前變量的地址并未被修改!若修改的是對(duì)象實(shí)例里面的某個(gè)值,之前變量則會(huì)被修改
public void test() { String str = "123"; changeValue(str); System.out.println("str值為: " + str); // str未被改變,str = "123" } public changeValue(String str) { str = "abc"; }
Java 中方法參數(shù)的使用情況總結(jié):
- 一個(gè)方法不能修改一個(gè)基本數(shù)據(jù)類型的參數(shù)(即數(shù)值型或布爾型);
- 一個(gè)方法可以改變一個(gè)對(duì)象參數(shù)的狀態(tài);
- 一個(gè)方法不能讓對(duì)象參數(shù)引用一個(gè)新的對(duì)象
public void test() { Student student = new Student("Bobo", 15); changeValue1(student); // student值未改變,不為null! 輸出結(jié)果 student值為 name:Bobo、age:15 // changeValue2(student); // student值被改變,輸出結(jié)果 student值為 name:Lily、age:20 System.out.println("student值為 name: " + student.name + "、age:" + student.age); } public changeValue1(Student student) { student = null; } public static void changeValue2(Student student) { student.name = "Lily"; student.age = 20; }
Java 的幾種引用類型,弱引用的使用場(chǎng)景?
線程池分類,解釋下幾個(gè)核心參數(shù)?
APK 的打包過程是什么?
- aapt 工具打包資源文件,生成 R.java 文件
- aidl 工具處理 AIDL 文件,生成對(duì)應(yīng)的 .java 文件
- javac 工具編譯 Java 文件,生成對(duì)應(yīng)的 .class 文件
- 把 .class 文件轉(zhuǎn)化成 Davik VM 支持的 .dex 文件
- apkbuilder 工具打包生成未簽名的 .apk 文件
- jarsigner 對(duì)未簽名 .apk 文件進(jìn)行簽名
- zipalign 工具對(duì)簽名后的 .apk 文件進(jìn)行對(duì)齊處理
求路過大神們的正解...
常見的設(shè)計(jì)模式有哪些?你提供的 JS 錯(cuò)誤治理方案,用了哪些設(shè)計(jì)模式?
算法 - 二叉樹層序遍歷,奇數(shù)層逆序遍歷節(jié)點(diǎn),偶數(shù)層正序遍歷
未來 3~5 年的規(guī)劃是什么?
你覺得你的優(yōu)點(diǎn)是什么?缺點(diǎn)是什么?
現(xiàn)在的職級(jí),近期的績(jī)效如何
商業(yè)化部門相關(guān)的業(yè)務(wù)介紹 (核心大概是商業(yè)化部門壁壘高,培養(yǎng)一個(gè)人成本高,比做其他業(yè)務(wù)更有含金量,可以積累很多業(yè)務(wù)策略知識(shí)),然后讓問他問題
未來幾年的規(guī)劃?生活上有什么規(guī)劃?
你覺得你的優(yōu)點(diǎn)是什么?缺點(diǎn)是什么?
現(xiàn)在的職級(jí),近期的績(jī)效如何
為什么給你這么好的績(jī)效?
有沒有看其他機(jī)會(huì)?阿里面試的情況
算法 - 數(shù)組插入,考慮擴(kuò)容
在項(xiàng)目的遇到的比較有挑戰(zhàn)的事是什么?
你在美團(tuán)負(fù)責(zé)的業(yè)務(wù)有哪些?
未來幾年的規(guī)劃是什么?
你覺得你的優(yōu)點(diǎn)是什么?缺點(diǎn)是什么?
現(xiàn)在的職級(jí),近期的績(jī)效如何
本科和研究生專業(yè)都是偏硬件的,是否有相關(guān)的軟件經(jīng)歷?
研究生是保研的還是自己考的?
去美團(tuán)之前有沒有 Android 開發(fā)經(jīng)歷?
當(dāng)時(shí)為什么要選擇去美團(tuán)?為什么要選擇來北京?
為什么要換工作?期望以后的工作是怎樣的?
金句:現(xiàn)在自己的技術(shù)成長(zhǎng)有點(diǎn)碰到瓶頸,加上一直對(duì)您公司欽慕有加
現(xiàn)在的職級(jí),近期的績(jī)效如何?
這么好的績(jī)效,為什么不選擇美團(tuán)內(nèi)換部門看看機(jī)會(huì)?
幾次晉升中,業(yè)績(jī)亮點(diǎn)是什么?
家是哪里的,有回家那邊發(fā)展的打算沒有?
有打算再去看看快手之類的工作機(jī)會(huì)沒有?
問一些阿里現(xiàn)在的面試進(jìn)展和情況
期望的薪資
面試是一個(gè)不斷學(xué)習(xí)、不斷自我提升的過程,有機(jī)會(huì)還是出去面面,至少能想到查漏補(bǔ)缺效果,而且有些知識(shí)點(diǎn),可能你自以為知道,但讓你說,并不一定能說得很好。
有些東西有壓力才有動(dòng)力,而學(xué)到的知識(shí)點(diǎn),都是錢(因?yàn)榧夹g(shù)人員大部分情況是根據(jù)你的能力來定級(jí)、來發(fā)薪水的),技多不壓身。
附上我的面試各大專題整理: 面試指南
滿滿的都是干貨,希望對(duì)大家有幫助!
大家如果有啥好建議,面試的好處,也可以評(píng)論回復(fù)哈,我補(bǔ)充,謝謝???
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。