hoyouly

持有从数据源获取到的数据，并且它可以被 DataBinding 组件观察，当 Activity 被销毁时，它将被取消订阅。 不支持线程切换，其次不支持背压 优点 数据变更的时候更新UI 没有内存泄漏 不会因为停止Activity崩溃 无需手动处理生命周期 共享资源 使用方式 observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> 最常用的方法...

前两天接到一个新的任务，研究百度的PaddleOCR，准备把现有的讯飞OCR替换掉。下载了一个DEMO运行一下，然后就想着替换试试，可是刚开始就出现错误了，已运行就闪退，查看log，发现竟然是一个Error JNI DETECTED ERROR IN APPLICATION: JNI NewStringUTF called with pending exception java.lang.NoSuchMethodError: no non-static metho...

看了一遍，没搞明白这里面说的对象和数据结构的具体意思，但是还是决定下记录下来，后面再仔细品味这一部分。 对象和数据结构区分 对象和数据结构的区别如下 对象暴露行为，隐藏数据，便于添加新的对象而无需修改既有行为，同时也难以在既有对象添加新行为。 数据结构暴露数据，没有明显的行为，便于想既有数据结构添加新的行为，同时也难于在既有函数添加新的数据结构。 如下面代码，就是使用数据结构类型代码，也叫过程式代码 public class Squre { ...

前言 好的软件系统是由一系列读起来不错的代码文件组成的，他们需要拥有一致和顺畅的风格。读者要能确信，他们在一个源文件中看到的格式风格在其他文件中也是同样的用法，绝对不要用不同的风格来编写源码，这样会增加其复杂度。 这个所谓的风格，其实就是指编码风格。每个团队在成立之初，都需要制定一种编码风格，由于这种风格是团队共同决定的，作为团队的一员，我们必须遵守这些规则 规则 我认为的规则应该有以下几条 代码格式化之后再提交，这个是关键，重中之重。 每一行字符的...

我们知道，新建一个Android项目的时候，都会有下面红框中的文件， 虽然Android开发了有好几年了，可是一直都没用过，测试都是直接运行到手机中的，没写过测试用例的，没那个习惯，而且我一般都会把那几个文件给删掉的 可是今天一个偶然的机会，看到了写测试用例，然后就想着玩玩，可是我的项目中都已经没有这些东西了，没办法，重新添加一份吧。 红框中的就是新添加的部分。 想着没啥问题的，可是在MainPresenterTest类中 @RunWith(Moc...

最好的注释就是代码。 如果代码清晰明了，变量/函数命名恰到好处，函数短小精悍，使读者一目了然。那么任何注释都是多余的。 注释是一种失败，是在弥补在代码表达意图时遭遇的失败。 第一次读这话，感觉不可思议。之前一直以为注释是为了解释一些代码的逻辑，尤其是很长一段代码，如果一行注释都不添加，让读者很难有兴趣读下去的。可是现在仔细看来，还真是这个道理，如果代码清晰明了，读者一目了然，还需要注释吗。写注释的常见动机就是有糟糕代码的存在。 与其花时间编写搞错的糟糕代码的...

看到很多人都学习Jetpack，我也想着充充电，学习过程中知道了Hilt 这个库,觉得有点意思，就想着玩一把，刚开始以为很简单，不就是一个依赖注入，简单。 因为前段时间根据学习Android Jetpack? 实战和教程这里全都有！，这个把里面的demo敲了一遍，想着就直接在这上面改吧。 教程是根据Jetpack 新成员 Hilt 实践（一）启程过坑记 这个上面写的，博主写的很详细，而且里面写了好几个遇到的坑。想着有人已经踩过坑了，我就直接一路小跑，飞奔到Hil...

这一章主要是说对函数的整洁 简单概况一下，一个整洁的函数包含以下几点 一个好函数名 只做一件事，并且做好这件事 短小精悍 参数尽量少 避免出现输出参数 避免重复代码 一个好函数名 好名称的标准：长而具有描述性的名称，要比短而令人费解的名称好，长而具有描述性的名称，要比描述性的长注释好。 使用某种命名规范，让函数名称的多个单次容易阅读。 一个好的函数名，应该能解释函数的意图，以及参数的顺序和意图 例如一元函数：函数和参数应该形成...