# tongxinlu
**Repository Path**: asfasfsd/tongxinlu
## Basic Information
- **Project Name**: tongxinlu
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-04-10
- **Last Updated**: 2026-04-10
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
# Android 项目开发规范与框架指南
## 1. 介绍
本项目基于一个通用基础框架搭建，旨在统一团队开发规范，提高代码质量与协作效率。
- **核心框架目录：** `dj` 文件夹下的所有文件均为框架通用文件。为便于后续框架升级与维护，**业务代码请勿在此目录下创建**。
- **项目依赖：** `build.gradle.kts` 文件中已包含框架所需的基础依赖，请勿随意删减，以免引发未知错误。其中个人项目引用请存放于 //demo-------------------start//demo-------------------end之间
- **开发环境：** 统一使用JDK17和kt1.8.0。
---
## 2. 开发规范
所有开发人员必须严格遵守以下规范。
### 2.1 主题与颜色 (Theme & Colors)
UI 设计团队将在 **蓝湖 (Lanhu)** 中提供目标 App 的主要配色方案。开发人员需在项目的 `res/values/colors.xml` 文件中统一定义主题色、辅助色及文字色等资源。
- **⚠️ 核心要求：** **禁止**在 XML 布局文件或代码中直接写入十六进制色值（如 `#FFFFFF`）。
- **正确用法：** 所有颜色必须通过资源引用的方式使用。
```xml
android:background="@color/app_primary_blue"
android:textColor="@color/text_primary_title"
android:background="#FFFFFF"
```
### 2.2 资源文件命名规范
#### 2.2.1 图片资源 (Image Resources)
- **图片资源 (蓝湖下载的图片):** 必须放置在 `/res/mipmap-xxhdpi/` 目录下。
- **其他图片:** 所有xml图片资源（如背景图、圆角），**必须**放置在 `/res/drawable/` 目录下。
- **命名规则:**
| 类型 | 命名格式 | 示例 | 说明 |
| :--- | :--- | :--- | :--- |
| 页面专属图片 | `{页面名}_{用途}` | `fragment_main_bg`
`activity_login_logo` | 页面专用资源，页面名建议与类名保持一致。 |
| 列表项图片 | `{列表名}_item_{用途}` | `user_list_item_avatar` | 列表循环使用的图片。 |
| 全局通用图片 | `common_{用途}` 或 `app_{用途}` | `common_bg_gradient`
`common_ic_exit` | 应用级通用资源。 |
#### 2.2.2 Drawable XML 资源
所有**圆角背景、按钮状态选择器、渐变效果**等，**必须**通过 Drawable XML 文件 (``, ``, `` 等) 定义，**严禁**使用 `.png` 或 `.jpg` 图片代替。所有 Drawable XML 文件均放置于 `/res/drawable/` 目录。特殊情况：背景带光晕或者图标和背景一体的情况下使用蓝湖图片作为背景，此类情况请注意图片比例，不得使用background属性，应使用imageview去自适应图片大小。
- **命名规则:**
| 类型 | 命名格式 | 示例 | 说明 |
| :--- | :--- | :--- | :--- |
| 纯色圆角背景 | `shape_{颜色}_{圆角}` | `shape_white_solid_corner_15dp` | 单一纯色圆角背景。 |
| 部分圆角背景 | `shape_{颜色}_{位置}_{圆角}` | `shape_white_solid_corner_top_15dp` | 仅特定方向圆角。 |
| 渐变背景 | `gradient_{起始色}_to_{结束色}_{圆角}` | `gradient_blue_to_cyan_corner_20dp` | 渐变色背景。 |
| 边框样式 | `shape_{填充色}_stroke_{边框色}_{宽度}_{圆角}` | `shape_white_stroke_gray_2dp_corner_15dp` | 带边框的样式。 |
| 状态选择器 | `selector_{控件}_{用途}` | `selector_button_login_background` | 用于定义不同状态（按下、选中等）的样式。 |
> **💡 说明:** 命名中的 “颜色名” 应与 `colors.xml` 中的定义保持一致。
### 2.3 布局编写规范 (Layout)
- **根布局:** 推荐使用 `ConstraintLayout` 作为根布局，以构建扁平化、高性能的视图层级。**尽可能减少布局的嵌套深度**。
- **Toolbar:** 非特殊设计情况下，所有页面的顶部导航栏**必须**通过 `` 标签复用项目中提供的标准 Toolbar 布局，禁止重复编写。
- **字符串 (Strings):** **所有**面向用户的UI文本（如按钮文字、标题、提示语）**无需**在 `res/values/strings.xml` 中定义，直接写即可。
### 2.4 代码编写规范
- **框架结构:** `MainActivity` 中的5个核心 Fragment 是应用的基础框架，**禁止随意更改**。新的业务逻辑请在对应的 Fragment 中进行开发。
- **命名规范:** 类名采用大驼峰命名法，命名应清晰反映其职责 (如 `ScannerActivity`, `VideoUtil`, `LoginViewModel`)。
- **单一职责:** 确保每个类的功能清晰、单一，避免编写包含多种无关功能的“上帝类”。
### 2.5 项目完成规范
---
为确保应用（App）的质量、合-规性与用户体验，特制定以下项目完成规范。所有应用在正式发布前，必须严格遵守本规范并通过所有指定测试。
---
#### **一、 隐私合规性自检**
应用开发完成后，需依据相关法律法规及平台要求，在OPPO开放平台和vivo开放平台执行全面的隐私合规性自检，并确保审查通过。
* **检测流程:**
* 开发者需登录OPPO与vivo的开发者管理中心，进入隐私安全检测服务页面。
* 上传待检测的应用安装包（APK），并启动自动化隐私检测流程。
* 平台将通过静态检测与动态沙箱技术，对应用进行全方位的隐私合规分析。 这包括但不限于权限使用分析、SDK集成情况、个人信息收集与使用行为等。
* **验收标准:**
* **隐私政策规范：** 应用必须提供清晰、独立且易于访问的隐私政策文本。政策中需明确告知开发者主体、个人信息的收集与使用目的、方式与范围，并提供有效的用户申诉渠道。
* **权限申请合规：** 应用申请所有系统权限时，必须遵循“最小必要”原则，不得申请与业务功能无关的权限。 每次申请敏感权限前，均需明确告知用户其目的。
* **检测报告：** 最终的隐私自检报告中，所有检测项均须显示为“通过”或“安全”。对于“风险项”，开发者有义务自行排查并确保其合规性，避免潜在风险。
---
#### **二、 自动化兼容性测试**
为保障应用在不同设备和系统版本上的稳定性与性能，必须在OPPO及vivo开放平台的云测试服务中完成自动化兼容性测试。
* **测试流程:**
* 前往OPPO及vivo开放平台的自动化测试或云测服务板块。
* 创建新的测试任务，并上传已通过隐私自检的应用版本。
* 在机型选择阶段，需遵循以下原则审慎挑选测试设备。
* **机型选择与覆盖要求:**
* **Android版本覆盖：** 测试机型需全面覆盖主流Android操作系统版本，建议选取搭载Android 8至Android 15系统的设备，以确保应用在各版本系统上的向前与向后兼容性。
* **设备多样性：** 至少选择10款具有代表性的主流机型，覆盖不同屏幕分辨率、处理器及内存配置，以充分暴露潜在的UI适配问题和性能瓶颈。
* **平台建议：** vivo云测平台拥有超多真实测试机型，覆盖其最热门及最新的设备，OPPO平台同样提供全系列真机进行远程调测。 建议优先选择平台推荐的热门或最新机型进行测试。
* **验收标准:**
* **测试报告：** 自动化测试完成后，平台将出具详细的测试报告。
* **核心指标：** 报告需显示应用在所有选定机型上的关键兼容性指标（如安装、启动、卸载、运行稳定性）均无严重问题（如崩溃、无响应、闪退等）。
* **项目完成：** 成功获取并通过上述所有机型的兼容性测试报告，可视为该应用功能开发与基础测试阶段的完成。
---
## 3. 框架使用指南
### 3.1 初始框架说明
框架已集成**启动页、底部导航栏、关于我们、网络请求**等基础功能。
- **DJID:**
1. **必须先创建项目**，才能调用 `install` 接口获取 `djid`。
2. **务必修改包名**，模板包名为临时包名。
3. 框架会根据应用包名自动获取 `djid`。可通过 `SharedPreferencesUtil.getString("appId")` 从缓存中读取。`SplashActivity.userNo` 为设备自增ID。
- **“我的”页面:**
1. **用户协议**和**隐私政策**页面已通过 WebView 集成，只需正确配置包名即可。
2. 若存在多个马甲包，需在 `WebViewActivity` 中增加 `url` 判断逻辑，通过判断应用名称给予不同的链接。 (如 `yszc2`, `yhxy2`)。
3. **用户反馈**功能已完成，无需额外开发。
- **底部导航栏:**
1. 修改底部 Tab 的数量、图标和文字，请编辑 `menu` 资源文件及 `xml 文件。
2. 如需**禁用 ViewPager 的左右滑动切换**功能，仅通过点击 Tab 切换，可将 `ViewPager` 控件替换为 `widget/lzy/NoScrollableViewPager`。
- **启动页 (SplashActivity):**
- 启动页逻辑**涉及广告业务**，关系到项目收益，**请勿随意修改**。
- **网络框架:**
- 网络请求框架已集成并调通，相关使用示例请参考文档。
- 接口环境切换：若接口地址或环境发生变化，请修改 `Appconst.BASE_URL` 常量。
### 3.2 权限管理
- **申请时机:** **禁止**在功能页面加载前预申请权限。权限申请应在用户触发具体功能时发起（如：点击“拍照”按钮时才申请相机权限）。
- **强制权限页面:** 对于必须获取某些权限才能进入的页面 (如：编辑页必须有存储权限)，使用 `com/santiao/tax/widget/dialog/lzy/PermissionPopup.java` 进行权限申请。即先进入功能页面但是不初始化，弹出权限申请的popup，让用户授权之后再初始化。
- **非强制权限功能:** 对于非必需权限，将权限请求绑定在具体功能按钮上，使用 `com/santiao/tax/utils/lzy/PermissionUtils.kt` 中的 `tryToDoSomethingWithCheckPermissionAndCode()` 方法进行申请。
### 3.3 通用组件
- **首页弹窗:**
- 可复用 `com/santiao/tax/widget/dialog/lzy/CustomTzPopup.java`。
- 使用时，只需替换弹窗内的图片，并在代码中修改文本颜色、在XML中调整视图约束比例即可。
---
## 4. 版本控制 (Git)
### 4.1 提交信息规范 (Commit Message)
清晰的 Commit Message 有助于代码审查和问题追溯。
- **格式:** `: `
- **示例:**
- `feat: add user login functionality`
- `fix: resolve crash issue on user profile page`
- `refactor: optimize image loading logic`
- **常用 `type`:**
- `feat`: 新增功能
- `fix`: 修复 Bug
- `refactor`: 代码重构
- `style`: 代码格式调整（不影响功能）
- `docs`: 文档更新
- `chore`: 构建过程或辅助工具的变动
---
## 5. 分支与打包规范
### 5.1 通用发布要求
1. **启动图规范：** 必须使用符合当前 App 品牌形象的启动图，严禁出现其他 App 的名称或 Logo。
2. **签名策略：** 打包所使用的签名文件必须与分支主体严格对应。例如，`master` 分支的构建产物，固定使用“三条”的签名文件。
3. **第三方平台注册规范：** 在百度等第三方平台注册应用时，禁止使用 App 的完整名称。应使用测试或代号名称（例如：使用“卫星test”而非“卫星全景导航”）。
4. **应用加固：** 所有计划发布到应用商店的 APK/AAB 安装包，都必须经过360加固处理。
5. **任务时效性：** 每日下午 5:30 之前下发的开发或打包任务，原则上必须在当日完成。如有特殊情况，需及时与相关负责人沟通。
### 5.2 分支命名规范
- **主分支:**
- `master`：(主体: 三条)
- **渠道分支:**
- `xxxx_blm`：(主体: 班灵猫)
- `xxxx_yl`：(主体: 有俍)
- `xxxx_qx`：(主体: 趣信)
- `xxxx_xh`：(主体: 星辉)
- `xxxx_ls`：(主体: 烙熵)
- `xxxx_ctl`：(主体: 磁通量)
- **特殊情况处理:**
1. **同一主体下存在多个软件著作权:** 从第二个软著开始，分支命名格式为 `xxxx_{主体缩写}_{App中文名}`。
2. **同一App针对特定渠道的大功能改版:** 分支命名格式为 `xxxx_{主体缩写}_{App中文名}_{渠道名}`。
### 5.3 打包流程
#### 1. 需求分析与分支准备
1. **接收并分析打包需求**
- 打包流程始于对接人在工作群中发布的具体打包要求。请仔细查阅该通知以明确任务范围。
- 
2. **确认打包资产与分支**
- 对接人会提供本次任务所需的核心资产，通常包括：**应用图标**、**目标分支名称**以及包含**广告位ID的配置文件**。
- 根据通知中的信息，定位到正确的代码仓库，并依据需要上架的主体，使用 `git checkout` 切换到指定分支或 `git checkout -b` 创建新分支,流程如下：
- 打开“事情管理”后，找到对接人所需的包。在“注意事项”栏目中可查看到分支创建说明，例如从 xxxx 处进行打分支。将其中的应用名称复制后，打开仓库表并进行搜索，即可查到该应用对应的仓库及其所在的分支。如上图所示，该任务在仓库中对应 car 仓库下的三条分支。若自身权限或项目中并未包含此仓库，则将仓库名称复制并提交给对应负责人处理即可。
#### 2. 核心信息配置与替换
1. **常规信息修改**
- 根据渠道要求，在项目中准确替换**应用包名 (Application ID)** 和**应用名称 (App Name)**和**应用图标 (App Icon)**。
2. **广告 ID 替换**
- 首先，打开由对接人提供的广告ID配置文件（通常是 `.docx` 格式，例如 `xxx-测试.docx`）。下图所包含的id则为gm_ad_id，其他id都有相应注释。
- 
- 然后，在项目中定位到广告ID的配置文件或常量类。将文档中所有ID，完整、精确地复制并替换到代码中的相应位置。
- 
- **替换规则说明：**
- **开屏广告 (Splash Ad):** “开屏”与“开屏2”位置下面的两个无注释的广告位ID为兜底项。
- **信息流广告 (Native Ad):** 如果文档中只提供了两个信息流广告ID，而代码中预留了多个位置，则应将这两个ID重复填写，以填满所有信息流广告位。
3. **友盟统计配置**
- 登录友盟平台，为当前渠道创建对应的应用，并将获取到的 App Key 配置到项目中,详细步骤如下:
- 登录友盟控制台：https://www.umeng.com/?loginredirect=true，账号使用公司统一的账号，请询问对应负责人获取。
- 登录成功之后点击右上角个人中心，进入应用性能监测平台。
- 在性能监测平台点击添加应用：
- 填入应用名称，应用类型统一选择实用工具-娱乐工具即可，点击注册应用。
- 选择应用性能监测平台和移动统计两款产品，点击确认开头，将得到的apikey替换。build.gradle中的 resValue("string", "gm_ad_id", "5613107")即可完成。
4. **视觉资源替换**
- 替换启动图以及个人中心等页面可能存在的 Banner 图片。启动图资源需确保符合当前渠道要求。
- 启动图查找其他同品类APP的启动图，将其截图保存发送给对应负责人由负责人进行选择，将决定好的启动图擦除多余部分即可作为项目启动图。
5. **修改多渠道打包配置 (`build.gradle.kts`)**
**5.1. 渠道配置命名：**
- 在 `build.gradle.kts` 中，渠道配置的命名需遵循 `上架主体缩写 + 商店名` 的格式。
- **示例：** `blmAlls` (班灵猫-全部商店)、`stXiaomi` (三条-小米商店)。
- **⚠️ 重要原则：** 分支名与发布主体名可以不同。例如，使用 `blm` 分支来打包一个计划以 `三条` 主体上架的应用是完全允许的。因此，**渠道配置的缩写必须与最终上架的主体保持一致，而不是与当前Git分支名一致。**
示例：
> #### 单一分支支持多主体发布的原则与实践
>
> 为了高效应对应用商店审核的不确定性，我们的工作流将**代码开发分支**与**市场发布主体**进行解耦。这意味着，一个稳定开发分支（如 `master`）可以预先配置，用于为多个不同的发布主体生成安装包。
>
> ##### 1. 核心场景说明
>
> * **主计划 (Primary Plan):**
> * 一个应用（例如：此播放器）在 `master` 分支上完成开发，其首选的上架主体是“三条”。因此，我们会优先使用“三条”的身份信息（应用名、图标、包名等）进行打包和提交。
> * **备用计划 (Contingency Plan):**
> * 在应用商店审核过程中，可能会因为应用名不合规、元数据问题或其他政策原因导致“三条”主体的应用被驳回。
> * 此时，为了不影响上线进度，我们无需修改或迁移代码。而是直接利用 `master` 分支的同一份稳定代码，切换到备用的“趣信”主体，修改相应的身份信息后，重新打包上架。
>
> ##### 2. 对多渠道打包配置的影响
>
> 这一策略直接反映在 `build.gradle.kts` 的多渠道打包配置中。对于 `master` 分支而言，我们需要为其**预先定义所有潜在上架主体的渠道配置**。
>
> * **配置示例：**
> 在 `productFlavors` (或类似配置块) 中，会同时存在“三条”和“趣信”的渠道配置。
>
> ```kotlin
> android {
> // ...
> flavorDimensions "market"
> productFlavors {
> // --- 主计划：为“三条”主体配置 ---
> create("Xiaomi") { // 未声明主体 = 三条, Xiaomi = 小米商店
> dimension = "market"
> manifestPlaceholders["app_icon"] = "@mipmap/icon_saitiao"
> resValue("string", "appName", "三条播放器")
> resValue ("string", "downloadChannel", "XIAOMI")//渠道
> // ... 其他“三条”相关的配置
> }
>
> create("Alls") { // 未声明主体 = 三条, Alls = 全部商店
> dimension = "market"
> // ...
> }
>
>
> // --- 备用计划：为“趣信”主体配置 ---
> create("qxXiaomi") { // qx = 趣信, Xiaomi = 小米商店
> dimension = "market"
> manifestPlaceholders["app_icon"] = "@mipmap/icon_quxin"
> resValue("string", "appName", "趣信播放器")
> resValue ("string", "downloadChannel", "XIAOMI")//渠道
> // ... 其他“趣信”相关的配置
> }
>
> create("qxAlls") { // qx = 趣信, Alls = 全部商店
> dimension = "market"
> // ...
> }
> }
> }
> ```
> 当主计划存在多个变体（例如同一分支下出现不同渠道，如 yl 分支下包含 ylXiaomi）时，通常意味着该变体替换了应用图标。因此，需要按照要求修改图标的配置。在这种情况下，应在渠道配置中加入：resValue("string", "downloadChannel", "XIAOMI")配置示例如下图所示：
> 
>
> 此外，当同一分支中使用备用主体时，应用名称也会被替换。此类构建通常不会发布到 alls 这一通用渠道，而是指定某几个特定的上架商店。对于包含多个商店渠道的情况（例如 qxXiaomiVivo），其渠道字段应留空，可按如下方式配置：resValue("string", "downloadChannel", "")参考示例如下图所示：
> 
>
>
> * **执行打包：**
> 当需要打包时，开发者只需在 Android Studio 的 **Build Variants** 面板选择，或通过命令行指定需要构建的版本即可。例如：
> * 执行 `./gradlew assembleStXiaomiRelease` 将打出“三条”主体的小米渠道包。
> * 执行 `./gradlew assembleQxXiaomiRelease` 将打出“趣信”主体的小米渠道包。
>
> 通过这种方式，我们确保了代码的单一来源和稳定性，同时获得了应对市场变化的高度灵活性。
**5.2. 签名与对接声明：**
- **签名规则：** 无论最终上架哪个主体，APK的签名文件 **始终** 使用当前 **Git分支名** 所对应的签名。
- **对接规范：** 在与运营等相关方对接时，必须清晰地声明 **“分支主体”** 与 **“上架主体”** 的关系。
- **标准对接话术示例：** “班灵猫上三条”，这表示 “使用 `blm` 分支的代码和签名，打包一个以 `三条` 为主体的应用”。
**5.3. 参数配置：**
- 使用 `resValue` 和 `manifestPlaceholders` 为不同渠道配置差异化参数，如应用图标、渠道标识等。`alls` (全部商店) 类型通常无需配置特定渠道标识。
- **示例代码：**
```kotlin
create("Xiaomi") { // 主体是三条(st)，商店是小米(Xiaomi)（什么都不写就是三条参考分支规范）
dimension = "app_icon"
manifestPlaceholders["app_icon"] = "@mipmap/icon_app_logo_st" // 使用三条的图标
resValue("string", "appName", "三条应用") // 使用三条的应用名
resValue("string", "downloadChannel", "XIAOMI") // 渠道
}
```
#### 3. 配置垃圾代码生成器
- 为每个渠道包配置独立的垃圾代码生成规则，以增强反编译难度。确保 `register()` 中的名称与渠道配置名一致，并更新 `packageBase` 为当前应用的包名。
- **示例代码：**
```kotlin
variantConfig {
register("blmAllsRelease"){
packageBase = "com.santiao.tax" // 生成java类根包名
packageCount = 35 // 生成包数量
activityCountPerPackage = 35 // 每个包下生成Activity类数量
excludeActivityJavaFile = false // 是否排除生成Activity的Java文件
otherCountPerPackage = 35 // 每个包下生成其它类的数量
methodCountPerClass = 35 // 每个类下生成方法数量
resPrefix = "players_" // 生成的layout、drawable、string等资源名前缀
drawableCount = 35 // 生成drawable资源数量
stringCount = 35 // 生成string数量
}
}
```
#### 4. 打包后自检
- 打包完成后，必须进行严格的自检流程：
- **解包检查：** 使用apktool解包 APK 文件，确认包体内已成功生成垃圾代码。代码代码生成目录一般情况如图所示,查找解包出的文件中是否包含垃圾代码。
- **安装测试：** 在测试设备上安装应用，验证启动图、应用加载、核心功能是否正常。
- **协议检查：** 检查隐私协议和用户协议是否能正常打开。若页面提示 404，需立即与相应负责人联系（例如，检查 `com.santiao.tax` 税务查询的隐私协议是否已创建）。
#### 5. 加固、签名与交付
- 自检通过后，使用 **360加固** 对安装包进行加固处理，然后使用对应的签名文件进行签名。
- 完成后，将包文件发送至运营群，并 **@对应交接人**，消息格式如下：
```
闹钟铃声响v101
有俍上有俍
com.liang.naozhong
广告已配置 @对应对接人
```