父類的普通方法可以被繼承和重寫,不多作解釋,如果子類繼承父類,而且子類沒有重寫父類的方法,但是子類會有從父類繼承過來的方法。
靜態的方法可以被繼承,但是不能重寫。如果父類中有1個靜態的方法,子類也有1個與其方法名,參數類型,參數個數都1樣的方法,并且也有static關鍵字修飾,那末該子類的方法會把原來繼承過來的父類的方法隱藏,而不是重寫。通俗的講就是父類的方法和子類的方法是兩個沒有關系的方法,具體調用哪個方法是看是哪一個對象的援用;這類父子類方法也不在存在多態的性質。《Java編程思想》中這樣提到“只有普通的方法調用可以是多態的”。
>
作甚靜態?靜態方法是類在加載時就被加載到內存中的方法,在全部運行進程中保持不變,因此不能重寫。但非靜態方法是在對象實例化時才單獨申請內存空間,為每個實例分配獨立的運行內存,因此可以重寫。
1、Vector是多線程安全的,而ArrayList不是,這個可以從源碼中看出,Vector類中的方法很多有synchronized進行修飾,這樣就致使了Vector在效力上沒法與ArrayList相比;
2、兩個都是采取的線性連續空間存儲元素,但是當空間不足的時候,兩個類的增加方式是不同的,很多網友說Vector增加原來空間的1倍,ArrayList增加原來空間的50%,其實也差不多是這個意思,不過還有1點點問題可以從源碼中看出,1會兒從源碼中分析。
3、Vector可以設置增長因子,而ArrayList不可以,最開始看這個的時候,我沒理解甚么是增量因子,不過通過對照1下兩個源碼理解了這個,先看看兩個類的構造方法:
桌面小部件則是通過AppWidgetProvider來實現的,AppWidget本質是1個廣播.
通知欄和桌面小部件的開發進程中都會用到RemoteView,它們在更新界面時沒法像在Activity里面那樣直接更新View,這是由于二者的界面都運行在其他線程中,確切的說是系統的SystemServer進程.為了跨進程更新界面,RemoteViews提供1系列set方法,并且這些方法只是View全部方法的子集,另外RemoteVIew支持的View類型也是有限的。
surfaceView是在1個新起的單獨線程中可以重新繪制畫面,而View必須在UI的主線程中更新畫面。那末在UI的主線程中更新畫面 可能會引提問題,比如你更新畫面的時間太長,那末你的主UI線程會被你正在畫的函數阻塞。那末將沒法響應按鍵,觸屏等消息。當使用surfaceView 由因而在新的線程中更新畫面所以不會阻塞你的UI主線程。但這也帶來了另外1個問題,就是事件同步。比如你觸屏了1下,你需要surfaceView中 thread處理,1般就需要有1個event queue的設計來保存touch event,這會稍稍復雜1點,由于觸及到線程同步。
在Android中進程按優先級可以分為5類,優先級從高到低排列:
- 前臺進程 該進程包括正在與用戶進行交互的界面組件,比如1個Activity
- 可視進程 該進程中的組件雖然沒有和用戶交互,但是依然可以被看到
- 服務進程 該進程包括在履行后臺操作的服務組件,比如播放音樂的進程
- 后臺進程 該進程包括的組件沒有與用戶交互,用戶也看不到
- 空進程 沒有任何界面組件、服務組件,或觸發器組件**
Android系統是進程托管的,也就是說進程都是由系統來管理,系統會依照特定的算來來回收這些進程。在回收中秉持幾個原則
1. 盡可能延上進程的生命周期,不到必須的情況下不會回收,由于系統回收進程會影響用戶體驗
2. 按優先級從低到高進行回收
3. 同等優先級的進程越近使用越晚回收。
進程過1段時間后是會被回收的,但要遵守上面的這些原則,播放音樂的這個進程的優先級還是比較高的,所以被稀里糊涂地回收的可能性不大,在播放音樂時無緣無故地停止這樣的情況很少對吧?service和application的生命周期有關,只要進程被回收,那末它所占用的所有資源將被回收。
仔細分析在1個靜態成員的變量中保存了Activity里面的1個視圖,可惡的是視圖中保存了Context的援用,這個時候就產生了1個對象長時間被援用,致使Activity沒法被GC掉,Activity占用的內存也沒法被GC掉。這個時候內存溢動身生了。
淺談Android開發中內存泄漏與優化
http://m.blog.csdn.net/article/details?id=50581404
http://www.linuxidc.com/Linux/2015⑴2/126432.htm
eclipse的jni的開發,
dnk環境搭建
先要用編譯,在bin里,用javah編譯,生成.h文件。
編寫Android.mk文件
用gunstep生成so文件。
用Android studio 來開發jni
并發:
多個用戶爭取同1個資源(這個資源可以是服務器上的日志,可以是履行某1此sql操作,可使ftp服務器上的某個文件等,又或是程序中的某1個全局變量,因此我們可以稱這類資源為:全局資源);
解釋:
并發是在多個用戶要求同1個資源的時候,或是程序本身多線程要求同1個資源的時候釀成的。
比如:
1個財務系統,兩個人同時對總錢數進行操作,1個加10塊1個減100塊,注意這兩個操作是同時進行的,那系統就不知道是加還是減了,這是并提問題。或,多個線程同時要求同1個資源,必定致使此資源的數據不安全,A線程修改了B線程的處理的數據,而B線程又修改了A線程處理的數理(線程安全)。
異步:
A線程要要求某個資源,但是此資源正在被B線程使用中,由于沒有同步機制存在,A線程
依然要求的到這個資源,A線程無需等待。
同步:
A線程要要求某個資源,但是此資源正在被B線程使用中,由于同步機制存在,A線程要求
不到,怎樣辦,A線程只能等待下去。
同步與異步:
明顯,同步最安全,最保險的。而異步不安全,容易致使死鎖,這樣1個線程死掉就會致使全部
進程崩潰,但沒有同步機制的存在,性能會有所提升。所以對同步與異步必須有所取舍。
Java同步機制有4種實現方式:(部份援用網上資源)
① ThreadLocal ② synchronized( ) ③ wait() 與 notify() ④ volatile
目的:都是為了解決多線程中的對同1變量的訪問沖突
ThreadLocal
ThreadLocal 保證不同線程具有不同實例,相同線程1定具有相同的實例,即為每個使用該
變量的線程提供1個該變量值的副本,每個線程都可以獨立改變自己的副本,而不是與其它線程的副本沖突。
優勢:提供了線程安全的同享對象
與其它同步機制的區分:同步機制是為了同步多個線程對相同資源的并發訪問,是為了多個線程之間進行通訊;而 ThreadLocal 是隔離多個線程的數據同享,從根本上就不在多個線程之間同享資源,這樣固然不需要多個線程進行同步了。
volatile
volatile 修飾的成員變量在每次被線程訪問時,都逼迫從同享內存中重讀該成員變量的值。
而且,當做員變量產生變化時,逼迫線程將變化值回寫到同享內存。
優勢:這樣在任什么時候刻,兩個不同的線程總是看到某個成員變量的同1個值。
緣由:Java 語言規范中指出,為了取得最好速度,允許線程保存同享成員變量的私有拷貝,而
且只當線程進入或離開同步代碼塊時才與同享成員變量的原始值對照。這樣當多個線程同時與某
個對象交互時,就必須要注意到要讓線程及時的得到同享成員變量的變化。而 volatile 關鍵字就
是提示 VM :對這個成員變量不能保存它的私有拷貝,而應直接與同享成員變量交互。
使用技能:在兩個或更多的線程訪問的成員變量上使用 volatile 。當要訪問的變量已在
synchronized 代碼塊中,或為常量時,沒必要使用。
線程為了提高效力,將某成員變量(如A)拷貝了1份(如B),線程中對A的訪問其實訪問的
是B。只在某些動作時才進行A和B的同步,因此存在A和B不1致的情況。volatile就是用來避免這類
情況的。 volatile告知jvm,它所修飾的變量不保存拷貝,直接訪問主內存中的(讀操作多時使用
較好;線程間需要通訊,本條做不到)
Volatile 變量具有 synchronized 的可見性特性,但是不具有原子特性。這就是說線程能夠自
動發現 volatile 變量的最新值。Volatile 變量可用于提供線程安全,但是只能利用于非常有限的
1組用例:多個變量之間或某個變量確當前值與修改后值之間沒有束縛。
您只能在有限的1些情形下使用 volatile 變量替換鎖。要使 volatile 變量提供理
想的線程安全,必須同時滿足下面兩個條件:
對變量的寫操作不依賴于當前值;該變量沒有包括在具有其他變量的不變式中。
sleep() vs wait()
sleep是線程類(Thread)的方法,致使此線程暫停履行指定時間,把履行機會給其他線程,但是監
控狀態仍然保持,到時后會自動恢復。調用sleep不會釋放對象鎖。
wait是Object類的方法,對此對象調用wait方法致使本線程放棄對象鎖,進入等待此對象的等待鎖
定池,只有針對此對象發出notify方法(或notifyAll)后本線程才進入對象鎖定池準備取得對象鎖
進入運行狀態。
(如果變量被聲明為volatile,在每次訪問時都會和主存1致;如果變量在同步方法或同步塊中
被訪問,當在方法或塊的入口處取得鎖和方法或塊退出時釋放鎖時變量被同步。)
9.1自定義view
9.2圖表,柱狀圖
9.3新特性view
Android開發之RecyclerView的使用全解
HTTP協議狀態碼表示的意思主要分為5類 ,大體是 :
1×× 保存
2×× 表示要求成功地接收
3×× 為完成要求客戶需進1步細化要求
4×× 客戶毛病
5×× 服務器毛病
AsyncTask的本質是1個線程池,所有提交的異步任務都會在這個線程池中的工作線程內履行,當工作線程需要跟UI線程交互時,工作線程會通過向在UI線程創建的Handler(原理見:《Handler+Looper+MessageQueue深入詳解》)傳遞消息的方式,調用相干的回調函數,從而實現UI界面的更新。
1、 AsyncTask的本質是1個靜態的線程池,AsyncTask派生出的子類可以實現不同的異步任務,這些任務都是提交到靜態的線程池中履行。
2、線程池中的工作線程履行doInBackground(mParams)方法履行異步任務
3、當任務狀態改變以后,工作線程會向UI線程發送消息,AsyncTask內部的InternalHandler響應這些消息,并調用相干的回調函數
handler不是不可以在子線程里生成,生成時,需要prepare,否則報錯。
具體見博客。
1般大家都知道ArrayList和LinkedList的大致區分:
1.ArrayList是實現了基于動態數組的數據結構,LinkedList基于鏈表的數據結構。
2.對隨機訪問get和set,ArrayList覺得優于LinkedList,由于LinkedList要移動指針。
3.對新增和刪除操作add和remove,LinedList比較占優勢,由于ArrayList要移動數據。
當Android系統啟動1個利用的時候,有1步是對Dex進行優化,這個進程有1個專門的工具來處理,叫DexOpt。DexOpt的履行進程是在第1次加載Dex文件的時候履行的。這個進程會生成1個ODEX文件,即Optimised Dex。履行ODex的效力會比直接履行Dex文件的效力要高很多。但是在初期的Android系統中,DexOpt有1個問題,也就是這篇文章想要說明并解決的問題。DexOpt會把每個類的方法id檢索起來,存在1個鏈表結構里面。但是這個鏈表的長度是用1個short類型來保存的,致使了方法id的數目不能夠超過65536個。當1個項目足夠大的時候,明顯這個方法數的上限是不夠的。雖然在新版本的Android系統中,DexOpt修復了這個問題,但是我們依然需要對老系統做兼容。
android studio 中這樣做
android{
defaultConfig {
...
// Enabling multidex support.
multiDexEnabled true
}
dexOptions {
javaMaxHeapSize "4g" //set the max heap size for dexing to 4GB.
incremental true
}
}
dependencies {
//compile fileTree(include: ['*.jar'], dir: 'libs')
//compile project(':library')
compile 'com.android.support:multidex:1.0.1'
...
}
利用了甚么框架
框架是何種原理
github項目地址
HttpClient和HttpURLConnection的區分
github地址
android 介紹Retrofit的簡單使用
Retrofit原理及調用流程分析
github地址
Android-xUtils框架原理分析
比較好的,就是下面這倆個,
騰訊im 免費,企業和個人
網易云信 個人有期限,企業收費
bugly
bghd
vitamio
ijkplayer
vlc
https://github.com/JakeWharton/butterknife
MVC之外的另兩種軟件架構(ORM,IOC)
mvp
使用新版Android Studio檢測內存泄漏和性能
移動項目:開發,項目經理
個人倉庫
無線電管理監測
智能玩具交互
黨建加油站 視頻播放器
混合開發:rn,cordova
后臺:
spring hibernate
node