讲的真透彻！Android面试中常问的MMAP到底是啥东东？已拿到offer

2024-02-01 08:17:46

背景

首先我是个菜鸡，工资也低的一笔。

刚毕业时候在一家国企上班干 app 开发，干了快两年的时候，跳槽到了一家伪大厂干安全。投了不少简历都没有回音，只有这加伪大厂要我就来了。当时说好了会接触一些底层的东西，然而平时也就写 python 脚本，逆向，android 上写了一些风控的东西，感觉有点 low，工资也不高，当初没敢多要，hr 给的比我要的还高。刚刚 leader 谈了谈明年的规划，现在想跳槽。

现在也是很尴尬，原来 app 开发的东西也忘了不少，然后其实我想干 framework 开发，自己对 ams,pms 还算挺了解的，平时也根据他们原创了一点微小的解决方案。最近开始 fork 一个 aosp，买个 pixel 改改刷刷练习一下。

理想毕竟是理想，Android 低端不好混，没什么经验跳到 framework 上去感觉也是挺难的，跳回 app 开发又不甘心，现在的状态貌似是干了快 3 年没有特别精通的东西。最近闹的裁员，我司也是其中之一。加薪怕是没戏了，然而生活还要继续，跳槽避无可避。

组件化

1.1 组件化初衷

APP版本不断的迭代，新功能的不断增加，业务也会变的越来越复杂，维护成本高。
业务耦合度高，代码越来越臃肿，团队内部多人协作开发困难。
Android项目在编译代码的时候电脑会非常卡，又因为单一工程下代码耦合严重，每修改一处代码后都要重新编译打包测试，导致非常耗时。
方便单元测试，改动单独一个业务模块，不需要着重于关注其他模块被影响。

1.2 什么是组件化

组件化就是将一个app分成多个Module，如下图，每个Module都是一个组件(也可以是一个基础库供组件依赖)，开发的过程中我们可以单独调试部分组件，组件间不需要互相依赖，但可以相互调用，最终发布的时候所有组件以lib的形式被主app工程依赖并打包成一个apk。

1.3 组件化优势

组件化就是将通用模块独立出来，统一管理，以提高复用，将页面拆分为粒度更小的组件，组件内部除了包含UI实现，还包含数据层和逻辑层。
每个工程都可以独立编译、加快编译速度，独立打包。
每个工程内部的修改，不会影响其他工程。
业务库工程可以快速拆分出来，集成到其他App中。
迭代频繁的业务模块采用组件方式，业务线研发可以互不干扰、提升协作效率，并控制产品质量，加强稳定性。
并行开发，团队成员只关注自己的开发的小模块，降低耦合性，后期维护方便等。

2 组件化通信

2.1 组件化通信

组件化互相不直接依赖，如果组件A想调用组件B的方法是不行的。很多开发者因为组件化之间通信比较复杂则放弃了组件化的使用

组件通信有以下几种方式:

####### 1.本地广播

本地广播，也就是LoacalBroadcastRecevier。更多是用在同一个应用内的不同系统规定的组件进行通信，好处在于：发送的广播只会在自己的APP内传播，不会泄漏给其他的APP，其他APP无法向自己的APP发送广播，不用被其他APP干扰。本地广播好比对讲通信，成本低，效率高，但有个缺点就是两者通信机制全部委托与系统负责，我们无法干预传输途中的任何步骤，不可控制，一般在组件化通信过程中采用比例不高。

2.进程间的AIDL

进程间的AIDL。这个粒度在于进程，而我们组件化通信过程往往是在线程中，况且AIDL通信也是属于系统级通信，底层以Binder机制，虽说Android提供模板供我们实现，但往往使用者不好理解，交互比较复杂，往往也不适用应用于组件化通信过程中。

3.匿名的内存共享

匿名的内存共享。比如用Sharedpreferences，在处于多线程场景下，往往会线程不安全，这种更多是存储一一些变化很少的信息，比如说组件里的配置信息等等

4.Intent Bundle传递

Intent Bundle传递。包括显性和隐性传递，显性传递需要明确包名路径，组件与组件往往是需要互相依赖，这背离组件化中SOP（关注点分离原则），如果走隐性的话，不仅包名路径不能重复，需要定义一套规则，只有一个包名路径出错，排查起来也稍显麻烦，这个方式往往在组件间内部传递会比较合适，组件外与其他组件打交道则使用场景不多。

2.2 目前主流做法之一就是引入第三者，比如图中的Base Module。

3 ARouter组件通信框架

3.1 ARouter 简介

是ARouter是阿里巴巴开源的Android平台中对页面、服务提供路由功能的中间件，提倡的是简单且够用。主要用作组件化通信

        Intent intent = new Intent(mContext, XxxActivity.class);
 intent.putExtra("key","value");
 startActivity(intent);
 
 Intent intent = new Intent(mContext, XxxActivity.class);
 intent.putExtra("key","value");
 startActivityForResult(intent, 666);

上面一段代码，在Android开发中，最常见也是最常用的功能就是页面的跳转，我们经常需要面对从浏览器或者其他App跳转到自己App中页面的需求，不过就算是简简单单的页面跳转，随着时间的推移，也会遇到一些问题：

集中式的URL管理：谈到集中式的管理，总是比较蛋疼，多人协同开发的时候，大家都去AndroidManifest.xml中定义各种IntentFilter，使用隐式Intent,最终发现AndroidManifest.xml中充斥着各种Schame，各种Path，需要经常解决Path重叠覆盖、过多的Activity被导出，引发安全风险等问题
可配置性较差：Manifest限制于xml格式，书写麻烦，配置复杂，可以自定义的东西也较少
跳转过程中无法插手：直接通过Intent的方式跳转，跳转过程开发者无法干预，一些面向切面的事情难以实施，比方说登录、埋点这种非常通用的逻辑，在每个子页面中判断又很不合理，毕竟activity已经实例化了
跨模块无法显式依赖：在App小有规模的时候，我们会对App做水平拆分，按照业务拆分成多个子模块，之间完全解耦，通过打包流程控制App功能，这样方便应对大团队多人协作，互相逻辑不干扰，这时候只能依赖隐式Intent跳转，书写麻烦，成功与否难以控制。

为了解决以上问题，我们需要一款能够解耦、简单、功能多、定制性较强、支持拦截逻辑的路由组件：我们选择了Alibaba的ARouter，偷个懒，直接贴ARouter的中文介绍文档：

3.2 ARouter 优势

从 ARouter Github 了解到它的优势：

支持直接解析标准URL进行跳转，并自动注入参数到目标页面中支持多模块工程使用支持添加多个拦截器，自定义拦截顺序支持依赖注入，可单独作为依赖注入框架使用支持InstantRun 支持MultiDex(Google方案) 映射关系按组分类、多级管理，按需初始化支持用户指定全局降级与局部降级策略页面、拦截器、服务等组件均自动注册到框架支持多种方式配置转场动画支持获取Fragment 完全支持Kotlin以及混编典型的应用：

从外部URL映射到内部页面，以及参数传递与解析跨模块页面跳转，模块间解耦拦截跳转过程，处理登陆、埋点等逻辑

跨模块API调用，通过控制反转来做组件解耦

三、典型应用场景

从外部URL映射到内部页面，以及参数传递与解析
跨模块页面跳转，模块间解耦
拦截跳转过程，处理登陆、埋点等逻辑
跨模块API调用，模块间解耦(注册ARouter服务的形式，通过接口互相调用)

结尾

最后，针对上面谈的内容，给大家推荐一个Android资料，应该对大家有用。

首先是一个知识清单：（对于现在的Android及移动互联网来说，我们需要掌握的技术）

泛型原理丶反射原理丶Java虚拟机原理丶线程池原理丶
注解原理丶注解原理丶序列化
Activity知识体系（Activity的生命周期丶Activity的任务栈丶Activity的启动模式丶View源码丶Fragment内核相关丶service原理等）
代码框架结构优化（数据结构丶排序算法丶设计模式）
APP性能优化（用户体验优化丶适配丶代码调优）
热修复丶热升级丶Hook技术丶IOC架构设计
NDK（c编程丶C++丶JNI丶LINUX）
如何提高开发效率？
MVC丶MVP丶MVVM
微信小程序
Hybrid
Flutter