根据这两天对已有项目的熟悉和整理，现对该项目可优化点进行整理。其中已经明确了部分优化点，其它优化点需在现有项目中梳理完毕进行分析后得知，并需要结合业务考虑各优化点的可行性。同时需要长期跟踪线上崩溃日志，及时解决线上崩溃。
该文档为后续项目的整体优化改造梳理了方向，同时对可能存在的问题进行了部分说明。项目优化是持久战，需认真对待。
因优化点涉及内容较多，工作量大，应分期逐步完成，初步分期工作如下，目前正在进行一期优化工作，已经完成了CocoaPods优化工作和安装包瘦身一期工作。
一期：Xcode警告优化、Code Snippet、CocoaPods优化、Target优化、安装包瘦身优化二期、启动时间分析优化、系统权限排查、无用系统库排查、极光推送更新。
二期：梳理现有项目，各方面性能优化梳理和分析、现有代码优化、数据库缓存优化。
三期：基础控件组件化、网络中心优化。
四期：业务模块化、私有库。
完整可优化点如下：
- 开发工具
- Xcode警告优化
现状：目前Xcode警告多达700+，大量的警告信息预示着可能存在代码问题和异常，同时降低编译速度。
优化：屏蔽CocoaPods托管的第三方库警告信息，根据现有警告信息逐个排查解决，修复警告。因其它第三方库源码导致的警告尽量设置忽视警告，提高编译速度，降低潜在风险。
- Xcode Code Snippet （次要）
现状：代码片段为每个开发人员自行添加，涉及面不全。未对现有业务代码进行添加。
优化：整理系统常用代码片段和项目业务共用代码片段，保存代码片段，提高开发效率。
- 第三方库
- CocoaPods优化
现状：目前部分第三方库由CocoaPods托管，部分代码以源码形式导入工程。
优化：梳理项目用到的所有第三方库，已修改过源代码的第三方库禁止采用CocoaPods托管，其它未修改的尽量采用CocoaPods进行托管。
- Target优化
现状：目前项目分为2个Target，分别为A和B。第三方库未区分Target，导致A存在部分用不到的第三方库。同时也可以为A和B两个Target安装包瘦身。
优化：通过Target进行第三方库分组。
- 极光推送优化
现状：现有极光推送版本为3.0.0版本，线上每版因极光推送导致的崩溃日志约10条左右，通过网络查询，该版本存在前后台切换导致崩溃的bug。
优化：替换极光推送SDK，并进行相关测试，确保推送功能不受影响。
- 安装包瘦身
现状：
目前存在A和B两个APP，因不同APP包含类库资源不同，导致安装包大小不同。之前已经做过一次瘦身优化，清理了部分无用图片和类，现有A项目加固后的Ad Hoc总包约为72M，B项目加固后的Ad Hoc总包约为84M。
优化：
1、无用类：结合工具扫描项目中从未被引用的类文件，并结合项目查找进行确认。逐个模块排查，对于不常见类或未功能类进行功能确认和项目中查找。
2、第三方库：通过Target分组进行区分，无用第三库的逐个排查。
3、图片资源：部分图片资源采用Target分组区分，结合工具扫描未使用的图片资源，并结合项目查找进行确认，尝试图片无损压缩。
4、启动图和ICON 按Target分组，目前B项目启动图约10M。
5、代码按Target分组，结合条件编译，目前部分B Target代码会打包到A Target中。
6、Xcode设置优化。
- 启动时间优化
现状：现有APP启动时间未存在明显问题，启动速度快。但仍需分析现有启动时间和启动加载项，如需优化可从以下着手：
1、分析现有APP冷启动时间，设置系统参数打印预启动各阶段时间，埋点统计启动后到主界面显示完毕所需时间。
2、整理项目中无用分类和无用类文件，结合工具排查和人工排查。
3、无用系统库排查，对无用系统库进行移除。
4、部分SDK配置初始化时间点后移，在完成启动再进行相关配置。
- 性能优化
性能优化涉及面大，需根据具体分析结果进行针对性的优化。可排查点如下：
1、界面性能排查，结合Instruments工具进行排查，排查是否存在离屏渲染、图层叠加等，排查各界面帧率是否存在问题。
2、循环引用排查，结合Instruments和第三方MLeaksFinder、FBRetainCycleDetector等工具类进行排查，排查是否存在循环引用情况，是否存在界面pop后未被释放的情况。
3、内存使用排查，结合Instruments工具关注各界面使用时，内存的使用情况，分析是否存在优化点。
4、耗电量使用排查，结合Instruments工具排查APP总体耗电量水平，并分析是否存在可优化点。
5、网络流量监控，结合Instruments和第三方工具进行汇总，并分析如何进行流量优化。
- 代码优化
1、NSUserDefaults优化
现状：用户信息缓存、设置配置项均采用NSUserDefaults进行存储，多人开发阶段易发生key值覆盖问题。
优化：对NSUserDefaults进行封装，提供统一存取方法，开发阶段对存储的key进行校验，如已存在该key值，则在开发阶段提醒开发人员更换key值。
2、NSNotificationCenter
现状：目前推送均直接使用NSNotificationCenter，各通知名称定义分散，对现有通知名称定义不清晰。
优化：梳理现有使用通知的场景和位置，并分析存在的可优化点。例如：统一封装通知中心，统一定义通知名称。
3、用户信息
现状：用户信息的存储和更新发生在登录、进入首页、我的信息等界面，每个界面的网络请求触发和数据处理都是单独的。
优化：梳理涉及用户信息存储和使用的地方，并分析存在的可优化点。例如：统一用户信息的相关逻辑，包括请求存储读取。
4、首页和登录页
现状：进入首页和进入登录页，存在于注册完成或者修改密码、退出登录等场景，每个场景都是单独获取进行跳转，如后期修改涉及地方较多。
优化：梳理涉及到的界面，统一管理RootController的跳转逻辑。
5、版本检测
现状：APP从后台到前台会检测版本，我的界面显示了版本检测就会调用一次版本检测。
优化：统一版本检测，对我的界面频繁调用版本检测进行优化。
6、第三方库中介者
现状：APP中对于第三方库在业务模块中均为直接引用，对业务代码入侵性大，耦合度高，一旦修改或替换第三方库，业务模块代码涉及改动较多。例如：MJRefresh下拉刷新控件。
优化：梳理现有第三方库在业务代码中直接引用的情况，并分析单独封装后替换的可行性。
7、其它
梳理现有代码是否存在其它可优化点，并结合业务进行相关优化。
- 数据库和缓存优化
1、业务相关缓存优化
现状：目前业务基础数据相关数据缓存是在进入首页后完成的，通过接口返回时间点判断是否需要更新本地缓存。
优化：梳理现有缓存耗时和缓存失败后续更新机制，分析可优化点。
2、城市缓存优化
现状：行政区域缓存是在首次获取城市信息后，由接口返回全部城市数据和当前版本号，APP数据库缓存全部城市和版本号，下次请求时会将当前缓存的版本号传递给后台，后台进行判断决定是否返回全部城市数据。目前在存储数据时，界面会存在短暂卡顿。
优化：数据插入采用事务机制，存在缓存时优先显示缓存数据，然后再展示接口请求的当前城市。
3、用户信息缓存
现状：目前用户信息的缓存直接存储在NSUserDefaults中，安全性低。
优化：整理涉及用户信息的缓存，考虑迁移至钥匙串中的可行性。并充分考虑本地用户信息的安全。
4、其它缓存
梳理其它涉及缓存的功能点，并结合具体业务场景分析可优化点。
- 网络优化
- 现有网络请求整理：
1、APP启动涉及请求整理
整理APP启动阶段涉及到的网络请求，目前AppDelegate中启动后会调用两次初始化接口、版本检测接口，分析可优化点。
2、APP首页涉及网络请求整理
目前首页存在大量网络请求，整理并分析可优化点。
3、各模块功能涉及网络请求整理
统计各模块涉及到网络请求，梳理共性请求进行封装，避免相同代码编写多处的问题。梳理各模块接口逻辑，分析可优化点。
- 接口中心优化
现状：目前各个接口统一在接口工具类中进行封装，所有接口方法都在其中，请求参数均通过拼接生成，一旦修改涉及面较大，同时改动一处就会导致重新编译时间较长。
优化：梳理现有接口方式，并分析可优化点。例如：接口中心细分，建议按业务模块拆分，不同模块负责不同接口处理。对xml参数拼接尽量通过对象完成自动转换。
- 控件组件化
1、基础控件组件化
现状：目前各UI控件均为每个界面单独编写，且存在样式不统一现象，在开发新需求时已存在重复劳动。一旦统一更换UI，涉及面大。例如：按钮样式、分段控件样式、列表样式。
优化：梳理现项目中所有UI控件，并针对使用频率和共用性进行分组，优先组件化共用性控件。并针对提取的UI组件提供基础组件库。
2、业务控件组件化
梳理现有公共业务控件进行组件化。
3、路由中心
现有VC跳转均通过import导入和push方式进行，如进行模块拆分后，此方法太过依赖。分析现有业务场景，搭建适合的路由中心。
- 业务模块化
项目工程按模块分拆，A、B、C、D、E模块化，结合CocoaPods引入私有库。每个单独业务线为一个工程，最终通过私有库接入主工程，各业务线开发之前不受相互影响。
因私有库要求较高，必须具备完备的组件库和路由中心后再根据颗粒度决定业务模块如何拆分。
- 十一.RN接入
目前主流混合开发为React Native、WEEX、Flutter，三者相比较而言RN成熟，技术文档多。对于RN的接入，分析现有APP功能点，梳理接入可行性。RN的接入主要为运营提供服务和其跨平台热修复的特性。
