读了一篇不错的文章，记录一下, (侵删)
- 原文： Android系统优化的那10年
大前提
- 没代码，是最牛的优化--在阶段去掉某些功能；
- 非关键逻辑，延后处理
- 非关键逻辑，考虑提前处理
- 关键逻辑，多线程，并发处理
- 缓存部分结果，减少重复执行次数
- 一次多操作，减少操作次数
app启动优化
- apk redex优化；
- 尽量保证热启动；
- 启动时候禁止kill，gc等耗时任务；
- Launcher优先响应click事件，其它任务异步化或延迟执行；
- view对click事件提前串行执行；
- 启动动画单独设计和速率等调整，这个很影响速度；
- app进程预创建和缓存-可以节约30-50ms左右；
- 耗时class预加载/异步加载；
- app的renderthread等预先启动，gpu等环境预先初始化和缓存-节约几十ms；
- app的theme、layout等和业务逻辑无关的资源可以预先load和缓存-可以节约上百ms；
- app的lib so使用监控，预mmap；
- 系统层so合并和缓存，提升so加载速度;
- app 减少不必要业务路径，延迟不重要逻辑；
- 系统级dns缓存-可以节约100~400ms左右；
- app启动流程task化，充分利用多核cpu，避免锁等待。
- ams启动大锁优化，有限保证top-app和system_server各个核心线程占有cpu优势资源;
- 各类boost和top-app的大核独占绑定、优先级调高，后台进程优先级调低；
app运行优化
- 非主activity等class，可以在startActivity后手动classloader.loadClass()；
- looper里消息分类和优先级：类型数组->优先级链表/数组->同优先级消息链表；
- tp报点优化：缩短休眠唤醒间隔、提高采样率，优化坐标计算算法；
- 不等sync信号，直接先处理input事件流程，点击提前处理，滑动阈值、摩擦力参数优化,input也可以单独线程处理；
- view对click事件考虑串行不走post，click effect异步化或优先处理onclick;
- 子线程分担ui线程input/../measure/layout任务-facebook方案可以参考；
- app动态分辨率-部分app降低分辨率不影响体验；
- app自身各类listview\recycleview的item view细化缓存；
- app自身layout优化，自定义层级、减少层级等；
- framework层measure时动态优化不必要的viewgroups，减少层级；
- view跨context缓存，切换activity时更新view的context相关内容；
- gpu数据并行化；
- SurfaceFlinger过滤多余layer，动态fps；
- 其它系统级：app线程的cpu核心绑定，cpu\gpu频率，场景化boost，预留足够内存，减少不必要的io，提高cpu、disk、net 优先级。irq balance。cgroups可以限制cpu、mem、disk 、net、io，要充分利用保证top-app优先使用。
- 注意thermal导致的限速降频等；
- 整个系统为了高扩展性移植性等架构，多采用分层结构，但客制化对应的系统可以打破原有架构设计，根据top-app等android特有性能设计更好优先级、实时性的场景化方案，比如优先响应top-app的网络请求，io请求等。
- 机器码优化运行，减少字节码解析运行--目前几乎都是arm芯片，google可以考虑放弃通用性，单独编译成机器码级别app。
其实，google现在也越来越关注开发者意见了。系统方可以开放2类api:
- app启动加速api:提供api给app 预加载缓存，提高冷启动速度；
- app运行调频api: 微信把厂商提供给它的boost api封装成 Hardcoder 也开源的；
思路来源
- app或系统自身的各类指标监控，关键点同步到服务端--标准产品研发逻辑；
- 用户反馈问题专项攻关--能发现更广更接近用户的迫切问题；
- 各类方案借鉴：前端、后台、移动端等的业务方向，同类产品思路的相互借鉴，app、framework、native、kernel、driver、硬件等层级方向；--跨界思考
- 逆向各类rom、app；专利分析，产品宣传分析;
- 高薪招聘xx岗，面试友商相关人员，进行方案、思路获取。
- 上下游合作：华为和王者荣耀合作，一加和游戏引擎厂商unity3d合作。
