转载自 https://github.com/getActivity/AndroidProject/blob/master/HelpDoc.md
以下内容基于项目 https://github.com/getActivity/AndroidProject
目录
为什么没有用 MVP
- AndroidProject 舍弃 MVP 的最大一个原因，需要写各种类，各种回调，如果这个页面比较简单的话，使用 MVP 会让原本简单的代码变复杂，导致后续开发和维护成本是非常高，前期付出的代价和后期的维护不成正比关系，当然这种说法只适用于各种中小型项目，大型的项目我还没有经历过，不过我觉得，无论是 MVC、MVP、MVVM，它们出现的目的是为了解决代码多并且乱的问题，作用就是给代码做分类，但是可以跟大家分享我的心得，我并不看好 MVP，因为它让我开发和维护都很痛苦，所以我就直接将它从 AndroidProject 移除，目的也很简单，不推荐大家使用，因为 MVP 不适合大多数项目的开发和维护。我更推荐大家直接将代码写在 Activity，但是有一个前提条件需要大家遵守，大家要做好代码封装和重复代码的抽取，尽量让 Activity 成为只有业务代码的类，这样一个项目里面的大多数 Activity 代码量都能很好控制在 1000 行代码以内。但是这种看似简单的操作，但是实际要做到是一件不容易的事情，这里面不仅要解决代码带来的问题，还要解决带来的各种人性矛盾，困难重重，这种想法经过很长一段时间的思考，虽然写法在开发和维护中效率是非常高的，但是不被大多数人认可，大家更愿意相信 MVC、MVP、MVVM，而很少有人理解这三种模式的本质是什么，就是为了给代码做分类，但这三种模式都不够灵活，很生硬，像是一套套规则，而这样的代码分类，只会让大多数人的开发越来越头疼。
为什么没有用 ButterKnife
- 随着 AndroidProject 的不断优化，ButterKnife 功能很强大，但是实际开发中，大多数人只用到了 BindView 和 OnClick 注解，在 OnClick 注解在我的项目中发现一个 Bug，就是有时候不会响应点击事件，这个问题并不是必现的。还有 BindView 注解只是在视觉上面将 View 和 ID 的关系更明显了，它其实不能为我们简化代码，因为使用 BindView 和 findViewById 的代码量是一样的。
- ButterKnife 最大的缺点是还会自动生成 ViewBinding 类，就算在类中只使用了一个 BindView，它也会生成这个类，其实这样是不太好的。
- 另外一个点，将 Android Studio 升级到 4.1 之后，会出现以下提示，这个是因为 Gradle 在 5.0 之后的版本，View ID 将不会以常量的形式存在，所以不能将其定义在
BindView 注解或者在 switch case 块中。
Resource IDs will be non-final in Android Gradle Plugin version 5.0, avoid using them as annotation
Resource IDs will be non-final in Android Gradle Plugin version 5.0, avoid using them in switch case statements
- 考虑到这些情况，我在新版的 AndroidProject 上面移除了 ButterKnife 框架，其实 findViewById 一直挺好，只是我们没有认真思考过而已。
- 另外大家如果不想写 findViewById，我可以推荐一款自动生成 findViewById 的插件给大家：FindViewByMe
为什么没有用 ViewBinding
- 首先 ViewBinding 和 ButterKnife 有一个相同的毛病，就是自动生成一个类，然后在这个类里面进行 findViewById，但是有一个致命的缺点，每个
Activity / Fragment / Dialog / Adapter 都需要先初始化 ViewBinding 对象，因为每次生成的类名都是不固定的，所以无法在基类中封装处理，并且每次都要写 binding.xxx 才能操作控件。
ActivityXxxxBinding.inflate binding = ActivityXxxxBinding.inflate(getLayoutInflater());
binding.tv_data_name.setText("字符串");
- 另外一个它会根据控件 id 作为属性的名称，这样会导致一个代码不规范的问题，如果在 xml 中控件的 id 命名符合规范了，会导致在 Java 代码中的命名不规范，如果在 Java 代码中的命名规范了，又会导致 xml 的 id 不符合规范了。而代码规范关系到后续的代码维护，是一个很重要的问题，不容忽视。
- 虽然 ViewBinding 是谷歌官方推荐的，但是我觉得并不完美，解决了 findViewById 的同时又带来了其他的问题，在关键问题上有问题和矛盾，直白点说这些问题都是硬伤。
- 正如我上面所说的，findViewById 一直挺好，只是我们没有认真思考过而已。
- 另外大家如果不想写 findViewById，我可以推荐一款自动生成 findViewById 的插件给大家：FindViewByMe
为什么没有用 DataBinding
- DataBinding 最大的优势在于，因为它可以在 xml 直接给 View 赋值，但它的优点正是它最致命的缺点，当业务逻辑简单时，会显得格外美好，但是一旦判断条件复杂起来，由于 xml 属性不能换行的特性，会导致无法在 xml 直接赋值又或者很长的一段代码堆在布局中，间接导致 CodeReview 时异常艰难，更别说在原有的基础上继续更新迭代，这对每一个开发者来讲无疑是一个巨大的灾难。
- 还有一个是 DataBinding 的学习成本比较高，其次成本也挺高，使用前需要做很多封装，另外每次使用时都需要添加
layout 和 data 节点，然后在 Java 代码中初始化 DataBinding 对象，无法在基类中封装处理，每次都要写 binding.xxx 才能操作控件，和 ViewBinding 的问题差不多。
ActivityXxxxBinding binding = DataBindingUtil.setContentView(this, R.layout.activity_xxxx);
为什么没有用组件化
- 先来说说组件化的优点，能够把不同的业务代码进行隔离，达到完全解耦的效果，同时也能提升编译和打包速度。但是这两个优点只有项目业务变得大并且复杂的情况下才能产生价值，否则价值并不大，在我看来，代码解耦其实是把双刃剑，解耦的过程相对比较麻烦，这会直接加大前期开发的工作量，并且一些解耦的方式可能会导致代码重复，例如 AndroidManifest 清单文件，需要同时配置两份文件，后期改动也需要改两遍，另外一个是路由跳转，现在大多数路由框架都是通过 APT 生成一张映射表，这个需要我们每写一个 Activity 都要写一个路径的注解，这个不仅写起来麻烦，管理起来也会很麻烦，另外对每个业务模块的 SDK 初始化操作和数据存储交互上又该如何处理和解耦？这些都是组件化所存在的问题，矛和盾又该如何抉择？
- 组件化其实是一个很好的思想，但是它并不适用于中小型项目，因为这些项目并没有那么复杂，大部分业务模块都很小，大的业务模块其实也不多，当然我个人建议可以将大点的模业务进行模块化，但是没有必要做组件化，因为一旦涉及，从组件化中得到弊会大于利。而在一些大型的项目中，大大小小的模块非常多，一次打包编译可能要半个小时甚至更久（请注意大厂的电脑基本都是高配或者顶配），相比较这种情况之下，组件化的优点就已经大于了它的缺点，同时他们也有充足的人力和过硬的技术，并且能长期投入巨大的时间和精力来做这件事。
- AndroidProject 面对的是大众开发者，所以更倾向中小型的项目代码的设计，虽然我没有做过大型的项目，但是在我看来是差不多的，最大的不同可能是代码分类方式的不同，该做的事情不会少，该写的代码也不会少，就是业务和代码的体量上比我们大，所以他们要处理体量大所带来的的问题。
为什么没有集成界面侧滑功能
- AndroidProject 其实有加入过这个功能，但是在 v9.0 版本 就移除了，原因是第三方侧滑框架 BGASwipeBackLayout 在 Android 9.0 上面会闪屏，并且还是 100% 必现，用户体验极差，我也跟作者反馈过这个问题，但结果不了了之，所以不得不移除。但是到了 v10.0 版本，我又加上界面侧滑功能了，不过这次我换成了 SmartSwipe 来做，但是我又再一次失望了，这个框架在 Android 11 上面，如果 Activity 上有 WindowManager 正在显示，然后使用界面侧滑，那么会出现闪屏的情况，具体效果如下图：
- 就这个情况我也联系过作者，并详细阐述了产生的原因和具体的复现步骤，但是我等了三天连个回复都没有，实属有些让我心寒，在等待的期间我看到 Github 的 issue 已经基本没有回复了，并且最后一次提交是在 13 个月前了，种种迹象都已经表明，所以经过慎重考虑，最终决定在 v12.1 版本 移除界面侧滑功能。
为什么没有用今日头条的适配方案
- 关于屏幕适配方案，其实不能说头条的方案就是最好的，其实谷歌已经针对屏幕适配做了处理，就是 dp 和 sp ，而 dp 的计算转换是由屏幕的像素决定，系统只认 px 单位， dp 需要进行转换，比如 1dp 等于几个 px ，这个时候就需要基数进行转换，比如 1dp = 2px，这个基数就是 2。
ldpi：1dp=0.75px
mdpi：1dp=1px
hdpi：1dp=1.5px
xhdpi：1dp=2px
xxhdpi：1dp=3px
xxxhdpi：1dp=4px
- 这个是谷歌对屏幕适配的一种默认方式，厂商也可以根据需要去修改默认的基数，从而达到最优的显示效果。
- 谷歌的屏幕适配方案也不是百分之一百完美的，其实会存在一些需求不能满足的问题。谷歌的设计理念是屏幕越大显示的东西越多，这种想法并没有错，但有些 App 可能对这块会有要求，希望根据屏幕大小对控件进行百分比压缩。这个时候谷歌那套适配方案的设计已经和需求完全不一致了。
- 那什么样的 App 才会有那样的需求呢？现在手机的屏幕大多在 5 - 6寸，而平板大多在 8 - 10 寸，也就是说我们只适配手机的话，只需要针对 5 - 6 寸的，并且它们的分辨率都差不多，其实用谷歌那种方案是最优的，如果我们需要适配平板的话，一般都会要求对控件进行百分比压缩，这个时候谷歌那套方案会把原先在手机显示的控件在平板上面变大一点，这样就会导致屏幕剩余的空间过大，导致控件显示出来的效果比较小，而如果采用百分比对控件压缩的方式，能比较好地控制 App 在不同屏幕下显示的效果。
- 另外谈谈我的经历，我自己之前的公司主要是做平板上面的应用，所以也用过 AutoSize 框架，一年多的使用体验下来，发现这个框架 Bug 还算是比较多的，例如框架会偶尔出现机型适配失效，重写了 getResources 方法情况之后出现的情况少了一些，但是仍然还有一些奇奇怪怪的问题，这里就不一一举例了，最后总结下来就是框架还不够成熟，但是框架的思想还是很不错的。我后面换了一家公司，也是做平板应用，项目用的是用通配符的适配方案，跟 AutoSize 相对比，没有了那些奇奇怪怪的问题，但是代码的侵入性比较高。这两种方案各有优缺点，大家看着选择。
- 在这块我也发起过群投票，相比谷歌的适配方案，大多数人更认同那种百分比适配方案，秉承着少数服从多数的理念，我在 AndroidProject v13.0 版本 加入了通配符的适配方案。虽然有一部分人不认同，但是我想跟这些人说的是：我的每一个决定都是十分谨慎的，因为这其中涉及到许多人的利益，AndroidProject 虽然是我创造的，但是它早就不是我一个人的了，而是大家的，每个重要的决定我都会考虑再三才会去做，在做决定的时候我会把大众的利益放在第一位，把自己的利益放在最后一位，所以大家唯一能做的是，相信我的选择。或许你可能觉得这样不太对，也随时欢迎你提出不同的意见给到我，我不认为自己做的决定一定都是对的，但是我会一直朝着对的方向前进。
字体大小为什么不用 dp 而用 sp
- 首先我们先回顾一下谷歌原生的写法，将控件大小的单位定成了 dp，而字体大小的单位定成了 sp，而无论是 dp 还是 sp 作为单位，最终还是会转成 px 的单位。
- 谷歌这样做也有一定目的，dp 是根据屏幕的密度来计算的，而 sp 是根据手机设置的字体大小来计算的，如果用 dp 来代替 sp 会有一个问题，那么就是无论用户在手机里面怎么设置字体大小，应用的字体大小不会产生任何变化。这种场景对年轻人来讲没有太大的影响，而对一些老龄用户，例如我们的爸妈，他们一般会把手机的字体调大，这样才能看清楚里面的字，如果我们采用 dp 来代替 sp 的方案，会对这类用户造成不便，换位思考，我们终有一天也会变老，变得老眼昏花，我们会如何看待这个事情？
- 显然这种方式是不合理的，也非常地不人性化。网上这种方案可能主要就是为了解决把控件宽高写死之后，在某些字体上显示比较大的机型会出现字显示不全的问题，而这种把控件宽高写死的方式本身也是不合理的，应该在不得已的情况下才把控件的宽高写死，一般情况下我们应当使用自适应的方式，让控件自己测量自己的宽高，特别是在有显示字体的控件下，就更不应该把宽高写死。
为什么没有用 DialogFragment 来防止内存泄漏
为什么没有用腾讯 X5 WebView
为什么没有用单 Activity 多 Fragment
为什么没有用 ConstraintLayout 来写布局
为什么不拆成多个框架来做这件事
为什么最低兼容到 Android 5
- AndroidProject 从 v11.0 版本，已经将 minSdkVersion 从 19 升级到 21，原因也很简单，我不推荐大家兼容 Android 4.4 版本，因为这个版本兼容性的问题太多，对 dex 分包、矢量图的支持不是特别好，这个我们开发者处理不了，除此之外还有很多 API 要做高低版本兼容，这个我们开发者能做，但是我觉得没什么必要性，因为这个版本的机型会越来越少，会逐步退出历史舞台，而 AndroidProject 一旦投入到项目中使用，minSdkVersion 基本不会有变动，所以我的想法是，不如在一开始就不兼容这个版本，免得后面给大家带来一些不必要的麻烦，Android 4.4 有些问题是真硬伤，这是一个非常令人头疼的问题。
为什么不加入扫描二维码功能
- AndroidProject 的定位是做一个技术架构，不是什么都做的 Demo 工程，如果只是解决大家的需求问题，那样在我看来意义其实并不大，当然实现需求固然很重要，但并不是所有的技术点在不同项目都会用到，AndroidProject 只是在做架构的同时顺道把模板做了，如果说架构是理论，那么模板就是实践，代码写得再好，如果不实践，那么也只是纸上谈兵，又或者中看不中用。
- AndroidProject 并不会为个人做定制，包括我自己，我可以给大家举个栗子，AndroidProject 集成了我很多自己的框架，但并不是所有我写的框架都会加入到里面去，例如多语种框架，主要原因是 App 国际化的场景并不多，大部分国内的 App 没有上架 GooglePlay，少数服从多数的原则，所以我没有加入这个框架到 AndroidProject 中，并不是框架做得不好，虽然加入会对这个框架有利，会有推广作用，但是不符合大部分人的利益，于是在大我和小我之间，我还是选择大我。这无疑是一个艰难的抉择，但是我必须得这么做。
为什么不加入 EventBus
- EventBus 我之前其实有加入过一版，只不过在 v10.0 版本上面移除了，原因很简单，它不是一个项目的必需品，我们用 EventBus 的初衷应该是，当需求在现有的基础上实现起来比较困难或者麻烦时，我们可以考虑用一用，但是到了实际项目中，会出现很多滥用的情况出现，在这里我建议大家，能用正常方式实现通讯的，尽量不要用 EventBus 实现。另外大家如果真的有需要，可以自行加入，集成也相对比较简单。
为什么没有用 Retrofit 和 RxJava
为什么没有用 Jetpack 全家桶
- AndroidProject 里面其实有运用到和 Jetpack 相关的技术，例如 Lifecycle 特性，在 BaseDialog 加入了此特性，不仅如此，里面引入的 EasyHttp 网络请求框架也采用了 Lifecycle 特性来管控网络请求，Lifecycle 是一个好东西，把组件的生命周期抽象化了，这样我们无需要关心这个组件是 Activity 或 Fragment，又或者是其他类型的组件。
- 但是除了 Lifecycle 组件之外，LiveData 和 ViewModel 组件在 AndroidProject 基本没有用到，这个是因为 AndroidProject 有自己的代码设计思想，只会集成一些合适的代码库，不会一味地去追求什么全家桶，框架选型是要综合考虑很多方面的因素，并没有大家想得那么简单。
为什么不对图片加载框架进行再次封装
- 常用的图片加载框架无非就两种，最常用的是 Glide，其次是 Fresco。我曾做过一个技术调研：
- 无疑 Glide 已成大家最喜爱的图片加载框架，当然也有人使用 Fresco，但是占比极少。
- 那既然萝卜白菜各有所爱，那么为什么不对图片加载框架抽取成接口呢？这样不就把所有的问题都解决了？
- 其实 AndroidProject 10.0 之前的版本有做过这块的内容，但是移除的原因是，抽取接口其实不难，难的是后续的扩展，例如 Glide 给我们开放了很多 API，我们最常用的是加载网络图片、加载圆角图片、加载圆形图片，但是如果是其他形状的图片呢？那就要涉及到 Glide 图形变换的 API 了，还有一个就是加载监听的事件，也需要涉及到 Glide 的 API，缓存策略，不止如此，还有很多 API 都涉及到 Glide 的 API，如果直接用 Glide 来做，我们可以轻松实现，但是如果经过一层的代码封装，那么会把框架本身的灵活性给扼杀掉。但并不是不可以实现，而是没有这个必要，就算做了付出和收益也会远远不成正比，同时也会给大家带来一定的学习成本。
模板 架构 技术中台有什么区别
- AndroidProject 正式从 安卓架构 更名为 安卓技术中台，因为它符合技术中台的特性，既能够做到快速开发，同时又能保证后续维护也能快速迭代。大家可以也将技术中台理解为：模板+架构，一般写模板代码的人做不了架构设计，而做架构设计的人又不想写模板代码，那么技术中台的概念便出现了，并且结合了这两种的优点，开发和维护都兼顾到位。
为什么不按业务来划分包名
- 有一些业务职责不明确，无法限定属于哪一个业务模块，并且大多数模块的类都是比较少，只有少部分的模块拥有一定数量的类，所以在一般的中小项目开发中，我更推荐以类的作用来划分包名。
为什么没有关于列表多 type 的封装
- 原生的 RecyclerView.Adapter 本身就支持多 type，只需要重写适配器的 getItemType 方法即可，具体用法不做过多介绍。
这不就是一个模板工程换成我也能写一个
- 想把 AndroidProject 做出来并不难，我当时只花了一两个星期，而做好它需要无限的时间和精力，我花了两年多的时间仍然还在半路之上，尽管有很多人认为它很好用，没有任何 Bug，但是在我看来还不够，因为每个人衡量标准的程度不同，我的标准是随着时间的推移和技术的提升而不断提高。具体付出了多少努力，可以先让我们看一组数据：
- 与其说 AndroidProject 做的是模板工程，但实际我在架构设计上花费的时间和精力会更多，其实这两者我都有在做，因为我的目的只有一个，能够帮助大家更好地开发和维护项目。具体 AndroidProject 在代码设计上有什么亮点，这里我建议你看一下里面的代码，我相信你看完后会有收获的，后面我可能也会出一篇文章具体讲述 AndroidProject 的亮点。
假设 AndroidProject 更新了该怎么升级它
- 原因和解释：首先纠正一点，AndroidProject 严格意义上来说，不是框架一种，而属于架构一种，架构升级本身就是一件大事，并且存在很多未知的风险点，我不推荐已使用 AndroidProject 开发的项目去做升级，因为开发和测试的成本极其高，间接能为业务带来价值其实很低，很多时候我知道大家很喜欢 AndroidProject 的代码，想用到公司项目中去，但是我仍然不推荐你那么做，假设这是你的个人项目可以那么做，但是公司项目最好不要，因为公司和你都是要靠这个项目赚钱，谁也不希望项目出现问题，如果是公司要开发人员重构公司项目，也可以考虑那么做，毕竟这个时候的风险公司已经承担了大部分了，接下来的话只需要服从公司安排即可。
- 更新的方式：由于 AndroidProject 不是一个单独的框架那么简单，无法通过更新远程依赖的方式进行升级，所以只能通过替换代码的形式进行更新，需要注意的是，代码覆盖完需要经过严格的自测及测试，测试是做这件事情的关键流程，需要重视起来，对每一处功能进行详细测试，一定要详细，特别涉及到主流程的功能。
为什么不用谷歌 ActivityResultContracts
- ActivityResultContract是 Activity 1.2.0-alpha02 和 Fragment 1.3.0-alpha02 中新追加的新 API，但是在此之前 AndroidProject 早已经对 onActivityResult 回调进行了封装，详情请见 BaseActivity
public abstract class BaseActivity extends AppCompatActivity {
/** Activity 回调集合 */
private SparseArray<OnActivityCallback> mActivityCallbacks;
/**
* startActivityForResult 方法优化
*/
public void startActivityForResult(Class<? extends Activity> clazz, OnActivityCallback callback) {
startActivityForResult(new Intent(this, clazz), null, callback);
}
public void startActivityForResult(Intent intent, OnActivityCallback callback) {
startActivityForResult(intent, null, callback);
}
public void startActivityForResult(Intent intent, @Nullable Bundle options, OnActivityCallback callback) {
if (mActivityCallbacks == null) {
mActivityCallbacks = new SparseArray<>(1);
}
// 请求码必须在 2 的 16 次方以内
int requestCode = new Random().nextInt((int) Math.pow(2, 16));
mActivityCallbacks.put(requestCode, callback);
startActivityForResult(intent, requestCode, options);
}
@Override
protected void onActivityResult(int requestCode, int resultCode, @Nullable Intent data) {
OnActivityCallback callback;
if (mActivityCallbacks != null && (callback = mActivityCallbacks.get(requestCode)) != null) {
callback.onActivityResult(resultCode, data);
mActivityCallbacks.remove(requestCode);
return;
}
super.onActivityResult(requestCode, resultCode, data);
}
public interface OnActivityCallback {
/**
* 结果回调
*
* @param resultCode 结果码
* @param data 数据
*/
void onActivityResult(int resultCode, @Nullable Intent data);
}
}
- 至于要不要换成谷歌出的那种呢？我们先来对比这两种的方式的用法
// Google 的用法
registerForActivityResult(new ActivityResultContracts.StartActivityForResult(), new ActivityResultCallback<ActivityResult>() {
@Override
public void onActivityResult(ActivityResult result) {
Intent data = result.getData();
int resultCode = result.getResultCode();
}
}).launch(new Intent(this, HomeActivity.class));
// AndroidProject 的用法
startActivityForResult(HomeActivity.class, new OnActivityCallback() {
@Override
public void onActivityResult(int resultCode, @Nullable Intent data) {
}
});
对这两种经过对比，得出结论如下：
- 谷歌原生的没有 AndroidProject 封装得那么人性化，谷歌那种方式调用稍微麻烦一点
- 谷歌那种方式直接集成进 AndroidX 包的，要比直接在 BaseActivity 中封装要好
- AndroidProject 封装 onActivityResult 回调至少要比谷歌要早一两年，并非谷歌之后的产物
- 之前使用 AndroidProject 的人群已经习惯和记忆了那种方式，所以 API 不能删也不能改
- 所以并不是我不想用，而是谷歌封装得还不够好，至少在我看来还不够好，抛去 AndroidProject 封装的时间早不说，谷歌封装出来的效果也是强差人意，我感觉谷歌工程师的封装得越来越敷衍了，看起来像是在完成任务，而不是在做好一件事。
轮子哥你怎么看待层出不穷的新技术
- 新东西的出现总能引起别人的好奇和尝试，但是我建议有兴趣的人可以学一下，但是如果要应用到项目中，我个人建议还是要慎重，因为纵观历史，我们不难发现，技术创新虽然很受欢迎，但是大多数都经不住时间的考验，最终一个个气尽倒下，这是因为很多新技术，表面看起来很美好，但实际上一入坑深似海。当然也有一些优秀的技术创新活了下来，但是毕竟占的是少数。
- 谈谈我对新技术的看法，首先我会思考这种新技术能解决什么痛点，这点非常重要，再好的技术创新，也必须得创造价值，否则就是在扯淡。有人肯定会问，什么样的技术才算有价值？对于我们 Android 程序员来讲，无非就围绕两点，开发和维护。要么在前期开发上，能发挥很大的作用，要么在后续维护上面，能体现它的优势。
- 还有谷歌的新技术不一定都是好的，也有一些是 KPI 产物，别忘了，他们也是打工的，他们也有 KPI 考核，为了年终奖和晋升，他们不得不卖力宣传，纵使他们知道这个东西有硬伤，但是他们也会推出来看看市场反应。所以我们看待一种新技术，不要太看重是否是大公司出品的，也不要太看重是哪个行业名人写的，我们应该要重点关注的是，产品的质量以及能带给我们带来哪些帮助，还有会带来哪些不好的影响，这个才是正确的技术价值观。
