JoeySheng的专栏-移动互联网技术发展博客

问题起因 我曾经在开发Android Application的过程中遇到过那个有名的65k方法数的问题。如果你开发的应用程序变得非常庞大，你八成会遇到这个问题。 这个问题实际上体现为两个方面： 一、65k方法数 Android的APK安装包将编译后的字节码放在dex格式的文件中，供Android的JVM加载执行。不幸的是，单个dex文件的方法数被限制在了65536之内，这其中除了我们自己实

类加载器ClassLoader 早期使用过Eclipse等Java编写的软件的同学可能比较熟悉，Eclipse可以加载许多第三方的插件（或者叫扩展），这就是动态加载。这些插件大多是一些Jar包，而使用插件其实就是动态加载Jar包里的Class进行工作。这其实非常好理解，Java代码都是写在Class里面的，程序运行在虚拟机上时，虚拟机需要把需要的Class加载进来才能创建实例对象并工作，而完成这

Android 不仅系统版本众多，机型众多，而且各个市场都各有各的政策和审核速度，每次发布一个版本对于开发同学来讲都是一种漫长的煎熬。相比于 iOS 两三天就能达到 80% 的覆盖速度而言，Android 应用版本升级至少需要两周才能达到 80% 的升级率，严重阻碍了版本迭代速度。也导致市场上 App 版本分散，处理 bug 和投诉等也越来越麻烦。 修复的 bug 需要等待下个版本发布窗口才

一、为什么使用aar打包，而不是jar     jar打包只打源代码，像资源文件不会打包，而aar恰恰相反，它会把代码合资源统统打包进一个文件 二、资源命名问题 资源命名最好统统加上你的项目名字前缀，比如图片资源、string、color、dimens、layout等等，反正res目录下所有文件最好都使用统一的加前缀命名，防止跟宿主app下的资源重复，因为aar引用跟源码引用起到的效果一样一