Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info

引言

最近在协助业务团队解决一些疑难问题，其中有一个就是有些用户反馈在进行某个特定的操作时，偶尔会遇到加载很久的情况，就好像是timeout不起作用一样，但是业务开发的同学明明将网络请求的timeout设置为30s,这是为什么呢？难道是okhttp有bug?还是说用户操作不当？

最终我花费了三天时间，慢慢地抽丝剥茧，终于找到了问题的原因

图形绘制概述

Android框架提供了两种绘制图形的方式:Canvas和OpenGL.

android.graphics.Canvas是一个2D图形API, 并且是在开发者中最流行的图形API. Canvas运算会在Android中绘制所有原生和自定义android.view.View. 在Android中，Canvas API通过一个名为OpenGLRender的绘制库实现硬件加速，该绘制库将Canvas运算转换为OpenGL运算，以便它们可以在GPU上执行。

从Android 4.0开始，硬件加速的Canvas默认情况下处于启用状态。因此，支持OpenGL ES 2.0的硬件GPU对于Android 4.0及更高版本的设备来说是强制要求。

除了Canvas,开发者渲染图形的另一个主要方式是使用OpenGL ES直接渲染到Surface. Android在Android.opengl包中提供了OpenGL ES接口，开发者可以使用这些接口通过SDK或Android NDK中提供的原生API调用其GL实现。

Android图形组件

无论开发者使用什么渲染API,一切内容都会渲染到”Surface”. Surface表示缓冲队列中的生产方，而缓冲队列通常会被SurfaceFlinger消耗。在Android平台上创建的每个窗口都由Surface提供支持。所有被渲染的可见Surface都被SurfaceFlinger合成到显示部分。

下图显示了关键组件是如何协作的

1.疑问

前些天有朋友问了我一个问题：对于像Http(s)URLConnection这样Android官方提供的用于进行网络连接的类，在进行很好的封装后，使用起来也很方便，但问题来了，使用它们是否足够可靠

1.起因

今天在做流量分析时，从服务端记录的请求日志发现流量排名前10的用户里有一个用户的某个网络请求竟然在很短的时间内请求了10000多次! 那段时间内的流量占比如下图:

2.分析

考虑到客户端采用AOP的方式记录了所有的网络请求信息，于是赶紧把客户端日志拉上来进行分析，看看是不是某些条件触发的，却意外地并没有看到频繁地网络请求! 我的内心是崩溃

Google推荐的Android架构使用方式

引入

Lifecycles,LiveData,ViewModel

1
2
3

compile 'android.arch.lifecycle:runtime:1.0.0-alpha3'
compile 'android.arch.lifecycle:extensions:1.0.0-alpha3'
annotationProcessor 'android.arch.lifecycle:compiler:1.0.0-alpha3'

整体的架构图

引言

很多人应该知道Activity,Service中的Context和ApplicationContext的区别,而且也知道Context,ContextImpl,ContextWrapper,Activity,Service,Application构成的体系，在异步任务需要Context时,也知道为了防止内存泄露需要传递ApplicationContext而不是Activity的Context,但是这样的场景并不万能，因为并不是所有需要Activity的Context的地方都可以用ApplicationContext来

引言

Android应用程序的编译中，负责资源打包的是aapt,如果不对打包后的资源ID进行控制，就会导致插件中的资源ID冲突。所以，我们需要改写aapt的源码，以达到通过某种方式传递资源ID的Package ID,通过aapt打包时获取到这个Package ID并且应用才插件资源的命名中

引言

到目前为止，我们已经分析了OpenAtlas中插件的安装，卸载，更新，以及安装好插件之后组件类的加载过程，但是对于这些是如何引发的还不知道，比如，在宿主的一个Activit中调用startActivity()跳转到插件中的一个Activity,如何判断这个Activity在的插件是否已经安装，如果没有，需要在哪里判断并安装呢？

要回答这些问题，就需要对于Android中四大组件的启动过程非常熟悉(主要涉及到ActivityThread,ApplicationThread,H,Instrumentation,ActivityManagerNative,
ActivityManagerProxy,AMS等),之后Hook一些关键的对象，然后在关键的位置进行判断并安装插件

如果看过我的前两篇博客Android插件化(二):OpenAtlas插件安装过程分析和Android插件化(三):OpenAtlas的插件重建以及使用时安装，就知道在插件的安装过程中OpenAtlas做了哪些事，那么插件的卸载就只需要把持久化和内存中的内容移除即可