https://github.com/longforus/testhotfix
https://github.com/longforus/testhotfix
Last synced: 10 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/longforus/testhotfix
- Owner: longforus
- Created: 2019-03-19T14:00:30.000Z (almost 7 years ago)
- Default Branch: master
- Last Pushed: 2019-03-19T14:00:53.000Z (almost 7 years ago)
- Last Synced: 2025-01-09T10:18:05.742Z (12 months ago)
- Language: Kotlin
- Size: 125 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Tinker热修复原理学习后的几点思考
最近几天断断续续的学了一下Tinker的热修复原理,按我的一句话说就是把已经修复的class放在有bug的class前面,让系统的classLoader能够先找到,找到了之后就不会再向下找了,那么bug也就避免了,具体的原理不准备记录,自己也讲不清楚.按照教程操作后,也能在8.1的真机上操作成功,但是9.0的模拟器没有成功.思考后有几个点没有搞明白,记录一下.
1. 这个例子中每次都是新创建的bug类的对象,能够修复成功,说明在创建实例的时候,每次都会使用classLoader读取class,如果是生命周期比较长,创建时期比hotfix操作早的对象,应该就不能修复了吧.
2. 自己打包生成的dex体积较大,(这里没有什么内容dex就有4M,但是第一个dex只有几kb,是因为配置了multiDex-config.txt的原因么?如果是那么只有这个列表包含的class才会分配到主包当中,怎么才能反着做呢?反着做也不可能,谁知道哪些class是包含有bug的呢?)怎么把需要修复的class打成单独的dex,tinker的补丁包,只有几kB,是如何实现对比拆分的呢?
3. 在进程重启后,fix失效,需要重新进行fix操作,但是tinker可以持续有效,如果原理是完全相同的话,tinker肯定是保存了补丁dex文件,在每次启动的时候读取这些文件进行fix操作,在如2这么大的dex的情况下势必是非常耗时的,在dex小但是数量多的情况下会不会对启动性能造成明显的影响呢?
4. 通过`getDir("odex", Context.MODE_PRIVATE)`获取的目录,因为文件夹名应该叫odex,结果却不是,获取的路径是:`/data/user/0/com.longforus.testhotfix/app_odex`,这个需要跟进代码去看看实现方式.