MoJieBlog

下面是我之前看深入理解JVM记得笔记。直接复制了。 ### 1.1 概述 虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟直接使用的java类型，这就是虚拟机的类加载机制。 ### 1.2 类加载的过程 * 加载 * 验证 * 准备 * 解析 * 初始化 * 使用 * 卸载 >其中验证，准备，解析三个部分称为连接。其中解析和初始化的顺序可能会不同（可能先解析后初始化，也可能先初始化后解析）。 #### 1.2.1 关于初始化 5种情况会触发类的初始化 * 遇到new,getstatic,putstatic,invokesstatic这四个字节码指令时，如果类没有被初始化 *...

我也分享下： * 首先分清你要做什么，是否支持缩放。以此来确定图片的宽高。如果只是显示，没必要把图片宽高弄得太大，如果要做类似世界地图的效果，肯定是要移动和缩放的，这种一般图片宽高会比较大。然后我们分情况说。 * 一般加载图片，宽高只要跟控件宽高差不多，甚至小一些都是可以的。 * 图片尽量使用软引用，较大的图片可以通过bitmapFactory缩放后再使用，并及时recycler。 * 加载巨图时不要使用setImageBitmap或setImageResourse或BitmapFactory.decodeResource,这些方法拿到的都是bitmap的对象，占用内存较大。可以用BitmapFactory.decodeStream方法配合BitmapFactory.Options进行缩放 * 加载超大宽高的图片。这里我没做过，但是之前看过类似的效果，原理也简单的了解了一下。就是分区块加载，比如先加载其中的某一块，用户移动时再加载其他区块。网上有一个不错的库BitmapRegionDecoder。

* 避免轮循。可以利用推送。如果非要轮循，合理的设置频率。 * 应用处于后台时，避免某些数据的传输，比如感应器，定位，视频缓存。 * 页面销毁时，取消掉网络请求。 * 限制访问频率，失败后不要无限的重连。 * 合理的选择定位精度和频率。 * 使用缓存。如果数据变化周期比较长，可以出一个配置接口，用于记录那些接口有变化。没变化的直接用缓存。 * 减少广播的使用频率。可以用观察者，startActivityForResult等代替。 其他的暂时想不到了。

> 1） aapt 为res 目录下资源生成R.java 文件，同时为AndroidMainfest.xml 生成Mainfeset.java文件 > 2）aidl 将项目中自定义的aidl 生成相应的Java文件 > 3） javac 将项目中所有java 代码编译成class 文件，包括 业务逻辑代码， aapt 生成 java文件，aidl 生成java 文件 > 4） proguard ， 混淆同时生成mapping.txt ,这步可选 >...

内存溢出(oom)说白了就是应用要申请的内存大于手机对该应用的限制。因此所有导致内存增长的操作都是有可能导致内存溢出的。之所以没有看到内存只增不减，是因为JVM的自动垃圾回收机制。所以上面说的导致oom的情况，只是某些特定场景。并不是说加载小图就不会oom，也不是说创建一个线程就不会oom,也不是说内存泄漏就一定会oom...举个例子： 比如：假如你有一个10立方米的水桶，你一次倒入1立方米的水，前10次都不会溢出，但是第11次就要开始往外取1立方水（相当于内存回收）才能继续倒水，不然就会溢出水（oom）。

我来说下为什么是16.6毫秒刷新一次UI。经常玩游戏的人肯定知道60fps的时候基本上就感觉不到卡顿。这里的60fps就是每秒60帧。1000/60 = 16.666666...所以当手机刷新频率16.6时，用户就不会感到卡顿

我补充一些东西吧。kotlin和java都是运行在java虚拟机的语言。编译后都会生成.class文件。而虚拟机运行的正是.class文件。所以两者都可以用来写Android。再说说个人的一些看法。java作为一门相对时间长一点的语言。相对来说更万能一些。基本上能完成所有的开发场景。而且，因为时间够久，相对来说问题也很少,虽然大家都吐槽分号，类型转换，空指针这些傻瓜操作，但是我并没有觉得不写这些就能对我的开发有质的的提升，唯一让我想学kt的动力就是google的Android实例将来要用kt写。而kotlin作为一门新语言，有他自己的优点，也有一些缺点。具体什么缺点大家看下面的文章吧。 [从java到kotlin,再从kotlin回归java](https://www.oschina.net/translate/from-java-to-kotlin-and-back-again?lang=chs&p=1)

以下是我读源码的一些感想： #### 构造方法 首先看构造方法，一共七个构造方法，但是最后都是调用了两个方法，分别是 Handler(Callback callback, boolean async)和Handler(Looper looper, Callback callback, boolean async)。 然后来分析这两个方法 ```java public Handler(Callback callback, boolean async) { //FIND_POTENTIAL_LEAKS是一个私有的静态变量，默认是false，而且整个源码只有这里调用了 //按道理应该改变不了的 //看注释是，当设置为true时检测匿名，本地或者成员类继承Handler并且不是静态，这种类型的类会造成潜在的内存泄漏 if (FIND_POTENTIAL_LEAKS) { final Class

看了大家的回答，感觉都讲得很不错。我这里说几个大家在开发中关于内存优化的几个细节。 * 循环中尽可能不要创建较大的对象，列入bitmap。这会引起内存抖动。 * 自定义View避免在onDraw中创建对象，因为自定义Viewon的onDraw方法会被频繁调用。创建对象，甚至较大的对象，会导致内存增加，甚至内存抖动。 * cursor和流的及时关闭，特别是异常处理。一定要写finally里关闭流。 * 避免静态内部类的引用。比如A类中有静态变量B。这是只要B被应用，就会导致A也不能回收。 * 图片尽量使用软引用。较大的图片可以通过bitmapFactory缩放后再使用。并及时recycler.另外加载较大的图片尽可能不要使用setImageResourse,BitmapFactory.decordeResource和setImageBitmap方法。这些方法返回的是Bitmap对象。占用内存较大。可以使用BitmapFactory.decodeStream配合BitampFactory.Options对图片进行缩放，然后显示。 ... 其实关于内存的优化还有好多，欢迎大家补充。

* MVC:model,view,control。在Android开发中。传统的MVC写法大多是把view和control写在一起，也就是我们常见的Activity和Fragment文件里。这样的缺点就是造成这两个页面代码量比较大，而且业务逻辑和view耦合在一起。一旦需求变更维护成本会比较高。 * MVP:与MVC相比，MVP将业务和UI解耦。view触发业务，prensenter处理业务并且将结果反馈给view。View便可以根据业务的处理结果直接显示相应UI。这样的好处就是，业务和ui解耦，当需求变更时，只要处理相应的方法便可。 如果做Android的话，我建议还是MVVM，不过现在谷歌提供的dataBinding有点蛋疼，每次修改布局还要重新rebuild下。期待有其他解决办法。