子曰：“父母之年，不可不知也。一則以喜，一則以懼。”《論語》
見過很多的人為了家庭放棄工作。你是螺絲釘，你可能一輩子就在一個地方，離開了你的地方，就成了廢鐵。 你是金子，鉆石呢？？
面試的時間一般是半個小時到一個小時左右，時間很是寶貴，建議只做自己最擅長的那一部分
基礎知識要配合著項目經驗來進行講述，這樣才會給面試官最大的尊重，也給自己一個發光的機會
Java基礎
TCP （Transmission Control Protocol，傳輸控制協議）
1. 一種面向連接的、可靠的、基于字節流的傳輸層通信協議
2. TCP層是位于IP層之上，應用層之下的中間層
3. 三次握手
1. 客戶端發送SYN（SEQ=x）報文給服務器端，-> SYN_SEND。
2. 服務器端收到SYN報文，回應一個SYN （SEQ=y）ACK(ACK=x+1）報文，->SYN_RECV。
3. 客戶端收到服務器端的SYN報文，回應一個ACK(ACK=y+1）報文，-> Established(已建立的)。
4. 這一過程與打電話很相似，先撥號振鈴，等待對方摘機說“喂”，然后才說明是誰。在一個TCP連接中，僅有兩方進行彼此通信。
4. 握手以后，進行傳（yue）遞(hui)
5. 可靠性保證
1. 應用數據被分割成TCP認為最適合發送的數據塊（報文）
2. 當TCP發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。
3. 既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。（自動調整順序）
4. ．TCP還能提供流量控制（緩沖區大小）。
UDP （User Data Protocol，用戶數據報協議）
1. 不面向連（fu）接(ze)
2. 全力發送
3. 一個可以給多個發送
4. 不保證順序
5. 數據報模式
6. 丟包 [ping就是用的這個，所以網不好就丟包]
- 新浪面試題
寫一個函數，計算兩個文件的相對路徑的遞歸算法
String aPath = "/P/y/z/a/b/a/g/e.php";
String bPath = "/P/y/z/a/b/a/g/c.php";
情況的時候貌似不對。
代碼可改成：
public String pathARelativePathB(String pathA, String pathB, int i) {
// A相對于B ../g/e.php
if (pathA.contains(pathB)) {
if (i == 1) {
return pathA.replaceAll(pathB + "/", "");
} else {
StringBuffer sb = new StringBuffer();
for (int j = 1; j < i; j++)
sb.append("../");
return sb.append(pathA.replaceAll(pathB + "/", "")).toString();
}
} else {
return pathARelativePathB(pathA, pathB.substring(0, pathB.lastIndexOf("/")), ++i);
}
}
-
編寫一個函數用來實現輸入任意一個字符串，實現對該字符串進行反轉
- 轉換成char數組，倒著輸出即可[英文數字均可] [簡單(la)粗暴(ji)]
- 如果是中文串，編碼問題就不是那么善良了
- 這時候，使用字符串截取類，倒著一個一個的截取即可
- 也可以使用整個串長度的For循環，輸出指定位置的字符即可
- 小技巧split("")可以讓整個串按字符分割
- 數據結構高手的想法，整個串分割后壓入棧中，進行彈出就是反轉
- 首尾交換法 比如原長度是10，那么 [0][10] | [1][9]進行交換，for循環只用跑 1/2，效率也是非常可觀
- 歡迎大家對以上算法進行效率排序，可以在公眾號中給我留言
Android 基礎
-
場景 [Context]
- 源碼分析 Activity、Service、Application都是Context的子類
- 分類 Activity ApplicationContext
- 兩個有什么區別，需要顯示東西的時候，就用Activity中的Context就可以，不需要顯示的時候，那么使用ApplicationContext就行，當然，注意對象的引用，發生內存泄漏也不好，軟引用空指針了也不好
- 場景，就是前臺小蜜要不停的穿梭在老板的辦公室，前臺等地方，所以不同的場景下，小蜜能做的事情也不同
- 所以，要分場合的使用你的小蜜
-
四大組件
- 活動(Activity)
- 生命周期方法調用，四種啟動方式
- 服務(Service)
- 生命周期，綁定方法
- 廣播接收者(BroadcastReceiver)
- 動態注冊(onDestroy中解綁)和靜態注冊的區別，優先級
- 廣播分類 有序(優先級大的有權利截斷廣播)/無序
- 廣播分類 本地/全局
- 廣播分類 Sticky 粘性廣播，延遲廣播 權限 android.permission.BROADCAST_STICKY
- 粘性廣播保證后注冊的接收者也可以接收到，但只保持最后一條廣播
- 粘性廣播已經很少用
- 內容提供者(Content Provider)
- Uri格式 [scheme:] [//host:port] [path] [?query][#fragment]
- 當外部應用需要對ContentProvider中的數據進行添加、刪除、修改和查詢操作時，可以使用ContentResolver類來完成，要獲取ContentResolver對象，可以使用Context提供的getContentResolver()方法。
- 怎么描述他的功能呢，就是給別人開的后門吧
- 活動(Activity)
5. 內容觀察者(ContentObserver)（提供者的小弟）
1. 觀察短信、通話記錄、是否飛行模式
2. 需要頻繁檢測的數據庫或者某個數據是否發生改變，如果使用線程去操作，很不經濟而且很耗時
3. 在用戶不知曉的情況下對數據庫做一些事件，比如：悄悄發送信息、拒絕接受短信黑名單等
4. 比如，只接受指定用戶的信息
5. 建議和Handler配合使用更新UI
-
OOM [out of memory 內存溢出]
- 一般一個應用使用的內存不能超過默認值 32M ，小米150M..
- 國內的黑科技APP就不要吐槽了，大的能占你的手機 1G 運存
- 為什么能占這么多還不OOM，解決方式很多
- 保持不重要的內存進行軟引用，讓系統的gc自己動起來
- 大圖加載(10M以上的大圖) 得到bitmap之前先利用BitmapFactory.Options的inSampleSize的值得到壓縮圖片。
- 數據需要的時候再進行加載
- LruCache 設計自己的緩存去 數據單獨進行管理 底層使用LinkedHashMap在使用一個對象的時候就把這個對象移動到隊列頭部，而且線程安全
- AsyncTask 它封裝了Thread和Handler
- 內存泄漏 (占用的內存只增不減)-> 合理的使用你的內存
先簡單的泄漏一下
第一種 [JAVA] 泄漏
1. 創建一百個對象
2. 把這一百個對象放入集合中，放入后把原對象引用置為空
3. 使用完集合后，這些對象還是會繼續存在，造成泄漏
4. 將對象也置為空，系統就會自動GC
第二種 [上下文的泄漏]
1. 靜態類中使用的Context
2. 如果靜態類的生命周期長于Context生命周期 -> 泄漏
3. 可以使用ApplicationContext 在Application中添加一個靜態工廠方法，返回ApplicationContext.
4. Handler 造成的內存泄漏 Handler、Message 和 MessageQueue 都是相互關聯在一起的
5. 如果Handler還有沒處理完的東西Activiy已經被關閉了
6. Handler 中還繼續持有這個 Activity 的引用 -> 泄漏
7. 解決方案，Handler 對 Activity 使用軟引用
8. 使用前判斷非空
- 原因，在內存中有一個無法訪問也無法清除的對象
- 危險，小的泄漏無所謂，每次泄漏一點，時間久了，手機的內存就被啃光了，明顯感覺到卡頓和發熱的時候，早就積少成多了
- 避免這些問題是高端開發人員的核心技能之一
- 盡量避免使用 static 成員變量，這些東西和APP生命周期一樣，極其浪費系統資源
- 將內部類改為靜態內部類
- 靜態內部類中使用弱引用來引用外部類的成員變量
- Handler 更新UI使用弱引用
-
ANR [Application Not Responding]
- 喜歡玩舊手機的人，經常看到這個
- 經常會問你，xx失去響應，該不該把它關了
- Activity 5s broadCastReceiver 10s Service 20s
- 為什么，你卡到UI線程了
- 好的應用是不允許這個問題出現
- 所以，[耗時/聯網/數據庫] 等操作就放到工作服務和子線程中
- 最好辦法，異步數據處理，多用緩存機制
- 微小的卡頓保持在100-200ms中，放心沒人發現
- 使用進度條來保持耗時的不尷尬
