一.背景 动态插件化编程是一件很酷的事情,能实现业务功能的 解耦 便于维护,另外也可以提升 可扩展性 随时可以在不停服务器的情况下扩展功能,也具有非常好的 开放性 除了自己的研发人员可以开发功能之外,也能接纳第三方开发商按照规范开发的插件. 常见的动态插件的实现方式有 SPI.OSGI 等方案,由于脱离了 Spring IOC 的管理在插件中无法注入主程序的 Bean 对象,例如主程序中已经集成了 Redis 但是在插件中无法使用. 本文主要介绍在 Spring Boot 工程中热加载 jar

本章主要讲解如何为框架新增插件化开发功能. 在.net 4.0中,我们可以在Application开始之前,通过PreApplicationStartMethod方法加载所需要的任何东西.那么今天我们主要做的工作就集中在这个时间段: 1.将插件DLL及文件拷贝入主网站目录并编译 2.加载Plugin 首先来说说第一步,由于这步里面,我们主要拷贝DLL及文件,所以我们利用了一个List<Assembly>容器来记录所有的插件的DLL,具体代码如下: 1: using System; 2: usi

Android的插件化已经是老生常谈的话题了,插件化的好处有很多:解除代码耦合,插件支持热插拔,静默升级,从根本上解决65K属性和方法的bug等等. 下面给大家介绍一下我们正在用的插件化框架.本片主要以类图的方式向大家介绍插件化框架的实现.下图是框架的初始化流程: 框架初始化后,就该启动插件了,下图是插件的启动流程: 这个步骤主要是初始化插件的运行环境,利用宿主的Context改造成插件的Context.接下来是插件启动Activity的流程: 该步骤主要是用宿主的Activity包装插件的Ac

支持插件化应用的开发框架能给程序带来无穷的生命力,也是目前很多系统.程序追求的重要方向之一,插件化的模块,在遵循一定的接口标准的基础上,可以实现快速集成,也就是所谓的热插拔操作,可以无限对已经开发好系统进行扩展,而且不会影响已有的功能,不在需要的模块,通过修改配置移除即可.我的Winform开发框架一直以来,来源于多年的项目积累以及客户的反馈,已经具备了众多很好的特性以及相关的模块组合,为了更好拥抱变化,提高基于Winform开发框架基础上开发新系统的效率,以及为框架融入更多好的特性,故此把我的

.NET MVC 插件化框架支持原生MVC的Area和路由特性 前面开放的源码只是简单的Plugin的实现,支持了插件的热插拔,最近晚上偶然想到,原生的MVC提供Areas和RouteAtrribute等路由特性标签,按照先前的做法,无法解析插件的路由特性和Areas,所以花费了两个晚上的时间,把插件给改进到支持Areas和路由特性,但同时也放弃了Web类插件的热插拔,Func类的插件依然支持热插拔. 下面是实现支持插件使用Areas和路由特性标签的流程: 原生的MVC在启动的时候需要执行两条代

No1: 插件化技术的好处: 1)减轻应用的内存和CPU占用 2)实现热插拔,即在不发布新版本的情况下更新某些模块 No2: 插件化方案必须要解决三个基础性问题:资源访问.Activity生命周期的管理和ClassLoader的管理 No3: 宿主是指普通的apk,插件一般指经过处理的dex或者apk.插件化框架大多采用apk作为插件,很多需要用到代理Activity,插件Activity的启动大多数是借助一个代理Activity来实现的. No4: Activity的工作主要是通过Contex

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由达文西发表于云+社区专栏 最近在工作中接触到了Android插件内的开发,发现自己这种技术还缺乏最基本的了解,以至于在一些基本问题上浪费不少时间,如插件Context和主工程Context的区别,权限必须在主工程申明等,因此花了点时间了解了一下插件的历史,并写了两个Demo作为总结.本文旨在通过两个实例直观的说明插件的实现原理以加深对插件内开发的理解,因此不会深入探讨背景和原理,代码也尽量专注于核心逻辑. 原理与背景 Androi

前言 正常的App开发流程基本上是这样的:开发功能-->测试--->上线,上线后发现有大bug,紧急修复---->发新版本---->用户更新----->bug修复.从发现bug到修复bug花了很长时间.我们希望bug的修复是立马生效的,用户无感知就能自动修复bug.当然,Android端的动态修复bug已经有不少框架了,不过我们今天讲的是另一个话题:Android的插件化.Android插件化有很多好处:热插拔.静默升级.bug动态修复.代码解耦等.正是因为如此,才有越来越多

动态加载技术(也叫插件化技术),当项目越来越庞大的时候,我们通过插件化开发不仅可以减轻应用的内存和CPU占用,还可以实现热插拔,即在不发布新版本的情况下更新某些模块.     通常我们把安卓资源文件制作成插件的形式,无外乎有一下几种: zip.jar.dex.APK(未安装APK.安装APK) 对于用户来讲未安装的APK才是用户所需要的,不安装.不重启,无声无息的加载资源文件,这正是我们开发者追求的结果.     但是,开发中宿主程序调起未安装的插件apk,一个很大的问题就是资源如何访问,这些资

http://www.cnblogs.com/android-blogs/p/5703355.html 什么是组件化和插件化? 组件化开发就是将一个app分成多个模块,每个模块都是一个组件(Module),开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等,但是最终发布的时候是将这些组件合并统一成一个apk,这就是组件化开发.插件化开发和组件化开发略有不用,插件化开发时将整个app拆分成很多模块,这些模块包括一个宿主和多个插件,每个模块都是一个apk(组件化的每个模块是个lib),最终

概述 nopCommerce的插件机制的核心是使用BuildManager.AddReferencedAssembly将使用Assembly.Load加载的插件程序集添加到应用程序域的引用中.具 体实现可以参考nopCommerce解决方案中Nop.Core项目的Plugins目录下的相关文件.其中PluginManager.cs文件是核 心文件,包含了处理插件化的核心代码.nopCommerce的注释中感谢了其参考的Umbraco项目,并给出了主要参考文章的链接.   我们直接从nopComm

1.介绍 涛哥写的文章  <Android 插件化的 过去 现在 未来> http://kymjs.com/code/2016/05/04/01#rd

Android Small插件化框架源码分析 目录 概述 Small如何使用 插件加载流程 待改进的地方 一.概述 Small是一个写得非常简洁的插件化框架,工程源码位置:https://github.com/wequick/Small 插件化的方案,说到底要解决的核心问题只有三个: 1.1 插件类的加载 这个问题的解决和其它插件化框架的解决方法差不多.Android的类是由DexClassLoader加载的,通过反射可以将插件包动态加载进去.Small的gradle插件生成的是.so包,在初始

最新内容请见原文:Android 插件化 动态升级 不少朋友私信以及 Android开源交流几个 QQ 群 中都问到这个问题,这里简单介绍下 1.作用 大多数朋友开始接触这个问题是因为 App 爆棚了,方法数超过了一个 Dex 最大方法数 65535 的上限,从这个介绍中也知道可以通过多个 Dex 来解决这个问题,因而便有了插件化的概念,将一个 App 划分为多个插件(Dex或相关格式)常用的其他解决方法还包括:删无用代码,用 H5 代替部分逻辑,买付费版的 Proguard插件化的其他作用包括

1. 插件化的原理 是 Java ClassLoader 的原理:Java ClassLoader基础 常用的其他解决方法还包括:Google Multidex,用 H5 代替部分逻辑,删无用代码,买付费版的 Proguard 当插件化作用包括:(1) 模块解耦,(2) 动态升级,(3) 高效并行开发(编译速度更快) (4) 按需加载,内存占用更低 (5) 节省升级流量 2. 插件化 Android 插件化 —— 指将一个程序划分为不同的部分,比如一般 App 的皮肤样式就可以看成一个插件 An

客户端开发给人的印象往往是小巧,快速奔跑.但随着产品的发展,目前产生了大量的门户型客户端.功能模块持续集成,开发人员迅速增长.不同的开发小组开发不同的功能模块,甚至还有其他客户端集成进入.能做到功能模块开发和发布的独立,能像Html5一样能帅气的解决bug并动态更新到用户的手机,一直是客户端开发的梦寐以求的特性. 一.问题提出      一般的,一个Android应用在开发到了一定阶段以后,功能模块将会越来越多,APK安装包也越来越大,用户在使用过程中也没有办法选择性的加载自己需要的功能模块.此

携程Android App的插件化和动态加载框架已上线半年,经历了初期的探索和持续的打磨优化,新框架和工程配置经受住了生产实践的考验.本文将详细介绍Android平台插件式开发和动态加载技术的原理和实现细节,回顾携程Android App的架构演化过程,期望我们的经验能帮助到更多的Android工程师. 需求驱动 2014年,随着业务发展需要和携程无线部门的拆分,各业务产品模块归属到各业务BU,原有携程无线App开发团队被分为基础框架.酒店.机票.火车票等多个开发团队,从此携程App的开发和发布

自从在<Winform开发框架之插件化应用框架实现>一文中,介绍并总结了Winform开发框架插件化应用框架的实现后,赢得了很多同行和客户的支持,于是把我的WCF开发框架.混合式开发框架都进行了升级,把它们都提升到插件化应用的高度上.本文主要介绍WCF开发框架,如何实现插件化的应用.从我随笔<基于我的Winform开发框架扩展而成的WCF开发框架>介绍可以看到,一般的WCF应用,是在客户端添加服务应用的方式,然后使用自动生成的WCF服务客户端代理来访问相应的服务的,这种方式比较方便

通过对嵌入式企鹅圈原创团队成员degao之前发表的<Android Small插件化框架源码分析>的学习,对Android使用的插件化技术有了初步的了解,但还是有很多需要认真学习的地方,特别是大部分知识都需要结合虚拟机和Androidframwork的原理才能慢慢理解.比如,文中作者提到了插件化框架要解决的三个核心问题: 1)插件类的加载: 2)插件资源的处理: 3)Activity注册和生命周期问题: 其中第3点作者是这样解释的,“大部分插件化框架解决办法都是采用在宿主工程里预先注册Acti

一.前言 nopCommerce的插件机制的核心是使用BuildManager.AddReferencedAssembly将使用Assembly.Load加载的插件程序集添加到应用程序域的引用中.具体实现可以参考nopCommerce解决方案中Nop.Core项目的Plugins目录下的相关文件.其中PluginManager.cs文件是核心文件,包含了处理插件化的核心代码. 我们直接从nopCommerce3.5的实现中抽取必要的实现代码,制作一个简易版的插件系统Demo用于演示ASP.NET

前言 如同第一章我们说的,宿主程序通过 dexclassloader 将插件的类加载进来,然后通过反射去调用它的方法,这样Activity就被当成了一个普通的类来执行了,因此系统不再接管它的生命周期,也就是说Activity的生命周期函数失效了.针对这样的问题,有网友想出使用Fragment来解决此问题,Fragment既有类似于Activity的生命周期,又有类似于View的界面,因此选它比较合适,具体的做法是将Fragment加入到宿主的代理Activity内部,其生命周期将完全由代理Act