我曾經從事過五年的iOS應用開發工作，那段時間我一直在盡量避免同Android打交道——不過現在情況不同了。不管大家是否相信，Android開發其實樂趣滿滿、而且與iOS開發相比也不像大家想象的那樣差異巨大。
我在Android平台上開發出這款“七分鐘鍛煉”應用，并借此學到了很多寶貴的知識。我希望這篇文章分享的一些小技巧也能幫助大家解決實際問題。請注意，我接下來進行比較的内容并不一定完全比對，而且本文的重點也不在于完整地叙述Android開發;當然，我一定會提到自己在開發這款簡單應用的過程中所積累到的全部經驗。
IDE
我選擇使用Android Studio，而且我願意打賭：隻要測試完成，它将成為未來的業界标準。雖然很多報道稱它的運作狀态并不穩定，但在我的實際使用中、它僅僅崩潰過一次。也許我隻是習慣了Xcode。
Java
無論大家對Java如何評價，說到底它也隻是不過是一種程式設計語言而已。它能夠解決問題，而且對于經驗豐富的開發者來說、大家肯定是把主要精力放在架構而非Java身上。很高興我用不着跟J2EE扯上關系。
iOS加密
移動應用安全保護平台——愛加密，在Android應用加密保護方面有dex加殼、獨有的so庫加密保護、資源檔案保護等。而且推出了iOS應用加密保護，實屬全球首創。分别從本地資料、方法體/方法名、URL編碼、程式結構、網絡傳輸資料等幾個方面對iOS應用進行全方位的保護，并可以根據iOS應用使用者的需求提供定制解決方案，進而實作iOS防破解保護。下圖是iOS應用使用前後
模拟器
我一直認為iOS模拟器讓人頭痛不已，但相比之下我才發現當初的自己還是太年輕。在稍作嘗試之後，我決定放棄Android模拟器、直接将應用部署在實際裝置上——除非大家願意拿出大量時間盯着螢幕枯等。
Storyboard / NIB
我在自己的iOS開發部落格上談了很多關于Storyboard的話題，很多與我意見相左的讀者發來的一些措辭強硬的郵件讓我徹底放棄了這一交流平台。
Android使用的布局格式為xml。它們彼此之間完全獨立。Android Studio還提供一套出色的“所見即所得”編輯器：
但大家仍然可以深入到原始xml當中——如果願意的話（反正我一般是不願意這麼麻煩）。
相對于自動布局，大家也可以選擇其它布局容器，例如RelativeLayout以及FrameLayout之類。在這裡，我們能夠以像素數量（即裝置的像素容納能力）或者matchparent、wrapcontant等來設定理想的寬度、高度、填充效果、邊框以及色調。
Wrap非常适合文本内容，它會自動将調整正确的高度并設定與之相适應的尺寸，并把其餘工作交給LinearLayout等特定布局方案。
雖然我還沒有用過，但Fragment看起來同樣是一種對自定義UI元素加以重新利用的好途徑。
UIViewController
Android利用一個Activity來實作UIViewConroller的功能。每一個螢幕/視窗都相當于一個Activity。我們就在這裡處理大部分工作，包括将資料綁定到UI當中或者處理事件等等。
Controller/View轉換
在iOS當中我們利用segue、pushViewController、presentController等在不同螢幕之間進行遷移。但在Android環境下，我們需要使用Intent。
大家可以輕松遷移至新的activity當中，甚至能夠将一部分資料傳遞過去。
public void onItemClick(...) {
Intent i = new Intent(getBaseContext(), MyActivity.class);
i.putExtra("row", position);
startActivity(i);
}
在新的Activity（也就是以上代碼中的MyActivity）中，我們可以提取出傳遞來的資料：
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_mine);
Bundle extras = getIntent().getExtras();
if (extras != null) {
int row = extras.getInt("row");
....
}
...
}
大家也可以利用Intent來觸發各類事件，例如實作表格共享：
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.putExtra(Intent.EXTRA_TEXT, "Share This");
sendIntent.setType("text/plain");
startActivity(sendIntent);
IBOutlet
也許大家跟我一樣，在超過半數的情況下會忘記連接配接IBOutlet。
在Android當中，每一個場景/元件都擁有獨立的ID，内容如下所示：
@+id/myButton
它随後會自動生成一個名為R的類，接下來我們可以如下所示通路代碼中的按鈕：
Button button = (Button)findViewById(R.id.myButton);
标簽
iOS開發者們經常使用的一項技巧就是利用場景标簽來儲存查找資訊，例如整體布局的位移。在Android環境下，大家也可以将整個對象加入到标簽當中，這種作法非常實用。
row.setTag(data);
UITableViewController / UITableViewDataSource / UITableViewCell
Android當中的ListView就相當于iOS上的UITableView。
而UITableViewDataSource在Android中所對應的則是ArrayAdapter：
MyAdapter adapter = new MyAdapter(this, R.layout.listview_item_row);
listView.setAdapter(adapter);
其中listviewitemrow屬于某一行的布局，相當于iOS中的UITableViewCell。
其中的adapter随後會在getView當中建立/重新使用各行。
大家也可以像這樣設定标題：
View header = getLayoutInflater().inflate(R.layout.listview_header_row, null);
listView.addHeaderView(header);
圖檔/資源
由于有了Asset Catalogue的輔助，iOS環境下的圖檔處理變得非常輕松，通常情況下開發者隻需考慮視網膜屏與非視網膜屏這兩種情況（除非大家想要在iPhone上使用專門針對iPad的圖檔）。
由于Android陣營下各款裝置的分辨率千差萬别，是以大家必須要提供以下四種圖檔格式。
它們分别是：mdpi（普通分辨率）、hdpi（高分辨率）、xhdpi（超高分辨率）以及xxhdpi（超超高分辨率）。我個人認為xxxhdpi版本的誕生将隻是時間問題。
在利用Android Studio建立項目時，大家隻需要提供一份圖示、它就能自動建立出這四種格式。這種作法相信已經給從事過Android應用開發的朋友們留下了嚴重的心理陰影：别怕，大家可以随後手動将其替換為完美的像素版本。
是以，最基本的解決思路就是為每幅圖檔針對每種像素密度建立一個單獨的版本，為其設定同樣的名稱并放在正确的檔案夾之下;這樣Android就會視裝置平台的具體情況挑選理想的版本。
自定義字型
自定義字型在Android上實作起來同樣非常簡單：将字型複制到main/assets當中，而後就能利用以下代碼加以調用：
Typeface font = Typeface.createFromAsset(getAssets(), "Lato-Regular.ttf");
textView.setTypeface(font);
問題在于這種方式并不是在所有裝置上都行得通，是以大家需要準備一套後備字型——不過我自己手頭的兩台Android裝置都沒有提供這樣的字型。
NSLog
日志看起來沒什麼可講的，大家可以利用它來進行應用程式調試什麼什麼的（此處省去一千字）。System.out.println(..)似乎也同樣能夠完成這項任務。
向下相容能力
我們都聽說過Android裝置的碎片化問題。不過從本質上講，處理舊版本Android的難度并不比在舊版本iOS上使用新型iOS功能更高。不過大家可能需要對這種相容能力加以高度重視，畢竟Android環境下這類問題的出現頻率要遠高于iOS。
我們可以通過下列代碼來檢查目前Android版本：
if (Build.VERSION.SDK_INT >= 11.0) {
...
}
以下代碼則用于防止函數調用引發的警告資訊：
@SuppressLint({"NewApi", "LocalSuppress"})
private void myFunction() {
...
}
千奇百怪的漫長Android之旅
CountDownTimer
CountDownTimer——這項内置功能的存在實在讓我興奮不已，因為這正是我的七分鐘鍛煉應用所必需的要素。然而經過實際測試，它不會在onFinish之前發送最後一次onTick，這是個非常詭異的bug而且到現在也沒能得到修複。詭異，真是太詭異了。
方位
當使用者轉動手中的裝置時，我們的activity也會完全重置，這意味着大家必須在activity重新載入之後為其保留全部狀态與恢複機制。Android環境下的處理方式令人頭痛，但iOS則處理得很好。
Kindle Fire / Amazon Store
要讓自己的應用程式順利入駐Amazon Store，我隻需要對現有成果作出兩項調整：
·YouTube SDK無法起效，因為Kindle Fire上不提供YouTube應用。不過對Flash的支援能力依然被保留下來。
·大家需要針對Amazon Store替換應用購買代碼。
大家可以利用android.os.Build.MANUFACTURER以及android.os.Build.MODEL對裝置的制造商以及産品型号資訊進行檢測。