Android 開發藝術探索看不懂對著書敲慢慢理解，設計模式之禪總結，平時記錄的筆記，3w多次字防止丟失，留存。-有解無憂

知識點1：

1.子執行緒為什么不允許訪問ui因為android中的ui控制元件不是執行緒安全的，

2.為什么不給Ui加上鎖的機制，第一點會讓ui訪問的邏輯變得復雜，其次降低ui訪問的效率，

3.List轉化成String[]

		public static String[] toStringArray(List<String> strList) {
			String[] array = new String[strList.size()];
			strList.toArray(array);
			return array;
			}

4.webview中的常用方法

(1)goBack():后退，
(2)goForward():前進，
(3)loadUrl(String url):加載指定URL對應的網頁
(4)boolean zoomIn():放大網頁，
(5)boolean zoomOut():縮小網頁，

5.解決ScrollView嵌套listview只顯示一行item得問題
重寫listview

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec)
{    heightMeasureSpec=MeasureSpec.makeMeasureSpec(Integer.MAX_VALUE>>2,MeasureSpec.AT_MOST);
        super.onMeasure(widthMeasureSpec, heightMeasureSpec);
    }

6.activity切換時的overridePendingTransition影片效果：

第一個引數為第一個Activity離開時的影片，第二引數為所進入的Activity的影片效果
淡入淡出效果
Activity.overridePendingTransition(R.anim.fade, R.anim.hold);
放大淡出效果
overridePendingTransition(R.anim.my_scale_action,R.anim.my_alpha_action);
轉動淡出效果
overridePendingTransition(R.anim.scale_rotate,R.anim.my_alpha_action);
轉動淡出效果
overridePendingTransition(R.anim.scale_translate_rotate,R.anim.my_alpha_action);
左上角展開淡出效果
overridePendingTransition(R.anim.scale_translate,R.anim.my_alpha_action);
壓縮變小淡出效果
overridePendingTransition(R.anim.hyperspace_in,R.anim.hyperspace_out);
右往左推出效果
overridePendingTransition(R.anim.push_left_in,R.anim.push_left_out);
下往上推出效果
overridePendingTransition(R.anim.push_up_in,R.anim.push_up_out);
左右交錯效果
overridePendingTransition(R.anim.slide_left,R.anim.slide_right);
放大淡出效果
overridePendingTransition(R.anim.wave_scale,R.anim.my_alpha_action);
縮小效果
overridePendingTransition(R.anim.zoom_enter,R.anim.zoom_exit);
上下交錯效果
overridePendingTransition(R.anim.slide_up_in,R.anim.slide_down_out);

7.app的版本時在build中的defaultConfig中的versionName中設定的，

知識點2：

1.獲取手機螢屏的密度

	float xdpi = getResources().getDisplayMetrics().xdpi;
	float ydpi = getResources().getDisplayMetrics().ydpi;

2.androidstudio中全域替換字串，在包的下面右邊replace in path

3.廣播在不通的包下面，接受要加上Intent.addFlags(0x01000000);

4.通過jks檔案查看簽名

keytool -list -v -keystore D:\companyjks\aaaa-storepass 123456

5.intent在頁面之間跳轉時只可以帶上keyvalue形式的資料，可以把物件繼承Serializablera(序列化)然后就可以直接講物件傳輸過去，

6.Onstart和onstop是從Activity是否可見的角度去分析
OnResume和onPauser是從activity是否在前臺的角度去分析的

7.adb shell ps 或者adb shell ps|grep 包名可以查看當前的行程資訊

行程名以:開頭的行程屬于私有行程 不以:開頭的行程屬于全域行程，其他應用可以通過	ShareUID的方式可以和他跑在同一個行程中，

8.序列化時應該手動指定serialVersionUID的值，如過不指定，系統會自動生成hashcode值，這樣的話如果增加或者洗掉了變數，則反序列化會失敗，指定了serialVersionUID的值之后就不會，但是類的結構大聲改變之后，就算指定了serialVersionUID的值也不會反序列化成功，

9.影片：

(1)ScrollTo/ScrollBy:操作簡單，適合對View內容的話哦的那個
(2)影片：操作簡單，主要適用于沒有互動的view和實作復雜的影片效果
(3)改變布局引數：操作稍微復雜，適用于有互動的view，

10.直接用資料線去安裝apk

adb install -r 應用程式.Apk，

11.使用adb命令去啟動一個Activity

Adb shell am start -n  com.adam.collection.test/com.adam.collection.test.ui.MainActivity，

12.在View提供的方法當中:

getTop():獲取到的是View自身的頂邊到父布局頂邊的距離
getLeft():獲取到的是View自身的左邊到父布局左邊的距離
getRight():獲取到的是View自身的右邊邊到父布局左邊的距離
getBotton():獲取到的是View自身的底邊到父布局頂邊的距離

在MotionEvient提供的方法中：

getX():獲取點擊事件距離控制元件左邊的距離，即視圖坐標
getY():獲取點擊事件距離控制元件頂邊的距離，即視圖坐標
getRawX():獲取點擊事件距離整個螢屏左邊的距離，即絕對坐標
getRawY():獲取點擊事件距離整個螢屏頂邊的距離，即絕對坐標

13:Androuid布局優化：

1.避免重繪ui,性能浪費
2.優化布局層級，view樹不要太高，層級嵌套不要太深
3.使用include復用公共的布局
4.使用viewStub 區別于Gone是他在初始化時不會去加載
5.hierarchyviewer工具去快速找到樹中冗余的布局
6LinearLayout比RelativeLayout性能好，RelativeLayout的功能比較復雜，會花費更多的cpu時間，但是在嵌套的時候，RelativeLayout的性能優于LinearLayout，
7.merge標簽 在嵌套時，如果include里面的布局跟外部一樣，里面的布局可以用merge來替代，來去除多余重復的層級
8.在自定義繪制view的時候  在onDraw方法中避免執行大量的耗時操作，會造成頁面的卡頓，
9.不要用靜態變數去參考當前的 context會造成Activity泄露，記憶體無法釋放，
10.Activity的物件被單例模式所持有，而單例模式的特點是其生命周期和Applicatio保持一致，因此Activity物件無法被及時釋放，
11.屬性影片：從Android3.0開始，Google提供了屬性影片，其中有一類無限回圈的影片，如果在Activity中播放此類影片且沒有在onDestory中停止影片，那么影片會一直播放下去，盡管已經無法在界面上看到影片效果了，并且這個時候Activity的View會被影片持有，而View又持有了Activity,最終Activity無法釋放，下面的影片是無限影片，會泄露當前Activity,解決方法是在Activity的onDestory中嗲用animator.cancel()來停止影片，

14:Android記憶體優化

Bitmap優化：使用適合解析度和大小的圖片，及時回收記憶體，使用圖片快取，

代碼優化：

1.對常量使用static修飾符
2.使用靜態方法，靜態方法會比普通方法提高15%左右的訪問速度
3.減少不必要的成員變數，這點在Androidlint工具上已經集成檢測了，如果一個變數可以定義為區域變數，則會建議你不要定義為成員變數，
4.減少不必要的物件，使用基礎型別會比使用物件更加節省資源，同時更應該避免頻繁創建短作用域的變數
5.盡量不要使用列舉，少用迭代器，列舉占用的記憶體空間要比整型大
6.對Cursor,ReCeiver,Sensor，File等物件，要非常注意對他們的創建，回收與注冊，解注冊
7.避免使用ioc框架，ioc通常使用注解，反射來進行實作，雖然現在java對反射的效率已經進行了很好的優化，但大量使用反射依然會帶來性能的下降
8.使用RenderScript,OpenGl來進行非常復雜的繪圖操作
9.使用SurfaceView來代替view進行大量 頻繁的繪圖操作
//SurfaceView適合頻繁更新，被動更新的試圖，像股票曲線
//view適合自己主動去更新視圖
10.盡量使用視圖快取，而不是每次都執行inflate方法決議視圖，
11.常量請使用static final來修飾
15:記憶體泄露分析工具MAT

設計模式知識點：

單例模式：
1.在sInstance=new Singleton時有三條原子操作：
(1)給Singleton的實力分配記憶體，
(2)呼叫Singleton()的建構式，初始化成員欄位
(3)講sInstance物件指向分配的記憶體空間（此時sInstance就不是null了），
由于編譯器亂序執行可能 1，3，2的順序去執行呼叫3之后被拿走使用了就會出錯
還很難復現，可以給sInstance加上一個Volatile關鍵字，雖然會影響性能，但是程式的正確性也很重要，
單例模式一般沒有介面，擴展很困難，若要擴展，除了修改代碼基本上沒有第二種途徑可以實作，單例物件如何持有Context，那么很容易引發記憶體泄漏，此時需要注意傳遞給單例物件的Context最好時Application Context 參考使用Activity的Context話會造成Activity無法釋放，
工廠方法模式：
產品實作類實作抽象產品方法，工廠實作類實作工廠抽象方法，工廠實作鏟平的生產
抽象工廠模式：
在工廠方法模式的基礎上添加介面，把方法都放在抽象方法中，由子類去實作，他的優點時高層不需要去關心產品時怎么實作的，只需要找到工廠類讓他去創建就可以了，（女媧造人）
模板方法模式：
在抽象類中有基本方法跟模板方法，模板方式實作了對基本方法的調度，完成固定的邏輯，上層只需要去呼叫模板方法就可以了（悍馬模型）
建造者模式：
將一個復雜物件的構建與他的表示分離，使得同樣的構建程序可以創建不同的表示（造各種不同功能的車型能啟動能停止能啟動能鳴笛）創建一個產品類，創建一個抽象建造者，具體建造者實作抽象建造者，會實作產品里面的邏輯并且有個回傳產品的方法，最后導演類產生了一個建造者拿到里面回傳的產品，
建造者適合相同的方法，不同的執行順序，產生不同的事件結果，
代理模式：
讓其他物件提供一種代理以控制對這個物件的訪問（代練著給張三打游戲，執行者時代練著，升級的時張三）代理者拿著游戲者去執行操作，
普通代理時有一個代理來執行用戶的操作，方法不知道代理后面是誰，而強制代理時方法通過用戶來找找到代理，這個代理時用戶提供的，
原型模式：
淺拷貝是指clone方法拷貝了本物件，對是物件內部的陣列，參考物件等都不拷貝，還是指向原生物件的內部元素地址，所以拷貝出來的修改的是原型中的資料，深拷貝對私有的類變數進行獨立的拷貝，比如說物件內部的陣列，所以在拷貝出來物件修改的是拷貝出來的陣列，對原型中的陣列資料并沒有改變，
總結：淺拷貝只拷貝物件，操作的還是原來原型中的資料，深拷貝是把所有的都拷貝一份，是完全獨立出來的，
中介者模式：
用一個中介物件封裝一系列的物件互動，中介者使各物件不需要顯示地相互作用，從而使其耦合松散，而且可以獨立地改變他們之間的互動，在各個不同的類中間形成一個中介類，其他類中需要跟中介類互動就可以，減少類與類之間的耦合程度，
優點：減少類間的依賴，把原來的一對多的依賴變成了一對一的依賴，同事類只依賴中介者，減少依賴，降低耦合，
缺點：會導致中介者會膨脹得很大，而且邏輯復雜，同事類越多，中介者得邏輯就越復雜，
命令模式：
命令模式是一個高內聚得模式，將一個請求封裝成一個物件，有一個接收者角色，一個命令角色，一個呼叫者角色，命令角色給個命令給呼叫者，呼叫者根據命令讓接收者去完成對應得功能，
優點：呼叫者和接收者之間沒有依賴關系，呼叫者實作功能只需要呼叫Command抽象類得execute方法就可以，不需要了解接收者是誰，
缺點：回到直Command的類膨脹問題，
責任鏈模式：
使多個物件都有機會處理請求，從而避免了請求的發送者和接收者之間的耦合關系，將這些物件連成一條鏈，并沿著這條鏈傳遞該請求，知道有物件處理他為止（三從四德）
優點：將請求和處理分開，請求者可以不用知道是誰處理的，處理者可以不用知道請求的全貌，兩者解耦，提高系統的靈活性，
缺點：性能問題，每個請求都要從鏈頭便利到鏈尾，特別是在鏈比較長的時候，性能是一個非常大的問題，二是除錯不方便，環節比較多的時候，由于采用了類似遞回的方式，除錯的時候邏輯可能比較復雜，
裝飾模式：
裝飾模式是動態地給一個物件添加一些額外的職責，就增加功能來說，裝飾及模式相比生成子類更為靈活（成績單）
優點：裝飾類和被裝飾類不會互相耦合，低耦合，裝飾模式是繼承關系的一個替代方案，裝飾模式可以動態地擴展一個實作類的功能，類似于代理模式，擴展性非常好，
缺點：多層的裝飾是很復雜的，如果最里層的裝飾出現了問題，需要一層一層你排查，作業量會很大，系統的復雜度會升高，
使用環境：需要擴展一個類的功能額，或給一個類增加附加功能，
需要動態地給一個物件增加功能，這些功能可以再動態地撤銷
需要為一批的兄弟類進行改裝或加裝功能，首選裝飾模式，
策略模式：
定義一組演算法，將每個演算法都封裝起來，并且使他們之間可以互換，（諸葛亮三個錦囊）
優點：策略模式本身定義的，只要實作抽象策略，他就成為策略家族的一個成員，通過封裝角色對其進行封裝，保障對外可以自由切換，
策略家族對外提供的訪問介面就使封裝類，簡化了操作，同事避免了有條件陳述句判斷
擴展性好，符合OCP原則，（開閉原則）
缺點：每個策略都是一個類，服用的可能性小，類數量增多，
上層模塊必須知道有哪些策略，然后才能決定使用哪一個，這個與迪米特法則相違背，
類膨脹，對外暴露，
配接器模式：
將一個類的介面變成客戶端所期待的另一種介面，從而使原本因介面不匹配而無法再一起作業的兩個類能夠在一起作業，
優點：讓兩個沒有任何關系的類在一起運行，增加了類的透明性，具體的實作都委托給了源角色，而這些對高層次的模塊使透明的，也是它不需要關心的，提高了類的復用度，靈活性特別好，
配接器模式使為了擴張而使用的，不應該在設計的時候考慮用它，
迭代器模式：
迭代器模式目前是一個沒落的模式，基本上沒人會單獨寫一個迭代器，除非是產品性質的開發，（它提供一種方法訪問一個容器物件中各個元素，而又不需暴露該物件的內部細節）
計量不要自己寫迭代器模式，使用java提供的Iterator一般就能滿足你的需求，
組合模式：
將物件組合成樹形結構以表示“部分-整體”的層次結構，使得用戶對單個物件和組合物件的使用具有一致性，
把一組相似的物件當作一個單一的物件，比如說一個部門是一個物件，這個物件里面會有很多相似的物件，
觀察者模式：
定義物件間一種一對多的依賴關系，使得每當一個物件改變狀態，則所有依賴與他的物件都會得到通知并被自動更新，（李斯監控韓非子）
優點：觀察者和被觀察者之間是抽象耦合，不管增加觀察者還是被觀察者都非常容易擴展，而且在java中都已經實作的抽象層級的定義，在系統擴展方面更是得心應手，建立一套觸發機制，觀察者可以完美地實作這里的鏈條形式，
缺點：一個被觀察者，多個觀察者，開發效率和運行效率問題需要考慮，在java中訊息的通知默認是順序執行，一個觀察者卡死，會影響整體的執行效率，可以采用異步，
門面模式：
要求一個子系統的外部與其內部的通信必須通過一個統一的物件進行，門面模式提供一個高層次的介面，使得子系統更易于使用，
門面模式注重”統一的物件“也就是提供一個訪問一個子系統的介面，除了這個介面不允許有任何訪問子系統的行為發生，
把子系統屏蔽掉，只暴露一個門面介面，
優點：外界只依賴門面物件，與子系統無關，提高了靈活性，安全性，
缺點：不符合開閉原則，對修改關閉，對擴展開放，
備忘錄模式：
在不破壞封裝性的前提下，捕獲一個物件的內部狀態，并在該物件之外保存這個狀態，這樣以后就可將該物件回復到原先保存的狀態，
訪問者模式：
封裝一些作用于某些資料結構中的個元素的操作，它可以在不改變資料結構的前提下定義作用于這些元素的新的操作，
狀態模式：
當一個物件內在狀態改變時允許其改變行為，這個物件看起來像改變了其類，狀態模式的信心時分裝，狀態的變更引起了行為的變更，
優點：避免了過多的switch…case或者if…else陳述句的使用，避免勞累程式的復雜性，提高系統的可維護性
體現了開閉原則和單一職責原則，每個狀態都是一個子類，你要增加狀態就要增加子類，修改狀態只修改一個子類，封裝性好，符合門面模式
缺點：子類太多造成類膨脹，
解釋器模式：
給定一門語言，定義它得文法得一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子，
優點：解釋器是一個簡單語法分析工具，它最顯著的優點就是擴展性，修改語法規則只要修改相應的非終結符運算式就可以了，若擴展語法，則只要增加非終結符類就可以了，
缺點：解釋器模式會引起類膨脹，解釋器模式采用遞回呼叫方法，還有一個效率問題，
享元模式：
享元模式是池技術的重要實作方式，使用共享物件可有效地支持大量的細粒度的物件，沒有的物件直接直接創建，有的物件直接拿出來用例子中使用的是Hashmap，避免過多的物件造成記憶體溢位，
優點：可以減少應用程式創建的物件，降低程式記憶體占用，增強程式的性能，
缺點：系統的復雜性提高，需要分離出外部狀態和內部狀態，而且外部狀態具有固化特性，不應該隨內部狀態改變而改變，否則導致系統的邏輯混亂，
橋梁模式：
將抽象和實作解耦，使得兩者可以獨立地變化，生產的工廠new 一個不同的類就可以生產不同的東西，
抽象角色參考實作角色，抽象角色的部分實作是由實作角色完成的，
優點：抽象和實作分離，解決繼承的缺點而提出的設計模式，實作不受抽象的約束，不用再系結再一個固定的抽象層次上，
優秀的擴充能力，對外暴露的介面層允許增加實作，增加抽象
客戶不用關心細節的實作，它已經由抽象層通過聚合關系完成了封裝，

深入理解java虛擬機

1.所有的物件實體以及陣列都應當在堆上分配，

2.方法區與java堆一樣，是各個執行緒共享的記憶體區域，他用于存盤已被虛擬機加載的型別資訊、常量、靜態變數、即時編譯器編譯后的代碼快取等資料，

3.運行時常量池時方法區的一部分，class檔案中有一項資訊時常量池表，用于存放編譯期生成的各種字面量與符號參考，這部分講在類加載后存放到方法區的運行時長常量池，

4.參考計數演算法，通過計數器來判斷物件是否失活，主流的java虛擬機里面沒有選用應用計數演算法來管理記憶體
原因：計數演算法有很多例外情況要考慮，必須要配合大量額外處理才能保證正確地作業，譬如單純的參考計數就很難解決物件之間相互回圈參考的問題，

public class ReferenceCountingGC { 
public Object instance = null; 
private static final int _1MB = 1024 * 1024; 
/**
* 這個成員屬性的唯一意義就是占點記憶體，以便能在GC日志中看清楚是否有回收過 
*/ 
private byte[] bigSize = new byte[2 * _1MB]; 
public static void testGC() { 
ReferenceCountingGC objA = new ReferenceCountingGC(); 
ReferenceCountingGC objB = new ReferenceCountingGC(); 
objA.instance = objB; 
objB.instance = objA; 
objA = null; 
objB = null; 
// 假設在這行發生GC，objA和objB是否能被回收？ 
System.gc(); 
} 
}

可達性分析演算法，

在主流的Java虛擬機中基本上采用的都是可達性分析演算法來判斷物件的存活，
這個演算法是通過一些“GC Roots”的物件作為起點，從這些節點開始向下搜索，
搜索走過的路徑稱之為參考鏈，當一個物件到“GC Roots”沒有任何參考鏈的時候，
也就是說這個物件到“GC Roots”不可達，證明這個物件是不能再被參考了
，因此就會被垃圾回收器判斷為可以被回收的物件，在虛擬機中可以作為“GC Roots”的物件主要有四種：
       （1）虛擬機堆疊參考的物件
       （3）方法區常量參考的物件
       （4）本地方法堆疊中參考的物件
（有參考之后 GC Roots下面就會有參考鏈）

5.參考分為強參考，軟參考，弱參考和虛參考四種，這4種參考強度依次逐漸減弱，

強參考不會被回收
軟參考在記憶體不夠的時候就會被回收
弱參考只能生存到下一次垃圾收集發生為止無論記憶體是否足夠，都會回收掉弱參考關聯的物件
為一個物件設定虛參考的目的是為了能在這個物件被收集器回收時收到一個系統通知，

6.任何一個物件的finalize()方法只會被系統自動呼叫一次，

7.方法區中的回收
(1)回收常量，只要這個常量并沒有被任何地方參考，就可以回收
(2)回收類

①該類中所有的實體都已經被回收，也就是java堆中不存在該類及其任何派生子類的實體，
②加載該類的類加載器已經被回收，這個條件出給是經過精心設計的可替換類加載器的場景，
如osgi,jsp的重加載，否則通常是很難達成的
③該類對應得java.lang.Class物件沒有在任何地方被參考，無法在任何地方通過反射訪問該類得方法，