joy keeps flowin’ - 什么都想写点
Jetpack系列之ViewModel
ViewModel和架构MVVM中的VM（ViewModel）同名，但并不是一个东西，架构中的ViewModel是和View双向绑定的，这里的ViewModel只能做到利用LiveData更新。 为什么用ViewModel呢？一是把网络请求和数据库读取的逻辑从Activity中放到了ViweModel，分担了一部分Activity的压力；另一个原因是可以在Activity或Fragment重建时保存数据，不会丢失。今天探讨的时第二个问题。
旅行的意义
我总是想弄清楚各种意义，仿佛没有意义的事物就不应该存在。时常看到有人分享各地的标志性建筑、食物或是服饰等等，单独拿出来分享的还是少数，更多的还是与某些东西合影的照片。即使去旅行的时间非常短，但一定会有那么两三个带标志性的，标志性物品和某个城市、某个地区、某种文化划上了等号。
Jetpack系列之Lifecycle
Android中又越来越多组件依赖Lifecycle，从来不好奇Lifecycle是什么东西，又是怎么起作用的吗？我很好奇。 LifecycleOwner # 通常的用法往往是从LifecyclerOwner中拿到Lifecycle对象，之后add Oberver或者remove Observer。
Jetpack系列之LiveData
Jetpack中最不陌生的大概就是LiveData了，LiveData的两个特点：和lifecycleOwner绑定且监听数据变化。用过的哪个不说好？ 流程 # 常用的LiveData的形式大概是这样的：
Android屏幕适配和最小宽度
凡事总要问为什么。为什么需要屏幕适配？ 众所周知，Android是一个较开发的系统，允许各家厂商定制修改AOSP，选用不同规格的硬件，包括CPU、内存、电池、传感器等等等等。当然屏幕也在其中。也因此，大家手上的手机屏幕大不相同，体现在屏幕的尺寸、分辨率上。
material风格吸顶效果
前言 # Material Design是Google在2014年的I/O大会上发布的一种设计规范，包括布局、颜色、形状、声音、动效等。面向的是Android、iOS、Web和Flutter。对自己的Android，Google还推出了一系列组件、主题帮助开发者快速、方便的实现Material Design的效果。下面是几个能用在大部分实际项目中的控件：
实现Material风格的ActionBar滚动变色
许许多多Material风格的Android应用支持滚动后改变Action Bar和状态栏的颜色, 放一张示例图: 实现 # 外层ViewGroup改用CoordinatorLayout # CoordinatorLayout才支持内部View滚动后调用behavior的方法, 自定义View也能实现.
验证suspend all threads
验证suspend all threads # 对应KOOM实现流程, 结合对比几种场景, 验证KOOM中fork前suspend和resume后作用. suspend和resume # suspendAndFork 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 pid_t HprofDump::SuspendAndFork() { KCHECKI(init_done_) if (android_api_ < __ANDROID_API_R__) { suspend_vm_fnc_(); } else if (android_api_ <= __ANDROID_API_S__) { void *self = __get_tls()[TLS_SLOT_ART_THREAD_SELF]; sgc_constructor_fnc_((void *)sgc_instance_.get(), self, kGcCauseHprof, kCollectorTypeHprof); ssa_constructor_fnc_((void *)ssa_instance_.get(), LOG_TAG, true); // avoid deadlock with child process exclusive_unlock_fnc_(*mutator_lock_ptr_, self); sgc_destructor_fnc_((void *)sgc_instance_.get()); } pid_t pid = fork(); if (pid == 0) { // Set timeout for child process alarm(60); prctl(PR_SET_NAME, "forked-dump-process"); } return pid; } resumeAndWait
Cow and Hprof
COW(copy on write) # Linux通过fork()和exec()函数族创建新进程。 为什么通过这种方式，而不是从头开始创建新进程？ # Of course, one big question you might have: why would we build such an odd interface to what should be the simple act of creating a new process? Well, as it turns out, the separation of fork() and exec() is essential in building a UNIX shell, because it lets the shell run code after the call to fork() but before the call to exec(); this code can alter the environment of the about-to-be-run program, and thus enables a variety of interesting features to be readily built. The shell is just a user program4 . It shows you a prompt and then waits for you to type something into it. You then type a command (i.e., the name of an executable program, plus any arguments) into it; in most cases, the shell then figures out where in the file system the executable resides, calls fork() to create a new child process to run the command, calls some variant of exec() to run the command, and then waits for the command to complete by calling wait(). When the child completes, the shell returns from wait() and prints out a prompt again, ready for your next command. The separation of fork() and exec() allows the shell to do a whole bunch of useful things rather easily. For example: prompt> wc p3.c > newfile.txt In the example above, the output of the program wc is redirected into the output file newfile.txt (the greater-than sign is how said redirection is indicated). The way the shell accomplishes this task is quite simple: when the child is created, before calling exec(), the shell (specifically, the code executed in the child process) closes standard output and opens the file newfile.txt. By doing so, any output from the soonto-be-running program wc is sent to the file instead of the screen (open file descriptors are kept open across the exec() call, thus enabling this behavior [SR05]).
查身份证的权力
查身份的权力 # 今日周五, 回家路上心情尚可. 快到小区门口时见到红蓝灯交互闪动, 心想不妙: 又他妈要查身份证. 走到门口时, 果不其然. 心中即使有不甘心仍报上身份证号码. 从小区门口走到卧室的途中越想越气. 遂查阅一番查阅身份相关规定.如下: