--<摘自android插件化开发指南> 1.有些项目,整个app只有一个Activity,切换页面全靠Fragment,盛行过一时,但有点极端 2.Activity切换fragment页面 第一步:FragmentLoaderActivity作为Fragment的承载容器 <activity android:name=".FragmentLoaderActivity"> <intent-filter> <action android:name

最近几年移动开发业界兴起了「 插件化技术 」的旋风,各个大厂都推出了自己的插件化框架,各种开源框架都评价自身功能优越性,令人目不暇接.随着公司业务快速发展,项目增多,开发资源却有限,如何能在有限资源内满足需求和项目的增长,同时又能快速响应问题和迭代新需求,这就是一个矛盾点.此时,插件化技术正好风生水起,去了解各个主流框架实现思路,看看能对目前工作是否有帮助,是很有必要的. 主要分为以下几个部分 插件化介绍 入门知识 实现原理 主流框架 实战 小结 进阶资料 插件化介绍 百度百科里是这么定义插件的

本书在京东购买地址:https://item.jd.com/31178047689.html 本书Q群:389329264 (一)这是一本什么书 如果只把本书当作纯粹介绍Android插件化技术的书籍,那就大错特错了. 本书在研究Android插件化之余,还详细介绍了Android系统的底层知识,包括Binder和AIDL的原理.四大组件的原理.App的安装和启动流程.Context和ClassLoader的家族史.没有罗列大量的Android系统中的源码,而是以一张张UML图,把这些知识串起来

OpenAtlas有一个问题,就是四大组件必须在Manifest文件里进行注冊,那么就必定带来一个问题,插件中的组件都要反复在宿主中注冊.像Service,ContentProvider等组件眼下没有什么好的解决方法.仅仅能在宿主中注冊. 可是像Activity,显然是有解决方法的.就是使用Fragment取代Activity,Activity仅仅是作为一个放Fragment的容器,那么不仅在插件中不用再清单文件里注冊,就连宿主的注冊问题也一并攻克了.那么,解决方式呢,没错,就是之前写的一篇博文

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

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的开发和发布

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

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

1.为什么需要插件化系统 “编程就是构建一个一个自己的小积木, 然后用自己的小积木搭建大系统”. 但是程序还是会比积木要复杂, 我们的系统必须要保证小积木能搭建出大的系统(必须能被组合),有必须能使各个积木之间的耦合降低到最小. 传统的程序结构中也是有模块的划分,但是主要有如下几个缺点: a: c++二进制兼容 b: 模块对外暴露的东西过多,使调用者要关心的东西过多 c: 封装的模块只是作为功能的实现者封装,而不是接口的提供者 d: 可替换性和可扩展性差 而插件式的系统架构就是为了解决这样的问题

最近在研究Android应用的插件化开发,看了好几个相关的开源项目.插件化都是在解决以下几个问题: 如何把插件apk中的代码和资源加载到当前虚拟机. 如何把插件apk中的四大组件注册到进程中. 如何防止插件apk中的资源和宿主apk中的资源引用冲突. 就这几个问题,我开始研究插件化开发实现的相关技术. 在上篇文章中我讲了如何把插件apk中的class加载到当前进程 的问题,本篇文章主要讲第一点的第二点:如何加载另一个apk中的资源到当前应用中. AssetManager介绍 当我们在组件中获取资

如有转载,请声明出处: 时之沙: http://blog.csdn.net/t12x3456    (来自时之沙的csdn博客) 概述: 随着应用的不断迭代.应用的体积不断增大,项目越来越臃肿,冗余添加.项目新功能的加入,无法确定与用户匹配性,发生严重异常往往牵一发而动全身,仅仅能紧急公布补丁版本号.强制用户进行更新.结果频繁的更新,反而容易减少用户使用黏性.或者是公司业务的不断发展,同系的应用越来越多,传统方式须要通过用户量最大的主项目进行引导下载并安装. 怎么办? 參考浏览器-插件开发模式:

欢迎各位增加我的Android开发群[257053751​] 假设你还不知道什么叫插件化开发.那么你应该先读一读之前写的这篇博客:Android插件化开发,初入殿堂 上一篇博客主要从总体角度分析了一下Android插件化开发的几个难点与动态载入没有被安装的apk中的Activity和资源的方法.事实上一般的插件开发主要也就是载入个Activity.读取一些资源图片之类的.可是总有遇到特殊情况的时候,比方载入Service. 要动态载入Service,有两种思路:一是通过NDK的形式.将Servi

大熊君JavaScript插件化开发 一,开篇分析 Hi,大家好!大熊君又和大家见面了,还记得昨天的那篇文章吗------这个系列的开篇(第一季).主要讲述了以“jQuery的方式如何开发插件”, 那么今天我们带着昨天的疑问来继续我们的插件开发之旅.昨天的问题如下: (1),如果项目技术选型换了这些插件又是强依赖“jQuery”机制,我们以前写的插件将会不能用(假设不用jQuery的情况),如何做重构那? (2),重构插件的关键逻辑,我们将如何组织那? 好了,带着问题去学习今天的文章吧. 首先我

360手机助手使用的 DroidPlugin,它是360手机助手团队在Android系统上实现了一种插件机制.它可以在无需安装.修改的情况下运行APK文件,此机制对改进大型APP的架构,实现多团队协作开发具有一定的好处. 它是一种新的插件机制,一种免安装的运行机制 github地址: https://github.com/DroidPluginTeam/DroidPlugin 参考博客:http://blog.csdn.net/hejjunlin/article/details/52124397

应用插件化背景 目前很多应用功能越来越多,软件显得越来越臃肿.因此插件化就成了很多软件发展的必经之路,比如支付宝这种平台级别的软件: 页上密密麻麻的功能,而且还在增多,照这个趋势发展下去,软件包的大小将会不可想象.目前常用的解决方案是使用web页面,但用户体验和Native界面是没法比的. 设想,如果每一个功能点都是一个动态库,在用户想使用某个功能的时候让其从网络下载,然后手动加载动态库,实现功能的的插件化,就再也不用担心功能点的无限增多了,这该是件多么美好的事! 软件版本实时模块升级 还在忍受

前言:前一段时间新开源了一种全面插件化的方案-- RePlugin,之前一种都在关注 DroidPlugin 并且很早也在项目中试用了,但最终没有投入到真正的生产环节,一方面是项目中没有特别需要插件化的需求,另一方面也考虑到 DroidPlugin 不是特别稳定,Android系统每更新一次 DroidPlugin 可能就会出现一些 Bug,毕竟 Hook 了 Android 原生的太多东西,系统一旦更新引发 Bug 是在所难免的.当然,这些并不能否认 DroidPlugin 的优秀,它的原理和