hello，沒想到這么快年就要過完了，今天來聊一聊蘋果規范里兩個令人迷惑的東西，action sheet 和 activity view。

兩個組件都屬于常見組件，其中 action sheet 出現得更早。之后出現的 activity view 在布局上違背了 action sheet 的部分設計理念和規則，而蘋果規范又對此語焉不詳，因此有些同學對如何設計一個底部浮層(或者面板)產生了很多疑問。因此今天我們就從它的發展史出發來講講他們的差異，以及應該如何看待“規范”。可以說規范的演變就是不斷吃書的過程。

Action sheet 的演變歷史

action sheet 是設計規范中提供的最早的一批標準組件，和其他組件相比，蘋果對 action sheet 的定義和迭代的更新其實不算多，它的樣式也沒有特別大的變化。

在 2008 年 iPhone OS 2 時代的規范中，將 action sheet 和警告彈窗(alert)、模態視圖(modal view)都歸類為視圖的不同類型。實際上“視圖 view”這個說法一直都非常模糊，我猜測這個說法來源于 MVC 設計模式，是開發兼任設計時代遺留下來的名詞。現在蘋果將 view 解釋為“應用程序用戶界面的基本構件”，我個人把 view 按照原子系統理解為“頁面模板”。

從創立之初，action sheet 有兩種用途：

• 收納針對用戶當前任務的多種操作。這樣就不用在頁面上把這些操作全部展示出來。
• 進行風險操作之前，可以用 action sheet 來做再確認。

根據這兩個用途，2008 年對 action sheet 的說明和規則總共有以下幾點：

• 一定要有底部取消按鈕，除了取消按鈕之外至少提供 2 個操作按鈕
• 點擊操作按鈕之后，action sheet 將會消失
• Action sheet 上不寫說明文案，因為它是被用戶主動點擊彈出的頁面，用戶可以根據當前任務和按鈕文案推斷出這個浮層的作用。

根據以上幾點我們可以看出 2008 年前后移動端的業態還是比較簡單的。第 2 條規則讓 action sheet 是一個只能承載操作按鈕的臨時不穩定容器，它杜絕了使用 action sheet 來做多級復雜任務的可能性，而且也并沒有提到任何和擴展性相關的解決方案。

在 2011 年時，蘋果對 action sheet 進一步作出了說明：

• 解釋了將取消按鈕放在頁面底部的作用：鼓勵用戶看完所有選項后再做出選擇。
• 強調風險/破壞性操作要用紅色按鈕。
• 不允許縱向滑動，因為：過長的面板可能會導致用戶花費過長的時間來思考每個選項;縱向滑動可能導致誤觸。

自此，action sheet 的幾個比較重要的規范就都成型了。盡管在 2014 年取消了“點擊操作按鈕后 action sheet 會消失”和“action sheet 上不寫說明文案”的說明，讓它的擴展性稍微強了一些，但是從蘋果對其縱向滑動的限制、對「取消」按鈕的強調上，可以看出 action sheet 仍然是暫時性的，傾向于不讓用戶停留太久、完成較為復雜的任務。

在 iOS14 之后，蘋果提供了新的組件 menu 來收納操作，因此進一步限制了 action sheet 的使用場景。iOS14 版規范將 action sheet 歸納到 alert 警告彈窗中，“只有破壞性操作可以使用 action sheet，否則都應該使用 menu”。但在后續版本迭代中又更改了說法，現在 action sheet 基本上被用于承載與「用戶發起的操作」直接相關的功能，比如刪除/離開前的再確認，而不再承載“收納主頁面放不下的次級操作”的功能。

Activity view 的演變歷史

Activity view 是為了“分享”這個功能定制的。目前為止它的使用場景基本限制在分享上，很少見其他場景使用這樣的版式，但我個人認為它在未來有擴展場景的潛質。

蘋果一直有“分享”功能，這個功能最開始使用 action sheet 實現，然后在 iOS6 時期由 action sheet 改版了圖標樣式(但是很可惜沒有說為什么這樣改)。iOS6 時代蘋果并沒有成熟的 App 間分享功能，當時只支持 facebook、twitter、微博等幾個有限的 App 分享，因此在頁面設計上面也沒有考慮擴展性。到了 iOS7 后，蘋果進行了兩個重要的功能迭代：

• 允許 App store 中海量的第三方 App 接入“分享”功能。這導致分享頁面上的操作數量不確定
• 上線了 airdrop 功能，并且可能由于早期對這個功能的推廣，iOS7 允許圖片在當前頁面內被多次分享給不同的人，因此只能支持單次操作的 action sheet 無法再滿足訴求了。

于是基于這兩個重要的功能變化，才產生了我們熟悉的這個橫滑版的 Activity view。

activity view 的設計究竟想解決什么樣的問題我們不得而知，因為它的規范中說的東西也比較語焉不詳。只能說從它最終呈現的效果來看，和以往的設計有這些改變：

Activity view 首次在 iOS7 的規范中登場時，是一個“控制器”controller，而非一個完整頁面，這讓它可以添加“取消”按鈕成為一個類似 action sheet 的模態，也可以作為頁面上的一個元素，搭配頁面左上角的“取消”按鈕。

我個人認為這么設計其實挺冗余，頁面允許橫滑后，“取消”按鈕非要放在頁面底部的理由就根本不成立了，因為用戶的視線并不一定是從上到下看完的，而有可能是從左到右，根本沒往下看。沒有必要為了遵守 action sheet 的規范而制作兩套功能完全一樣的版式。

• activity view 采用了大圖標而非縱向文字列表的樣式。從迭代趨勢來看，合理猜測是因為接入第三方平臺后圖片 icon 的識別效率比純文字更高。
• Activity view 允許橫滑。這也違背了 action sheet“面板不允許縱向滑動”的理由。很明顯這樣做是因為接入第三方平臺 app 數量不確定，只能通過橫滑來保證一些系統操作(復制/投屏等)能夠在第一屏露出。

當然 iOS7 的 activity view 還有些其他的問題，

基于這些問題，activity view 再次改版，也就是現在 iOS13 的樣式。

自此，activity view 完全脫離了早期 action sheet 規范的影響，它允許縱向滑動、不再添加底部取消按鈕、并且支持用戶在本頁面進行多層級的相對較為復雜的操作(比如點擊 airdrop 彈出二級彈窗，但不關閉此 activity view)。

總而言之，根據現行的蘋果規范：

• action sheet 更加聚焦、迅速，它不支持多層級操作，更多被用于再確認場景。
• Activity view 暫時被用于分享場景，它更加具有擴展性，且支持多層級操作。

「寫在最后」

上面講了這么多演變歷史相關的東西，其實我們也可以看出來像蘋果這樣的操作系統迭代是很謹慎也很慢的。從 action sheet 到 activity view，蘋果花了近 10 年時間。而我們日常做設計迭代速度和反應時間肯定是要比蘋果快的。因此，做設計不要單純照搬操作系統規范，而要去思考哪些東西比較貼合場景。