我为什么写这么多开源框架，还长期保持维护？

除了我想让更多人受益于开源外，还有一点就是，我想保持我良好的编程习惯

写业务代码也可以保持良好的编程习惯啊

能，但是太慢！

写业务时无法注意到的细节

在写业务代码时，即使项目时间充裕，你也会忽略掉很多细节，而这些细节正是影响你进步速度的关键，但你自己却很难察觉，在不知不觉间就对你的进阶之路造成了很大的影响

所以你的进步速度非常之慢，做了多年也只是熟练而已，无法更进一步

业务代码和框架代码最直观的差别就是，业务代码可以随意修改，而框架代码，使用者不能直接修改

由于业务代码的修改不受限制，所以一有需求变动，你就直接通过修改问题代码的方式来快速解决问题，即使这个代码的变动非常频繁，但你的第一反应却不是通过代码设计的方式来解决后续的扩展问题，因为这看似一劳永逸的方式，会浪费你当下大量的时间

人类的潜意识会更注重当下付出的成本，而忽略掉未来会获得的收益

因为你上面的编码方式，所养成的不好的编程习惯，会让你本能的不注重代码的耦合性、灵活性、可扩展性

所以即使你天天敲代码，你的进步也如此之慢，因为你平时就缺乏架构设计、代码设计的锻炼，日积月累，你也只是搬砖的速度比之前更快一点而已

写开源框架时给你带来的改变

这个时候如果有一个好的 leader 能每天 review 你的代码，还时常提醒你这些问题，只要你慢慢改成，并养成习惯，那你的进阶之路也会十分顺畅

但如此好的 leader 是可遇不可求的，那我们如果没有一个好 leader，该如何养成一个好习惯呢？

我的建议就是做开源库，而且尽量做开源框架，比如架构框架、UI 框架，网络框架、图片框架，尽量少做开源 App（当然如果为了学习某项技术也是可以的）

因为开源 App 主要是帮助你和别人学习某些技术，也是有大量的业务代码存在的，无非就是用了一些新的技术，而且还是你一个人写，有些细节你更不会考虑 …

而开源框架是拿给别人调用的，所以对代码质量要求更高，考虑的细节更多，对你的提升也越大

并且你的框架代码是放在服务器上的，使用者无法修改你的代码，这就会强迫你更关注代码的耦合性、灵活性、可扩展性，甚至是你写业务时根本不会注重的注释和文档

因为使用者用得稍有不爽就会给你发起 issue，不断地督促你优化你的代码、注释、文档，不断地帮助你培养一个良好的编程习惯

这就好比你有成百上千个好 leader 每天 review 你的代码，并指出你的问题，给予更好的建议，而且这些 leader 中绝对藏龙卧虎，这样日积月累下去，你怎能不成长？

良好的编程习惯助你快速进步

我的很多编程习惯，经过不断的纠错，优化，纠错，优化，已经深深的刻进我的脑子里了

我框架用到的大多数设计模式，都不是我刻意去用的，都是遇到某些问题，或者使用者需要增加什么功能，我为了不影响之前的版本，保证扩展性的前提下，去解决这些问题，而不得不去使用这些设计模式，很多情况下，代码已经写完了，才知道，原来我用的是 xx 设计模式

在这种不断优化代码，养成的良好编程习惯下，我写代码时，使用设计模式已经变成了潜意识的行为，根本说不出为什么要用这个设计模式，只因为觉得这样用才是最优解，这就好比拳击手，遇到攻击时会潜意识的躲闪、反击一样，这就是不断实战、不断训练的结果

我的所有开源框架加起来每个月平均下载量在 5 万左右，每天都有各种 issue 向我飞来，这些成千上万的使用者（监督者），迫使我不断地优化自己的代码，甚至连每个注释我都精雕细琢

框架要做到满足所有人的需求太难了，但只要你不断优化，能做到让大部分人满意，那对你的提升绝对是巨大的，而且你的编程习惯也会有巨大的飞跃

比如我写注释的编程习惯培养起来后，我的每个开源框架，都写了大量的注释，描述的非常详细，保证大部分人都能明白原理，但还是有很多人跑过来问我文档和注释上已经写了的问题

我真的是吐血，兄弟，我真不想回答，你杀了我好吧 …

一个好的习惯，坚持一天，就往目标前进一步

一个坏的习惯，持续一天，也就浪费一天时间

我做开源三年时间改掉了我很多不好的编程习惯，让我进步飞速，所以我感谢开源

我也鼓励更多的人积极参与开源，让别人受益的同时，别人也让你不断进步

当然做开源，并不只是代码写的好，就能收获大量的 star，他还需要综合性的能力，比如框架定位、产品需求分析、运营、推广等很多东西，其中最重要的就是持续维护

我去年创新的新框架 AndroidAutoSize，上线一个月时间就 3k star，现在每个月有 2 万以上的下载量，超过我之前的所有开源框架，这就是因为我之前所积累的开源经验所赐，关于 Github 的运营之道后面我也会分享的

公众号

扫码关注我的公众号 JessYan，一起学习进步，如果框架有更新，我也会在公众号上第一时间通知大家

Hello 我叫 JessYan，如果您喜欢我的文章，可以在以下平台关注我

• 个人主页: https://jessyan.me
• GitHub: https://github.com/JessYanCoding
• 掘金: https://juejin.im/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

在平时的开发工作中，我们经常将一个地方的代码，复制粘贴到另外一个地方，俗称搬砖，搬砖搬多了，作为一个资深的挨踢民工，难免会总结一些提高生产力的搬砖经验

Android Studio 模板是个提高生产力的好东西，使用过 MVPArms 的朋友，都应该使用过我提供的配套模板，使用该套模板，一键即可生成整个页面需要的所有文件，甚至还可以一键生成整个 Module，真正的解放了大家的双手，让大家的双手可以去做更多热爱的事情

Android Stuidio 模板一共有 4 种类型，分别对应不同的功能，我先来简单介绍下这 4 种模板，最后再着重介绍下一键生成 Module 的模板，因为前面 3 种模板在网上有太多优秀的教程了，而 Module 模板的资料非常少，我再重复写一遍前 3 种模板的教程也不一定有别人写得好，意义并不大，所以我前面只做简单介绍，后面会贴出一些教程链接，没了解过的就当科普了，了解过的就直接跳过

现在还差几个 star 就超过 Mozilla 在模板语言 Freemarker 中排名 star 全球第一了，让我得瑟一下😏

Live Templates

Live Templates 的功能主要是根据关键字快速生成代码块

在设置中找到 Live Templates，点击红框中的按钮 “+”，即可新建 Live Templates

File Templates

File Templates 顾名思义，主要功能就是一键生成单个文件

在设置中找到 File and Code Templates，点击红框中的按钮 “+”，即可新建 File Templates

Activity Templates

Activity Templates 可以一键生成多个文件，但不光可以生成 Activity 文件，还可以根据需求生成任何 Java 文件、XML 文件以及其他类型的文件

新建 Activity Templates 要比上面的两个模板复杂的多，需要使用到 FreeMarker，感兴趣的朋友，可以看看我开源的 Activity Templates，稍微修改一下就能应用到自己的项目当中

module Templates

module Templates 可以一键生成 Module 以及 Module 中所需要的所有文件

module Templates 也是使用 FreeMarker 创建的，如果你能理解 Activity Templates，那你也可以快速的新建一个 module Templates

详解 module Templates

不知道大家了解过一键生成 Module 的 Android Stuidio 模板吗，这种类型的模板我在网上没搜到有相关的开源库和文章，所以我就自己研究了一段时间，在去年就开源给了 MVPArms 的使用者

Module Templates 其实要比 Activity Templates 简单很多，因为 Module Templates 的某些限制，导致它的配置面板不能自定义一些新增的功能，所以复杂性降低很多，但是功能性和灵活性就要弱于 Activity Templates，不过即使这样也能满足我们大部分的需求了

Android Studio 中所有的 module Templates 都放在 gradle-projects 这个目录中（Android Studio 安装目录/plugins/android/lib/templates/gradle-projects），如果按照很多教程中对 Activity Templates 学习方法的描述，我们应该按照和 Activity Templates 一样的学习方式，打开 gradle-projects 目录中的 NewAndroidModule 进行学习

但是我可以告诉大家，在你没有足够经验的情况下，最好不要这样做，因为这个文件夹中包含着 Android Studio 创建 Android Module 所需要的所有文件和代码，里面比较复杂，有很多判断条件，很多东西对你的项目来说都用不到，在学习时会耽误你很多时间

所以为了让大家快速上手，我就用我已经开源的 module Templates 作为学习案例，里面的所有文件和代码都是经过我筛选过后提取出来的，非常易于大家学习和理解

module Templates 结构

NewArmsComponent
├── root
│   ├── res //Module 中的资源文件都放这里
│   ├── ├── anim
│   ├── ├── layout
│   ├── ├── mipmap-hdpi
│   ├── ├── mipmap-xhdpi
│   ├── ├── mipmap-xxhdpi
│   ├── ├── mipmap-xxxhdpi
│   ├── ├── values
│   ├── src/app_package   //Module 中的源文件模板都放这里
│   ├── ├── ActivityLifecycleCallbacksImpl.java.ftl
│   ├── ├── Api.java.ftl
│   ├── ├── AppLifecyclesImpl.java.ftl
│   ├── ├── ...
│   ├── test/app_package   //Module 中的测试文件模板都放这里
│   ├── ├── ExampleInstrumentedTest.java.ftl
│   ├── ├── ExampleUnitTest.java.ftl
│   ├── AndroidManifest.xml.ftl   //AndroidManifest.xml 模板文件
│   ├── CMakeLists.txt.ftl   //不用 CMake 可以忽略
│   ├── build.gradle.ftl   //App build.gradle 模板文件
│   ├── native-lib.cpp.ftl   //不用 C 可以忽略
│   ├── root-build.gradle.ftl   //根目录 build.gradle 模板文件
│   ├── settings.gradle.ftl   //settings.gradle 模板文件
├── globals.xml.ftl
├── recipe.xml.ftl
├── template.xml
├── template_new_project.png

root 文件夹下包含的是生成 Module 所需要的模板文件，template_new_project.png 是模板的封面图，globals.xml.ftl 我们暂时用不到，recipe.xml.ftl、template.xml 这两个文件存放的是模板的配置参数，是整个模板的核心文件，我们来看看这两个文件

template.xml

template.xml 放置的是配置面板的参数，配置面板是什么东西？看下图

module Templates 和 Activity Templates 的配置面板不一样，Activity Templates 可以任意修改和新增配置面板中的项目，但是 module Templates 不可以，只能固定为图中的这四项

看看 template.xml 里面的内容

<?xml version="1.0"?>
<template
    format="5"
    revision="2"
    name="MVPArms Module"
    description="Creates a new MVPArms Module.">

    <category value="Application" />

    <formfactor value="Things" />

----------------------- 分割线 -----------------------
    <thumbs>
        <thumb>template_new_project.png</thumb>
    </thumbs>
    
    <parameter
        id="packageName"
        name="Package name"
        type="string"
        constraints="app_package|nonempty"
        default="com.mycompany.myapp" />
        
    ...
    
 <globals file="globals.xml.ftl" />
 <execute file="recipe.xml.ftl" />
</template>        

只用看分割线以上的标签即可，下面的标签基本用不上，每个 parameter 标签在配置面板中都对应一个项目，但 parameter 标签只在 Activity Templates 中可以任意修改和新增，在 module Templates 中的任何修改和新增都是无效的，这点大家可以试试

name 标签和 description 标签顾名思义，这就不用多解释了，category 标签固定为 Application 即可

这里要特别要提一下 formfactor 标签，在 NewAndroidModule 中，formfactor 标签的值为 Mobile，最开始我也和它一样，将值赋为 Mobile，结果发现无法生成文件，我想可能是 Android Studio 只允许存在一个 Android 的 Module 模板，我又试着改成了 TV、Glass、Wear …，发现都不完美，要不是无法生成文件，要不就生成太多不需要的文件，最后改成 Things 后，效果就接近完美了

recipe.xml.ftl

recipe.xml.ftl 的功能就是告诉模板引擎，你打算怎么处理你的模板文件

<?xml version="1.0"?>
<!-- TODO: check include Cpp support; add driver module template -->
<recipe>
    <mkdir at="${escapeXmlAttribute(projectOut)}/libs" />
    <mkdir at="${escapeXmlAttribute(resOut)}/anim" />
    <mkdir at="${projectOut}/src/main/java/${slashedPackageName(packageName)}/app/utils" />

    <merge from="root/settings.gradle.ftl"
             to="${escapeXmlAttribute(topOut)}/settings.gradle" />
    <merge from="root/root-build.gradle.ftl"
             to="${escapeXmlAttribute(topOut)}/build.gradle" />
             
    <copy from="root/res/mipmap-hdpi/ic_launcher.png"
        to="${escapeXmlAttribute(resOut)}/mipmap-hdpi/ic_launcher.png" />
    <copy from="root/res/mipmap-xhdpi/ic_launcher.png"
        to="${escapeXmlAttribute(resOut)}/mipmap-xhdpi/ic_launcher.png" />
    <copy from="root/res/mipmap-xxhdpi/ic_launcher.png"
        to="${escapeXmlAttribute(resOut)}/mipmap-xxhdpi/ic_launcher.png" />
    <copy from="root/res/mipmap-xxxhdpi/ic_launcher.png"
        to="${escapeXmlAttribute(resOut)}/mipmap-xxxhdpi/ic_launcher.png" />                  

    <instantiate from="root/build.gradle.ftl"
                   to="${escapeXmlAttribute(projectOut)}/build.gradle" />
    <instantiate from="root/AndroidManifest.xml.ftl"
                   to="${escapeXmlAttribute(manifestOut)}/AndroidManifest.xml" />
    <instantiate from="root/res/values/styles.xml.ftl"
                   to="${escapeXmlAttribute(resOut)}/values/styles.xml" />

    <instantiate from="root/src/app_package/GlobalConfiguration.java.ftl"
                   to="${projectOut}/src/main/java/${slashedPackageName(packageName)}/app/GlobalConfiguration.java" />
    <open file="${projectOut}/src/main/java/${slashedPackageName(packageName)}/app/GlobalConfiguration.java" />
    <instantiate from="root/src/app_package/AppLifecyclesImpl.java.ftl"
                   to="${projectOut}/src/main/java/${slashedPackageName(packageName)}/app/AppLifecyclesImpl.java" />
    <open file="${projectOut}/src/main/java/${slashedPackageName(packageName)}/app/AppLifecyclesImpl.java" />
       
<#if unitTestsSupported>
    <instantiate from="root/test/app_package/ExampleUnitTest.java.ftl"
                   to="${escapeXmlAttribute(unitTestOut)}/ExampleUnitTest.java" />
</#if>          
</recipe>

Module 所需要的模板文件都放在 root 文件夹下，而使用 recipe.xml.ftl 中的标签就是为了告诉模版引擎，你打算将哪个模板文件通过什么方式放到 Module 中的什么位置

mkdir 标签，顾名思义，就是生成一个空的文件夹

merge 标签中的 from 填写模板文件的地址，to 填写 Module 中的目标位置，merge 标签会将 from 中填写的模板文件，放到 to 中填写的目标位置上，如果目标位置已经存在一个相同文件名的文件，则将模板文件中的全部内容复制到已经存在的文件中，否则则创建一个新的文件

copy 标签会将 from 中填写的文件，放到 to 中填写的目标位置上，如果目标位置已经存在一个相同文件名的文件，则会覆盖此文件

instantiate 标签会将 from 中填写的模板文件，放到 to 中填写的目标位置上，如果目标位置已经存在一个相同文件名的文件，则会覆盖此文件，看描述和 copy 标签差不多，那它们的区别是什么呢？

copy 标签的目标对象是普通文件，也就是没有 .ftl 后缀的文件，instantiate 标签的目标对象是模板文件，也就是有 .ftl 后缀的文件，那有 .ftl 后缀的文件和没有 .ftl 后缀的文件有什么区别呢？

有 .ftl 后缀的文件中可以使用 FreeMarker 语法，在生成文件时，模版引擎会根据文件中的 FreeMarker 语法对文件内容进行相应的修改，比如根据不同的条件生成不同的内容，而没有 .ftl 后缀的文件，文件中的内容一旦确定在生成时是无法改变的，就如同单纯的复制粘贴

${escapeXmlAttribute(resOut)} 对应的是 Module 中的 res 文件夹

${projectOut}/src/main/java/${slashedPackageName(packageName)} 对应的是包名下的根目录

${escapeXmlAttribute(topOut)} 对应的是整个工程的根目录

${escapeXmlAttribute(projectOut)} 对应的是 Module 的根目录

${escapeXmlAttribute(manifestOut)} 对应的是放置 AndroidManifest.xml 的文件夹

${escapeXmlAttribute(testOut)} 对应的是 Module 中放置测试文件的文件夹

模板文件

root 文件夹下模板文件的编写也不难，因为 module Templates 没有用到自定义变量，所以大多数情况下，就是将你写好的 java 文件，后面加上 .ftl 后缀即可，看看下面我贴出的源代码链接，你很快就能上手

你如果还想学到更多的 FreeMarker 语法，可以翻翻下面贴出的 FreeMarker 中文文档

开源代码链接

我给 MVPArms 写的 File Templates

我给 MVPArms 写的 Activity Templates

我给 MVPArms 写的 module Templates

我给组件化项目写的 module Templates

教程链接

快速写出 Activity Templates 的插件

Live Templates 教程

File Templates 教程

Activity Templates 教程

FreeMarker 中文文档

公众号

扫码关注我的公众号 JessYan，一起学习进步，如果框架有更新，我也会在公众号上第一时间通知大家

Hello 我叫 JessYan，如果您喜欢我的文章，可以在以下平台关注我

• 个人主页: https://jessyan.me
• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!

前言

我在前面两篇文章中详细介绍了 今日头条适配方案 和 SmallestWidth 限定符适配方案 的原理，并验证了它们的可行性，以及总结了它们各自的优缺点，可以说这两个方案都是目前比较优秀、比较主流的 Android 屏幕适配方案，而且它们都已经拥有了一定的用户基数

但是对于一些才接触这两个方案的朋友，肯定或多或少还是不知道如何选择这两个方案，我虽然在之前的文章中给出了它们各自的优缺点，但是并没有用统一的标准对它们进行更细致的对比，所以也就没办法更形象的体现它们的优劣，那下面我就用统一的标准对它们进行对比，看看它们的对比情况

方案对比

我始终坚定地认为在这两个方案中，并不能以单个标准就能评判出谁一定比谁好，因为它们都有各自的优缺点，都不是完美的，从更客观的角度来看，它们谁都不能成为最好的那个，只有可能明确了它们各自的优缺点，知道在它们的优缺点里什么是我能接受的，什么是我不能接受的，是否能为了某些优点做出某些妥协，从而选择出一个最适合自己项目的屏幕适配方案

单纯的争论谁是最好的 Android 屏幕适配方案没有任何意义，每个人的需求不一样，站的角度不一样，评判标准也不一样，你能接受的东西他不一定能接受，你觉得不可接受的东西他却觉得可以接受，你有你的理由，他有他的理由，想让一个观点让所有人都能接受太难了！所以我在这里只是列出它们的对比项和对比结果，尽可能的做到客观，最后的选择结果请自行决定，如果还有什么遗漏的对比项，请补充！

可以看到 SmallestWidth 限定符适配方案 和 今日头条适配方案 的适配效果其实都是差不多的，我在前面的文章中也通过公式计算过它们的精确度，SmallestWidth 限定符适配方案 运行在未覆盖的机型上虽然也可以适配，但是却会出现一定的误差，所以 今日头条适配方案 的适配精确度确实要比 SmallestWidth 限定符适配方案 略高的，不过只要 SmallestWidth 限定符适配方案 合理的分配资源文件，适配效果的差距应该也不大

SmallestWidth 限定符适配方案 主打的是稳定性，在运行过程中极少会出现安全隐患，适配范围也可控，不会产生其他未知的影响，而 今日头条适配方案 主打的是降低开发成本、提高开发效率，使用上更灵活，也能满足更多的扩展需求，简单一句话概括就是，这两兄弟，一个求稳，一个求快，好了，我就介绍这么多了，自己选择吧！

AndroidAutoSize

由来

下面就开始介绍我根据 今日头条屏幕适配方案 优化的屏幕适配框架 AndroidAutoSize，大家千万不要认为，我推出的屏幕适配框架 AndroidAutoSize 是根据 今日头条屏幕适配方案 优化的，我本人就一定支持 今日头条屏幕适配方案 是最好的 Android 屏幕适配方案这个观点，它确实很优秀，但同样也有很多不足，我最真实的观点在上面就已经表述咯，至于我为什么要根据 今日头条屏幕适配方案 再封装一个屏幕适配框架，无外乎就以下几点原因:

• SmallestWidth 限定符适配方案 已经有多个优秀的开源解决方案了，它们已经能满足我们日常开发中的所有需求

• 今日头条 官方技术团队只公布了 今日头条屏幕适配方案 的 文章 以及核心代码，但并没有在 Github 上创建公开的仓库，一个新的方案必定要有一个成长迭代的过程，在此期间，一定需要一个可以把所有使用者聚集起来的公共社区，可以让所有使用该方案的使用者在上面交流，大家一起总结、一起填坑，这样才能让该方案更成熟稳定，这就是开源的力量
• 今日头条 官方技术团队公布的核心代码并不能满足我的所有需求，已经开源的其他基于 今日头条屏幕适配方案 的开源项目以及解决方案也不能满足我的所有需求，而我有更好的实现想法
• MVPArms 需要一个适配效果还不错并且切换维护成本也比较低的屏幕适配框架，以帮助使用者用较低的成本、工作量将已经停止维护的 AndroidAutoLayout 快速替换掉

我建议大家都可以去实际体验一下 今日头条屏幕适配方案 和 SmallestWidth 限定符适配方案，感受下它们的异同，我给的建议是，可以在项目中先使用 今日头条屏幕适配方案，感受下它的使用方式以及适配效果，今日头条屏幕适配方案 的侵入性非常低，如果在使用过程中遇到什么不能解决的问题，马上可以切换为其他的屏幕适配方案，在切换的过程中也花费不了多少工作量，试错成本非常低

但如果你在项目中先使用 SmallestWidth 限定符适配方案，之后在使用的过程中再遇到什么不能解决的问题，这时想切换为其他的屏幕适配方案，这工作量可就大了，每个 Layout 文件都含有大量的 dimens 引用，改起来这工作量得有多大，想想都觉得后怕，这就是侵入性太高导致的最致命的问题

如果想体验 今日头条屏幕适配方案，千万不要错过 AndroidAutoSize 哦！仅需一步即可接入项目，下面是 AndroidAutoSize 的地址:

Github : 您的 Star 是我坚持的动力 ✊

与今日头条屏幕适配方案的关系

AndroidAutoSize 与 今日头条屏幕适配方案 的关系，相当于汽车和发动机的关系，今日头条屏幕适配方案 官方公布的代码，只实现了修改系统 density 的相关逻辑，这的确在屏幕适配中起到了最关键的作用，但这还远远还不够

要想让使用者能够更傻瓜式的使用该方案，并且能够应对日常开发中的所有复杂需求，那在架构框架时，还需要考虑 API 的易用性以及合理性、框架的扩展性以及灵活性、功能的全面性、注释和文档的易读性等多个方面的问题

于是我带着我的这些标准在网上搜寻了很久，发现并没有任何一个开源框架或解决方案能够达到我的所有标准，它们大多数还只是停留在将 今日头条屏幕适配方案 封装成工具类来引入项目的阶段，这样在功能的扩展上有限制，并且对用户的使用体验也不好，而我想做的是一个全面性的产品级屏幕适配框架，这离我最初的构想，差距还非常大，于是我只好自己动手，将我的所有思想实现，这才有了 AndroidAutoSize

写完 AndroidAutoSize 框架后，因为对 今日头条屏幕适配方案 有了更加深入的理解，所以才写了 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案，以帮助大家更清晰的理解 今日头条屏幕适配方案

与 AndroidAutoLayout 的关系

AndroidAutoSize 因为名字和 鸿神 的 AndroidAutoLayout 非常相似，并且在填写设计图尺寸的方式上也极为相似，再加上我写的屏幕适配系列的文章也发布在了 鸿神 的公众号上，所以很多人以为 AndroidAutoSize 是 鸿神 写的 AndroidAutoLayout 的升级版，这里我哭笑不得 😂，我只好在这里说一句，大家好，我叫 JessYan，的确可以理解为 AndroidAutoSize 是 AndroidAutoLayout 的升级版，但是它是我写的，关注一波呗

但 AndroidAutoSize 和 AndroidAutoLayout 的原理，却天差地别，比如 AndroidAutoLayout 只能使用 px 作为布局单位，而 AndroidAutoSize 恰好相反，在布局中 dp、sp、pt、in、mm 所有的单位都能支持，唯独不支持 px，但这也意味着 AndroidAutoSize 和 AndroidAutoLayout 在项目中可以共存，互不影响，所以使用 AndroidAutoLayout 的老项目也可以放心的引入 AndroidAutoSize，慢慢的完成屏幕适配框架的切换

之所以将框架取名为 AndroidAutoSize，第一，是想致敬 AndroidAutoLayout 对 Android 屏幕适配领域的贡献，第二，也想成为在 Android 屏幕适配领域有重要影响力的框架

结构

我在上面就已经说了很多开源框架以及解决方案，只是把 今日头条屏幕适配方案 简单的封装成一个工具类然后引入项目，这时很多人就会说了 今日头条屏幕适配方案 官方公布的全部代码都只有 30 行不到，你不把它封装成工具类，那封装成什么？该怎么封装？下面就来看看 AndroidAutoSize 的整体结构

├── external
│   ├── ExternalAdaptInfo.java
│   ├── ExternalAdaptManager.java
│── internal
│   ├── CancelAdapt.java
│   ├── CustomAdapt.java
│── unit
│   ├── Subunits.java
│   ├── UnitsManager.java
│── utils
│   ├── AutoSizeUtils.java
│   ├── LogUtils.java
│   ├── Preconditions.java
│   ├── ScreenUtils.java
├── ActivityLifecycleCallbacksImpl.java
├── AutoAdaptStrategy.java
├── AutoSize.java
├── AutoSizeConfig.java
├── DefaultAutoAdaptStrategy.java
├── DisplayMetricsInfo.java
├── FragmentLifecycleCallbacksImpl.java
├── InitProvider.java

AndroidAutoSize 根据 今日头条屏幕适配方案 官方公布的 30 行不到的代码，经过不断的优化和扩展，发展成了现在拥有 18 个类文件，上千行代码的全面性屏幕适配框架，在迭代的过程中完善和优化了很多功能，相比 今日头条屏幕适配方案 官方公布的原始代码，AndroidAutoSize 更加稳定、更加易用、更加强大，欢迎阅读源码，注释非常详细哦！

功能介绍

AndroidAutoSize 在使用上非常简单，只需要填写设计图尺寸这一步即可接入项目，但需要注意的是，AndroidAutoSize 有两种类型的布局单位可以选择，一个是 主单位 (dp、sp)，一个是 副单位 (pt、in、mm)，两种单位面向的应用场景都有不同，也都有各自的优缺点

• 主单位: 使用 dp、sp 为单位进行布局，侵入性最低，会影响其他三方库页面、三方库控件以及系统控件的布局效果，但 AndroidAutoSize 也通过这个特性，使用 ExternalAdaptManager 实现了在不修改三方库源码的情况下适配三方库的功能

• 副单位: 使用 pt、in、mm 为单位进行布局，侵入性高，对老项目的支持比较好，不会影响其他三方库页面、三方库控件以及系统控件的布局效果，可以彻底的屏蔽修改 density 所造成的所有未知和已知问题，但这样 AndroidAutoSize 也就无法对三方库进行适配

大家可以根据自己的应用场景在 主单位 和 副单位 中选择一个作为布局单位，建议想引入老项目并且注重稳定性的人群使用 副单位，只是想试试本框架，随时可能切换为其他屏幕适配方案的人群使用 主单位

其实 AndroidAutoSize 可以同时支持 主单位 和 副单位，但 AndroidAutoSize 可以同时支持 主单位 和 副单位 的目的，只是为了让使用者可以在 主单位 和 副单位 之间灵活切换，因为切换单位的工作量可能非常巨大，不能立即完成，但领导又要求马上打包上线，这时就可以起到一个很好的过渡作用

主单位

主单位 的 Demo 在 demo

基本使用

将 AndroidAutoSize 引入项目后，只要在 app 的 AndroidManifest.xml 中填写上设计图尺寸，无需其他过多配置 (如果你没有其他自定义需求的话)，AndroidAutoSize 即可自动运行，像下面这样👇

<manifest>
    <application>            
        <meta-data
            android:name="design_width_in_dp"
            android:value="360"/>
        <meta-data
            android:name="design_height_in_dp"
            android:value="640"/>           
     </application>           
</manifest>

在使用主单位时，design_width_in_dp 和 design_height_in_dp 的单位必须是 dp，如果设计师给你的设计图，只标注了 px 尺寸 (现在已经有很多 UI 工具可以自动标注 dp 尺寸了)，那请自行根据公式 dp = px / (DPI / 160) 将 px 尺寸转换为 dp 尺寸，如果你不知道 DPI 是多少？那请以自己测试机的 DPI 为准，如果连怎么得到设备的 DPI 都不知道？百度吧好伐，如果你实在找不到设备的 DPI 那就直接将 px 尺寸除以 3 或者 2 也是可以的

如果你只是想使用 AndroidAutoSize 的基础功能，AndroidAutoSize 的使用方法在这里就结束了，只需要上面这一步，即可帮助你以最简单的方式接入 AndroidAutoSize，但是作为一个全面性的屏幕适配框架，在保证基础功能的简易性的同时，也必须保证复杂的需求也能在框架内被解决，从而达到一个小闭环，所以下面介绍的内容全是前人踩坑踩出来的一些必备功能，如果你没这个需求，或者觉得麻烦，可以按需查看或者跳过，下面的内容建议和 Demo 配合起来阅读，效果更佳

注意事项

• 你在 AndroidManifest.xml 中怎么把设计图的 px 尺寸转换为 dp 尺寸，那在布局时，每个控件的大小也需要以同样的方式将设计图上标注的 px 尺寸转换为 dp 尺寸，千万不要在 AndroidManifest.xml 中填写的是 dp 尺寸，却在布局中继续填写设计图上标注的 px 尺寸

• design_width_in_dp 和 design_height_in_dp 虽然都需要填写，但是 AndroidAutoSize 只会将高度和宽度其中的一个作为基准进行适配，一方作为基准，另一方就会变为备用，默认以宽度为基准进行适配，可以通过 AutoSizeConfig#setBaseOnWidth(Boolean) 不停的切换，这意味着最后运行到设备上的布局效果，在高度和宽度中只有一方可以和设计图上一模一样，另外一方会和设计图出现偏差，为什么不像 AndroidAutoLayout 一样，高和宽都以设计图的效果等比例完美呈现呢？这也很简单，你无法保证所有设备的高宽比例都和你设计图上的高宽比例一致，特别是在现在全面屏全面推出的情况下，如果这里不这样做的话，当你的项目运行在与设计图高宽比例不一致的设备上时，布局会出现严重的变形，这个几率非常大，详情请看 这里

自动运行是如何做到的？

很多人有疑惑，为什么使用者只需要在 AndroidManifest.xml 中填写一下 meta-data 标签，其他什么都不做，AndroidAutoSize 就能自动运行，并在 App 启动时自动解析 AndroidManifest.xml 中填写的设计图尺寸，这里很多人不敢相信，问我真的只需要填写下设计图尺寸框架就可以正常运行吗？难道使用了什么 黑科技?

其实这里并没有用到什么 黑科技，原理反而非常简单，只需要声明一个 ContentProvider，在它的 onCreate 方法中启动框架即可，在 App 启动时，系统会在 App 的主进程中自动实例化你声明的这个 ContentProvider，并调用它的 onCreate 方法，执行时机比 Application#onCreate 还靠前，可以做一些初始化的工作，get 到了吗？

这里需要注意的是，如果你的项目拥有多进程，系统只会在主进程中实例化一个你声明的 ContentProvider，并不会在其他非主进程中实例化 ContentProvider，如果在当前进程中 ContentProvider 没有被实例化，那 ContentProvider#onCreate 就不会被调用，你的初始化代码在当前进程中也就不会执行，这时就需要在 Application#onCreate 中调用下 ContentProvider#query 执行一下查询操作，这时 ContentProvider 就会在当前进程中实例化 (每个进程中只会保证有一个实例)，所以应用到框架中就是，如果你需要在多个进程中都进行屏幕适配，那就需要在 Application#onCreate 中调用 AutoSize#initCompatMultiProcess 方法

进阶使用

虽然 AndroidAutoSize 不需要其他过多的配置，只需要在 AndroidManifest.xml 中填写下设计图尺寸就能正常运行，但 AndroidAutoSize 还是为大家准备了很多可配置选项，尽最大可能满足大家日常开发中的所有扩展需求

所有的全局配置选项在 Demo 中都有介绍，每个 API 中也都有详细的注释，在这里就不过多介绍了

自定义 Activity

在 AndroidManifest.xml 中填写的设计图尺寸，是整个项目的全局设计图尺寸，但是如果某些 Activity 页面由于某些原因，设计师单独出图，这个页面的设计图尺寸和在 AndroidManifest.xml 中填写的设计图尺寸不一样该怎么办呢？不要急，AndroidAutoSize 已经为你考虑好了，让这个页面的 Activity 实现 CustomAdapt 接口即可实现你的需求，CustomAdapt 接口的第一个方法可以修改当前页面的设计图尺寸，第二个方法可以切换当前页面的适配基准，下面的注释都解释的很清楚

public class CustomAdaptActivity extends AppCompatActivity implements CustomAdapt {

	 /**
     * 是否按照宽度进行等比例适配 (为了保证在高宽比不同的屏幕上也能正常适配, 所以只能在宽度和高度之中选择一个作为基准进行适配)
     *
     * @return {@code true} 为按照宽度进行适配, {@code false} 为按照高度进行适配
     */
    @Override
    public boolean isBaseOnWidth() {
        return false;
    }

	 /**
     * 这里使用 iPhone 的设计图, iPhone 的设计图尺寸为 750px * 1334px, 高换算成 dp 为 667 (1334px / 2 = 667dp)
     * <p>
     * 返回设计图上的设计尺寸, 单位 dp
     * {@link #getSizeInDp} 须配合 {@link #isBaseOnWidth()} 使用, 规则如下:
     * 如果 {@link #isBaseOnWidth()} 返回 {@code true}, {@link #getSizeInDp} 则应该返回设计图的总宽度
     * 如果 {@link #isBaseOnWidth()} 返回 {@code false}, {@link #getSizeInDp} 则应该返回设计图的总高度
     * 如果您不需要自定义设计图上的设计尺寸, 想继续使用在 AndroidManifest 中填写的设计图尺寸, {@link #getSizeInDp} 则返回 {@code 0}
     *
     * @return 设计图上的设计尺寸, 单位 dp
     */
    @Override
    public float getSizeInDp() {
        return 667;
    }
}

如果某个 Activity 想放弃适配，让这个 Activity 实现 CancelAdapt 接口即可，比如修改 density 影响到了老项目中的某些 Activity 页面的布局效果，这时就可以让这个 Activity 实现 CancelAdapt 接口

public class CancelAdaptActivity extends AppCompatActivity implements CancelAdapt {

}

自定义 Fragment

Fragment 的自定义方式和 Activity 是一样的，只不过在使用前需要先在 App 初始化时开启对 Fragment 的支持

AutoSizeConfig.getInstance().setCustomFragment(true);

实现 CustomAdapt

public class CustomAdaptFragment extends Fragment implements CustomAdapt {

    @Override
    public boolean isBaseOnWidth() {
        return false;
    }

    @Override
    public float getSizeInDp() {
        return 667;
    }
}

实现 CancelAdapt

public class CancelAdaptFragment extends Fragment implements CancelAdapt {

}

适配三方库页面

在使用主单位时可以使用 ExternalAdaptManager 来实现在不修改三方库源码的情况下，适配三方库的所有页面 (Activity、Fragment)

由于 AndroidAutoSize 要求需要自定义适配参数或取消适配的页面必须实现 CustomAdapt、CancelAdapt，这时问题就来了，三方库是通过远程依赖的，我们无法修改它的源码，这时我们怎么让三方库的页面也能实现自定义适配参数或取消适配呢？别急，这个需求 AndroidAutoSize 也已经为你考虑好了，当然不会让你将三方库下载到本地然后改源码！

• 通过 ExternalAdaptManager#addExternalAdaptInfoOfActivity(Class, ExternalAdaptInfo) 将需要自定义的类和自定义适配参数添加进方法即可替代实现 CustomAdapt 的方式，这里 展示了使用方式，以及详细的注释

• 通过 ExternalAdaptManager#addCancelAdaptOfActivity(Class) 将需要取消适配的类添加进方法即可替代实现 CancelAdapt 的方式，这里 也展示了使用方式，以及详细的注释

需要注意的是 ExternalAdaptManager 的方法虽然可以添加任何类，但是只能支持 Activity、Fragment，并且 ExternalAdaptManager 是支持链式调用的，以便于持续添加多个页面

当然 ExternalAdaptManager 不仅可以对三方库的页面使用，也可以让自己项目中的 Activity、Fragment 不用实现 CustomAdapt、CancelAdapt 即可达到自定义适配参数和取消适配的功能

副单位

前面已经介绍了 副单位 的应用场景，这里就直接介绍 副单位 如何使用，副单位 的 Demo 在 demo-subunits

基本使用

首先和 主单位 一样也需要先在 app 的 AndroidManifest.xml 中填写上设计图尺寸，但和 主单位 不一样的是，当在使用 副单位 时 design_width_in_dp 和 design_height_in_dp 的单位不需要一定是 dp，可以直接填写设计图的 px 尺寸，在布局文件中每个控件的大小也可以直接填写设计图上标注的 px 尺寸，无需再将 px 转换为 dp，这是 副单位的 特性之一，可以帮助大家提高开发效率

<manifest>
    <application>            
        <meta-data
            android:name="design_width_in_dp"
            android:value="1080"/>
        <meta-data
            android:name="design_height_in_dp"
            android:value="1920"/>           
     </application>           
</manifest>

由于 AndroidAutoSize 提供了 pt、in、mm 三种类型的 副单位 供使用者选择，所以在使用 副单位 时，还需要在 APP 初始化时，通过 UnitsManager#setSupportSubunits(Subunits) 方法选择一个你喜欢的副单位，然后在布局文件中使用这个副单位进行布局，三种类型的副单位，其实效果都是一样，大家按喜欢的名字选择即可

由于使用副单位是为了彻底屏蔽修改 density 所造成的对三方库页面、三方库控件以及系统控件的布局效果的影响，所以在使用副单位时建议调用 UnitsManager#setSupportDP(false) 和 UnitsManager#setSupportSP(false)，关闭 AndroidAutoSize 对 dp 和 sp 的支持，AndroidAutoSize 为什么不在使用 副单位 时默认关闭对 dp、sp 的支持？因为允许同时支持 主单位 和 副单位 可以帮助使用者在 主单位 和 副单位 之间切换时更好的过渡，这点在前面就已经提到过

UnitsManager 的详细使用方法，在 demo-subunits 中都有展示，注释也十分详细

自定义 Activity 和 Fragment

在使用 副单位 时自定义 Activity 和 Fragment 的方式是和 主单位 是一样的，这里就不再过多介绍了

适配三方库页面

如果你的项目在使用 副单位 并且关闭了对 主单位 (dp、sp) 的支持，这时 ExternalAdaptManager 对三方库的页面是不起作用的，只对自己项目中的页面起作用，除非三方库的页面也使用了副单位 (pt、in、mm) 进行布局

其实 副单位 之所以能彻底屏蔽修改 density 所造成的对三方库页面、三方库控件以及系统控件的布局效果的影响，就是因为三方库页面、三方库控件以及系统控件基本上使用的都是 dp、sp 进行布局，所以只要 AndroidAutoSize 关闭了对 dp、sp 的支持，转而使用 副单位 进行布局，就能彻底屏蔽修改 density 所造成的对三方库页面、三方库控件以及系统控件的布局效果的影响

但这也同样意味着使用 副单位 就不能适配三方库的页面了，ExternalAdaptManager 也就对三方库的页面不起作用了

布局实时预览

在开发阶段布局时的实时预览是一个很重要的环节，很多情况下 Android Studio 提供的默认预览设备并不能完全展示我们的设计图，所以我们就需要自己创建模拟设备，dp、pt、in、mm 这四种单位的模拟设备创建方法请看 这里

总结

AndroidAutoSize 在经历了 240+ commit、60+ issues、6 个版本 的洗礼后，逐渐的稳定了下来，已经在上个星期发布了首个正式版，在这里要感谢将 AndroidAutoSize 接入到自己项目中的上千个使用者，感谢他们的信赖，AndroidAutoSize 创建的初衷就是为了让所有使用 今日头条屏幕适配方案 的使用者能有一个可以一起交流、沟通的聚集地，所以后面也会持续的收集并解决 今日头条屏幕适配方案的常见问题，让 今日头条屏幕适配方案 变得更加成熟、稳定

至此本系列的第三篇文章也就完结了，这也预示着这个系列连载的终结，这篇文章建议结合系列的第一篇文章 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案 一起看，这样可以对 今日头条屏幕适配方案 有一个更深入的理解，如果你能将整个系列的文章都全部认真看完，那你对 Android 屏幕适配领域的相关知识绝对会有一个飞速的提升!

当你的项目需要切换某个框架时，你会怎么去考察、分析、对比现有的开源方案，并有足够的理由去选择或优化一个最适合自己项目的方案呢？其实整个系列文章可以看作是我怎么去选择同类型开源方案的过程，你以后当遇到同样的选择也可以参照我的思维方式去处理，当然如果以后面试官问到你屏幕适配相关的问题，你能将我如何选择、分析、对比已有方案的过程以及文章中的核心知识点告诉给面试官，那肯定比你直接说一句我使用的是某某开源库有价值得多

以下是 骚年你的屏幕适配方式该升级了! 系列文章，欢迎转发以及分享:

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!

Hello 我叫 JessYan，如果您喜欢我的文章，可以在以下平台关注我

• 个人主页: https://jessyan.me
• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!

前言

ok，根据上一篇文章 骚年你的屏幕适配方式该升级了!-今日头条适配方案 的承诺，本文是这个系列的第二篇文章，这篇文章会详细讲解 smallestWidth 限定符屏幕适配方案

了解我的朋友一定知道，MVPArms 一直使用的是 鸿神 的 AndroidAutoLayout 屏幕适配方案，得益于 AndroidAutoLayout 的便捷，所以我对屏幕适配领域研究的不是很多，AndroidAutoLayout 停止维护后，我也一直在找寻着替代方案，直到 今日头条屏幕适配方案 刷屏，后来又无意间看到了 smallestWidth 限定符屏幕适配方案，这才慢慢的将研究方向转向了屏幕适配领域

最近一个月才开始慢慢恶补 Android 屏幕适配的相关知识，对这两个方案也进行了更深入的研究，可以说从一个小白慢慢成长而来，所以我明白小白的痛，因此在上一篇文章 骚年你的屏幕适配方式该升级了!-今日头条适配方案 中，把 今日头条屏幕适配方案 讲得非常的细，尽量把每一个知识点都描述清晰，深怕小白漏掉每一个细节，这篇文章我也会延续上一篇文章的优良传统，将 smallestWidth 限定符屏幕适配方案 的每一个知识点都描述清晰

顺便说一句，感谢大家对 AndroidAutoSize 的支持，我只是在上一篇文章中提了一嘴我刚发布的屏幕适配框架 AndroidAutoSize，还没给出详细的介绍和原理剖析 (原计划在本系列的第三篇文章中发布)，AndroidAutoSize 就被大家推上了 Github Trending，一个多星期就拿了 2k+ stars，随着关注度的增加，我在这段时间里也累坏了，issues 就没断过，不到半个月就提交了 200 多次 commit，但累并快乐着，在这里要再次感谢大家对 AndroidAutoSize 的认可

谈谈对百分比库的看法

是这样的，在上篇文章中有一些兄弟提了一些观点，我很是认同，但是我站在执行者的角度来看待这个问题，也有一些不同的观点，以下是我在上篇文章中的回复

大家要注意了！这些观点其实针对的是所有以百分比缩放布局的库，而不只是今日头条屏幕适配方案，所以这些观点也同样适用于 smallestWidth 限定符屏幕适配方案，这点有很多人存在误解，所以一定要注意！

上图的每一个方框都代表一种 Android 设备的屏幕，Android 的 系统碎片化、机型以及屏幕尺寸碎片化、屏幕分辨率碎片化 有多严重大家可以通过 友盟指数 了解一下，有些时候在某些事情的决断标准上，并不能按照事情的对错来决断，大多数情况还是要分析成本，收益等多种因素，通过利弊来决断，每个人的利弊标准又都不一样，所以每个人的观点也都会有差别，但也都应该得到尊重，所以我只是说说自己的观点，也不否认任何人的观点

方案是死的人是活的，在某些大屏手机或平板电脑上，您也可以采用其他适配方案和百分比库结合使用，比如针对某个屏幕区间的设备单独出一套设计图以显示比小屏幕手机更多更精细的内容，来达到与百分比库互补的效果，没有一个方案可以说自己是完美的，但我们能清晰的认识到不同方案的优缺点，将它们的优点相结合，才能应付更复杂的开发需求，产出最好的产品

友情提示: 下面要介绍的 smallestWidth 限定符屏幕适配方案，原理也同样是按照百分比缩放布局，理论上也会存在上面所说的 大屏手机和小屏手机显示的内容相同 的问题，选择与否请仔细斟酌

简介 smallestWidth 限定符适配方案

这个方案的的使用方式和我们平时在布局中引用 dimens 无异，核心点在于生成 dimens.xml 文件，但是已经有大神帮我们做了这 一步

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-800x480
│   ├── ├──values-860x540
│   ├── ├──values-1024x600
│   ├── ├──values-1024x768
│   ├── ├──...
│   ├── ├──values-2560x1440

如果有人还记得上面这种 宽高限定符屏幕适配方案 的话，就可以把 smallestWidth 限定符屏幕适配方案 当成这种方案的升级版，smallestWidth 限定符屏幕适配方案 只是把 dimens.xml 文件中的值从 px 换成了 dp，原理和使用方式都是没变的，这些在上面的文章中都有介绍，下面就直接开始剖析原理，smallestWidth 限定符屏幕适配方案 长这样👇

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw360dp
│   ├── ├──values-sw400dp
│   ├── ├──values-sw411dp
│   ├── ├──values-sw480dp
│   ├── ├──...
│   ├── ├──values-sw600dp
│   ├── ├──values-sw640dp

原理

其实 smallestWidth 限定符屏幕适配方案 的原理也很简单，开发者先在项目中根据主流屏幕的 最小宽度 (smallestWidth) 生成一系列 values-sw<N>dp 文件夹 (含有 dimens.xml 文件)，当把项目运行到设备上时，系统会根据当前设备屏幕的 最小宽度 (smallestWidth) 去匹配对应的 values-sw<N>dp 文件夹，而对应的 values-sw<N>dp 文件夹中的 dimens.xml 文字中的值，又是根据当前设备屏幕的 最小宽度 (smallestWidth) 而定制的，所以一定能适配当前设备

如果系统根据当前设备屏幕的 最小宽度 (smallestWidth) 没找到对应的 values-sw<N>dp 文件夹，则会去寻找与之 最小宽度 (smallestWidth) 相近的 values-sw<N>dp 文件夹，系统只会寻找小于或等于当前设备 最小宽度 (smallestWidth) 的 values-sw<N>dp，这就是优于 宽高限定符屏幕适配方案 的容错率，并且也可以少生成很多 values-sw<N>dp 文件夹，减轻 App 的体积

什么是 smallestWidth

smallestWidth 翻译为中文的意思就是 最小宽度，那这个 最小宽度 是什么意思呢？

系统会根据当前设备屏幕的 最小宽度 来匹配 values-sw<N>dp，为什么不是根据 宽度 来匹配，而要加上 最小 这两个字呢？

这就要说到，移动设备都是允许屏幕可以旋转的，当屏幕旋转时，屏幕的高宽就会互换，加上 最小 这两个字，是因为这个方案是不区分屏幕方向的，它只会把屏幕的高度和宽度中值最小的一方认为是 最小宽度，这个 最小宽度 是根据屏幕来定的，是固定不变的，意思是不管您怎么旋转屏幕，只要这个屏幕的高度大于宽度，那系统就只会认定宽度的值为 最小宽度，反之如果屏幕的宽度大于高度，那系统就会认定屏幕的高度的值为 最小宽度

如果想让屏幕宽度随着屏幕的旋转而做出改变该怎么办呢？可以再根据 values-w<N>dp (去掉 sw 中的 s) 生成一套资源文件

如果想区分屏幕的方向来做适配该怎么办呢？那就只有再根据 屏幕方向限定符 生成一套资源文件咯，后缀加上 -land 或 -port 即可，像这样，values-sw400dp-land (最小宽度 400 dp 横向)，values-sw400dp-port (最小宽度 400 dp 纵向)

smallestWidth 的值是怎么算的

要先算出当前设备的 smallestWidth 值我们才能知道当前设备该匹配哪个 values-sw<N>dp 文件夹

ok，还是按照上一篇文章的叙述方式，现在来举栗说明，帮助大家更好理解

我们假设设备的屏幕信息是 1920 * 1080、480 dpi

根据上面的规则我们要在屏幕的高度和宽度中选择值最小的一方作为最小宽度，1080 < 1920，明显 1080 px 就是我们要找的 最小宽度 的值，但 最小宽度 的单位是 dp，所以我们要把 px 转换为 dp

帮助大家再巩固下基础，下面的公式一定不能再忘了！

px / density = dp，DPI / 160 = density，所以最终的公式是 px / (DPI / 160) = dp

所以我们得到的 最小宽度 的值是 360 dp (1080 / (480 / 160) = 360)

现在我们已经算出了当前设备的最小宽度是 360 dp，我们晓得系统会根据这个 最小宽度 帮助我们匹配到 values-sw360dp 文件夹下的 dimens.xml 文件，如果项目中没有 values-sw360dp 这个文件夹，系统才会去匹配相近的 values-sw<N>dp 文件夹

dimens.xml 文件是整个方案的核心所在，所以接下来我们再来看看 values-sw360dp 文件夹中的这个 dimens.xml 是根据什么原理生成的

dimens.xml 生成原理

因为我们在项目布局中引用的 dimens 的实际值，来源于根据当前设备屏幕的 最小宽度 所匹配的 values-sw<N>dp 文件夹中的 dimens.xml，所以搞清楚 dimens.xml 的生成原理，有助于我们理解 smallestWidth 限定符屏幕适配方案

说到 dimens.xml 的生成，就要涉及到两个因数，第一个因素是 最小宽度基准值，第二个因素就是您的项目需要适配哪些 最小宽度，通俗理解就是需要生成多少个 values-sw<N>dp 文件夹

第一个因素

最小宽度基准值 是什么意思呢？简单理解就是您需要把设备的屏幕宽度分为多少份，假设我们现在把项目的 最小宽度基准值 定为 360，那这个方案就会理解为您想把所有设备的屏幕宽度都分为 360 份，方案会帮您在 dimens.xml 文件中生成 1 到 360 的 dimens 引用，比如 values-sw360dp 中的 dimens.xml 是长这样的

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">1dp</dimen>
	<dimen name="dp_2">2dp</dimen>
	<dimen name="dp_3">3dp</dimen>
	<dimen name="dp_4">4dp</dimen>
	<dimen name="dp_5">5dp</dimen>
	<dimen name="dp_6">6dp</dimen>
	<dimen name="dp_7">7dp</dimen>
	<dimen name="dp_8">8dp</dimen>
	<dimen name="dp_9">9dp</dimen>
	<dimen name="dp_10">10dp</dimen>
	...
	<dimen name="dp_356">356dp</dimen>
	<dimen name="dp_357">357dp</dimen>
	<dimen name="dp_358">358dp</dimen>
	<dimen name="dp_359">359dp</dimen>
	<dimen name="dp_360">360dp</dimen>
</resources>

values-sw360dp 指的是当前设备屏幕的 最小宽度 为 360dp (该设备高度大于宽度，则最小宽度就是宽度，所以该设备宽度为 360dp)，把屏幕宽度分为 360 份，刚好每份等于 1dp，所以每个引用都递增 1dp，值最大的 dimens 引用 dp_360 值也是 360dp，刚好覆盖屏幕宽度

下面再来看看将 最小宽度基准值 定为 360 时，values-sw400dp 中的 dimens.xml 长什么样

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">1.1111dp</dimen>
	<dimen name="dp_2">2.2222dp</dimen>
	<dimen name="dp_3">3.3333dp</dimen>
	<dimen name="dp_4">4.4444dp</dimen>
	<dimen name="dp_5">5.5556dp</dimen>
	<dimen name="dp_6">6.6667dp</dimen>
	<dimen name="dp_7">7.7778dp</dimen>
	<dimen name="dp_8">8.8889dp</dimen>
	<dimen name="dp_9">10.0000dp</dimen>
	<dimen name="dp_10">11.1111dp</dimen>
	...
	<dimen name="dp_355">394.4444dp</dimen>
	<dimen name="dp_356">395.5556dp</dimen>
	<dimen name="dp_357">396.6667dp</dimen>
	<dimen name="dp_358">397.7778dp</dimen>
	<dimen name="dp_359">398.8889dp</dimen>
	<dimen name="dp_360">400.0000dp</dimen>
</resources>

values-sw400dp 指的是当前设备屏幕的 最小宽度 为 400dp (该设备高度大于宽度，则最小宽度就是宽度，所以该设备宽度为 400dp)，把屏幕宽度同样分为 360份，这时每份就等于 1.1111dp 了，每个引用都递增 1.1111dp，值最大的 dimens 引用 dp_360 同样刚好覆盖屏幕宽度，为 400dp

通过两个 dimens.xml 文件的比较，dimens.xml 的生成原理一目了然，方案会先确定 最小宽度基准值，然后将每个 values-sw<N>dp 中的 dimens.xml 文件都分配与 最小宽度基准值 相同的份数，再根据公式 屏幕最小宽度 / 份数 (最小宽度基准值) 求出每份占多少 dp，保证不管在哪个 values-sw<N>dp 中，份数 (最小宽度基准值) * 每份占的 dp 值 的结果都是刚好覆盖屏幕宽度，所以在 份数 不变的情况下，只需要根据屏幕的宽度在不同的设备上动态调整 每份占的 dp 值，就能完成适配

这样就能保证不管将项目运行到哪个设备上，只要当前设备能匹配到对应的 values-sw<N>dp 文件夹，那布局中的 dimens 引用就能根据当前屏幕的情况进行缩放，保证能完美适配，如果没有匹配到对应的 values-sw<N>dp 文件夹，也没关系，它会去寻找与之相近的 values-sw<N>dp 文件夹，虽然在这种情况下，布局中的 dimens 引用的值可能有些许误差，但是也能保证最大程度的完成适配

说到这里，那大家就应该就会明白我为什么会说 smallestWidth 限定符屏幕适配方案 的原理也同样是按百分比进行布局，如果在布局中，一个 View 的宽度引用 dp_100，那不管运行到哪个设备上，这个 View 的宽度都是当前设备屏幕总宽度的 360分之100，前提是项目提供有当前设备屏幕对应的 values-sw<N>dp，如果没有对应的 values-sw<N>dp，就会去寻找相近的 values-sw<N>dp，这时就会存在误差了，至于误差是大是小，这就要看您的第二个因数怎么分配了

其实 smallestWidth 限定符屏幕适配方案 的原理和 今日头条屏幕适配方案 挺像的，今日头条屏幕适配方案 是根据屏幕的宽度或高度动态调整每个设备的 density (每 dp 占当前设备屏幕多少像素)，而 smallestWidth 限定符屏幕适配方案 同样是根据屏幕的宽度动态调整每个设备 每份占的 dp 值

第二个因素

第二个因数是需要适配哪些 最小宽度？比如您想适配的 最小宽度 有 320dp、360dp、400dp、411dp、480dp，那方案就会为您的项目生成 values-sw320dp、values-sw360dp、values-sw400dp、values-sw411dp、values-sw480dp 这几个资源文件夹，像这样👇

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw360dp
│   ├── ├──values-sw400dp
│   ├── ├──values-sw411dp
│   ├── ├──values-sw480dp

方案会为您需要适配的 最小宽度，在项目中生成一系列对应的 values-sw<N>dp，在前面也说了，如果某个设备没有为它提供对应的 values-sw<N>dp，那它就会去寻找相近的 values-sw<N>dp，但如果这个相近的 values-sw<N>dp 与期望的 values-sw<N>dp 差距太大，那适配效果也就会大打折扣

那是不是 values-sw<N>dp 文件夹生成的越多，覆盖越多市面上的设备，就越好呢？

也不是，因为每个 values-sw<N>dp 文件夹其实都会占用一定的 App 体积，values-sw<N>dp 文件夹越多，App 的体积也就会越大

所以一定要合理分配 values-sw<N>dp，以越少的 values-sw<N>dp 文件夹，覆盖越多的机型

验证方案可行性

原理讲完了，我们还是按照老规矩，来验证一下这个方案是否可行？

假设设计图总宽度为 375 dp，一个 View 在这个设计图上的尺寸是 50dp * 50dp，这个 View 的宽度占整个设计图宽度的 13.3% (50 / 375 = 0.133)

在使用 smallestWidth 限定符屏幕适配方案 时，需要提供 最小宽度基准值 和需要适配哪些 最小宽度，我们就把 最小宽度基准值 设置为 375 (和 设计图 一致)，这时方案就会为我们需要适配的 最小宽度 生成对应的 values-sw<N>dp 文件夹，文件夹中的 dimens.xml 文件是由从 1 到 375 组成的 dimens 引用，把所有设备的屏幕宽度都分为 375 份，所以在布局文件中我们应该把这个 View 的高宽都引用 dp_50

下面就来验证下在使用 smallestWidth 限定符屏幕适配方案 的情况下，这个 View 与屏幕宽度的比例在分辨率不同的设备上是否还能保持和设计图中的比例一致

验证设备 1

设备 1 的屏幕总宽度为 1080 px，屏幕总高度为 1920 px，DPI 为 480

设备 1 的屏幕高度大于屏幕宽度，所以 设备 1 的 最小宽度 为屏幕宽度，再根据公式 px / (DPI / 160) = dp，求出 设备 1 的 最小宽度 的值为 360 dp (1080 / (480 / 160) = 360)

根据 设备 1 的 最小宽度 应该匹配的是 values-sw360dp 这个文件夹，假设 values-sw360dp 文件夹及里面的 dimens.xml 已经生成，且是按 最小宽度基准值 为 375 生成的，360 / 375 = 0.96，所以每份占的 dp 值为 0.96，dimens.xml 里面的内容是长下面这样的👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">0.96dp</dimen>
	<dimen name="dp_2">1.92dp</dimen>
	<dimen name="dp_3">2.88dp</dimen>
	<dimen name="dp_4">3.84dp</dimen>
	<dimen name="dp_5">4.8dp</dimen>
	...
	<dimen name="dp_50">48dp</dimen>
	...
	<dimen name="dp_371">356.16dp</dimen>
	<dimen name="dp_372">357.12dp</dimen>
	<dimen name="dp_373">358.08dp</dimen>
	<dimen name="dp_374">359.04dp</dimen>
	<dimen name="dp_375">360dp</dimen>
</resources>

可以看到这个 View 在布局中引用的 dp_50，最终在 values-sw360dp 中定格在了 48 dp，所以这个 View 在 设备 1 上的高宽都为 48 dp，系统最后会将高宽都换算成 px，根据公式 dp * (DPI / 160) = px，所以这个 View 的高宽换算为 px 后等于 144 px (48 * (480 / 160) = 144)

144 / 1080 = 0.133，View 的实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以完成了等比例缩放

某些设备的高宽是和 设备 1 相同的，但是 DPI 可能不同，而由于 smallestWidth 限定符屏幕适配方案 并没有像 今日头条屏幕适配方案 一样去自行修改 density，所以系统就会使用默认的公式 DPI / 160 求出 density，density 又会影响到 dp 和 px 的换算，因此 DPI 的变化，是有可能会影响到 smallestWidth 限定符屏幕适配方案 的

所以我们再来试试在这种特殊情况下 smallestWidth 限定符屏幕适配方案 是否也能完成适配

验证设备 2

设备 2 的屏幕总宽度为 1080 px，屏幕总高度为 1920 px，DPI 为 420

设备 2 的屏幕高度大于屏幕宽度，所以 设备 2 的 最小宽度 为屏幕宽度，再根据公式 px / (DPI / 160) = dp，求出 设备 2 的 最小宽度 的值为 411.429 dp (1080 / (420 / 160) = 411.429)

根据 设备 2 的 最小宽度 应该匹配的是 values-sw411dp 这个文件夹，假设 values-sw411dp 文件夹及里面的 dimens.xml 已经生成，且是按 最小宽度基准值 为 375 生成的，411 / 375 = 1.096，所以每份占的 dp 值为 1.096，dimens.xml 里面的内容是长下面这样的👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">1.096dp</dimen>
	<dimen name="dp_2">2.192dp</dimen>
	<dimen name="dp_3">3.288dp</dimen>
	<dimen name="dp_4">4.384dp</dimen>
	<dimen name="dp_5">5.48dp</dimen>
	...
	<dimen name="dp_50">54.8dp</dimen>
	...
	<dimen name="dp_371">406.616dp</dimen>
	<dimen name="dp_372">407.712dp</dimen>
	<dimen name="dp_373">408.808dp</dimen>
	<dimen name="dp_374">409.904dp</dimen>
	<dimen name="dp_375">411dp</dimen>
</resources>

可以看到这个 View 在布局中引用的 dp_50，最终在 values-sw411dp 中定格在了 54.8dp，所以这个 View 在 设备 2 上的高宽都为 54.8 dp，系统最后会将高宽都换算成 px，根据公式 dp * (DPI / 160) = px，所以这个 View 的高宽换算为 px 后等于 143.85 px (54.8 * (420 / 160) = 143.85)

143.85 / 1080 = 0.133，View 的实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以完成了等比例缩放

虽然 View 在 设备 2 上的高宽是 143.85 px，比 设备 1 的 144 px 少了 0.15 px，但是误差非常小，整体的比例并没有发生太大的变化，是完全可以接受的

这个误差是怎么引起的呢，因为 设备 2 的 最小宽度 的实际值是 411.429 dp，但是匹配的 values-sw411dp 舍去了小数点后面的位数 (切记！系统会去寻找小于或等于 411.429 dp 的 values-sw<N>dp，所以 values-sw412dp 这个文件夹，设备 2 是匹配不了的)，所以才存在了一定的误差，因此上面介绍的第二个因数是非常重要的，这直接决定误差是大还是小

可以看到即使在高宽一样但 DPI 不一样的设备上，smallestWidth 限定符屏幕适配方案 也能完成等比例适配，证明这个方案是可行的，如果大家还心存疑虑，也可以再试试其他分辨率的设备，其实到最后得出的比例都是在 0.133 左右，唯一的变数就是第二个因数，如果您生成的 values-sw<N>dp 与设备实际的 最小宽度 差别不大，那误差也就在能接受的范围内，如果差别很大，那就直接 GG

优点

1. 非常稳定，极低概率出现意外

2. 不会有任何性能的损耗

3. 适配范围可自由控制，不会影响其他三方库

4. 在插件的配合下，学习成本低

缺点

1. 在布局中引用 dimens 的方式，虽然学习成本低，但是在日常维护修改时较麻烦

2. 侵入性高，如果项目想切换为其他屏幕适配方案，因为每个 Layout 文件中都存在有大量 dimens 的引用，这时修改起来工作量非常巨大，切换成本非常高昂

3. 无法覆盖全部机型，想覆盖更多机型的做法就是生成更多的资源文件，但这样会增加 App 体积，在没有覆盖的机型上还会出现一定的误差，所以有时需要在适配效果和占用空间上做一些抉择

4. 如果想使用 sp，也需要生成一系列的 dimens，导致再次增加 App 的体积

5. 不能自动支持横竖屏切换时的适配，如上文所说，如果想自动支持横竖屏切换时的适配，需要使用 values-w<N>dp 或 屏幕方向限定符 再生成一套资源文件，这样又会再次增加 App 的体积

6. 不能以高度为基准进行适配，考虑到这个方案的名字本身就叫 最小宽度限定符适配方案，所以在使用这个方案之前就应该要知道这个方案只能以宽度为基准进行适配，为什么现在的屏幕适配方案只能以高度或宽度其中的一个作为基准进行适配，请看 这里

使用中的问题

这时有人就会问了，设计师给的设计图只标注了 px，使用这个方案时，那不是还要先将 px 换算成 dp？

其实也可以不用换算的，那这是什么骚操作呢？

很简单，你把设计图的 px 总宽度设置成 最小宽度基准值 就可以了，还是以前面验证可行性的例子

我们在前面验证可行性时把 最小宽度基准值 设置成了 375，为什么是 375 呢？因为设计图的总宽度为 375 dp，如果换算成 px，总宽度就是 750 px，我们这时把 最小宽度基准值 设置成 750，然后看看 values-sw360dp 中的 dimens.xml 长什么样👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="px_1">0.48dp</dimen>
	<dimen name="px_2">0.96dp</dimen>
	<dimen name="px_3">1.44dp</dimen>
	<dimen name="px_4">1.92dp</dimen>
	<dimen name="px_5">2.4dp</dimen>
	...
	<dimen name="px_50">24dp</dimen>
	...
	<dimen name="px_100">48dp</dimen>
	...
	<dimen name="px_746">358.08dp</dimen>
	<dimen name="px_747">358.56dp</dimen>
	<dimen name="px_748">359.04dp</dimen>
	<dimen name="px_749">359.52dp</dimen>
	<dimen name="px_750">360dp</dimen>
</resources>

360 dp 被分成了 750 份，相比之前的 375 份，现在 每份占的 dp 值 正好减少了一半，还记得在验证可行性的例子中那个 View 的尺寸是多少吗？50dp * 50dp，如果设计图只标注 px，那这个 View 在设计图上的的尺寸应该是 100px * 100px，那我们直接根据设计图上标注的 px，想都不用想直接在布局中引用 px_100 就可以了，因为在 375 份时的 dp_50 刚好等于 750 份时的 px_100 (值都是 48 dp)，所以这时的适配效果和之前验证可行性时的适配效果没有任何区别

看懂了吗？直接将 最小宽度基准值 和布局中的引用都以 px 作为单位就可以直接填写设计图上标注的 px！

总结

关于文中所列出的优缺点，列出的缺点数量确实比列出的优点数量多，但 缺点 3，缺点 4，缺点 5 其实都可以归纳于 占用 App 体积 这一个缺点，因为他们都可以通过增加资源文件来解决问题，而 缺点 6 则是这个方案的特色，只能以宽度为基准进行适配，这个从这个方案的名字就能看出

请大家千万不要曲解文章的意思，不要只是单纯的对比优缺点的数量，缺点的数量大于优点的数量就一定是这个方案不行？没有一个方案是完美的，每个人的需求也都不一样，作为一篇科普类文章我只可能把这个方案描述得尽可能的全面

这个方案能给你带来什么，不能给你带来什么，我必须客观的描述清楚，这样才有助你做出决定，你应该注重的是在这些优缺点里什么是我能接受的，什么是我不能接受的，是否能为了某些优点做出某些妥协，而不只是单纯的去看数量，这样毫无意义，有些人就是觉得稳定性最重要，其他的都可以做出妥协，那其他缺点对于他来说都是无所谓的

好了，这个系列的第二篇文章讲完了，这篇文章也是按照上篇文章的优良传统，写的非常详细，哪怕是新手我相信也应该能看懂，为什么这么多人都不知道自己该选择什么样的方案，就是因为自己都没搞懂这些方案的原理，懂了原理过后才知道这些方案是否是自己想要的

接下来的第三篇文章会详细讲解两个方案的深入对比以及该如何选择，并剖析我根据 今日头条屏幕适配方案 优化的屏幕适配框架 AndroidAutoSize 的原理，敬请期待

如果大家想使用 smallestWidth 限定符屏幕适配方案，可以参考 这篇文章，里面提供有自动生成资源文件的插件和 Demo，由于我并没有在项目中使用 smallestWidth 限定符屏幕适配方案，所以如果在文章中有遗漏的知识点请谅解以及补充，感谢！

以下是 骚年你的屏幕适配方式该升级了! 系列文章，欢迎转发以及分享:

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!

Hello 我叫 JessYan，如果您喜欢我的文章，可以在以下平台关注我

• 个人主页: https://jessyan.me
• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!

前言

这个月在 Android 技术圈中 屏幕适配 这个词曝光率挺高的，为什么这么说呢？因为这个月陆续有多个大佬发布了屏幕适配相关的文章，公布了自己认可的屏幕适配方案

上上个星期 Blankj 老师发表了一篇力挺今日头条屏幕适配方案的 文章，提出了很多优化的方案，并开源了相关源码

上个星期 拉丁吴 老师在 鸿神 的公众号上发布了一篇 文章，详细描述了市面上主流的几种屏幕适配方案，并发布了他的 smallestWidth 限定符适配方案和相关源码 (其实早就发布了)，文章写的很好，建议大家去看看

其实大家最关注的不是市面上有多少种屏幕适配方案，而是自己的项目该选择哪种屏幕适配方案，可以看出两位老师最终选择的屏幕适配方案都是不同的

我下面就来分析分析，我作为一个才接触这两个屏幕适配方案的吃瓜群众，我是怎么来验证这两种屏幕适配方案是否可行，以及怎样根据它们的优缺点来选择一个最适合自己项目的屏幕适配方案

这是我推荐给大家的屏幕适配框架，本来想放到最后作为福利的，害怕大家看不到，所以就将链接放到这里，提前送给大家

Github : 您的 Star 是我坚持的动力 ✊

浅谈适配方案

在 拉丁吴 老师的文章中谈到了两个比较经典的屏幕适配方案，在我印象中十分深刻，我想大多数兄弟都用过，在我的开发生涯里也是有很长一段时间都在用这两种屏幕适配方案

第一种就是宽高限定符适配，什么是宽高限定符适配呢

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-800x480
│   ├── ├──values-860x540
│   ├── ├──values-1024x600
│   ├── ├──values-1024x768
│   ├── ├──...
│   ├── ├──values-2560x1440

就是这种，在资源文件下生成不同分辨率的资源文件，然后在布局文件中引用对应的 dimens，大家一定还有印象

第二种就是 鸿神 的 AndroidAutoLayout

这两种方案都已经逐渐退出了历史的舞台，为什么想必大家都知道，不知道的建议看看 拉丁吴 老师的文章，所以这两种方案我在文章中就不在阐述了，主要讲讲现在最主流的两种屏幕适配方案，今日头条适配方案 和 smallestWidth 限定符适配方案

建议大家不清楚这两个方案的先看看这两篇文章，才清楚我在讲什么，后面我要讲解它们的原理，以及验证这两种方案是否真的可行，最后对他们进行深入对比，对于他们的一些缺点给予对应的解决方案，绝对干货

今日头条屏幕适配方案

原理

上面已经告知，不了解这两个方案的先看看上面的两篇文章，所以这里我就假设大家已经看了上面的文章或者之前就了解过这两个方案，所以在本文中我就不再阐述 DPI、Density 以及一些比较基础的知识点，上面的文章已经阐述的够清楚了

今日头条屏幕适配方案的核心原理在于，根据以下公式算出 density

当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density

density 的意思就是 1 dp 占当前设备多少像素

为什么要算出 density，这和屏幕适配有什么关系呢？

public static float applyDimension(int unit, float value,
                                       DisplayMetrics metrics)
    {
        switch (unit) {
        case COMPLEX_UNIT_PX:
            return value;
        case COMPLEX_UNIT_DIP:
            return value * metrics.density;
        case COMPLEX_UNIT_SP:
            return value * metrics.scaledDensity;
        case COMPLEX_UNIT_PT:
            return value * metrics.xdpi * (1.0f/72);
        case COMPLEX_UNIT_IN:
            return value * metrics.xdpi;
        case COMPLEX_UNIT_MM:
            return value * metrics.xdpi * (1.0f/25.4f);
        }
        return 0;
    }

大家都知道，不管你在布局文件中填写的是什么单位，最后都会被转化为 px，系统就是通过上面的方法，将你在项目中任何地方填写的单位都转换为 px 的

所以我们常用的 px 转 dp 的公式 dp = px / density，就是根据上面的方法得来的，density 在公式的运算中扮演着至关重要的一步

要看懂下面的内容，还得明白，今日头条的适配方式，今日头条适配方案默认项目中只能以高或宽中的一个作为基准，进行适配，为什么不像 AndroidAutoLayout 一样，高以高为基准，宽以宽为基准，同时进行适配呢

这就引出了一个现在比较棘手的问题，大部分市面上的 Android 设备的屏幕高宽比都不一致，特别是现在大量全面屏的问世，这个问题更加严重，不同厂商推出的全面屏手机的屏幕高宽比都可能不一致

这时我们只以高或宽其中的一个作为基准进行适配，就会有效的避免布局在高宽比不一致的屏幕上出现变形的问题

明白这个后，我再来说说 density，density 在每个设备上都是固定的，DPI / 160 = density，屏幕的总 px 宽度 / density = 屏幕的总 dp 宽度

• 设备 1，屏幕宽度为 1080px，480DPI，屏幕总 dp 宽度为 1080 / (480 / 160) = 360dp

• 设备 2，屏幕宽度为 1440，560DPI，屏幕总 dp 宽度为 1440 / (560 / 160) = 411dp

可以看到屏幕的总 dp 宽度在不同的设备上是会变化的，但是我们在布局中填写的 dp 值却是固定不变的

这会导致什么呢？假设我们布局中有一个 View 的宽度为 100dp，在设备 1 中 该 View 的宽度占整个屏幕宽度的 27.8% (100 / 360 = 0.278)

但在设备 2 中该 View 的宽度就只能占整个屏幕宽度的 24.3% (100 / 411 = 0.243)，可以看到这个 View 在像素越高的屏幕上，dp 值虽然没变，但是与屏幕的实际比例却发生了较大的变化，所以肉眼的观看效果，会越来越小，这就导致了传统的填写 dp 的屏幕适配方式产生了较大的误差

这时我们要想完美适配，那就必须保证这个 View 在任何分辨率的屏幕上，与屏幕的比例都是相同的

这时我们该怎么做呢？改变每个 View 的 dp 值？不现实，在每个设备上都要通过代码动态计算 View 的 dp 值，工作量太大

如果每个 View 的 dp 值是固定不变的，那我们只要保证每个设备的屏幕总 dp 宽度不变，就能保证每个 View 在所有分辨率的屏幕上与屏幕的比例都保持不变，从而完成等比例适配，并且这个屏幕总 dp 宽度如果还能保证和设计图的宽度一致的话，那我们在布局时就可以直接按照设计图上的尺寸填写 dp 值

屏幕的总 px 宽度 / density = 屏幕的总 dp 宽度

在这个公式中我们要保证 屏幕的总 dp 宽度 和 设计图总宽度 一致，并且在所有分辨率的屏幕上都保持不变，我们需要怎么做呢？屏幕的总 px 宽度 每个设备都不一致，这个值是肯定会变化的，这时今日头条的公式就派上用场了

当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density

这个公式就是把上面公式中的 屏幕的总 dp 宽度 换成 设计图总宽度，原理都是一样的，只要 density 根据不同的设备进行实时计算并作出改变，就能保证 设计图总宽度 不变，也就完成了适配

验证方案可行性

上面已经把原理分析的很清楚了，很多文章只是一笔带过这个公式，公式虽然很简单但我们还是想晓得这是怎么来的，所以我就反向推理了一遍，如果还是看不懂，那我只能说我尽力了，原理讲完了，那我们再来现场验证一下这个方案是否可行?

假设设计图总宽度为 375 dp，一个 View 在这个设计图上的尺寸是 50dp * 50dp，这个 View 的宽度占整个设计图宽度的 13.3% (50 / 375 = 0.133)，那我们就来验证下在使用今日头条屏幕适配方案的情况下，这个 View 与屏幕宽度的比例在分辨率不同的设备上是否还能保持和设计图中的比例一致

验证设备 1

屏幕总宽度为 1080 px，根据今日头条的的公式求出 density，1080 / 375 = 2.88 (density)

这个 50dp * 50dp 的 View，系统最后会将高宽都换算成 px，50dp * 2.88 = 144 px (根据公式 dp * density = px)

144 / 1080 = 0.133，View 实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以完成了等比例缩放

某些设备总宽度为 1080 px，但是 DPI 可能不同，是否会对今日头条适配方案产生影响？其实这个方案根本没有根据 DPI 求出 density，是根据自己的公式求出的 density，所以这对今日头条的方案没有影响

上面只能确定在所有屏幕总宽度为 1080 px 的设备上能完成等比例适配，那我们再来试试其他分辨率的设备

验证设备 2

屏幕总宽度为 1440 px，根据今日头条的的公式求出 density，1440 / 375 = 3.84 (density)

这个 50dp * 50dp 的 View，系统最后会将高宽都换算成 px，50dp * 3.84 = 192 px (根据公式 dp * density = px)

192 / 1440 = 0.133，View 实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，所以也完成了等比例缩放

两个不同分辨率的设备都完成了等比例缩放，证明今日头条屏幕适配方案在不同分辨率的设备上都是有效的，如果大家还心存疑虑，可以再试试其他分辨率的设备，其实到最后得出的比例不会有任何偏差, 都是 0.133

优点

1. 使用成本非常低，操作非常简单，使用该方案后在页面布局时不需要额外的代码和操作，这点可以说完虐其他屏幕适配方案

2. 侵入性非常低，该方案和项目完全解耦，在项目布局时不会依赖哪怕一行该方案的代码，而且使用的还是 Android 官方的 API，意味着当你遇到什么问题无法解决，想切换为其他屏幕适配方案时，基本不需要更改之前的代码，整个切换过程几乎在瞬间完成，会少很多麻烦，节约很多时间，试错成本接近于 0

3. 可适配三方库的控件和系统的控件(不止是是 Activity 和 Fragment，Dialog、Toast 等所有系统控件都可以适配)，由于修改的 density 在整个项目中是全局的，所以只要一次修改，项目中的所有地方都会受益

4. 不会有任何性能的损耗

缺点

暂时没发现其他什么很明显的缺点，已知的缺点有一个，那就是第三个优点，它既是这个方案的优点也同样是缺点，但是就这一个缺点也是非常致命的

只需要修改一次 density，项目中的所有地方都会自动适配，这个看似解放了双手，减少了很多操作，但是实际上反应了一个缺点，那就是只能一刀切的将整个项目进行适配，但适配范围是不可控的

这样不是很好吗？这样本来是很好的，但是应用到这个方案是就不好了，因为我上面的原理也分析了，这个方案依赖于设计图尺寸，但是项目中的系统控件、三方库控件、等非我们项目自身设计的控件，它们的设计图尺寸并不会和我们项目自身的设计图尺寸一样

当这个适配方案不分类型，将所有控件都强行使用我们项目自身的设计图尺寸进行适配时，这时就会出现问题，当某个系统控件或三方库控件的设计图尺寸和和我们项目自身的设计图尺寸差距非常大时，这个问题就越严重

举个栗子

假设一个三方库的 View，作者在设计时，把它设计为 100dp * 100dp，设计图的最大宽度为 1000dp，这个 View 在设计图中的比例是 100 / 1000 = 0.1，意思是这个 View 的宽度在设计图中占整个宽度的 10%，如果我们要完成等比例适配，那这个三方库 View 在所有的设备上与屏幕的总宽度的比例，都必须保持在 10%

这时在一个使用今日头条屏幕适配方案的项目上，设置的设计图最大宽度如果是 1000dp，那这个三方库 View，与项目自身都可以完美的适配，但当我们项目自身的设计图最大宽度不是 1000dp，是 500dp 时，100 / 500 = 0.2，可以看到，比例发生了较大的变化，从 10% 上升为 20%，明显这个三方库 View 高于作者的预期，比之前更大了

这就是两个设计图尺寸不一致导致的非常严重的问题，当两个设计图尺寸差距越大，那适配的效果也就天差万别了

解决方案

方案 1

调整设计图尺寸，因为三方库可能是远程依赖的，无法修改源码，也就无法让三方库来适应我们项目的设计图尺寸，所以只有我们自身作出修改，去适应三方库的设计图尺寸，我们将项目自身的设计图尺寸修改为这个三方库的设计图尺寸，就能完成项目自身和三方库的适配

这时项目的设计图尺寸修改了，所以项目布局文件中的 dp 值，也应该按照修改的设计图尺寸，按比例增减，保持与之前设计图中的比例不变

但是如果为了适配一个三方库修改整个项目的设计图尺寸，是非常不值得的，所以这个方案支持以 Activity 为单位修改设计图尺寸，相当于每个 Activity 都可以自定义设计图尺寸，因为有些 Activity 不会使用三方库 View，也就不需要自定义尺寸，所以每个 Activity 都有控制权的话，这也是最灵活的

但这也有个问题，当一个 Activity 使用了多个设计图尺寸不一样的三方库 View，就会同样出现上面的问题，这也就只有把设计图改为与几个三方库比较折中的尺寸，才能勉强缓解这个问题

方案 2

第二个方案是最简单的，也是按 Activity 为单位，取消当前 Activity 的适配效果，改用其他的适配方案

使用中的问题

有些文章中提到了今日头条屏幕适配方案可以将设计图尺寸填写成以 px 为单位的宽度和高度，这样我们在布局文件中，也就能直接填写设计图上标注的 px 值，省掉了将 px 换算为 dp 的时间 (大部分公司的设计图都只标注 px 值)，而且照样能完美适配

但是我建议大家千万不要这样做，还是老老实实的以 dp 为单位填写 dp 值，为什么呢？

直接填写 px 虽然刚开始布局的时候很爽，但是这个坑就已经埋上了，会让你后面很爽，有哪些坑？

第一个坑

这样无疑于使项目强耦合于这个方案，当你遇到无法解决的问题想切换为其他屏幕适配方案的时候，layout 文件里曾经填写的 px 值都会作为 dp

比如你的设计图实际宽度为 1080px，你不换算为 360dp (1080 / 3 = 360)，却直接将 1080px 作为这个方案的设计图尺寸，那你在 layout 文件中，填写的也都是设计图上标注的 px 值，但是单位却是 dp

一个在设计图上 300px * 300px 的 View，你可以直接在 layout 文件中填写为 300dp，而由于这个方案可以动态改变 density 的原因还是可以做到等比例适配，非常爽!

但你不要忘了，这样你就强耦合于这个方案了，因为当你不使用这个方案时，density 是不可变的!

举个栗子

使用这个方案时，在屏幕宽度为 1080px 的设备上，将设计图宽度直接填写为 1080，根据今日头条公式

当前设备屏幕总宽度 / 设计图总宽度 = density

这时得出 density 为 1 (1080 / 1080 = 1)，所以你在 layout 文件中你填写的 300dp 最后转换为 px 也是 300px (300dp * 1 = 300px 根据公式 dp * density = px)

在这个方案的帮助下非常完美，和设计图一模一样完成了适配

但当你不使用这个方案时，density 的换算公式就变为官方的 DPI / 160 = density，在这个屏幕宽度为 1080px，480dpi 的设备上，density 就固定为 3 (480 / 160 = 3)

这时再来看看你之前在 layout 文件中填写的 dp，换算成 px 为 900 px (300dp * 3 = 900px 根据公式 dp * density = px)

原本在在设计图上为 300px 的 View，这时却达到了惊人的 900px，3倍的差距，恭喜你，你已经强耦合于这个方案了，你要不所有 layout 文件都改一遍，要不继续使用这个方案

第二个坑

第二个坑其实就是刚刚在上面说的今日头条适配方案的缺点，当某个系统控件或三方库控件的设计图尺寸和和我们项目自身的设计图尺寸差距非常大时，这个问题就越严重

你如果直接填写以 px 为设计图的尺寸，这不用想，肯定和所有的三方库以及系统控件的设计图尺寸都不一样，而且差距都非常之大，至少两三倍的差距，这时你在当前页面弹个 Toast 就可以明显看到，比之前小很多，可以说是天差万别，用其他三方库 View，也是一样的，会小很多

因为你以 px 为单位填写设计图尺寸，人家却用的 dp，差距能不大吗，你如果老老实实用 dp，哪怕三方库的设计图尺寸和你项目自身的设计图尺寸不一样，那也差距不大，小到一定程度，基本都不用调整，可以忽略不计，而且很多三方库的设计图尺寸其实也都是那几个大众尺寸，很大可能和你项目自身的设计图尺寸一样

总结

可以看到我讲的非常详细，可以说比今日头条官方以及任何博客写的都清楚，从原理到优缺点再到解决方案一应俱全，因为篇幅有限，如果我还想把 smallestWidth 限定符适配方案写的这么详细，那估计这篇文章得有一万字了

所以我把这次的屏幕适配文章归位一个系列，一共分为三篇，第一篇详细的讲 今日头条屏幕适配方案，第二篇详细的讲 smallestWidth 限定符适配方案，第三篇详细讲两个方案的深入对比以及如何选择，并发布我根据 今日头条屏幕适配方案 优化的屏幕适配框架 AndroidAutoSize

今日头条屏幕适配方案 官方公布的核心源码只有 30 行不到，但我这个框架的源码有 1500 行以上，在保留原有特性的情况下增加了不少功能和特性，功能增加了不少，但是使用上却变简单了

<manifest>
    <application>            
        <meta-data
            android:name="design_width_in_dp"
            android:value="360"/>
        <meta-data
            android:name="design_height_in_dp"
            android:value="640"/>           
     </application>           
</manifest>

只要这一步填写了设计图的高宽以 dp 为单位，你什么都不做，框架就开始适配了

大家可以提前看看我是怎么封装和优化的，我后面的第三篇文章会给出这个框架的原理分析，敬请期待

关于大家的评论以及关注的问题，我在这里统一回复一下:

感谢，大家的关注和回复，我介绍这个今日头条的屏幕适配方案并不是说他有多么完美，只是他确实有效而且能帮我们减少很多开发成本

对于很多人说的 DPI 的存在，不就是为了让大屏能显示更多的内容，如果一个大屏手机和小屏手机，显示的内容都相同，那用户买大屏手机又有什么意义呢，我觉得大家对 DPI 的理解是对的，这个观点我也是认同的，Google 设计 DPI 时可能也是这么想的，但是有一点大家没考虑到，Android 的碎片化太严重了

为什么 Android 诞生这么多年，Android 的百分比库层出不穷，按理说他们都违背了上面说的这个理念，但为什么还有这么多人去研究百分比库通过各种方式去实现百分比布局 (谷歌官方也曾出过百分比库)？为什么？很简单，因为需求啊！为什么需求，因为开发成本低啊！为什么今日头条的这个屏幕适配方案现在能这么火，因为他的开发成本是目前所有屏幕适配方案中最低的啊！

DPI 的意义谁又不懂呢？难道就你懂，今日头条这种大公司的程序员不懂这个道理吗？今日头条这么大的公司难道不想把每个机型每个版本的设备都适配完美，让自己的 App 体验更好，哪怕付出更大的成本，有些时候想象是美好的，但是这个投入的成本，谁又能承担呢，连今日头条这么大的公司，这么雄厚的资本都没选择投入更大的成本，对每个机型进行更精细化的适配，难道市面上的中小型公司又有这个能力投入这么大的成本吗？

鱼和熊掌不可兼得，DPI 的意义在 Google 的设计理念中是完全正确的，但不是所有公司都能承受这个成本，想必今日头条的程序员，也是因为今日头条 App 的用户量足够多，机型分布足够广，也是被屏幕适配这个问题折磨的不要不要的，才想出这么个不这么完美但是却很有效的方案

以下是 骚年你的屏幕适配方式该升级了! 系列文章，欢迎转发以及分享:

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!

Hello 我叫 JessYan，如果您喜欢我的文章，可以在以下平台关注我

• 个人主页: https://jessyan.me
• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

我在之前的文章 《解决Retrofit多BaseUrl及运行时动态改变BaseUrl》 中，介绍了市面上能够解决此类问题的 4 个常见的解决方案，并开源了自己经过优化后的解决方案 RetrofitUrlManager，现在再为大家带来此系列的第二篇文章，这篇文章主要介绍 RetrofitUrlManager 针对 BaseUrl 替换逻辑的重大升级，因为这个升级对于 RetrofitUrlManager 足够重要，将使 RetrofitUrlManager 能够从容应对更多复杂的需求，所以单独写一篇文章让更多的人能够知道

Github : 您的 Star 是我坚持的动力 ✊

为什么不使用多 Retrofit 实例的方案?

在上篇文章 《解决Retrofit多BaseUrl及运行时动态改变BaseUrl》 中，4 种方案的特点和不足我都描述的很清楚，建议没看过这篇文章的可以去看看这篇文章，扩宽知识面，在后面的时间里经常有人问我为什么不使用多 Retrofit 实例的方案，多个 Retrofit 实例看起来并不会占用多少资源啊?

在回答之前为了让看这篇文章的人能了解我在说什么，所以我再粘贴下 上篇文章 中关于这个方案的部分描述

民间常用解决方案:
之前也看过很多开源的聚合类 App 源码, 像一些整合 知乎、 豆瓣、 Gank 等多个平台数据的 App, 因为各自平台的域名不同, 所以大多数这类 App 会给每个平台都各自创建一个 Retrofit 对象, 即不同的 BaseUrl 使用不同的 Retrofit 对象来创建 ApiService 进行请求, 这样只要新增一个不同的 BaseUrl, 那就需要重新创建一个新的 Retrofit 对象

我在这篇文章中重新回答下这个问题，为每个不同的 BaseUrl 都创建一个其他配置属性都一模一样的 Retrofit 实例不止会造成资源的浪费，还会造成接口管理成本的增加，这个才是最重要的一点, 举个例

我们平时项目中所有的 ApiService 都是使用同一个 Retrofit 实例的 Retrofit#create(ApiService) 方法进行实例化后开始接口的请求

但是当项目中出现多个 Retrofit 实例后，我们在开发中不光要区分哪些接口使用哪个 ApiService，还要区分哪些 ApiService 需要使用哪个 Retrofit 实例进行实例化，如果 ApiService 使用错误的 Retrofit 实例进行实例化，那这个 ApiService 的所有接口请求都注定完全失败

越复杂的项目，开发人数越多的项目，出错的风险就越大，并且扩展性也在大打折扣，后面一有变更将会十分痛苦，随着项目中接口的增加，以及 Retrofit 实例的增加 (BaseUrl 的增加)，这个管理成本会成几何倍的增加

使用多 Retrofit 实例的方案前期投入成本过高，可能会影响之前项目管理接口的方式，某些封装过 Retrofit 的项目，也可能需要大改，对于老项目的接入不利，而使用 RetrofitUrlManager 不仅可以满足多 BaseUrl 及运行时动态改变 BaseUrl 的需求，还具有热插拔以及低侵入性的特点，在使用过程中将不会影响到之前的接口管理方式和使用方式，还具有极强的扩展性，可应对后面陆续增加的极其复杂的 BaseUrl 替换需求

升级之前的 RetrofitUrlManager 的问题

此次升级之前的 RetrofitUrlManager 版本，只是将 上篇文章 的思想完全实现，有了整个框架的基础，但是在动态替换 BaseUrl 方面还不够强大，最被大家吐槽的就是只能替换 BaseUrl 的域名

比如一个需要替换 BaseUrl 的 Url 地址为 "https:www.google.com/api/v2"，其中 "https:www.google.com/api" 是我们传给 Retrofit 的 BaseUrl，这时我们使用 RetrofitUrlManager 框架，想把 BaseUrl 替换成 "https:www.github.com"，我们期望的替换后的 URL 地址是 "https:www.github.com/v2"，但使用框架替换后的实际 URL 地址是 "https:www.github.com/api/v2", "/api" 作为 BaseUrl 的一部分并没有被新的 BaseUrl 替换掉，只是替换了 BaseUrl 中的域名

RetrofitUrlManager 是如何改善的

改善之前先要先分析为什么会这样？因为 RetrofitUrlManager 框架在拦截器中拦截到的 URL 地址是 Retrofit 已经把 BaseUrl 和接口注解中的相对路径合并后得到的最终路径地址，所以框架并不知道您传给 Retrofit 的 BaseUrl 除了域名外还包含后面的 "/api"，框架不知道 BaseUrl 的具体值，所以框架只会默认所有的 BaseUrl 都只含有域名，所以也就只能替换域名

高级模式

想要解决此类问题也很简单，告诉 RetrofitUrlManager 框架您传给 Retrofit 的 BaseUrl 具体值即可，所以框架升级后增加了 RetrofitUrlManager#startAdvancedModel(String) 方法，在 App 初始化时将您传给 Retrofit 的 BaseUrl 同样传给此方法，即可开启高级模式，高级模式即可替换拥有多个 pathSegments 的 BaseUrl，不再局限于只能替换域名

什么是 pathSegment?

在 "https://www.github.com/wiki/part?name=jess" 中，其中的 "/wiki" 和 "/part" 就是 pathSegment, PathSize 就是 pathSegment 的个数

这个 URL 地址的 PathSize 就是 2, 第一个 pathSegment 是 "/wiki"，第二个 pathSegment 是 "/part"，可以粗略的理解为域名后面跟了几个 "/" PathSize 就是几

高级模式的替换规则

1. 旧 URL 地址为 "https://www.github.com/wiki/part"，您在 App 初始化时传入 RetrofitUrlManager#startAdvancedModel(String) 的 BaseUrl 为 "https://www.github.com/wiki"，您想替换成的 BaseUrl 地址是 "https://www.google.com/api"，经过框架替换后生成的最终 URL 地址为 "http://www.google.com/api/part"

2. 旧 URL 地址为 "https://www.github.com/wiki/part"，您在 App 初始化时传入 RetrofitUrlManager#startAdvancedModel(String) 的 BaseUrl 为 "https://www.github.com/wiki"，您想替换成的 BaseUrl 地址是 "https://www.google.com"，经过框架替换后生成的最终 URL 地址为 "http://www.google.com/part"

3. 旧 URL 地址为 "https://www.github.com/wiki/part", 您在 App 初始化时传入 RetrofitUrlManager#startAdvancedModel(String) 的 BaseUrl 为 "https://www.github.com"，您想替换成的 BaseUrl 地址是 "https://www.google.com/api"，经过框架替换后生成的最终 URL 地址为 "http://www.google.com/api/wiki/part"

超级模式

超级模式是高级模式的加强版，优先级高于高级模式，按理说高级模式就能满足开发中的大部分需求，那什么又是超级模式呢？那就要先来说说高级模式了

高级模式的原理

在高级模式中您需要在 App 初始化时将您传给 Retrofit 的 BaseUrl 同样传给 RetrofitUrlManager#startAdvancedModel(String) 一份，用以开启高级模式，成功开启高级模式后，这个传给 RetrofitUrlManager#startAdvancedModel(String) 的 BaseUrl 就会作为框架替换 BaseUrl 的基准

什么叫作基准呢? 用此 BaseUrl 开启高级模式，并不意味着框架就只能替换 域名 为 "www.github.com" 前两个 pathSegments 为 "/wiki/part" 的 URL，只要拥有域名以及大于或等于两个 pathSegments 的 URL 都可以被框架替换，因此高级模式只会保存传入 RetrofitUrlManager#startAdvancedModel(String) 的 BaseUrl 的格式 (保存 pathSegments 的个数)，并不是保存具体的值

高级模式的局限

如果传给 RetrofitUrlManager#startAdvancedModel(String) 的 BaseUrl 为 "https://www.github.com/wiki/part" (PathSize = 2)，框架就会将项目中所有 URL 中的 域名 以及 域名 后面的前两个 pathSegments 作为可被替换的 BaseUrl 整体，意味着框架只会将 URL 中的 域名 以及前两个 pathSegments 剪切并替换为您期望的 BaseUrl

这时服务器突然作出调整，项目中的一部分 URL 只需要将 "https://www.github.com/wiki" (PathSize = 1) 替换掉, 第二个 pathSegment "/part" 不再作为 BaseUrl 的一部分，不能被替换掉，必须要保留下来

这时项目中就出现了多个需要被替换的 BaseUrl 格式 (PathSize 不同)，有些 URL 只需要替换 域名 以及前两个 pathSegments，有些又只需要替换 域名 以及前一个 pathSegments，但是在开启高级模式时，只保存了一个 BaseUrl 的格式，这时使用高级模式实现此需求就比较棘手

这个需求是一个比较变态的需求，可能很多人遇不上，但是我想让您知道当您遇上了也不要怕，因为 RetrofitUrlManager 的超级模式已经帮您考虑周全

超级模式的用法

超级模式与高级模式不同的是，开启超级模式并不需要调用 API，只须要在需要开启超级模式的 Url 尾部加上 RetrofitUrlManager#IDENTIFICATION_PATH_SIZE (#baseurl_path_size=) + PathSize，这样就明确的告诉了框架，在这个 URL 中需要被替换的 BaseUrl 含有几个 pathSegments，相当于每个 URL 都可以指定自己需要被替换的 BaseUrl 的格式，这样就比高级模式只能在 App 初始化时，指定一个全局的 BaseUrl 格式灵活得多，如果当您开启高级模式的同时也开启了超级模式，由于超级模式的优先级高于高级模式，所以只会执行超级模式

超级模式的替换规则

1. 旧 URL 地址为 "https://www.github.com/wiki/part#baseurl_path_size=1"，"#baseurl_path_size=1" 表示其中 BaseUrl 为 "https://www.github.com/wiki"，您想替换成的 BaseUrl 地址是 "https://www.google.com/api"，经过框架替换后生成的最终 URL 地址为 "http://www.google.com/api/part"

2. 旧 URL 地址为 "https://www.github.com/wiki/part#baseurl_path_size=1"，"#baseurl_path_size=1" 表示其中 BaseUrl 为 "https://www.github.com/wiki"，您想替换成的 BaseUrl 地址是 "https://www.google.com"，经过框架替换后生成的最终 URL 地址为 "http://www.google.com/part"

3. 旧 URL 地址为 "https://www.github.com/wiki/part#baseurl_path_size=0"，"#baseurl_path_size=0" 表示其中 BaseUrl 为 "https://www.github.com"，您想替换成的 BaseUrl 地址是 "https://www.google.com/api"，经过框架替换后生成的最终 URL 地址为 "http://www.google.com/api/wiki/part"

4. 旧 URL 地址为 "https://www.github.com/wiki/part/issues/1#baseurl_path_size=3"，"#baseurl_path_size=3" 表示其中 BaseUrl 为 "https://www.github.com/wiki/part/issues"，您想替换成的 BaseUrl 地址是 "https://www.google.com/api"，经过框架替换后生成的最终 URL 地址为 "http://www.google.com/api/1"

三种模式比较

在升级之前，框架就只有一个默认的普通模式 (只能替换域名)，在升级之后新增了 高级模式 和 超级模式，这两个模式让框架变得更加强大，在上面的内容中也详细的介绍了这两个模式，现在就来总结下这三个模式，让大家能够按照自己的需求选择出最适合的模式

替换 BaseUrl 的自由程度 (可扩展性)

普通模式 < 高级模式 < 超级模式

• 普通模式: 只能替换域名

• 高级模式: 只能替换在 RetrofitUrlManager#startAdvancedModel(String) 中传入的固定 BaseUrl 格式

• 超级模式: 每个 URL 都可以随意指定可被替换的 BaseUrl 格式

使用上的复杂程度

普通模式 < 高级模式 < 超级模式

• 普通模式: 无需做过多配置

• 高级模式: 在 App 初始化时调用一次 RetrofitUrlManager#startAdvancedModel(String) 即可

• 超级模式: 每个需要开启超级模式的 URL 尾部都需要加入 RetrofitUrlManager#IDENTIFICATION_PATH_SIZE (#baseurl_path_size=) + PathSize

总结

由此可见，自由度越强，使用上也越复杂，所以可以根据自己的需求选择对应的模式，并且也可以根据需求的变化随意升级或降级这三种模式

这次更新让 RetrofitUrlManager 的能力提升了一个档次，足以应对各种复杂的 BaseUrl 替换需求，正因为 RetrofitUrlManager 极强的扩展性，现在甚至可以做到，让服务器可以通过远程动态控制项目中的多个 BaseUrl

如果还有什么问题或者需求可以给我提 Issues，如果 RetrofitUrlManager 能够给您带来实质的帮助，也请不要吝啬您的 Star

Hello 我叫Jessyan,如果您喜欢我的文章,可以在以下平台关注我

• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

我在 上篇文章 中介绍了 MVPArms 的官方快速组件化方案 ArmsComponent

当时一直强调 ArmsComponent 是 快速 的组件化方案, 但是在文章中只提供了一个近万字的官方文档, 却没展现出这个组件化方案的快速之处

看到近万字的文档后, 新手已经开始瑟瑟发抖了? 觉得入门成本太高想放弃?

写这篇文章的意义就是为了展现 快速 这两个字, 到底有多快? 飞快!

现在我可以不开玩笑的告诉大家, 官方文档上介绍的大部分内容和规范, 现在只需要一键就可以生成, 快速并且零差错, 让新手也可以很愉快的玩耍组件化, 极大的提升开发体验和效率, 你还有什么理由不选择 ArmsComponent 开启组件化的大门呢？

好了, 进入正题, 大家直接看下图

看了这个 GIF 图过后, 是不是已经跃跃欲试了? 点几下就可以生成组件? Are you kidding me? 那好, 您如果不信的话立马去安装然后试一试!

Github : 您的 Star 是我坚持的动力 ✊

使用须知

1. 先使用 ArmsComponent-Template (Module 级一键模板) 一键搭建整体组件架构, 再使用 MVPArmsTemplate (页面 级一键模板) 一键生成每个业务页面所需要的 MVP 及 Dagger2 相关类, 即可让什么都不懂的新手也可以一秒开始组件化项目!

2. 若您基于本模板修改并且开源于网络, 请注明出处, 尊重开源, 才有人愿意开源, 谢谢!

如何安装？

请将 NewArmsComponent 这个文件夹复制到 AndroidStudio Module 模版的存放路径, 请注意是复制整个文件夹, 不是里面的内容!

AndroidStudio Module 模版存放路径 (请注意 Module 级模板和页面级模板的存放路径不一样, 不要放错了!):

• Windows : AS安装目录/plugins/android/lib/templates/gradle-projects

• Mac : /Applications/Android Studio.app/Contents/plugins/android/lib/templates/gradle-projects

最后记得重启 AndroidStudio !

如何使用?

使用时按下图步骤即可, 也可以使用快捷键, Mac 的快捷键是在项目名上按 Command + n, 选择 Module, Windows 快捷键自己百度

注意事项

• 本模板是基于 ArmsComponent 开发的, 所以使用的是 ArmsComponent 的整体架构, 最优的方式是直接 clone 或下载 ArmsComponent 工程后, 在工程上面直接使用本模板, 开始业务的开发, 让您体验纯傻瓜式的组件化开发

• 使用本模板生成的组件马上就可以独立运行, 但是如果您想要集成调试, 还需要在宿主 App 中 依赖此组件

  dependencies {
      
    if (!isBuildModule.toBoolean()) {
        //在宿主 App 中使用 implementation 依赖业务组件, 业务组件的代码就会完全暴露给宿主 App, 不利于代码的隔离
        //使用 runtimeOnly 依赖业务组件, 可实现业务组件的代码在编译时对宿主 App 不可见, 仅在运行时对宿主 App 可见
        runtimeOnly project(":ModuleZhihu")
        runtimeOnly project(":ModuleGank")
        runtimeOnly project(":ModuleGold")
        runtimeOnly project(":组件名(Module name)")
    }
  }
  

• 此模板会持续保持更新, 但只保证能够兼容最新的 AndroidStudio 稳定版, 暂不提供其他版本

  

  

Hello 我叫Jessyan,如果您喜欢我的文章,可以在以下平台关注我

• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

• 0 前言
  • 0.1 起源
  • 0.2 组件化方案分析
    • 0.2.1 业务组件的划分和代码隔离
    • 0.2.2 路由框架
    • 0.2.3 基础库
  • 0.3 ArmsComponent 的优势
• 1 简介
  • 1.1 什么是组件化?
  • 1.2 为什么要组件化?
  • 1.3 分析现有的组件化方案
  • 1.4 如何选择组件化方案?
• 2 组件化方案描述
  • 2.1 架构图一览
  • 2.2 架构图详解
    • 2.2.1 宿主层
    • 2.2.2 业务层
      • 2.2.2.1 业务模块的拆分
    • 2.2.3 基础层
      • 2.2.3.1 核心基础业务
      • 2.2.3.2 公共服务
      • 2.2.3.3 基础 SDK
        • 2.2.3.3.1 MVPArms
        • 2.2.3.3.2 UI 组件
        • 2.2.3.3.3 其他 SDK
  • 2.3 跨组件通信
    • 2.3.1 为什么需要跨组件化通信?
    • 2.3.2 跨组件通信场景
    • 2.3.3 跨组件通信方案
    • 2.3.4 跨组件通信方案分析
    • 2.3.5 跨组件传递复杂数据格式
  • 2.4 组件的生命周期
    • 2.4.1 问题分析
    • 2.4.2 可行方案分析
    • 2.4.3 最终执行方案
• 3 项目讲解
  • 3.1 如何让组件独立运行?
  • 3.2 配置 AndroidManifest
  • 3.3 配置 ConfigModule
  • 3.4 RouterHub
  • 3.5 EventBusHub
  • 3.6 在项目中使用多个不同的域名

0 前言

MVPArms 从两年前开源至今, 已经累积了 5k star, 获得了上千个商业项目的信赖和认可

回顾两年前, 那时 MVPArms 还没诞生, MVP、Dagger2、Rxjava、Retrofit 这些技术在国内才刚刚开始流行, 在网上能搜索到的中文学习资料远没有现在这么丰富, 特别是 Dagger, 在网上能搜索到的文章甚至有很多讲的是 Square 的 Dagger1, 学习资料的匮乏加上 Dagger2 本身就是块硬骨头, 让本人在学习的道路上不知道多走了多少弯路

从那时开始, 让初学者都能够快速搭建一个 MVP + Dagger2 + Retrofit + Rxjava 项目的种子就已经深埋在心中, 后面经过不懈的努力, MVPArms 终于诞生并开源了, 开源以后只是一直坚持将 代码, 注释 和 文档 做到极致, 没想到的是, MVPArms 能发展到如今的体量, 感谢开源!

0.1 起源

这是 MVPArms 的起源, ArmsComponent 的起源同样相似, 从去年开始, 组件化逐渐火热起来, 本人也在去年年初开始在公司项目中进行组件化, 一切还算顺利

那时同样的种子继续埋在了心中, 我想让刚刚接触组件化的初学者也能快速搭建一个中小型的组件化项目, 经过一年的不断优化, 终于决定将其开源(MVPArms 官方组件化方案 ArmsComponent)

Github : 您的 Star 是我坚持的动力 ✊

0.2 组件化方案分析

看了很多组件化方案, 所以总结了在组件化中很重要的三个大点:

1. 基础库(网络请求、图片加载等)的封装
2. 路由框架(页面跳转, 服务提供)
3. 业务组件的划分和代码隔离

0.2.1 业务组件的划分和代码隔离

先说第三点 业务组件的划分和代码隔离, 现在大部分的文章都围绕着这点, 我这里发表下个人的观点, 第三点确实是很重要的一点, 不管是大厂的方案还是小厂的方案都有借鉴之处, 但是这点也是最不可能讨论出最终结果和统一解决方案的一点

每个公司、每个项目的情况都不一样, 大厂的方案真的适合您吗? 不一定, 大厂几十个业务群, 几百号开发人员, 他们的组织结构和项目规模都不是普通公司能比拟的, 如果伸拉硬套他们的方案, 进行更严格更细粒度的代码隔离, 可能产出的价值还不及您先前付出的代价, 带来效率的降低, 所以根据项目的实际情况做出灵活的调整才是项目负责人最应该干的事, 这点我在后面会有详细的介绍

0.2.2 路由框架

陆续也有很多组件化方案开源自己的 路由框架, 是个很不错的开始, 我觉得大家写的都不错, 各有各的优势, 本方案也决定用别人的 路由框架, 自己写的原理也差不多, 还不一定比别人考虑的完善, 还要自己维护, 为什么不选择一个成熟稳定的呢？

0.2.3 基础库

很多组件化文章只是在讲如何拆分以及封装基础库, 但是至今没看到有哪个组件化方案开源过完整的基础库的, 我猜测原因可能是, 组件化方案都是从商业项目不断的业务迭代中逐渐完善的, 基础库也属于公司的核心机密, 所以不可能开源

但是基础库尤其重要, 特别是兼容组件化的基础库, 这关乎到组件化方案的根基, 根基都没有, 何谈其他更高级的功能? 但是从封装到完善一个兼容组件化的基础库是需要很长时间的, 大多数中小公司是不愿意投入这个成本的

0.3 ArmsComponent 的优势

ArmsComponent 拥有一键自动生成组件功能, 可以一键搭建整体组件架构, 让您体验纯傻瓜式的组件化开发, 虽然一键搭建功能让新手也可以一秒开始组件化项目, 但本方案还是提供有上万字的详细文档让您可以更深入的了解本方案, 并且 JessYan 郑重承诺, ArmsComponent 将和 MVPArms 一起持续维护下去, ArmsComponent 绝对是一个真正用心对待的组件化方案

MVPArms 是一个开源两年, 成熟稳定, 涵盖大量主流技术且兼容组件化的基础库, MVPArms 使得 ArmsComponent 成为了唯一提供完整基础库的组件化方案, 这就是 ArmsComponent 相对于其他组件化方案最大的优势

因为有了 基础库 的存在, 再加上已有的 路由框架, 组件化中的三个大点就已经占有两个(业务组件的划分和代码隔离 在后面会有介绍), 因此使用 ArmsComponent 启动一个新项目, 即可快速进行组件化, 将 Demo (组件化项目雏形) 克隆下来后, 稍作修改, 马上就可以投入到业务的开发之中

ArmsComponent 对于新项目以及已经开始使用 MVPArms 的项目将会更加便捷, 有着优于其他组件化方案的体验, 对于那些网络请求, 图片加载等基础功能乱七八糟散落到项目各处, 没有统一抽离出来的旧项目, 建议直接使用 MVPArms, 开始组件化

如果您不想使用 MVPArms, 觉得接入成本太大, 没关系, 借鉴下 MVPArms 和 ArmsComponent 的代码, 尝试改造自己的项目, 也是个不错的选择

1 简介

好了, 进入正题!

1.1 什么是组件化?

组件化简单概括就是把一个功能完整的 App 或模块拆分成多个子模块, 每个子模块可以独立编译和运行, 也可以任意组合成另一个新的 App 或模块, 每个模块即不相互依赖但又可以相互交互, 遇到某些特殊情况甚至可以升级或者降级

1.2 为什么要组件化?

现在的项目随着需求的增加规模变得越来越大, 规模的增大带来了很多烦恼, 各种业务错中复杂的交织在一起, 每个业务模块之间, 代码没有约束, 带来了代码边界的模糊, 代码冲突时有发生, 更改一个小问题可能引起一些新的问题, 牵一发而动全身, 增加一个新需求, 瞻前顾后的熟悉了大量前辈们写的代码后才敢动手, 编译时间也不在断增加, 开发效率极度的下降, 在这种情况下组件化的出现就是为了解决以上的烦恼

1.3 分析现有的组件化方案

很多大厂的组件化方案是以 多工程 + 多 Module 的结构(微信, 美团等超级 App 更是以 多工程 + 多 Module + 多 P 工程(以页面为单元的代码隔离方式) 的三级工程结构), 使用 Git Submodule 创建多个子仓库管理各个模块的代码, 并将各个模块的代码打包成 AAR 上传至私有 Maven 仓库使用远程版本号依赖的方式进行模块间代码的隔离

1.4 如何选择组件化方案?

按照康威定律, 系统架构的设计需要根据组织间的沟通结构, 因为现在大部分项目的规模和开发人员的数量以及结构还不足以需要某些大厂发布的组件化方案支撑(大厂的组织结构和项目规模都非常庞大, 他们的方案不一定完全适合所有公司的项目), 进行更严格更细粒度的代码间以及模块间的隔离, 盲目的使用某些组件化方案, 可能会带来开发效率降低, 开发成本远大于收益等情况, 性价比变低, 作为项目负责人, 应该根据项目目前的规模以及开发人员的组织结构去选择目前最适合的组件化方案, 做到以项目实际情况去制定技术方案, 而不是盲目跟随某些大厂的技术方案让项目和开发人员花费大量时间去调整和适应

2 组件化方案描述

ArmsComponent 目前采用的是 单工程 + 多 Module 的结构, 由于 Demo 较小仅仅为了展示基本规范, 所以也只是采用源码依赖并没有做到远程版本号依赖组件, 代码管理也只是采用 单仓库 + 多分支 的方式, 这样也是对于开发初期, 项目规模还较小, 开发人员也较少时, 开发效率较高的方案, 如果您的项目规模较大, 开发人员众多, 就可以采用上面提到的 多工程 + 多 Module, 并使用私有 Maven 仓库管理组件版本

世界上没有一个方案可以完美到兼顾所有情况, 并且还满足所有人, 所有项目的需求, 所以项目负责人必须按照项目实际情况做出灵活的调整, 才能做出最适合自家项目的方案

2.1 架构图一览

ArmsComponent 组件化架构图

2.2 架构图详解

目前架构一共分为三层, 从低到高依次是基础层, 业务层和宿主层, 由于目前项目较小人员较少所以三层都集中在一个工程中, 但您可以根据项目的规模和开发人员的数量拆分成多个工程协同开发

2.2.1 宿主层

宿主层位于最上层, 主要作用是作为一个 App 壳, 将需要的模块组装成一个完整的 App, 这一层可以管理整个 App 的生命周期(比如 Application 的初始化和各种组件以及三方库的初始化)

2.2.2 业务层

业务层位于中层, 里面主要是根据业务需求和应用场景拆分过后的业务模块, 每个模块之间互不依赖, 但又可以相互交互, 比如一个商城 App 由 搜索, 订单, 购物车, 支付 等业务模块组成

Tips: 每个业务模块都可以拥有自己独有的 SDK 依赖和自己独有的 UI 资源 (如果是其他业务模块都可以通用的 SDK 依赖 和 UI 资源 就可以将它们抽离到 基础 SDK(CommonSDK 2.2.3.3) 和 UI 组件(CommonRes 2.2.3.3.2) 中)

2.2.2.1 业务模块的拆分

写业务之前先不要急着动手敲码, 应该先根据初期的产品需求到后期的运营规划结合起来清晰的梳理一下业务在未来可能会发生的发展, 确定业务之间的边界, 以及可能会发生的变化, 最后再确定下来真正需要拆分出来的业务模块再进行拆分

2.2.3 基础层

基础层位于最底层, 里面又包括 核心基础业务模块、公共服务模块、 基础 SDK 模块, 核心基础业务模块 和 公共服务模块 主要为业务层的每个模块服务, 基础 SDK 模块 含有各种功能强大的团队自行封装的 SDK 以及第三方 SDK, 为整个平台的基础设施建设提供动力

2.2.3.1 核心基础业务

核心基础业务 为 业务层 的每个业务模块提供一些与业务有关的基础服务, 比如在项目中以用户角色分为 2 个端口, 用户可以扮演多个角色, 但是在线上只能同时操作一个端口的业务, 这时每个端口都必须提供一个角色切换的功能, 以供用户随时在多个角色中切换, 这时在项目中就需要提供一个用于用户自由切换角色的管理类作为 核心基础业务 被这 2 个端口所依赖(类似 拉勾, Boss 直聘等 App 可以在招聘者和应聘者之间切换)

核心基础业务 的划分应该遵循是否为业务层大部分模块都需要的基础业务, 以及一些需要在各个业务模块之间交互的业务, 都可以划分为 核心基础业务

2.2.3.2 公共服务

公共服务 是一个名为 CommonService 的 Module, 主要的作用是用于 业务层 各个模块之间的交互(自定义方法和类的调用), 包含自定义 Service 接口, 和可用于跨模块传递的自定义类

主要流程是:

提供服务的业务模块:

在公共服务(CommonService) 中声明 Service 接口 (含有需要被调用的自定义方法), 然后在自己的模块中实现这个 Service 接口, 再通过 ARouter API 暴露实现类

使用服务的业务模块:

通过 ARouter 的 API 拿到这个 Service 接口(多态持有, 实际持有实现类), 即可调用 Service 接口中声明的自定义方法, 这样就可以达到模块之间的交互

跨模块传递的自定义类:

在 公共服务 中定义需要跨模块传递的自定义类后 (Service 中的自定义方法和 EventBus 中的事件实体类都可能需要用到自定义类), 就可以通过 ARouter API, 在各个模块的页面之间跨模块传递这个自定义对象 (ARouter 要求在 URL 中使用 Json 参数传递自定义对象必须实现 SerializationService 接口)

Tips: 建议在 CommonService 中给每个需要提供服务的业务模块都建立一个单独的包, 然后在这个包下放 Service 接口 和 需要跨模块传递的自定义类, 这样更好管理

掌握公共服务层的用法最好要了解 ARouter 的 API

点击查阅 ARouter 文档

2.2.3.3 基础 SDK

基础 SDK 是一个名为 CommonSDK 的 Module, 其中包含了大量功能强大的 SDK, 提供给整个架构中的所有模块

2.2.3.3.1 MVPArms

MVPArms 是整个基础层中最重要的模块, 可谓是整个组件化架构中的心脏, 里面提供了开发一个完整项目所必须的一整套 API 和 SDK, 是整个项目的脚手架, 我用它来统一整个组件化方案的基础设施, 使每一个模块更加健壮, 因为有了 MVPArms, 使得 ArmsComponent 成为了唯一提供完整基础框架的组件化方案, 所以学习 ArmsComponent 之前必须先学会 MVPArms

学习 MVPArms 时请按以下排列顺序依次学习:

1.点击学习 Demo

2.点击查阅 详细文档

3.点击下载 一键生成代码插件

2.2.3.3.2 UI 组件

基础 SDK 中的 UI 组件 是一个名为 CommonRes 的 Module, 主要放置一些业务层可以通用的与 UI 有关的资源供所有业务层模块使用, 便于重用、管理和规范已有的资源

Tips: 值得注意的是, 业务层的某些模块如果出现有资源名命名相同的情况 (如两个图片命名相同), 当在宿主层集成所有模块时就会出现资源冲突的问题, 这时注意在每个模块的 build.gradle 中使用 resourcePrefix 标签给每个模块下的资源名统一加上不同的前缀即可解决此类问题

android {
    defaultConfig {
        minSdkVersion rootProject.ext.android["minSdkVersion"]
        ...
    }
    resourcePrefix "public_"
}

可以放置的资源类型有:

• 通用的 Style, Theme
• 通用的 Layout
• 通用的 Color, Dimen, String
• 通用的 Shape, Selector, Interpolator
• 通用的 图片资源
• 通用的 动画资源
• 通用的 自定义 View
• 通用的第三方 自定义 View

2.2.3.3.3 其他 SDK

其他 SDK 主要是 基础 SDK 依赖的一些业务层可以通用的 第三方库 和 第三方 SDK (比如 ARouter, 腾讯 X5 内核), 便于重用、管理和规范已有的 SDK 依赖

2.3 跨组件通信

2.3.1 为什么需要跨组件通信?

因为各个业务模块之间是各自独立的, 并不会存在相互依赖的关系, 所以一个业务模块是访问不了其他业务模块的代码的, 如果想从 A 业务模块的 A 页面跳转到 B 业务模块的 B 页面, 光靠模块自身是不能实现的, 所以这时必须依靠外界的其他媒介提供这个跨组件通信的服务

2.3.2 跨组件通信场景

跨组件通信主要有以下两种场景:

• 第一种是组件之间的页面跳转 (Activity 到 Activity, Fragment 到 Fragment, Activity 到 Fragment, Fragment 到 Activity) 以及跳转时的数据传递 (基础数据类型和可序列化的自定义类类型)

• 第二种是组件之间的自定义类和自定义方法的调用(组件向外提供服务)

2.3.3 跨组件通信方案

其实以上两种通信场景甚至其他更高阶的功能在 ARouter 中都已经被实现, ARouter 是 Alibaba 开源的一个 Android 路由中间件, 可以满足很多组件化的需求, 也是作为本方案中比较重要的一环, 需要认真看下文档, 了解下基本使用

关于跨组件通信框架, 本方案不做封装, 专业的事交给专业的人做, 此类优秀框架为数众多, 各有特点, 可以根据您的需求选择您喜欢的框架, 不一定非得是 ARouter, 选择 ARouter 也是因为 Alibaba 出品, 开源时间较长, 使用者众多, 相对稳定, 出现问题比较好沟通

2.3.4 跨组件通信方案分析

第一种组件之间的页面跳转不需要过多描述了, 算是 ARouter 中最基础的功能, API 也比较简单, 跳转时想传递不同类型的数据也提供有相应的 API (如果想通过在 URL 中使用 Json 参数传递自定义对象, 需要实现 SerializationService, 详情请查阅 ARouter 文档);

第二种组件之间的自定义类和自定义方法的调用要稍微复杂点, 需要 ARouter 配合架构中的 公共服务(CommonService) 实现, 主要流程在 公共服务(2.2.3.2) 中已有介绍, 这里我画了个示意图, 以便大家更好理解

跨组件通信示意图

此种服务提供方式叫作 接口下沉, 看图的同时请配合阅读 公共服务(2.2.3.2) 中的主要流程便于理解

本方案中还提供有 EventBus 来作为服务提供的另一种方式, 大家知道 EventBus 因为其解耦的特性, 如果被滥用的话会使项目调用层次结构混乱, 不便于维护和调试, 所以本方案使用 AndroidEventBus 其独有的 Tag, 可以在开发时更容易定位发送事件和接受事件的代码, 如果以组件名来作为 Tag 的前缀进行分组, 也可以更好的统一管理和查看每个组件的事件, 当然也不建议大家过多使用 EventBus

Tips: 每个跨组件通信框架提供服务的方式都不同, 您也可以选择其他框架的服务提供方式

2.3.5 跨组件传递复杂数据格式

在一般情况下基本数据类型就可以满足大多数跨组件传递数据的需求, 但是在某些情况下也会需要传递复杂的自定义数据类型, 传递自定义类型在方案中也提供有两种方式:

第一种在 公共服务(2.2.3.2) 中已提及, 就是在 公共服务 (CommonService) 中定义这个自定义类

第二种方式也比较简单, 直接通过解析 Json 字符串就可以传递

2.4 组件的生命周期

每个组件 (模块) 在测试阶段都可以独立运行, 在独立运行时每个组件都可以指定自己的 Application, 这时组件自己管理生命周期就轻而易举, 比如想在 onCreate 中初始化一些代码都可以轻松做到, 但是当进入集成调试阶段, 组件自己的 Application 已不可用, 每个组件都只能依赖于宿主的生命周期, 这时每个组件如果需要初始化自己独有的代码, 该怎么办?

2.4.1 问题分析

在集成调试阶段, 宿主依赖所有组件, 但是每个组件却不能依赖宿主, 意思是每个组件根本不知道自己的宿主是谁, 当然也就不能通过访问代码的方式直接调用宿主的方法, 从而在宿主的生命周期里加入自己的逻辑代码

如果直接将每个模块的初始化代码直接复制进宿主的生命周期里, 这样未免过于暴力, 不仅代码耦合不易扩展, 而且代码还极易冲突, 所以修改宿主源码的方式也不可行

所以有没有什么方法可以让每个组件在集成调试阶段都可以独自管理自己的生命周期呢?

其实解决思路很简单, 无非就是在开发时让每个组件可以独立管理自己的生命周期, 在运行时又可以让每个组件的生命周期与宿主的生命周期进行合并 (在不修改或增加宿主代码的情况下完成)

2.4.2 可行方案分析

想在不更改宿主代码的情况下在宿主的生命周期中动态插入每个组件的代码, 这倒有点像 AOP 的意思

现有的解决方案大概有三种:

1. 在基础层中提供一个用于管理组件生命周期的管理类, 每个组件都手动将自己的生命周期实现类注册进这个管理类, 在集成调试时, 宿主在自己的 Application 对应生命周期方法中通过管理类去遍历调用注册的所有生命周期实现类即可

2. 使用 AnnotationProcessor 解析注解在编译期间生成源代码自动注册所有组件的生命周期实现类, 然后宿主再在对应的生命周期方法中去调用
3. 使用 Javassist 在编译时动态修改 class 文件, 直接在宿主的对应生命周期方法中插入每个组件的生命周期逻辑

我最后还是选择了第一种方法, 因为后面两种方法虽然使用简单, 还可以自动化的完成所有操作, 非常炫酷, 但是这两种方法技术实现复杂, 在不同的 Gradle 版本中还会出现兼容性问题影响整个项目的开发进度, 较难维护, 还会增加编译时间

选择第一种方法虽然增加了几步操作, 但是简单明了, 便与理解和维护, 后续人员加入也可以很快上手, 不受 Gradle 版本的影响, 也不会增加编译时间

2.4.3 最终执行方案

第一种方案具体原理也没什么好说的, 比较简单, 大概就是在基础层中定义有生命周期方法 (attachBaseContext(), onCreate() …) 的接口, 每个组件实现这个接口, 然后将实现类注册进基础层的管理器, 宿主通过管理器在对应的生命周期方法中调用所有的接口实现类, 典型的观察者模式, 类似注册点击事件

在 MVPArms 中这种方案的实现类叫作 ConfigModule, 每个组件都可以声明一个或多个 ConfigModule 实现类, 内部实现较为复杂, 实现原理是 反射 + 代理 + 观察者, 这个类也是整个 MVPArms 框架提供给开发者最重要的类

它可以给 MVPArms 框架配置大量的自定义参数, 包括项目中所有生命周期的管理 (Application, Activity, Fragment), 项目中所有网络请求的管理 (Retrofit, Okhttp, Glide),为框架提供了极大的扩展性, 使框架更加灵活

3 项目讲解

项目地址 : ArmsComponent

3.1 如何让组件独立运行?

在项目根目录的 gradle.properties 中, 改变 isBuildModule 的值即可

#isBuildModule 为 true 时可以使每个组件独立运行, false 则可以将所有组件集成到宿主 App 中
isBuildModule=true

3.2 配置 AndroidManifest

由于组件在独立运行时和集成到宿主时可能需要 AndroidManifest 配置不一样的参数, 比如组件在独立运行时需要其中的一个 Activity 配置了 <action android:name="android.intent.action.MAIN"/> 作为入口, 而当组件集成到宿主中时, 则依赖于宿主的入口, 所以不需要配置 <action android:name="android.intent.action.MAIN"/>, 这时我们就需要两个不同的 AndroidManifest 应对不同的情况

在组件的 build.gradle 中加入以下代码, 即可指定不同的 AndroidManifest, 具体请看项目代码

android {
	sourceSets {
        main {
            jniLibs.srcDirs = ['libs']
            if (isBuildModule.toBoolean()) {
                manifest.srcFile 'src/main/debug/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/release/AndroidManifest.xml'
            }
        }
    }
}

3.3 配置 ConfigModule(GlobalConfiguration)

ConfigModule 在 最终执行方案(2.4.3) 中提到过, GlobalConfiguration 是实现类, 他可以给框架配置大量的自定义参数

项目 CommonSDK 中提供有一个 GlobalConfiguration 用于配置每个组件都会用到的公用配置信息, 但是每个组件可能都需要有一些私有配置, 比如初始化一些特有属性, 所以在每个组件中也需要实现 ConfigModule, 具体请看项目代码

需要注意的是, 在 配置 AndroidManifest(3.2) 中提到过组件在独立运行时和集成到宿主时所需要的配置是不一样的, 当组件在独立运行时需要在 AndroidManifest 中声明自己私有的 GlobalConfiguration 和 CommonSDK 公有的 GlobalConfiguration, 但在集成到宿主时, 由于宿主已经声明了 CommonSDK 的公有 GlobalConfiguration, 所以在 AndroidManifest 只需要声明自己私有的 GlobalConfiguration, 这里也说明了 AndroidManifest 在不同的情况需要做出不同的配置

3.4 RouterHub

RouterHub 用来定义路由器的路由地址, 以组件名作为前缀, 对每个组件的路由地址进行分组, 可以统一查看和管理所有分组的路由地址

RouterHub 存在于基础库, 可以被看作是所有组件都需要遵守的通讯协议, 里面不仅可以放路由地址常量, 还可以放跨组件传递数据时命名的各种 Key 值, 再配以适当注释, 任何组件开发人员不需要事先沟通只要依赖了这个协议, 就知道了各自该怎样协同工作, 既提高了效率又降低了出错风险, 约定的东西自然要比口头上说强

Tips: 如果您觉得把每个路由地址都写在基础库的 RouterHub 中, 太麻烦了, 也可以在每个组件内部建立一个私有 RouterHub, 将不需要跨组件的路由地址放入私有 RouterHub 中管理, 只将需要跨组件的路由地址放入基础库的公有 RouterHub 中管理, 如果您不需要集中管理所有路由地址的话, 这也是比较推荐的一种方式

路由地址的命名规则为 组件名 + 页面名, 如订单组件的订单详情页的路由地址可以命名为 “/order/OrderDetailActivity”

ARouter 将路由地址中第一个 ’/’ 后面的字符叫作 Group, 比如上面的示例路由地址中 order 就是 Group, 以 order 开头的地址都被分配该 Group 下

Tips: 切记不同的组件中不能出现名称一样的 Group, 否则会发生该 Group 下的部分路由地址找不到的情况!!!

所以每个组件使用自己的组件名作为 Group 是比较好的选择, 毕竟组件不会重名

3.5 EventBusHub

AndroidEventBus 作为本方案提供的另一种跨组件通信方式 (第一种跨组件通信方式是 公共服务(2.2.3.2)), AndroidEventBus 比 greenrobot 的 EventBus 多了一个 Tag, 在组件化中更容定位和管理事件

EventBusHub 用来定义 AndroidEventBus 的 Tag 字符串, 以组件名作为 Tag 前缀, 对每个组件的事件进行分组

Tag 的命名规则为 组件名 + 页面名 + 动作, 比如需要使用 AndroidEventBus 通知订单组件的订单详情页进行刷新, 可以将这个刷新方法的 Tag 命名为 “order/OrderDetailActivity/refresh”

Tips: 基础库中的 EventBusHub 仅用来存放需要跨组件通信的事件的 Tag, 如果某个事件只想在组件内使用 AndroidEventBus 进行通信, 那就让组件自行管理这个事件的 Tag

3.6 在项目中使用多个不同的域名

在项目中, 有 知乎 、干货集中营、稀土掘金 三个模块, 这三个模块网络接口的域名都不一样, 但是在项目中却可以统一使用框架提供的同一个 Retrofit 进行网络请求, 这是怎么做到的呢? 这是采用本人的另一个库 RetrofitUrlManager, 它可以使 Retrofit 同时支持多个 BaseUrl 以及动态改变 BaseUrl

Android 官方架构组件在今年 5 月份 Google I/O 大会上被公布, 直到 11 月份一直都是测试版, 由于工作比较繁忙, 期间我只是看过类似的文章, 但没有在实际项目中使用过, 更没有看过源码, 所以对这几个组件的使用很是生疏, 同时也觉得这几个组件非常高大上, 非常神秘!

直到 11 月份 Android 官方架构组件正式版发布, 并且 Google 也在 Support Library v26.1.0 以后的版本中内嵌了 Android 官方架构组件中的生命周期组件, 我想, 这是趋势, 既然 Google 这么推崇, 那我也是时候学习一波并将它们引入 MVPArms 框架了

Github : 你的 Star 是我坚持的动力 ✊

简单介绍

因为想将 Android 官方架构组件引入 MVPArms 框架之中, 所以我认真学习了 Android 官方架构组件中除了 Room 之外的所有源码, 以考察是否整个组件都适合引入 MVPArms 框架

在学习完源码过后, 发现 Android 官方架构组件其实并没有想象的那么高深, 原理反而是我们在日常开发中都会用到的知识点, 那我就在文章的开头先简单的介绍下 Android 官方架构组件中的这几个组件

Lifecycles

生命周期组件是 Android 官方架构组件中的核心组件, 它可以使各种实例作为观察者与 Activity 和 Fragment 等具有生命周期特性的组件绑定在一起, LiveData 和 ViewModel 都是基于此组件, 简而言之就是, 你将需要绑定生命周期的实例注册给该组件, 该组件就会在你指定的某个生命周期方法执行时通知这个实例

应用场景很多, 比如之前在 MVP 架构中, 你需要在 Activity 执行 onCreate 时, 让 Presenter 初始化一些操作, 这时就不用在 Activity 的 onCreate 中再调用 Presenter 的某个初始化方法了, 直接使用官方的生命周期组件即可完成, 在 Activity 执行 onDestroy 时需要释放一些对象的资源, 也可以使用到生命周期组件

LiveData

LiveData 具有两个功能, 第一个功能是观察者模式, 在 Value 发生变化时通知之前注册的所有观察者, 第二功能是基于生命周期组件与 Activity 和 Fragment 等具有生命周期特性的组件绑定在一起, 在生命周期发生改变时停止或恢复之前的事件

简而言之就是, 当某个页面请求网络数据成功后需要同步 UI, 但这个页面已经不可见, 这时就会停止同步 UI 的操作

ViewModel

ViewModel 有两个功能, 第一个功能可以使 ViewModel 以及 ViewModel 中的数据在屏幕旋转或配置更改引起的 Activity 重建时存活下来, 重建后数据可继续使用, 第二个功能可以帮助开发者轻易实现 Fragment 与 Fragment 之间, Activity 与 Fragment 之间的通讯以及共享数据

浅析官方架构组件

用法就不多说了, 此类文章和 Demo 太多了, 明白了它们的功能和应用场景后, 我们才知道它们是否真的适合自己的需求, 而不是盲目跟风, 下面我就来分析下我是如何考察新技术, 以及如何判断这些新技术是否有必要应用到自己的项目中

Lifecycles

上面介绍了生命周期组件的功能, 这里就来分析一下生命周期组件是否有必要引入我的框架 MVPArms

说到生命周期我就想到了我之前在 传统MVP用在项目中是真的方便还是累赘? 中讨论的一个内容

现在市面上流行的 MVP 架构有两种, 第一种是将 Activity 或 Fragment 作为 View, 抽象一个 Presenter 层出来, 第二种是将 Activity 或 Fragment 作为 Presenter, 抽象一个 View 层出来

第一种类型代表的框架有 MVPArms, 第二种类型代表的框架有 TheMVP, 当然第一种类型的 MVP 架构在市面上用的是最多的, 那么第二种类型的优点是什么呢?

我在上面这篇文章也说过, 主要优势有两个, 方便重用View, 以及 可直接与 Activity 或 Fragment 的生命周期做绑定, 这样就可以直接使用 Activity 或 Fragment 的生命周期, 不用再去做多余的回调, 当然也有缺点, 我在文章中也有介绍, 有兴趣的可以去看看

第一种类型的 MVP 架构是不具有可以和 Activity 或 Fragment 的生命周期直接做绑定的优势的, 所以很是嫉妒第二种类型的 MVP 架构, 这也是两种类型的 MVP 架构最大的区别, 但你想的没错, 现在使用生命周期组件就可以使第一种类型的 MVP 架构很轻易的具有绑定生命周期的优势, 现在第一种类型的 MVP 架构将如虎添翼

经过以上的分析, 我认为生命周期组件对于我的框架来说是很有必要的, 这将使日常开发更加便捷

LiveData

LiveData 与 RxJava 都是基于观察者模式, 功能上也有重合, Google 在官方文档上也明确表示, 如果你正在使用 RxJava, Agera 等类似功能的库, 只要你能正确的处理数据流的生命周期, 就完全可以继续使用它们来替代 LiveData

Note: If you are already using a library like RxJava or Agera, you can continue using them instead of LiveData. But when you use them or other approaches, make sure you are handling the lifecycle properly such that your data streams pause when the related LifecycleOwner is stopped and the streams are destroyed when the LifecycleOwner is destroyed. You can also add the android.arch.lifecycle:reactivestreams artifact to use LiveData with another reactive streams library (for example, RxJava2).

从官方文档可以看出 Google 对此的建议就是 RxJava, Agera, LiveData 等类似功能的库, 你只使用一个即可

选择 RxJava 还是 LiveData ?

LiveData 和 RxJava 的功能的确过于重合, 我也十分赞同 Google 官方的建议, 两者之中选择其一就可以了, 没必要两者都引入项目, 而 MVPArms 框架, 也正好引入了 RxJava, 所以我也来分析分析在 MVPArms 框架中该选择 LiveData 还是 RxJava?

于是我认真的研究了其源码, LiveData 具有两个功能, 通知观察者更新数据和根据生命周期停止和恢复之前的事件, 而 Rxjava 加上 RxLifecycle, RxJava 加上 AutoDispose, 或 Rxjava 加上生命周期组件, 也可以轻易做到根据生命周期停止和恢复之前的事件, 在配上 Rxjava 强大的操作符, LiveData 能做的事 RxJava 都能做, LiveData 不能做的事 RxJava 也能做

并且 RxJava 不仅仅只是 RxJava, 他还是一个庞大的生态链, 他还有 RxCache, RxLifecycle, RxAndroid, RxPermission, Retrofit-Adapter 等大量并且强大的衍生库, 我们离开它做很多事都非常不便, 刚刚出生, 羽翼未丰的 LiveData 相比于 RxJava 将没有任何优势, 甚至显得非常简陋

因此 LiveData 和 RxJava 之间如果只能选择一个的话, 我没有任何理由选择 LiveData

ViewModel

ViewModel 中有一个功能让我十分惊艳, 也十分好奇, 它可以使 ViewModel 以及 ViewModel 中的数据在屏幕旋转或配置更改引起的 Activity 重建时存活下来, 重建后数据可继续使用, 这个功能十分实用且十分重要, 因为之前也没有一个官方解决方案, 所以我觉得很有必要将这个功能引入 MVPArms 框架

同样另外一个功能, 它还可以帮助开发者轻易实现 Fragment 与 Fragment 之间, Activity 与 Fragment 之间的通讯以及共享数据, 同样也正是我所需要的官方解决方案

但在我继续深入研究, 准备将它引入到项目中时, 却发现 Google 将这个功能做了高度封装并限制了它的使用范围, 只能用于 ViewModel

但我想 Google 既然能让 MVVM 框架中的 ViewModel 具有这些功能, 那我为什么不能将这个功能扩展出来提供给 MVP 框架中的 Presenter, 乃至其他更多的模块?

于是我认真的研究了其源码, 准备通过修改源码并封装成库的方式, 让更多的开发者在更多的场景下能够使用到这些功能

改造 ViewModel 组件

要想改造 ViewModel 组件 自然要对它的整个源码分析一遍, 知道其原理, 才知道如何下手

分析源码

篇幅有限, 就来简单的分析下源码把, 源码其实也就几个类, 经过了层层封装, 核心代码就在一个叫做 HolderFragment 的 Fragment 中,

在我看来 ViewModel 组件 的核心原理也就是 HolderFragment 中的一行代码实现的:

setRetainInstance(true);

setRetainInstance(boolean) 是 Fragment 中的一个方法, 我想很多人应该都知道这个方法的意义

简单来说将这个方法设置为 true 就可以使当前 Fragment 在 Activity 重建时存活下来, 如果不设置或者设置为 false, 当前 Fragment 会在 Activity 重建时同样发生重建, 以至于被新建的对象所替代

意思是只要将这个方法设置为 true, Fragment 以及 Fragment 之中的所有数据都会在 Activity 重建时存活下来

这时我们在 setRetainInstance(boolean) 为 true 的 Fragment 中放一个专门用于存储 ViewModel 的 Map, 自然 Map 中所有的 ViewModel 都会幸免于 Activity 重建

于是我们让 Activity, Fragment 都绑定一个这样的 Fragment, 将 ViewModel 存放到这个 Fragment 的 Map 中, ViewModel 组件 就这样实现了

如何改造

想要知道如何改造, 那我们就要明确这次改造的最终目的是什么, 我们的目的就是要让 ViewModel 组件 能用于 Presenter, 乃至其他更多的模块, 不止是用于 ViewModel

那为什么 Google 官方的 ViewModel 组件 不能用于其他模块呢, 通过阅读源码可以知道, 是因为 Google 把上文提到的 Map, 封装了起来, 并没有提供出去, 并且限制了 ViewModel 的构建方式

ViewModel 组件 让一个新的 ViewModel 必须继承于它的基类, 并且让开发者必须提供一个 Factory 指明当前 ViewModel 的构建方式, ViewModel 组件 会在合适的时机, 主动去根据 Factory 构建 ViewModel 实例, 并放入 Map 中

这时整个构建过程都被 ViewModel 组件 掌控并被限制于 ViewModel, 所以我需要做的就是将 Map 和 ViewModel 的构建方式扩展出来, 将更多的控制权交给外部的开发者

实践

经过上面的分析, 思路和方案都有了, 接下来就剩下如何把思路和方案实现了

于是我结合上文分析的思路和方案对官方源码进行了改造并做了适当的优化, LifecycleModel 就这样诞生了

这篇文章主要还是讲在完成一个目标前, 在从 0 到 1 期间进行的思路和分析的过程, 至于细节你如果感兴趣的话还是去看我的源码把, 哈哈, 注释很详细哦!

Github : 你的 Star 是我坚持的动力 ✊

总结

一个新技术是否真的适合自己还是需要自己去考察, 不应该盲目跟风, 如果你只知道这个技术很火然后去用它, 不知道为什么用它, 用它的好处, 那你就会一直陷入被动学习的窘境, 一直在学习, 但是总觉得自己跟不上时代的进步, 担惊受怕, 这是现代技术人大部分都存在的处境

至于最近闹的沸沸扬扬的简书 饱醉豚 事件, 自从简书 CEO 站台后, 已经不再是当事人一个人的事, 而是关乎到简书整个平台, 既然这个 CEO 这么傲气, 这个平台都不在乎我们这个群体, 我们也不再去关注这个平台就是了, 流量是跟着原创作者走还是跟着平台, 自己心里没点逼数吗?

简书以及简书 CEO 最好做出深刻的道歉, 否则我也会离开简书 (好像我更文频率也不是很高把? 咳咳… 我主打的是质量! 质量! 不是数量, 逃～)

踩坑

在实际项目中使用 ViewModel 组件 时我也遇到了一些问题, 浪费了我很多时间, 所以有必要分享出来让大家少走弯路

通过 Activity 获取 ViewModel 时遇到的坑:

• 在 Application.ActivityLifecycleCallbacks 中的 onActivityCreated 方法中获取 ViewModel 时, Activity 每重建一次, 获取的 ViewModel 都是重新构建后的新实例, 并不能让 ViewModel 以及 ViewModel 中的数据幸免于 Activity 重建, 所以不要此方法中获取 ViewModel

• 在 Activity 的 onDestroy 方法中不能获取 ViewModel, 会报错

通过 Fragment 获取 ViewModel 时遇到的坑:

• 在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentAttached 方法中获取 ViewModel 时也会出现和 Activity 一样的情况, 获取的 ViewModel 是重新构建后的新实例, ViewModel 以及 ViewModel 中的数据不能幸免于 Activity 重建, 所以也不要此方法中获取 ViewModel

• 在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentDestroyed 方法中也不能获取 ViewModel, 会报错

• 在 Fragment 的 onDestroy 方法中不能获取 ViewModel, 会报错

Hello 我叫Jessyan,如果您喜欢我的文章,可以在以下平台关注我

• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end

Hello,我是 JessYan,作为一个喜欢探索新颖解决方案的我,在 上篇文章 中,向大家介绍了怎样通过一行代码即可实现上传下载以及 Glide 进度监听,现在又给大家带来了另一项大家都很期待的问题的解决方案,这个问题起源于 MVPArms 的一个 Issues ,当然使用 Retrofit 时,多个 BaseUrl 以及动态切换 BaseUrl 这两个需求,在其他地方也经常被讨论,那么下面就来讲讲我的思路和解决方案

Github : 你的 Star 是我坚持的动力 ✊

需求出现的场景

也许在日常开发中有些人已经遇到了这两个需求的场景,但为了让一些之前没遇到这些场景的朋友,也能看懂这篇文章,所以先在前面提一提

多个 BaseUrl 的需求场景

如果项目是聚合型 App ,比如像一些新闻资讯类客户端,可能数据源来自于多个平台,比如说知乎啊,豆瓣啊,今日头条啊,所以这样就会涉及到多个 BaseUrl

如果项目使用到多个三方服务提供商,比如图片的读取使用到一个服务商,文件的存储又使用到另一个服务商,这个也会存在一个 App 出现多个 BaseUrl

动态改变 BaseUrl 的需求场景

如果项目的 BaseUrl 会在 App 启动时,请求服务器,根据服务器的返回结果,来确定项目最终的 BaseUrl,就会涉及到运行时动态切换 BaseUrl

如果项目的某个三方服务提供商,并不是固定的,也许会出现变更的情况,比如存储服务从七牛迁移至其他云存储,那我们为了避免更改代码导致重新打包以及发版,就会从服务器获取三方服务提供商的 BaseUrl ,然后在运行时动态改变这个 BaseUrl

解决方案

其实官方 Api 早已经提供了解决方案来支持多个 BaseUrl 以及运行时动态改变 BaseUrl ,民间也同样有很多解决方案

官方静态解决方案

熟悉 Retrofit 的开发者应该知道 @Get , @Post 这些标注到每个接口方法上的注解不仅可以传相对路径,还可以传全路径,这样我们就可以做到不同的接口使用不同的 BaseUrl ,从而达到使用多个 BaseUrl 的需求,但是注解上的值只能是 Final 的常量,不能动态改变,所以我称这个解决方案为静态解决方案

官方动态解决方案

熟悉 Retrofit 的开发者也同样知道 @Url 这个标注到每个接口方法参数上的注解,它可以将全路径作为参数传进接口作为每次请求的 Url 地址,每次请求接口都可以将不同的全路径作为参数,从而达到支持多个 BaseUrl 以及在运行时动态改变 BaseUrl ,所以很多请求图片等资源的接口都是使用这个方案(咦,看样子这个官方解决方案不是同时解决我提到的这两个问题吗,别急,先往后面看!)

民间常用解决方案

之前也看过很多开源的聚合类 App 源码,像一些整合 知乎 , 豆瓣 , Gank 等多个平台数据的 App ,因为各自平台的域名不同,所以大多数这类 App 会给每个平台都各自创建一个 Retrofit 对象,即不同的 BaseUrl 使用不同的 Retrofit 对象来创建 ApiService 进行请求,这样只要新增一个不同的 BaseUrl ,那就需要重新创建一个新的 Retrofit 对象

这样也可以同时实现,支持多个 BaseUrl 以及运行时动态改变 BaseUrl 这两个需求,但是以个人的观点,创建多个其他配置属性一模一样,只是 BaseUrl 不一样的 Retrofit 对象,太过于浪费资源

民间大牛解决方案

之前偶然看到了一个 Retrofit 维护者, Square 公司的大牛的 解决方案,用来解决运行时动态改变 BaseUrl ,其实也算半官方的解决方案

提到这个解决方案时,不得不讲一个趣事,其实之前 Retrofit 默认是支持运行时动态改变 BaseUrl 的,以前是有一个名为 BaseUrl 的接口,而 Retrofit.Builder#baseUrl(BaseUrl) 方法当时传的参数就是这个 BaseUrl ,而不是现在的 HttpUrl ,这个接口内部就有一个方法返回 HttpUrl ,那时候只要实现 BaseUrl 后,动态改变这个方法的返回值,就可以实现动态改变 BaseUrl

但是这位大牛认为这样的做法不安全,所以提了一个 Pull Requests ,删掉了这个 BaseUrl 接口,并用上面的解决方案替代之,而亲爱的 JakeWharton 同意了他的观点,并合并了这个 PR 于是才有了现在的 Retrofit.Builder#baseUrl(HttpUrl) 这个不能动态改变 BaseUrl 的 Api

用 Retrofit 比较早的老鸟,应该知道以前有一个这个 Api,我是说后来的版本怎么没了,原来毁在了这位兄台手上

这个方案也就是利用 Interceptor 拦截器,动态改变每个 Request 的 Url 从而实现动态改变 BaseUrl,但他这个解决方案不能支持多 BaseUrl ,只要 host 一设置,直到下一次改变 Host 之前,后面的所有 Request 都必须使用同一个 Host ,还有一些弊端后面一起分析

几个方案的对比与分析

淘汰含有明显缺陷的方案

4个方案中,我首先淘汰的就是 民间常用解决方案 ,在前面已经明确了我的观点,因为我个人认为创建多个其他配置属性一模一样,只是 BaseUrl 不一样的 Retrofit 对象,太过于浪费资源,所以就算他能满足我的所有需求,除非真的没有更好的解决方案,否则我是不会选择它的

剩下的三个方案中, 官方静态解决方案 只能解决,2个需求中的支持多个 BaseUrl ,而对于动态改变 BaseUrl ,由于注解的 Value 只能为常量,所以对这个需求也是无能为力的(两个需求都满足,才表示可行)

谁是最优方案?

其实在前面已经说了 官方动态解决方案 就已经可以同时实现多 BaseUrl 和运行时动态改变 BaseUrl ,那为什么我不直接选择这个方案,还要继续分析呢?

答案也很简单,我认为这个方案,虽然灵活,但是灵活却给它带来了使用上的繁琐,每个接口每次调用都必须传入全路径作为参数,不仅繁琐而且接口一多还不好管理

那 民间大牛解决方案 可行? 但是我在前面已经说了这个不可行啊?

这个方案虽然可以支持运行时动态切换 BaseUrl 但是它是全局处理,一经使用改变的是所有请求的 Url ,所以它并不支持多 BaseUrl

并且更可怕的是,这个方案不仅不支持多 BaseUrl ,还会影响 官方静态解决方案 和 官方动态解决方案 这两个支持多 BaseUrl 的方案,因为不管你注解里面声明的是什么全路径,它的 Interceptor 拦截器,都会强行将这个请求的 Url 改成它的 BaseUrl ,所以这个方案注定只适合只有一个 BaseUrl 但需要动态改变的项目

那岂不是 4 个解决方案都不可行?说这么久说个毛线啊?

方案全部淘汰?散会？

等等别急啊,虽然我站在我的角度, Pass 了文中提到的所有已存在的解决方案

但是大家仔细想想,如果网上已经存在完美的解决方案,那我还写这篇文章有什么意义?必定是没有我满意的解决方案,我才会自己动手去解决并分享啊,毕竟我是一个不愿意写重复内容的有为青年,只要是我写的内容肯定是会让大家学到不一样的知识三 ✊,不然不是砸自己招牌

好了,不逗大家了,开整!

别急,还有大招!

虽然在已有的解决方案当中没有找到让我满意的,但是在遇到问题时,冷静分析现有解决方案是很有必要的,理解前人的思路后才会对整个问题理解得更透彻,我的很多文章也都是以分析和解决思路为主,授人以鱼不如授人以渔,所以我不会直接告诉你答案,先分析一波,理清思路

这不,在分析 民间大牛解决方案 时,虽然最后发现这不是自己想要的解决方案,但是作为有发散思维的我,又是灵机一动,借助原有解决方案在上面这样一改不是就可行了?

如何改善原有方案？

上面的分析已经说了 民间大牛解决方案 ,可以在 Interceptor 拦截器中设置一个全局的 Host(Host 可以理解为 BaseUrl) ,拦截器会强行将这个 Host 应用到所有的请求上,改变该请求原有的 Url,这样导致了只会同时存在一个 Host

所以我在想,将这个唯一的 Host 变量改为集合,以存储多个 Host ,在将不同的 Host 应用到不同的请求上,不就可以支持多 BaseUrl？

实践想法

说干就干,于是我自己建了一个全局的容器来存储多个 Host,这样我就可以在 App 运行时的任何时间,任何地点随意新增,修改,删除 Host

遇到问题

但是问题来了,我想要将不同的 Host 应用到不同的请求上,但我怎么知道什么请求需要什么样的 Host ,每个请求总要有个标记,让我知道他需要什么样的 Host 吧

于是我就在想 Retrofit 有什么方法,可以在请求之前给每个请求加上不同的字符串标记,于是我很自然的想到了 Header ,Retrofit 正好有 @Headers 这个注解,可以给每个接口方法上加入自定义 Header

再次解决难点

我给需要不同 BaseUrl 的接口方法上加入了自定义的 Header ,以标明每个接口需要的 Host 的 Name ,而这个 Name 对应的值就是 Host,但这个值不是在 @Headers 中被指定的,它是可以动态改变的

存储 Host 的容器是一个 Map, key 就是这个 Name ,value 才是 Host ,拦截器每次拦截到请求时,会判断这个请求是否有这个自定义 Header, 有的话,拿到这个 Header 中标注的 Name,然后用这个 Name ,去那个存储 Host 的全局 Map 中 get(name),拿到对应的 Host 再应用到请求上不是就达到支持多个 BaseUrl 了?

如果想动态改变某个 Host 也简单,将新的 Host 以同样的 Name put(name) 进这个全局 Map ,到时候拦截器,使用这个 Name get(name) 出来的值,就已经是改变后最新的 Host ,在将这个 Host 应用到请求上不是就达到动态改变 BaseUrl 了？

这不,两个需求同时满足!

优化方案

这个方案就两步,给需要不同 BaseUrl 的请求设置 Header (想用 Retrofit 默认 BaseUrl 的接口,或者使用 官方静态解决方案, 官方动态解决方案 就不需要设置),在通过全局容器来管理 BaseUrl

针对于那种只有一个 BaseUrl 但需要动态改变的项目,本框架提供了一个 GlobalDomain 来优化这个场景,不需要给接口加 Header ,只需要一步,向全局容器 put(GlobalDomain) 你想要改变的 BaseUrl 就可以了

比 官方动态解决方案 给每个接口传全路径作为参数,要简单的多, 官方动态解决方案 注定只适合那种只有一两个需要动态改变 BaseUrl 的接口

总结

以上提到的解决方案,已经优化并封装成了三方库并上传至 Jcenter,方便大家使用

本解决方案主要适合,需要同时具备多 BaseUrl 以及动态改变 BaseUrl 的项目,或者只有一个 BaseUrl ,但需要动态改变 BaseUrl 的项目

如果对于只需要多 BaseUrl 不需要动态改变 BaseUrl 的项目,其实用 官方静态解决方案 就已经足够了,但我还是推荐用我的这个解决方案,因为需求都是会变的,如果一旦要加入动态改变 BaseUrl 的需求,如需要动态切换 生产环境 和 开发环境 ,那这时怎么办,一个个改掉每个接口注解里面的全路径?

Github : 具体使用看 Demo ,记得 Star !

Hello 我叫Jessyan,如果您喜欢我的文章,可以在以下平台关注我

• GitHub: https://github.com/JessYanCoding
• 掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613
• 简书: https://www.jianshu.com/u/1d0c0bc634db
• 微博: https://weibo.com/u/1786262517

– The end