为什么要用记录呢,因为我从开始接触Android时我们的项目就在65535的边缘。不久Google就出了multidex的解决方案。我们也已经接入multidex好多年,但我自己还没有接入,所以本博文只是作者自己对multidex接入整理记录其中大部分来源于Google官网。
随着APP的一次又一次迭代,APP的体积也越来越大,这时候,会引发这么一个问题,早期的错误异常如下:
LZ-Says:在外面呆了一年又一年,似乎都快忘记当初出来的目的,不过,幸好,不忘初心~给家里买点东西,家里开心,我也开心~这就够了。
在开发的过程中,由于产品功能越来越多,导致第三方sdk引入过多,运行时出现65535的问题。先给大家普及一下65535是怎么回事:
当Android系统安装一个应用的时候,有一步是对Dex进行优化,这个过程有一个专门的工具来处理,叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件,即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。
当程序越来越大之后,出现了一个 dex 包装不下的情况,通过 MultiDex 的方法解决了这个问题,但是在低端机器上又出现了 INSTALL_FAILED_DEXOPT 的情况,那再解决这个问题吧。等解决完这个问题之后,发现需要填的坑越来越多了,文章讲的是我在分包处理中填的坑,比如 65536、LinearAlloc、NoClassDefFoundError等等。
在 【Android 热修复】热修复原理 ( 类加载机制 | PathClassLoader 加载 Dex 机制 | PathDexList 查找 Class 机制 | 类查找的顺序机制 )三、 类查找的顺序机制 博客章节有讲解到 , Android 类加载时 , 必须进行分包操作 , 必须有
版权声明:本文为[他叫自己Mr.张]的原创文章,转载请注明出处,否则禁止转载。 https://micro.blog.csdn.net/article/details/52230418
随着安卓平台的不断发展与壮大,市场上大而全的应用比比皆是,产品需求的变更累积和UI交互的极致追求,除了 resources 文件的俱增,在 Android Project 中依赖的 Library 和 自己写的 Java 代码也会越来越多。这些变化,除了会导致打包出的 APK 文件越来越大之外,当项目中java代码包含的方法数(method count)超出一个峰值时,编译过程中就会出现如下错误:
近日,Android Developers在Google+上宣布了新的Multidex支持库,为方法总数超过65K的Android应用提供了官方支持。 如果你是一名幸运的Android应用开发者,正在开发一个前景广阔的应用,不断地加入新功能、添加新的类库,那么终有一天,你会不幸遇到这个错误: Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536 这个错误是Andro
一、背景 就在项目灰度测试前不久,爆出了在 Android 3.0以下手机上安装时出现 INSTALL _ FAILED_DEXOPT,导致安装失败。这一问题意味着项目将不能在 Android 3.0以下的手机上安装使用,对项目的发布有比较大的影响,所以必须尽快解决。 INSTAL L_FAILED_DEXOPT导致无法安装的问题,从根本上来说,可能是两个原因造成的: (1) 单个 dex 文件方法总数65K 的限制。 (2) Dexopt 的 LinearAlloc 限制。 当 Android 系统安装一
首先插播一条自己的广告——有些朋友可能都知道了,我最近创建了一个知识星球,在这里试了一周,发现私密圈子的效率果然比群要好很多,付费门槛过滤掉了大部分广告和没有意愿学习分享的人,希望在这里能聚集更多的热
随着应用不断迭代,业务线的扩展,应用越来越大(比如集成了各种第三方sdk或者公共支持的jar包,项目耦合性高,重复作用的类越来越多),相信很多人都遇到过如下的错误: UNEXPECTED TOP-LEVEL EXCEPTION: java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536 at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java
对于Android大型程序来说,64k方法数与线性内存的限制都是必须要考虑的问题。对于它们的原理与分析,可参考下面这篇文章:http://ingramchen.io/blog/2014/09/prevention-of-android-dex-64k-method-size-limit.html。同时Android官方也推出了自己的解决方案,但却不能满足所有应用的需求。 事实上,解决64K方法限制的唯一方法是拆分多dex,不同方案的差异在于需指定哪些类必须在主dex,这与我们期待的效果以及加载方式相关。
前两篇文章介绍了一下android发展的历史背景、android环境搭建,这篇文章和大家说一下android项目的目录结构及作用。
最近公司项目中需要集成热更新功能,由于刚开始接入的时候踩了很多坑,所以现在记录一下集成的过程.
上一篇文章说道tinker的热更新,可是少了点补丁包的管理,这一篇文章介绍的bugly就是增强版的,更加方便你集成tinker和包括了补丁包的后台管理。 为什么使用 Bugly 热更新?
前言 何老师开启了逗猫线程; 何老师开启了黑科技线程; 何老师 嘿嘿嘿; 何老师 烫烫烫; 对 APK 进行保护是我们经常需要做的事,而且似乎也是每个公司必备的技能了。在使用如 ProGuard,DexGuard 等常见的产品之余,也有很多公司自行研发了一些保护的方案,专门来针对自家产品做出保护,比如说我司也开发了专门防止二次打包的工具。 在开发这款产品,并用于实战的过程中,也发现了很多坑,下面一一细数过来,希望对同样也希望开发一款 APK 保护类产品的人们能有所启发。 坑一: 签名校验 本来以为签名校验是
1、生成密钥文件到app工程目录下 2、在gradle.properties文件下配置密钥文件信息 # Project-wide Gradle settings. # IDE (e.g. Androi
在 【Android 安全】DEX 加密 ( 支持多 DEX 的 Android 工程结构 ) 博客中介绍了 DEX 加密工程的基本结构 ,
以上所述是小编给大家介绍的Android忽略文件,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对ZaLou.Cn网站的支持!
这里建议您对老项目先暂时点击 Don’t remind me on this project,以防有坑。当然我不入地狱谁入地狱,我点 Update,于是问题来了,一直处于下载中,不过,莫担心,我下载好了,公众号聊天界面回复「 gradle-4.1-all 」,下载 gradle-4.1-all.zip 文件,放到:
原文地址:Troubleshooting ProGuard issues on Android 原文作者:Wojtek Kaliciński 译文出自:掘金翻译计划 本文永久链接:github.com/xitu/gold-m… 译者:dieyidezui 校对者:corresponding 为什么使用 ProGuard ProGuard 是一个压缩、优化、混淆代码的工具。尽管有很多其他工具供开发者们使用,但是 ProGuard 作为 Android Gradle 构建过程的一部分,已经打包在 SDK 中
随着业务的快速迭代增长,美团App里不断引入新的业务逻辑代码、图片资源和第三方SDK,直接导致APK体积不断增长。包体积增长带来的问题越来越多,如CDN流量费用增加、用户安装成功率降低,甚至可能会影响用户的留存率。APK的瘦身已经是不得不考虑的事情。在尝试瘦身的过程中,我们借鉴了很多业界其他公司提供的方案,同时也针对自身特点,发现了一些新的技巧。本文将对其中的一些做详细介绍。 在开始讲瘦身技巧之前,先来讲一下APK的构成。 APK的构成 可以用Zip工具打开APK查看。比如,美团App 7.8.6的线上版本
做移动开发最麻烦的就是收集用户在使用过程中的程序的异常崩溃日志,因为这个异常崩溃是无征兆的在毫无防备随时的出现,所以有时候真是丈二金刚(摸不着头脑);这个还是其次要命的是用户端程序的每次迭代和版本的分布又不容易推送和获取。
同款iOS的在这里: MUI、HBuilderX、H5+开发APP本地打包(iOS)
在Git中如果想忽略掉某个文件,不让这个文件提交到版本库中,可以使用修改根目录中 .gitignore 文件的方法 ,把要忽略的文件名填进去,Git就会自动忽略这些文件。
携程Android App的插件化和动态加载框架已上线半年,经历了初期的探索和持续的打磨优化,新框架和工程配置经受住了生产实践的考验。本文将详细介绍Android平台插件式开发和动态加载技术的原理和实现细节,回顾携程Android App的架构演化过程,期望我们的经验能帮助到更多的Android工程师。 需求驱动 2014年,随着业务发展需要和携程无线部门的拆分,各业务产品模块归属到各业务BU,原有携程无线App开发团队被分为基础框架、酒店、机票、火车票等多个开发团队,从此携程App的开发和发布进入了一个全
携程Android App的插件化和动态加载框架已上线半年,经历了初期的探索和持续的打磨优化,新框架和工程配置经受住了生产实践的考验。本文将详细介绍Android平台插件式开发和动态加载技术的原理和实现细节,回顾携程Android App的架构演化过程,期望我们的经验能帮助到更多的Android工程师。 需求驱动 2014年,随着业务发展需要和携程无线部门的拆分,各业务产品模块归属到各业务BU,原有携程无线App开发团队被分为基础框架、酒店、机票、火车票等多个开发团队,从此携程App的开发和发布进入了
真的要细说 Gradle,恐怕目前能力还是有限,仅仅了解皮毛,简单分享,欢迎交流~
为了提升编译速度,这几天用上了 AS 3.0 和 Gradle 3.0 插件,不得不说不论是 AS 3.0,还是 Gradle 3.0 都变化非常大,具体的更新日志参考下官网,其中 Gradle 3.0的配置和可能遇到的问题可以说是非常详细了。Gradle 4.1-all 官方下载速度很慢,我直接放出来下载地址和相关官方文档地址吧。
当前市面的热补丁方案有很多,其中比较出名的有阿里的 AndFix、美团的 Robust 以及 QZone 的超级补丁方案。但它们都存在无法解决的问题,这也是正是最后使用 Tinker 的原因。先看一张图对比:
本文来自张绍文老师的《Android开发高手课》,我把我认为比较好的文章整理分享给大家。
美团•大众点评是中国最大的O2O交易平台,目前已拥有近6亿用户,合作各类商户达432万,订单峰值突破1150万单。美团App是平台主要的入口之一,O2O交易场景的复杂性决定了App稳定性要达到近乎苛刻的要求。用户到店消费买优惠券时死活下不了单,定外卖一个明显可用的红包怎么点也选不中,上了一个新活动用户一点就Crash……过去发生过的这些画面太美不敢想象。客户端相对Web版最大的短板就是有发版的概念,对线上事故很难有即时生效的解决方式,每次发版都如临深渊如履薄冰,毕竟就算再完善的开发测试流程也无法保证不会将B
在项目开发中,将公用的代码提取到common_module中,将某些单独功能封装到lib_module中,再根据业务划分module,团队成员分别开发各自的模块。 但随着项目的迭代,功能越来越多,增加了一些业务模块后,相互调用的情况会增多,就会发生各个业务模块之间的耦合非常严重,导致代码难以维护且扩展性很差。组件化就应用而生了。 组件化基础:多module划分业务和基础功能。 组件:单一的功能组件,如适配,支付,路由组件等,可单独抽出来形成SDK。 模块:独立的业务模块,如直播,首页模块等。模块可能包含多个不同组件。
为什么要用记录呢,因为我从开始接触Android时我们的项目就在65535的边缘。不久Google就出了multidex的解决方案。我们也已经接入multidex好多年,但我自己还没有接入,所以本博文只是作者自己对multidex接入中产生的问题以及解决方案做理解和记录。
开发壹二APP,一路上或多或少踩了一些坑,有些是太基础一时忘记,有的是细节没有注意。记录下来方便回忆,有些应该没有解决,有些结论可能不太准确,需要后续研究。没有作具体分类,只是按时间先后记录,所以,显得特别杂乱。
随着项目的不断迭代,代码量跟资源文件不断增多。那么就会出现打包后的 APK 文件越来越大,如果突然有一天你们老板或领导叫你优化 APK 大小,你还不知道怎么优化那就有点说不过去了,这篇文章咱们就来一起分析并优化 APK 体积大小吧。
为什么要用记录呢,因为我从开始接触Android时我们的项目就在65535的边缘。不久Google就出了multidex的解决方案。我们也已经接入multidex好多年,但我自己还没有接入,知其然而不知其所以然。出了问题只能自己找源码来分析。前两篇文章 Multidex记录一:介绍和使用 和 Multidex记录二:缺陷&解决 分别讲述了怎么接入和接入时遇到的问题,本博文只是对multidex源码学习过程中的分析和理解的记录。
除了AS自带的Analyzer之外,还有ApkChecker、ClassyShark等工具。
在2.3版本Apk安装时 , 会进行Dexopt , 如果单个Dex中的class过大/method过多 , 就会导致LinearAlloc为Class/Method的内存分配不足 , 从而让Dexopt进程挂掉.
最近写了篇有关Eclipse工程转Android Studio工程的文章,而导致公司项目需要转 AS 的直接原因,就是今天要写的主题–方法数超限,相信大多数 Android 项目的都会碰到这个问题。
网上关于启动优化的文章多不胜数,内容千篇一律,大都是列举一些耗时操作,采用异步加载、懒加载等。
LintOptions ( build.gradle#android#lintOptions ) 文档位置 : android-gradle-dsl/2.3/com.android.build.gradle.internal.dsl.LintOptions.html
项目中的方法数太多,包括自己的、第三方等,超过65536就会报这个错,无法生成apk文件。 官方解决方案:https://developer.android.com/intl/zh-cn/tools/building/multidex.html 解决办法: 1.app:build.gradle apply plugin: 'com.android.application' android { defaultConfig { ... multiDexEnabled
这一章主要针对项目中可以用到的一些实用功能来介绍Android Gradle,比如如何隐藏我们的证书文件,降低风险;如何批量修改生成的apk文件名,这样我们就可以修改成我们需要的,从文件名中就可以看到渠道,版本号以及生成日期等信息,这多方便啊;还有其他突破65535方法的限制等等。
领取专属 10元无门槛券
手把手带您无忧上云