MS(2)：Android之基礎知識篇
二、元件
1、Activity----------1
分析篇：全面瞭解Activity
問題：Activity生命週期及流程圖；
問題：介紹Activity的幾種啟動模式，並簡單說說自己的理解或者使用場景；
1.standard:預設標準模式，每啟動一個都會建立一個例項，
2.singleTop：棧頂複用，如果在棧頂就呼叫onNewIntent複用，從onResume()開始
3.singleTask：棧內複用，本棧內只要用該型別Activity就會調到棧頂複用，從onResume()開始
4.singleInstance：單例模式，除了3中特性，系統會單獨給該Activity建立一個棧，
問題：Activity傳遞引數
問題：Activity中如何動態的新增Fragment
FragmentManager mFragmentManager = getSupportFragmentManager(); //獲取支援包中的FragmentManager();
ExampleFragment mExampleFragment =newmExampleFragment(); //動態新增的Fragment
FragmentTransaction fragmentTransaction = mFragmentManager.beginTransaction(); //通過beginTransaction()獲取fragmentTransaction
fragmentTransaction.add(R.id.new_panel, mExampleFragment); //向view中新增指定的Fragment
fragmentTransaction.commit(); //更新完成後不要忘記了commit()哦;
知識點：鎖定屏與解鎖螢幕只會呼叫onPause()，而不會呼叫onStop方法，開屏後則呼叫onResume()（經自己實際測試小米上會呼叫onStop）；
問題：記憶體不足時系統會殺掉後臺的Activity，若需要進行一些臨時狀態的儲存，在哪個方法進行
Activity的 onSaveInstanceState() 和 onRestoreInstanceState()並不是生命週期方法，它們不同於 onCreate()、onPause()等生命週期方法，它們並不一定會被觸發。當應用遇到意外情況（如：記憶體不足、使用者直接按Home鍵）由系統銷燬一個Activity，onSaveInstanceState() 會被呼叫。但是當使用者主動去銷燬一個Activity時，例如在應用中按返回鍵，onSaveInstanceState()就不會被呼叫。除非該activity是被使用者主動銷燬的，通常onSaveInstanceState()只適合用於儲存一些臨時性的狀態，而onPause()適合用於資料的持久化儲存。
問題：onSaveInstanceState()被執行的場景有哪些；
系統不知道你按下HOME後要執行多少其他的程式，自然也不知道activity A是否會被銷燬，因此係統都會呼叫onSaveInstanceState()，讓使用者有機會儲存某些非永久性的資料。以下幾種情況的分析都遵循該原則
1.當使用者按下HOME鍵時；2.長按HOME鍵，選擇執行其他的程式時；3.鎖屏時；4.從activity A中啟動一個新的activity時；5.螢幕方向切換時。
問題：Activity場景記錄及恢復的原理
問題：Activity快取方法：
1.配置改變導致Activity被殺死，橫屏變豎屏：在onStop之前會呼叫onSaveInstanceState()儲存資料在重建Activity之後，會在onStart()之後呼叫onRestoreInstanceState(),並把儲存下來的Bundle傳給onCreate()和它會預設重建Activity當前的檢視，我們可以在onCreate()中，回覆自己的資料。
2.記憶體不足殺掉Activity，優先順序分別是：前臺可見，可見非前臺，後臺。
問題：同一個應用程式的不同Activity可以執行在不同的程式中麼？如果可以，舉例說明；
問題：Activity怎樣加速啟動
1、要顯示的activity的onCreate（）方法中不要進行耗時操作，減小主執行緒的阻塞時間。初始化的一次性操作可以放到onresume中。
2、前一個activity的onpause不要做耗時操作
3、優化佈局檔案， 如果我們的佈局層次巢狀過多,那麼view繪製的時間和findViewById的時間必然會變多。
4、使用多執行緒非同步逐漸顯示view
問題：怎樣退出終止APP
問題：Activity切換動畫
1、在android:theme 主題裡設定android:windowAnimationStyle
2、使用overridePendingTransition函式
2、Service----------1
分析篇：Service全面總結
問題：Service的生命週期，兩種啟動方法，有什麼區別：
1.context.startService() ->onCreate()- >onStart()->Service running-->(如果呼叫context.stopService() )->onDestroy() ->Service shut down
1.如果Service還沒有執行，則呼叫onCreate()然後呼叫onStart()；
2.如果Service已經執行，則只呼叫onStart()，所以一個Service的onStart方法可能會重複呼叫多次。
3.呼叫stopService的時候直接onDestroy，
4.如果是呼叫者自己直接退出而沒有呼叫stopService的話，Service會一直在後臺執行。該Service的呼叫者再啟動起來後可以通過stopService關閉Service。
2.context.bindService()->onCreate()->onBind()->Service running-->onUnbind() -> onDestroy() ->Service stop
1.onBind將返回給客戶端一個IBind介面例項，IBind允許客戶端回撥服務的方法，比如得到Service執行的狀態或其他操作。
2.這個時候會把呼叫者和Service繫結在一起，Context退出了,Service就會呼叫onUnbind->onDestroy相應退出。
3.所以呼叫bindService的生命週期為：onCreate --> onBind(只一次，不可多次繫結) --> onUnbind --> onDestory。
問題：onStartCommand()的返回值是一個很奇怪的值START_STICKY，這是個什麼呢？或者說這個方法的返回值是用來幹嘛的呢？
事實上，它的返回值是用來指定系統對當前執行緒的行為的。它的返回值必須是以下常量之一：
START_NOT_STICKY : 如果系統在 onStartCommand() 返回後終止服務，則除非有掛起 Intent 要傳遞，否則系統不會重建服務。這是最安全的選項，可以避免在不必要時以及應用能夠輕鬆重啟所有未完成的作業時執行服務。
START_STICKY : 如果系統在 onStartCommand() 返回後終止服務，則會重建服務並呼叫 onStartCommand()，但絕對不會重新傳遞最後一個 Intent。相反，除非有掛起 Intent 要啟動服務（在這種情況下，將傳遞這些 Intent ），否則系統會通過空 Intent 呼叫 onStartCommand()。這適用於不執行命令、但無限期執行並等待作業的媒體播放器（或類似服務）。
START_REDELIVER_INTENT : 如果系統在 onStartCommand() 返回後終止服務，則會重建服務，並通過傳遞給服務的最後一個 Intent 呼叫 onStartCommand()。任何掛起 Intent 均依次傳遞。這適用於主動執行應該立即恢復的作業（例如下載檔案）的服務。
注意點：Android5.0後隱式啟動service會報Service Intent must be explicit
問題：說下IntentService原理
IntentService已經做了這些事：
建立預設的工作執行緒，用於在應用的主執行緒外執行傳遞給 onStartCommand() 的所有 Intent
建立工作佇列，用於將一個 Intent 逐一傳遞給 onHandleIntent() 實現，這樣的話就永遠不必擔心多執行緒問題了
在處理完所有啟動請求後停止服務，從此媽媽再也不用擔心我忘記呼叫 stopSelf() 了
提供 onBind() 的預設實現（返回 null）
提供 onStartCommand() 的預設實現，可將 Intent 依次傳送到工作佇列和 onHandleIntent() 實現
問題：IntentService與Service的區別
IntentService是Service的子類，是一個非同步的，會自動停止的服務，很好解決了傳統的Service中處理完耗時操作忘記停止並銷燬Service的問題
會建立獨立的worker執行緒來處理所有的Intent請求；
會建立獨立的worker執行緒來處理onHandleIntent()方法實現的程式碼，無需處理多執行緒問題；
所有請求處理完成後，IntentService會自動停止，無需呼叫stopSelf()方法停止Service；
為Service的onBind()提供預設實現，返回null；
為Service的onStartCommand提供預設實現，將請求Intent新增到佇列中；
IntentService不會阻塞UI執行緒，而普通Serveice會導致ANR異常
Intentservice若未執行完成上一次的任務，將不會新開一個執行緒，是等待之前的任務完成後，再執行新的任務，等任務完成後再次呼叫stopSelf()
問題：如何保證一個後臺服務不被殺死；比較省電的方式是什麼
分析篇：保證service不被殺死
終極解決方案:Android應對程式被殺死--Service（二）
使用Jni,在 c端 fork程式，檢測Service是否存活，若Service已被殺死，則進行重啟Service.
至於檢測方式，可以輪詢獲取子程式Pid,若為1, 則說明子程式被Init程式所領養,已經成為了孤兒程式.
但是這種方式比較消耗電量，並且由於不同手機系統定製的改變，當應用被強制停止時，父程式並不一定被真正殺死，因此在一些特定機型上是無法通過此方式進行判斷.這裡推薦使用liunx socket的方式進行類似心跳包的檢測，並且當觸發檢測Service是否被殺死之前，需要判斷應用是否已經被解除安裝，如果應用已經被解除安裝，則不再進行檢測Service行為，直接呼叫exit(0)退出子程式，避免浪費系統資源和消耗電量.
注意: 目前在Android5.0系統上會把fork出來的程式放到一個程式組裡， 當程式主程式掛掉後，也會把整個程式組殺掉,因此用fork的方式也無法在Android5.0及以上系統實現守護程式. 這個是系統層面的限制，當然也是為了優化整個的系統環境,守護程式給手機帶來的體驗並不好
1、利用service自己的機制.在onStartCommand中設定引數為START_STICKY，記憶體不足被殺死記憶體有的時候會重新建立，短時間5次限制。
2、設定Android:persistent="true"。
3、提升service優先順序android:priority。
4、提升service程式優先順序,可以繫結通知欄成為前臺服務，在service中建立一個notification，startForeground；nDestory方法中需要通過stopForeground(true)來取消前臺執行狀態。
5、 android:process=”com.xxx.xxxservice”配置到單獨的程式中
6、onDestroy方法裡重啟service。
7、監聽系統廣播判斷Service狀態，手機重啟、介面喚醒、應用狀態改變等等監聽並捕獲到，然後判斷我們的Service是否還存活去啟動。
8、雙程式Service： 讓2個程式互相保護**，其中一個Service被清理後，另外沒被清理的程式可以立即重啟程式
9、加上兩個類似於守護程式的Service， 分別檢查Service的執行狀態，註冊響應的廣播，對其進行守護,一旦發現沒有執行就將其啟動.我利用的系統廣播是Intent.ACTION_TIME_TICK，這個廣播每分鐘傳送一次，我們可以每分鐘檢查一次Service的執行狀態，如果已經被結束了，就重新啟動Service。它的優點就是間隔時間短而且非常穩定, 而其他的廣播並不能保證這一點,當然，在具體的應用中還是要根據需求使用, 結合其他廣播來保證自己的service一定會被重啟.
10、通過jni呼叫，在c層啟動多程式 fork 機制建立 Native 程式監聽主程式，為純Linux程式生命週期不受android的控制，適用於5.0以下。
(要在 Native 程式中感知主程式是否存活有兩種實現方式：
10.1、在 Native 程式中通過死迴圈或定時器，輪訓判斷主程式是否存活，檔主程式不存活時進行拉活。該方案的很大缺點是不停的輪詢執行判斷邏輯，非常耗電。
10.2、在主程式中建立一個監控檔案，並且在主程式中持有檔案鎖。在拉活程式啟動後申請檔案鎖將會被堵塞，一旦可以成功獲取到鎖，說明主程式掛掉，即可進行拉活。由於 Android 中的應用都執行於虛擬機器之上，Java層的檔案鎖與 Linux 層的檔案鎖是不同的，要實現該功能需要封裝 Linux 層的檔案鎖供上層呼叫。)
11、5.0以上利用 JobScheduler 機制拉活，系統會定時呼叫該程式以使應用進行一些邏輯操作。
12、利用賬號同步機制拉活，Android 系統的賬號同步機制會定期同步賬號進行
13、QQ黑科技: 在應用退到後臺後，另起一個只有 1 畫素的頁面停留在桌面上，讓自己保持前臺狀態，保護自己不被後臺清理工具殺死
14、在已經root的裝置下，修改相應的許可權檔案,將App偽裝成系統級的應用Android4.0系列的一個漏洞，已經確認可行
15、在NDK環境中將1中編寫的C程式碼編譯打包成可執行檔案(BUILD_EXECUTABLE)。主程式啟動時將守護程式放入私有目錄下，賦予可執行許可權，啟動它即可。
16、聯絡廠商，加入白名單
問題：註冊Service需要注意什麼
Service還是執行在主執行緒當中的，所以如果需要執行一些複雜的邏輯操作，最好在服務的內部手動建立子執行緒進行處理，否則會出現UI執行緒被阻塞的問題
問題：Service與Activity怎麼實現通訊
方法一：
1、新增一個繼承Binder的內部類，並新增相應的邏輯方法
2、Messager
3、AIDL
方法二：
通過BroadCast(廣播)的形式 當我們的進度發生變化的時候我們傳送一條廣播，然後在Activity的註冊廣播接收器，接收到廣播之後更新檢視
3、BroadcastReceiver----------1
問題：註冊廣播接收器有哪幾種方式,有什麼區別
靜態註冊：在AndroidManifest.xml檔案中進行註冊，當App退出後，Receiver仍然可以接收到廣播並且進行相應的處理
動態註冊：在程式碼中動態註冊，當App退出後，也就沒辦法再接受廣播了
問題：如何通過廣播攔截和abort一條簡訊；
要攔截首先設定許可權：android.permission.SEND_SMS，android.permission.RECEIVE_SMS，設定receiver的優先順序為最高1000，acticion為android.provider.Telephony.SMS_RECEIVED。
在4.4前，簡訊攔截都是通過動態註冊高優先順序BroadcastReceiver的方式進行攔截的，主要是用於跟競品進行簡訊搶佔。而現在ContenetObserver是並行通知的情況下，如果過濾邏輯不夠快，依然有可能會被競品搶先把簡訊先刪除掉，導致拿到的最後一次簡訊是舊的簡訊。建議結合BroadcastReceiver和ContenetObserver進行攔截，BroadcastReceiver做內容校正和後備資料，以防拿到的最後一條簡訊是舊的時候，依然可以進行正常的攔截流程；
4.4以上引入了default sms機制，我們可以在不成為default sms的前提下實現簡訊攔截，利用App Ops許可權管理功能，
但由於App Ops從4.3出現到4.4一直牌隱藏的狀態，猜想google還在不斷調整中；
Write SMS/MMS的許可權開關的存在跟defaultsms本身是一個矛盾，之所以出現Write SMS/MMS的許可權開關，完全是因為App Ops出現在前，而defaultsms出現在後所致。
6.0以上引入了新的動態許可權管理，類似於iOS中的許可權。6.0以前是在安裝時一次性獲取許可權，6.0之後是在執行的時候選擇。
問題：廣播是否可以請求網路；
網路狀態發生變化的時候，系統會發出 android.NET.conn.CONNECTIVITY_CHANGE，在onreceiver中使用ConnectivityManager監聽網路狀態，從4.0 開始所有的網路請求都需要線上程中，廣播請求網路同理 開啟執行緒線上程中請求網路
問題：廣播引起anr的時間限制
10秒鐘，所以在Onceive中耗時的操作一般新開執行緒處理
4、ContentProvider ----------1
問題：許可權管理
讀寫分離(exported=true讀設定Android:readPermission,寫設定android:writePermisson
問題：許可權控制-精確到表級(匹配URI)，URL控制
5、Fragment ----------1
MS思考：Android面試一天一題（Day 24: 悲催的Fragment）
分析篇：Fragment 全解析
問題：Fragment生命週期
onAttach繫結activity,oncreate,onActivitycreated:Activity的onCreate方法已經執行完成並返回,onstart,onresume,onpause,onstop,onDesdroyview,onDesdroy,ondettach解除繫結；
問題：Fragment狀態儲存
人為返回出棧不呼叫onSaveInstanceState，在ondesdroy中儲存（儲存在能和Fragment一起共存的Argument：Bundle b = getArguments();），恢復狀態在onActivityCreated中
問題：fragement裡面可以再巢狀fragment？
getChildFragmentManager()
Android Fragment使用(二) 巢狀Fragments (Nested Fragments) 的使用及常見錯誤
6、Intent----------1
問題：顯示Intent與隱式Intent的區別
對明確指出了目標元件名稱的Intent，我們稱之為“顯式Intent”。 對於沒有明確指出目標元件名稱的Intent，則稱之為“隱式 Intent”。
對於隱式意圖，在定義Activity時，指定一個intent-filter，當一個隱式意圖物件被一個意圖過濾器進行匹配時，將有三個方面會被參考到：
動作(Action)
類別(Category ['kætɪg(ə)rɪ] )
資料(Data )
問題：Intent可以傳遞哪些資料型別
1.Serializable
2.charsequence: 主要用來傳遞String，char等
3.parcelable
4.Bundle
7、動畫----------1
問題：Android中的動畫有哪些，區別是什麼
逐幀動畫(Drawable Animation)： 載入一系列Drawable資源來建立動畫，簡單來說就是播放一系列的圖片來實現動畫效果，可以自定義每張圖片的持續時間
補間動畫(Tween Animation)： Tween可以對View物件實現一系列簡單的動畫效果，比如位移，縮放，旋轉，透明度等等。但是它並不會改變View屬性的值，只是改變了View的繪製的位置，比如，一個按鈕在動畫過後，不在原來的位置，但是觸發點選事件的仍然是原來的座標。
屬性動畫(Property Animation)： 動畫的物件除了傳統的View物件，還可以是Object物件，動畫結束後，Object物件的屬性值被實實在在的改變了
問題：動畫的原理：
1.動畫的基本原理：其實就是利用插值器和估值器，來計算出各個時刻View的屬性，然後通過改變View的屬性來，實現View的動畫效果。
2.View動畫:只是影像變化，view的實際位置還在原來的地方。
3.幀動畫是在xml中定義好一系列圖片之後，使用AnimationDrawable來播放的動畫。
4.View的屬性動畫：
1.插值器：作用是根據時間的流逝的百分比來計算屬性改變的百分比
2.估值器：在1的基礎上由這個東西來計算出屬性到底變化了多少數值的類
問題：不使用動畫，怎麼實現一個動態的 View？
1、利用執行緒改變view的位置大小等
2、自定義view重繪
問題：View的補間動畫有哪幾種？補間動畫效果的實現原理
8、ListView----------1
問題：怎麼實現一個部分更新的 ListView？
intvisiblePosition = mListView.getFirstVisiblePosition();
//只有當要更新的view在可見的位置時才更新，不可見時，跳過不更新
if(itemIndex - visiblePosition >=0) {
//得到要更新的item的view
View view = mListView.getChildAt(itemIndex - visiblePosition);
問題：怎麼實現ListView多種佈局？
問題：ListView與資料庫繫結的實現
9、View相關----------1
問題：Postvalidata與Validata有什麼區別？
Validata只能在工作執行緒呼叫，Postvalidata內部使用了handler實現，可在工作執行緒呼叫
10、RecyclerView----------1
11、Scrollview----------1
問題：Scrollview怎麼判斷是否滑倒底部
android:怎麼判斷android中ScrollView滑動到了最底部?
12、Context----------1
問題：Context與ApplicationContext的區別，分別用在什麼情況下
ApplicationContext的生命週期是與Application的生命週期相關的，context隨著Application的銷燬而銷燬，伴隨application的一生，與activity的生命週期無關.第二種中的context跟Activity的生命週期是相關的，但是對一個Application來說，Activity可以銷燬幾次，那麼屬於Activity的context就會銷燬多次。
Application的Context是一個全域性靜態變數，SDK的說明是隻有當你引用這個context的生命週期超過了當前activity的生命週期，而和整個應用的生命週期掛鉤時，才去使用這個application的context。
在android中context可以作很多操作，但是最主要的功能是載入和訪問資源。在android中有兩種context，一種是 application context，一種是activity context，通常我們在各種類和方法間傳遞的是activity context。
在使用context的時候，小心記憶體洩露，防止記憶體洩露，注意一下幾個方面：
1. 不要讓生命週期長的物件引用activity context，即保證引用activity的物件要與activity本身生命週期是一樣的
2. 對於生命週期長的物件，可以使用application context
3. 避免非靜態的內部類，儘量使用靜態類，避免生命週期問題，注意內部類對外部物件引用導致的生命週期變化
問題：Application（或者Service）和Activity都可以呼叫Context的startActivity方法，那麼在這兩個地方呼叫startActivity有區別嗎？
Application（或者Service）需要給Intent設定Intent.FLAG_ACTIVITY_NEW_TASK才能正常啟動Activity，Application（或者Service）需要給Intent設定Intent.FLAG_ACTIVITY_NEW_TASK才能正常啟動Activity
問題：Context的例項是什麼時候建立的？一個應用裡面會有幾個Context的例項？
Context數量 = Activity數量 + Service數量 + 1（Application）
問題：為什麼Dialog不能用Application的Context
13、佈局相關----------1
三、程式執行緒
1、程式----------1
問題：多程式開發以及多程式應用場景
例子：音樂播放服務，雲平臺客戶端的同步服務
問題：多程式的好處
（1）Android系統對每個應用程式的記憶體佔用是有限制的，佔用記憶體越大的程式，通常被系統殺死的可能性越大。讓一個元件執行在單獨的程式中，可以減少主程式所佔用的記憶體，降低被系統殺死的概率；
（2）如果子程式因為某種原因崩潰了，不會直接導致主程式的崩潰，可以降低主程式崩潰的概率；
（3）即使主程式退出了，子程式仍然可以繼續工作，比如子程式是推送服務，在主程式退出的情況下，仍然能夠保證使用者可以收到推送訊息。
問題：多程式使用場景
（1）BroadcastReceiver
一個程式傳送廣播，可以啟動其他程式的BroadcastReceiver。拿到清單檔案中BroadcastReceiver的intentFilter中的action屬性值，可以在另一個應用中傳送廣播啟動當前應用裡的BroadcastReceiver。
（2）ContentProvider
一個應用通過ContentProvider向其他的應用暴露自己的資料，供其他應用訪問
（3）啟動其他應用的activity或者service
2、執行緒----------1
問題：什麼時候使用CountDownLatch
問題：HandlerThread、Thread、Asynctask原理與區別
問題：生產者與消費者，手寫程式碼 ****（多執行緒同步的框架的實現原理，以及如何用生產者消費者模型解決同步問題）
3、Socket程式設計
問題：socket短線重連怎麼實現，心跳機制又是怎樣實現，四次握手步驟有哪些（網路通訊原理）
4、ThreadLocal
四、資料儲存
問題：資料持久化的四種方式有哪些？
檔案儲存： 通過java.io.FileInputStream和java.io.FileOutputStream這兩個類來實現對檔案的讀寫，java.io.File類則用來構造一個具體指向某個檔案或者資料夾的物件。
SharedPreferences： SharedPreferences是一種輕量級的資料儲存機制，他將一些簡單的資料型別的資料，包括boolean型別，int型別，float型別，long型別以及String型別的資料，以鍵值對的形式儲存在應用程式的私有Preferences目錄（/data/data/<包名>/shared_prefs/）中，這種Preferences機制廣泛應用於儲存應用程式中的配置資訊。
SQLite資料庫： 當應用程式需要處理的資料量比較大時，為了更加合理地儲存、管理、查詢資料，我們往往使用關聯式資料庫來儲存資料。Android系統的很多使用者資料，如聯絡人資訊，通話記錄，簡訊息等，都是儲存在SQLite資料庫當中的，所以利用操作SQLite資料庫的API可以同樣方便的訪問和修改這些資料。
ContentProvider: 主要用於在不同的應用程式之間實現資料共享的功能，不同於sharepreference和檔案儲存中的兩種全域性可讀寫操作模式，內容提供其可以選擇只對哪一部分資料進行共享，從而保證我們程式中的隱私資料不會有洩漏的風險
解析xml：
問題：Json有什麼優劣勢
分析篇：Json優劣勢
1.JSON的速度要遠遠快於XML
2.JSON相對於XML來講，資料的體積小
3.JSON對資料的描述性比XML較差
問題：資料庫的知識，包括本地資料庫優化點。
相關文章
- WebSocket系列之基礎知識入門篇Web
- SecureFiles LOBs基礎知識之儲存篇
- Android面試之——數學基礎知識Android面試
- Android基礎知識Android
- Linux基礎知識複習之命令篇Linux
- MySql基礎知識（2）MySql
- Android知識點回顧之Activity基礎Android
- Android知識點回顧之Service基礎Android
- Java基礎知識回顧之七 —– 總結篇Java
- Java基礎知識回顧之七 ----- 總結篇Java
- Go 基礎教程--2-基礎知識Go
- Java基礎知識篇05——方法Java
- GO基礎知識分享2Go
- OBD2基礎知識
- Android基礎知識之拼寫檢查框架Android框架
- MySQL指南之基礎知識MySql
- Android基礎知識學習Android
- Android應用基礎知識Android
- Android NDK學習筆記1-基礎知識篇Android筆記
- Java&Android 基礎知識梳理(2) 序列化JavaAndroid
- Flutter 知識點總結-基礎篇Flutter
- Java基礎知識篇02——封裝Java封裝
- Java基礎知識題集（2）Java
- 嵌入式基礎（2）---硬體基礎知識
- Python基礎知識之字典Python
- Python基礎知識之集合Python
- Java基礎知識整理之this用法Java
- Java基礎知識之概述（一）Java
- php基礎知識之$GET$POSTPHP
- oracle spatial 基礎知識之五Oracle
- 安卓(Android)開發基礎知識安卓Android
- Android 基礎知識——執行緒Android執行緒
- Android中的RecyclerView: 基礎知識AndroidView
- 移動端適配 - 基礎知識篇
- Java個人知識點總結（基礎篇）Java
- 前端開發基礎知識整理–css篇前端CSS
- Java基礎知識篇——Java基本介紹Java
- yii2 基礎知識總結