Java+Android+資料結構基礎知識總結 [一]

Java 資料結構安卓開發 · 發表 2019-01-18 23:24:37

摘要：子曰：“父母之年，不可不知也。一則以喜，一則以懼。”《論語》見過很多的人為了家庭放棄工作。你是螺絲釘，你可能一輩子就在一個地方，離開了你的地方，就成了廢鐵。你是金子，鑽石呢？？面試的時間一般是半個小時到一個小時左右，時間很是寶貴，建議只做自己最擅長的那...

子曰：“父母之年，不可不知也。一則以喜，一則以懼。”《論語》

見過很多的人為了家庭放棄工作。你是螺絲釘，你可能一輩子就在一個地方，離開了你的地方，就成了廢鐵。你是金子，鑽石呢？？

面試的時間一般是半個小時到一個小時左右，時間很是寶貴，建議只做自己最擅長的那一部分

基礎知識要配合著專案經驗來進行講述，這樣才會給面試官最大的尊重，也給自己一個發光的機會

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);
}
}

編寫一個函式用來實現輸入任意一個字串，實現對該字串進行反轉
1. 轉換成char陣列，倒著輸出即可[英文數字均可] [簡單(la)粗暴(ji)]
2. 如果是中文串，編碼問題就不是那麼善良了
3. 這時候，使用字串擷取類，倒著一個一個的擷取即可
4. 也可以使用整個串長度的For迴圈，輸出指定位置的字元即可
5. 小技巧split("")可以讓整個串按字元分割
6. 資料結構高手的想法，整個串分割後壓入棧中，進行彈出就是反轉
7. 首尾交換法比如原長度是10，那麼 [0][10] | [1][9]進行交換，for迴圈只用跑 1/2，效率也是非常可觀
8. 歡迎大家對以上演算法進行效率排序，可以在公眾號中給我留言

Android 基礎

場景 [Context]
1. 原始碼分析 Activity、Service、Application都是Context的子類
2. 分類 Activity ApplicationContext
3. 兩個有什麼區別，需要顯示東西的時候，就用Activity中的Context就可以，不需要顯示的時候，那麼使用ApplicationContext就行，當然，注意物件的引用，發生記憶體洩漏也不好，軟引用空指標了也不好
4. 場景，就是前臺小蜜要不停的穿梭在老闆的辦公室，前臺等地方，所以不同的場景下，小蜜能做的事情也不同
5. 所以，要分場合的使用你的小蜜

四大元件
1. 活動(Activity)
  1. 生命週期方法呼叫，四種啟動方式
2. 服務(Service)
  1. 生命週期，繫結方法
3. 廣播接收者(BroadcastReceiver)
  1. 動態註冊(onDestroy中解綁)和靜態註冊的區別，優先順序
  2. 廣播分類有序(優先順序大的有權利截斷廣播)/無序
  3. 廣播分類本地/全域性
  4. 廣播分類 Sticky 粘性廣播，延遲廣播許可權 android.permission.BROADCAST_STICKY
  5. 粘性廣播保證後註冊的接收者也可以接收到，但只保持最後一條廣播
  6. 粘性廣播已經很少用
4. 內容提供者(Content Provider)
  1. Uri格式 [scheme:] [//host:port] [path] [?query][#fragment]
  2. 當外部應用需要對ContentProvider中的資料進行新增、刪除、修改和查詢操作時，可以使用ContentResolver類來完成，要獲取ContentResolver物件，可以使用Context提供的getContentResolver()方法。
  3. 怎麼描述他的功能呢，就是給別人開的後門吧

5.內容觀察者(ContentObserver)（提供者的小弟）
1.觀察簡訊、通話記錄、是否飛航模式
2.需要頻繁檢測的資料庫或者某個資料是否發生改變，如果使用執行緒去操作，很不經濟而且很耗時 
3.在使用者不知曉的情況下對資料庫做一些事件，比如：悄悄傳送資訊、拒絕接受簡訊黑名單等
4.比如，只接受指定使用者的資訊
5.建議和Handler配合使用更新UI

OOM [out of memory 記憶體溢位]
1. 一般一個應用使用的記憶體不能超過預設值 32M ，小米150M..
2. 國內的黑科技APP就不要吐槽了，大的能佔你的手機 1G 運存
3. 為什麼能佔這麼多還不OOM，解決方式很多
4. 保持不重要的記憶體進行軟引用，讓系統的gc自己動起來
5. 大圖載入(10M以上的大圖) 得到bitmap之前先利用BitmapFactory.Options的inSampleSize的值得到壓縮圖片。
6. 資料需要的時候再進行載入
7. LruCache 設計自己的快取去資料單獨進行管理底層使用LinkedHashMap在使用一個物件的時候就把這個物件移動到佇列頭部，而且執行緒安全
8. 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. 使用前判斷非空

1. 原因，在記憶體中有一個無法訪問也無法清除的物件
2. 危險，小的洩漏無所謂，每次洩漏一點，時間久了，手機的記憶體就被啃光了，明顯感覺到卡頓和發熱的時候，早就積少成多了
3. 避免這些問題是高階開發人員的核心技能之一
4. 儘量避免使用 static 成員變數，這些東西和APP生命週期一樣，極其浪費系統資源
5. 將內部類改為靜態內部類
6. 靜態內部類中使用弱引用來引用外部類的成員變數
7. Handler 更新UI使用弱引用

ANR [Application Not Responding]
1. 喜歡玩舊手機的人，經常看到這個
2. 經常會問你，xx失去響應，該不該把它關了
3. Activity 5sbroadCastReceiver 10s Service 20s
4. 為什麼，你卡到UI執行緒了
5. 好的應用是不允許這個問題出現
6. 所以，[耗時/聯網/資料庫]等操作就放到工作服務和子執行緒中
7. 最好辦法，非同步資料處理，多用快取機制
8. 微小的卡頓保持在100-200ms中，放心沒人發現
9. 使用進度條來保持耗時的不尷尬

Java+Android+資料結構 基礎知識總結 [一]

您可能也會喜歡…

Java+Android+資料結構基礎知識總結 [一]