A. 如何在iOS與android間移植APP
除了像"I am rich"這種定點打擊蘋果燒包族的APP外，大多數應用都會盡量覆蓋包含盡可能多的用戶。這就需要考慮在iOS和Android兩種主流操作系統間移植的問題。如果為各個平台量身定做界面，就能讓用戶利用以往的使用習慣快速學習。但為多個平台設計各異的界面畢竟是需要工作量的。如何才能在跨平台移植的時候只做那些最有必要的工作呢？兵不打無准備之仗，先來看看iOS與Android間有什麼差別吧。
1、物理鍵之返回
Android手機的基本設計思路是是把最常用的功能硬體化，所以就有了home,menu,back三個功能鍵（其實界面設計很簡單啦，就是「用戶到某個地方做某事」，所以就有了導航用的back和展開命令用的menu）。
喬老爺夠狠，要求iOS設備只有一個物理鍵home（據說以後還會把這個鍵砍掉，用手勢當home）。所以在iOS上，返回是通過title bar左側的back按鈕來實現的。但這樣設計也有好處，因為這個back「軟」鍵上的文本是可以改的。在這個按鈕上填上上一次的題目，可以讓用戶明確地知道按下它會回到哪裡。
2、物理鍵之menu
在android上，與當前頁面相關的命令會收到由「menu」鍵喚出的菜單里。而在iOS上，這些命令會放在屏幕底部的toolbar上。這種展示方式相比android的優點是「能一目瞭然地看到能夠對當前頁面做的操作」。而在android上，必須按下menu鍵才能看到命令。你不希望用戶在使用你的APP時肩負著把這些命令背下來的艱巨任務吧？
3、Android的加分項：通知系統
在iOS上，向用戶推送信息的方式只有一種，就是alert box。這在iOS只支持單任務的時候還好說，提醒一來，哦…… 看完了就點確定。但到了多任務版本後就有點不合用了。雖然iOS的alertbox可以在用戶使用某APP的時候彈出其他APP的提示，但這樣未免太煩了。有時一些提醒並不需要強硬中斷用戶當前的操作，比如後台在下載的報紙下完了。Android有更精巧的Status Bar Notification和Toast Notification（詳情可參看鍾磊的手機系統消息通知設計的整理和分析和我寫的如何為手機界面設計提示消息）。當要推送非緊急的消息時，Android平台可以使用更柔和的狀態欄提示。
4、Android的加分項：長按操作
在Android上，當需要對一個對象採取一些操作時，可以長按，喚出相應的context menu（這是對一個項目的，如果是針對當前整個頁面的操作，Android有menu物理鍵，iOS有toolbar）。但是在iOS平台上就不太有地方去放置針對屏幕上某一個對象的大量操作（一兩個是可以的，放在項目旁邊就O了）。可能在喬老爺看來，當需要對一個對象進行「炒、炸、烹、煮、蒸、熏、爆」的時候，就說明你想要的太多了。
5、iOS的加分項：右上角的快捷操作按鈕
對於「右利手」用戶而言，單手持機時屏幕左下角到右上角的連線是右手拇指的甜區。所以依照iOS的Guideline，當前頁上最最最最最最最最最最最最最最常用的按鈕應該放在titlebar的右端。
其實你會發現，清楚了這些差異之後，如何在平台間移植APP就清晰明了啦。
Android -> iOS
1、在每一級的標題欄左上角加上返回上一層的按鈕。按鈕名一定要是上一級的名稱，不能用「返回」等無法透露回到哪裡的文字。
2、由於iOS上沒有menu鍵，所以需要將menu上的命令轉化成toolbar上的圖標。因此要額外繪制圖標或者使用內置圖標。
3、由於在iOS上沒有「長按出context menu」的規則，所以需要給項目添加一個detail頁面。不能在list頁面操縱項目，那就再drill down一層唄。
4、由於iOS的通知方式只有alert box，所以諸如「下載完成」等提醒只能篩出重要的部分，用alert box傳遞。對次要提醒的設計可以看我之前的文章。
iOS -> Android
1、左上角的返回按鈕拿掉。
2、工具欄上的命令可以放到menu里。
3、如果對某個對象的命令很多，可以為其設計長按的context menu
4、不是很緊急的提醒就不要用alert box了，可以換成status bar notification
5、標題欄右側的高頻按鈕可以保留，這個在android上也可以通用。
其實總的來說，也就兩點：
1、差異主要體現在導航方式和頁面命令上，所以對於頁面元素的布局基本沒影響。尤其是對於全屏游戲這種基本沒導航，控制項又都擺在屏幕上的更是影響不大。
2、iOS對硬體的依賴更低。如果實在是小公司，趕時間，沒精力跨平台移植的話，可以考慮只為iPhone設計，然後直接套到android上，湊活著也能用的。但android用戶在使用時也會覺得有一點點怪怪的。
B. 如何學習和理解Android系統
我以前是做嵌入式系統開發的，對於平台比較熟，所以我的學習方向是從下往上進行學習，有相同工作經歷者可以效仿一下吧：)個人認為其實就是三大塊，分為移植-框架-應用1、android系統移植 其實這一塊工作主要集成在android linux kernel 的驅動代碼編寫及android系統啟動調試過程 。 對於android-HAL移植代碼編寫，其實android系統需要移植的模塊較少（最精簡的系統啟動），只需要實現libgralloc模塊，這塊就是顯示及顯存分配的代碼以及HDMI的啟動高清輸出。 需要熟練掌握的知識是linux驅動及android系統的啟動過程會干哪些事情。以前寫過相關的linux kernel及android 完整的啟動流程。 只要熟悉清楚這些原理，就是解決啟動過程中的問題，基本上移植android系統不會有太大的問題，只要啟動了原始的android系統後面就是完善及優化系統了。 深入研究過三個平台代碼（海思，ST及博通）的android代碼與原始android系統代碼，基本上都是這么做的。 這里推薦 --- 移植與調試 ，可以對android的外圍設備及相關移植內部有一定的了解，碰到問題多問問google，可能其它朋友也碰到過，當然也可以找你一起討論解決。2、框架層代碼學習 這塊代碼需要熟悉幾個android的幾個重要概念： Binder (IPC通訊)， Service 服務 ，Zygote 等等 緊接著就是研究大的模塊代碼，如SurfaceFlinger , AudioFilnger ， Media(這塊還一直沒有時間看，很遺憾) 等，下一個計劃就是研究media媒體播放這塊，以前做過本地播放應該會減小很多的學習時間，知識的本質是相通的。 瀏覽器及虛擬機這塊也是個大頭，目前開發沒怎麼用到，所以也沒有去怎麼接觸和了解，說不上好的建議 這里推薦 系統篇，寫的特好，更多的內容見博客，網上很多牛人呀。3、java應用程序 這一塊代碼的編寫，最好的教材就是 android SDK ,這些api有詳細的介紹及用法，與msdn媲美。
網上摘抄。。
C. 請教關於android移植的問題
一、概述
移植的工作一般的主要不外乎做以下這些事情：
A、有的現成好的直接選配
這個工作主要是熟悉該源碼的編譯系統，就是源碼自動化編譯是怎麼組織的。Linux環境下不外乎是Makefile及腳本。所以得熟悉這兩個方面的知識。
B、有的不好的代碼修改好後選配
這個工作不僅僅是要熟悉編譯系統，還要熟悉別人的代碼結構。一般牛X的軟體架構也牛X，所以主要是學習牛X的人設計的代碼結構，所謂的框架。框架懂了，再熟悉裡面的細節，就可以改了。
C、添加新代碼並選配
這個工作同樣要熟悉編譯系統及源碼結構。這個時候對框架可能不能僅僅限於知道，而且要深刻理解，按照牛人的思路來設計代碼。
所以Android的移植就可以簡單的說成有以下方面的工作：
A、熟悉android的編譯系統
主要是.mk文件的規則，這個官網及源碼中有文檔說明（development/Ndk/Docs/android-mk.txt），得好好研究清楚。
就源碼中的腳本，譬如：build/envsetup.sh
B、熟悉android的源碼目錄結構
system：根文件系統相關的一些代碼
packages：android的一些APP的源碼
frameworks：framework層代碼，不改動android源碼的話，主要就是app層調用hal層代碼的介面實現的源碼
hardware：hal層代碼
devices和vendor：廠商定製代碼
build：編譯系統的一些mk文件
out：是編譯輸出目錄
主要的一些目錄就是上面了，對於初學的話，差不多就足夠了。當然所有的都熟悉是最好了。
C、三個層次的代碼
要向android添加代碼的話，一般主要熟悉三個層次的代碼就差不多了。
APP<--->framework<--->HAL
APP：應用程序層次，主要是Java代碼，通過跨平台的java編寫的代碼來完成需求邏輯對系統提出功能性要求，讓系統去完成相應的動作。
framework：cpp代碼，主要是提供給java調用的介面，這些介面通常是去調用到hal層的代碼。
HAL：登記一組供framework回調的函數，來完成一定的功能。