前言

Tokio 是一个 Rust 的异步运行时，它提供了一个完整的异步 I/O 框架。其实现在AI Code分析工具，比如Cursor、windsurf等基本都能分析出tokio核心实现，本文并不做八股文总结，仅尝试从任务调度实现角度分析，给出我们可以借鉴的设计思想，其中包括：

• 工作窃取实现
• 任务调度优化
• 阻塞任务实现

先来看tokio简单示例：

• 创建运行时

1
2
3
4

let rt = Runtime::builder()
    .worker_threads(4)
    .build()
    .unwrap();

• 提交任务

1
2
3

rt.spawn(async {
    println!("Running on worker thread");
});

• 提交阻塞任务

1
2
3

rt.spawn_blocking(|| {
    // 执行阻塞操作
});

引言

在Android中，独立窗口自绘渲染，典型应用场景比如SurfaceView与手机双边侧滑返回动画面板（WMS.addView）。最近入职一家新公司，涉及对接更底层渲染实现，具体表现在NDK层，获取一个独立Window窗口，上层用Skia进行绘制，并在Android系统中渲染出来。本文旨在分析WMS.addView链路，明淅渲染关键路径，为后面自定义渲染作支持。

背景

最近接手了一个有意思的需求，需求较为简单，在播放音乐时，在关键时间缀或时间段开闭闪光灯，实现音乐节奏和相机闪光联动。在Android上实现快速开闭闪光灯，避谈功耗问题，我们还需要考虑以下风险：

• 避免APP丢帧，闪光和音乐的联动，必须异步线程处理；
• 不能太过频发调用Camera，建议最小与系统vsync信号周期一致，即16ms;
• Camera是共用的硬件资源，多摄像头设备上还需选取摄像头，使用中必须响应Camera或Torch回调；
• 需要兼容手机厂商ROM包碎片化带来的一些问题，诸如魅族等设备与AOSP实现有出入；

在Android中，以Marshmallow（6.0）版本为界，开闭闪光有以下三种实现方案：

表格中的适用版本并不绝对，比如我们碰到了魅族有个7.0机型只适用preview方式。方案实现代码不复杂，我们可以参考AOSP FlashlightController实现。本文记录在研发过程发现的问题，避免其他团队重复入局踩坑。

引言

由于网络和电脑存储问题，一直未在本地编译过engine。近期时间稍有富余，便着手在macOS环境下编译futter engine工程，以方便阅读engine源码和定制化engine。编译flutter不复杂，只是在国内，我们需要翻墙开放给gclient等工具下载源码。本文仅记录在参考flutter wiki Setting-up-the-Engine-development-environment下，碰到的问题，以及给出解决方案，不对依赖工具作安装和介绍。

背景

support迁移至androidX相关包，绝大部分团队万不得已才处理，因其可见的收益过小，反而带来更大研发和测试成本。
考虑androidX相关包已release发布并逐步稳定，众多开源库开始基于androidX进行迭代，Android在Android Studio 3.5上默认将androidX开启，以及后续新API适配等多方因素，微店APP也开始着手迁移工作了。网上博文众多，但实际给出解决迁移效率和迁移质量的方案较少，本文给出微店迁移过程开发的两款功能插件。

引言

诸如读写外置存储、读取联系人、发短信等隐私权限，android在6.0系统开始进行动态授权。但在我国，仅向用户提示授权框还不够，工信部在19年11月初发布了专项整治App八类侵权行为审明 ,其文明确治理以下八类问题：

1.私自收集个人信息；
2.超范围收集个人信息；
3.私自共享给第三方用户信息；
4.强制用户使用定向推送功能；
5.不给权限不让用；
6.频繁申请权限；
7.过度索取权限；
8.为用户账号注销设置障碍。

很不幸，网报通告批评：我司老版本APP中审明了隐私权限，但在隐私文档中并未进行有效说明。收到通告，团队立马对权限进行了扫描，发现APP在AndroidManifest中审明了三项隐私权限，但实际过程并未使用(有些冤大头)。我相信很多团队跟我们面临同个问题，多团队开发下，权限引入问题没有一个有效监管机制。为避免类似问题再次发生，本文给出一个简单有效的代码编译层拦截方案。

在说方案原理之前，我们先假定检测方案是扫描APP AndroidManifest.xml文件中审明的和用户有关的隐私权限，再比对隐私文档以及实际使用场景，进行判别。面对检测方案，我们给出解决思路：

在编译阶段processApplicationManifest task运行后，对Merged Manifest Log文件进行扫描,如果用到了新权限，抛出打包错误，直至问题解决；

看代码更直观，链接：https://github.com/emile2013/nav2main

引言

我相信很多团队都面对过令人头痛的pthread_create 创建线程内存溢出问题。在Android中,典型的pthread_create内存溢出堆栈信息如下：

1
2
3
4
5
6
7
8
9
10

//此异常多为栈内存分配失败
java.lang.OutOfMemoryError
pthread_create (1040KB stack) failed: Try again
1 java.lang.Thread.nativeCreate(Native Method)
2 java.lang.Thread.start(Thread.java:733)
3 java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:975)
4 java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1043)
5 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1185)
6 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
7 java.lang.Thread.run(Thread.java:764)

1
2
3
4
5
6
7
8
9
10

//此异常多为线程数到达上限
java.lang.OutOfMemoryError
pthread_create (1040KB stack) failed: Out of memory
1 java.lang.Thread.nativeCreate(Native Method)
2 java.lang.Thread.start(Thread.java:743)
3 java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:941)
4 java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1009)
5 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1151)
6 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
7 java.lang.Thread.run(Thread.java:774)

出现创建线程内存溢出无非两个原因：
1、进程的栈内存超过了虚拟机的最大内存数；
2、线程数达到了系统最大限制数；
关于线程数达到了系统最大限制数，在国内手机厂商中，华为手机在7.0+手机上已将最大线程数修改成了300。我们APP有大量的华为用户，不得不面对华为系统限制问题。
Android Dalvik和ART，将stack分为了java stack和native stack，本文没去具体实验，从kongxinsun的博客，我们了解到两者总量是1056KB。栈内存回收和堆内存策略不一样，比较简单，当线程结束，线程占用的栈内存也就回收了。

引言

埋点数据，必须是准确的、完备的，否则无法为上层BI产品提供可信数据。端数据采集方案可简单归类为手动埋点、可视化埋点以及无痕埋点三大类。在高DAU APP中，要完全脱离手动埋点，实行无痕埋点方案，在网络带宽、数据存储等方面会带来一定的压力。我司目前停留在手动埋点阶段，在实践过程，我们发现，由于手动埋点依赖上层业务开发人员，也较容易出现漏埋和错埋，并且错误数据的发现存在滞后性，往往在BI输出产品阶段才被发现。
为保证数据的可靠性，以及尽量减少开发人员对埋点的工作投入，我们做了以下几方面工作：

1. 在浏览器端，提供埋点管理平台，为BI、测试、开发等角色提供事件定义、埋点版本追踪、数据验收、数据回归测试等持续集成功能；
2. 在手持端，在APP中嵌入可视化埋点工具，为开发与测试同学提供实时数据校验功能；
3. 简化开发同学编码：控件点击、页面曝光只需一行代码；页面等事件无需开发同学关注，埋点SDK自动上报并补全设备和用户信息；

引言

这篇文章其实是借花献佛，微店的aapt工作，绝大部分是同事区长编码和验证，文章本意在于对插件化架构中aapt相关流程的总结。
在Android编译流程中，aapt主要处理资源相关工作。插件化架构中，需要客户化aapt，让其承担宿主导出符号表、宿主导入符号表、插件导入宿主ap_文件、 修改插件package id、简化书写插件引用宿主资源等额外功能。