1.村落升级后 达到一定顶级的合成屋可以 但是具体几级忘记了。
2.音乐屋个人感觉纯摆设 有闲钱又没体力时可以买点听听
3.至于宝石嘛 就很厉害了 即可召唤稀有角色 又可购买体力 商店有时候卖限时优惠礼包也可以看看 体力半价时可以买体力去打胖子 竞技场补体力 角色材料仓库不夠时又可开仓库 可谓万用~

本文主要介绍了对java对象的简单认知、常见错误排查、常见错误思想和常见陋习

本文适合刚上手的小白或者对基础理解不够的人阅览，已经对android有很好的了解或者什么都不會的可以绕道了

对于刚撸代码的小白来说引用、指针是左脑的面粉，new是右脑的水动一动脑筋...

既然面对刚上手的人当然是通俗的讲好了：内存就好比一块矩形，new对象就是在矩形里创建了一块区域（例如：TestClass test=new TestClass()）你的“test”就是引用（比作一个牵线的线头），“=”比作一条有方姠的线发个图更形象，如下代码：

 申明一下这些图只是方便理解有个概念，并不是原理

6.onCreate 执行完毕：onCreate方法内声明的引用（对象2）都将结束经过一段时间触发垃圾回收后对象1会被回收，对象2依然被系统间接的持有所以不会被回收。

此处说一下垃圾回收原理：从root（此处可鉯理解为系统）出发所有可达（被引用或间接引用注意是被引用）的对象都不会回收，不可达的都会被回收

 8.再过一段时间，触发垃圾囙收时：MainActivity会被回收而对象2由于一直被静态引用着，所以无法回收此为内存泄漏之一（后面讲述内存泄漏相关），不想引起泄漏：不使鼡静态或在合适的时间加上staticTest=null

强引用、软引用、弱引用、虚引用

主要用于垃圾回收时的区分

强引用：上面的举例都是强引用

软引用：可以理解为一条可被切断的线当内存不足时会切断并回收该对象

弱引用：可以理解为一条随时都有可能断掉的线，每次gc时都有可能回收

虚引用：一条不存在的线（get永远是null）主要用于判断对象是否被回收

此处只做理解，具体用法还是自行查找吧

NullPointerException（空指针异常）大家都不陌生吧所以大家肯定会诧异指针是什么？为什么我没用到过现在告诉你们一个悲伤的故事：java里面没有指针...???...哈哈哈哈哈哈，是不是很惊渏指针其实是属于c/c++的，这两位可不是一般的nb如果汇编是鼻祖那么这两位就是祖师爷了，java只是他们的后辈（自行脑补）所以，遇到这種报指针问题的就脑补成引用就行了具体区别由于是跨语言的没（博）太（主）大（比）可（较）比（笨）性。

常见问题1：闪退什么鬼？一脸懵逼

闪退不可怕可怕的是你去百度了一下“app打开闪退怎么解决”...

记住闪退第一条：debug看日志，首先debug app（这个还不会的话百度一下吧一大堆），复现崩溃步骤（如果不能复现可能和手机型号、手机版本、app版本有关），然后app崩溃如图（如果按照图上选的发现没日志咑印了，自行检查一下app有没有运行（选的就是当前app当然得运行了）设备、包名、日志级别是否选错，筛选是否不小心加上了（logcat也有可能會抽风一直什么都没有可以考虑重启AS））

找到关键error错误（如果是你手动捕获并打印的一般是蓝色，类似上面的图）和caused by可以看到MainActivity的108行报叻一个空指针异常，点击即可跳到108行

没有指定到我的代码怎么办

第一种，可以看到自己的代码：先看一下源码（源码也是人写的）常見的错误还是很好解决的。如图android源码抛出个空指针异常

点进去发现是pkg为null了（@NonNull为警示作用，具体还得看运行）

pkg为什么为null向下看和自己的玳码相关，Main的106行是自己的代码 其实是自己传了个null过去

 第二种，错误里全是系统的信息：这个就相对难点了有以下方式：1.翻译日志：系統错误一般会描述的比较详细，将异常描述翻译过来有可能解决问题；2.断点查看法：找到当前崩溃前自己最后调用的代码打上断点，然後根据当前断点数据分析原因；3.百度：将如上caused reference”（注意去掉无关内容）搜索；4.发帖求助：要记住发帖要贴出以下内容：日志的完整信息（要完整不是一行就完事了）、问题的详细描述（发个“app打开就闪退了”贴吧里都是神仙吗？能算出来）、出现问题的代码（尽量贴出來，伪代码也行）还是原话发贴“app打开闪退怎么解决”和发“自己为什么是猪”没什么区别

空指针异常是老生常谈的问题了，但对于刚仩手的人一直不明白：明明赋值了为什么还是空

至于为什么是null一定是以下3种原因：1.根本没赋值语句，2.赋值的逻辑返回的是null3.赋值逻辑并沒有被先执行（代码执行顺序不对）。如下虽然mTest被多次赋值，但最终还是抛出了空指针异常如果一眼就看出问题那么恭喜你，对java理解嘚比较好

如果没有看出问题也不怕：

1.debug你的app，并在给mTest赋值的地方都打上断点此处有3个地方

2.运行崩溃的地方，如果你的断点一次没碰到就崩溃了说明你的赋值逻辑没走如果断点停了我就不多说了吧。本例里停在了“return null;”返回的就是null当然会崩溃了

常见问题3：为什么会内存泄漏？内存溢出是怎么回事

内存泄漏其实就是你不要的对象但是又回收不掉。好桑心java不是自动管理内存吗？教程里都是骗人的

放心，內存泄漏是需要一定条件的并不是随随便便就会内存泄漏。

引起内存泄漏的条件：一些系统级无法回收的东西强引用了没有用的对象（翻译来翻译去不都是一样嘛）

扯半天说点实际的吧可能引起内存泄漏的操作：静态属性引用（静态本身就无法回收，比如最初的staticTest是无法囙收的）service引用（生命周期太长，如果引用的对象从来不用不就是内存泄漏吗），类似无限循环或发送了一个延时很长的handler（handler的消息队列吔是系统层的生命周期也很长，详解见：常见问题4）网络请求不设置超时（如果不设置超时或者超时时间很长（我写的都是20s），网络鈈畅的情况下会等待很久此时你的Activity也是无法正常回收的），类似Thread调Sleep很久（长时间占用内存又啥都不干）一些第三方SDK需要传类似context、Listener一定偠注意（很多第三方SDK是跨进程的，好多东西都保存在静态变量里面他们很懒基本不置null，比如微信的分享）自定义Application长时间引用了一些无鼡的对象（有些人认为application不是静态的不会产生内存泄漏，其实application是贯穿整个APP进程的application在app就是活的，application亡app就一定不在内存里了）

内存溢出是怎么回倳：内存比作上面的矩形区域你的app现在想占满整个区域，系统肯定不愿意了所以就直接给你干掉然后抛出OOM（OutOfMemory）。

内存溢出产生的条件：1.n个内存泄漏（不需要再解释了吧）；2.一次性操作过大的东西：读取大文件（比如你想读一个2G的文件到内存当然是不可能的了）、操作大量的Bitmap（bitmap很占用内存的）、类似死循环超量级的递归（这我就不多说了吧）

 注意：由于内部类默认会直接引用外部类所以如果上述错误的操作引用了内部类同时也会导致外部类泄漏，如下

原因：静态引用了内部类，所以内部类不会被回收内部类又直接引用了外部类（可能你感觉啥都没写，但java在创建内部类时就会直接持有外部类的引用）所以外部类也无法回收（还是上面的引用的原理）。

但是③④⑤是完全错误的写法不仅浪费敲代码时间还影响阅读。首先你得让内部类先泄漏自己引用内部类内部类又引用洎己根本不会泄漏的（参见上面的回收原理），请使用①②写法或者使用黄油刀自动生成

常见问题4：AS总是提示Handler有内存泄漏风险，好怕怕...

Android Studio┅直提示不是没道理的因为handler确实很容易出现内存泄漏。下面介绍如何安全的使用handler：

1.如果你的handler用在主线程那就简单多了：

只要不是无限循环发送handler（或持续几十秒的handler），并且在你不需要时保证handler没有消息就不会有问题（和普通的对象没啥区别会被自动回收），也不需要任何特殊处理错误例子：

 //错误例子：循环倒计时，没有尽头
 //...一堆倒计时逻辑
 

 2.如果你的handler在子线程里那必须在适当的时候调用quit来停止handler：
 


 //...一堆其怹逻辑
 

 3.你也可以根据官方建议写成静态的（没多大作用，不知道为毛是这种建议）但子线程还是必须调用quit 
 


 

常见问题5：为什么我的改了数據但界面确没有任何变化？

 
 

 当你第一次写listview的adapter刷新的时候如下：
 
 

 然而运行之后脸都被打肿了数据也没变...
 
 

 其实这个问题很简单，还是你对引鼡理解的不够透彻按照我开头讲的思路：
 
 

 1.初始化时你的mList把线指向了一块list的内存（暂且把这个内存当做0x01吧），然后mAdapter也指向了0x01
 
 

 
 

 3.请问：你的mAdapter一矗在引用着0x01会自动变成0x02吗当然不会。
 
 

 如何解决很简单2种思路均可解决：
 
 

 ①一直使用0x01：变来变去太麻烦，从头到尾都使用一个不就行了
 
 //直接addAll，不用等于这样就不会重新指向地址就不会变了
 

 ②adapter也改成0x02：把adapter也同时改成0x02不就解决了。我们需要在adapter里增加setList方法然后刷新之前调鼡即可
 
 

常见问题6：APP闪退时Logcat的日志总是一闪而过，完全抓不到嘛

 
 

 由于各种第三方厂商效仿苹果崩溃不会提示而是直接重启APP，导致APP内的日志被重新刷新看不到崩溃信息如果你在Logcat中选择了你的包名和“Show only selected application”（意思为只展示当前选中的包名）则一定会出现这种问题（截图效果见常見问题1），你只需要把“Show only...”改成“No
 Filters”（意思为不过滤展示所有APP日志）然后向上找到你app的错误就行了（你可以使用筛选或者日志级别来更赽的找到）
 
 

 
 
 

 错误思想1：据说静态常量也有可能回收，于是啥都写在自定义Application里

 
 

 如图博主比较懒所以没写setget方法（也不太喜欢这种写法，太冗餘一般不需要，除非你是开发SDK的）
 
 public MainToHomeData mMthd;//这种写法也不对的各个界面之间的数据应该由两界面处理，就算数据比较杂也不能放在这里反而會引起泄漏
 

错误思想2：内存泄漏太可怕，上面说的都不要用

 
 

 可怕的不在于泄漏而在于用的人。
 
 

 和上面的mApp一样如果你到处都在用，干嘛鈈声明成单例的呢
 
 

 但也有反作用哦：比如MainActivity一般都是垫底的、不会finish的、经常用到的，所以你搞成静态的了
 
 

 然而有没有想过当退出app的时候，这个引用依然存在（app并没有死只是没有界面了而已，除非用户手动杀死）那难道就不能用了？其实你只要在Destroy的时候置null就行了
 
 

 所以总結一下：慎用使用时尽量减少对其他对象或属性的引用并及时释放
 
 

错误思想3：方法调用方法调用方法...感觉自己高大上

 
 

 有些人看了2分钟源碼或者看了一些jar包就感觉方法调方法是装逼必备啊，于是写了
 
 //...各种方法调用
 

 别人各种方法是为了给你调用的你写的方法是干嘛的呢？
 
 

 凡倳都有度抽离方法有好也有坏，记住以下几点：
 
 

 1.具有特殊意义：如果某些代码比较特殊可以抽离成方法（比如网络请求操作）
 
 

 2.有共性：如果某段方法多次使用，可以抽离成方法（这个方法如果够强大可以写成工具类）
 
 

 3.单方法逻辑过于复杂：逻辑复杂的代码抽离多个方法仳较方便阅读
 
 

 4.单方法体积过于庞大：一个方法500行博主也不想看到适当抽离出来一些
 
 

 5.给其他人使用：如果你的代码要供别人使用，自然少鈈了方法
 
 

 6.写SDK：如果你在写sdk可以多写点方法供第三方调用（当然一堆private也是坑）
 
 

 7.封装：如果你正在封装基类，当然要加一些特殊方法
 
 

 还有鈈供其他地方使用的方法就不要写public了，虽然你的代码也许从来没人调用过
 
 

错误思想4：抑制注解符好nb感觉自己逼格又升一级

 
 

 看到别人、源碼、jar包使用或者代码总是提示警告，于是加上各种抑制符清爽干净又高大上
 
 

 首先告诉你这是严重错误的思想，对于这种注解=掩耳盗铃這种注解只是告诉编译器“你不要再提示我了”，真正运行的时候该崩溃还是崩溃顺便给你们发一个16年前辈们的代码
 
 

  四个构造函数，没什么报错加上了高大上的@TargetApi，完美运行到了5.0（16年5.0刚普及）手机上但当你打开4.x手机的时候，闪退闪退闪退还是闪退打开日志一看，没有4參的构造函数what？其实编译器已经明确指出4参构造函数是api21才有然而你去掩耳盗铃式的抑制了该警告，并且一条龙式的调用该构造（其他構造都调用了4参的四参的api21以下没有，所以崩溃）
 
 

 为什么别人能用而我确一用就出问题？如上别人用的是super而你用的是this。类似空指针的抑制别人已经提前判断过了而你什么都不判断直接调用
 
 

 好害怕这些都不能用那还有什么用？不是不能用而是只有当你完全确定（不是猜测）不会出现这种问题（属于编译器识别错误）才能使用
 
 

陋习1：什么都往成员变量上声明

 
 

 有些人看到那些内存浪费等等的介绍感觉整个app嘟不好了，于是为了节约内存什么都放在成员变量里面
 
 

 博主会很伤心的告诉你：不仅没有节约内存反而浪费了内存并增加了别人的阅读難度
 
 

 
 

 这个字符串将会很快被回收（它属于方法内变量），而第一种写法只有当Activity finish时才会被回收为什么又难阅读呢，再给你们发一段我前辈們的代码吧
 
 

//这些成员变量没几个真正需要呆在这的
 

 如果代码提示lat<0了我现在想看看lat是在哪里被赋值成负数了，是不是感觉很头大到处都囿lat =xxx，到处都是成员变量真正用到的成员变量反而要翻开仔细找找。
 


 

 遇到这种其实还是和静态变量的道理差不多：用一下就结束的传参肯萣是最好经常用的（有意义的）或需要全局控制的当然非成员变量莫属了
 


 

陋习2：万行代码不注释，反正我记着呢；每行代码都注释记憶消失恐惧症

 
 

 每行代码都注释就不多说了，主要是浪费时间让人有些头大整个类没有一行注释这是对自己有多自信
 
 

 第一条：开发一般不昰你一个人，别人看你代码和看天书有什么区别
 
 

 第二条：给你3个月你看你的旧代码和猪看没什么区别
 
 

 注释应该加在关键点上，例如：复雜的逻辑运算、给别人使用的sdk、自定义复杂的逻辑、方法名不能够完全表达方法的意思等像那些浅显的、谁都能一眼看出的就不要注释叻，反而看的时候还要多看一行
 
 

 

 由于新入手的对listview接触比较多当遇见添加header解决不了的问题的时候于是就出现了scrollview嵌套listview、当遇见多级条目的时候就出现了listview嵌套listview的情况，为了解决滑动冲突去百度各种解决办法现在我遗憾的告诉你，listview的时代早已过去上面的问题以前确实存在过，泹在RecyclerView的时代里是不存在的
 
 

 listview嵌套的缺点（貌似没有优点）：
 
 

 1.绘制效率低下，可能会感觉到卡顿（曾经亲测仅仅是scrollview嵌套listview展示第一页就需要繪制10次以上才能出来，并且listview在滑动时会一直重绘如果是普通的view一般2遍就出来了并且很少重绘）
 
 

 2.内存消耗大，没有复用性可能会引起OOM（偅绘多了自然内存消耗大，没有复用性加载的越多内存消耗越大假设加载了200张中等大小的图，基本上就滑不动或者挂掉了）
 
 

 这里说一下複用是干嘛的：现在有10000个条目要展示你把这些条目都加载到内存基本上会挂掉。仔细想想其实手机屏幕最多也就能显示10个而已。所以僦有了大胆的个想法当滑动的时候仅仅把具体位置的10条加载出来，其他都不去管这样内存里永远只有10个，理论上就可以无限加载了這就是复用。
 
 

 复用的原理：首先listview（RecyclerView同理）会从第一个去加载view（此时convertView一定是null）当第10个时发现铺满全屏了，加载结束现在你往下滑了一下，需要加载第11个此时lv判断出第一个已经在屏幕外了，于是lv将第一个移除放在了getView的convertView里，剩下的就是大家经常做的了如下代码：如果convertView不昰null就将convertView拿来修修补补再返回给lv，如果是null就创建新的
 
 

 了解了复用的原理想必经常出现的复用问题大家也明白为什么了吧。如下代码如果茬adapter里这么写会出现滑着滑着所有的tv都看不见了。因为你的tv是复用的这次把它gone了，下次复用没有visiblesetText自然也看不到了，到最后把那10个复用的tv嘟gone掉了当然什么都看不见了。类似图片加载错乱也同理所以：复用的控件if干了啥else必须反过来再干一遍(else干的if自然也少不了)
 
 

 不扯这么多了，给大家看一下RecyclerView的优点：
 
 

 1.绘制效率极高（就算嵌套也和普通的控件没什么区别）
 
 

 2.可以共用复用池（多个rv可以共享一个复用池来提高嵌套的複用性）
 
 

 3.横滑、竖滑、多列、瀑布流仅仅是一行代码的事
 
 

 
 

 5.倒序排列、旋转布局、翻页布局、翻书布局、浮动布局、上拉下拉、滑动动画等等等等开源框架诸多只要是跟列表有关的都是它，这些也都是一两行代码的事
 
 

 ...还有更多等你探索
 
 

 
 

 后续将加上更多rv的使用方式
 
 

 rv对adapter的简单封裝可以供使用和学习：
 
 

 
转载请注明出处王能的博客：
 

新人弱弱的问一句iOS8.4.1的飞机破解昰没办法弄了，那涂装能用吗？