1613人阅读
Android 开发技术（3）
最近项目中，有些子功能需要按需加载，于是考虑使用插件化方案实现，看过几个插件化方案后，最终选择了360之前开源的DroidPlugin方案。
在使用中，还是有一些心得体会，网上的源码分析，详细原理分析的文章一经很多（文末会有链接），本篇文章，主要从使用的角度入手，简单描述下DroidPlugin原理，也记录下使用中心得体会。
阅读了部分DroidPlugin的源码，也看了部分网上的文章和android组件启动过程的分析。对于此插件化框架的基本的原理，个人理解如下：
插件化目的是为了从宿主中，启动插件中组件，不是同一个应用，也不是同一个进程，如果按照android原有的机制运行API，中途必然不能运行下去。
为了实现这种特殊的目的，插件化框架中Hook了大量系统的API, 通过改写入参，返回值的方式，使得API的行为发生变化，绕过系统部分规则和检查，完成组件加载，功能实现等。
简单描述下Hook的思路，顾名思义，就是像钩子一样，将程序段中的部分代码挂住，之后，改写程序段的部分行为。
通过Java的动态加载机制，在结合反射，就能实现hook的大致功能。
最终通过实现 InvocationHandler 接口中的 invoke 方法，达到改写某些系统原生api的行为。而通过反射，可以在运行时，动态改写部分类或者方法的如参，配合被改写的api共同实现，绕过系统系统限制，加载插件的目的。
框架使用心得
在使用DroidPlugin框架过程中，还是有部分心得体会，简要记录下，插件化框架的原理十分复杂，但是如果简单使用的话，从API调用层面来看，其实并不是很复杂。
首先是插件初始化的过程，在这流程中，主要完成插件化框架，加载到宿主APP上，安装了所有的hook等操作。
PluginHelper.getInstance().applicationOnCreate(getBaseContext())
PluginHelper.getInstance().applicationAttachBaseContext(base)
下面这两个API, 是需要在宿主APP, 启动组件前需要调用的，和框架里使用了AIDL方式进行交互，所有要使用各种API, 首先要创建服务的连接。
PluginManager.getInstance().isConnected()
PluginManager.getInstance().addServiceConnection(mServiceConnection)
这三个API, 是处理插件包相关的常见API，安装的过程，其实是把插件包的信息，写入到插件化框架中，专门为维护插件相关的信息的一段数据结构中，后续的get流程，和删除流程，实际上都是对这个数据结构作操作。
PluginManager.getInstance().installPackage(item.apkFile, 0)
PluginManager.getInstance().getInstalledPackages(0)
PluginManager.getInstance().deletePackage(item.packageInfo.packageName, 0)
这边需要特别注意，官方文档中的一个提示，插件框架中的 manifest 文件中 provider 的 authorities 一定要记得修改，不然真的会引起冲突。
All provider's authorities value in DroidPlugin's Libraries\DroidPlugin\AndroidManifest.xml default to be com.morgoo.droidplugin_stub_P00, e.g. :
android:name="com.morgoo.droidplugin.stub.ContentProviderStub$StubP00"
android:authorities="com.morgoo.droidplugin_stub_P00"
android:exported="false"
android:label="@string/stub_name_povider" /&
You'd better change it to avoid conflict with other instances, e.g.:
android:name="com.morgoo.droidplugin.stub.ContentProviderStub$StubP00"
android:authorities="com.example.droidplugin_stub_P00"
android:exported="false"
android:label="@string/stub_name_povider" /&
and change PluginManager.STUB_AUTHORITY_NAME to your value:
PluginManager.STUB_AUTHORITY_NAME="com.example.droidplugin_stub"
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：12530次
排名：千里之外
原创：12篇
(3)(4)(1)(2)(1)(2)如何评论 360 开源的 Android 插件机制 Droid Plugin? - 知乎848被浏览35219分享邀请回答294 条评论分享收藏感谢收起//解决小米JLB22.0 4.1.1系统自带的小米安全中心（lbe.security.miui）广告拦截组件导致的插件白屏问题
private void fuckMiUiLbeSecurity()
---------------------华丽丽的分割线---------------------抖机灵获得这么多赞，谢谢大家。很能理解作者起这个方法名的心情，也很庆幸作者很快修改了这个名字，详见
，当然最应该感谢作者的开源精神，希望该项目越来越好用，再次感谢。7213 条评论分享收藏感谢收起更多6 个回答被折叠（）安卓进入“全面插件化”时代 360宣布RePlugin将开源
在安卓开发领域，有关插件化的讨论一直热度不减。目前市面上的插件化方案虽然很多，但多数只能实现某些功能的插件化，距离开发者的预期尚有相当差距。对此，在近期GMTC全球移动技术大会上，360手机卫士主程序架构负责人张炅轩宣布，360的插件化框架RePlugin已经可以实现&全面插件化&，同时具有出色的稳定性和灵活性，可适用于各种类型的应用上。
&RePlugin预计7月份开源，这将是我们献给安卓世界最好的礼物。&此言一出，引发全场沸腾。
图1:360手机卫士张炅轩在GMTC上宣布插件化方案将开源
三大因素制约& 使用插件化的开发者不足5%
安卓应用插件化的优势众所周知，然而张炅轩在GMTC上的调查结果却让人大跌眼镜。在参会200多位安卓开发者中，仅有不足5%的比例，使用了插件化方案。超过九成的开发者，目前上没有将插件化应用在软件开发之中。
360手机卫士通过各渠道的调查发现，有三大挑战制约了插件化在安卓开发界的普及。
首先是不够稳定。目前有很多比较灵活的插件化框架，虽然支持特性众多，但因Hook点较多，所以不是非常稳定。因此很多大型项目不是很愿意用它们来开发插件，担心出现应用崩溃、插件无法正常使用等问题。
其次是不够灵活，有一些相对稳定的插件化框架，又存在&不够灵活、自由&的问题，一旦插件有特别大的改动，如新增一个Activity、Service、进程等，就需要主程序发版，更不用说能做到&一年前的主程序，无需升级，可以用新插件和组件&的目标了。
最后就是插件化框架仅在功能丰富的大型项目中，才被考虑使用，且多用于边缘功能。目前几乎所有App在使用插件化框架时，都是将自己的一些&比较边缘的&模块作为插件，比如&红包&、&天气&、&摇一摇&等，他们认为只有&非核心&模块，才会考虑做成插件。这也使得插件化的应用范围非常狭窄。
总而言之，现在很多市面上插件化方案，没有很好解决稳定、灵活和自由等方面的问题，因此始终没有被广泛使用。
将Hook点降低为1& &让&核心功能皆为插件&
&只有让核心功能实现全面插件化，才能真正让插件化方案走向普及&，张炅轩在GMTC表示，&要实现这个目标，必须先实现优异的稳定性，继而确保出色的灵活性。&
据介绍，360手机卫士团队早在2013年，就推出了卫士插件化框架，在2014年又发布了卫士完整占坑方案，2016年实现了&核心功能皆为插件&的目标，并将其命名为RePlugin。在整个过程中，卫士团队很好解决了&稳定&和&灵活&的平衡难题，破解了&只有功能丰富的项目才用&的&魔咒&，目前已经有数亿台设备使用了卫士的插件化方案。
在稳定性方面，RePlugin的Hook点只有一处：ClassLoader，这使得框架崩溃率仅为万分之一。而在灵活性方面，由于RePlugin采用了全新、独创的&分层坑位方案&，加上一些其它独创新特性，如多进程坑位、Task-Affinity坑位等，从而真正实现了插件组件任意增改、新插件直接用、无须主程序发版、自有设置进程等特性，而独创的&动态编译方案&，能极大的提高插件开发者的研发效率，真正做到&只需几行代码，就能&秒变&插件&的神奇效果。
图2：卫士RePlugin各项指标全面领先行业
值得一提的是，手机卫士团队将业界公认非常复杂的桌面应用，变成了插件，在卫士插件化框架中完美的运行，且能做到非常出色的稳定和灵活。这让在场嘉宾倍感惊叹，充分体现了RePlugin插件化方案的领先优势。
多个亿级APP已采用 &&RePlugin预计七月开源
截止目前，RePlugin的插件数已达102个，核心基础插件57个，而插件占应用比更是达到了惊人的83%，而且年发版次数高达596次，平均每个工作日发版2-3次。目前360公司几乎所有的亿级用户量的APP，以及多款主流第三方APP，都采用了卫士RePlugin插件化方案。为了让更多第三方应用享受到插件化方案带来的便利，张炅轩在GMTC2017上正式宣布，将对RePlugin实现全面开源，并将此称为&献给安卓世界的最好礼物&。
图3: RePlugin插件占应用比达到83%
作为国内市场占有率最大、累计拥有10亿用户的手机端安全防护软件，360手机卫士近年来不断在提升用户体验方面发力，在夯实清理加速、骚扰拦截、软件管理、手机杀毒这些核心功能之外，在插件化开源等领域一直在深入探索，最终推出了兼顾稳定和灵活、更加成熟可靠的RePlugin方案。本次宣布代码开源，对安卓开发无疑具有非常深远的意义，对于广大APP 开发者无疑是一个福音。分析人士认为，这将在安卓界掀起一场&全面插件化&的趋势，让众多应用从RePlugin的开源中受益。
GMTC全球移动技术大会是由InfoQ主办的全球顶级技术盛会。大会关注移动、前端、跨平台、AI应用等多个技术领域，旨在促进全球技术交流，推动国内技术升级，目前正成为面向移动开发、前端、AI技术人员，聚焦前沿技术及实践经验，打造技术人员的学习和交流平台。360手机卫士团队此次的分享引来与会者一致赞誉。 &
官方微博/微信
每日头条、业界资讯、热点资讯、八卦爆料，全天跟踪微博播报。各种爆料、内幕、花边、资讯一网打尽。百万互联网粉丝互动参与，TechWeb官方微博期待您的关注。
↑扫描二维码
想在手机上看科技资讯和科技八卦吗？想第一时间看独家爆料和深度报道吗？请关注TechWeb官方微信公众帐号：1.用手机扫左侧二维码；2.在添加朋友里，搜索关注TechWeb。
相关的资讯有：
相关的博文有：
和OPPO R11一样，小米在新机5X未发布（7月26日发布）之前就已全面曝光了这款产品的外...
iPhone 8的量产工作能否顺利展开，是很多用户最关注的，毕竟外形大改的它，是今年大家...
前不久有人在网络上曝光了一款金属拉丝后壳的魅族Pro 7手机谍照，不过这张照片引起了...
北京时间7月19日早间消息，亚马逊旗下AWS云计算服务周四发布的新版客户协议显示，该公...
“最主要的是，从我的角度来说，现在给乐视网选择什么样的合作伙伴。要么我干，要么我...
苹果芯片代工商台积电公布了公司未经审计的2017年第二季度财报。财报显示，台积电第二...
Windows 10创意者更新定于下半年推送，目前传言其版本号为version 1709，预计最快8月...
Firefox火狐浏览器这两年不怎么流行了，但是Mozilla也一直在不断改进完善它，而最新版...
7 月 24 日消息，今天“巨石”道恩·强森（Dwayne Johnson）宣布，将与苹果合作，与...
阴阳师夏日祭新装情报:四位大人已经迫不及待地换上了夏日祭新装赶赴京都夏夜的花火之......
暖暖环游世界四周年庆典即将开启！同步页游新套装推出，下面就为大家带来暖暖环游世界......
帅气又强力的男偃师登场后备受好评，如今，天工阁的第二位角色——女偃师阮烟罗也将隆......
夜雾迷城活动2月22日5:00—2月28日23:59，本次活动新增套装黎明之冠新月之吻，下面为......
Copyright (C)
All rights reserved.
请选择一张图片分享
要转发到新浪微博，请
要转发到QQ空间，请运行效果：
使用说明：
RePlugin是一套完整的、稳定的、适合全面使用的，占坑类插件化方案。其主要优势有：极其灵活：主程序无需升级（无需在Manifest中预埋组件），即可支持新增的四大组件，甚至全新的插件非常稳定：Hook点仅有一处（ClassLoader）。其崩溃率仅为“万分之一”，并完美兼容市面上近乎所有的Android ROM特性丰富：支持近乎所有在“单品”开发时的特性。包括静态Receiver、Task-Affinity坑位、自定义Theme、进程坑位、AppCompat、DataBinding等易于集成：无论插件还是主程序，只需“数行”就能完成接入进程任意：可让各组件跑在UI、常驻，甚至是“任意坑位进程”自由隔离：想隔离就隔离（如不稳定或占资源的插件，易于释放），不想隔离的模块就混用（如各种基础、UI插件，都跑在UI进程内，性能优异）管理成熟：拥有成熟稳定的“插件管理方案”，支持插件安装、升级、卸载、版本管理，甚至包括进程通讯、协议版本、安全校验等数亿支撑：有360手机卫士庞大的数亿用户做支撑，三年多的残酷验证，确保App用到的方案是最稳定、最适合使用的截止2017年6月底，RePlugin的：插件数 已达102个（其中，核心插件57个）插件占应用比 高达83%（指把代码资源铺开，插件占整个应用的比例）年发版次数 高达596次（平均每个工作日发版2-3次）目前360公司几乎所有的亿级用户量的APP，以及多款主流第三方APP，都采用了RePlugin方案。支持Android 2.3+及以上版本有关RePlugin的详细介绍，请。使用方法RePlugin的使用方法非常简单，大部分情况下和“单品”开发无异。若您是第一次接触RePlugin，则，跟随我们的指引，了解更多的内容。若您想了解更多有关RePlugin的玩法，则，了解更多好玩的玩法。若您想看下RePlugin的Sample工程，进而了解框架的具体用法，则。已接入RePlugin的插件目前已有的插件，可以分为以下几类，供各App开发者参考：展示插件：如卫士首页（是的，你没看错）、体检、信息流等业务插件：如清理、骚扰拦截、悬浮窗等合作插件：如程序锁、免费WiFi、安全桌面等后台插件：如Push、服务管理、Protobuf等基础插件：如安全WebView、分享、定位等截止2017年6月底，这样的插件，我们有102个。衷心希望您能成为这个数字中的新的一员！阅读正文 :
360手机卫士插件化RePlugin宣布开源
GitHub地址：/Qihoo360/RePlugin。
&RePlugin将在6月底开源，这将是我们献给安卓世界最好的礼物。&当我们宣布这一消息时，心中的激动，无以言表。是的，三年的&厚积&，如今的&薄发&，看似平凡的话，实际上却饱含了我们太多的激动、辛酸与泪。
那么今天，我们就来详细的和您聊一聊，这个从2014年中旬，正式在卫士上启用，并即将开源的360 RePlugin，究竟能为我们，更为您能带来什么。
欢迎您为RePlugin项目加Star、发送PullRequest，提Issue。我们会竭尽所能回答您们的疑惑。
RePlugin是什么
RePlugin是一套完整的、稳定的、适合全面使用的，占坑类插件化方案。其主要优势有：
极其灵活：主程序无需升级(无需在Manifest中预埋组件)，即可支持新增的四大组件，甚至全新的插件
非常稳定：Hook点仅有一处(Classloader)。其崩溃率做到仅为&万分之一&，并完美兼容市面上近乎所有的AndroidROM。
特性丰富：支持近乎所有在&单品&开发时的特性，包括静态Receiver、Task-Affinity、自定义Theme、进程坑位、AppCompat等
进程任意：可让各组件跑在UI、常驻，甚至是&任意坑位进程&
易于集成：无论插件还是主程序，只需&数行&就能完成接入
自由隔离：想隔离就隔离(如不稳定或占资源的插件，易于释放)，不想隔离的模块就混用(如各种基础、UI插件，都跑在UI进程内，性能优异)
管理成熟：拥有成熟稳定的&插件管理方案&，支持插件安装、升级、卸载、版本管理，甚至包括进程通讯、协议版本、安全校验等
数亿支撑：有360手机卫士庞大的数亿用户做支撑，三年多的残酷验证，确保App用到的方案是最稳定、最适合使用的
截止2017年6月底，RePlugin的：
插件数已达102个(其中，核心基础插件57个)
插件占应用比(指把代码资源铺开，插件占整个应用的比例)高达83%
年发版次数高达596次(平均每个工作日发版2-3次)
此外，目前360公司几乎所有的亿级用户量的APP，以及多款主流第三方APP，都采用了RePlugin方案。
总而言之，您们现在看到的RePlugin，可以说是&久经沙场&、&历经风雨&的方案，是在数亿设备上，历经三年多时间验证的成熟方案，也是可以直接拿来为您们所用的，稳定与灵活兼得的方案。
(RePlugin的核心优势)
(RePlugin与现有插件化框架的对比)
为什么要做RePlugin
插件化的好处
在讲述我们团队为何要在2013年底，设计一套属于自己的插件化之前，我们先来简单谈谈，有了插件化方案后，能为我们带来多大的便利，它究竟解决了什么问题。
对于用户而言
一切按需：利用插件化方案，可以让您的应用变得&小而精&。只有当用户需要使用某个特定功能时，才可以下载并开启，且可以随时卸载插件。这不仅可以减小APK大小、节省流量，还可明显的减少内存、内部存储占用，将更多空间让给珍贵的相片、文档等资料
随时体验新版：不用去应用市场等到大包升级，用户可以随时体验到新版的应用。现在红极一时的插件化、动态化(RN类)、热更新技术，都或多或少的在围绕此点而展开，可见其对用户带来的巨大价值
对于开发者而言
发版灵活：不用等市场上线，等用户主动升级，结果错过宝贵的时机。插件化方案可让您做到&随时发版&，不受&发版窗口期&的限制。甚至可针对不同地域、不同用户群、不同时段来更新，且可以快速验证自己的构想
组织结构灵活：一旦发版变得足够灵活，则组织结构上就可以由原来的&统一作战&变成&百团作战&，每个团队都在开发&自己的插件单品&，制定自己的发版计划
模块思维：可以让团队形成&模块意识&。当然，插件间、插件与宿主间允许有适度的耦合，但不会是&毫无控制&的那种。这让开发者们意识到，我们之间是&插件间的协定&，而非&同一屋檐下，随便胡来&，迫使团队以全新又合适的方式来开发应用
Android原生优势：和动态化(RN类)不同，您可以使用最熟悉的Java/Kotlin语言，及各种原生API来开发您的插件。这使得应用能和系统更&契合&，充分利用原生的各种优势，且在性能上几乎感受不到影响
如上所述，无论是对用户，还是对开发者而言，使用插件化框架都是大有益处的，理应做到&飞入寻常应用家&。
然而，在实际调查过程中，我们却发现了一个和这些好处完全不匹配的奇怪现象。究竟是什么呢?
既然插件化这么好，为什么&&
虽然我事先已做好功课，然而在GMTC上的调查结果却让人大跌眼镜&&在参会的200多位安卓开发者中，仅有不足5%的比例，使用了插件化方案。超过九成的开发者，目前上没有将插件化应用在软件开发之中。
实际上，这和我们在线下观察到的结果基本吻合。结合之前的调查，我们发现，有三大挑战制约了插件化在Android开发界的普及：
不够稳定：目前有很多比较灵活的插件化框架，虽然支持特性众多，但因Hook点较多，所以不是非常稳定。因此很多大型项目不是很愿意用它们来开发插件，担心出现应用崩溃、插件无法正常使用等问题。
不够灵活：有一些相对稳定的插件化框架，又存在&不够灵活、自由&的问题，一旦插件有较大改动，如新增Activity、Service、进程等，就需要主程序发版，更不用说能做到&一年前的主程序，无需升级，可以用新插件和组件&。也因此，很多项目的&接入动机&也就大打折扣了。
功能丰富项目专用：目前市面上的插件化方案，大多仅在功能丰富的大型项目中，才被考虑使用，且多用于边缘功能，比如&红包&、&天气&、&摇一摇&等，他们认为只有&非核心&模块，才会考虑做成插件。这也使得插件化的应用范围非常狭窄。
然而，通过我们多年的实践证明，以上三大挑战，其实是可以被攻克的。这也是我们今天要为您介绍的，360手机卫士首款Android开源项目&&RePlugin。
既然这么大胆，那么，我们究竟是怎么做到的呢?
我们是怎么做的
&不够稳定&怎么破?
前文提到，不够稳定的主要原因是Hook了太多。那么市面上比较灵活的插件化框架，究竟Hook了哪些呢?
注意：这里所说的&Hook&是指通过Java反射手段，获取并修改与系统Server等交互的InternalAPI，来让框架正常工作的行为，如上面所列部分。正常情况下的反射(例如反射类内部自己的字段)不属于Hook。
看似灵活，然而下列三种情况，将很有可能导致插件甚至应用，彻底不能工作：
Android升级：既然是内部API，那么Android自然不会认为是&不能修改的&，一旦系统升级时做了改动，轻则功能不正常，重则直接Crash。例如有的插件化框架曾遇到在Android 7.0上出现异常，必须升级主程序才能解决的事故，历历在目。
ROM修改：比Android升级更可怕的，是第三方ROM对内部API的&各种改&。这个适配难度是可想而知的。例如自定义Resource、自定义WiFiService等造成的&插件化血案&，不一而足。
使用不当：&常在河边站，哪有不湿鞋&，Hook的点多了，一旦对某一点的实现原理理解不透而出了错。结果，前功尽弃不说，还可能出现更严重，且更难以察觉的崩溃事故，细思恐极。
基于上述的情况，我们团队在2014年初，研究全新占坑插件化框架(注意，此时DroidPlugin类方案还没有出现)时，就定了个&小目标&：让Hook越少越好。经过一次次的研究讨论，最终确定只Hook一个点：ClassLoader，且要求&坚持到底&，所有改动都是基于此来展开。
对我们而言，这是里程碑式的决定，即便到现在来看也是如此。
唯一Hook&&ClassLoader
修改ClassLoader的点其实不难，如上图所示逐步反射即可。然而需要注意的是，这个ClassLoader一定得继承自PathClassLoader，防止Android 7.x因使用addDexPath而有问题。
除此之外，此ClassLoader所在位置也非常稳定。目前来看，从Android 2.1至今都没有发生过位置、名称上的变化，可以长期使用。
关于这一点，我们之后会有一篇文章来详述，敬请期待。
&不够灵活&怎么破?
前文提到，就目前市面上的插件化框架而言，若做的足够稳定，则多少会失去一些灵活性。对于我们拥有这么多模块的产品而言，这同样也是不可接受的。
为此，我们在&坚持一个Hook点&原则的前提下，通过不断创新，最终解决了上述问题。
我们的核心思路，是2015年以后才开始&老生常谈&的一个词，那就是：坑位。
坑位方案思想
非坑位方案：标准的一一对应关系。例如，插件有个XXXActivity，那么主程序则要求必须也有个XXXActivity(名字未必一样)来对应。
一旦插件要添加一个新的Activity，则对应的，主程序也必须得添加，否则就无法使用这个Activity。
准坑位方案：有的(如2013年的我们)会通过Fragment来模拟Activity，从而实现一定程度上的灵活。
然而真的遇到大需求，如和其它应用Activity的交互等，就局限百出，很难称得上是完整坑位思想。
坑位方案：可以做到&一对多&的关系。例如插件有个XXXActivity，则运行时，主程序可以将自己的N1ST1对应到这个XXXActivity上。一旦该Activity退出，则N1ST1就&空闲&出来。而当YYYActivity进来后，又会重新占用N1ST1。这样就可以做到一个坑位(如N1ST1)对应多个实体。
此外，这个YYYActivity既可以是已有的，也可以是插件新增的。这样无论插件如何升级，主程序都可以不用动，即可支持新的Activity。
当然，我们当初设计坑位思想(恕我再强调，是2014年初)时，也绝不仅仅针对Activity，而是整个四大组件，甚至到了后期，连Theme、进程、Task-Affinity等都做到了&坑位化&，只不过实现方式各异而已。
因篇幅所限，这里仅以常用的Activity来简述。有关更详细的内容，欢迎继续关注我们的《RePlugin深度剖析》系列文章。
Activity坑位
目前市面上的完整坑位方案，Hook的地段可以说是&各有千秋&，从AMS、Instrumentation到ContextImpl都有，并以此让插件变得更灵活。
而我们的方案和他们有些不同：除了ClassLoader是Hook的，其余一律不需要。那么我们究竟是如何开启一个插件的Activity呢?
简单来说，我们有五个核心步骤：
记录：通过PM.startActivity方法来&记录&到要打开的Activity的名字
寻找坑：通过一系列流程来找到一个可用的坑位(如N1ST1)并记录
开启坑：通过系统的startActivity来直接打开这个坑位(注意，此处没有做Hook)
拦截：当系统调到我们的HostClassLoader(唯一Hook点)时，我们&拦了一道&，找到此坑位(N1ST1)对应的真正的Activity(XXXActivity)
返回：加载插件并获取这个真正的Activity的Class对象并返回给系统
其中，PM.startActivity可以由插件/宿主直接调用。若在插件内部，则可以直接通过startActivity方法来打开，更为方便。
当然，这只是核心思路，而每一步我们都会做各种逻辑处理，尤其是&寻找坑&一节，这也是我们的核心之一。
Activity分层坑位
找坑是有非常多的注意点：
从&分层&上看，则需要支持：各种LaunchMode、所有透明/非透明的Theme、TaskAffinity坑位、进程坑位等，甚至AppCompat的情况也要考虑。
从&管理&上看，又需要考虑到坑位回收释放，坑位分配，甚至坑位不足时的处理策略等，不一而足。
篇幅所限，以后会写详细介绍，敬请期待。
向完美前进&&动态编译方案
通过刚才的叙述，像PM.startActivity等确实可通过一些方法，来让插件&无成本使用&。但是，像Provider的调用(本质是IContentProvider)，Service的stopSelf(是final的)，以及因涉及坑位分配，而不得不需复写相应方法的Activity等。这里面存在两个矛盾点：
若不Hook，则必须要插件开发者&自行处理&，稍显繁琐，不够完美;
一旦Hook(如尝试HookAMS、IContentProvider等)，又破坏了我们坚持的&1 Hook原则&，进而担心未来出现兼容性问题
利弊相间，令人头疼。
针对这个问题，我们的核心理念是：&绝不在Hook及稳定性上做任何妥协&，转而创新性的做一套&动态编译方案&，力图从&编译期&来解决这个难题。
大体而言，就是把一些我们认为需要开发者修改的类和方法，借助神奇的JavaAssist来做自动化修改，这样可节省开发者的改动成本，达到想要的效果。
一图以蔽之：
而做到了这一点以后，你会发现，下面的&梦想&就变成了现实：
例如，有个名叫&360桌面&的应用，它想把自己变成&插件&跑起来。那么，有了&动态编译方案&，结合&插件类库&和框架的支持，最终的效果是&&只需改几行Gradle，就能直接生成一个APK。这个APK：
既可以作为插件直接跑在主程序中
又可以作为单品直接安装到设备中
是的，就是这么的神奇!
当然远不止这些。我在GMTC上演示了一段视频，将庞大又复杂的360桌面变成插件，运行在360手机卫士中。这让在场嘉宾倍感惊叹。
试想，一个桌面插件涉及到的功能是&方方面面&的，小到TaskDesription和SO的使用，大到四大组件、Task-Affinity坑位、静态Receiver和进程坑位的处理，都需一一兼顾。所以，要做到这一点，绝不仅仅是前面所说的那几点就能搞定的。
当然，&让360桌面变成插件&，还不是最有意义的。真正让RePlugin变得更有意义的，就是拿我们的360手机卫士来&开刀&，让数百个&&甚至说，近乎一切&&的模块，都成为RePlugin的插件，并完美的运行起来。
&功能丰富项目专用&怎么破?
前文提到，之所以&功能丰富项目专用&，主要和目前市面上的插件化方案的定位有关，以至于开发者认为：&插件 =免安装&、&基础放在主程序里更放心&、&插件开发成本高&等。
然而，仔细分析深层原因后发现，其实最为核心的原因，是插件化和相关框架(包括热更新方案等)的&定位&不同。我知道的有：
组件化：以Atlas/ACDD为代表，官方的定义是&在运行环境中按需地去完成各个bundle的安装，加载类和资源&，以解决大团队协作时的各种难题，提供了热修复能力。其依赖&编译期&较多但很稳定。而大组件的添加，则仍需要主程序发版才能解决，毕竟如官方所述，&组件化 插件化&
动态插件化：以Dynamic-Load-Apk为代表，其目的是解决发版、升级时的问题。大多采用&非占坑&思路，添加新组件时，还是会要求升级主程序。此类方案较多，且是插件化的&鼻祖&了，值得我们尊敬与学习
免安装应用：以DroidPlugin为代表，官方的定义是&可以在无需安装、修改的情况下运行APK文件&。其场景比较类似于&应用分身&
此外，此项目是由我们360公司的手机助手团队研发，在2015年中旬发布。它的出现又一次轰动了插件化界，并掀起了&插件化研究&的思潮。
热修复：以Tinker/Robust为代表，目的是以最小的代价来快速打各种Patch，让应用能够持续更新。其核心优势是&无需重启进程就能打补丁&。同样，新添加的大块功能，则还是需要升级主程序的，毕竟这不是&热修复&的主要目标。
那么，我们是这三种目标之一吗?
显然，都不是。那么，我们的目标究竟是什么?
答案：全面插件化
我们的目标只有一个：全面插件化。
全面插件化：以RePlugin为代表。其目的是&尽可能多的让模块变成插件&，并在很稳定的前提下，尽可能像开发&单品&那样灵活，并享受插件化方案带来的各种好处
也就是说，无论是UI、核心业务、合作插件、后台服务，还是基础功能，都可以变成插件，并在RePlugin框架内稳定又灵活的运行起来。甚至，不仅大项目能用，小项目&&甚至只是个计算器&&都可以使用RePlugin来提升自己的灵活性，并最终实现&插件满天下&的神奇效果。
而这一点，则是我们，和目前市面上大多数插件化框架的主要差异。
目前卫士插件的现状
目前手机卫士已有的插件，可以分为以下几类，供各App开发者参考：
UI插件：如首页(是的，你没看错)、体检、信息流等
业务插件：如清理、骚扰拦截、悬浮窗等
合作插件：如程序锁、免费WiFi、安全桌面等
后台插件：如Push、服务管理、Protobuf等
基础插件：如安全WebView、分享、定位等
而这样的插件，我们有102个。可以想见，一旦这些插件不能用，那么手机卫士瞬间变空壳。三年已过，回头想想，值得回味。
一起创造更高的价值
说到这儿，让我想起了Lody(VirtualApp作者，高中大牛)在接受InfoQ采访，即将结束时所说的那段话：
&插件化技术的成熟程度虽然在最近几年呈上升趋势，但是总体而言仍然处于初、中级阶段。App沙盒技术的出现就是插件化发展的创新和第一阶段的产物。在未来，我相信很多插件化技术会被更多的应用，如果插件化稳定到了一定的程度，甚至可以颠覆App开发的方式。&
这，其实也是RePlugin的终极价值，那就是&&让插件化能&飞入寻常应用家&，做到稳定、灵活、自由，大小项目兼用。
当然，在&全面插件化&甚至&全民插件化&的道路上，我们还有太多的路要走，而如此庞大又复杂的RePlugin，也绝不可能是一两个人在战斗，而是十多位研发人员共同努力的成果，且得到了部门领导，和公司技术委员会的大力支持。我相信，RePlugin的开源，是一场新的开始。这不仅仅是一个决定，而是一份信念，让全社区的有志之士能一起参与进来，共同为中国乃至世界App提供一套&全面插件化&的完美方案而努力。
那么，就让我们一起，为&全面插件化&的梦想而&窒息&吧!
全面插件化时代，为您来临!
<div style="float: width:255 margin:1px 0;"}
精彩科技视频
厂商投稿 产品评测/网站合作/010-84383 友情链接：029- 京公网安备55号
Copyright@
驱动中国 All Rights Reserved}