企业官网建设流程全解析

网站维护的内容,商丘网站建设推广公司地址,网站做成app,快速排名精灵先把结论讲清楚#xff1a;Application Framework 就是 Android 专门给 App 准备的一整套“官方服务 标准工具箱”。 它把底下那些硬核东西#xff1a;Linux 内核、驱动、HAL、Native 库、ART…都藏起来#xff0c; 然后用一堆你听得懂的 Java/Kotlin API 的形式#xff0…先把结论讲清楚Application Framework 就是 Android 专门给 App 准备的一整套“官方服务 标准工具箱”。它把底下那些硬核东西Linux 内核、驱动、HAL、Native 库、ART…都藏起来然后用一堆你听得懂的 Java/Kotlin API 的形式端到你面前。换成人话对 App 开发者来说Application Framework 就是Activity/Service/BroadcastReceiver/ContentProviderContext/Intent/Handler/View/Fragment以及一大堆XXXManagerActivityManager、WindowManager、LocationManager、PackageManager…它负责的事情可以总结成一句话让你只用管“业务和界面”不用直接去和“进程、内存、硬件、Binder、驱动”这些宫斗。这篇文章我们从几个角度拆开讲Application Framework 在整个系统架构里是“哪一层”它大致由哪些模块组成常见的系统服务都干什么四大组件Activity / Service / BroadcastReceiver / ContentProvider与 Framework 的关系。某些关键机制的背后Activity 启动、Intent 分发、权限校验、进程管理。系统服务之间如何协作AMS、WMS、PMS 等是怎么配合的。这些框架设计对我们日常写 App 有什么实质影响应该怎么顺势而为一、Application Framework 在整栋“Android 楼”里的位置先把大地图画出来文字版从下往上Android 大约分Linux 内核层进程、线程、内存管理、文件系统、网络、驱动、Binder 驱动、wakelock、电源管理…硬件抽象层HALCamera HAL、Audio HAL、Sensor HAL、Fingerprint HAL 等把具体硬件封装成统一接口Native 层C/C 系统库bionic、OpenGL ES、libmedia、libandroid、SQLite…Native 守护进程SurfaceFlinger、MediaServer、keystore 等Runtime 层ART / Dalvik 虚拟机Java 核心类库、垃圾回收、JIT/AOT…Application Framework应用框架层一堆 Java 层的系统服务大多在system_server进程里对外暴露为各种Manager和android.*包下的类应用层Apps系统应用拨号、短信、设置第三方应用你写的所有 APK你可以想象内核 / HAL / Native / Runtime 地基 水电 管道 发电厂Application Framework 市政府 各个职能部门 对外办事窗口App 城市里的公司、商店、住户通过这些窗口办业务重点App 绝大多数时候只跟 Application Framework 打交道很少或者尽量不直接摸底层的 Native、HAL、内核。二、Application Framework 是些什么东西拼成的先用一句最通俗的话Application Framework N 多“系统服务System Services” 一套“组件模型 生命周期管理” 一堆“基础类和工具”。简单列一下里面的“大角色”负责 App 生命周期、任务栈的ActivityManagerServiceAMSJava APIActivityManager负责窗口和界面的WindowManagerServiceWMSJava APIWindowManager、View、ViewRootImpl负责包管理、安装卸载的PackageManagerServicePMSJava APIPackageManager负责显示 / 通知 / 状态栏 的StatusBarManagerService、NotificationManagerServiceJava APINotificationManager负责存储 / 文件 / 权限判断 的MountService早期、StorageManagerServiceJava APIStorageManager、Environment负责位置 / 传感器 的LocationManagerService、SensorServiceJava APILocationManager、SensorManager负责电话 / 短信 / 网络 的Telephony 系统服务、ConnectivityService、WifiServiceJava APITelephonyManager、ConnectivityManager、WifiManager负责输入法 / 剪贴板 / 声音 / 电源 等的InputMethodManagerService、ClipboardService、AudioService、PowerManagerService…Java APIInputMethodManager、ClipboardManager、AudioManager、PowerManager还有很多不一一列举。核心观念是每一个你熟悉的XXXManager背后都有一个跑在系统进程里的XXXManagerService给你撑腰。这些服务几乎都运行在一个大进程里system_server。它就像整个系统的“大总管”负责资源调度、权限管理、进程管理等。三、四大组件和 Application Framework你写的所有页面和后台都被它管着Android 独有的一套东西四大组件ActivityServiceBroadcastReceiverContentProvider你可以理解为Framework 给你的四种“官方角色”Activity前台界面跟用户互动Service后台服务执行长时间操作BroadcastReceiver消息收发员接收系统/应用发出的广播ContentProvider数据对外暴露的门面比如通讯录、媒体库等这些组件怎么“活过来”“死掉”“切换前后台”都是 Application Framework 帮你管。我们分别看一下它们和 Framework 的关系。3.1 ActivityAMS WMS 一起管的“前台角色”AMSActivityManagerService管逻辑哪个 Activity 在前台任务栈结构TaskStack前进、后退生命周期回调onCreate/onStart/onResume/onPause/onStop/onDestroyWMSWindowManagerService管界面哪个 Window 显示在屏幕上Window 的层级、动画、触摸事件分发等和 SurfaceFlinger 合作把画面真正画到屏幕上你调用startActivity(Intent(this,DetailActivity::class.java))实际发生的是你所在进程通过 Binder 调 AMS说“我要启动 Activity X”AMS 检查权限、任务栈、目标进程是否存在如果目标 Activity 在同一个进程发消息给你的进程让主线程创建实例、调用生命周期如果是另一进程通过 Zygote fork / 进程管理启动新进程然后再让那个进程创建 ActivityAMS 同时联动 WMS告诉窗口管理“我要展示一个新窗口了”处理动画、切换等整个过程看起来是一行代码背后是多进程 多服务联动。3.2 ServiceAMS 管“活着没”Binder 管“怎么调”Service 分两类启动式 ServicestartService()/stopService()绑定式 ServicebindService()/unbindService()无论哪种方式关键点都有AMS 决定这个 Service 对应哪个进程它应该何时创建/销毁调用 onCreate/onStartCommand/onDestroy是否可以在内存紧张时被杀死Binder 决定进程 A 怎么调用进程 B 的 Service 方法AIDL、Messenger 等都是 Binder 上层封装你在代码里写bindService(intent,conn,BIND_AUTO_CREATE)流程大致是你的进程通过 Binder 调到 AMS“我要绑定某个 Service”AMS 找到目标 Service 所在的进程如果没起来就先拉起来目标进程创建 Service 实例onCreate → onBind返回一个 Binder 接口AMS 把这个 Binder 回传给你你这边的ServiceConnection.onServiceConnected()被回调此后你就可以通过这个 Binder通常是接口代理远程调用 Service 中的方法你不用管跨进程细节Framework Binder 全帮你搞定。3.3 BroadcastReceiverAMS 做“广播站台长”广播机制的本质也是靠 AMS 管理静态广播在 manifest 注册系统开机时 PMS 解析 manifest 并记下来动态广播在代码里注册由 Activity/Service 调用 AMS 注册发送广播sendBroadcast(Intent(com.xx.ACTION_YYY))流程调到 AMS 的广播管理逻辑AMS 根据 Action、权限、包名过滤出匹配的 Receiver 列表对于每一个匹配目标如果是“已在活跃进程里”的 Receiver就直接回调对应进程如果是需要另起进程的比如静态注册在没启动过的 App 里就先启动相应进程再回调 onReceiveAMS 负责控制广播是否粘性、是否有序广播超时防止 Receiver 卡死广播权限检查3.4 ContentProvider数据共享的大门口由 AMS PMS Provider 共同协作ContentProvider 主要负责对外暴露一套统一的数据访问接口insert/query/update/delete系统内很多数据都通过它对外提供通讯录、短信、媒体库等URI 形式一般如下content://contacts/… content://media/external/images/…访问流程App 通过ContentResolver调用query/insert等方法Framework 通过 AMS/PMS 找到对应 Provider 所在的进程若进程未起先启动获取 Provider 的 Binder 接口调用对应方法返回数据通常是 Cursor你看到的是 ContentResolver 的几行代码背后是系统服务把“访问控制 跨进程 生命周期”这一大堆事都干完了。四、系统服务大军AMS / WMS / PMS 这些缩写到底干嘛的Application Framework 层的核心可以概括为几个超级大服务。很多源码/面试时经常提的三个缩写AMSActivityManagerServiceWMSWindowManagerServicePMSPackageManagerService再加上NotificationManagerServiceInputMethodManagerServicePowerManagerServiceConnectivityServiceLocationManagerServiceSensorServiceTelephony 相关服务…我们挑最关键的几个讲清楚它们各自负责啥、怎么协作。4.1 AMS进程 Activity Service 任务栈的大总管AMS 的职责非常多简单说只要和“应用组件生命周期、进程、生死、前后台、任务栈”有关的事基本都归它管。包括但不限于启动/停止 Activity管理 Activity 栈启动/停止/绑定 Service注册/发送 Broadcast进程创建/死亡监控内存紧张时决定杀谁结合内核 LMK前台/后台 App 状态切换记录哪些进程持有什么组件、何时可以回收你写的startActivity/startService/bindService/sendBroadcast背后都是在跟 AMS 说话。AMS 有点像一整个商业楼的物业管理 消防控制中心哪个公司在第几层、哪家店正在营业、哪家已经关门、哪一层人太多要限制、哪家占用太多资源要提醒甚至“请出去”。4.2 WMS窗口与显示系统的“城管局”WMS 负责整个系统所有窗口Window的管理每个 Activity 的窗体系统状态栏、导航栏Toast、Dialog、系统悬浮窗甚至输入法窗口软键盘也归它管它决定了窗口的 Z 轴顺序谁在谁上面窗口的大小、位置是否全屏、是否可触摸截图、投屏时抓哪一层图像当你的 Activity 启动时AMS 同意你“逻辑上”进入前台WMS 帮你真正把 Window 贴上去通过 ViewRootImpl、SurfaceFlinger 合成WMS 也会配合权限系统判断App 有没有权限画系统级悬浮窗如 SYSTEM_ALERT_WINDOW某些特殊窗口锁屏界面、系统对话框只有系统签名应用才能创建4.3 PMSPakageManagerService应用安装 权限 组件信息的“档案局”PMS 负责解析 APK 的AndroidManifest.xml把里面的 Activity/Service/BroadcastReceiver/Provider 信息存入系统数据库管理已安装应用列表权限声明 授权哪些 app 申请了哪些权限配置了哪些 intent-filter提供查询入口给其他系统服务比如AMS 想知道某个 Intent 能匹配哪些 Activity就问 PMSLauncher 想列出所有可启动的应用图标也问 PMS当你安装一个 APK 时PMS 做的事包括解压 APK校验签名解析 manifest、资源把各种信息写入包管理数据库通知系统其他模块有新应用安装成功触发广播等App 调用valpmcontext.packageManagervalinfopm.getPackageInfo(packageName,0)其实就是在让PackageManagerService帮你查档案。4.4 其他重要服务简单过一遍NotificationManagerService管理通知栏添加、更新、移除通知决定优先级、是否展示、是否静音对应的 Java APINotificationManagerLocationManagerService统一管理 GPS、网络定位、传感器融合控制定位请求频率、精度、耗电策略对应 Java APILocationManagerSensorService管理加速度计、陀螺仪、磁场、光照等传感器数据提供统一的事件接口给SensorManagerConnectivityService / WifiService管理网络连接状态、网络切换、流量统计、VPN 等通过ConnectivityManager、WifiManager暴露给 AppPowerManagerService管理屏幕亮灭、休眠、唤醒、wakelock对应PowerManager给 App 提供 wakelock 接口慎用你在 App 里通过getSystemService()拿到的各种XXXManager基本就是这些 Service 的 Java proxy。五、从“调用 API”到“系统服务响应”一次完整的链路我们拿一个最常见的操作启动一个 Activity看看 Application Framework 背后到底做了啥。5.1 你写的那一行代码startActivity(Intent(this,SecondActivity::class.java))背后大致是下面几步简化版Activity 调用了startActivity→ 实际走到Instrumentation或ContextImpl内部最终调用到ActivityManagerService的startActivityBinder 接口AMS 里做的事检查调用者有没有启动这个 Activity 的权限M anifest 是否声明解析 Intent → 查询 PMS看看哪一个 Activity 匹配处理任务栈逻辑singleTask、singleTop 等 launchMode决定是在当前进程里创建 Activity 还是启动新进程如果目标是新进程AMS 让 Zygote fork 一个新进程在新进程里创建 Application 对象跑 Application.onCreate然后调用 ActivityThread在主线程里创建目标 Activity 实例调用 onCreate/onStart/onResume同时AMS 通知 WMS“有个新的 Activity 窗口要上来了”WMS 让 ViewRootImpl 创建 Surface配合 SurfaceFlinger 把画面显示出来。你看到的只是页面跳过去了onCreate/onResume被调用了但实际上你敲的那个 API穿过了App 进程 → Runtime → Binder → AMS → Zygote → WMS → 再回到 App 进程这一整套 Application Framework 机制就是帮你屏蔽了这些复杂度让你“看上去”只是在调用本地方法。六、Application Framework 解决了哪些“大麻烦”如果没有 Application Framework你会面临一大堆原始问题进程管理App 什么时候启动 / 什么时候被杀 / 被杀后如何恢复状态系统内存紧张时杀谁怎么保证前台不被轻易杀多任务 页面栈多个页面之间怎么管理返回栈从别的 App 跳到你这儿再返回栈怎么合并singleTask/singleInstance 等模式如何实现跨进程通信不同 App 之间怎么通信系统服务怎么对多个 App 暴露统一接口权限检查如何做权限和安全短信、电话、通讯录、文件、摄像头、麦克风这些敏感能力谁能用如何拦截非法访问如何给用户一个统一的授权体验硬件访问App 绝不能直接和驱动打交道否则乱套了要有一层中间人系统服务对硬件能力再抽象、做统一访问控制生命周期和状态保存屏幕旋转、内存回收、进程重启时如何恢复 Activity 状态Service 长时间运行如何不被滥用导致耗电后台限制如何执行Application Framework 把这些都变成一套约定俗成的组件模型四大组件 生命周期回调一套清晰的系统服务 APIXXXManager一套统一的权限和进程管理机制你只要在这套规则下写 App大部分“麻烦事”系统帮你兜底。七、Application Framework 与 Binder为什么“跨进程调用看起来像本地调用”有一个非常重要的点Application Framework 大部分“调用系统服务”的 API其实都是在做跨进程调用但语法像本地方法。比如你调用valamgetSystemService(Context.ACTIVITY_SERVICE)asActivityManager am.getRunningTasks(1)ActivityManager在你进程里只是一个代理Proxy真正的服务逻辑在ActivityManagerServicesystem_server 进程你调用的方法最终会通过 Binder 驱动跨进程发到 system_server 里执行再把结果传回来Application Framework 的设计目标之一就是让开发者感觉不到自己在跨进程但系统内部可以强制进程隔离、安全控制。Binder 一层 Manager / Service 代理的组合让这一切成为可能对你来说是面向对象的 API对系统来说是安全的 IPC 通信八、对日常开发的影响理解 Framework 能帮你避坑和优化什么知道这些不是为了背面试题更重要的是8.1 生命周期和进程真相别跟系统抢“主导权”AMS 有权在任何“合适”的时候杀掉你的进程尤其是后台、空进程Activity 的 onPause/onStop/onDestroy 不一定都被完整调用崩溃/杀进程Service 不是“永生”的尤其在新版本的后台限制下所以不要把重要状态只放在内存里进程被杀就没了可以配合 ViewModel、SavedStateHandle、持久化存储不要认为“前台 Service 就永远不会死”高负载系统照样可能干掉你要容错重启逻辑但也要注意别滥用影响体验8.2 和系统抢资源的成本多跑一个 Service不是白给的系统服务设计得很精细地控制CPU、内存、网络、电量前台/后台优先级你开一个常驻 Service就相当于在跟系统说“给我来一杯长期保温的热水。”系统不得不让你的进程优先级变高减少被杀概率给你保留更多资源但代价就是——别人可用资源变少整体耗电上升所以不要随意搞长轮询常驻后台 Service各种无脑闹钟Alarm尽量用JobScheduler / WorkManager系统帮你择机执行Firebase Cloud Messaging / 推送合理的前台服务有真正的用户可见需求8.3 权限和数据访问顺着框架走安全又省心想读短信、通讯录、定位、相机等敏感数据Application Framework 已经给你设计好接口和权限你无需也不应该绕过这些比如直接读数据库文件、自己搞 socket 到某底层服务顺着框架走的好处兼容性好新系统版本只要保证接口不变你的 App 就能无感升级安全权限系统、隐私规则都在框架里统一管理九、站在更高一点的位置看Application Framework 的“设计哲学”把所有细节都放一边从更高层抽象看Application Framework 的设计哲学是在“灵活性”和“安全性/可控性”之间找平衡。它想做到让 App 开发者只关心业务页面的写法数据的逻辑交互体验尽量不让你直接操心“进程调度、锁、内存碎片、硬件访问”等复杂操作又要保证系统能统一管理所有 App谁可以在后台跑谁可以访问哪些数据谁抢太多资源要被限流/干掉谁的行为影响用户体验要弹警告比如耗电、频繁崩溃于是它提供了统一的组件模型 生命周期回调让系统有“插手点”一致的 API 接口XXXManager、Intent、ContentResolver统一的权限控制和签名机制“一人一屋”的进程隔离模型每个 App 一个沙箱你如果顺着这套设计思路写 App就会感觉开发效率高踩坑少升级 Android 版本时问题也相对容易定位如果刻意对抗这套设计各种黑科技绕过框架也许一时爽但系统一升级就全崩或者被系统新加的安全策略直接拦截十、总结用一句话记住 Application Framework 是啥用一句尽量接地气的话来收尾Android 的 Application Framework就是系统帮你准备好的那套“办事大厅 服务柜台 办事规则”。你写的 Activity / Service / BroadcastReceiver / ContentProvider都是按照它的模板填写“申请表”你用的各种XXXManager、Intent、ContentResolver都是在找不同的“窗口”办事而这些窗口背后站着 AMS、WMS、PMS、NotificationManagerService、LocationManagerService… 这帮“公务员”他们帮你去调底层的电、水、气内核、驱动、HAL、Native 库保证所有 App 在这座城市里井井有条地生活。理解 Application Framework不是为了背它有多少个类、多少个 Service而是为了在你写 App 时脑子里能有这样一张地图我这行代码是在跟谁说话这个生命周期回调为什么要这样设计系统为什么在这个时机杀我进程我怎么写代码才能顺着系统的“节奏”走而不是跟它对着干当你有了这张“框架地图”很多以前觉得“玄学”的问题就都能找到“框架层”的解释。