企业官网建设流程全解析

做ROM开发那阵子，我被一个"跨进程共享配置"的问题折腾得够呛：Java层要判断当前设备处于哪种运行环境，C++层也要读同一个值，两边还得实时同步。SharedPreferences在Java层用起来挺顺，但Native那边根本不可能去碰它；后来改成写文件，文件锁、写一半断电、多进程读到旧数据，各种糟心事全来了。最后我把方案彻底换成了Android系统自己维护的那套全局配置机制——SystemProperties，问题一下清爽了。

这篇文章我不打算只堆API。系统属性的底层存储方式、读和写为什么是两条完全不同的路径、SELinux对setprop的权限约束、以及我这些年踩进去又爬出来的坑，都会一起写清楚。不管你是做应用开发、framework开发还是Native开发，这篇文章应该都能帮你省下不少排查时间。

1. 为什么Android要专门维护一套"全局属性"

1.1 多进程架构下的配置同步难题

Android应用天生是多进程的，AMS、WMS这些系统服务各自跑在独立进程，App的业务代码也跑在独立的app进程里。这么多进程要共享同一份配置，最直接的想法是做个Binder服务，需要时通过服务端查询。但仔细想想，很多配置是每个进程都想随时看、反复看的，比如"系统是否已经启动完成""当前设备时区""设备型号"。如果每次读都要走一次Binder，即使Binder性能再好，高频访问下也是不小的开销。

SystemProperties选择的方案很不同：它在init进程启动阶段就创建好一块共享内存，所有进程通过内存映射（mmap）直接把这共享内存映射到自己进程的地址空间里。也就是说，"读属性"在进程看来就是读自己进程里的一段内存，根本不走Binder、不需要向任何服务发起请求。这也是getprop每次执行都飞快、在代码里频繁读取几乎无感知的原因。

1.2 和常规做法放在一起看差距

我后来整理过一个对比，拿SystemProperties和SharedPreferences、普通文件、环境变量做过一轮比较：

这套机制最适合的场景，一句话概括就是：短小、需要全局可见、读取频繁、写入低频的配置项。反过来说，它不适合存大对象，属性值上限很小；也不适合高频写入，因为写路径要经过属性服务，大量setprop会对系统造成压力。搞清楚边界比背API更重要。

2. 属性从开机到运行时的存储与流转

2.1 属性区域在开机时是怎么填充的

init进程是Android用户态的第一个进程。它在初始化阶段会创建属性共享内存区，然后把编译镜像里携带的属性文件挨个读进来填充。常见的属性文件包括/system/etc/prop.default、/system/build.prop、/vendor/build.prop、/odm/etc/build.prop、/product/etc/build.prop，不同Android版本路径略有差异，但顺序逻辑是一样的：后加载的属性如果和前面重复，会覆盖先加载的值。

属性还会从内核cmdline里解析出ro.boot.*系列，比如当前设备是从什么模式启动的。最后，如果之前存在persist.开头的持久化属性，init会从/data/property目录把历史值重新读出来并覆盖到属性区，保证用户已经改过的配置重启后不丢失。

2.2 读与写是两条完全不同的路径

很多人一开始没意识到，SystemProperties的读写机制是完全不对称的：

• 读属性：进程直接读共享内存，零系统调用级别的开销。
• 写属性：进程通过socket把请求发给init进程内的属性服务，属性服务先做权限检查（SELinux），然后更新共享内存区。如果属性名以persist.开头，还会把值异步写入持久化文件。

这个不对称非常关键。getprop和setprop虽然看起来都是"属性操作"，但setprop的实际开销比getprop大得多。曾见过有同事拿setprop当内存标记用，高频写入导致设备卡顿，就是因为忽略了写路径的代价。

2.3 属性命名空间的前缀语义

系统属性没有一个正式的"注册中心"，但它有一套约定俗成的命名空间，前缀决定了属性的语义和处理方式：

命名前缀本质上是属性系统的"软约定"，但实际操作中一定要遵守。尤其是ro.和persist.，它们的行为和普通属性有本质区别，后文我会专门讲坑。

3. 不同开发场景下，属性怎么读写才靠谱

3.1 Java层：SystemProperties是个隐藏API

Java层读系统属性，标准入口是android.os.SystemProperties，但它被标了@hide，普通应用在编译期直接调用会报错，因为SDK里这个类不是公开API，Android Studio根本看不到。

应用开发最常用的方式是反射：

public static String getSystemProperty(String key, String defValue) { try { Class<?> clz = Class.forName("android.os.SystemProperties"); Method get = clz.getMethod("get", String.class, String.class); return (String) get.invoke(null, key, defValue); } catch (Exception e) { return defValue; } }

调用时传入默认值兜底：

String mode = getSystemProperty("sys.app.env", "prod");

这里有个需要注意的点：Android 9（API 28）开始对隐藏API做限制，反射调用不一定在所有ROM上都能成功。我实测下来，大多数国产ROM对SystemProperties.get这种核心类放宽了限制，但release包还是要做好捕获异常、返回默认值的降级方案，别让反射失败把业务逻辑带崩。

3.2 Native层：用 __system_property_get 而不是 property_get

C/C++层读属性，老代码里最常见的是property_get。但这个函数在新版NDK里已经不再推荐使用了，系统源码里虽然还大量存在，但NDK工具链中更稳定的接口是__system_property_get：

#include <sys/system_properties.h> char value[PROP_VALUE_MAX] = {0}; if (__system_property_get("sys.app.env", value) > 0) { // value 里就是属性值 }

PROP_VALUE_MAX表示属性值的最大长度，不同Android版本定义不同，老版本一般是31，新版本提升到92。写Native代码时，缓冲区大小一定要按系统头文件里的常量来，不要自己拍脑袋写死一个数字。

property_set的情况也一样，Native层写入推荐使用__system_property_set。不过要牢记：写属性在Android 8之后受到SELinux限制，不是进程想写就能写的，具体权限在下一章细说。

3.3 命令行：getprop和setprop是调试主力

日常调试还是命令行最直接：

# 查看所有属性 adb shell getprop # 查看单个属性 adb shell getprop ro.build.version.sdk # 按关键字搜索 adb shell getprop | grep boot # 设置属性（普通调试机很可能被权限拒绝） adb shell setprop sys.app.test true

普通App通过adb setprop往往会看到权限失败，这很正常。setprop的权限受SELinux策略管控，userdebug/eng版本下shell域有更大的操作空间，但release版本限制很严。

3.4 所有属性本质上都是字符串

SystemProperties不区分int、boolean，底层全是字符串。所以实际开发里能看到ro.debuggable=1、sys.boot_completed=1、persist.sys.timezone=Asia/Shanghai，读取方自己负责解析。Java层常见的解析方式：

boolean debug = "1".equals(getSystemProperty("ro.debuggable", "0")); int sdkInt = Integer.parseInt(getSystemProperty("ro.build.version.sdk", "0"));

这种约定简单但不无风险，解析时要记得判空和异常捕获。曾遇到同事用Integer.parseInt解析一个厂商属性，结果某台设备上属性值为空，直接抛异常，整个启动流程被打断。

4. 从零创建自定义属性并跑通读写

4.1 编译期挂载静态属性

做ROM定制时经常需要带一个编译期确定的属性，比如产品线标识、工厂模式开关。最典型的做法是在产品mk文件里加：

PRODUCT_PROPERTY_OVERRIDES += ro.company.factorymode=0

这个变量会在打包时写入build.prop，编译产物安装到设备后，开机阶段init会读入系统属性区。加的时候注意+=后面别漏了空格，这个细节坑过不少刚接触构建系统的人。

因为属性名带了ro.前缀，开机后它就只读了，App端没法动态改。如果确实需要运行时修改，就不应该起ro.开头的名字。

4.2 运行时动态写入属性

如果属性名不是ro.开头，就可以在系统启动后动态写入。Java层代码如下：

public static void setSystemProperty(String key, String value) { try { Class<?> clz = Class.forName("android.os.SystemProperties"); Method set = clz.getMethod("set", String.class, String.class); set.invoke(null, key, value); } catch (Exception e) { // 写入失败要降级处理 } }

Native层则是：

__system_property_set("sys.app.env", "staging");

但这里要特别提醒：运行时动态写入不是所有进程都有权限的。普通App调用SystemProperties.set()，绝大多数ROM上会直接失败，因为SELinux策略根本没有授予app域写系统属性的权限。只有系统应用、root进程、shell域，以及通过PropertyContexts配置过的特定域，才有写入资格。

4.3 用属性控制进程行为

系统属性最常见的价值之一，是让系统服务和App读取同一个开关。比如我在某个项目里设计了一个"远程诊断模式"：

• 系统服务启动时读persist.sys.diagnostic，决定是否开启日志收集。
• 售后人员通过工程命令把persist.sys.diagnostic置为true。
• 重启后属性依然保留，系统服务读到true，自动进入诊断模式。

因为persist.前缀保证持久化，这个方案比普通文件操作干净得多，不需要单独维护配置文件的读写权限和路径生命周期。

4.4 SELinux权限是怎么管住setprop的

Android 8之后，setprop的权限完全由SELinux策略控制。每个属性在property_contexts文件中都有对应的上下文标签，比如：

sys.app.test u:object_r:system_prop:s0

当某个域尝试写入这个属性时，SELinux会检查该域是否对这个标签拥有写入权限。没有权限时，logcat或kernel日志里会出现典型的avc: denied { set }记录。定制ROM时如果自定义属性写入失败，优先查这个：

adb shell dmesg | grep avc

SELinux策略文件的修改需要重新编译boot镜像，这部分对普通App开发者不可控，但做系统定制时几乎必踩。

5. 实战中那些让人抓狂的坑

5.1 ro. 属性一旦设置，当前开机周期内改不回去

这是最经典的坑。有一次我想做个"工厂测试模式"，第一次运行设置ro.factory.test=1，测试结束想把属性改回0，结果setprop直接失败，代码里property_set返回值也异常。

原理很简单：ro.前缀的属性在属性服务里有特殊逻辑，一旦写入就不能在当前开机周期内修改（可能是为了保序和缓存一致性考虑）。所以调试这类开关时，千万别用ro.前缀。非要只读语义，就老老实实放在build.prop里通过编译期确定；运行时开关用sys.或persist.好了。

5.2 persist. 属性不是无限次擦写闪存

persist.属性每次写入都会触发持久化存储写入，频繁写入会消耗闪存寿命，特别是嵌入式设备上这个损耗更敏感。我见过有人把业务计数器或大流量统计结果写进persist.属性，结果设备用一段时间后/data/property分区出现问题，开机异常。

我的经验法则是：persist.只放真正需要跨重启保留的"低频率配置"，比如用户时区、模式开关；高频临时状态用sys.就够了。如果/data/property下的属性文件出现损坏，某些设备可以通过双清恢复，但系统定制场景下这种问题排查起来非常痛苦。

5.3 启动早期读属性会拿到空值

框架开发里最容易踩的是时序问题。你的服务在开机早期启动，但某个属性要等另一个服务运行到某个阶段才会被写入，你提前去读，拿到空值。

我之前的做法是在自定义init服务里通过trigger控制启动时机：

on property:sys.boot_completed=1 start my_service

或者代码里等待属性出现：

while (!"1".equals(getSystemProperty("sys.boot_completed", "0"))) { Thread.sleep(100); }

轮询虽然不优雅，但简单直观。属性系统本身也在某些版本里提供过监听机制，不过跨版本稳定性一般，轮询反而是兼容性最好的方案。

5.4 hidden-api限制导致反射失败

应用层反射SystemProperties不是一个完全稳定的路径。Android 9之后的hidden-api限制、不同厂商ROM对豁免名单的修改，都会让反射行为不一致。我遇到过一次，某厂商设备上反射SystemProperties.get直接抛NoSuchMethodException，排查后发现对方的ROM对隐藏API做了更严格的过滤，把方法调用给挡了。

后来我的兜底策略是：能走公开API就不走反射，比如设备型号用Build.MODEL，SDK版本用Build.VERSION.SDK_INT；必须读系统属性时才用反射，并且一定要catch所有异常，读到空就返回默认值。对依赖某个自定义属性的功能，宁可功能降级，也不能让整个流程崩溃。

5.5 ctl. 属性控制服务时容易配对出错

ctl.前缀是用来和init内部服务管理交互的，比如：

# 启动/停止/重启 init 管理的服务 setprop ctl.start my_service setprop ctl.stop my_service setprop ctl.restart my_service

很多人不知道的是，这些操作虽然看起来是"设置属性"，实际上是属性服务收到请求后转给init去执行服务状态的变更。写属性的人用的都是ctl.同一个前缀，但"服务名"其实是值里的内容。如果服务名拼错了，属性写入本身不报错，服务却不会启动，非常容易让人白排查半天。所以这类调用要做返回值检查和前后状态验证。

5.6 自定义属性写入后读出来是旧值

还有一种情况：属性明明写成功了，读出来却是旧的。多数时候是不同进程对属性共享内存映射的更新时机问题，即写完立即在另一个进程读，理论上应该能读到最新值，但如果中间有缓存层（比如Java层某些ROM自己做的包装），可能不是实时生效。另一个常见原因是值太长被截断，属性值长度超限后并不会报错，只会静默截断，所以读出来的值看起来"不对"。排查时先adb shell getprop确认实际存储值，别直接怀疑代码。

6. 日常工作中实用的属性调试技巧

6.1 观察属性变化的几个土办法

系统没有提供一个特别直观的"属性变化监听"命令，我平时最常用的是在终端里循环查看：

while true; do adb shell getprop sys.app.test; sleep 1; done

在另一个终端里做触发操作，就能看到属性什么时候从空变成有值。这个方法虽然土，但足够好使。代码里如果需要监听属性变化，Java层可以通过反射调用SystemProperties.addChangeCallback，不过它是全局级的，不会单独过滤属性名，回调来了还要自己判断是哪个属性变了。Native层同样没有太理想的跨版本方案，所以我的建议是：低频轮询比花哨的监听机制更可靠。

6.2 用 on property 触发init动作

在做系统级功能时，"属性变化"不仅能被别人读到，还能主动触发init的动作。init.rc里可以这么写：

on property:sys.restart_webview=1 restart webview_zygote

这条配置让系统在收到sys.restart_webview=1时自动重启webview相关服务。实际调试WebView崩溃恢复时，这个能力帮过我大忙。它本质上是把"属性变化"当成一种跨进程事件通知机制在用，比反复读文件监听inotify简单。

6.3 高频出现的系统属性解读

日常开发里高频见到的系统属性，我把含义和用途整理在下面：

这些属性在排查启动时序、设备差异、权限问题时，是最快的信息来源。

6.4 管理自定义属性的工程化建议

属性写多了，很容易变成到处散落的魔法字符串。我自己的习惯是在项目里建一个常量类集中管理：

public final class Props { public static final String FACTORY_MODE = "sys.company.factorymode"; public static final String DIAGNOSTIC_ENABLE = "persist.sys.diagnostic"; public static final String APP_ENV = "sys.app.env"; }

所有读写属性的代码只引用常量，不直接写字符串。同时给自定义属性做一张清单表，记录属性名、前缀语义、权限要求、使用方、生命周期，避免两个人同时往同一个属性上写不同含义的值。这些管理成本看起来琐碎，真到线上问题排查时，能省掉大量来回对代码的时间。

还有一点：能编译期确定的值，优先放进build.prop；能不用persist.就不用persist.；能通过公开API读取的，就别反射SystemProperties。这三条原则是我后期做所有系统级功能时的底线。

系统属性这套机制看着简单，真正用顺了，会发现它其实是Android全局协调的一块基石。从init、SELinux、共享内存到构建系统，每一环都牵动着底层设计。我做完这个项目后再回看当时的文件锁方案，只庆幸换得早。