编辑｜小智
戳 阅读原文，获得短信提醒，不错过下次 InfoQ 大咖说直播！
回复 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 非常注重创新，产品创新、技术创新等，创新在内部受到极大鼓励，大家都勇于做各种层面的探索和尝试，最终也达到了比较好的效果：一方面推出了很多业界首创的功能和技术，另一方面，也使得很多已有的功能和技术变得更加好用。这方面的例子很多，举两个我当时参与和负责的项目作为例子。
电脑和前智能手机时代，主题换肤还是一个比较普遍的功能，但是到了 iOS 和 Android 上，这个功能弱化了，只支持更换壁纸和铃声等非常简单的个性化设置。但手机是私人物品，使用时间又长，用户需要更多彰显个性的能力。MIUI 应该是最早涉足 Android 系统级换肤能力的 ROM，当时有两个方面的创新：
一个是功能侧，MIUI 可定制项非常多，不仅支持壁纸、铃声、图标、字体等单项的更换，同时还支持系统应用和第三方应用的界面素材更换，另外还有百变锁屏、自由桌面等非常酷炫的功能，甚至还支持多套主题拆开混搭使用。
另一个是技术侧，MIUI 很早就开始深入研究 Android 的应用资源管理机制，在此基础之上率先做出了能更换所有应用资源的技术方案，后来很快又做到了更换主题后不需要重启手机，全部效果就都能生效的体验。而百变锁屏技术框架在当时的 Android 上也是十分先进的，可以让设计师很容易就写出酷炫的动画和交互，同时还能保证整个渲染的效率，以及很小的功耗代价，当时甚至还有人在百变锁屏上开发和运行小游戏。
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 的诉求和 PC 端是不太一样的，传统 PC 端 OS 大部分情况下只需要提供狭义上 OS 的能力，加上一些简单的工具和管理软件即可，其他需求可以使用第三方软件来满足。但移动端却不太一样，一方面，很多重度应用是开箱必备的，一台手机开箱后没有相机、拨号、短信等应用肯定是无法想象的，而且这些应用都是用户经常使用的。另一方面，现在手机软硬件一体化程度很高，很多功能如果 OS 不提供，很难有第三方应用能作为替代实现的。所以在这样的背景下，移动端 OS 一定需要把这些应用以及其他系统层面的交互做得更好。目前大部分 ROM 在这方面都已经很不错了，但是还没有触到天花板，大的功能点差不多的前提下，后面拼的就是细节了，如何把体验从 80 分提升到 95 分，从 95 分提升到 98 分，每一步都是巨大的工作量和挑战。
提升效率是绝大多数技术革命不变的核心之一，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 应用开发框架的研发工作，目前是直达服务技术平台、系统框架、系统工具三个领域和团队的负责人，当前主要关注移动设备上客户端和前端的应用开发平台和框架等相关领域。
今日荐文
点击下方图片即可阅读
