JSONObject.parseObject

转载请标明出处:http://77blogs.com/?p=146

{

“data”:{

“shop_uid”:”123″;

“id”:”123″

}

}

将上面的json字符串转换为JSONObject之后可能会出现顺序不一样,即在JSONObject中,可能是下面的顺序:

 

“id”:”123″

“shop_uid”:”123″;

 

为了保证顺序一样,可以用:

JSONObject jsonObject = JSONObject.parseObject(dataString, Feature.OrderedField);

后面加上参数:

Feature.OrderedField

android Activity runOnUiThread() 方法的使用

转载请标明出处:http://77blogs.com/?p=138

利用Activity.runOnUiThread(Runnable)把更新ui的代码创建在Runnable中,然后在需要更新ui时,把这个Runnable对象传给Activity.runOnUiThread(Runnable).

Runnable对像就能在ui程序中被调用。

从上面的源代码中可以看出,程序首先会判断当前线程是否是UI线程,如果是就直接运行,如果不是则post,这时其实质还是使用的Handler机制来处理线程与UI通讯。

用这种方式创建ProgressDialog就比较方便,或者刷新adapter也比使用Thread+Handler方便。

如果不是在activity中创建,需要在前面加上((Activity)mContext). 。

readLine()的注意点

转载请标明出处:http://77blogs.com/?p=142

我在用socket做即时通讯的时候,读取服务器返回的信息用了BufferedReader,用起来挺方便的。

BufferedReader br = new BufferedReader(new InputStreamReader(socket.getInputStream()));
String line ;
while ((line = br.readLine())!=null){
}
readLine()用起来很方便,每次都是返回一行。
不过该方法有许多值得注意的地方:

一、网络模式:
1、在网络上,readLine()是阻塞模式,也就是说如果readLine()读取不到数据的话,会一直阻塞,而不是返回null,所以如果你想要在while循环后执形相关操作是不可能的,因为while()里面是一个
死循环,一旦读不到数据,它又开始阻塞,因此永远也无法执形while()循环外面的操作,所以应该把操作放在while循环里面。(在我做的即时通讯里,为了能够不断获取服务器返回的消息,就是用这种方法,不断去服务器获取消息
,一旦有就返回。)

2、在while()里面判断readLine()!= null的时候要赋值给一个String,因为如果不为null,那么这时候已经读了一行。如果用while (br.readLine()!=null),那么下面没法再获取到这一行,所以应该用
while ((line = br.readLine())!=null){}

3、readLine()通过下列字符之一即可认为某行已终止:换行 (‘\n’)、回车 (‘\r’) 或回车后直接跟着换行,所以我们在发送数据的时候要再后面加上这些标志符,否则程序会阻塞。而我是直接用下面这种方法:
PrintStream ps = new PrintStream(socket.getOutputStream(), true, “UTF-8”);
ps.println()。
ps.println()已经包含换行了,所以不要用print(),若是要就要在后面加上换行符;

4、readLine()只有在数据流发生异常或者另一端被close()掉时,才会返回null值。

二、读取文件模式:
1、readLine()什么时候才会返回null呢?读取到文件等的结尾时候。(注意和网络上的是不一样的)。

如果不指定buffer大小,则readLine()使用的buffer有8192个字符。在达到buffer大小之前,只有遇到”/r”、”/n”、”/r/n”才会返回。

Glide源码解析一,初始化

转载请标明出处:http://77blogs.com/?p=269

Glide作为一个强大的图片加载框架,已经被android官方使用,所以,明白Glide的加载流程以及原理对加深我们对glide的理解是很重要的。

本文基于glide 4.11

 

我们从这一句入手,先看看Glide的初始化过程,也就是Glide.with(this)这个方法。

一、单例实例化

 

可以看到里面有多个重载方法,最常用的是这个,这些方法最终返回的是RequestManager

都一致调用了getRetriever(…).get(view)

我们看一下getRetriever(…)里面做了什么。

 

getRequestManagerRetriever()返回的是一个RequestManagerRetriever,我们主要看的是Glide.get(context)

 

可以看到Glide.get(context)里面进行了初始化的操作,它是我们熟悉的单例模式。最终会调用

 

二、GlideModule配置加载

上面的get方法中,我们需要注意这一句:

点进去可以看到关键部分的代码为

 

 Glide提供给我们自定义加载组件的方式,在Glide 3x中,我们首先会定义一个继承于GlideModule的类,然后在项目的AndroidMenifest.xml中进行指定:

而在Glide4中,提供另外一个配置的模式,那就是注解,并且不再继承GlideModule,而是继承AppGlideModule和LibraryGlideModule,分别对应Application和Library,使用@GlideModule注解进行标记。而Glide3.x中的配置方式已经建议放弃使用。

getAnnotationGeneratedGlideModules(context.getApplicationContext());便是获取Glide注解自动生产的一个Glide的Module配置器,叫做:

GeneratedAppGlideModuleImpl

然后将其作为参数最终传递到initializeGlide方法。

 

initializeGlide方法:

 

上面这一段的意思就是:从manifest中解析到我们自定义的GlideModule类,如果判断与注解生成的类重复,那么就可以去掉。

annotationGeneratedModule.isManifestParsingEnabled()

判断是否还支持Glide 3x的在AndroidMenifest.xml中进行指定的方式,默认是返回true,说明现在还是支持的。

 

接着以上代码,Glide将逐个调用剩下的GlideModule,并回调applyOptionsregisterComponents接口,这时,用户配置的GlideModule就会被调用,同时用户设置的参数也就被配置到Glide中。

 

源码中获取的通过注解生成的GlideModule只有一个,这也说明了我们只能通过注解配置一次。
 
三、构建Glide

Glide glide = builder.build(applicationContext);

  build方法里面是对glide的各种配置,比如上面的:

1、加载源数据的线程池

2、加载磁盘缓存中数据的线程池(不能用来加载url网络数据)

3、动画加载请求器

4、内存计算器

5、网络状态检测器

6、bitmap缓存池(避免不断不断创建与回收bitmap导致内存抖动)

7、数组资源缓存池

8、内存缓存,缓存完成加载和显示的图片数据资源
9、本地磁盘缓存,默认存储在app内部私密目录
 
然后创建图片加载引擎。

 

最后再将上面的缓存池,引擎等作为参数,构建一个Glide

 

 这个构造函数非常长,我们只挑一些重点的来讲,其它的可以类推:

1、创建各种decoder,也就是解码器,比如:

将ByteBuffer解码为GifDrawable。

 

将资源uri解码为Drawable

 

2、创建各种factory,即模型装换器,比如:

将Android资源ID转换为Uri,在加载成为InputStream

 

将资源ID转换为Uri

 

3、创建各种Transcoder,即转码器,比如

将Bitmap转码为Byte arrays

 

将将GifDrawable转码为Byte arrays

 

4、创建各种encoder,即编码器,比如:

将Bitmap数据缓存为File

 

5、注册:

 

 如上面,注册将Byte数据缓存为File的编码器,注册将InputStream缓存为File的编码器。将ByteBuffer解码为Bitmap的解码器,将inputStreams解码为Bitmap的编码器。

 

四、生命周期管理。

getRetriever(activity).get(activity);中的getRetriever(activity)方法讲解完了,接下来讲get方法,大家就能知道glide是怎么监听图片的生命周期的。

 

 

 

 同样的,get方法也有多个重载方法,方法里面检测,如果是运行在后台线程,那都会调用下面这个方法:

 

因为不是运行在主线程,所以最终也都会调用:

getApplicationManager(context),创建一个RequestManager,生命周期与application的一样。

而如果不是运行在后台线程的话,那么重载方法里面的参数不同,执行的方法也就不同,我且看这一个:

public RequestManager get(@NonNull Activity activity) 

传递的参数是activity,那么生命周期应该与Activity一样。

 

我们点进去fragmentGet方法:

 

可以看到它首先获取RequestManagerFragment,这其实就是一个fragment,然后获取与之绑定的RequestManager,如果获取不到就说明还没绑定,那么就去构建一个RequestManager,然后与RequestManagerFragment进行绑定。而在构建RequestManager的时候,传进去了一个current.getGlideLifecycle(),这个是Glide的生命周期,可以看出生命周期的管理是在RequestManager中的。那怎么实现与activity的生命周期同步呢?

接下来就要看看getRequestManagerFragment(fm, parentHint, isParentVisible);这个方法做了什么。

首先通过tag去找activity中有没有存在对应的fragment,找不到的话就去pendingRequestManagerFragments  这个map中看有没有,还没有的话就去初始化一个RequestManagerFragment。

再将fragment添加到activity中。

pendingRequestManagerFragments的作用:

pendingRequestManagerFragments是为了防止重复添加fragment。因为add方法来添加fragment并不会立即执行,而是被加入任务队列中。它有相关的生命周期是异步进行的,所以如果add之后立马又在相同fragment或者activity环境中调用get方法,那么就很有可能又创建一个新的RequestManagerFragment,所以用pendingRequestManagerFragments在add任务完成前拦截其他的添加操作,在完成后发送消息移除。

 

如果父布局可见,也就是activity可见,那么开始生命周期的start回调。

在RequestManagerFragment里面可以看到,fragment的生命周期进行回调的时候就会调用glide自定义的生命周期lifecycle的相应方法。

也就是说glide是通过往activity中添加fragment,然后监听fragment的生命周期来控制glide的生命周期进行同步

其它的重载方法类推。

 

 
 

 

Android获取定位权限,获取设备所在的经纬度

转载请标明出处:http://77blogs.com/?p=253

前言:

有时候我们仅仅是想要获取设备所在的经纬度,那么直接调用Android相关的api就可以了,不需要去接入高德地图或者谷歌地图等等。

一、获取定位服务

二、获取所有可用的位置提供器

三、判断可用的位置提供器类型,是网络定位,还是GPS定位,若是都没有,那么就跳转至设置界面,提示打开网络和GPS定位服务

这里说一下两种定位的区别:

通过GPS定位,较精确,也比较耗电,而网络定位精度不高,省电。

四、获取Location

五、监视地理位置变化

这里设置3秒监听一次

六、实现地理位置变化接口

注意:

要在文件清单里面写上

我为此写了个工具类。

这里边涉及到了另一个问题,获取权限

对于6.0以下的权限及在安装的时候,根据权限声明产生一个权限列表,用户只有在同意之后才能完成app的安装,造成了我们想要使用某个app,就要默默忍受其一些不必要的权限(比如是个app都要访问通讯录、短信等)。而在6.0以后,我们可以直接安装,当app需要我们授予不恰当的权限的时候,我们可以予以拒绝。当然你也可以在设置界面对每个app的权限进行查看,以及对单个权限进行授权或者解除授权。

 

新的权限机制更好的保护了用户的隐私,Google将权限分为两类,一类是Normal Permissions,这类权限一般不涉及用户隐私,是不需要用户进行授权的,比如手机震动、访问网络等;另一类是Dangerous Permission,一般是涉及到用户隐私的,需要用户进行授权,比如读取sdcard、访问通讯录等。

 

对于Dangerous Permission,我们需要动态获取权限,那么我们怎么动态定位权限呢?

在activity中(其实我们可以把权限的获取写在一个BaseActivity中)我们可以这么做:

1、判断版本,如果6.0以下,那么便不需要获取权限。

2、若是6.0以及以上的话,那么便去判断是否已经授权,若是没有授权,那么便会去申请授权。若是已经授权,那么便直接执行我们的操作。

(判断之后若是没有授权,会弹出系统对话框询问是否同意授权,该对话框不可定制。)

3、授权回调。询问是否同意授权的时候,系统会弹出对话框,我们选择之后,会进行回调。在回调里面进行判断。

若是同意了,那么便可以直接执形我们的操作,若是不同意,那么下次依旧会弹出询问的对话框。不过这个对话框与之前比起来多了一个选项,那就是“不再提醒”(第一次询问没有这个选项)。这就难办了,若是点击了不再提醒,那么以后就不会再弹出对话框了,唉,那我们怎么判断呢?

Google给我们提供了一个方法:

该方法主要是为了给用户提供解释。

这个方法,在没弄明白之前,也是挺烦人。弄明白之后就好办了,那么,我们需要弄明白它的返回值。

(1)、当用户第一次被询问是否授权的时候,该方法返回值为false

(2)、若是用户上一次拒绝授权,但是没有点击“不再提醒“”的时候,这一次返回true。(我们可以根据这个判断,在这一次给用户一个解释,解释为什么该app需要该权限)

(3)、当用户上一次拒绝授权,并且点击了“不再提醒”的时候,那么返回false。

(4)、当用户在设置界面手动关闭了该APP的权限,那么也返回false。

 

那么,就出现了一个问题,这么多种情况都返回false,那么我们要怎么判断是哪一种情况呢?

比如第一与第三种情况。

若是我们在进行权限判断之前调用这个方法:

若是返回true,说明是第二种情况,需要给用户一个解释(我们可以给出一个对话框,点击确定后再执形检测权限的操作,即下面的的操作)。

若是返回false,那么到底是第一还是第三种情况。我们无法判断。这里我给出一种方法:在授权回调里面去检测,如下。

else可以说明已经拒绝授权。

然后调用shouldShowRequestPermissionRationale方法,若是返回false,说明

1、点击了“不再提醒”。

2、该app本身没有权限,被关闭。

那么我们就可以提醒用户去设置界面手动开启权限。

 

MAT分析android内存泄漏

转载请标明出处,违权必究:http://77blogs.com/?p=230

泄漏,泄漏,漏~

内存泄漏怎么破,什么是内存泄漏?与内存溢出有什么区别?

 

内存泄漏(Memory Leak):是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。

内存溢出(out of memory):是指程序在申请内存时,没有足够的内存空间供其使用,出现out of memory;

 

内存泄漏不一定会引起奔溃,但是内存溢出一定会

 

Java里头有GC垃圾回收机制,他是怎么判断该不该回收呢?

Q1:某对象没有任何引用的时候才进行回收?

A:不。无法往上追溯到GCroot引用点的才回收。

 

Q2:某对象被别的对象引用就不能进行回收?

A:不。软引用,弱引用,虚引用都可以

 


哪些可以作为GCroot引用点:

  • Javastack中引用的对象
  • 方法区中静态引用指向的对象
  • 方法区中常量引用指向的对象
  • Native方法中JNI引用指向的对象
  • Thread-活着的线程

 

adb命令验证是否存在内存泄漏:

1、打开要测试的apk,然后返回退出到主界面

2、AS的Terminal中输入命令:

     adb shell dumpsys meminfo com.status.mattest -d 

com.status.mattest为包名

 

然后便可以看到内存的一些情况

拉到下面可以看到:

我们退出APK之后,对象本应该都被回收,然而这里可以看到,还有view以及Activity占用着内存,由此可以知道内存泄漏了。

 


我们点击AS上的按钮,进行分析。

运行apk后会出现该界面:

我们点击MEMORY进入内存分析界面:

这时候我们需要进行刚刚的操作,打开apk,然后返回键退出,然后点击上图中垃圾桶形状的图标进行垃圾回收,多点几次,直到内存没有什么变化了。

然后点击上图中类似于下载按钮的图标获取内存快照。

获取完之后,左边会出现下面这图,Head Dump便是获取内存快照后出现的,我们可以点击红圈中的图形进行保存

跟着出现的还有这个窗口。

我们可以通过包来分类查看自己的项目.

Shallow Heap(浅堆) 表示该对象自身占用的堆内存,不包括它引用的对象。
针对非数组类型的对象,它的大小就是对象与它所有的成员变量大小的总和。

Retained Heap(深堆) 表示当前对象大小+当前对象可直接或间接引用到的对象的大小总和。
换句话说,Retained Size就是当前对象被GC后,从Heap上总共能释放掉的内存。

不过,释放的时候还要排除被GC Roots直接或间接引用的对象。他们暂时不会被被当做Garbage。

从图中可以看出,出现了内存泄漏的是CustomUtils,MainActivity,MainActivity$1代表MaiActivity里面的一个方法。

 

点击MainActivity,可以看到这么对东西,眼花缭乱,我们根本不知道是哪个引起了内存泄漏。那咋办。铺垫结束,mat该上场了。

MAT

下载mat https://www.eclipse.org/mat/downloads.php

安装步骤很简单。

打开MAT后,点击File -> Open Heap Dump 打开刚刚保存的内存快照,会发现打不开。

因为我们保存的内存快照是不能直接在MAT上打开的,需要进行转化。

 

在AS的Terminal窗口输入:hprof-conv -z A.hprof B.hprof

A.hprof为刚刚保存后的快照文件,B.hprof为转换后的文件,也就是我们要在MAT上打开的文件

然后我们在MAT上将其打开。

点击Finish

点击Histogram

 可以通过包名来分类查看

 

从下图中可以看到引起内存泄漏的类,Objects那一列不为0的就是,与我们之前看到的一样。

 

MainActivity右键

选择图中的选项,意思是过滤掉虚引用,软引用,弱引用

之后可以看到引用的路径,CustomUtils里面的instance引用了MainActivity的context,导致了MainActivity内存泄漏。

打开代码看一下

MainActivity中:

MainActivity中调用了单例CustomUtils,并且把context传了进去,而我们知道instance作为静态对象,是GCroot引用点,所以activity关闭了它也没法被回收,那么最为被instance引用的Activity自然也无法被回收,所以导致了内存泄漏。

 

解决:

把单例模式里面的context换为全局application的context,也就是说单例里面的context的周期应该与进程一样,而不能够与应用一样。当我们关闭应用的时候,进程还在,并没有被杀死。