题目-App架构

app架构

模块化、组件化、插件化

MVC、MVP、MVVM

技术：原生、RN/flutter、H5

性能监控：crash、app瘦身、启动、内存、log

Android沙箱模式

Linux权限机制

• 用户 uid gid gids
• 进程 uid gid gids，继承于所属用户，子进程继承父进程
• 文件系统，uid gid 以及相对应rwx权限

Android进程隔离

Import aar包的两种方式

一、
repositories {
flatDir {
dirs ‘libs’
}
}

api(name: ‘pafacedetector4.6.1’, ext: ‘aar’)
二、
api fileTree(dir: ‘libs’, include: [’.jar’, '.aar’])

xposed

Xposed 框架是一款可以在不修改 APK 的情况下影响程序运行（修改系统）的框架服务，基于它可以制作出许多功能强大的模块，且在功能不冲突的情况下同时运作。

当前，Per APP Setting（为每个应用设置单独的dpi或修改权限）、Cydia、XPrivacy（防止隐私泄露）、对原生 Launcher 替换图标等应用或功能均基于此框架

Sdk 里面应用的okhttp和应用里面用的冲突，怎么解决
compile(‘com.facebook.fresco:imagepipeline-okhttp3:0.12.0’, {
exclude module: “okhttp”
})

对第三方 SDK 依赖冲突，重新打个包试试，更换包名

https://www.jianshu.com/p/a927044a6751

Android多个module引用相同的第三方库，会重复打包么？
https://www.zhihu.com/question/274024367

Android 进程级别 和 oom_adj对应关系

https://www.cnblogs.com/0616–ataozhijia/p/5678412.html

DataBinding
https://blog.csdn.net/weixin_44339238/article/details/103877157

Android架构设计模式
https://blog.csdn.net/weixin_44339238/article/details/103426447

架构师
https://blog.csdn.net/weixin_44339238/article/details/102610273

开发过程中项目是否需要重构？又需要注意什么？
https://blog.csdn.net/weixin_44339238/article/details/99643704

Dagger2的原理及使用详解
https://blog.csdn.net/weixin_44339238/article/details/99586365

首先是平台
CSDN和博客园，主流的技术交流平台，虽然广告越打越多了，但是还是有很多不错的博文的。
segmentfault，有点像国内的Stack Overflow，适合交流代码问题的地方。
掘金，一个很有极客范的技术社区，强推，有很多技术大牛分享优质文章。
开发者头条，一个整合优质技术博客的社区，里面基本上都是精选的高质量博文，适合技术学习提升。
v2ex，一个极客社区，除了交流技术以外还会有很多和程序员生活相关的话题分享。
知乎.这个就不必多说了。
简书 简书上有些技术文章也很不错，有空大家也可以去看看。
Github 有一些GitHub的项目还是非常不错的，其中也有仓库会分享技术文章

tinker源码研究

组件化的好处
任意修改都需要编译整个工程,效率低下，提高编译效率
解耦,有利于多人团队协作开发
功能复用

MVC,MVP,MVVM
首先需要知道的是为什么要进行技术框架的设计? 肯定是为了低耦合，提高开发效率是吧，所以不要为了设计而设计

热修复原理
原理

安卓在加载class时会通过双亲委托机制去加载一个类，先让父类去加载，如果找不到再让子类去加载某个类。
通过查看ClassLoader源码发现findClass方法是由每个子类自己实现的，比如BootClassLoader或者BaseDexClassLoader。而PathClassLoader是继承自BaseDexClassLoader的，它的findClass也是在BaseDexClassLoader里面实现的。
BaseDexClassLoader的findClass里面使用了另一个对象DexPathList去查找对应的class，这是安卓里面特有的实现。在DexPathList对象里面有一个属性dexElements，dexElements是用于存放加载好了的dex数组的，查找class是从这个dexElements数组里面去找的。
…
一句话总结

将修复好的类放在dexElements的最前面,这样在加载类的时候就会被优先加载到而达到修复的目的

MVC

在Android中View和Controller一般就是被Activity充当了，当逻辑非常多，操作非常复杂时，Activity代码量非常庞大，不易维护。

Model : 模型层,业务逻辑+数据存储等
View : 用户界面,一般就是xml+Activity
Controller : 控制层,一般就是Activity
MVP

我个人角度,现在(2019年10月29日20:02:49)大多是使用这种方式,既不复杂也解耦合了.

Model:模型层,业务逻辑+数据存储+网络请求
View:视图层,View绘制和用户交互等,一般是Activity
Presenter:呈现层,连接V层和M层,完成他们之间的交互
MVVM

为了更加分离M,V层,所以有了MVVM.

Model:模型层,业务逻辑+数据存储+网络请求
View:视图层,View绘制和用户交互等,一般是Activity
ViewModel:其实就是Presenter和View的数据模型的合体.双向绑定,View的变动会反应到ViewModel中,数据的变动也会反应到View上

ARouter路由源码分析汇总
https://blog.csdn.net/woqu000000/article/details/105257936

https://majing.io/posts/10000004681173
Kotlin使用kotlin-kapt插件支持Android的注解处理

看懂编译注解annotationProcessor和kapt
https://www.jianshu.com/p/472e66632ed0

AbstractProcessor学习
https://juejin.cn/post/6844904197775687694

https://www.jianshu.com/p/099b9f7c5538

Gradle 插件
https://plugins.gradle.org/
github

组件化框架调研和思考
https://www.jianshu.com/p/0d45f2a894ba

关于 Android Gradle 的 和 Javac 这里不会展开讲，在这里我们只需要理解在对 @Route 等注解处理前，是由 Android Gradle 的 AndroidJavaCompiler 来发起编译操作，然后让 Javac 去调用 RouteProcessor 等注解处理器对注解进行处理的，把映射表保存成json文件

在我们调用 ARouter 的 init() 方法时，ARouter 会调用 LogisticsCenter 的 init() 方法，在 LogisticsCenter 的 init() 方法中，会判断当前路由表加载方式是否为插件，不是的话则从 Dex 中加载路由表，是的话则由插件从 Jar 中加载路由表，读取json文件

增量编译–对用户源程序局部修改后进行的重新编译的工作只限于修改的部分及与之相关部分的内容。相关部分的确定由编译系统确定，对用户是透明的。增量编译对软件开发，尤其是在调试期，可以大大缩短编译时间， 提高编译效率，这也是增量编译的优势所在。

全量编译–对用户源程序局部修改后进行的重新编译的工作涉及全部源代码，并不只限于局部修改及其相关部分。换句话说，无论是否有修改，全量编译都将进行一次全新的完整的编译，并不基于上一次的编译基础。

不知是否你们代码量不多，或者对编译耗时这个要求不高，这个插件对于大点项目的耗时是很夸张的。

1. 假增量，在Transform里面写了支持增量，但实际并没有这么做，还是全局遍历
2. 读所有问题来做解析注解完全没必要，可以利用apt生成份包含有这个注解的类，从而来加速解析速度，每个类都找javassist去解析判断，性能很差的，大海捞针一样。

对于目前的版本，编译耗时主要在全量编译的过程中，个人实践 20+ 模块的编译过程中，耗时可接受，对于模块单独开发的流程则不会有任何影响。本人开发项目流程开发中，已经很少使用全量编译，大多数时候都是在模块单独开发，所以当前版本对日常开发的影响并不大。

大家可以不使用注解，接口的初始化可以自行实现，效率是最高的， 自己初始化接口也没多少工作量的

很高兴对这个小工具对您有用　：），谢谢分享你的宝贵经验，证明了 AppJoint 是个低入侵性、轻量级的组件化方案，我主张项目不应该和某个具体的组件化方案强耦合，您做到了这一点，说明你已经把项目结构改造到十分松散耦合的状态了，如果是其它的组件化方案不一定能做到这一点。

把现在纯 plugin 的模式，改为 apt + plugin 的模式，不直接选择AppJoint依赖，而是参考appjoint和Arouter的思路重新写了一遍AnnotationProcessor

https://github.com/razerdp/Component

bitmap和Drawable区别
可以简单地理解为 Bitmap 储存的是 像素信息，Drawable 储存的是 对 Canvas 的一系列操作。
而 BitmapDrawable 储存的是「把 Bitmap 渲染到 Canvas 上」这个操作。

Bitmap

• 称作位图，一般位图的文件格式后缀为bmp

Drawable

• 作为Android平下通用的图形对象，它可以装载常用格式的图像
  比如GIF、PNG、JPG，当然也支持BMP，当然还提供一些高级的可视化对象，比如渐变、图形等。

Bitmap是Drawable . Drawable不一定是Bitmap
Drawable在内存占用和绘制速度这两个非常关键的点上胜过Bitmap

升级到Glide4.0，使用asDrawable代替asBitmap，drawable更省内存。

你好 关于性能问题，可以参考或者使用下面的开源库：
https://github.com/bugyun/SpiderMan/tree/master/SpiderMan-plugin-core
优势：
优化文件处理速度
启用多线程来优化速度
比市面上相关插件速度快1倍以上
避免处理各种文件
只需要继承几个类就可以完成 ASM/Javassist 的代码注入
支持 ASM 和 Javassist

总结一波安卓组件化开源方案
https://developer.aliyun.com/article/603094

https://github.com/javalue/ARouter-Module

https://github.com/razerdp/Component

Android组件化
https://blog.csdn.net/u010451990/category_9804174.html

Android Gradle Plugin打包Apk过程中的Transform API
https://www.jianshu.com/p/811b0d0975ef?from=timeline&isappinstalled=0

基于ASM的组件化框架
https://blog.csdn.net/a296777513/article/details/88793108

Android 组件化方案，从入门到精通。apply plugin: ‘com.android.application’
https://blog.csdn.net/nnmmbb/article/details/82969995

回归初心：极简 Android 组件化方案 — AppJoint
https://juejin.cn/post/6844903687488274445

Android组件化入门：一步步搭建组件化架构
https://juejin.cn/post/6844903833378750478

Android 方法插桩 Plugin 开发实践
https://juejin.cn/post/6925053342443913224

Gradle中Transform是什么？
https://juejin.cn/post/6925384677695946765

Android Gradle Plugin插件开发——基础
https://blog.csdn.net/guy_guy/article/details/80914600

AppJoint 使用详细博客
https://segmentfault.com/a/1190000021558520

plugin 实战包体积瘦身
https://blog.csdn.net/ziwang_/article/details/80474952

Android Gradle插件开发
https://zhuanlan.zhihu.com/p/84323077

kotlin版本组件化+mvvm项目架构
https://blog.csdn.net/weixin_33674976/article/details/93162522

Hello Groovy
https://blog.csdn.net/u010451990/article/details/105382861.