我的进阶曲线之三

WAKELOCK TYPE:
PARTIAL_WAKE_LOCK:保持CPU 运转，屏幕和键盘灯有可能是关闭的。
SCREEN_DIM_WAKE_LOCK：保持CPU 运转，允许保持屏幕显示但有可能是灰的，允许关闭键盘灯
SCREEN_BRIGHT_WAKE_LOCK：保持CPU 运转，允许保持屏幕高亮显示，允许关闭键盘灯
FULL_WAKE_LOCK：保持CPU 运转，保持屏幕高亮显示，键盘灯也保持亮度
ACQUIRE_CAUSES_WAKEUP：强制使屏幕亮起，这种锁主要针对一些必须通知用户的操作.
ON_AFTER_RELEASE：当锁被释放时，保持屏幕亮起一段时间


alarmmanager和wakelock 前者是应用会利用alarm服务去做一些事情，后者保证持有锁阶段的状态。两者完全是两码事。


thaw 解冻
hibrenate 冬眠
intentionally 故意地
repository 仓库
despite 尽管
preportinal 比例
transient 瞬间
evict 驱逐
leverage 杠杆
respectively 分别是（副词）
senarios 场景
chronologically 按时间顺序地
mentor 导师
vulnerability 弱点 漏洞
translucent半透明的
partial 部分的
dimension 维度，面积
Memory Churn内存抖动
invalidate 作废
counterfeit 山寨商品
enroll 录入，登记
vibe  bohibian vibe 波西米亚风格
infrastructure 基础设施

UX
hierarchy 等级层次
tremble 颤抖
flicker 花屏
stutter 口吃，卡顿
jank    闪避
tearing 撕裂
purgeable 可清除的








/sys/module/lowmemorykiller/parameters/adj
/sys/module/lowmemorykiller/parameters/minfree


echo 13 > /proc/sys/vm/swappiness
cat /proc/sys/vm/swappiness


echo $((128*1024*1024)) > /sys/block/zram0/disksize
cat /sys/block/zram0/disksize


busybox mkswap /dev/block/zram0
busybox swapon /dev/block/zram0




我们查看机器内存时，会发现MemFree的值很小。这主要是因为，在linux中有这么一种思想，内存不用白不用，因此它尽可能的cache和buffer一些数据，以方便下次使用。但实际上这些内存也是可以立刻拿来使用的。
所以 空闲内存=free+buffers+cached


In fact, any kernel page allocation done and tracked by drivers will not be tracked by the kernel, thus counting for the LOST RAM.


/sys 和 /proc一样也是一个文件系统：sysfs。


Page cache实际上是针对文件系统的，是文件的缓存，在文件层面上的数据会缓存到page cache。文件的逻辑层需要映射到实际的物理磁盘，这种映射关系由文件系统来完成。当page cache的数据
需要刷新时，page cache中的数据交给buffer cache，但是这种处理在2.6版本的内核之后就变的很简单了，没有真正意义上的cache操作。
造成了双缓冲，因为文件读写最后还是转化为对块设备的读写。
Buffer cache是针对磁盘块的缓存，也就是在没有文件系统的情况下，直接对磁盘进行操作的数据会缓存到buffer cache中，例如，文件系统的元数据都会缓存到buffer cache中。


Low Memory Killer与OOM的区别
OOM即Out of Memory是标准linux Kernel的一种内存管理机制，Low Memory Killer在它基础上作了改进：
OOM基于多个标准给每个进程打分，分最高的进程将被杀死 ；Low MemoryKiller则用oom_adj和占用内存的大小来选择Bad进程，OOM在内存分配不足时调用，而Low Memory Killer每隔一段时间就会检查，一旦发现空闲内存低于某个阈值，则杀死Bad进程。


我们现在知道了lowmemorykiller 是基于cache shrinker 机制的，具体而言就是lmk去注册一个shrinker，而整个shrinker链表又是由kswapd进程来管理的，
kswapd进程每次（内存紧张的时候）会遍历shrinker链表，对每一个节点执行相应已经注册的回调函数。


AMS仅仅是根据应用进程前后台的关系调整oom_adj值，剩下的就是oom_killer要干的事情了。AMS本身并不参与内存管理。


OnLowMemory 后台进程都已经杀完了，此时触发。OnTrimMemory 内存紧张的时候开始触发。比OnLowMemory要早。


进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。


云何应住 云何降伏其心


Limit the amount of time covered by the trace with the -t, --time option. The default length of a trace is 5 seconds.
就是说，systrace是从你点击确定的那一刻开始计时统计信息的。


SurfaceFlinger的Active Graphic Buffer填充好数据之后，就会被post到FB去显示。


在SurfaceFlinger服务端，FramebufferNativeWindow::FramebufferNativeWindow() 中指定的分配绘图缓冲区的回调函数是FramebufferNativeWindow::dequeueBuffer()。


另外，如果存在HWC设备，则surfaceflinger交给HWC去合成，如果没有HWC设备，则surfaceflinger会通过eglswapbuffers，交给GPU去合成，代码流程是不同的。


am start -W -n com.android.contacts/com.android.contacts.ui.main.ContactMainActivity


IPowerManager.aidl  --- 在这里实现的。
interface IPowerManager 
{ 
// WARNING: The first four methods must remain the first three methods because their 
// transaction numbers must not change unless IPowerManager.cpp is also updated. 
void acquireWakeLock(IBinder lock, int flags, String tag, String packageName, in WorkSource ws); 
void acquireWakeLockWithUid(IBinder lock, int flags, String tag, String packageName, int uidtoblame); 
void releaseWakeLock(IBinder lock, int flags); 
void updateWakeLockUids(IBinder lock, in int[] uids); 


我们发现su也设置了SUID位，这样普通用户也可以运行su程序，su程序会验证root密码，如果正确su程序可以把用户权限提高的root


power.c                                                      set_screen_state//此函数作为上层的最后一个函数，会打印出标志性的log，*** set_screen_state %d，如果打出这个log，至少证明从APP-HAL都是在正常干活的


android 会根据硬件（或者模拟）vsync信号，衍生出来两条soft vsync信号，app_UI 和 surfaceflinger。
其中，app_UI用来给app提出绘制请求时候，也就是说，只有app_UI的vsync信号上报，才会发起绘制请求。
接着，只有 surfaceflinger vsync信号上报上来，surfaceflinger才会参与界面的合成。


packages.list记录了如下数据：pkgName，userId，debugFlag，dataPath（包的数据路径）


在TCP传输里面，一定要有窗口的概念。我们不说一次次的连接，更多是是每个窗口期的链接。


寄存器R13在ARM指令中常用作堆栈指针SP
R14称为子程序链接寄存器LR(Link Register)
寄存器R15用作程序计数器(PC)
寄存器R16用作CPSR(CurrentProgram Status Register，当前程序状态寄存器)


binder_mmap (servicemanager)


其功能为：从当前进程中获取用户态可用的虚拟地址空间（vm_area_struct *vma），在mmap_region中真正获取vma，然后调用file->f_op->mmap(file, vma)，调用具体的支持mmap的驱动来处理。
binder_mmap (binder dirver)
刚开始(binder设备创建的时候)binder_mmap只是为进程映射一个物理页，
当后续如果映射的内存不够用的时候，根据需要增加建立相应的新的物理页映射，用于满足接下来的物理内存分配需求。
而这个动作就是在binder_alloc_buf函数中实现的。
就是当系统的物理内存不够用的时候，
通过binder_alloc_buf动态的建立需要的物理内存的映射（但最少是一个物理页，因为最少的映射单元就是一个物理页），
具体就是 binder_update_page_range 函数。
一句话，binder设备创建的时候，就准备好了充足的虚拟地址空间，但第一次只map一页的真正的物理空间。
之后，在binder事务需要的时候，才会重新从已经申请的（物理空间）free-list（RB树结构）查找并更新这棵树，
找不到的话，才会调用 binder_update_page_range 去申请物理空间。
另外，事务所需空间，是从目标进程内存去申请的。 


kmem_cache_alloc --- slab 申请


情感的逻辑就是情商


adb shell dumpsys power > power.txt查看wakelock使用状态


android 三缓存技术的核心还是： 新增加了一个缓冲区。
原来是两个缓冲区，只有等到显示完成释放（显示用）缓冲区后，在垂直同步vsync时钟信号协调下，去交换缓冲区。
即把准备好（待显示的）数据交换到（显示用）缓冲区，而（准备）缓冲区清空，准备下一帧数据。
目前新的方案是三个缓冲区，
如果（显示用）缓冲区一直被占用着，导致（准备）缓冲区无法（按时）交换，此时只能等待。则此时新创建个（准备）缓冲区，
准备（下下一组）待显示数据，不至于系统一直在等待状态。
三缓存一个明显的弊端是：从数据输入到屏幕响应的周期，显得更长了。但是整体上，显示系统会更有效率，用户体验上就是，系统整体上流畅了。
所有，三缓存也不是时刻都开着的，三缓存和两缓存动态协调工作。


现实主义题材的作品，要真实地反映当前物质世界。
一个比较明显的标准就是，事件或者人物命运的发展，是现实条件发展的必然，而不是作者自身的意志体现。


SElinux 是对linux 权限管理的一个扩展。
linux默认的权限管理为DAC，你可以理解为当前用户一确定，则所有操作权限就确定了，
所以，这种情况下，想方设法获得root权限，就可以随便了。
但是，selinux在此基础上，多加了一个判断MAC，核心思想就是，文件和进程，新增了上下文权限配置文件（sepolicy），
当要操作文件的时候，先判断当前用户，再读取上下文配置文件，取得进程和文件的上下文，多了这个上下文判断。


android intent的实质仍然binder通信。


把一个字符串“adcdefg”逐个素数标识：2 3 5 7 11 13 17,它们的乘积唯一地代表了这个字符串，基本思想，可发散。


adb shell pm list permissions -f > perm.txt
 
去芜存菁


所谓KPI即Key Performance Indicator


 好像还是不能理解SharedBufferStack？好吧，回忆一下，一般我们就绘制UI的时候，都会采用一种称为“双缓冲”的技术。双缓冲意味着要使用两个缓冲区，其中一个称为Front Buffer，另外一个称为Back Buffer。UI总是先在Back Buffer中绘制，然后再和Front Buffer交换，渲染到显示设备中。这下就可以理解SharedBufferStack的含义了吧？SurfaceFlinger服务只不过是将传统的“双缓冲”技术升华和抽象为了一个SharedBufferStack。可别小看了这个升华和抽象，有了SharedBufferStack之后，SurfaceFlinger服务就可以使用N个缓冲区技术来绘制UI了。N值的取值范围为2到16。例如，在Android 2.3中，N的值等于2，而在Android 4.1中，据说就等于3了。
 
 “内存文件”---各类mmap哦
 
 1毫升水体积是1立方厘米，重量是1克
 
 100%即1倍的增长率情况下，增长极限是e 
 50%的情况下，e^(1/2)
 300%的情况下，e^(3)
 
 刘彻为世宗孝武皇帝 --- 庙号
 汉武帝 --- 谥号
 
 把可以延迟的处理从硬中断处理程序独立出来，这样这个处理可以在开中断的情况下运行，这个处理就是软中断。可见，软中断的这种脱离可以大大缩短硬中断的响应时间，对于很多实时应用来说及其重要。
 
用如下命令  kill -3 $pid，Anr 目录下会生成一份 trace


system工作方式是，将后续的命令字符都传递给shell，交由shell来执行，这样很可能被攻击者利用shell的漏洞进行攻击。
而execve则是创建子进程，参数是传递给子进程的，因此可以防止此类攻击。


cmd和powershell两个控制台，是不同的环境变量配置，jar命令，在powershell中可以用，但是在cmd中不一定可用。


android 在 2D 绘制方面有自己的canvas库，3D方面必须依赖openGL。但是2D绘制仍然可以采用硬件加速的方式，
4.4之后的android默认都是打开的，由应用自定义（app window  view）。
invalidate （废止）实际上就仰仗于软件实现或者硬件加速。 


对于每一个应用程序来说，都有一个ActivityThread来表示应用程序的主进程，而每一个ActivityThread都包含有一个ApplicationThread实例，它是一个Binder对象，负责和其它进程进行通信。


adb shell dumpsys activity broadcasts，可以查看当前已经注册了的receiver。


为天地立心，为生民立命，为往圣继绝学，为万世开太平.


梦建立了人类意识和潜意识之间的一座桥梁，梦中出现的所有素材，都是有意义的，人，是无法欺骗自身的。


斯德哥尔摩综合症
该综合症是指某一具体情境中的受害者或犯罪活动中的被害人对于加害人或罪犯逐渐产生的情感依赖。这种情感产生的根源是，在加害人可以轻而易举处理受害者的前提下，或者说受害者的生死操纵在加害人手里，而加害人在受害者完全失去反抗能力的前提下还能让受害者活下来或倒施小恩小惠。于是，受害者不胜感激，对加害人产生一种心理上的依赖感。


当没有Camera或Video的时候，如果UI Layer即HWC_FRAMEBUFFER Layer小于等于3个且都满足图像格式条件，那么这些Layer的CompositionType属性会被修改为HWC_OVERLAY，为每个Layer分配pipe，经LayerMixer0合成经DMA_P输出，这就是HWC。由于BF pipe能力条件的限制，不使用其做HWC，而RGB1做预留的base layer Framebuffer使用，所以标榜的4-layer mdp composition support实际只能接受SurfceFlinger的3个Layer做合成，也就是SurfaceFlinger的属性debug.mdpcomp.maxlayer=3。当超过3个Layer的时候，由于管道数量的限制，不能够再使用LayerMixer0，就使用GPU render，也即每个Layer->draw。当然GPU render也算是一个Hardware Composition，CompositionType方式的其中之一就是GPU。


input keyevent KEYCODE_HOME


定制符合项目需求的安全策略
  SELinux的安全检查覆盖了所有重要的系统资源，每次MAC访问失败都会记录在内核中，如下：
  <6>[82.950769] type=1400 audit(1882976.149:5): avc: denied { write } for pid=3194 comm="BluetoothAdapte" name="aplog" dev="mmcblk0p22" ino=88 scontext=u:r:bluetooth:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir
  上面的log记录了一条违反安全策略的访问信息，即BluetoothAdapte进程试图在data分区写目录失败。
  scontext表示进程的SContext，u:r:bluetooth:s0，属于bluetooth域；
  tcontext表示目标的SContext，u:r:system_data_file:s0，属于system_data_file类型;
  tclass表示进程要操作的ObjectClass，dir表示目录；
  mmcblk0p22是userdata分区，write表示写操作。
  连起来就是bluetooth域的进程（BluetoothAdapte），对system_data_file类型的dir执行write操作失败。明确了失败原因，我们就可以在安全策略配置文件中定制我们自己的策略了：
  [external/sepolicy/bluetooth.te]
  allow bluetooth system_data_file:dir w_dir_perms;
  w_dir_perms是一个宏，其定义在global_macros中，包含了write相关操作：
  [external/sepolicy/global_macros]
  define(`w_dir_perms', `{ open search write add_name remove_name }')
   

当因为某种原因访问失败的时候，copy_from_user()会有纠错处理。直接访问就没有 

ION是google为android重新开发的一套全新的内存管理机制，
把内存按照用途（是否物理连续，是否虚拟连续等等）分类。针对不同使用需求，有不同的内存分配策略，
user只需要指定所申请的内存类型，系统会按照指定的策略去分配内存。
linux kernel只是提供了一组API如kmalloc/vmalloc/get_free_pages等。
ION的工作机制是提供了一个设备节点/dev/ion，内存申请操作就是对该设备的操作，从而实现对内核空间的访问请求。

在总线上注册设备时，会遍历该总线上已注册的驱动，用总线的match方法判断是否有匹配的驱动，如果有，则调用驱动的probe函数；在总线上注册驱动时，会遍历该总线上已注册的设备，用总线的match方法判断是否有匹配的设备，如果有，则调用驱动的probe函数。即，不管是先注册设备还是先注册驱动，总线的match方法会作用于所有组合，如果匹配了，则调用驱动的probe方法，这样就探测到了。
bus_for_each_drv()是对BUS上所有的Driver都进行__device_attach()操作；同样的，bus_for_each_dev()是对BUS上所有的Device都进行__driver_attach()操作。
BUS上实现的.match()函数，定义了Device和Driver绑定时的规则。比如Platform实现的就是先比较id_table，然后比较name的规则。如果BUS的match()函数没实现，认为BUS上的所有的Device和Driver都是match的，具体后续过程要看probe()的实现了。
Probe的规则是：如果BUS上实现了probe就用BUS的probe；否则才会用driver的probe。


proximity 接近，亲近，近似度