Android解耦式so库加载方案-低调大师

Android解耦式so库加载方案

2021-01-15 699

背景说明

在业务开发过程中经常会进入一些三方sdk,这些三方的sdk引入so库,有些so库文件还比较大,这时候我们就需要考虑so库从网络获取异步加载,减少发布包的体积

传统方案

关于so异步加载方案,网上的资料随便搜下大把,核心思想
so库文件放到网络->下载到本地沙盒->通过System.load载入
看起来挺简单的然而挺多资料没提到的是

so库存在依赖关系

比如当你把libunity.so下载下来通过
System.load("/data/data/com.example.soload/files/libunity.so")
加载的时候会得到如下异常

java.lang.UnsatisfiedLinkError: dlopen failed: library “libmain.so” not found
at java.lang.Runtime.loadLibrary0(Runtime.java:1071)
at java.lang.Runtime.loadLibrary0(Runtime.java:1007)
at java.lang.System.loadLibrary(System.java:1667)

原因分析

解决方案

载入libunity.so之前需要先载入libmain.so

扩展思考

我们写代码的时候怎么控制加载顺序呢
https://github.com/facebook/S...
https://github.com/KeepSafe/R...
以上2个开源库都有处理相关逻辑
核心思想就是解析so库ELF格式,分析依赖并递归,直到依赖库都加载完成再载入自身
这里不扩展开来有兴趣的伙伴可以看源码研究下

text relocations问题

当你把liblbs.so下载下来通过

System.load("/data/data/com.example.soload/files/liblbs.so")的时候又出现意外了
java.lang.UnsatisfiedLinkError: dlopen failed: “/data/data/com.example.soload/files/liblbs.so” has text relocations ( https://android.googlesource....
at java.lang.Runtime.load0(Runtime.java:938)
at java.lang.System.load(System.java:1631)==

原因分析：

https://blog.csdn.net/chjqxxx...

扩展思考：

我们可以通过命令进行自查

有源码的可以重新编译,没有源码的只能通过降低targetSdkVersion处理(然而也是治标不治本)

进阶方案

除了System.load方案还有没有其他方案呢
答案当然是肯定的
https://github.com/Tencent/ti...
核心思路:通过反射把自定义的native库path插入nativeLibraryDirect ories最前面，即使安装包libs目录里面有同名的so，也优先加载指定路径的外部so
这里截取tinker部分代码
com.tencent.tinker.lib.library.TinkerLoadLibrary.java

这个方案是不是看起来更简单了,由于这个方案是非常规手段,存在兼容风险, 我们需要验证该方案的兼容性,写个helloword的so,通过该方案加载,提前找个版本线上带上去,进行埋点统计
截至目前最新版上线2天统计到数据如下

其中失败的1例是上线前自测故意让校验失败产生的
也就是说截至目前可以认为改方案是靠谱的
当然了如果后续有新的Android系统版本更新
我们还需要关注新版本的兼容情况

项目应用

上面铺垫了那么多,现在进入正题
技术方案是一回事,落实到实际项目是另一回事
现在开始我们思考下如下几个问题

项目中引用的so库都是那些功能再用何时载入
三方jar(aar)引入的so库加载时机不受我们代码逻辑控制
使用的so库那些适合做异步加载
so库文件没有下载完成之前用户用相关功能如何处理
版本迭代so文件升级如何处理
打包阶段如何把so文件进行剔除

解决问题1、2、3

我们可以通过切面编程的思路解决,这里用到了开源库https://github.com/HujiangTec...
由于so库的加载都是通过调用系统函数System.loadLibrary进行,
那么我们全局拦截该函数的调用并打印调用链,
运行app,配合日志,就能分析so库的具体使用情况

这里我们需要根据自己业务场景分析,比如app进入到首页依赖的库不建议进行异步加载,需要异步加载的库最好是完成一个功能(我们需要按照经验进行逻辑分组参考文章开头的图)

解决问题4、5

Android是依据Activity作为活动单位,启动Activity是通过startActivity函数调用进行的,那么我们就可以拦截织入自己的逻辑
大致思路如下

对应实现部分代码截图

通过规则配置化+字节码拦截的逻辑对原有业务无侵入即可实现动态加载
研发关注正常的业务逻辑不需要针对性编写代码
后续引入新的so库,修改配置文件即可
在实现的过程中有些细节是需要考虑的
比如校验下载文件的完整性,下载要不要支持断点续传,so文件需要更新如何处理等

解决问题6

通过上面的介绍,我们实现了so文件的异步加载
但是打包的时候我们如何剔除so 减少最终发布包的大小
可以在build.gradle进行配置

但是上面提到了我们是通过json配置的规则
这样再重复配置一遍
而且还有可能2处配置不一致
而且我们的大原则是解耦
那么我们就继续hook打包流程

汇总小结

通过上面的介绍大致说明了原理

有兴趣的伙伴可以评论区留言，提出自己的想法

目前还在灰度验证阶段，等线上验证稳定后在评论区放出相关代码

so异步加载方案大同小异，该方案跟其他方案相比

个人感觉特色就是侵入性低

接入只需要3个步骤

未完待续

目前该方案还存在几个点有待优化

====================

问题1

目前用的是进阶方案实现的so库加载比较理想的方式是传统方案和进阶方案都应该支持一开始其实我想用传统方案去实现但是该方案在unity那块有问题(unity相关so的加载逻辑有点特殊存在通过jni直接加载so的情况由于没有源码内部逻辑不太清楚 ) 后续还需要研究完善毕竟官方System.load是官方提供的api 更可靠

问题2

进度加载的dialog是依附于调用startActivity的窗口
如果startActivuty之后里面立马调用finish会导致dialog泄露
这个是需要注意的一个点也就意味着对原有逻辑存在一定依赖
这个可以通过启动一个FLAG_ACTIVITY_NEW_TASK类型的activity
代理解决但是感觉这样有点重目前还有点纠结

问题3

目前文件只是放到了阿里云,用户的网络环境复杂多变,需要考虑支持腾讯云,七牛云等更多的服务商。

问题4

上传到oss的动作目前是动手完成的,需要做成脚本。

微信关注我们

原文链接：https://my.oschina.net/u/4471526/blog/4905944

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

在 MySQL 中是如何通过 MVCC 机制来解决不可重复读和幻读问题的？

前言接上篇文章《一文搞懂 undo log 版本链与 ReadView 机制如何让事务读取到该读的数据》，本文接下来介绍在可重复读隔离级别下，MySQL 是如何解决不可重复读和幻读问题的？本文的内容严重依赖上篇文章的知识，建议读者先阅读上篇文章。不可重复读「不可重复读现象指的是，在一个事务内，连续两次查询同一条数据，查到的结果前后不一样」。在 MySQL 的可重复读隔离级别下，不存在不可重复读的问题，那么 MySQL 是如何解决的呢？答案就是 MVCC 机制。MVCC 是 Mutil-Version Concurrent Control(多版本并发控制)的缩写，它指的是数据库中的每一条数据，会存在多个版本。对同一条数据而言，MySQL 会通过一定的手段（ReadView 机制）控制每一个事务看到不同版本的数据，这样也就解决了不可重复读的问题。假设现有一条数据，它的 row_trx_id=10，数据的值为 data0，它的 roll_pointer 指针为 null。假设现在有事务 A 和事务 B 并发执行，事务 A 的事务 id 为 20，事务 B 的事务 id 为 3...

2021-01-15

544

本文是 Android Studio 4.1 中 Profiler 有哪些新增特性的第二部分。之前的文章侧重于介绍 Android Studio 中 System Trace 的新增功能。我们从大家的反馈了解到使用 C++ 调试本地内存非常困难，尤其在开发游戏的时候。在 Android Studio 4.1 中，Memory Profiler (内存分析器) 可以记录本地内存分配的调用栈。本地内存记录基于 Perfetto 后端实现，它是 Android 的新一代性能工具和问题追溯解决方案。在调试内存问题的时候，通常的做法是搞清楚什么在占用内存，什么在释放内存。本文接下来会带着大家一起使用 Native Memory Profiler 来发现内存泄漏，并且使用 GPU 模拟压力测试 (Gpu Emulation Stress Test) 作为示例工程。准备工作首先，我们从 https://github.com/google/gpu-emulation-stress-test 克隆或者下载源码。当我们发现可疑的内存泄漏时，最好的做法是从更高的层次开始并且观察系统内存的图形。您...

2021-01-15

605

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。