资讯频道 → 移动开发
阅读更多

1顶
0踩

移动开发

原创新闻 VirtualAPK：滴滴 Android 插件化的实践之路

2016-12-27 11:15 by 副主编 jihong10102006 评论(0) 有11334人浏览
android 框架 VirtualAPK

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

引用
作者简介： 任玉刚，滴滴出行 Android 技术专家，《Android 开发艺术探索》作者，插件化框架 dynamic-load-apk 的发起者，CSDN 移动开发博客专家，曾当选 CSDN 2014、2015年度十大博客之星。热爱技术，热爱开源，凡事喜欢刨根问底，长期活跃在 CSDN 和 GitHub。目前就职于滴滴出行 App 架构组，从事热修复和插件化相关的开发工作。
博客地址：http://blog.csdn.net/singwhatiwanna；
GitHub：https://github.com/singwhatiwanna。
本文为 CSDN 首发，欢迎技术投稿、约稿，给文章纠错，请发送邮件至mobile@csdn.net。


一、前言
在 Android 插件化技术日新月异的今天，开发并落地一款插件化框架到底是简单还是困难，这个问题不同人会有不同的答案。但是我相信，完成一个插件化框架的 Demo 并不是多难的事儿，然而要开发一款完善的插件化框架却并非易事，尤其在国内，各大 ROM 厂商都对 Android 系统做了一定程度的定制，这更进一步加剧了 Android 本身的碎片化问题。

滴滴出行在插件化上的探索起步较晚，由于业务发展较快，迭代占据了大量的时间，这使得我们在2016年才开始研究这方面的技术。经过半年的开发、测试、适配和线上验证，今天，我们正式推出一款较为完善的插件化框架——VirtualAPK。之所以现在推出，是因为 VirtualAPK 在内部已经得到了很好的验证，我们在迭代过程中不断地做机型适配和细节特性的支持，目前已达到一个非常稳定的状况，足以支撑滴滴部分乃至全部业务的动态发版需求。目前滴滴出行最新版本（v5.0.4）上，小巴和接送机业务均为插件，大家可以去体验。

二、插件化的现状
到目前为止，业界已经有很多优秀的开源项目，比如早期的基于静态代理思想的 DynamicLoadApk，随后的基于占坑思想的 DynamicApk、Small，还有360手机助手的 DroidPlugin。它们都是优秀的开源项目，很大程度上促进了国内插件化技术的发展。

尽管有如此多的优秀框架存在，但是兼容性问题仍然是制约插件化发展的一大难题。一款插件化框架，也许可以在一款手机上完美运行，但是在数以千万的设备上却总是容易存在这样那样的兼容性问题。我相信上线过插件化的工程师应该深有体会。滴滴为什么还要自研一款新的插件化框架？因为我们需要一款功能完备、兼容性优秀、适用于滴滴业务的插件化框架，目前市面上的开源不能满足我们的需求，所以必须重新造轮子，于是 VirtualAPK 诞生了。

三、VirtualAPK 的诞生
VirtualAPK 是滴滴出行自研的一款优秀的插件化框架，主要有如下几个特性。
1. 功能完备
  • 支持几乎所有的 Android 特性；
  • 四大组件方面：四大组件均不需要在宿主manifest中预注册，每个组件都有完整的生命周期。
    •         （1）Activity：支持显示和隐式调用，支持 Activity 的 theme 和 LaunchMode，支持透明主题；
            （2）Service：支持显示和隐式调用，支持 Service 的 start、stop、bind 和 unbind，并支持跨进程 bind 插件中的 Service；
            （3）Receiver：支持静态注册和动态注册的 Receiver；
            （4）ContentProvider：支持 provider的所有操作，包括 CRUD 和 call 方法等，支持跨进程访问插件中的 Provider。
  • 自定义View：支持自定义 View，支持自定义属性和 style，支持动画；
  • PendingIntent：支持 PendingIntent 以及和其相关的 Alarm、Notification 和AppWidget；
  • 支持插件 Application 以及插件 manifest 中的 meta-data；
  • 支持插件中的so。
2. 优秀的兼容性
  • 兼容市面上几乎所有的 Android 手机，这一点已经在滴滴出行客户端中得到验证；
  • 资源方面适配小米、Vivo、Nubia 等，对未知机型采用自适应适配方案；
  • 极少的 Binder Hook，目前仅仅 hook 了两个 Binder：AMS 和 IContentProvider，Hook过程做了充分的兼容性适配；
  • 插件运行逻辑和宿主隔离，确保框架的任何问题都不会影响宿主的正常运行。
3. 入侵性极低
  • 插件开发等同于原生开发，四大组件无需继承特定的基类；
  • 精简的插件包，插件可以依赖宿主中的代码和资源，也可以不依赖；
  • 插件的构建过程简单，通过Gradle插件来完成插件的构建，整个过程对开发者透明。
四、VirtualAPK 的工作过程
VirtualAPK 对插件没有额外的约束，原生的 apk 即可作为插件。插件工程编译生成 apk 后，即可通过宿主 App 加载，每个插件 apk 被加载后，都会在宿主中创建一个单独的 LoadedPlugin 对象。如下图所示，通过这些 LoadedPlugin 对象，VirtualAPK 就可以管理插件并赋予插件新的意义，使其可以像手机中安装过的App一样运行。


1. VirtualAPK 的运行形态
我们计划赋予 VirtualAPK 两种工作形态，耦合形态和独立形态。目前 VirtualAPK 对耦合形态已经有了很好的支持，接下来将计划支持独立形态。
  • 耦合形态：插件对宿主可以有代码或者资源的依赖，也可以没有依赖。这种模式下，插件中的类不能和宿主重复，资源 id 也不能和宿主冲突。这是 VirtualAPK 的默认形态，也是适用于大多数业务的形态。
  • 独立形态：插件对宿主没有代码或者资源的依赖。这种模式下，插件和宿主没有任何关系，所以插件中的类和资源均可以和宿主重复。这种形态的主要作用是用于运行一些第三方 apk。
2. 如何使用
第一步： 初始化插件引擎

第二步：加载插件

我们对上述加载过程进行了一些封装，通过如下方式即可异步地去加载一个插件。

当插件入口被调用后，插件的后续逻辑均不需要宿主干预，均走原生的 Android 流程。比如，在插件内部，如下代码将正确执行：


五、探究原理
1. 基本原理
  • 合并宿主和插件的ClassLoader：需要注意的是，插件中的类不可以和宿主重复；
  • 合并插件和宿主的资源：重设插件资源的packageId，将插件资源和宿主资源合并；
  • 去除插件包对宿主的引用：构建时通过 Gradle 插件去除插件对宿主的代码以及资源的引用。
2. 四大组件的实现原理

  • Activity：采用宿主 manifest 中占坑的方式来绕过系统校验，然后再加载真正的 Activity；
  • Service：动态代理 AMS，拦截 Service 相关的请求，将其中转给一个虚拟空间（Matrix）去处理，Matrix 会接管系统的所有操作；
  • Receiver：将插件中静态注册的 Receiver 重新注册一遍；
  • ContentProvider：动态代理 IContentProvider，拦截 Provider 相关的请求，将其中转给一个虚拟空间（Matrix）去处理，Matrix 会接管系统的所有操作。
以下是 VirtualAPK 的整体结构图。

六、填坑之路
在实践中我们遇到了很多很多的问题，比如机型适配、API 版本适配、Binder Hook 的稳定性保证等问题，这里拿一个典型的资源适配问题来说明。

其实这是一个很无奈的问题，由于国内各大 ROM 厂商喜欢深度定制 Android 系统，所以就出现了这种适配问题。

正常情况下我们通过如下代码去创建插件的 Resources 对象：

然后在 Vivo 手机上，竟然出现了如下的类型转换错误，看起来是 Vivo 自己派生了 Resources 的子类。

于是反编译了下 Vivo 的 Framework 代码，果不其然，在如下代码中进行了类型转换，所以在加载插件资源的时候就报错了。

为了解决这个问题，我们分析了 VivoResources 的代码实现，然后在创建插件资源的时候，采用了如下的代码。

除了 Vivo 以外，有类似问题的还有 MIUI、Nubia 以及其他不知名的机型。而且在 Vivo 手机上，除了类型转换错误的问题，还有其他很坑的问题。

事实上我们还处理了很多其他的坑，这里无法一一说明，所以说如何保证插件化的稳定性是一件很有技术挑战的事情。

七、一些暂时不支持的特性
由于种种原因，VirtualAPK 目前未能支持所有的 Android 的特性，已知的有如下几点：
  • 不支持 Activity 的部分属性，比如 process、configChanges 等；
  • 暂不支持 overridePendingTransition(int enterAnim, int exitAnim) 这种形式的转场动画；
  • 插件中弹通知，不能使用插件中的资源，比如图片。
八、开源计划
我们的目标是打造一款功能完备的插件化框架，使得各个业务线都能以插件的形式集成，从而实现 Android App 的热更新能力。

目前 VirtualAPK 还有一些特性需要进一步完善，待完善后，将会进行开源计划。我们期望 VirtualAPK 开源后，可以让其他 App 能够无缝集成，无需考虑细节实现和兼容性问题即可轻松拥有热更新能力。

了解最新移动开发相关信息和技术，请关注 mobilehub 公众微信号（ID: mobilehub)。

  • 大小: 95.6 KB
  • 大小: 7.1 KB
  • 大小: 6.5 KB
  • 大小: 18.7 KB
  • 大小: 24.4 KB
  • 大小: 22 KB
  • 大小: 79.8 KB
  • 大小: 4.5 KB
  • 大小: 61.4 KB
  • 大小: 14.8 KB
  • 大小: 18.1 KB
1
顶
0
踩
评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 数据仓库和olap

    Data warehousing and on-line analytical processing (OLAP) are essential elements of decision support, which has increasingly become a focus of the database industry. Many commercial products and services are now available, and all of the principal database management system vendors now have offerings in these areas. Decision support places some rather different requirements on database technology compared to traditional on-line transaction processing applications. This paper provides an overview of data warehousing and OLAP technologies, with an emphasis on their new requirements. We describe back end tools for extracting, cleaning and loading data into a data warehouse; multidimensional data models typical of OLAP; front end client tools for querying and data analysis; server extensions for efficient query processing; and tools for metadata management and for managing the warehouse. In addition to surveying the state of the art, this paper also identifies some promising research issues, some of which are related to problems that the database research community has worked on for years, but others are only just beginning to be addressed. This overview is based on a tutorial that the authors presented at the VLDB Conference, 1996.

  • 数据仓库与数据库（OLAP与OLTP）

    数据仓库是一个面向主题的，集成的，时变的，非易失的数据集合，支持管理者的决策过程，决策支持系统（DSS）和联机分析应用数据源的结构化数据环境，数据仓库研究和解决从数据仓库中获得信息的问题。数据仓库存在的意义在于对企业的所有数据进行汇总，为企业各个部门提供统一的，规范的数据出口。 面向主题：数据仓库中的数据按照一定的主题进行组织，每一个主题对应一个宏观的分析领域，数据仓库排除对于决策无用的数据，提供特定主题的简明视图。 集成的：企业内不同业务部门数据的完整集成，对于企业内所有数据的集成要注意一致性。 稳

  • 简述数据仓库、OLAP、数据挖掘之间的关系

    （1）数据仓库是基础：无论是数据挖掘还是OLAP分析，他们成功的关键之一是能够访问正确的、完整的和集成的数据。这也是对数据仓库的要求。数据仓库不仅是集成数据的一种方式和一个焦点，而且所有的数据仓库的解决方案都源自和依赖于数据源部件的质量和效果(这种部件在数据仓库中称为抽取、变换和装载)。数据仓库的特点（集成的、随时间变化、稳定的、面向主题的）为OLAP分析、数据挖掘的成功提供了坚实的数据基础。（2...

  • 数据仓库—什么是OLAP

    从事数据仓库或者大数据的同学，应该经常会听到OLAP这个词。什么OLAP分析，OLAP引擎等等名词。今天就来聊聊什么是OLAP。 OLAP与OLTP 说起OLAP，就不得不提一下他的好兄弟OLTP，两者经常会被拿来比较。 首先，看一下两者的 定义： OLAP（On-Line Analytical Processing）：联机分析处理，OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 OLTP（on-line transaction processi

  • 数据挖掘—— 数据仓库和数据挖掘的OLAP技术

    数据仓库后端工具主要指的是用来装入和刷新数据的工具，包括： 数据提取：从多个外部的异构数据源收集数据 数据清理：检测数据中的错误并作可能的订正 数据变换：将数据由历史或主机的格式转换为数据仓库的格式 装载、排序、汇总、合并、计算视图，检查完整性。 并建立索引和分区 刷新 将数据源的更新传播到数据仓库中 数据仓库只需要两种数据访问： 数据的初始装载 数据访问 传统的异构数据库集成在多个异构数据库上建立包装程序和中介程序 度量可以根据其所用的聚集函数分为三类： 分布的：将函数用于n个聚集值得到的结果和将函数用于

  • 数据仓库、OLAP和 数据挖掘、统计分析的关系和区别分析

    一、什么是数据挖掘 　　数据挖掘(Data Mining)，又称为数据库中的知识发现(Knowledge Discovery in Database, KDD)，就是从大量数据中获取有效的、新颖的、潜在有用的、最终可理解的模式的非平凡过程，简单的说，数据挖掘就是从大量数据中提取或“挖掘”知识。   二、数据挖掘相关的10个问题  　 NO.1 Data Mining 和统计分析有

  • BI(数据仓库、OLAP、数据挖掘)

    数据仓库将来自于各种数据源的数据，根据不同的主题进行存储，并对原始数据进行抽取、转换和加载等一系列筛选和清理工作。OLAP则将数据通过多维视角和多种层次向用户进行多方式的呈现。数据挖掘则应用不同的算法，向用户揭示数据间的规律性，从而辅助商业决策。

  • 数据仓库，olap与数据挖掘之间的关系

    要说明他们的关系，不得不说说商务智能。从技术角度看，商务智能的过程是企业的决策人员以企业中的数据仓库为基础，经由联机分析处理工具、数据挖掘工具加上决策规划人员的专业知识，从数据中获得有用的信息和知识，帮助企业获取利润。      数据仓库是一个用以更好地支持企业或组织的决策分析处理的的数据集合，它有面向主题、集成、相对稳定、随时间不断变化四个特性，将数据仓库与传统的面向事务处理的数据库区分开来。数

  • OLAP 和 数据挖掘的区别

    总结来说： 数据仓库提供了一个分析的数据源数据挖掘能分析出未知的信息，提出假设OLAP能通过分析，验证假设 从技术角度看，商务智能的过程是企业的决策人员以企业中的数据仓库为基础，经由数据挖掘工具、联机分析处理工具加上决策规划人员的专业知识，从数据中获得有用的信息和知识，帮助企业获取更多的利润。       数据仓库是一个用以更好地支持企业或组织的决策分析处理的的数据集合，

  • OLAP与数据挖掘的区别

    大多数同事都曾做过OLAP相关的项目，他们常搞不清OLAP与数据挖掘有什么区别，现摘录一段文字来说明   所谓OLAP（Online Analytical Process）意指由数据库所连结出来的在线分析处理程序。有些人会说：「我已经有OLAP的工具了，所以我不需要Data Mining。」事实上两者间是截然不同的，主要差异在于Data Mining用在产生假设，OLAP则用于查证假设

  • 数据仓库与OLAP技术概述

    总述：这部分主要介绍数据挖掘的实现问题，重点关注数据的组织形式、系统框架、相关的设计和名词介绍。不会涉及到非常具体的应用项目，可以当做基础知识科普。 什么是数据仓库 联机事务处理系统（OLTP）和联机分析处理系统（OLAP）的区别有哪些 多维数据模型的建立 如何设计和构造数据仓库 三层数据仓库结构的案例 数据仓库后端工具应该提供的能力要在什么范围内 元数据存储库是什么 OLA...

  • 二、数据仓库和数据挖掘的OLAP技术

    数据仓库和数据挖掘的OLAP技术引言一、什么是数据仓库二、数据仓库的关键特征2.1、面向主题2.2、数据集成2.3、随时间而变化2.4、数据不易丢失三、数据仓库的构建和使用四、数据仓库与操作数据库系统五、多维数据模型 引言 数据仓库中的数据清理和数据集成，是数据挖掘的重要数据预处理步骤 数据仓库提供OLAP工具，可用于不同粒度的数据分析 很多数据挖掘功能都可以和OLAP操作集成，以提供不同概念层上的知识发现 分类 预测 关联 聚集 一、什么是数据仓库 数据仓库的定义很多，但却很难有一种严格的定义：

  • 联机分析处理（OLAP）与数据挖掘的关系

    联机分析处理(OLAP)是用来分析数据仓库中海量数据的技术。它的核心概念是“维”，它支持数据分析人员和决策人员从不同的角度、不同的级别地对数据仓库中的数据进行复杂查询和多维分析处理，并且能以直观形象的形式将查询和分析结果展现给分析和决策人员。OLAP使用的逻辑数据模型为多维数据模型。它主要用于分析大量历史数据，提供汇总和聚集机制，访问大部分是只读操作。这不同于OLTP中频繁的更新修改数据。数据

  • 关系型数据库横向扩展的三种方法

    本文是 Oracle Coherence 3.5一书，第一章: Achieving Performance, Scalability, and Availability Objectives，第二节：Achieving scalability中，数据库横向扩展部分的读书笔记。传统的关系型数据库很难扩展，通常是纵向扩展，但到达一定程度时只能横向扩展。数据库的横向扩展支持三种方法，即主从复制，集群和分片

  • 关系型数据库与分布式数据库

    关系型数据库 当前主流的关系型数据库有Oracle、DB2、PostgreSQL、Microsoft SQL Server、Microsoft Access、MySQL 关系数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。 关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。 关系型数据库将数据存储在硬盘中 注： 数

  • 数据仓库（OLAP OLTP）与数据挖掘

    一、挖掘数据存在问题： 1、把来自各个数据源的数据汇集到一个中心仓库中，即数据仓库。数据仓库位于一个单独的节点上，使用同一的模式从多个数据源收集数据，给用户提供一个单独的、统一的数据接口，目的是能在不同的数据上高效执行查询。       数据仓库处理相关问题：脏数据处理（某些带有错误的数据）技术，对大量数据的高效存储和索引技术 2、分析收集到的数据发现可以成为商务决策基础的信息或知识。 数...

  • 从“分析”的角度谈OLAP、数据挖掘、统计分析三者之间的区别和联系

            近来一直在考虑基于OLAP的分析、数据挖掘里的挖掘分析、统计业务中的统计分析相互间的内在关系，因为乍看上去这三者是非常相似的，很容易混在一起。事实上，他们之间还是有很大的区别。        首先谈谈OLAP中的分析，由于OLAP的核心是对多维数据集的处理，构建数据立方体，对数据立方体进行切片、切块、上卷、下钻等操作，达到比对分析的目的，同时建立数据立方体的过程也是对数据进行聚合汇

  • OLAP、OLTP的介绍和比较

    OLTP与OLAP的介绍     数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易

Global site tag (gtag.js) - Google Analytics