androidjava伺服器端開發

『壹』 android開發和java開發有什麼區別

Android開發和JAVA開發 是截然不同的兩個東西，就好比C語言只是一種概念你不能說他是vs studio的一種分支，因為C語言不是只能在vs studio上編譯運行，C還可以在TC和GCC等等編譯器上運行，Android和JAVA就是這種關系，你不應該問"Android開發和JAVA開發兩者有什麼區別"？你應該問Android為什麼要在JAVA上開發，Android不一定非要在JAVA上開發，任何編程語言都可以進行Android開發，包括C/C++ C# VBpython ，主流來講Android在JAVA上開發，是因為JAVA各方面優點更加適合Android的開發

1. 跨平台，一次編譯到處運行,若你想要你的app在各種不同的平台設備上運行，那麼所採用的開發語言就必須跨平台

2. 效率高，Java語法相對簡單，與C語言和C++語言很接近，但卻丟棄了C++很少使用的、很難理解的、令人迷惑的那些語言特性，雖然有時可能會出現運行效率不佳，但是開發效率比較高。而且C++中讓人頭疼的指針問題，垃圾回收，在JAVA完全不需要考慮，系統自動幫你完成

3. 虛擬機，Java程序是運行在虛擬機上的，這就為許可權控制，崩潰隔離等問題打下了非常良好的基礎，這樣的話就算是一個程序崩潰了，往往也只是應用閃退而已，不容易造成系統的整體崩潰。

4. 成熟，Java語言可以說是一個相當成熟的計算機編程語種，性能很好，用的人也超級多，除了基礎類庫完善，各種高級的第三方組件更是不計其數，更重要的是Java虛擬機規范是開放的，谷歌只要按照甲骨文的虛擬機規范很容易寫出一套虛擬機。

5. 安全，由於Java語言經常被使用在網路環境中，為了增加其程序的安全性，Java語言提了一個防止惡意代碼攻擊的安全機制，另外Java的強類型機制、垃圾回收器、異常處理和安全檢查機制，也使得用Java語言編寫的程序具有很好的健壯性。
   

『貳』 如何在Android上編寫高效的Java代碼

Java平台一般有三個版本：Java ME（微型版，用於某些手機）、Java SE（標准版，用於台式電腦）、Java EE（企業版，用於伺服器端應用）。在談到Java時，我們通常是指Java SE，因為只有這個版本包含虛擬機和編譯器。

首先，Java代碼會被編譯成稱為位元組碼的中間格式。當位元組碼在目標電腦上運行時，虛擬機會快速將它解析成目標電腦硬體和操作系統所需要的本機格式。

除了為開發者提供「一次編寫，到處運行」的優勢，Java還能通過垃圾回收器（GC）實現自動內存管理，開發者可免去手動在代碼中釋放無用對象的內存。雖然這個功能非常有用，且大大降低了在代碼中引入內存問題的風險，但是它會增加運行時的開銷，因為需要不停地執行垃圾回收進程。

本文開頭將比較Java SE和用於Android開發的Java之間的差異。首先我會介紹開發者習慣的Java
SE語言結構以及它們是如何在Android上運行的。其次，我會介紹如何優化Android中的Java代碼，如何優化內存分配，以及如何恰當地處理多線程。

比較Android上的Dalvik Java和Java SE

雖然遠在Android出現之前，開發者就能用Java編程語言為移動設備編寫應用程序，但它只是Java中功能極為有限的一個版本，稱為Java
ME（微型版）。不同的移動設備還需編寫不同的代碼，因此，寫一個應用程序就能在支持Java
ME的任何手機上運行是幾乎不可能的。此外，由於當時不存在很好的在線商店，應用發布過程極其復雜。

Android的問世為開發者提供了構建智能手機強大應用的機會，開發者只需用Java編程語言以及他們熟知的標准Java
API編寫代碼。然而，盡管Android開發者仍使用Java SE編譯器來編譯應用程序，你會發現，James
Gosling開發的Java和Android設備上的Java存在許多不同之處。

在Android設備上運行的VM（虛擬機）稱為Dalvik。它最初由谷歌的Dan
Bornstein開發，適用於CPU和內存受限的移動設備。Java SE和Dalvik Java存在一些差異，主要體現在虛擬機上。Java
SE使用了棧機設計，而Dalvik被設計成了基於寄存器的機器。Android SDK中有一個dx工具，它會把Java
SE棧機器的位元組碼轉換成基於寄存器的Dalvik機器位元組碼，該轉換步驟由IDE自動完成。

基於棧的虛擬機和基於寄存器的虛擬機的定義以及差異將不列入我們的討論范圍。由於歷史原因，Android使用基於寄存器的虛擬機。雖然基於寄存器的虛擬機最多可以比基於棧的虛擬機快32％，但這只限於執行時解釋位元組碼的虛擬機（也就是說，解釋型虛擬機）。在Android
2.2版本（也稱為Froyo）之前，Dalvik虛擬機都是純解釋型的。Froyo版本引入了JIT編譯器（即時編譯），這是Java
SE很早就有的一個優勢。

JIT編譯，也稱為動態翻譯。它在執行前把位元組碼翻譯成本機代碼（如圖1所示），這樣主要有兩個好處。首先，它消除了那些純解釋型虛擬機的開銷；其次，它能對本機代碼執行優化，這通常是靜態編譯代碼無法做到的。例如，JIT編譯器可以在它運行的CPU上選擇最合適的優化，也可以根據應用程序的輸入來分析代碼是如何運行的，以便進行下一步的優化。

圖1Android Java和Java SE翻譯步驟

雖然Android的Dalvik JIT編譯器有很大的發展前景，但要達到如Java SE的JIT編譯器般穩定、成熟度尚需很長一段時間。不過，Dalvik JIT的出現為Android提供了巨大的性能優勢，而且它也在不斷得以改善。

JAVA
SE虛擬機和Dalvik虛擬機的另一個區別是，後者進行了優化，可運行在同一個機器上的多個實例中。它在開機時會啟動一個叫做zygote的進程，該進程會創建第一個Dalvik實例，由這個實例創建所有其他的實例。當應用程序啟動時，zygote進程會收到一個創建新虛擬機實例的請求，並給該應用程序創建一個新進程（如圖2所示）。如果開發者已習慣於Java

SE開發，這樣的設計可能看起來不切實際，但它有一個很大的優勢，可以避免由一個應用程序運行失敗導致Dalvik虛擬機崩潰，繼而引發多應用程序崩潰。

圖2在Android中啟動新Dalvik虛擬機實例

Android和Java
SE除了運行的虛擬機不同之外，它們實現API的方式也不一樣。Android中屬於java和javax包中的API都來自Apache
Harmony（這是一個開源項目，旨在重新實現Java SE軟體棧，該項目從2011年11月不再維護）。在開發方面，這些API和Java
SE包中的類似，但也存在一些差別。例如，谷歌對HttpUrlConnection類進行了Java SE版本中所沒有的重大升級。

此外，Android平台移除了Java
SE中無關的API。例如，Swing/AWT包被完全移除，因為Android使用不同的UI框架。其他被移除的API還有RMI、CORBA、ImageIO和JMX。它們或者被替換為特定的Android版本（在android包空間內），或者因為一些實際原因根本不存在。

優化Android上的Java代碼

經過多年的改進，Java
SE具備了一些簡化編寫復雜代碼結構的新特性。其中的一些特性會讓整個流程變得更簡單，但開發者需要了解何時以及如何正確地使用它們。另外，由於Java

SE大多用於伺服器端開發（使用Java企業版的API），因而開發人員專門對伺服器端Java代碼進行了優化。註解和Java虛擬機對腳本語言的支持就是對伺服器端開發進行優化的例證。雖然這些工具在構建後端開發時很強大，但在開發Android客戶端代碼時，這些特性的作用很小，甚至起反作用。Java開發者已經習慣於無限量的RAM和CPU，而Android開發需要密切關注性能和內存分配。簡單地說，開發者需要使用稍微不同的方法對待Android和後端的開發。

然而，隨著Android的首次發布，情況有所改變。曾經一些在Android上盡量不用的Java規范重新被推薦，這主要因為Android目前的JIT編譯器解決了這些規范導致的性能問題。

本文將討論編寫Android應用程序需要了解的Java代碼。我們不會深究Java編程語言的細節，而是重點關注對Android開發重要的東西。不過，開發者仍需了解，大多數適用於Java SE的規則和建議同樣適用於Android和Dalvik虛擬機。

Android上的類型安全枚舉

Java SE 5.0新增了許多方便開發者的新特性。其中最值得期待的是引入了類型安全枚舉。枚舉在代碼中用來表示屬於某一組的幾個選擇。在早期版本的Java中，可以用多個整型常量解決這個問題。雖然這在技術上可行，但是很容易出錯。請看下面的代碼：
public class Machine {
public static final int STOPPED = 10;
public static final int INITIALIZING = 20;
public static final int STARTING = 30;
public static final int RUNNING = 40;
public static final int STOPPING = 50;
public static final int CRASHED = 60;
private int mState;

public Machine() {
mState = STOPPED;
}

public int getState() {
return mState;
}

public void setState(int state) {
mState = state;
}
}

問題是，雖然這些常量是期望的，但是沒有機制保證setState()方法接收不同的值。如果要在設置方法中添加檢查，那麼一旦得到的是非預期值，開發者就需要處理錯誤。開發者所需要的是在編譯時檢查非法賦值。類型安全的枚舉解決了這個問題，如下所示：
public class Machine {
public enum State {
STOPPED, INITIALIZING, STARTING, RUNNING, STOPPING, CRASHED
}
private State mState;

public Machine() {
mState = State.STOPPED;
}

public State getState() {
return mState;
}

public void setState(State state) {
mState = state;
}
}

注意在聲明不同類型安全值的地方新加的內部枚舉類。這在編譯時就會解決非法賦值的問題，所以代碼更不容易出錯。

如果Dalvik虛擬機還沒有JIT編譯器優化代碼，不建議在Android平台上使用枚舉類型，因為和使用整型常量相比，這種設計帶來的內存和性能損失更大。這就是為什麼在一些老版本的Android

API中還存在如此多的整型常量的原因。如今有了更強的JIT編譯器以及一個不斷改進的Dalvik虛擬機，開發者不必再擔心這個問題，放心大膽地使用類型安全枚舉即可。

然而，仍然存在一些情況使用整型常量是更好的選擇。像int這樣的Java基本類型，不會增加GC的開銷。此外，Android SDK中許多已有的API仍然依賴基本類型，比如Handler類——在這種情況下，你沒有太多的選擇。

Android中增強版的for循環

Java SE 5.0還引入了增強版的for循環，提供了一個通用的縮寫表達式來遍歷集合和數組。首先，比較以下五種方法：
void loopOne(String[] names) {
int size = names.length;
for (int i = 0; i < size; i++) {
printName(names[i]);
}
}

void loopTwo(String[] names) {
for (String name : names) {
printName(name);
}
}

void loopThree(Collection<String> names) {
for (String name : names) {
printName(name);
}
}

void loopFour(Collection<String> names) {
Iterator<String> iterator = names.iterator();
while (iterator.hasNext()) {
printName(iterator.next());
}
}

// 不要在ArrayList上使用增強版的for循環
void loopFive(ArrayList<String> names) {
int size = names.size();
for (int i = 0; i < size; i++) {
printName(names.get(i));
}
}

上面顯示了四種不同遍歷集合和數組的方式。前面兩種有著相同的性能，所以如果只是讀取元素的話，可以放心地對數組使用增強版for循環。對Collection對象來說，增強版for循環和使用迭代器遍歷元素有著相同的性能。ArrayList對象應避免使用增強版for循環。

如果不僅需要遍歷元素，而且需要元素的位置，就一定要使用數組或者ArrayList，因為所有其他Collection類在這些情況下會更慢。

一般情況下，如果在讀取元素幾乎不變的數據集時對性能要求很高，建議使用常規數組。然而，數組的大小固定，添加數據會影響性能，所以編寫代碼時要考慮所有因素。

隊列、同步和鎖

通常情況下，應用程序會在一個線程中生產數據，在另一個線程中使用它們。常見的例子是在一個線程中獲取網路上的數據，在另一個線程（操作UI的主線程）中把這些數據展現給用戶。這種模式稱為生產者/消費者模式，在面向對象編程課程中，開發者用演算法來實現該模式可能要花上幾個小時。下面會介紹一些簡化生產者/消費者模式實現的現成類。

1. 更智能的隊列

雖然已有現成的類並能用更少的代碼實現該功能，但許多Java開發者仍然選擇使用LinkedList以及同步塊實現隊列功能。開發者可在java.util.concurrent包中找到同步相關的類。此外，本包還包含信號量、鎖以及對單個變數進行原子操作的類。考慮下面使用標準的LinkedList實現線程安全隊列的代碼。
public class ThreadSafeQueue {
private LinkedList<String> mList = new LinkedList<String>();
private final Object mLock = new Object();

public void offer(String value) {
synchronized (mLock) {
mList.offer(value);
mLock.notifyAll();
}
}

public synchronized String poll() {
synchronized (mLock) {
while (mList.isEmpty()) {
try {
mLock.wait();
} catch (InterruptedException e) {
//簡潔起見忽略異常處理
}
}
return mList.poll();
}
}
}

雖然這段代碼是正確的，並有可能在考試中得滿分，但實現和測試這樣一段代碼只是在浪費時間。實際上，所有前面的代碼可用下面一行代替。
LinkedBlockingQueue<String> blockingQueue =
new LinkedBlockingQueue<String>();

上面的一行代碼能像前面的例子一樣提供相同類型的阻塞隊列，甚至能提供額外的線程安全操作。java.util.concurrent包含許多可選的隊列以及並發映射類，所以，一般情況下，建議使用它們，而不是像之前的示例那樣使用更多代碼。

2. 更智能的鎖

Java提供的synchronized關鍵字允許開發者創建線程安全的方法和代碼塊。synchronized關鍵字易於使用，也很容易濫用，對性能造成負面影響。當需要區分讀數據和寫數據時，synchronized關鍵字並不是最有效的。幸好，java.util.concurrent.locks包中的工具類對這種情況提供了很好的支持。
public class ReadWriteLockDemo {
private final ReentrantReadWriteLock mLock;
private String mName;
private int mAge;
private String mAddress;

public ReadWriteLockDemo() {
mLock = new ReentrantReadWriteLock();
}

public void setPersonData(String name, int age, String address) {
ReentrantReadWriteLock.WriteLock writeLock = mLock.writeLock();
try {
writeLock.lock();
mName = name;
mAge = age;
mAddress = address;
} finally {
writeLock.unlock();
}
}

public String getName() {
ReentrantReadWriteLock.ReadLock readLock = mLock.readLock();
try {
readLock.lock();
return mName;
} finally {
readLock.unlock();
}
}

// 重復代碼不再贅述
}

上面的代碼展示了在什麼地方使用ReentrantReadWriteLock，它允許多個並發線程對數據進行只讀訪問，並確保同一時間只有一個線程寫入相同的數據。

在代碼中使用synchronized關鍵字仍然是處理鎖問題的有效方法，但無論何種情況下，都要考慮ReentrantReadWriteLock是否是