適用于iOS開發者的Android開發技巧

     我曾從事過5年的iOS利用開發工作，那段時間我1直在盡可能避免同Android打交道――不過現在情況不同了。不管大家是不是相信，Android開發其實樂趣滿滿、而且與iOS開發相比也不像大家想象的那樣差異巨大。

     我在Android平臺上開發出這款“7分鐘鍛煉”利用，并借此學到了很多寶貴的知識。我希望這篇文章分享的1些小技能也能幫助大家解決實際問題。請注意，我接下來進行比較的內容其實不1定完全匹配，而且本文的重點也不在于完全地敘述Android開發;固然，我1定會提到自己在開發這款簡單利用的進程中所積累到的全部經驗。

      IDE

      我選擇使用Android Studio，而且我愿意打賭：只要測試完成，它將成為未來的業界標準。雖然很多報導稱它的運行狀態其實不穩定，但在我的實際使用中、它僅僅崩潰過1次。或許我只是習慣了Xcode。

      Java

      不管大家對Java如何評價，說到底它也只是不過是1種編程語言而已。它能夠解決問題，而且對經驗豐富的開發者來講、大家肯定是把主要精力放在框架而非Java身上。很高興我用不著跟J2EE扯上關系。

      iOS加密

      移動利用安全保護平臺――愛加密，在Android利用加密保護方面有dex加殼、獨有的so庫加密保護、資源文件保護等。而且推出了iOS利用加密保護，實屬全球首創。分別從本地數據、方法體/方法名、URL編碼、程序結構、網絡傳輸數據等幾個方面對iOS利用進行全方位的保護，并可以根據iOS利用用戶的需求提供定制解決方案，從而實現iOS防破解保護。下圖是iOS利用使用前后

      摹擬器

      我1直認為iOS摹擬器讓人頭痛不已，但相比之下我才發現當初的自己還是太年輕。在稍作嘗試以后，我決定放棄Android摹擬器、直接將利用部署在實際裝備上――除非大家愿意拿出大量時間盯著屏幕枯等。

      Storyboard / NIB

      我在自己的iOS開發博客上談了很多關于Storyboard的話題，很多與我意見相左的讀者發來的1些措辭強硬的郵件讓我完全放棄了這1交換平臺。

      Android使用的布局格式為xml。它們彼此之間完全獨立。Android Studio還提供1套出色的“所見即所得”編輯器：

       但大家依然可以深入到原始xml當中――如果愿意的話（反正我1般是不愿意這么麻煩）。

     相對自動布局，大家也能夠選擇其它布局容器，例如RelativeLayout和FrameLayout之類。在這里，我們能夠以像素數量（即裝備的像素容納能力）或matchparent、wrapcontant等來設定理想的寬度、高度、填充效果、邊框和色調。

     Wrap非常合適文本內容，它會自動將調劑正確的高度并設定與之相適應的尺寸，并把其余工作交給LinearLayout等特定布局方案。

     雖然我還沒有用過，但Fragment看起來一樣是1種對自定義UI元素加以重新利用的好途徑。

     UIViewController

     Android利用1個Activity來實現UIViewConroller的功能。每個屏幕/窗口都相當于1個Activity。我們就在這里處理大部份工作，包括將數據綁定到UI當中或處理事件等等。

     Controller/View轉換

     在iOS當中我們利用segue、pushViewController、presentController等在不同屏幕之間進行遷移。但在Android環境下，我們需要使用Intent。

     大家可以輕松遷移至新的activity當中，乃至能夠將1部份數據傳遞過去。

     在新的Activity（也就是以上代碼中的MyActivity）中，我們可以提取出傳遞來的數據：

     大家也能夠利用Intent來觸發各類事件，例照實現表格同享：

     IBOutlet

     或許大家跟我1樣，在超過半數的情況下會忘記連接IBOutlet。

     在Android當中，每個場景/組件都具有獨立的ID，內容以下所示：

      它隨后會自動生成1個名為R的類，接下來我們可以以下所示訪問代碼中的按鈕：

      標簽

      iOS開發者們常常使用的1項技能就是利用處景標簽來保存查找信息，例如整體布局的位移。在Android環境下，大家也能夠將全部對象加入到標簽當中，這類作法非常實用。

     UITableViewController / UITableViewDataSource / UITableViewCell

     Android當中的ListView就相當于iOS上的UITableView。

     而UITableViewDataSource在Android中所對應的則是ArrayAdapter：

     其中listviewitemrow屬于某1行的布局，相當于iOS中的UITableViewCell。

     其中的adapter隨后會在getView當中創建/重新使用各行。

     大家也能夠像這樣設置標題：

      圖片/資源

      由于有了Asset Catalogue的輔助，iOS環境下的圖片處理變得非常輕松，通常情況下開發者只需斟酌視網膜屏與非視網膜屏這兩種情況（除非大家想要在iPhone上使用專門針對iPad的圖片）。

      由于Android陣營下各款裝備的分辨率千差萬別，因此大家必須要提供以下4種圖片格式。

      它們分別是：mdpi（普通分辨率）、hdpi（高分辨率）、xhdpi（超高分辨率）和xxhdpi（超超高分辨率）。我個人認為xxxhdpi版本的誕生將只是時間問題。

      在利用Android Studio創建項目時，大家只需要提供1份圖標、它就可以自動創建出這4種格式。這類作法相信已給從事過Android利用開發的朋友們留下了嚴重的心理陰影：別怕，大家可以隨后手動將其替換為完善的像素版本。

      因此，最基本的解決思路就是為每幅圖片針對每種像素密度創建1個單獨的版本，為其設定一樣的名稱并放在正確的文件夾之下;這樣Android就會視裝備平臺的具體情況挑選理想的版本。

     自定義字體

     自定義字體在Android上實現起來一樣非常簡單：將字體復制到main/assets當中，而后就可以利用以下代碼加以調用：

     問題在于這類方式其實不是在所有裝備上都行得通，因此大家需要準備1套后備字體――不過我自己手頭的兩臺Android裝備都沒有提供這樣的字體。

      NSLog

     日志看起來沒甚么可講的，大家可以利用它來進行利用程序調試甚么甚么的（此處省去1千字）。System.out.println(..)似乎也一樣能夠完成這項任務。

      向下兼容能力

     我們都聽說過Android裝備的碎片化問題。不過從本質上講，處理舊版本Android的難度其實不比在舊版本iOS上使用新型iOS功能更高。不過大家可能需要對這類兼容能力加以高度重視，畢竟Android環境下這類問題的出現頻率要遠高于iOS。

      我們可以通過以下代碼來檢查當前Android版本：

      以下代碼則用于避免函數調用引發的正告信息：

      千奇百怪的漫長Android之旅

      CountDownTimer

      CountDownTimer――這項內置功能的存在實在讓我興奮不已，由于這正是我的7分鐘鍛煉利用所必須的要素。但是經過實際測試，它不會在onFinish之前發送最后1次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對裝備的制造商和產品型號信息進行檢測。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈