AndroidManifest出现Bug是无法修复的,因为它是由系统进行解析的,系统会直接获取安装包里唯一的AndroidMainfest.xml文件,在解析过程不会访问补丁包信息。
代码修复:任何的热修复方案,想要改变代码逻辑,都需要在补丁包里包含一个新逻辑的dex文件。
资源修复:有些资源,比如桌面图标,通知栏图标以及RemoteView之类的资源,是由系统直接解析安装包里的资源得到的,因此对于这类资源,任何热修复方案都无法进行资源替换和修复。
so库修复:so库的修复思路应该是最明确的。在Android系统中,所有的so库都是由System.load进行加载的,因此只要找到办法在加载的时候优先加载补丁包的so库,而不是加载原有安装包的so库,就能够进行完整的底层代码替换了。
代码修复
代码修复主要有三大主要方案,阿里系的底层替换和腾讯系的类加载方案以及美团的javaHook方案(Instant Run原理)。
- 底层替换方案限制颇多,但是时效性最好,加载轻快,立即见效。
传统的底层替换方案(Dexposed,AndFix),依赖直接修改虚拟机方法实体的具体字段实现的。不同厂商/版本对ArtMethod结构体的结构修改带来的问题。每个Java方法在art中都对应着一个ArtMethod,ArtMethod记录了这个Java方法的所有信息,包括所属类,访问权限,代码执行地址等等。
实现一种不修改底层具体结构的替换方式,解决兼容性问题,代码量大大减少。native层面替换,把ArtMethod方法作为整体进行替换。
- 类加载方案时效性差,需要重新类启动才能见效,但修复范围广,限制少。
类加载方案的原理是在App重新启动后让Classloader去加载新的类。
QQ空间方案会入侵打包流程,并且为hack添加一些无用的信息,不优雅。
QFix方案需要获取底层虚拟机的函数,稳定性不够,无法新增public函数
Tinker方案是完整的全量的dex文件加载,将补丁合成的方案做到了极致,从dex的方法和指令维度进行全量合成,对于dex内容的比较粒度过细,实现较为复杂,性能消耗比较严重,时空转换性价比不高。
dex比较的最佳粒度,应该是类的维度,采用全量合成dex的技术,这个技术方案是从手机淘宝插件化框架Atlas汲取的。直接利用Android原有的类查找与合成机制,快速合成新的的全量dex文件。这样既不需要处理合成时的方法数超过原有方法数的情况,也不会对dex的结构进行破坏性重构。
我们重新编排了包中dex文件的顺序。这样虚拟机在查找类的时候,会优先找到classes.dex中的类,然后才是classes2.dex,classes3.dex,也可以看作是dex文件级别的类插桩方案。这个方式十分巧妙,它对旧包与补丁包中的classes.dex顺序进行了打破和重组,最终使系统可以自然的识别到这个顺序,以实现类覆盖的目的,大大减少合成补丁的开销。
Sophix使用了两者的结合,自动选择,小修改,在底层替换方案限制范围内的,直接采用底层替换热修复,可以做到及时生效。其他采用类加载替换方案。
- Robust的JavaHook方案的原理与Instant Run的代码插桩原理一致,优点是实时生效,不需要重新启动,高兼容性(Robust只是在正常的使用DexClassLoader),高稳定性,修复成功率高达99%。支持方法级别的修复,包括静态方法。支持增加方法和类。支持ProGuard的混淆,内联优化等操作。
缺点是代码是侵入式的,会在原有的类中加入相关代码,so库和资源的替换暂时不支持。会增大apk的体积,平均一个函数会比原来增加17.47个字节,10万个函数会增加1.67M。
Sophix方案
热部署(及时生效)
在native层面替换,把ArtMethod方法作为整体进行替换,实时生效,但同时也会带来诸多限制:
访问权限的问题
-
方法调用时的权限检查
-
同名包下的权限问题(设置新类的ClassLoader为原来类就可以了,通过反射进行设置)
-
反射调用非静态方法产生的问题
及时生效带来的限制
以下两种情况是不适用的:
-
引起了原有的类中发生结构变化的修改(字段,方法增加减少),改成以冷启动支持
-
修复了的非静态方法会被反射调用,改成以冷启动方式支持
编译期和语言特性的影响
1. 内部类编译
-
静态内部类/非静态内部类的区别
-
内部类和外部类互相访问
外/内部类为了访问内/外部类私有的域/方法,编译器会自动为内部类生成access$数字编号相关方法,JVM规范,好像是提供了一个静态方法
- 热部署解决方案
一个外部类如果有内部类,把所有的method/field的私有访问权限改成protected或public或者默认访问权限。
同时把内部类所有的method/field的私有访问权限改成protected或public或者默认访问权限。
2. 匿名内部类编译
-
匿名内部类编译命名规则(access$**)
-
热部署解决方案
应该极力避免插入一个新的匿名内部类。当然如果匿名内部类是插入到外部类的末尾,那么是允许的。
3. 有趣的域编译
-
静态field,非静态field
-
静态field初始化,静态代码块(不支持
<clinit>
方法的热部署,只能冷启动生效)
静态代码块和静态域初始化在clinit中的先后关系就是两者出现在源码中的先后关系
以下三种情况都会尝试去加载一个类:
-
创建一个类的对象(new-instance指令)
-
调用类的静态方法(invoke-static指令)
-
获取类的静态域的值(sget指令)
-
非静态field初始化,非静态代码块
-
热部署解决方案
clinit只能冷启动,init无影响
4. final static预编译规则
final static修饰的基本类型或String常量类型,没有被编译到clinit方法中
- final static域编译规则
final static修饰的原始类型和String类型域(非引用类型),并不会被编译在clinit方法中,而是在初始化执行initSFields方法时得到了初始化赋值。
final static修饰引用类型,初始化仍在clinit方法中
- final static域优化原理
final static引用类型没有得到优化,只是基本数据类型和String类型域(非引用类型)
- 热部署解决方案
修改 final static 基本类型或者 String 类型域(非引用类型域),由于在编译期间引用到基本类型的地方被立即数替换,引用到 String 类型(非引用类型)的地方被常量池索引 ID 替换,所以在热部署模式下,最终所有引用到该 final static 域的方法都会被替换。实际上此时仍然可以执行热部署万案。
修改 final static 引用类型域,是不允许的,因为这个 field 的初始化会被编译到 clinit 万法中,所以此时没法走热部署 。
5. 有趣的方法编译
- 应用混淆方法编译
项目如果应用了混淆方法编译,可能导致方法内联和裁剪,最后可能导致method的新增或减少。
- 方法内联
以下几种可能导致方法被内联掉:
-
方法没有被其他任何地方引用
-
方法足够简单,比如一个方法的实现就只有一行代码
-
方法只被一个地方引用
可能导致只能走冷启动方案
- 方法裁剪
可能导致只能走冷启动方案
如果让该参数不被裁剪,不让编译器在优化的时候认为引用了一个无用的参数就好了,这里介绍一种最有效的方法:
public static void test(Context context){
if(Boolean.FALSE.booleanValue()){
context.getApplicationContext();
}
Log.d(“BaseBug”,“test”)
}
这里不能使用基本类型,必须使用包装类Boolean,因为如果使用基本数据类型if语句可能也会被优化掉。
- 热部署解决方案
混淆配置文件加上-dontoptimize项就不会去做方法内联和裁剪,proguard-android-optimize.txt 或者 proguard-android.txt,两者的区别就是后者应用了 -dontoptimize 这一项配置而前者没有应用。
混淆库给热部署带来的影响主要在optimization阶段
optimzation step: -dontoptimize(热补丁模式下)
preverification step: -dontpreverify
混淆库对反射的处理(proguard.jar),shrinking阶段,obfuscation阶段
6. switch case语句编译
packed-switch,sparse-switch指令
可能导致资源替换不全
热部署解决方案:反编译->资源ID->替换->回编译
7. 泛型编译
泛型擦除,类型擦除与多态的冲突和解决,泛型类型转换
热部署解决方案
如果由 B extends A 变成了 B extends A<Number>
,那么就可能会新增对应的桥接方法 ,此时新增了方法,只能走冷 部署,如果要避免,那就避免类似上面的那种修复。
泛型的系统注解
8. Lambda表达式编译
Lambda表达式可能导致方法的新增或减少
- Lambda表达式的编译规则
函数式接口具有两个主要特征:**它是一个接口,这个接口具有唯一的抽象方法;我们将同时满足这两个特性的接口称为函数式接口。**比如java.lang.Runnable和java.util.Comparator,函数式接口和匿名内部类的区别如下:
-
关键字this,匿名类的this关键字指向匿名内部类,而Lambda表达式的this关键字指向包围Lambda表达式的类。
-
编译方式,Java编译器将Lambda表达式编译成类的私有方法,使用Java7的invokeddynnamic字节码指令来动态绑定这个方法。Java编译器将匿名内部类编译成外部类$数字编号的新类。
编译器间自动生成私有静态的lambda$main$**(*)
方法,这个方法的实现其实就是Lambda表达式里面的逻辑。
invokedynamic指令执行Lambda表达式
比较与匿名内部类的区别,发现并没有在磁盘上生成外部类$数字编号的新类
invokedynamic指令执行时实际上回去调用java/lang/invoke/LambdaMetafactory的metafactory静态方法。**这个静态方法实际上会在运行时生成一个函数式接口的具体类。**然后具体类会调用Test的私有静态lambda$main$**(*)
方法。
我们可以通过添加- Djdk.internal . lambda .dumpProxyClasses 这个虚拟机运行参数,那么运行时会将生成的新类的 .class 内窑输出到一个文件中。
Sun/Oracle Hotspot VM和Android虚拟机解释Lambda表达式的异同点
上面的方式是Sun/Oracle Hotspot VM解释.class文件中lambda表达式的方式,**Android虚拟机首先通过javac把源代码编译成.class,然后再通过dx工具优化成适合移动设备的dex字节码文件。**Android中如果要使用Java8的语言特性,需要使用新的Jack工具类来替换掉就的工具类编译。细节见书籍。
很明显可以看到.dex字节码文件和.class字节码文件对Lambda表达式处理的异同点:
共同点:编译期间都会为外部类合成一个static辅助方法,该方法内部逻辑实现Lambda表达式。
不同点:
-
.class字节码通过invoke-dynamic指令执行Lambda表达式。而.dex字节码中执行Lambda表达式跟普通方法调用没有任何区别。
-
.class字节码中运行时生成新类,.dex字节码中编译期间生成新类。
-
热部署解决方案
打补丁是通过反编译为smail然后跟新APK跟基线APK进行差异对比,得到最后的补丁包。
新增一Lambda表达式,会导致外部类新增一个辅助方法,所以此时不支持走热部署方案。如果Lambda表达式中访问非静态field/method,就会持有外部类的引用。
增加或减少一个Lambda表达式会导致类方法比较错乱,所以会导致热部署失败。
修改一个Lambda表达式,可能导致新增field,所以此时也导致热部署失败。
9. 访问权限检查对热替换的影响
- 类加载阶段父类/实现接口访问权限检查
一个类的加载过程,必须经历resolve,link,init三个阶段,父类或实现接口权限控制检查主要发生在link阶段。
- 类校验阶段访问权限检查
10. <clinit>
方法
由于补丁热部署的特殊性,不允许类结构变更以及不允许变更<clinit>
方法,所以补丁工具如果发现了以上几种限制情况,只能走冷启动。可能有时候在源码层上来看并没有新增或减少method和 field,但是实际上由于要满足 Java 各种语法特性的需求,所以编译器会在编译期间自动合成一些method 和 field时,最后就有可能触发了这几个限制情况。
小结
重点讲解了影响热替换热修复的一些重要的编译器问题。但是热修复还有个比较大的问题,由于是在运行期发生了变动,如果我们修改了某个方法的逻辑,就会导致它在修复前后的逻辑不一致,这就会引发一些诡异的错误。**因此热替换方式的热修复只适用于修复一些简单的BUG,如果要做一些功能方面的更新,不建议采用。**热部署修复方案的根本原理是基于native层方法的替换,所以当类结构变化时,如新增减少类method/field在热部署模式下会受到限制,修复了的非静态方法会被反射调用也会受到限制。
冷启动代码修复
现有的一些冷启动实现方案
| | Tinker | QQ空间 |
| — | — | — |
| 原理 | 提供dex差量包,整体替换dex的方案。差量的方式给出patch.dex,然后将patch.dex与应用的class.dex合并成一个完整的dex,完整的dex加载得到dexFile对象作为参数构建一个Element对象然后整体替换掉旧的dex Element数组。 | 为了解决Dalvik下的unexpected dex problem异常而采用插桩的方式,单独放一个帮助类在独立的dex中让其他类调用,阻止了类被打上CLASS_ISPREVERIFIED标志从而规避问题的出现。最后加载补丁dex得到dexFile对象作为参数构建一个Element对象插入到dex Elements数组的最前面 |
| 优点 | 自研dex差异算法,补丁包很小,dex merge成完整的dex,Dalvik不影响类加载性能,Art下也不存在必须包含父类/引用类的情况 | 没有合成整包,产物比较小,比较灵活 |
| 缺点 | dex合并内存消耗在vm heap上,容易导致OOM,最后导致dex合成失败 | Dalvik下影响类加载性能,Art下类地址写死,导致必须包含父类/引用类,最后补丁包很大 |
Tinker的dex merge操作是在Java层面进行的,所有对象的分配都是在java heap上完成的,可能发生申请的java heap超过vm heap规定的大小,进程发生OOM导致进程被杀死合成失败,如果在JNI层面进行C++ new/malloc申请的内存,分配在native heap,native heap的增长并不受vm heap大小的限制,只受限于RAM,如果RAM不足,也会导致进程被杀死导致闪退。在JNI层面进行dex merge,从而避免OOM提高合并成功率。
QQ空间的解决方案
问题来源
如果我们把要修复的QzoneActivityManager类打包成一个dex文件,插入到所有的dex文件的最前面,
1. ModuleManager在classes.dex中
2. QzoneActivityManager在patch.dex
ModuleManager引用了QzoneActivityManager,但是发现这两个类不在同一个dex文件中,于是问题就出现了
解决方案
dex在转换为odex(dexopt)的代码中的一段,在安装apk的时候,class.dex会被虚拟机(dexopt)优化成odex文件,然后才拿去执行
//DexPrepare.cpp
/*
- First, try to verify it.
*/
if (doVerify) {
if (dvmVerifyClass(clazz)) {
/*
-
Set the “is preverified” flag in the DexClassDef. We
-
do it here, rather than in the ClassObject structure,
-
because the DexClassDef is part of the odex file.
*/
assert((clazz->accessFlags & JAVA_FLAGS_MASK) ==
pClassDef->accessFlags);
((DexClassDef*)pClassDef)->accessFlags |= CLASS_ISPREVERIFIED;
verified = true;
} else {
// TODO: log when in verbose mode
ALOGV(“DexOpt: ‘%s’ failed verification”, classDescriptor);
}
}
虚拟机在启动的时候,会有许多的启动参数,其中一项就是verify选项,当verify选项被打开的时候,上面doVerify变量为true,那么就会执行dvmVerifyClass进行类的校验,如果dvmVerifyClass校验类成功,那么这个类会被打上CLASS_ISPREVERIFIED的标志,那么具体的校验过程是什么样子的呢?
//DexVerify.cpp
bool dvmVerifyClass(ClassObject* clazz)
{
int i;
if (dvmIsClassVerified(clazz)) {
ALOGD(“Ignoring duplicate verify attempt on %s”, clazz->descriptor);
return true;
}
for (i = 0; i < clazz->directMethodCount; i++) {
if (!verifyMethod(&clazz->directMethods[i])) {
LOG_VFY(“Verifier rejected class %s”, clazz->descriptor);
return false;
}
}
for (i = 0; i < clazz->virtualMethodCount; i++) {
if (!verifyMethod(&clazz->virtualMethods[i])) {
LOG_VFY(“Verifier rejected class %s”, clazz->descriptor);
return false;
}
}
return true;
}
- 验证clazz->dvmIsClassVerified方法,directMethods包含了以下方法:
- static方法
- private方法
- 构造函数
- clazz->virtualMethods
- 虚函数=override方法
概括一下就是如果以上方法中直接引用到的类(第一层级关系,不会递归进行搜索)和clazz都在同一个dex中的话,那么这个类就会被打上CLASS_ISPREVERIFIED
因为dex在优化的过程中会进行class的校验,给每一个class打上了一个CLASS_ISPREVERIFIED的标签,在调用的时候会根据该标签判断所在的class是否是同一个dex如果不是会抛出异常导致程序停止。所以我们需要防止类被打上CLASS_ISPREVERIFIED。
最终的解决方案是在所有类的构造函数里面插入了一段代码:代码如下
if (ClassVerifier.PREVENT_VERIFY) {
System.out.println(AntilazyLoad.class);
}
其中AntilazyLoad类会被打包成单独的hack.dex,这样当安装apk的时候,classes.dex内的类都会引用一个在不相同dex中的AntilazyLoad类,这样就防止了类被打上CLASS_ISPREVERIFIED的标志了,只要没被打上这个标志的类都可以进行打补丁操作。
然后在应用启动的时候加载进来.AntilazyLoad类所在的dex包必须被先加载进来,不然AntilazyLoad类会被标记为不存在,即使后续加载了hack.dex包,那么他也是不存在的,这样屏幕就会出现茫茫多的类AntilazyLoad找不到的log。
所以Application作为应用的入口不能插入这段代码。(因为载入hack.dex的代码是在Application中onCreate中执行的,如果在Application的构造函数里面插入了这段代码,那么就是在hack.dex加载之前就使用该类,该类一次找不到,会被永远的打上找不到的标志)
其中
class ClassVerifier{
public static boolean PREVENT_VERIFY=false;//false防止代码被执行,提高性能
}
之所以选择构造函数是因为他不增加方法数,一个类即使没有显式的构造函数,也会有一个隐式的默认构造函数。
空间使用的是在字节码插入代码,而不是源代码插入,使用的是javaassist库来进行字节码插入的。
虚拟机在安装期间为类打上CLASS_ISPREVERIFIED标志是为了提高性能的,我们强制防止类被打上标志会影响性能.(5.0以下)
但是插桩会给类加载效率带来比较严重的影响,熟悉Dalvik虚拟机开发的都知道,一个类的加载阶段通常有三个阶段:
-
dvmResolveClass
-
dvmLinkClass
-
dvmInitClass:在类解析完并尝试初始化类的时候执行,这个方法主要完成父类的初始化,当前类的初始化,静态变量的初始化赋值等操作。
可以看到如果类没被打上CLASS ISPREVERIFIED/CLASS ISOPTIMIZED 的标志,那么类的校验和优化都在类的初始化阶段进行。那么类的校验和优化都将在类的初始化阶段进行。正常情况下类的校验和优化都仅在 APK 第一次安装执行 dexopt 操作的时候进行 , 类的校验任务实际上是很重的,因为会对类的所有方法中的所有指令都进行校验,单个类加载时类校验耗时并不多,但是如果是在同一时间点加载大量类的情况下,这种耗时就会被放大 。
性能影响
插桩导致所有的类都非preverify,从而导致校验和优化操作都会在类加载时触发,平均每个类的校验和优化的耗时并不长,但是应用刚启动的时候一般会同时加载大量的类,容易导致用户白屏。
QFix的解决方案
与QQ空间采用的native hook方式不同,不会去hook某个系统方法,而是从navie层直接调用,有如下注意点:
-
dvmResolveClass的第三个参数fromUnverifiedConstant必须为true。
-
在APK多dex的情况下,dvmResolveClass第一个参数referrer类必须跟需要打包的类在同一个dex中,但是它们两个类不需要存在任何引用关系,任何一个在同一个dex中的类作为referrer都可以。
-
referrer类必须提前加载。
但是QFix的方案有它独特的缺陷,由于是在dexopt后绕过的,dexopt会改变原有的很多逻辑,许多odex层面的优化会固定字段和方法的访问偏移,这会导致比较严重的bug。比如可能导致方法调用错乱。
但是上面两种方案都是侵入应用打包,我们的需求是冷启动模式是热部署模式的补充方案,所以这两种方案使用的应该是同一套补丁,我们的需求是无侵入打包又能做热部署模式的补充解决方案。
如何解决Dalvik虚拟机下类的pre-verify问题,如果一个类中直接引用到的所有非系统类都和该类在同一个dex中的话,那么这个类就会被打上CLASS_ISPAREVERIFIED标志,具体判定代码可见虚拟机中的verifyAndOptimizeClass函数。
腾讯三大热修复方案如何解决该问题:
- QQ空间的处理方式是在每个类中插入一个来自其他dex的hack.class,由此让所有类都无法满足pre-verified条件。
缺点:入侵打包流程,添加臃肿代码,不优雅,无法新增public函数。
- Tinker的方式是合成全量的dex文件,这样所有类都在全量dex中解决,从而消除类重复而带来的冲突。
粒度过细,实现起来较为复杂,性能消耗比较严重,时空代价转换的性价比不高(dex占apk比例不高)
- QFix的方式是获取虚拟机中的某些底层函数,提前解析所有补丁类。以此绕过Pre-verify检查。
需要获取底层虚拟机函数,不够稳定可靠,无法新增public函数。
Robust解决方案(实时生效)
在打基础包时插桩,在每一个方法前插入一段ChangeQuickRedirect静态变量的逻辑,插入过程对业务开发完全透明。加载补丁时,从补丁包中读取要替换的类以及具体替换的方法实现,新建ClassLoader加载补丁dex。当changeQuickRedirect不为null的时候,可能会执行到accessDispatch从而替换掉之前老的逻辑,达到fix的目的。
public static ChangeQuickRedirect u;
protected void onCreate(Bundle bundle) {
//为每个方法自动插入修复逻辑代码,如果ChangeQuickRedirect为空则不执行
if (u != null) {
if (PatchProxy.isSupport(new Object[]{bundle}, this, u, false, 78)) {
PatchProxy.accessDispatchVoid(new Object[]{bundle}, this, u, false, 78);
return;
}
}
super.onCreate(bundle);
…
}
Robust的核心修复源码如下:
public class PatchExecutor extends Thread {
@Override
public void run() {
…
applyPatchList(patches);
…
}
/**
- 应用补丁列表
*/
protected void applyPatchList(List patches) {
…
for (Patch p : patches) {
…
currentPatchResult = patch(context, p);
…
}
}
/**
- 核心修复源码
*/
protected boolean patch(Context context, Patch patch) {
…
//新建ClassLoader
DexClassLoader classLoader = new DexClassLoader(patch.getTempPath(), context.getCacheDir().getAbsolutePath(),
null, PatchExecutor.class.getClassLoader());
patch.delete(patch.getTempPath());
…
try {
patchsInfoClass = classLoader.loadClass(patch.getPatchesInfoImplClassFullName());
patchesInfo = (PatchesInfo) patchsInfoClass.newInstance();
} catch (Throwable t) {
…
}
…
//通过遍历其中的类信息进而反射修改其中 ChangeQuickRedirect 对象的值
for (PatchedClassInfo patchedClassInfo : patchedClasses) {
…
try {
oldClass = classLoader.loadClass(patchedClassName.trim());
Field[] fields = oldClass.getDeclaredFields();
for (Field field : fields) {
if (TextUtils.equals(field.getType().getCanonicalName(), ChangeQuickRedirect.class.getCanonicalName()) && TextUtils.equals(field.getDeclaringClass().getCanonicalName(), oldClass.getCanonicalName())) {
changeQuickRedirectField = field;
break;
}
}
…
try {
patchClass = classLoader.loadClass(patchClassName);
Object patchObject = patchClass.newInstance();
changeQuickRedirectField.setAccessible(true);
changeQuickRedirectField.set(null, patchObject);
} catch (Throwable t) {
…
}
} catch (Throwable t) {
…
}
}
return true;
}
}
其实我感觉Robust的方案虽然有侵入性,增加代码体积等的缺点,但是感觉这种方式是兼容率最好的方案。也不会受Android版本的更新影响。
Sophix的解决方案
新的全量dex方案(Dalvik)
在原先基线包里的dex中,去掉补丁包dex中也有的类,这样基线包dex里就只包含不变的类了。而这些不变的类在要用拿到补丁中的新类会自动找到补丁dex,补丁包中的新类在需要用到不变的类时也会找到基线包dex的类。基线包里面不使用补丁类的类仍旧可以按原来的逻辑做odex,最大程度的保证了dexopt的效果。对dex的结构也不用进行破坏性重构。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
总结
学习技术是一条慢长而艰苦的道路,不能靠一时激情,也不是熬几天几夜就能学好的,必须养成平时努力学习的习惯。所以:贵在坚持!
最后如何才能让我们在面试中对答如流呢?
答案当然是平时在工作或者学习中多提升自身实力的啦,那如何才能正确的学习,有方向的学习呢?有没有免费资料可以借鉴?为此我整理了一份Android学习资料路线:
这里是一部分我工作以来以及参与过的大大小小的面试收集总结出来的一套BAT大厂面试资料专题包,主要还是希望大家在如今大环境不好的情况下面试能够顺利一点,希望可以帮助到大家。
好了,今天的分享就到这里,如果你对在面试中遇到的问题,或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划。来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。
最后,祝愿即将跳槽和已经开始求职的大家都能找到一份好的工作!
这些只是整理出来的部分面试题,后续会持续更新,希望通过这些高级面试题能够降低面试Android岗位的门槛,让更多的Android工程师理解Android系统,掌握Android系统。喜欢的话麻烦点击一个喜欢再关注一下
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!
[外链图片转存中…(img-BgCGqSaw-1712233402576)]
[外链图片转存中…(img-MZXMO70Y-1712233402576)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
总结
学习技术是一条慢长而艰苦的道路,不能靠一时激情,也不是熬几天几夜就能学好的,必须养成平时努力学习的习惯。所以:贵在坚持!
最后如何才能让我们在面试中对答如流呢?
答案当然是平时在工作或者学习中多提升自身实力的啦,那如何才能正确的学习,有方向的学习呢?有没有免费资料可以借鉴?为此我整理了一份Android学习资料路线:
[外链图片转存中…(img-GZoaAKgR-1712233402577)]
这里是一部分我工作以来以及参与过的大大小小的面试收集总结出来的一套BAT大厂面试资料专题包,主要还是希望大家在如今大环境不好的情况下面试能够顺利一点,希望可以帮助到大家。
[外链图片转存中…(img-GMsL5jAd-1712233402577)]
好了,今天的分享就到这里,如果你对在面试中遇到的问题,或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划。来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。
最后,祝愿即将跳槽和已经开始求职的大家都能找到一份好的工作!
这些只是整理出来的部分面试题,后续会持续更新,希望通过这些高级面试题能够降低面试Android岗位的门槛,让更多的Android工程师理解Android系统,掌握Android系统。喜欢的话麻烦点击一个喜欢再关注一下