692
從100到2.8億用戶，MIUI的發展、創新故事
作者｜董紅光
編輯｜小智
MIUI 發展曆程回顧
早期的 Android 係統非常難用，界麵也很醜陋，與同時代的 iOS 差距非常明顯，當時 Android 主要精力還是在完善係統本身，因此也基本沒有考慮過中國人的本地化需求。所以在當時，做一款定製化的 Android 係統，易用、漂亮、更符合國人的需求，在用戶側還是有非常大唿聲的。MIUI 就是在這樣的背景之下誕生的，2010 年 8 月 16 日正式發布了第一個版本，當時找了 100 個內測用戶，都是發燒友，率先將手機刷成 MIUI，深度使用、全方位吐槽、提各種意見建議。後來我們還拍了一部微電影，叫《100 個夢想的讚助商》，向最初的這部分發燒友和所有一直以來支持我們的米粉們表達敬意和感謝。
MIUI 的整個理念也是從那個時候就形成的，沿用至今，即“和用戶做朋友”，真正去貼近和了解用戶，從各個渠道傾聽真實用戶的看法。其中有一個很重要的渠道是 MIUI 論壇，論壇上都是發燒友，大家互相交流各種玩機經驗，而 MIUI 甚至小米幾乎所有人也都在論壇上，經常和發燒友們一起交流，解答問題，同時征詢大家的各種看法。比如，在做很多功能之前，我們都會去論壇上問大家的意見，根據收集回來的信息，再做方案上的調整。功能發出去之後，繼續在論壇上收集大家的吐槽，然後再快速迭代改進。
這裏就提到了 MIUI 的另一大特點——每周發版，以前稱其為“橙色星期五”，這樣做的好處在於，用戶可以第一時間用到最新功能，如果不滿意，馬上吐槽，我們很快迭代方案，小步快跑，快速試錯。這樣做得到了非常好的效果。所以那時大家說 MIUI 非常好用就不難理解了，因為 MIUI 的很多功能都是直接來自於真實的用戶需求，而且根據用戶的反饋修改無數遍，最終的效果自然會讓更多的人滿意。
回顧 MIUI 從 100 個用戶發展到今天的 2 億多用戶，期間變化非常大，其中兩個方麵感觸比較深：
一個是人數上的變化，最開始人很少，研發人員隻有 20 個左右，後來總體人數逐步發展到 1000 多，這個影響很深遠。一方麵可以做更多的事情了，MIUI 在過去 8 年期間發布了 9 個大版本，幾百個小版本，包含了無數的功能，很多以前沒有足夠精力做的事情，也一點點做起來和完善了。另一方麵，可以把事情做得更好了，以前可能隻能達到 80 分的，現在可以做到 95 分，甚至向 98 分 100 分努力，無論是功能細節，還是技術實現，以及性能、穩定性、功耗等等，每一點的提升，背後都是大量的人力投入。
另一個是模式上的細分，最開始 MIUI 麵向的都是發燒友用戶，都是很資深的玩家，動手能力強，對新功能很渴望，對 bug 容忍度高，所以快速試錯、每周升級對所有用戶都非常適合。但當用戶規模已經是 2 億以上時，對全部用戶都這麼做就不再適合了，功能也需要做更多的權衡。MIUI 在此做了很多事情，比如細分了體驗版、開發版、穩定版，版本的發版頻率和功能取舍都是針對相應的人群專門製定的，因此發燒友與普通用戶才都能通過合適的版本滿足自己的需求。
MIUI 的持續創新
MIUI 非常注重創新，產品創新、技術創新等，創新在內部受到極大鼓勵，大家都勇於做各種層麵的探索和嚐試，最終也達到了比較好的效果：一方麵推出了很多業界首創的功能和技術，另一方麵，也使得很多已有的功能和技術變得更加好用。這方麵的例子很多，舉兩個我當時參與和負責的項目作為例子。
主題
電腦和前智能手機時代，主題換膚還是一個比較普遍的功能，但是到了 iOS 和 Android 上，這個功能弱化了，隻支持更換壁紙和鈴聲等非常簡單的個性化設置。但手機是私人物品，使用時間又長，用戶需要更多彰顯個性的能力。MIUI 應該是最早涉足 Android 係統級換膚能力的 ROM，當時有兩個方麵的創新：
一個是功能側，MIUI 可定製項非常多，不僅支持壁紙、鈴聲、圖標、字體等單項的更換，同時還支持係統應用和第三方應用的界麵素材更換，另外還有百變鎖屏、自由桌麵等非常酷炫的功能，甚至還支持多套主題拆開混搭使用。
另一個是技術側，MIUI 很早就開始深入研究 Android 的應用資源管理機製，在此基礎之上率先做出了能更換所有應用資源的技術方案，後來很快又做到了更換主題後不需要重啟手機，全部效果就都能生效的體驗。而百變鎖屏技術框架在當時的 Android 上也是十分先進的，可以讓設計師很容易就寫出酷炫的動畫和交互，同時還能保證整個渲染的效率，以及很小的功耗代價，當時甚至還有人在百變鎖屏上開發和運行小遊戲。
MIUI SDK
MIUI 發展到今天，已經可以在非常多的 Android 版本和底層平台之上運行了，但這些背後，需要的是大量的移植和適配工作，不僅僅是 BSP 側的工作，MIUI 對於 Android 的改動，也都需要做機型適配。隨著 Android 版本和機型越來越多，如何能夠做到快速適配，就變成一個急需解決的問題了。以前 MIUI 對於 Android framework 的改動，基本是通過直接改代碼的形式實現的，這些都是移植成本。
為了降低這部分成本，我們提出了一個新的思路，將一部分代碼剝離獨立出來，形成一個 apk，叫做 MIUI SDK。這個並沒有什麼特別的，但 MIUI SDK 還做了另一件事：很多改變 Android framework 的行為，不再需要直接改代碼了，而是可以通過運行時動態 hook 的方式，將原始行為覆蓋掉。說到這裏，可能很多 Android 玩家馬上想到了 Xposed，最基本的原理的確比較類似，但是實際應用過程中會遇到很多問題，一個最大的問題是，Android 從 5.0 開始，正式切換為 ART 虛擬機。以前的 dalvik 虛擬機做動態 hook 相對容易，方案也比較成熟，但是 ART 的原理完全不一樣，因為使用了 AOT 的方式，在安裝應用時直接編譯成機器碼，因此之前的技術方案完全不能使用。
Xposed 的思路是將 ART 虛擬機替換成一個修改過的版本，這樣可以配合上層框架做些工作。但是這個思路對於 MIUI 來說不是好的選擇，因為這實際上是將移植成本從 framework 轉移到了 ART 側。MIUI 實際的做法是，通過對 ART 大量的調研工作，在 5.0 正式推出後很短的時間，就支持了動態 hook，這可能是第一個支持在 ART 上動態 hook 的技術方案，並且更關鍵的一點是，這套方案並沒有修改 ART 相關的任何代碼，最終和 dalvik 時做 hook 的效果基本一致。這套技術方案和相關的研究，不僅可以應用在機型移植和類 Xposed 的功能上，還可以應用在代碼熱修複、AOP 編程等很多領域。
未來移動端 OS 的展望和探索
這個話題比較大，沒有誰能一下子說得清楚，更很難預測準確，我對這件事情的理解也並不深，個人認為有兩個可能的方向：
1. 深挖用戶體驗
用戶對移動端 OS 的訴求和 PC 端是不太一樣的，傳統 PC 端 OS 大部分情況下隻需要提供狹義上 OS 的能力，加上一些簡單的工具和管理軟件即可，其他需求可以使用第三方軟件來滿足。但移動端卻不太一樣，一方麵，很多重度應用是開箱必備的，一台手機開箱後沒有相機、撥號、短信等應用肯定是無法想象的，而且這些應用都是用戶經常使用的。另一方麵，現在手機軟硬件一體化程度很高，很多功能如果 OS 不提供，很難有第三方應用能作為替代實現的。所以在這樣的背景下，移動端 OS 一定需要把這些應用以及其他係統層麵的交互做得更好。目前大部分 ROM 在這方麵都已經很不錯了，但是還沒有觸到天花板，大的功能點差不多的前提下，後麵拚的就是細節了，如何把體驗從 80 分提升到 95 分，從 95 分提升到 98 分，每一步都是巨大的工作量和挑戰。
2. 通過新的形態提升效率
提升效率是絕大多數技術革命不變的核心之一，OS 也是這樣，比如提升資源的利用效率，但我這裏說的，主要是對用戶操作的效率提升。如何將用戶的操作化繁為簡，是一個 OS 應該去思考的問題，MIUI 在這方麵也做了很多的探索，我舉幾個例子：
負一屏
移動端傳統的使用方式還是先打開應用，然後在應用內使用服務，或者閱讀內容，但用戶關心的不是應用，而是應用提供的服務和內容本身。那麼如果能夠將服務和內容前置到應用之外，用戶無需再多一步打開應用的過程，直接可以便捷的使用服務，就能大大提高用戶側的使用效率。MIUI 在這方麵做了很多探索，一個最典型的例子就是負一屏，將服務和內容以卡片的形式鋪到桌麵上，用戶直接使用即可。
傳送門
傳送門是 MIUI 9 發布會上一個重點介紹的功能，簡單來說，用戶可以在任何文字上長按，係統會分析這段內容，將相關的服務在下方展現出來，用戶點擊即可啟動相關服務。沒有傳送門時大家的操作是這樣的：比如在某個應用中看到一位明星的名字，想進一步了解，那麼需要長按文字，選擇複製明星的名字，切換到瀏覽器，打開搜索引擎，長按粘貼文字，點搜索，才出現相關的服務。有了傳送門，隻需要一步，即可達到相同的效果，極大的提升了用戶的效率。
直達服務
這個項目是我負責的，這裏多說一些。直達服務想解決什麼樣的問題呢？我們可以先看看 PC 端用戶是如何使用服務的。在 PC 端，除了遊戲和部分專業軟件以外，絕大多數情況，用戶使用的都是瀏覽器，打開搜索引擎，搜索關鍵字，點擊 URL 進入服務網站，使用過程中可能還會通過鏈接進入到另一個服務網站，但整個過程是非常順暢的，不需要下載軟件，服務之間的跳轉連接也是無縫的。
但移動端卻不是這樣的，移動端服務的承載主要有兩種形式，網頁和應用，分別來看：
網頁在移動端和 PC 端的地位有著天壤之別，原因主要有兩個：第一，移動端會用到大量的硬件能力，比如拍照、掃碼、定位、指紋、藍牙、傳感器，等等，但是大部分能力都沒有相應的 API 能夠讓網頁使用，這就意味著用網頁承載服務很可能並不完整；第二，移動端的芯片能力比 PC 端還是要弱一些，但是界麵的複雜性和要求卻很高，再加上前端技術的靈活性和曆史包袱，導致移動端網頁非常容易變得卡頓、慢、內存占用高，使用體驗非常糟糕，想做到流暢需要花費很高的代價，而且依然很難達到原生應用的效果。
而另一種承載形式——應用——同樣有兩個很嚴重的問題：第一，想使用服務，必須先下載安裝應用，通常有幾十兆左右，可能用戶在外麵需要流量下載，可能網絡速度比較慢需要等待 10 分鍾以上，而等到下載安裝完了，可能已經太晚用不上或者想不起來再用了，這中間有一個非常嚴重的斷檔等待期；第二，應用的孤島現象嚴重，即便已經安裝了這些應用，你會發現，大部分應用之間依然無法無縫銜接，取而代之的是，一個應用中打開的是另一個服務的網頁，而網頁的體驗經常比較糟糕，而且可能承載不了服務，這就意味著用戶的操作流程可能會斷掉，需要手動切到另一個應用繼續接下來的操作，這對於用戶來說是難以忍受的。而孤島現象的另一個重要體現在於很難做應用內搜索，大部分情況用戶還是隻能到各個應用中分別搜索，而不是一個地方搜索全部內容。
理想的移動端服務形態，應該能夠像 PC 端瀏覽器一樣的流暢體驗，具體來說，就是能夠結合移動端網頁和應用的優點，既不需要下載安裝，功能服務又完整，還能達到原生般的流暢，服務間還能無縫打通和互相索引。我們覺得這樣的服務形態應該是未來很重要的一種形式，理應對此進行探索，所以才有了直達服務這個項目。
直達服務平台上的各個服務采用前端技術棧開發，但是並不跑在瀏覽器或 WebView 中，它舍棄了瀏覽器內核渲染，轉而采用 Android 的原生渲染機製，也就是說，實際上是使用前端技術棧開發了一個原生應用，無論是渲染效率，還是係統能力的 API 豐富程度，都遠遠超出傳統網頁。同時，直達服務又不像原生應用先把完整應用下載下來才能運行，反而和網頁類似，隻下載當前需要的部分，由於這部分通常來說非常小，網絡條件良好的情況下，一般不超過 1 秒即可打開服務。從開發效率角度看，直達服務和前端開發是比較接近的，采用了前端主流的模版 + 數據綁定的 MVVM 模式，非常容易理解和上手。
入口層麵，通常情況下，移動端服務的發現主要有三類，應用商店、搜索、場景化。直達服務充分發揮了直達服務自身的優勢和 MIUI 的優勢，深挖了搜索和場景化入口，舉兩個例子：第一個例子，在全局搜索或瀏覽器搜索中，可以輸入一個特定內容，比如一本漫畫的名字，那麼無需安裝漫畫應用，即可直接打開諸如快看漫畫這樣的直達服務，以等同於原生應用的體驗直接閱讀這本漫畫；第二個例子，在上麵提到的傳送門場景之下，發現一個特定內容，比如一個電影的名字，那麼同樣無需安裝電影應用，即可直接打開諸如豆瓣電影這樣的直達服務瀏覽電影評價。
總之，直達服務本身要解決的，是用戶使用服務的效率問題，盡量拋掉多餘環節和預設條件，一步直達到服務本身。
寫在最後
MIUI 作為國人非常喜愛的一個 Android ROM，一路走來，凝聚了大量小米人的心血和智慧，也匯集了非常多米粉的意見和需求，未來 MIUI 依然會堅持從用戶出發，探索更多更優的用戶體驗和技術能力，更好的服務所有的用戶。歡迎大家多提意見和建議，如果有興趣參與其中，也非常歡迎大家加入小米。
作者介紹
董紅光，小米 MIUI 係統框架負責人。畢業於北京航空航天大學計算機專業，曾就職於 IBM 中國開發中心，負責服務器端中間件的研發工作，2010 年加入小米，初期負責 MIUI 係統主題換膚能力和主題市場的研發工作，後負責 MIUI 應用開發框架的研發工作，目前是直達服務技術平台、係統框架、係統工具三個領域和團隊的負責人，當前主要關注移動設備上客戶端和前端的應用開發平台和框架等相關領域。
今日薦文
最後更新：2017-10-08 05:38:45