移動網際網路時代，移動端產品的規劃設計是大多數產品經理的必修課。廣義來說，移動端產品主要包含iOS端App、Android端App、微信端H5、小程式、WAP版H5以及平板端App（HD版），本文主要就前兩種——Android和iOS手機端App 在產品工作中應該注意的一些差異來進行闡述。

一、差異的背景原因

1）所屬公司不同

Android系統和iOS系統分別屬於谷歌和蘋果公司，不同的公司對應著不同的文化、風格以及所擁有資源。

2）開發語言不同

Android的底層是Linux系統，Linux是用C語言開發的，所以安卓底層開發用的 C，而應用層開發使用的是Java；iOS是蘋果特有的封閉系統，它的開發語言主要是Object-C。

3）生態體系不同

一個開源一個封閉，Android生態裡系統、硬體、應用、分發四大環節幾乎全部開放，群雄爭霸野蠻生長；而iOS生態裡，除了應用開發，其他三大環節全部牢牢掌握在蘋果公司手中，特別是分發環節，決定著一個應用的生死（這也是很多時候蘋果“耍流氓”的物質基礎）。當然，兩家生態體系各有利弊。

客觀條件決定了Android和iOS註定充滿差異，但他們都同為智慧機作業系統，也有許多共性，特別是在使用者層面，比如螢幕觸控、點選、滑動等操作，這看似不起眼，但這是手機行業進入智慧時代的重要基礎和特徵，也決定著應用的UI、互動規則。問題來了，既然決定應用的UI和互動規則的基礎是一樣的，那麼在產品規劃設計時——

二、同一個App的安卓和iOS版本應不應該一致？

1）理想狀態——遵循各自平臺的風格和規範

安卓Material Design和iOS Flat Design的設計風格都是非常優秀的，遵從各自設計規範，使用各自平臺預設的互動模式和元素樣式，研發不用「重新發明輪子」，對系統友好，程式碼效能、質量、開發效率都高，而且使用者在同一平臺不同應用之間的體驗較一致（切換應用比切換平臺的頻率大多了）。但這意味著更多的人力、時間、資金投入，所以一般都是有一定實力和條件的公司才採用這種方案，代表應用有微信、知乎、網易雲音樂等。

2）現實情況——人少活多時間緊，能一致儘量一致

「跨平臺一致性」的論斷其實說服力並不十分充分，因為使用者在兩平臺間頻繁切換的情況一定是少數，反而更應該考慮的是同一平臺不同應用間的一致性。

所以，人力、資金、時間的制約才是主要因素。一個公司通常都會有Android工程師和iOS工程師，但很難出現Android互動設計師和iOS互動設計師，加人（新增UI及互動設計師）可比加班（讓Android工程師「重新發明輪子」）成本高多了。

那麼到底是採用Android的還是iOS的規範呢？

這個有一定歷史原因，iOS的規範形成的比Android的早，而且在之前的很長一段時間，產品和設計人員大多數使用的是蘋果裝置，對iOS風格的熟悉和認可程度更高，所以就基本形成了按照iOS風格設計一套UI和互動，然後Android開發人員酌情變通，能一致都儘量一致的這樣一種現狀，除了節省成本（前面所述加人比加班成本高）還可以更快的迭代。

3）趨勢——Android和iOS越來越趨同

扁平化、通知中心、分屏多工、系統許可權、指紋識別......Android和iOS互相借鑑已是不爭的事實（雖然他們都不承認），而且開發者們的現實掣肘所帶來的一致性需求，也催生了許多自定義控制元件、樣式的分享，應用在兩平臺間實現一致性的開發成本在降低，一致性的觀念也正在被越來越多的人接納和採用。更讓人欣喜的是像QQ這樣不缺錢不缺人的應用，在兩平臺的UI和互動採用了相同的方案，這樣做的目的也許是在引領趨勢以及追求更高層次的一致性——整個智慧機世界的和諧大統一。

三、產品工作中無法避免的幾點Android和iOS差異

1）狀態列控制

      1））沉浸式狀態列

我簡單化的理解就是狀態列的背景可以跟隨導航欄變化（透明或者某個顏色），同時狀態列文字及圖示會根據不同的背景而變為白色或黑色。

這個功能iOS很早就有，但Android在4.4版本之後才開始使用，而為了兼顧4.4之前的使用者，又不能都用沉浸式，所以處理方案有三種：

① 狀態列背景統一用黑色，狀態列文字統一用白色；

② 狀態列背景統一加一條黑色半透明層，狀態列文字統一用白色；

③ 根據系統不同版本進行適配，系統版本高於Android 4.4的用沉浸式，低於4.4的用方案①或②。

2）返回機制

Android有“實體”返回鍵，iOS沒有

iOS一直都是通過導航欄左上角“返回按鈕”來完成返回操作，但Android一直通過“按鍵”方式來實現返回，所以在產品設計中，iOS版本的非一級頁面上都需要帶有返回按鈕或圖示，而安卓如果帶上此元素反而顯得多餘。

可但是——在Android4.0之後，返回鍵和返回按鈕具有不同的功能定義了，返回按鈕表示「up 向上」，返回的是上一級頁面，返回鍵表示「back 返回」，返回的是上一步。所以，Android版App的頁面上帶有返回按鈕也就變得有必要了。

另外，在微信端H5網站場景下，這個差別也會很突出，分享出去的頁面，如果沒有「up 向上」，是無法回到網站上一級的，所以很多微信站都帶有頂部返回欄，與微信導航欄有重複之感。

3）適配要求

Android機型繁多，iOS基本只需考慮5678四代不超10款型號[“齊劉海”暫不在討論範圍]

使用Android系統的各家廠商所生產出來的手機型號五花八門，系統也經過深度定製，測試時也不可能買那麼多測試機，所以一般是根據資料統計，看使用者的手機型號分佈情況，選出代表機型然後採購測試機。

資料來源：友盟+

4）檔案讀取許可權

Android類似於Windows，App幾乎可讀取本地所有檔案；iOS端App無法讀取本地除圖片和視訊外的其他檔案

如果產品功能裡有需要使用者上傳手機裡的檔案（例如歌曲、錄音、TXT、Word/PPT/Excel等）時，要特別注意，iOS版本是辦不到的，蘋果手機只能通過PC上的iTunes來處理檔案，很麻煩。這時有幾個選擇可以供考慮：

① 在iOS版本上的相關頁面指引使用者iTunes操作方法；

② 此功能Android上iOS不上；

③ 增加步驟，讓使用者先使用PC將檔案傳到系統裡，然後通過手機進行選擇

5）應用市場規則

Android應用市場多，無需付費，稽核寬鬆且時間短；iOS應用市場只有App Store，每年99或299美元，稽核嚴格且時間長

所有應用市場上架前都得註冊申請賬號，應用提交和更新都得稽核。Android應用市場太多，可根據情況選擇相應的平臺，下圖是2016年中國應用市場排名情況。

Android應用市場申請簡單，均免費，應用提交後稽核也很快，基本都在幾小時內。

不過iOS就沒那麼輕鬆了，簡單總結一下：

在申請時

① 申請流程和時間長，少則半個月，多則半年；

② 申請頁面及郵件回覆全英文；

③ 個人/公司開發者賬號每年99美元（可以釋出應用到App Store），企業開發者賬號每年299美元（應用只限企業內部使用，不能上架App Store），支付需用具備visa標識的卡。

應用提交時

① 初次提交稽核一般在一週左右通過，應用升級提交稽核3天左右，遇到聖誕等節日會延後；

② 生殺大權掌握在蘋果手中，讓你下架你還一點脾氣都不能有，搞不好進黑名單，重新再走一遍註冊申請提交流程。

所以當Android和iOS需同時上線時，iOS版本得提前做準備，提前提交稽核，在提交時可以設定稽核通過後的上線時間。

如果iOS應用被下架，使用者是沒有其他渠道能方便、正常地下載安裝該應用的，那這個應用基本上就等於廢掉了。不得不說這一點是蘋果非常狠的地方，也是他商業模式上非常關鍵的一環（“耍流氓”的物質基礎），下面就開始說他最大的“耍流氓”行為。

6）虛擬商品購買和提成規則

Android無限制，不抽成；iOS限制較多且抽成30%

簡單總結一下幾個關鍵知識點：

① iOS應用裡購買虛擬商品，必須使用蘋果內購方式，蘋果抽成30%；

② 虛擬物品包含且不僅限於：遊戲類的道具面板（先充值）、直播類的禮物（先充值）、會員、付費問答及各種形式的充值等；

③ 使用者購買的虛擬商品不能流通，不能再變成實物。

只要是充值，不管充值後的單位是什麼（XX幣、XX點、XX豆等），都算虛擬商品；

直播類應用看似虛擬商品流通了，但實質是用充值的幣買的禮物，幣只能消耗，不能流通。

在購買虛擬商品時，是不能調取支付寶或微信支付的，否則不讓應用上架。有人甚至嘗試過將調取支付寶和微信的功能做成後臺可控制的開關，在蘋果稽核通過後再把開關開啟，但最後也未能得逞，而且進黑名單的風險極高。

對虛擬物品抽成30%這一點，在設計產品時一定要考慮，因為這甚至會關乎商業模式的選擇。曾經遇到過一個真實案例：花一百多萬開發出一個商城，結果不能上架，因為其商城的核心模式是先充值（充值時帶返點），然後用充值的“幣”再購買商品。而且即使能上架，平臺的利潤也無法支撐蘋果抽掉的30%。

蘋果這一霸王條款其實挺不合理，但是人家牛啊，現階段大家都得接受。而針對蘋果對虛擬商品的限制和抽成規則，產品設計時的規則有兩方面選擇：

① 扣除的30%由使用者承擔。比如Android或PC上充值10元得100個幣，iOS充值10元得70個幣；

② 扣除的30%由平臺承擔。比如使用者通過iOS充值10元，平臺實收7元，但給該使用者和Android充值同等的100個幣；

①號選擇對於平臺來說最省事，但是受傷害的是使用者，而且如果充值後的單位用的是“元”的話，使用者第一反應是怎麼剛充的錢還沒用就不見了一大塊？

②號選擇的使用者體驗好，但是平臺白白損失了30%的收入，而且如果涉及到給第三方分成提現，會特別麻煩。

例如：以得到App舉例，使用者在得到上購買199元的專欄，得到要給專欄作者提成，此時的提成比例怎麼定呢？

假若統一定的是80%，平臺需給專欄作者159.2元，如果使用者全用Android充值那皆大歡喜。可是，如果購買使用者是通過iOS充值的，其每個人充值199元，得到平臺實收只有139.3元（使用者餘額顯示199元，平臺承擔被蘋果扣去的30%），139.3元進來轉了一圈，變成159.2元給了作者，平臺白辛苦，還反而虧了19.9元。如果十萬一百萬使用者都這麼幹，平臺就掛了。

所以，30%由平臺承擔的方式一旦涉及第三方提現，只有兩個選擇：

A. 提現比例低於70%，平臺保證不虧，Android充值的部分多賺，iOS充值部分少賺；

B.  Android和iOS充值的按不同比例給第三方提現；

B選擇最合理，但又會出現個問題：使用者消費的199元裡有一部分是通過Android充值的，一部分是通過iOS充值的，這記錄和區別起來會比較麻煩。那怎麼辦呢？

Android和iOS各自充值的餘額不能跨系統使用

無疑這樣的方式體驗不好，但貌似沒有更好的辦法，目前得到就是這麼處理的。

總結：

本文所列舉的6點Android和iOS差異，在很長一段時間內會一直存在，特別是後三點，因為它們關乎蘋果的商業盈利模式，蘋果是不會輕易妥協的。而這些點又影響著產品設計時的商業模式考量、產品規則制定、功能樣式取捨以及上線時間安排等方面，所以在產品工作中有必要清楚地瞭解它們。