十二、其他
ATask
BlackMagic
开发中的黑魔法，提高开发效率，同时显得高大上
Job
跳槽求职面试
BlackMagic_Reverse
逆向
第4节：Optimize+CI
一、卡顿Caton问题
-
卡顿相关：包括列表中加载大图的问题
二、打包问题
1、公有库打包
2、私有库打包
dvlproad的私有库仓库
dvlproadSpecs
3、持续集成打包
持续集成(包含iOS自动化打包)
CJTest
测试持续集成的事例
web必备基础-3代码复用
一、css复用
二、UI 复用
1、目前实例(jquery的load方法)
将一个页面分成多个html文件（静态html分割页面）
参考文章：
-
1
2
3
4<script type="text/javascript">
$(".footer").load('footer.html');
$.nicenav(300, '216px');
</script> -
1
2
3
4
5
6
7
8
9
10
11<div id="header"></div>
<div id="content"></div>
<div id="footer"></div>
<script>
$(function(){
$('#header').load('header.html');
$('#content').load('content.html');
$('#footer').load('footer.html');
})
</script>
2、其他方法
-
1
如何抽离出公用的部分呢？(有点类似Vue，React等框架的组件化)我选的是运用jquery的load方法，还有很多其他方法，如iframe ，include等等网上都能搜到。
web必备基础-2实践基础
性能优化
一、启动优化
主要是启动耗时，处理的主要方式是
代码方面：
- 移除多余的：有些SDK是仅用来Debug测试的，没必要带到Release（条件编译）
- 延迟非关键：如广告SDK
- 分配到子线程处理，并发处理
其他方面：
- +load
- 动态库dylib合并
排查工具：Time Profiler
二、内存优化
及时释放（不要只持有，但不释放，如避免单例持有大对象）
autorelease
1、内存暴涨（Memory Spike）
大量小对象 → 一次性加载/渲染过多 cell、图片、富文本。（Cell 复用）
少量大对象 → 单个对象占用内存非常大（加载大图/视频，例如单张图片 100MB，或一个大 Data blob）
短时间内创建大量对象或加载大资源，造成内存占用过多，可能引发系统回收甚至崩溃。
- 原因：循环创建对象、大量数据瞬时加载、大图加载等。
- 工具检测：Instruments -> Allocations / Memory Usage。
示例：
JSON 解析时递归错误，不断循环创建对象；
请求没做分页/单页数量极大(之前遇到为了省去Flutter中列表的数据处理，直接单页请求4000个数据)
加载大图，大图直接解码显示原始位图，占用内存太大。优化：Downsampling（缩放解码），只解码需要显示的尺寸/缩略图，而不是原图全尺寸。
1
解码成位图 (bitmap): 4000 x 4000 图片 (RGBA8888) = 4000 * 4000 * 4 bytes ≈ 64 MB
之前在发布内容时候（Flutter应用）涉及到多视频的压缩
2、内存泄漏（Memory Leak）：
- 原因：未释放的强引用循环、未释放的资源（解决循环引用导致释放不掉的问题）。
- 工具检测：Xcode Instruments -> Leaks。
内存抖动（Memory Churn）：
- 原因：频繁的内存分配和释放。图片/数据频繁解码滑动列表时，每次都解码同一张图片，没有缓存。
- 影响：性能下降、电池消耗增加。
APP 被系统 Kill（Jetsam）：
- 原因：使用内存超出系统限制。
- 检查：控制台日志包含 JetsamEvent。
排查工具：Instruments 的 Leaks 和 Allocations 分析内存泄漏
1、正确的地方使用 reuseIdentifier
2、内存泄漏
1、使用Product-Analyze分析内存泄
利用Product-Analyze分析内存泄露，并不能把所有的内存泄露查出来，因为有的内存泄露是在运行时，用户操作时才产生的。那就需要用到Instruments了。
三、卡顿优化
《卡顿监控.md》
《列表优化.md》
四、网络优化
《网络框架.md》
分页规范
一、分页底层原理
后台得到符合指定条件的所有记录，然后再截取位置。常见的截取位置方法为分页和指定第几页。
为避免请求非第一页数据时候，后台在得到符合指定条件的所有记录和第一页得到的不一样，需要前台或者后台需要记录与第一页一样的请求时间。
常见方案：
| 备注 | ||
|---|---|---|
| pageIndex | ||
| pageSize | 缺点：只能index变，size不能变，不然返回的数据会错误 | |
| timestamp | 此为优化点，为的是避免请求非第一页数据时候，后台在得到符合指定条件的所有记录和第一页得到的不一样 没此参数的时候，后台应该是缓存了第一次请求后所有记录，只有再次重新请求或过期才释放这些所有记录。 |
timestamp 的记录方式：
1、后端记录（需要结合过期时间）
需要结合过期时间，以处理为每个用户记录的这个第一页请求时间。有额外开销
2、前端记录
二、优化方案：解决size的变化
方法1：后端记录下发的数据，新请求时候进行过滤
缺点：需要集合过期时间
方法2：前端下发上次请求的最后一条记录信息
信息方法1：上次最后一条的id，此方法不通。因为新增的记录后台id目前已经不是自增的了
信息方法2：上次最后一条的modifyTime，此方法可以，前提需要后台的时间单位为更为精确的mm级或者um等。
结论：此时所需字段如下
| 不需要，已通过最后一条的modifyTime 处理 | ||
| 不需要，已通过最后一条的modifyTime 处理 | ||
| 最后一条的modifyTime | ||
| pageSize | 可灵活变动 |
End
工作流程
前言
管理相关：详见管理相关 主要包含以下内容。
账号管理
一、开发相关
1、分支规范
2、目录结构规范
目录结构规范的必要性在于：
- 便于团队协作：在团队协作中，规范的目录结构可以让所有人都能够快速地找到他们需要的文件和资源，提高开发效率。
- 便于维护：有一致的目录结构可以让项目更易于维护。例如，如果您需要添加一个新的功能，您可以很快地找到添加到哪个文件夹中。
- 可读性更高：良好的目录结构可以让代码更易于阅读和理解，这对于代码的维护和升级非常重要。
3、基础框架分层规范及解耦
在项目开发中，基础框架分层是非常重要的，可以帮助我们将代码分成多个层次，每个层次都有自己的职责和责任，从而提高代码的可维护性、可扩展性、可重用性和可测试性。同时，基础框架分层也可以帮助我们解耦不同部分的代码，减少代码之间的依赖关系，从而提高代码的灵活性和可靠性。
解耦的必要性在于：
- 减少代码之间的依赖关系：解耦可以帮助我们减少代码之间的依赖关系，降低代码的耦合度，从而提高代码的灵活性和可靠性。
- 提高代码的可维护性：解耦可以帮助我们将代码分成多个独立的部分，每个部分都有明确的职责和责任。这样，我们可以更容易地测试、修改和维护应用程序的不同部分，从而提高代码的可维护性。
- 提高代码的可扩展性：解耦可以帮助我们将应用程序的不同部分分离开来，以便于单独测试和修改。这样，我们可以更容易地扩展应用程序的功能和特性，而不会影响到其他部分的代码。
- 提高代码的可重用性：解耦可以帮助我们将可复用的代码和组件集中在公用组件层中，方便其他部分的代码进行复用。
4、项目空安全升级的必要性
Flutter 空安全（Null Safety）是指在代码中添加了对空值的非空断言、空值检查等机制，从而使代码更加健壮和安全性。Flutter 空安全升级的必要性主要体现在以下几个方面：
- 提高代码的健壮性和安全性：空值是程序中常见的 bug 和异常来源，它们可能会导致应用程序的崩溃和数据丢失等问题。Flutter 空安全升级可以帮助我们在编码时更加谨慎和严谨地处理空值，从而提高代码的健壮性和安全性。
- 改进开发体验：Flutter 空安全升级可以使开发人员更加自信地编写代码，减少了在运行时意外发现空值异常的可能性。此外， Flutter 空安全还提供了更好的类型推断和代码提示，使代码编写更加高效。
- 为未来的 Flutter 版本做好准备：Flutter 空安全是未来 Flutter 版本的必备功能，通过升级到 Flutter 空安全，我们可以为未来的 Flutter 版本做好准备，并避免在未来的升级中遇到问题。
- 适应 Dart 语言的发展：Dart 语言从一开始就支持空安全，Flutter 空安全升级可以使我们更加适应 Dart 语言的发展，以便更好地利用 Dart 语言的新特性和功能。
因此，Flutter 空安全升级是非常必要的，它可以提高代码的健壮性和安全性，改进开发体验，为未来的 Flutter 版本做好准备，并适应 Dart 语言的发展。
举几个例子说明不升级空安全容易出现的问题或者隐患
以下是一些在不升级 Flutter 空安全的情况下可能出现的问题或隐患：
- 空指针异常：在使用空值时，如果没有进行空值检查或非空断言操作，可能会导致空指针异常。
- 运行时错误：在使用空值时，如果没有进行空值检查或非空断言操作，可能会导致应用程序在运行时出现错误或异常，从而导致应用程序崩溃或数据丢失等问题。
- 不良用户体验：在应用程序中使用空值时，如果没有进行空值检查或非空断言操作，可能会导致应用程序出现不良的用户体验，例如界面卡顿、延迟等。
- 难以维护和修改代码：在没有使用 Flutter 空安全的情况下，代码中可能存在大量的空值检查和非空断言操作，这会使代码变得冗长和复杂，从而使代码难以维护和修改。
- 降低代码质量：在不使用 Flutter 空安全的情况下，可能会存在一些代码质量问题，例如代码重复、逻辑混乱等问题，这会降低代码的可读性、可维护性和可扩展性。
因此，升级 Flutter 空安全是非常必要的，它可以提高应用程序的健壮性和安全性，改进用户体验，提高代码的可读性、可维护性和可扩展性，并减少开发过程中出现的错误和异常。
5、代码规范
模块功能划分清晰
- 页面接口整理 见《请求规范.md》 中的【请求接口的整理规范】
打包保证
详见：app打包保证
主要处理问题：
- 避免外部人员使用非正式包
质量保证
1、操作日志：app记录所有的记录，方便排查，接入游戏的地方也要有日志 [p1]
2、崩溃率、卡顿检测 [p1]
3、app接入apm [p2]
弱网测试：
业务提升
5、全站埋点：有现成工具最好，从核心业务开始 [p2]
日常事项
4、值班：记录每个人的能力，碰到问题找对应的人，值班热线电话号码，24小时随时待命 【p0】
分支规范
一、分支简介
项目应包含以下分支：
master
该分支为项目主分支，此分支只作为稳定版本发布使用，不允许在此分支上修改 bug ，开发功能等。并且该分支每次发布时需根据项目的版本号打上 tag ，例如 v1.0.0。
develop
该分支为各开发人员的开发合并分支，各开发人员在各自开发分支/功能分支/bug分支上开发/调试代码，完成相关工作后即可合并到 develop 分支，不允许各位在此分支上直接开发。此分支无需打 tag 。
qa-test
该分支是交由 QA 进行测试的分支，每次交由 QA 测试时，从 dev 分支合并到该分支，合并的最后一次 commit 需要打 tag ，例如 v1.0.0-test-num，num 为 1.0.0 版本提交测试的序号。QA 测试稳定后，merge 到 master 并打上 tag，待发布。
feture_xxx
该分支用于开发新功能，比如新版本迭代时，有一个较大的功能模块，可以不在 dev_hzxxx 分支开发，相关开发同学可在此类分支上开发，有两个优点：(1)可以多人协同 (2)可以防止模块较大时导致原来代码混乱。
issue_xxx
该分支用于解决 jira 上 bug，修改完成并验证后合并到 dev 分支，等待 QA 验证。
说明：关于以上 feature_xxx 和 issue_xxx 分支的使用说明可以根据实际情况进行参考，不是规定死的，在开发过程中有疑问可以跟大家讨论。
二、分支命名规范
1 | master |