- 直接显示内容而不是弹出需要注册登录的页面
- 通过交互引导用户，而不是一些文字引导
- 延迟请求授权，而不是一下登录之后就开始要权限（定位，相机，图片）。
针对延迟请求，想到一个好主意，就是新建一个类，可以是单例，负责管理这些请求。
App Startup Time: Past, Present, and Future
了解在苹果平台上使用的dyld动态链接器，它是如何在这些年来发生变化的，以及它下一步的发展方向。了解改进的工具如何使优化应用程序的启动时间变得更容易，并了解dyld中的新更改如何进一步改善启动时间。
startup time 启动时间
main函数执行之前所用的时间
launch closure启动收尾
启动你的程序所需要的全部信息，比如使用什么dylib，他们的哪些偏移位置用于不同的符号，代码签名是什么，
Improving App Startup Time
Do less！
- Ember fewer dylibs
- Declear fewer classes/methods
- Use fewer initializers
减少代码，代码越少，启动速度越快。使用更少的dylib，减少嵌入的dylib,使用系统库效果会更好。应该声明较少的库和方法，减少初始化函数( 初始化函数是在main函数执行之前执行 )。
Use more Swift
- No initializers
- Swift size improvements
因为Swift从设计上避免了许多的陷阱，在c、c+++、oc可能遇到这些陷阱。
Swift没有初始化器，不允许特定类型的未对齐的数据结构。所以转向Swift可以让你更容易获得快速的程序启动(Apple says)。
Static initilizer tracing
静态初始化追踪器，instrument提供每个静态初始化器的准确时间。方便知道初始化的过程花费了多久的时间。
dyld3
为什么推出dylb3
提升速度（启动应用的时候尽量多的减少工程量）
增强安全（更积极的安全检查）
可测试性和可靠性
怎么做到上述目标
速度
把复杂操作dylb移出进程
- 现在大多数dylb只是普通的后台程序
允许部分dylb驻留在进程之中
- 减少受攻击面积（驻留部分要尽可能少）
- 提高启动速度
- 最快的代码就是你不写代码
- 关注那些你几乎不执行的代码
安全
确定安全敏感性组件身份
- 边界检查
- @rpath 攻击
标识可占用缓存的组件
- 依赖关系不会改变
- 符号在库中的偏移位置不会发生改变
dylb3有三个部分
- 一个进程外的macho 解析编译器
- 一个进程内的处理闭包（launch closures）的引擎
- 一个缓存服务的启动闭包（launch closures）
大多数启动的时候使用缓存不会触发进程外的mach-o parser/compiler
launch closures比mach-o更简单
launch closures为速度而构建
使用dylb3要注意什么
完全兼容dylb2.x
- 一些apis关闭了dylb3的优化导致程序变慢或者会在dylb3中使用回退模式
- 一些为dylb2.x的优化不再有任何影响
严格的链接语义
在加入新动态连接器后，很多的语义可能现在还无法使用，甚至是错误的。
- 放入一个支持旧二进制数据的工作区
- 新的二进制数据可能导致链接错误