通过对Android基本组件的学习，也有接触少部分Android的事件处理，比如按钮的点击事件、选框的状态切换事件。 一、Android事件处理 Android提供了两种方式的事件处理：基于回调的事件处理和基于监听的事件处理。 基于监听的事件处理：主要做法就是为Android界面组件绑定特定的事件监听器，前面小节已经见到大量这种事件处理的示例。 基于回调的事件处理：主要做法就是重写Android组件特定的回调方法， 或者重写Activity的回调方法。Android为绝大部分界面组件都提供了
大部分时候，事件处理器都没有什么利用价值（可利用代码通常都被抽象成了业务逻辑方法），因此大部分事件器更合适，实际上，这种形式是目前是最广泛的事件监听器形式。上面的程序代码就是匿名内部类来创建事件监对于使用匿名内部类作为监听器的形式来说，唯一的缺点就是匿名内部类的语法有点不易掌握 内部类
interface是一些功能的集合，但它只定义了对象必须实现的成员，而不包含成员的实现代码，成员的具体代码由实现接口的类提供。Android对接口的使用场景主要有三类：事件监听器接口、对象序列化结构、线程类相关接口。
事件处理：提供为用户动作响应的机制 Android提供两种方式的事件处理 一、基于回调的事件处理 二、基于监听的事件处理 事件监听处理模型中三类对象： 事件源：EventSource通常是组件（按钮，窗口，菜单） 事件：Event通常是用户的操作 事件监听器：Event Listener通常是对不同事件做出的响应 实现事件监听器如下几种形式： 4.1内部类形式：将事件监听器定义成当前类的内部类 4.2外部类形式：将事件监听器定义成一个外部类 4.3 Activity本身作为一个事件监听器类：让Activit
上一期我们学习了Android中的事件处理，也详细学习了Android中基于监听的事件处理，同时学会了匿名内部类形式，那么本期继续来学习其他四种事件监听器。 一、使用内部类作为事件监听器 和上面的匿名内部类不同，使用内部类可以在当前类中复用该监听器类；因为监听器类是外部类的内部类，所以可以自由访问外部类的所有界面组件，这也是内部类的两个优势。 接下来通过一个简单的示例程序来学习Android使用内部类作为事件监听器。 继续使用WidgetSample工程，在app/main/res
1.前言 在android的进阶之路上，看《android开发艺术探索》实在看不下去了，开始怀疑自己的android基础了，于是找了两本android基础的书把android基础过一遍，还确实发现了好多知识漏洞-基于回调的事件，这个还真以前没用过，然后就想着把android事件处理机制的知识点都整理一遍，嗯，就是这样的。 2.基于监听的事件 基于监听的事件更接近于“面向对象”的事件处理，这种处理方法与java的AWT/Swing的处理方式相同。 2.1监听的处理流程 基于监听的事件
Swing 是目前Java中不可缺少的窗口工具组，是建立图形化用户界面（GUI）程序的强大工具。Java Swing组件自动产生各种事件来响应用户行为。Java将事件封装成事件类，并且为每个事件类定义了一个事件监听器。一个组件注册事件监听器方法，表明该组件要响应指定事件。也就是说我们可以通过注册监听器，监听事件源产生的事件，从而在事件处理程序中处理我们所需要处理的用户行为。 Java Swing中处理各组件事件的一般步骤是： 1． 新建一个组件。
对于图形用户界面的程序来说，事件处理是十分重要的。要想实现用户界面，必须掌握Java事件处理的基本方法。本章将讲解Java AWT事件模型的工作机制，从中可以看到如何捕捉鼠标和键盘产生的事件。另外，本章还介绍如何使用最简单的GUI组件元素，如按钮，以及如何处理由这些组件产生的基本事件。在下一章中，将阐述如何将Swing提供的多个组件组织在一起，并全面地讲述这些组件产生的事件。
将类实现相应的接口，这样类本身就成了一个监听器，使得加入监听器的代码可以更简洁，这种方法适合加入监听器的组件较多，且要求监听器的事件处理代码可以被组件共用，需要注意的是
今天来和大家总结一下有关在进行Java的GUI编程时常用的事件监听函数的基本作用和功能。
这样看起来，类Draw像是类Circle的一个成员，Circle称为外部类。成员内部类可以无条件访问外部类的所有成员属性和成员方法（包括private成员和静态成员）。
在 Android 中 , 使用 Kotlin 开发 , 为 BottomNavigationView 设置 OnNavigationItemSelectedListener 监听接口 ;
这些方法都是View类的，所以像TextView这样看似不是按钮的组件也可以使用这些监听。
之前使用OnSharedPreferenceChangeListener，遇到了点小问题，就是有些时候OnSharedPreferenceChangeListener没有被触发。最近花了点时间研究了一下，小做整理。本文将会介绍监听器不被触发的原因，解决方法，以及其中隐含的一些技术细节。
前言 内存泄漏向来都是内存优化的重点，它如同幽灵一般存于我们的应用当中，有时它不会现身，但一旦现身就会让你头疼不已。因此，如何避免、发现和解决内存泄漏就变得尤为重要，这一篇我们先来学习如何避免内存泄漏
【常用控件属性】 简单提及一下基本的控件，更多的参数和属性参考录播课程或自行查阅。
版权声明：署名，允许他人基于本文进行创作，且必须基于与原先许可协议相同的许可协议分发本文 （Creative Commons）
在编写和维护Java应用程序时，内存泄漏是一个重要的问题，可能导致性能下降和不稳定性。本文将介绍内存泄漏的概念，为什么它在Java应用程序中如此重要，并明确本文的目标，即识别、预防和解决内存泄漏问题。
Android 依赖注入的核心就是通过反射获取 类 / 方法 / 字段 上的注解 , 以及注解属性 ; 在 Activity 基类中 , 获取该注解 以及 注解属性 , 进行相关操作 ;
在之前的博客中写的 AWT 界面程序 , 右上角有三个按钮 , 分别是 最小化 , 最大化 , 关闭 按钮 ,
我们经常会在不经意间写出造成内存泄漏的代码，往往在代码上很难查出来。但是我们可以通过一些辅助工具来检测是否存在内存泄漏，比如通过AndroidStudio的monitors来查看内存的变化情况，或者是
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存。 内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，导致在释放该段内存之前就失去了对该段内存的控制，从而造成了内存的浪费
在上一篇Android内存泄漏的八种可能（上）中，我们讨论了八种容易发生内存泄漏的代码。其中，尤其严重的是泄漏Activity对象，因为它占用了大量系统内存。不管内存泄漏的代码表现形式如何，其核心问题在于：
说起内部类这个词，想必很多人都不陌生，但是又会觉得不熟悉。原因是平时编写代码时可能用到的场景不多，用得最多的是在有事件监听的情况下，并且即使用到也很少去总结内部类的用法。今天我们就来一探究竟。下面是本文的目录大纲：
在Android开发中，内存泄漏是一个常见但容易被忽视的问题。它会导致应用程序占用过多的内存资源，最终影响应用的性能和用户体验。本文将深入探讨Android常见的内存泄漏问题，并提供优化指南，帮助开发者更好地应对这一挑战。
这篇总结主要是基于我设计模式系列的文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢
前面介绍过了计算机内存模型，这是解决多线程场景下并发问题的一个重要规范。那么具体的实现是如何的呢，不同的编程语言，在实现上可能有所不同。
前言注普通内部类静态内部类匿名内部类局部内部类内部类的嵌套深入理解内部类内部类和多重继承内部类和内存泄露
内部类在 Java 里面算是非常常见的一个功能了，在日常开发中我们肯定多多少少都用过，这里总结一下关于 Java 中内部类的相关知识点和一些使用内部类时需要注意的点。 从种类上说，内部类可以分为四类：普通内部类、静态内部类、匿名内部类、局部内部类。我们来一个个看：
1、内存泄漏的根本原因在于生命周期长的对象持有了生命周期短的对象的引用 2、常见场景 （1）资源对象没关闭造成的内存泄漏（如： Cursor、File等） （2）全局集合类强引用没清理造成的内存泄漏（特别是 static 修饰的集合） （3）接收器、监听器注册没取消造成的内存泄漏，如广播，eventsbus （4）Activity 的 Context 造成的泄漏，可以使用 ApplicationContext （5）单例中的static成员间接或直接持有了activity的引用 （6）非静态内部类持有父类的引用，如非静态handler持有activity的引用 3、如何避免内存泄漏 （1）编码规范上： ①资源对象用完一定要关闭，最好加finally ②静态集合对象用完要清理 ③接收器、监听器使用时候注册和取消成对出现 ④context使用注意生命周期，如果是静态类引用直接用ApplicationContext ⑤使用静态内部类 ⑥结合业务场景，设置软引用，弱引用，确保对象可以在合适的时机回收 （2）建设内存监控体系 线下监控： ①使用ArtHook检测图片尺寸是否超出imageview自身宽高的2倍 ②编码阶段Memery Profile看app的内存使用情况，是否存在内存抖动，内存泄漏，结合Mat分析内存泄漏 线上监控： ①上报app使用期间待机内存、重点模块内存、OOM率 ②上报整体及重点模块的GC次数，GC时间 ③使用LeakCannery自动化内存泄漏分析 总结： 上线前重点在于线下监控，把问题在上线前解决；上线后运营阶段重点做线上监控，结合一定的预警策略及时处理 4、真的出现低内存，设置一个兜底策略 低内存状态回调，根据不同的内存等级做一些事情，比如在最严重的等级清空所有的bitmap，关掉所有界面，直接强制把app跳转到主界面，相当于app重新启动了一次一样，这样就避免了
通过他们自身的.setOnClickListener(OnclickListener)方法加入点击事件。
根据文章内容为读者总结摘要。
这篇总结主要是基于我之前设计模式基础系列文章而形成的的。主要是把重要的知识点用自己的话说了一遍，可能会有一些错误，还望见谅和指点。谢谢
最近在搞软件杯的事，要提取按键时的具体信息，包括按下去的时间和弹起的时间，还有按的是哪个键等等，发现用普通的OnClickListener无法做到，于是乎查了一下，就用OnTouchListener这
在多线程编程中，数据共享和线程安全问题是一个很大的挑战。为了解决这个问题，Java 提供了 ThreadLocal 类，它能够让每个线程维护自己独立的变量副本。
在 Java 编程中，内部类（Inner Class）是一个非常强大且灵活的概念，它允许在一个类的内部定义另一个类。内部类可以访问外部类的成员，包括私有成员，这使得内部类在许多编程场景中都非常有用。本篇博客将详细介绍 Java 中的内部类，包括成员内部类、局部内部类、匿名内部类和静态内部类。
Java是垃圾回收语言的一种，其优点是开发者无需特意管理内存分配，降低了应用由于局部故障(segmentation fault)导致崩溃，同时防止未释放的内存把堆栈(heap)挤爆的可能，所以写出来的代码更为安全。
所有的资源文件都会在R.java文件下生成对应的资源id，我们可以直接通过资源id访问到对应的资源。使用mipmap会在图片缩放在提供一定的性能优化，分辨率不同系统会根据屏幕分辨率来选择hdpi，mdpi，xmdpi，xxhdpi下的对应图片，所以你解压别人的apk可以看到上述目录同一名称的图片，在四个文件夹下都有，只是大小和像素不一样而已！当然,这也不是绝对的,比如我们把所有的图片都丢在了drawable-hdpi下的话,即使手机 本该加载ldpi文件夹下的图片资源,但是ldpi下没有,那么加载的还会是hdpi下的图片! 另外,还有一种情况:比如是hdpi,mdpi目录下有,ldpi下没有,那么会加载mdpi中的资源! 原则是使用最接近的密度级别!另外如果你想禁止Android不跟随屏幕密度加载不同文件夹的资源,只需在AndroidManifest.xml文件中添加android:anyDensity="false"字段即可!
内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。最近自己阅读了大量相关的文档资料，打算做个 总结 沉淀下来跟大家一起分享和学习，也给自己一个警示，以后 coding 时怎么避免这些情况，提高应用的体验和质量。
钻石问题(菱形继承)所引发的二义性问题： 假设类B和类C都继承自类A，且都重写了类A的某一个方法，而现在又有类D继承自类A和类B，那么此时类D会继承B、C的该同名方法，那么类D继承的该方法究竟是来自类A还是类B呢？这里产生了歧义。
介绍图 先上个源代码的链接：https://github.com/whenSunSet/MVVMRecycleView RecycleView是Google替代ListView的一种方案，其有着很高的解耦度，让许多开发者抛弃了以往的ListView，那么RecycleView在MVVM架构下又该怎么实现呢？如何实现单条item刷新以及增减Item的自动刷新呢？今天我就要给大家带来一种方便的高解耦度的解决方案。 1.了解几个工具类 我们先来看几个我制作的工具类，这几个工具类可以一直复用。为啥要介绍他
如HashMap、LinkedList等等。如果这些容器为静态的，那么它们的生命周期与程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。
在GUI中，我们看到了如何用图形树来组织一个图形界面。然而，这样的图形界面是静态的。我们无法互动的对该界面进行操作。GUI的图形元素需要增加事件响应(event handling)，才能得到一个动态的
1、根据java的内存模型会出现内存溢出的内存有堆内存、方法区内存、虚拟机栈内存、native方法区内存； 2、一般说的OOM基本都是针对堆内存； 3、对于堆内存溢出主的根本原因有两种 （1）app进程内存达到上限 （2）手机可用内存不足，这种情况并不是我们app消耗了很多内存，而是整个手机内存不足 4、而我们需要解决的主要是app的内存达到上限 5、对于app内存达到上限只有两种情况 （1）申请内存的速度超出gc释放内存的速度 （2）内存出现泄漏，gc无法回收泄漏的内存，导致可用内存越来越少 6、对于申请内存速度超出gc释放内存的速度主要有2种情况 （1）往内存中加载超大文件 （2）循环创建大量对象 7、一般申请内存的速度超出gc释放内存基本不会出现，内存泄漏才是出现问题的关键所在 8、内存泄漏常见场景 （1）资源对象没关闭造成的内存泄漏（如： Cursor、File等） （2）全局集合类强引用没清理造成的内存泄漏（特别是 static 修饰的集合） （3）接收器、监听器注册没取消造成的内存泄漏，如广播，eventsbus （4）Activity 的 Context 造成的泄漏，可以使用 ApplicationContext （5）单例中的static成员间接或直接持有了activity的引用 （6）非静态内部类持有父类的引用，如非静态handler持有activity的引用 9、怎么对内存进行优化呢 三个方向 （1）为应用申请更大内存，把manifest上的largdgeheap设置为true （2）减少内存的使用 ①使用优化后的集合对象，比如SpaseArray； ②使用微信的mmkv替代sharedpreference； ③对于经常打log的地方使用StringBuilder来组拼，替代String拼接 ④统一带有缓存的基础库，特别是图片库，如果用了两套不一样的图片加载库就会出现2个图片各自维护一套图片缓存 ⑤给ImageView设置合适尺寸的图片，列表页显示缩略图，查看大图显示原图 ⑥优化业务架构设计，比如省市区数据分批加载，需要加载省就加载省，需要加载市就加载失去，避免一下子加载所有数据 （3）避免内存泄漏 编码规范上： ①资源对象用完一定要关闭，最好加finally ②静态集合对象用完要清理 ③接收器、监听器使用时候注册和取消成对出现 ④context使用注意生命周期，如果是静态类引用直接用ApplicationContext ⑤使用静态内部类 ⑥结合业务场景，设置软引用，弱引用，确保对象可以在合适的时机回收 建设内存监控体系： 线下监控： ①使用ArtHook检测图片尺寸是否超出imageview自身宽高的2倍 ②编码阶段Memery Profile看app的内存使用情况，是否存在内存抖动，内存泄漏，结合Mat分析内存泄漏 线上监控： ①上报app使用期间待机内存、重点模块内存、OOM率 ②上报整体及重点模块的GC次数，GC时间 ③使用LeakCannery自动化内存泄漏分析 10、真的出现低内存，设置一个兜底策略 低内存状态回调，根据不同的内存等级做一些事情，比如在最严重的等级清空所有的bitmap，关掉所有界面，直接强制把app跳转到主界面，相当于app重新启动了一次一样，这样就避免了系统Kill应用进程，与其让系统kill进程还不如浪费一些用户体验，自己主动回收内存
一、Java内存回收机制 不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址。Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题。在Java语言
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
