自动重新加载-自定义ClassLoader初步

本文介绍了自定义ClassLoader的实现,支持从自定义路径加载类,可在不重启应用时自动重新加载修改过的类,还试验了检测类文件修改的机制。提供了源代码下载、运行方法,说明了源代码目录结构,还提及从jar文件加载资源及解决相关Zip操作错误的方法。
来源: Thinkbase.net,   自动重新加载-自定义ClassLoader初步


自己做了一个自定义 Class-Loader 的试验, 打算做一个记录和总结, 完整的源代码可以从[ att:自动重新加载-自定义ClassLoader初步.classLoader.zip ]得到.

自定义 Class-Loader 用来做什么呢? 可以想到的有两个用途:
  1. 用于在应用框架中自由指定应用程序类的位置(这样可以把应用程序的类和框架自身的类在位置上分开);
  2. 可以控制在需要的时候(比如检测到类的修改, 或者用户手工触发时)重新加载类.

http://www.javaresearch.org 上面找到几篇关于 Class-Loader 的文章, 基本上本文的所有思路都是从这两篇文章来的:
在这两篇文章的基础上, 本文自定义了一个Class-Loader, 主要目的是:
  1. 实现一个 Class-Loader, 支持从自定义的路径(包括目录和jar文件)中加载类;
  2. 尝试在避免重启的情况下自动重新加载修改过的类;
  3. 试验一种检测类文件修改的机制;
  4. 提供例子和测试程序, 测试 Class-Loader 的实现在发现和加载/重新加载类文件和资源文件时的行为.

源代码下载

源代码可以从[ att:自动重新加载-自定义ClassLoader初步.classLoader.zip ]下载.

源代码可以使用 Eclipse 直接打开, 同时下载文件中也包括 Ant 的 build.xml, 可以使用 Ant 命令建立和运行测试程序, 看到运行效果.

如何运行

下载源代码后, 解压到某个目录, 在命令行下进入此目录, 运行 ant build 即可完成编译, 然后运行 ant run 即可看到运行效果;

默认情况下 ant run 可以自动运行一遍相关的测试程序(请注意观察输出的信息), 然后测试程序会等待用户输入下一步命令, 输入 "c"+<回车> 将会重新执行一遍测试(请观察输出信息, 这次和最初启动时有一些差异), 输入 "x"+<回车> 将退出程序;

如果需要观察类自动加载的情形, 需要:
  1. 在未使用 "x"+<回车> 退出应用程序前, 在一个另外打开的命令行窗口中, 执行 ant refresh-1, ant refresh-2 或者 ant refresh-jar1, 来使两个类目录和一个jar文件中class文件以及资源文件发生改变;
  2. 在执行完上面的任意一条 ant 命令后, 回到原来的那个命令行窗口, 使用 "c"+<回车> 重新运行一遍测试, 注意在输出信息中的类文件修改检测和Class-Loader重新加载信息, 以及重新加载后运行结果的不同;
  3. 请注意类似"... was created at [2005-06-26 23:30:58]"这样的一些时间信息, 这些信息在每次类文件改变后会相应变化.

补充说明

关于源代码目录结构

  • 系统中的源代码主要包括:
    • boot-src
      • 这是系统启动时的代码, 这些代码不是由自定义的Class-Loader加载的, 因此也不会自动加载;
    • runtime-1-src
      • 运行时由自定义Class-Loader加载的代码(1);
    • runtime-2-src
      • 运行时由自定义Class-Loader加载的代码(2);
    • runtime-jar1-src
      • 运行时由自定义Class-Loader加载的代码, 与上面的两个runtime不同, 这个目录下的代码在编译之后是以jar包的形式被加载到系统中的.

其它

  • 本例子还尝试了从 jar 文件中加载 class 和 资源文件 的操作, 具体请参考相关代码;
  • 在覆盖jar文件的测试例子(ant refresh-jar1)中, 经过多次实验发现在这种情况下, 如果直接将编译结果打包到目标jar文件, 在以URL形式加载jar包中资源的时候, 容易引起Zip操作相关的错误, 经推断可能是因为jar包在这种情况下仍然保持打开状态(可以修改, 但是无法删除); 为了解决这个问题, 尝试首先在一个临时目录中生成需要的jar包, 然后复制覆盖目标jar文件, 通过这样处理, 避免了上述的Zip操作相关错误.

END

响应速度问题分析套路(以 Systrace 为主) 确认前提条件(老化,数据量、下载等)、操作步骤、问题现象,本地复现 需要明确测试标准 启动时间的起点是哪里 启动时机的终点是哪里 抓取所需的日志信息(Systrace、常规 log 等) 首先分析 Systrace,大概找出差异的点 首先查看应用耗时点,分析对比机差异,这里可以把应用启动阶段分成好几段来看,来对比分析是哪部分时间增加 Application 创建 Activity 创建 第一个 doFrame 后续内容加载 应用自己的 Message 分析应用耗时的点 是否某一段方法自身执行耗时比较久(Running 状态) –> 应用自身问题 主线程是否有大段 Running 状态,但是底下没有任何堆栈 –> 应用自身问题,加 TraceTag 或者使用 TraceView 来找到对应的代码逻辑 是否在等 Binder 耗时比较久(Sleep 状态) –> 检测 Binder 服务端,一般是 SystemServer 是否在等待子线程返回数据(Sleep 状态) –> 应用自身问题,通过查看 wakeup 信息,来找到依赖的子线程 是否在等待子进程返回数据(Sleep 状态) –> 应用自身问题,通过查看 wakeup 信息,来找到依赖的子进程或者其他进程(一般是 ContentProvider 所在的进程) 是否有大量的 Runnable –> 系统问题,查看 CPU 部分,看看是否已经跑满 是否有大量的 IO 等待(Uninterruptible Sleep | WakeKill - Block I/O) –> 检查系统是否已经低内存 RenderThread 是否执行 dequeueBuffer 和 queueBuffer 耗时 –> 查看 SurfaceFlinger 如果分析是系统的问题,则根据上面耗时的点,查看系统对应的部分,一般情况要优先查看系统是否异常,参考上面列出的的系统原因,主要看下面四个区域(Systrace) Kernel 区域 查看关键任务是否跑在了小核 –> 一般小核是 0-3(也有特例),如果启动时候的关键任务跑到了小核,执行速度也会变慢 查看频率是否没有跑满 –> 表现是核心频率没有达到最大值,比如最大值是 2.8Ghz,但是只跑到了 1.8Ghz,那么可能是有问题的 查看 CPU 使用率,是否已经跑满了 –> 表现是 CPU 区域八个核心上,任务和任务之间没有空隙 查看是否低内存 应用进程状态有大量的 Uninterruptible Sleep | WakeKill - Block I/O HeapTaskDeamon 任务执行频繁 kswapd0 任务执行频繁 SystemServer 进程区域 input 事件读取和分发是否有异常 –> 表现是 input 事件传递耗时,比较少见 binder 执行是否耗时 –> 表现是 SystemServer 对应的 Binder 执行代码逻辑耗时 binder 等 am、wm 锁是否耗时–> 表现是 SystemServer 对应的 Binder 都在等待锁,可以通过 wakeup 信息跟踪等锁情况,分析等锁是不是由于应用导致的 是否有应用频繁启动或者被杀 –> 在 Systrace 中查看 startProcess,或者查看 Event Log SurfaceFlinger 进程区域 dequeueBuffer 和 queueBuffer 是否执行耗时 –> 表现是 SurfaceFlinger 的对应的 Binder 执行 dequeueBuffer 和 queueBuffer 耗时 主线程是否执行耗时 –> 表现是 SurfaceFlinger 主线程耗时,可能是在执行其他的任务 Launcher 进程区域(冷热启动场景) Launcher 进程处理点击事件是否耗时 –> 表现在处理 input 事件耗时 Launcher 自身 pause 是否耗时 –> 表现在执行 onPause 耗时 Launcher 应用启动动画是否耗时或者卡顿 –> 表现在动画耗时或者卡顿 初步分析有怀疑的点之后 如果是系统的原因,首先需要看应用自身是否能规避,如果不能规避,则转给系统来处理 如果是应用自身的原因,可以使用 TraceView(AS 自带的 CPU Profiler)、Simple Perf 等继续查看更加详细的函数调用信息,也可以使用 TraceFix 插件,插入更多的 TraceTag 之后,重新抓取 Systrace 来对比分析 问题可能有很多个原因 首先要把影响最大的因素找出来优化,影响比较小的因素可以先忽略 有些问题需要系统的配合才能解决,这时候需要跟系统一起进行调优(比如各大 App 厂商就会有专门跟手机厂商打交道的,手机厂商会以 SDK 的形式,暴露部分系统接口给 App 来使用,比如 Oppo 、华为、Vivo 等) 有些问题影响很小或者无解,这时候需要跟测试同学沟通清楚 有些问题是重复问题或不同平台的相同,可以在 Bug 库中搜索是否有案例 帮我总结以上systrace中分析响应速度问题的过程,给我形成一个大致的思路和流程,给我讲明白
最新发布
03-08
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值