安卓app启动速度优化,一个月成功收割腾讯、阿里、字节offer

安卓app启动速度优化,一个月成功收割腾讯、阿里、字节offerAndroid 开发者该如何提升自己 说说我的两点建议 1 横向发展 适合有自己专精技术的人 在自己擅长领域深入钻研的同时 会 Hybrid 开发 Flutter RN H5 之外 会 web 开发 微信小程序等

大家好,我是讯享网,很高兴认识大家。

Android开发者该如何提升自己?

说说我的两点建议:

1、横向发展:(适合有自己专精技术的人)

在自己擅长领域深入钻研的同时,会Hybrid开发(Flutter,RN,H5)之外,会web开发、微信小程序等,再过5年你也完全不用担心找工作。但是,这确实比较难,全栈容易发展成全菜,就是啥都知道,啥都不精!

2、纵向发展:(适合大多数人)

如果做应用开发,就往应用架构方向发展;如果做系统层开发,就钻研底层驱动。

可以从以下这些方面进行学习:

移动架构

架构展示层:MVC、MVP、MVVM、Android Architecture Components;

架构层:模块化->组件化->插件化->沙盒/双开技术;

基础进阶:

比如高级自定义View、Android Framework层原理, App 管理机制等等;

JNI 和 NDK 开发也是比较常见,5G来了,招聘单位都在给自己公司规划小视频功能,然而我们却连NDK都不懂;

学习开发语言:

比如Kotlin,做底层C/C++是必不可少的,还有一个最容易忽略的 Java语言本身的高级面向对象思想;

源码:

看懂并且熟悉源码,熟悉其实现原理,争取做到能自己二次封装三方库。


讯享网

TCP与UDP的区别

  • TCP面向连接的, 传输数据时,需先进行三次握手,建立连接,UDP是无连接的,发送数据之前不需要建立连接
  • TCP通过确认和重传机制,提供可靠的服务。即通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达,而UDP不保证可靠传输,只是尽可能得交付
  • TCP面向字节流,即将数据看成一连串无结构的字节流。UDP是面向报文的,UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)
  • 每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
  • TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道

TCP的三次握手和四次挥手

这个概念大家一定不陌生,我以前写过一篇详细关于TCP的三次握手和四次挥手的文章,可以参考,这里就不赘述

TCP流量控制

很多人会将流量控制和拥塞控制搞混,所以单独拎出来,考究细节

流量控制:如果发送者发送数据过快,接收者来不及接收,那么就会有分组丢失。流量控制策略就是控制发送者的发送速度,使得接收者来得及接收,达到不丢失分组的目的。流量控制是构成TCP可靠性的一方面。

流量控制主要使用滑动窗口机制实现。下面以上图讲解滑动窗口(也叫接受窗口rwnd)的细节

主机A向主机B发送数据,开始双方确定的窗口值为400字节,这两个是前提条件。开始A发送了200字节,之后发生了分组丢失现象,B调整接受窗口大小为300字节。之后A又连续发送了300字节。此时A已经不能发送数据,需等待B的窗口信号。之后B调整窗口为100字节。接收到100字节数据后,调整窗口值为0,表示暂时不想接受数据。总共B调整了三次窗口大小,进行了三次流量控制

假如,B向A发送了零窗口的报文段后不久,B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段,然而这个报文段在传送中丢失 了。A一直等待收到B发送的非零窗口的通知,而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态,TCP为每个连接设有一个持续计时器。只 要TCP连接的一方收到对方的零窗口通知,就启动持续计时器,若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带1字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值。

TCP拥塞控制

拥塞控制,大家都能背出来,什么慢开始、拥塞避免、快重传、快恢复,大家都耳熟能详,但是有些细节问题,可以大家没有留意,比如快重传阶段后,为什么不直接进入慢开始阶段,而是进入拥塞避免阶段?

拥塞的概念:在某段时间,对网络中的某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变化,这种情况叫拥塞。网络拥塞往往是由许多因素引起的,简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题。拥塞问题的是指往往是整个系统的各个部分不匹配,只有各个部分平衡了,问题才会得到解决。

拥塞控制:防止过多的数据注入到网络,导致网络中的路由器或链路过载。

流量控制和拥塞控制的区别:可以看出流量控制是一个端到端的问题,而拥塞控制是一个全局性问题,设计到所有的主机、所有的路由器。

慢开始:乘法增加

发送方维持一个拥塞窗口cwnd,大小取决于网络的拥塞程度,动态地在变化。发送窗口小于等于拥塞窗口,而发送窗口一定不能超过接收窗口。发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就增大一些,以便把更多的分组发送出去。但是只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络的分组数。

开始时,如果发送大量数据包,容易导致网络中路由器缓冲空间耗尽,从而发生拥塞。所以新建连接时,cwnd初始化为1个最大报文段(MSS)大小,每经过一个迭代,拥塞窗口就乘以2,所以也称为乘法增加阶段。拥塞窗口不可能一直增大,所以一般会设置一个慢开始门限ssthresh.

  • 当cwnd<ssthresh时,使用慢开始算法。
  • 当cwnd>ssthresh时,改用拥塞避免算法。

拥塞避免:加法增大

一旦达到慢开始的初始门限ssthresh,就进入了拥塞避免阶段。每一个迭代,拥塞窗口加1,而不是加一倍

快重传

快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。快重传策略是为了防止TCP连接因等待重传计时器超时而空闲较长的时间。

快恢复

快重传和快恢复是搭配使用的,快重传完成后,立即执行快恢复算法。将ssthresh门限设置为当前拥塞窗口的一半,之后将拥塞窗口设置为新的ssthresh门限(即减半), 进入拥塞避免阶段。

这里可能会有人有疑问,为什么不直接进入慢开始阶段,更彻底得避免拥塞。主要的原因是考虑到如果网络出现拥塞得话,就不会收到多次重复确认,所以发送方认为网络可能没有出现拥塞,所以不执行慢开始算法,而是将cwnd设置为新得ssthresh门限,执行拥塞避免算法

最后

自我介绍一下,小编13年北京科技大学毕业,曾经在字节跳动待过,也去过vivo、小米等大厂,18年进入华为一直到现在。

小编这些年深知大多数初中级Android工程师,想要提升自己,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助

因此我收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担,能在岗位上再创辉煌,步步高升!!。

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点!不论你是刚入门Android开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有所帮助,需要这份学习资料的朋友可以戳我获取!!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
料的朋友可以戳我获取!!](https://bbs.csdn.net/topics/)

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

小讯
上一篇 2025-03-14 12:51
下一篇 2025-03-27 10:36

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/38369.html