注册
环信即时通讯云

环信即时通讯云

单聊、群聊、聊天室...
环信开发文档

环信开发文档

Demo体验

Demo体验

场景Demo,开箱即用
RTE开发者社区

RTE开发者社区

汇聚音视频领域技术干货,分享行业资讯
技术讨论区

技术讨论区

技术交流、答疑
资源下载

资源下载

收集了海量宝藏开发资源
iOS Library

iOS Library

不需要辛辛苦苦的去找轮子, 这里都有
Android Library

Android Library

不需要辛辛苦苦的去找轮子, 这里都有

iOS之SDWebImage内部实现原理 - 面试必问!

原理图片解释:内存层面的相当于一个缓存器,以key-value的形式存储图片。当SDImageCache缓存使用的LRU(最近最右淘汰算法)算法,来做缓存机制。当SDWebImageManager向SDImageCache要资源时,先搜索内存层面的数据,如果有...
继续阅读 »

原理

图片解释:内存层面的相当于一个缓存器,以key-value的形式存储图片。当SDImageCache缓存使用的LRU(最近最右淘汰算法)算法,来做缓存机制。当SDWebImageManager向SDImageCache要资源时,先搜索内存层面的数据,如果有就直接返回,如果没有的话访问磁盘,将图片从硬盘读取出来,然后解码(Decoder),将图片对象到内存层面做备份,在返回调用层。

SDWebImage加载图片整体流程

  1. 入口 setImageWithURL:placeholderImage:options: 会先把 placeholderImage 显示,然后 SDWebImageManager 根据 URL 开始处理图片。

  2. 进入SDWebImageManager,调用downloadWithURL:delegate:options:userInfo:

  3. 交给SDImageCache从缓存中查找图片是否已经下载:queryDiskCacheForKey:delegate:userInfo:

  4. 如果内存中已经有图片缓存,SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo: 到 SDWebImageManager。

  5. SDWebImageManagerDelegate 回调 webImageManager:didFinishWithImage: 到 UIImageView+WebCache 等前端展示图片。

  6. 如果内存缓存中没有,生成 NSInvocationOperation 添加到队列开始从硬盘查找图片是否已经缓存。

  7. 根据 URLKey 在硬盘缓存目录下尝试读取图片文件。这一步是在 NSOperation 进行的操作,所以回主线程进行结果回调 notifyDelegate:。

  8. 如果上一操作从硬盘读取到了图片,将图片添加到内存缓存中(如果空闲内存过小,会先清空内存缓存)。然后会进行第4、5步骤来展示图片

  9. 如果从硬盘缓存目录读取不到图片,说明所有缓存都不存在该图片,需要下载图片,回调 imageCache:didNotFindImageForKey:userInfo:

  10. 共享或重新生成一个下载器 SDWebImageDownloader 开始下载图片

  11. 图片下载由 NSURLConnection 来做,实现相关 delegate 来判断图片下载中、下载完成和下载失败。

    • connection:didReceiveData:中利用 ImageIO 做了按图片下载进度加载效果。

    • connectionDidFinishLoading: 数据下载完成后交给 SDWebImageDecoder 做图片解码处理。

      • 图片解码处理在一个 NSOperationQueue 完成,不会拖慢主线程 UI。如果有需要对下载的图片进行二次处理,最好也在这里完成,效率会好很多。
      • 在主线程 notifyDelegateOnMainThreadWithInfo: 宣告解码完成,imageDecoder:didFinishDecodingImage:userInfo: 回调给 SDWebImageDownloader。
  12. imageDownloader:didFinishWithImage: 回调给 SDWebImageManager 告知图片下载完成。

  13. 通知所有的 downloadDelegates 下载完成,回调给需要的地方展示图片。

  14. 将图片保存到 SDImageCache 中,内存缓存和硬盘缓存同时保存。写文件到硬盘也在以单独 NSInvocationOperation 完成,避免拖慢主线程。

  15. SDImageCache 在初始化的时候会注册一些消息通知,在内存警告或退到后台的时候清理内存图片缓存,应用结束的时候清理过期图片。



作者:枫叶无处漂泊
链接:https://www.jianshu.com/p/70620ccdfdb7


收起阅读 »

iOS非越狱注入插件

准备工作这里我们以QQ App来举例,这里需要注入的是我自己写的一个QQPlus这个插件; 首先我们需要准备以下文件:. ├── CydiaSubstrate ├── QQ.ipa ├── QQPlus.dylib ├── QQPlusSetting.bund...
继续阅读 »

准备工作

这里我们以QQ App来举例,这里需要注入的是我自己写的一个QQPlus这个插件; 首先我们需要准备以下文件:

.
├── CydiaSubstrate
├── QQ.ipa
├── QQPlus.dylib
├── QQPlusSetting.bundle
│ ├── Root.plist
│ ├── en.lproj
│ │ └── Root.strings
│ └── interface.json
├── blank.caf
├── cy.csv
└── libsubstitute.0.dylib
  • CydiaSubstrate: 从越狱手机目录/Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate拷贝出来
  • libsubstitute.0.dylib: CydiaSubstrate依赖文件, 从越狱手机目录/usr/lib/libsubstitute.0.dylib拷贝出来
  • QQ.ipa: 一个砸壳后的ipa文件, 如果没有砸壳则无法进行以下操作, 可以使用otool验证是否加壳
  • QQPlus.dylib: 需要注入的插件(确保可用)
  • QQPlusSetting.bundle: QQPlus.dylib插件需要依赖文件
  • blank.caf: QQPlus.dylib插件需要依赖文件
  • cy.csv: QQPlus.dylib插件需要依赖文件


  • 开始注入

    1. 首先我们把QQ.ipa包解压(ipa就是个压缩包, 直接解压或者使用命令解压都可)
    unzip QQ.ipa

    解压完成后我们先确认包是否加密, 使用otool命令

    cd Payload/QQ.app/
    otool -l QQ | grep crypt

    输入以上命令后输出

    cryptoff 28672
    cryptsize 4096
    cryptid 0

    这里cryptid0则为未加密, 确认了未加密后我们就可以开始注入了;

    1. CydiaSubstrate改名为libsubstrate.dylib然后将以下文件拷贝至/Payload/QQ.app/Frameworks目录

    libsubstrate.dylib
    libsubstitute.0.dylib
    QQPlus.dylib

    修改libsubstrate.dylib依赖文件
    因为libsubstrate.dylib是从越狱手机上拷贝出来的, 他的一个依赖文件ibsubstitute.0.dylib的路径是/usr/lib/libsubstitute.0.dylib, 我们需要将他修改到Frameworks目录下, 否则会闪退, 使用otool命令查看:

    aria@shenqiHyaliyadeMacBook-Pro  ~/Desktop/remake/QQ  otool -L libSubstrate.dylib
    libSubstrate.dylib (architecture arm64):
    /usr/lib/libsubstrate.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libsubstitute.0.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
    CydiaSubstrate (architecture arm64e):
    /usr/lib/libsubstrate.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libsubstitute.0.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    可以看到倒数第三个依赖, 我们需要使用install_name_tool命令修改他

    install_name_tool -change "/usr/lib/libsubstitute.0.dylib" "@executable_path/Frameworks/libsubstitute.0.dylib" libSubstrate.dylib

    然后再次使用otool命令查看是否修改成功

    aria@shenqiHyaliyadeMacBook-Pro  ~/Desktop/remake/QQ  otool -L libSubstrate.dylib
    libSubstrate.dylib (architecture arm64):
    /usr/lib/libsubstrate.dylib (compatibility version 0.0.0, current version 0.0.0)
    @executable_path/Frameworks/libsubstitute.0.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
    libSubstrate.dylib (architecture arm64e):
    /usr/lib/libsubstrate.dylib (compatibility version 0.0.0, current version 0.0.0)
    @executable_path/Frameworks/libsubstitute.0.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    这里可以看到已经把/usr/lib/libsubstitute.0.dylib已经被修改为@executable_path/Frameworks/libsubstitute.0.dylib

    1. 修改QQPlus.dylib插件依赖
      因为是越狱插件, 所以他的依赖是/Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate, 但是在非越狱手机上是肯定没有这个依赖的, 所以我们一样需要对他进行修改, 用otool命令查看依赖

    aria@shenqiHyaliyadeMacBook-Pro  ~/Desktop/remake/QQ  otool -L QQPlus.dylib
    QQPlus.dylib:
    /Library/MobileSubstrate/DynamicLibraries/QQPlus.dylib (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/CoreGraphics.framework/CoreGraphics (compatibility version 64.0.0, current version 1355.22.0)
    /System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1677.104.0)
    /System/Library/Frameworks/MobileCoreServices.framework/MobileCoreServices (compatibility version 1.0.0, current version 1069.25.0)
    /System/Library/Frameworks/QuartzCore.framework/QuartzCore (compatibility version 1.2.0, current version 1.11.0)
    /System/Library/Frameworks/Security.framework/Security (compatibility version 1.0.0, current version 59306.142.1)
    /System/Library/Frameworks/SystemConfiguration.framework/SystemConfiguration (compatibility version 1.0.0, current version 1061.140.1)
    /System/Library/Frameworks/UIKit.framework/UIKit (compatibility version 1.0.0, current version 61000.0.0)
    /Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
    /System/Library/Frameworks/AVFoundation.framework/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
    /System/Library/Frameworks/CFNetwork.framework/CFNetwork (compatibility version 1.0.0, current version 0.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
    /System/Library/Frameworks/CoreTelephony.framework/CoreTelephony (compatibility version 1.0.0, current version 0.0.0)
    这里可以很清楚的看到一个依赖/Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate, 同样我们需要使用install_name_tool命令修改他把他修改到Frameworks目录下的libSubstrate.dylib

    install_name_tool -change "/Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate" "@executable_path/Frameworks/libSubstrate.dylib" QQPlus.dylib

    再使用otool命令查看是否成功修改依赖

    aria@shenqiHyaliyadeMacBook-Pro  ~/Desktop/remake/QQ  otool -L QQPlus.dylib
    QQPlus.dylib:
    /Library/MobileSubstrate/DynamicLibraries/QQPlus.dylib (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/CoreGraphics.framework/CoreGraphics (compatibility version 64.0.0, current version 1355.22.0)
    /System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1677.104.0)
    /System/Library/Frameworks/MobileCoreServices.framework/MobileCoreServices (compatibility version 1.0.0, current version 1069.25.0)
    /System/Library/Frameworks/QuartzCore.framework/QuartzCore (compatibility version 1.2.0, current version 1.11.0)
    /System/Library/Frameworks/Security.framework/Security (compatibility version 1.0.0, current version 59306.142.1)
    /System/Library/Frameworks/SystemConfiguration.framework/SystemConfiguration (compatibility version 1.0.0, current version 1061.140.1)
    /System/Library/Frameworks/UIKit.framework/UIKit (compatibility version 1.0.0, current version 61000.0.0)
    @executable_path/Frameworks/libSubstrate.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
    /System/Library/Frameworks/AVFoundation.framework/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
    /System/Library/Frameworks/CFNetwork.framework/CFNetwork (compatibility version 1.0.0, current version 0.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
    /System/Library/Frameworks/CoreTelephony.framework/CoreTelephony (compatibility version 1.0.0, current version 0.0.0)

    这里可以看到依赖已经被修改为@executable_path/Frameworks/libSubstrate.dylib

    1. 拷贝QQPlus.dylib依赖文件到QQ.app根目录下(如果插件没有依赖文件则不需要此步骤, 由于我自己写的QQPlus.dylib需要依赖blank.cafcy.csvQQPlusSetting.bundle这三个文件, 所以需要一起拷贝进去)

    2. 修改QQ主程序, 插入Load Commands, 使用optool或者insert_dylib都行, 这里以optool进行操作:


    aria@shenqiHyaliyadeMacBook-Pro~/Desktop/remake/QQ/Payload/QQ.app  optool install -c load -p "@executable_path/Frameworks/QQPlus.dylib" -t QQ
    Found thin header...
    Inserting a LC_LOAD_DYLIB command for architecture: arm64
    Successfully inserted a LC_LOAD_DYLIB command for arm64
    Writing executable to QQ...

    再次使用otool命令查看是否注入成功

    aria@shenqiHyaliyadeMacBook-Pro~/Desktop/remake/QQ/Payload/QQ.app  otool -L QQ
    QQ:
    @rpath/QQMainProject.framework/QQMainProject (compatibility version 1.0.0, current version 1.0.0)
    ...
    @executable_path/Frameworks/QQPlus.dylib (compatibility version 0.0.0, current version 0.0.0)

    这里可以看到我们已经插入了@executable_path/Frameworks/QQPlus.dylib

    1. 打包QQ.ipa, 使用zip命令
    zip -ry target.ipa Payload
    重新签名安装
    由于修改了包内容, 所以需要重新签名, 签名可以参考其他文章或者使用第三方软件;
    安装成功后插件成功被加载, 效果如下:







    作者:神崎H亚里亚
    链接:https://www.jianshu.com/p/741eda8d460f



    收起阅读 »

    iOS-底层原理 :类的加载

    1.1 进入 map_imagesvoid map_images(unsigned count, const char * const paths[], const struct mach_header * const mhdrs[]) ...
    继续阅读 »

    一、map_images源码初探

    1.1 进入 map_images

    void
    map_images(unsigned count, const char * const paths[],
    const struct mach_header * const mhdrs[])
    {
    mutex_locker_t lock(runtimeLock);
    return map_images_nolock(count, paths, mhdrs);
    }


    • map_images中调用了map_images_nolock
    • map_images:管理文件中和动态库中的所有符号(class protocol selector category)

    1.2 进入 map_images_nolock


    • map_images_nolock方法中,会进行首次初始化。

    • 调用关键方法_read_images读取镜像文件。

    1.3 进入 _read_images

    由于代码量过大,只显示关键代码,请自行查阅


    • _read_images中做了以下操作,即是对(selector class protocol category )的处理
    1. 条件控制进行一次加载
    2. 修复预编译阶段的 @selector 的混乱问题
    3. 检测类,修复现在不处理的,将来需要处理的类,标记bundle
    4. 修复重映射一些没有被镜像文件加载进来的类
    5. 修复旧的objc_msgSend_fixup调用站点
    6. 检测协议,修复协议,当我们类里面有协议的时候调用readProtocol
    7. 修复没有被加载协议
    8. 分类处理,启动时的类别初始化完成后才走if里面,被推迟到对_dyld_objc_notify_register的调用完成后的第一个load_images调用为止
    9. 非懒加载类处理,实现了+load方法的类叫非懒加载类
    10. 没有被处理的类,优化那些被侵犯的类

    1.4 进入 readClass

    _read_images流程中的第三步,我们找到了关键方法readClass




    • addNamedClass:把cls绑定上插入到内存中存类的数据表中
    • addClassTableEntry:把cls加入到需要开辟内存的类的表

    既然我们已经把存到了内存中,那我们中的方法属性协议又是什么时候存进入的呢?是怎么从mahodata中拿到rwrwe的呢?我们还不得而知。

    现在我们的研究对象是,而_read_images与类相关的只有第三步,第九步和第十步,而第三步我们已经探索过,即是把类绑定名字加入到内存的两张表中,一张存类的表,一张存需要开辟内存的类的表,接着研究第九步和第十步


    1.5 探索与类相关的第九步和第十步

    首先在第九步中添加自定义条件,定位到研究对象GomuPerson,并加上2个断点,如下图所示


    • 经过断点调试,发现2个断点都不会走,但是我们又根据命名推断出了关键方法realizeClassWithoutSwift,但是没有调用

    于是我们推测,第九步没有走的原因,是不是因为判断条件不满足,非懒加载类才会走进if,接着我们探索一个拓展非懒加载类 & 懒加载类

    1.6 非懒加载类 & 懒加载类

    懒加载类:数据加载推迟到第一次发送消息的时候
    非懒加载类:map_images 的时候 加载所有类数据
    区分方法:当前类是否实现了 load 方法,实现则未非懒加载类

    懒加载类加载情况:GomuPerson中未实现load方法,在方法慢速查询lookUpImpOrForward(由于是第一次发送消息,缓存中没有数据,所以会进入到慢查询流程)中,插入以下代码,运行

    • 懒加载类不会调用_read_images第九步中的realizeClassWithoutSwift,而是在main函数中实例GomuPerson调用alloc方法发送消息的时候加载类
    • lookUpImpOrForward -> realizeClassMaybeSwiftMaybeRelock -> realizeClassWithoutSwift

    非懒加载类加载情况:GomuPerson中实现load方法,会调用第九步中的realizeClassWithoutSwift

    • 非懒加载类会调用_read_images第九步中的realizeClassWithoutSwift,在map_images加载类
    • _getObjc2NonlazyClassList -> realizeClassWithoutSwift

    GomuPerson中实现load方法,继续探索realizeClassWithoutSwift流程

    1.7 进入 realizeClassWithoutSwift

    调用realizeClassWithoutSwift之前,cls只是一个地址+name,ro,rw,rwe还没有,下面开始研究是否在realizeClassWithoutSwift对它们进行了操作






    收起阅读 »

    Compose | 一文理解神奇的Modifier

    写在最前Jetpack Compose的预览版出来已经有很长时间了,相信很多读者都进行了一番尝试。注意:下文如无特殊说明,Compose均指代Jetpack Compose可以说,Compose在声明布局时,其风格和React的JSX、Flutter 等非常的...
    继续阅读 »

    写在最前

    Jetpack Compose的预览版出来已经有很长时间了,相信很多读者都进行了一番尝试。注意:下文如无特殊说明,Compose均指代Jetpack Compose

    可以说,Compose在声明布局时,其风格和React的JSX、Flutter 等非常的相似。

    而且有一个高频出现的内容: Modifier,即 修饰器,顾名思义,它是一种修饰器, 在Compose的设计中,和UI相关的内容都涉及到它,例如:尺寸形状 等

    这一篇文章,我们一起学习两部分内容:

    • Modifier的源码和设计
    • SDK中既有的Modifier实现概览

    当然,最全面的学习文档当属:官方API文档 , 后续查询API的含义和设计细节等都会用到,建议收藏

    文中的代码均源自 1.0.1 版本

    先放大招,Modifier的45行代码

    其实有效代码行大约20行。

    先举个使用示例:

    Modifier.height(320.dp).fillMaxWidth()

    这里的 Modifier 是接口 androidx.compose.ui.Modifier 的匿名实现,这也是一个很有意思的实用技巧。

    我们先简单的概览下源码,再进行解读:

    interface Modifier {
    // ...
    companion object : Modifier {
    override fun foldIn(initial: R, operation: (R, Element) -> R): R = initial
    override fun foldOut(initial: R, operation: (Element, R) -> R): R = initial
    override fun any(predicate: (Element) -> Boolean): Boolean = false
    override fun all(predicate: (Element) -> Boolean): Boolean = true
    override infix fun then(other: Modifier): Modifier = other
    override fun toString() = "Modifier"
    }
    }

    而本身的接口则为:

    package androidx.compose.ui

    import androidx.compose.runtime.Stable

    interface Modifier {

    fun foldIn(initial: R, operation: (R, Element) -> R): R

    fun foldOut(initial: R, operation: (Element, R) -> R): R

    fun any(predicate: (Element) -> Boolean): Boolean

    fun all(predicate: (Element) -> Boolean): Boolean

    infix fun then(other: Modifier): Modifier =
    if (other === Modifier) this else CombinedModifier(this, other)
    }

    Modifier接口默认实现赏析

    先看Modifier接口,和Java8类似,Kotlin的接口可以提供默认实现, 显然, foldIn 和 foldOut 在这里是看不出门道的,必须结合 operation来看,先略过。

    any 和 all 也是看不出啥的,毕竟我把注释都删了 而 then 方法则有点意思,接收一个 Modifier 接口实例, 如果该实例是Modifier的内部默认实现,则认为是无效操作,依旧返回自身,否则则返回一个 CombinedModifier实例 将自身和 other 结合在一起。

    从这里,我们可以读出一点 味道 : 设计者一定会将一系列的Modifier设计成一个类似链表的结构,并且希望我们从Modifier的 companion实现开始进行构建。

    其实,结合注释,我们可以知道Modifier确实会组成一个链表,并且 any 和 all 是对链表的元素运行判断表达式。

    Modifier companion实现赏析

    再回过头来看 companion实现thenfoldInfoldOut 都是给啥返回啥, 再结合先前的接口默认实现,我们可以推断: 正常使用的话,最终的链表中不包含 companion实现 ,这从它的 any 和 all 的实现也可见一斑。

    很显然这是一个有意思的技巧,这里不做过多解析,但既然我这样描述,一定可以让它进入链表中的

    CombinedModifier 实现

    package androidx.compose.ui

    import androidx.compose.runtime.Stable

    class CombinedModifier(
    private val outer: Modifier,
    private val inner: Modifier
    ) : Modifier {
    override fun foldIn(initial: R, operation: (R, Modifier.Element) -> R): R =
    inner.foldIn(outer.foldIn(initial, operation), operation)

    override fun foldOut(initial: R, operation: (Modifier.Element, R) -> R): R =
    outer.foldOut(inner.foldOut(initial, operation), operation)

    override fun any(predicate: (Modifier.Element) -> Boolean): Boolean =
    outer.any(predicate) || inner.any(predicate)

    override fun all(predicate: (Modifier.Element) -> Boolean): Boolean =
    outer.all(predicate) && inner.all(predicate)

    override fun equals(other: Any?): Boolean =
    other is CombinedModifier && outer == other.outer && inner == other.inner

    override fun hashCode(): Int = outer.hashCode() + 31 * inner.hashCode()

    override fun toString() = "[" + foldIn("") { acc, element ->
    if (acc.isEmpty()) element.toString() else "$acc, $element"
    } + "]"
    }

    目前依旧缺乏有效的信息来解读 foldIn 和 foldOut 最终会干点啥,但可以看出其执行的次序,另外可以看出 any 和 all 没啥幺蛾子。

    看完 Modifier.Element 之后我们赏析下 foldIn 和 foldOut的递归

    Modifier.Element

    不出意外,SDK内部的各种修饰效果都将实现这一接口,同样没啥幺蛾子。

    package androidx.compose.ui

    interface Modifier {
    //...

    interface Element : Modifier {
    override fun foldIn(initial: R, operation: (R, Element) -> R): R =
    operation(initial, this)

    override fun foldOut(initial: R, operation: (Element, R) -> R): R =
    operation(this, initial)

    override fun any(predicate: (Element) -> Boolean): Boolean = predicate(this)

    override fun all(predicate: (Element) -> Boolean): Boolean = predicate(this)
    }
    }

    foldIn 和 foldOut 赏析

    这里举一个栗子来看 foldIn 和 foldOut 的递归:

    class A : Modifier.Element
    class B : Modifier.Element
    class C : Modifier.Element

    fun Modifier.a() = this.then(A())
    fun Modifier.b() = this.then(B())
    fun Modifier.c() = this.then(C())

    那么 Modifier.a().b().c() 的到的是什么呢?为了看起来直观点,我们 以 CM 代指 CombinedModifier

    CM (
    outer = CM (
    outer = A(),
    inner = B()
    ),
    inner = C()
    )

    结合前面阅读源码获得的知识,我们再假设一个operation:

    val initial = StringBuilder()
    val operation: (StringBuilder, Element) -> StringBuilder = { builder, e ->
    builder.append(e.toString()).append(";")
    builder
    }

    显然:

    Modifier.a().b().c().foldIn(initial, operation)

    所得到的执行过程为:

    val ra = operation.invoke(initial,A())
    val rb = operation.invoke(ra,B())
    return operation.invoke(rb,C())

    从链表的头部执行到链表的尾部。

    而foldOut 则相反,从链表的尾部执行到链表的头部。

    当然,真正使用时,我们不一定会一直返回 initial。 但这和Modifier没啥关系,只影响到你对哪个对象使用Modifier。

    SDK中既有的Modifier实现概览

    上文中,我们在 Modifier的源码和设计细节 上花费了很长的篇幅,相信各位读者也已经彻底理解,下面我们看点轻松的。

    很显然,下面这部分内容 混个脸熟 即可,就像在Android中的原生布局,一时间遗忘了布局属性的具体拼写也无伤大雅,借助SDK文档可以很快的查询到, 但是 不知道有这些属性 就会影响到开发了。

    三个重要的包

    • androidx.compose.foundation.layout: Modifier和布局相关的扩展
    • androidx.compose.ui.draw: Modifier和绘制相关的扩展
    • androidx.compose.foundation:Modifier的基础包,其中扩展部分主要为点击时间、背景、滑动等

    API文档的内容是很枯燥的,如果读者仅仅是打算先混个脸熟,可以泛读下文内容,如果打算仔细的结合API文档进行研究,可以Fork 我的WorkShop项目 ,将源码和效果对照起来

    foundation-layout库 -- androidx.compose.foundation.layout

    具体的API列表和描述见 Api文档

    这个包中,和布局相关,诸如:尺寸、边距、盒模型等,很显然,其中的内容非常的多。关于Modifier的内容,我们不罗列API。

    正如同 DSL 的设计初衷,对于Compose而言,了解Android原生开发的同学,或者对前端领域有一丁点了解的同学,70%的DSL-API可以一眼看出其含义, 而剩下来的部分,多半需要实际测试下效果。

    ui库 -- androidx.compose.ui.draw

    这部分大多和绘制相关,类比Android原生技术栈,部分内容是比较深入的,是 自定义时 使用的 工具,所幸这部分API不太多,我们花费一屏来罗列下, 混个脸熟。

    具体的API列表和描述见 Api文档

    • 透明度

    Modifier.alpha(alpha: Float)

    • 按形状裁切

    Modifier.clip(shape: Shape)

    • 按照指定的边界裁切内容, 类似Android中的子View内容不超过父View

    Modifier.clipToBounds()

    Clip the content to the bounds of a layer defined at this modifier.

    • 在此之后进行一次指定的绘制

    Modifier.drawBehind(onDraw: DrawScope.() -> Unit)

    Draw into a Canvas behind the modified content.

    • 基于缓存绘制, 用于尺寸未发生变化,状态未发生变化时

    Modifier.drawWithCache(onBuildDrawCache: CacheDrawScope.() -> DrawResult)

    • 人为控制在布局之前或者之后进行指定的绘制

    Modifier.drawWithContent(onDraw: ContentDrawScope.() -> Unit)

    • 利用Painter 进行绘制

    Modifier.paint(painter: Painter, sizeToIntrinsics: Boolean, alignment: Alignment, contentScale: ContentScale, alpha: Float, colorFilter: ColorFilter?)

    • 围绕中心进行旋转

    Modifier.rotate(degrees: Float)

    • 缩放

    Modifier.scale(scaleX: Float, scaleY: Float)

    • 等比缩放

    Modifier.scale(scale: Float)

    • 绘制阴影

    Modifier.shadow(elevation: Dp, shape: Shape, clip: Boolean)

    foundation库 -- androidx.compose.foundation

    所幸这部分也不太多,罗列下

    • 设置背景

    Modifier.background(color: Color, shape: Shape = RectangleShape)

    Modifier.background(brush: Brush, shape: Shape = RectangleShape, alpha: Float = 1.0f)

    Brush 是渐变的,Color是纯色的

    • 设置边界,即描边效果

    Modifier.border(border: BorderStroke, shape: Shape = RectangleShape)

    Modifier.border(width: Dp, color: Color, shape: Shape = RectangleShape)

    Modifier.border(width: Dp, brush: Brush, shape: Shape)

    • 点击效果

    Modifier.clickable(enabled: Boolean = true, onClickLabel: String? = null, role: Role? = null, onLongClickLabel: String? = null, onLongClick: () -> Unit = null, onDoubleClick: () -> Unit = null, onClick: () -> Unit)

    Modifier.clickable(enabled: Boolean = true, interactionState: InteractionState, indication: Indication?, onClickLabel: String? = null, role: Role? = null, onLongClickLabel: String? = null, onLongClick: () -> Unit = null, onDoubleClick: () -> Unit = null, onClick: () -> Unit)

    长按、单击、双击均包含在内

    • 可滑动

    Modifier.horizontalScroll(state: ScrollState, enabled: Boolean = true, reverseScrolling: Boolean = false)

    Modifier.verticalScroll(state: ScrollState, enabled: Boolean = true, reverseScrolling: Boolean = false)

    结语

    这篇博客算是正式开始学习Jetpack Compose。

    这是一个全新的内容,要真正的全面掌握还需要积累很多的知识,就如同最开始入门Android开发那样,各类控件的使用都需要学习和记忆

    但它也仅局限于:一种新的声明式、响应式UI构建框架,并不用过于畏惧,虽然有一定的上手成本,但还没有颠覆整个Android客户端的开发方式。

    另:WorkShop中的演示代码会跟随整个Compose系列的问题,我是兴致来了就更新一部分,这意味着可能会出现:有些效果博客中提到了,但WorkShop中没有写进去


    收起阅读 »

    JNI 与 NDK 入门

    JNI概念JNI是Java Native Interface的简写,它可以使Java与其他语言(如C、C++)进行交互。它是Java调用Native语言的一种特性,属于Java语言的范畴,与Android无关。为何需要JNIJava的源文件非常容易被反编译,而...
    继续阅读 »

    JNI

    概念

    JNI是Java Native Interface的简写,它可以使Java与其他语言(如C、C++)进行交互。

    它是Java调用Native语言的一种特性,属于Java语言的范畴,与Android无关。

    为何需要JNI

    • Java的源文件非常容易被反编译,而通过Native语言生成的.so库文件则不容易被反编译。
    • 有时我们使用Java时需要使用到一些库来实现功能,但这些库仅仅提供了一些Native语言的接口。
    • 使用Native语言编写的代码运行效率高,尤其体现在音频视频图片的处理等需要大量复杂运算的操作上。充分利用了硬件的性能。

    由于上述原因,此时我们就需要让Java与Native语言交互。而由于Java的特点,与Native语言的交互能力很弱。因此在此时,我们就需要用到JNI特性增强Java与Native方法的交互能力。

    实现的步骤

    1. 在Java中声明Native方法(需要调用的本地方法)
    2. 通过 javac 编译 Java源文件( 生成.class文件)
    3. 通过 javah 命令生成JNI头文件(生成.h文件)
    4. 通过Native语言实现在Java源码中声明的Native方法
    5. 编译成.so库文件
    6. 通过Java命令执行 Java程序,最终实现Java调用本地代码(借助so库文件)

    NDK

    概念

    Native是Native Development Kit的简写,是Android的开发工具包,属于Android,与Java无关系。

    它可以快速开发C/C++的动态库,自动将.so和应用一起打包为APK。因此我们可以通过NDK来在Android开发中通过JNI与Native方法交互。

    使用方式

    1. 配置 Android NDK环境(在SDK Manager中下载NDK、CMake、LLDB)
    2. 创建 Android 项目,与 NDK进行关联(创建项目时选择C++ support)
    3. 在 Android 项目中声明所需要调用的 Native方法
    4. 用Native语言实现在Android中声明的Native方法
    5. 通过 ndk-bulid 命令编译产生.so库文件

    将Android项目与NDK关联

    配置NDK路径

    local.properties中加入如下一行即可

    ndk.dir=

    添加配置

    在Gradle的 gradle.properties中加入如下一行,目的是对旧版本的NDK支持

    android.useDeprecatedNdk=true

    添加ndk节点

    在build.gradle中的defaultConfigandroid中加入如下的externalNativeBuild节点

    apply plugin: 'com.android.application'



    android {

    compileSdkVersion 27

    defaultConfig {

    applicationId "com.n0texpecterr0r.ndkdemo"

    minSdkVersion 19

    targetSdkVersion 27

    versionCode 1

    versionName "1.0"

    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

    externalNativeBuild {

    cmake {

    cppFlags ""

    }

    }

    }

    buildTypes {

    release {

    minifyEnabled false

    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

    }

    }

    externalNativeBuild {

    cmake {

    path "CMakeLists.txt"

    }

    }

    }



    dependencies {

    implementation fileTree(dir: 'libs', include: ['*.jar'])

    implementation 'com.android.support:appcompat-v7:27.1.1'

    implementation 'com.android.support.constraint:constraint-layout:1.1.3'

    testImplementation 'junit:junit:4.12'

    androidTestImplementation 'com.android.support.test1.0.2'

    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'

    }

    开发Native代码

    在Java文件中声明native方法

    我们首先需要在Java代码的类中通过static块来加载我们的Native库。可以通过如下代码,其中loadLibrary的参数是在CMakeList.txt中定义的Native库的名称

    static {

    System.loadLibrary("native-lib");

    }

    之后,我们便可以在这个类中声明Native方法

    public native String getStringFromJNI();

    创建CMakeList.txt

    我们还需要在src中创建一个CMakeList.txt文件,这个文件约束了Native语言源文件的编译规则。比如下面

    cmake_minimum_required(VERSION 3.4.1)



    add_library(native-lib SHARED src/main/cpp/native-lib.cpp)



    find_library(log-lib log)



    target_link_libraries(native-lib ${log-lib})

    add_library方法中定义了一个so库,它的名称是native-lib,也就是我们在Java文件中用到的字符串,而后面则跟着这个库对应的Native文件的路径

    find_library则是定义了一个路径变量,经过了这个方法,log-lib这个变量中的值就是Android中log库的路径

    target_link_libraries则是将native-lib这个库和log库连接了起来,这样我们就能在native-lib中使用log库的方法。

    创建Native方法文件

    在前面的CMake文件中可以看到,我们把文件放在了src/main/cpp/,因此我们创建cpp这个目录,在里面创建C++源文件native-lib.cpp。

    然后, 我们便可以开始编写如下的代码:

    #include 

    #include



    extern "C"{

    JNIEXPORT jstring JNICALL

    Java_com_n0texpecterr0r_ndkdemo_MainActivity_getStringFromJNI(

    JNIEnv* env,

    jobject) {

    std::string hello = "IG牛逼";

    return env->NewStringUTF(hello.c_str());

    }

    }

    此处我们使用的是C++语言,让我们来看看具体的代码。

    首先我们引入了jni需要的jni.h,这个头文件中声明了各个jni需要用到的函数。同时我们引入了C++中的string.h。

    然后我们看到extern "C"。为了了解这里为什么使用了extern "C",我们首先需要知道下面的知识:

    在C中,编译时的函数签名仅仅是包含了函数的名称,因此不同参数的函数都是同样的签名。这也就是为什么C不支持重载。

    而C++为了支持重载,在编译的时候函数的签名除了包含函数的名称,还携带了函数的参数及返回类型等等。

    试想此时我们有个C的函数库要给C++调用,会因为签名的不同而找不到对应的函数。因此,我们需要使用extern "C"来告诉编译器使用编译C的方式来连接。

    接下来我们看看JNIEXPORT和JNICALL关键字,这两个关键字是两个宏定义,他主要的作用就是说明该函数为JNI函数。

    而jstring则对应了Java中的String类,JNI中有很多类似jstring的类来对应Java中的类,下面是Java中的类与JNI类型的对照表

    我们继续看到函数名Java_com_n0texpecterr0r_ndkdemo_MainActivity_getStringFromJNI。其实函数名中的_相当于Java中的 . 也就是这个函数名代表了java.com.n0texpecterr0r.ndkdemo.MainActivity.java中的getStringFromJNI方法,也就是我们之前定义的native方法。

    格式大概如下:

    Java_包名_类名_需要调用的方法名

    其中,Java必须大写,包名里的.要改成__要改成_1

    接下来我们看到这个函数的两个参数:

    • JNIEnv* env:代表了JVM的环境,Native方法可以通过这个指针来调用Java代码
    • jobject obj:它就相当于定义了这个JNI方法的类 (MainActivity) 的this引用

    然后可以看到后面我们创建了一个string hello,之后通过env->NewStringUTF(hello.c_str())方法创建了一个jstring类型的变量并返回。

    在Java代码中调用native方法

    接着,我们便可以在MainActivty中像调用Java方法一样调用这个native方法

    TextView tv = findViewById(R.id.sample_text);

    tv.setText(getStringFromJNI());

    我们尝试运行,可以看到,我们成功用C++构建了一个字符串并返回给Java调用:

    image.png

    CMake

    我们在NDK开发中使用CMake的语法来编写简单的代码描述编译的过程,由于这篇文章是讲NDK的,所以关于CMake的语法就不再赘述了。。。如果想要了解CMake语法可以学习这本书《CMake Practice

    JNI与Java代码交互

    方法签名

    概念

    在我们JNI层调用一个方法时,需要传递一个参数——方法签名。

    为什么要使用方法签名呢?因为在Java中的方法是可以重载的,两个方法可能名称相同而参数不同。为了区分调用的方法,就引入了方法签名的概念。

    签名规则

    对于基本类型的参数,每个类型对应了一个不同的字母:

    • boolean Z
    • byte B
    • char C
    • short S
    • int I
    • long J
    • float F
    • double D
    • void V

    对于类,则使用 L+类名 的方式,其中(.)用(/)代替,最后加上分号

    比如 java.lang.String就是 Ljava/lang/String;

    对于数组,则在前面加 [ ,然后加类型的签名,几维数组就加几个。

    比如 int[]对应的就是[I , boolean[][]对应的则是[[Z,而java.lang.String[]就是[Ljava/lang/String;

    打印方法签名

    我们可以通过 javap -s 命令来打印方法的签名。

    例子

    比如下面的方法

    public native String getMessage();



    public native String getMessage(String id,long i);

    对应的方法签名分别为:

    ()Ljava/lang/String;

    (Ljava/long/String;J)Ljava/lang/String;

    可以看到,前面括号中表示的是方法的参数列表,后面表示的则是返回值。

    收起阅读 »

    Android自定义view之围棋动画

    Android自定义view之围棋动画好久不见,最近粉丝要求上新一篇有点难度的自定义view文章,所以它来了!!干货文,建议收藏前言废话不多说直接开始文章最后有源码完成效果图棋子加渐变色棋子不加渐变色一、测量1.获取宽高 @Override prote...
    继续阅读 »

    Android自定义view之围棋动画

    好久不见,最近粉丝要求上新一篇有点难度的自定义view文章,所以它来了!!


    干货文,建议收藏

    前言

    废话不多说直接开始


    文章最后有源码

    完成效果图

    棋子加渐变色

    在这里插入图片描述

    棋子不加渐变色

    在这里插入图片描述

    一、测量

    1.获取宽高

     @Override
    protected void onSizeChanged(int w, int h, int oldw, int oldh) {
    super.onSizeChanged(w, h, oldw, oldh);
    mWidth = w;
    mHeight = h;
    useWidth = mWidth;
    if (mWidth > mHeight) {
    useWidth = mHeight;
    }
    }

    2.定义测量最小长度

    将布局分为10份。以minwidth的1,3,5,7,9的倍数为标准点。

            minwidth = useWidth / 10;

    二、绘制背景(棋盘)

    1.初始化画笔

            mPaint = new Paint();        //创建画笔对象
    mPaint.setColor(Color.BLACK); //设置画笔颜色
    mPaint.setStyle(Paint.Style.FILL); //设置画笔模式为填充
    mPaint.setStrokeWidth(4f); //设置画笔宽度为10px
    mPaint.setAntiAlias(true); //设置抗锯齿
    mPaint.setAlpha(255); //设置画笔透明度

    2.画棋盘

            //细的X轴
    canvas.drawLine(minwidth, 3 * minwidth, 9 * minwidth, 3 * minwidth, mPaint);// 斜线
    canvas.drawLine(minwidth, 5 * minwidth, 9 * minwidth, 5 * minwidth, mPaint);// 斜线
    canvas.drawLine(minwidth, 7 * minwidth, 9 * minwidth, 7 * minwidth, mPaint);// 斜线
    //细的y轴
    canvas.drawLine(3 * minwidth, minwidth, 3 * minwidth, 9 * minwidth, mPaint);// 斜线
    canvas.drawLine(5 * minwidth, minwidth, 5 * minwidth, 9 * minwidth, mPaint);// 斜线
    canvas.drawLine(7 * minwidth, minwidth, 7 * minwidth, 9 * minwidth, mPaint);// 斜线
    mPaint.setStrokeWidth(8f);
    //粗的X轴(边框)
    canvas.drawLine(minwidth, minwidth, 9 * minwidth, minwidth, mPaint);// 斜线
    canvas.drawLine(minwidth, 9 * minwidth, 9 * minwidth, 9 * minwidth, mPaint);// 斜线
    //粗的y轴(边框)
    canvas.drawLine(minwidth, minwidth, minwidth, 9 * minwidth, mPaint);// 斜线
    canvas.drawLine(9 * minwidth, minwidth, 9 * minwidth, 9 * minwidth, mPaint);// 斜线

    绘制完后,发现有点小瑕疵

    效果图:

    在这里插入图片描述

    3.补棋盘瑕疵

            canvas.drawPoint(minwidth, minwidth, mPaint);
    canvas.drawPoint(9 * minwidth, minwidth, mPaint);
    canvas.drawPoint(minwidth, 9 * minwidth, mPaint);
    canvas.drawPoint(9 * minwidth, 9 * minwidth, mPaint);

    效果图:

    在这里插入图片描述

    三.画个不可改变的棋子(以便于了解动画移动位置)

    位置比例 (3,3)(3,5)(3,7) (5,3)(5,5)(5,7) (7,3)(7,5)(7,7)

            //画围棋
    canvas.drawCircle(3*minwidth, 3*minwidth, useWidth/16, mPaint);
    canvas.drawCircle(3*minwidth, 7*minwidth, useWidth/16, mPaint);
    canvas.drawCircle(5*minwidth, 5*minwidth, useWidth/16, mPaint);
    canvas.drawCircle(7*minwidth, 3*minwidth, useWidth/16, mPaint);
    canvas.drawCircle(7*minwidth, 7*minwidth, useWidth/16, mPaint);
    mPaint.setColor(rightcolor);
    canvas.drawCircle(3*minwidth, 5*minwidth, useWidth/16, mPaint);
    canvas.drawCircle(5*minwidth, 3*minwidth, useWidth/16, mPaint);
    canvas.drawCircle(5*minwidth, 7*minwidth, useWidth/16, mPaint);
    canvas.drawCircle(7*minwidth, 5*minwidth, useWidth/16, mPaint);

    效果图:

    在这里插入图片描述

    四.为动画开始做准备以及动画

    1.三个辅助类为动画做准备(参数模仿Android官方Demo)

    主要为get set构造,代码会贴到最后

    2.自定义该接口实例来控制动画的更新计算表达式

    public class XYEvaluator implements TypeEvaluator {
    public Object evaluate(float fraction, Object startValue, Object endValue) {
    XYHolder startXY = (XYHolder) startValue;
    XYHolder endXY = (XYHolder) endValue;
    return new XYHolder(startXY.getX() + fraction * (endXY.getX() - startXY.getX()),
    startXY.getY() + fraction * (endXY.getY() - startXY.getY()));
    }
    }

    3.棋子的创建

        private ShapeHolder createBall(float x, float y, int color) {
    OvalShape circle = new OvalShape();
    circle.resize(useWidth / 8f, useWidth / 8f);
    ShapeDrawable drawable = new ShapeDrawable(circle);
    ShapeHolder shapeHolder = new ShapeHolder(drawable);
    shapeHolder.setX(x - useWidth / 16f);
    shapeHolder.setY(y - useWidth / 16f);
    Paint paint = drawable.getPaint();
    paint.setColor(color);
    return shapeHolder;
    }

    4.动画的创建

        private void createAnimation() {
    if (bounceAnim == null) {
    XYHolder lstartXY = new XYHolder(3 * minwidth - useWidth / 16f, 3 * minwidth - useWidth / 16f);
    XYHolder processXY = new XYHolder(7 * minwidth - useWidth / 16f, 3 * minwidth - useWidth / 16f);
    XYHolder lendXY = new XYHolder(7 * minwidth - useWidth / 16f, 7 * minwidth - useWidth / 16f);
    bounceAnim = ObjectAnimator.ofObject(ballHolder, "xY",
    new XYEvaluator(), lstartXY, processXY, lendXY, lstartXY);
    bounceAnim.setDuration(animaltime);
    bounceAnim.setRepeatCount(ObjectAnimator.INFINITE);
    bounceAnim.setRepeatMode(ObjectAnimator.RESTART);
    bounceAnim.addUpdateListener(this);
    }
    if (bounceAnim1 == null) {
    XYHolder lstartXY = new XYHolder(7 * minwidth - useWidth / 16f, 7 * minwidth - useWidth / 16f);
    XYHolder processXY = new XYHolder(3 * minwidth - useWidth / 16f, 7 * minwidth - useWidth / 16f);
    XYHolder lendXY = new XYHolder(3 * minwidth - useWidth / 16f, 3 * minwidth - useWidth / 16f);
    bounceAnim1 = ObjectAnimator.ofObject(ballHolder1, "xY",
    new XYEvaluator(), lstartXY, processXY, lendXY, lstartXY);
    bounceAnim1.setDuration(animaltime);
    bounceAnim1.setRepeatCount(ObjectAnimator.INFINITE);
    bounceAnim1.setRepeatMode(ObjectAnimator.RESTART);
    bounceAnim1.addUpdateListener(this);
    }
    }

    5.两个动画的同步执行

            AnimatorSet animatorSet = new AnimatorSet();
    animatorSet.play(bounceAnim).with(bounceAnim1);
    animatorSet.start();

    6.效果图

    在这里插入图片描述

    视觉效果:感觉白子不太明显

    7.解决第6步问题

    在棋子的创建方法中添加渐变色

            RadialGradient gradient = new RadialGradient(useWidth / 16f, useWidth / 16f,
    useWidth / 8f, color, Color.GRAY, Shader.TileMode.CLAMP);
    paint.setShader(gradient);
    shapeHolder.setPaint(paint);

    效果图:

    在这里插入图片描述

    五.自定义属性

    attrs文件:

        <declare-styleable name="WeiqiView">
    <!-- 黑子颜色-->
    <attr name="leftscolor" format="reference|color"/>
    <!-- 白子颜色-->
    <attr name="rightscolor" format="reference|color"/>
    <!-- 棋盘颜色-->
    <attr name="qipancolor" format="reference|color"/>
    <!-- 动画时间-->
    <attr name="animalstime" format="integer"/>
    </declare-styleable>

    java文件中获取

        /**
    * 获取自定义属性
    */

    private void initCustomAttrs(Context context, AttributeSet attrs) {
    //获取自定义属性
    TypedArray ta = context.obtainStyledAttributes(attrs, R.styleable.WeiqiView);
    //获取颜色
    leftcolor = ta.getColor(R.styleable.WeiqiView_leftscolor, Color.BLACK);
    rightcolor = ta.getColor(R.styleable.WeiqiView_rightscolor, Color.WHITE);
    qipancolor = ta.getColor(R.styleable.WeiqiView_qipancolor, Color.BLACK);
    //获取动画时间
    animaltime = ta.getInt(R.styleable.WeiqiView_animalstime, 2000);
    //回收
    ta.recycle();

    }

    六.自定义属性设置后运行效果

    在这里插入图片描述

    七.小改变,视觉效果就不一样了!

    然后,把背景注释,像不像那些等待动画?

    在这里插入图片描述

    八.源码

    WeiqiView.java

    public class WeiqiView extends View implements ValueAnimator.AnimatorUpdateListener {
    private Paint mPaint;
    private int mWidth;
    private int mHeight;
    private int useWidth, minwidth;
    private int leftcolor;
    private int rightcolor;
    private int qipancolor;
    private int animaltime;
    //画一个圆(棋子)
    ValueAnimator bounceAnim, bounceAnim1 = null;
    ShapeHolder ball, ball1 = null;
    QiziXYHolder ballHolder, ballHolder1 = null;

    @RequiresApi(api = Build.VERSION_CODES.LOLLIPOP)
    public WeiqiView(Context context) {
    this(context, null);
    }

    @RequiresApi(api = Build.VERSION_CODES.LOLLIPOP)
    public WeiqiView(Context context, @Nullable AttributeSet attrs) {
    this(context, attrs, 0);
    }

    @RequiresApi(api = Build.VERSION_CODES.LOLLIPOP)
    public WeiqiView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
    this(context, attrs, defStyleAttr, 0);
    initCustomAttrs(context, attrs);
    }

    @RequiresApi(api = Build.VERSION_CODES.LOLLIPOP)
    public WeiqiView(Context context, @Nullable AttributeSet attrs, int defStyleAttr, int defStyleRes) {
    super(context, attrs, defStyleAttr, defStyleRes);


    }

    private void init() {
    initPaint();
    }


    /**
    * 获取自定义属性
    */

    private void initCustomAttrs(Context context, AttributeSet attrs) {
    //获取自定义属性。
    TypedArray ta = context.obtainStyledAttributes(attrs, R.styleable.WeiqiView);
    //获取颜色
    leftcolor = ta.getColor(R.styleable.WeiqiView_leftscolor, Color.BLACK);
    rightcolor = ta.getColor(R.styleable.WeiqiView_rightscolor, Color.WHITE);
    qipancolor = ta.getColor(R.styleable.WeiqiView_qipancolor, Color.BLACK);
    animaltime = ta.getInt(R.styleable.WeiqiView_animalstime, 2000);
    //回收
    ta.recycle();

    }

    /**
    * 初始化画笔
    */

    private void initPaint() {
    mPaint = new Paint(); //创建画笔对象
    mPaint.setColor(Color.BLACK); //设置画笔颜色
    mPaint.setStyle(Paint.Style.FILL); //设置画笔模式为填充
    mPaint.setStrokeWidth(4f); //设置画笔宽度为10px
    mPaint.setAntiAlias(true); //设置抗锯齿
    mPaint.setAlpha(255); //设置画笔透明度
    }

    @Override
    protected void onSizeChanged(int w, int h, int oldw, int oldh) {
    super.onSizeChanged(w, h, oldw, oldh);
    mWidth = w;
    mHeight = h;
    useWidth = mWidth;
    if (mWidth > mHeight) {
    useWidth = mHeight;
    }
    }


    @RequiresApi(api = Build.VERSION_CODES.KITKAT)
    @Override
    protected void onDraw(Canvas canvas) {
    super.onDraw(canvas);
    init();
    minwidth = useWidth / 10;
    mPaint.setColor(qipancolor);
    if (ball == null) {
    ball = createBall(3 * minwidth, 3 * minwidth, leftcolor);
    ballHolder = new QiziXYHolder(ball);
    }
    if (ball1 == null) {
    ball1 = createBall(7 * minwidth, 7 * minwidth, rightcolor);
    ballHolder1 = new QiziXYHolder(ball1);
    }
    //细的X轴
    canvas.drawLine(minwidth, 3 * minwidth, 9 * minwidth, 3 * minwidth, mPaint);// 斜线
    canvas.drawLine(minwidth, 5 * minwidth, 9 * minwidth, 5 * minwidth, mPaint);// 斜线
    canvas.drawLine(minwidth, 7 * minwidth, 9 * minwidth, 7 * minwidth, mPaint);// 斜线
    //细的y轴
    canvas.drawLine(3 * minwidth, minwidth, 3 * minwidth, 9 * minwidth, mPaint);// 斜线
    canvas.drawLine(5 * minwidth, minwidth, 5 * minwidth, 9 * minwidth, mPaint);// 斜线
    canvas.drawLine(7 * minwidth, minwidth, 7 * minwidth, 9 * minwidth, mPaint);// 斜线
    mPaint.setStrokeWidth(8f);
    //粗的X轴(边框)
    canvas.drawLine(minwidth, minwidth, 9 * minwidth, minwidth, mPaint);// 斜线
    canvas.drawLine(minwidth, 9 * minwidth, 9 * minwidth, 9 * minwidth, mPaint);// 斜线
    //粗的y轴(边框)
    canvas.drawLine(minwidth, minwidth, minwidth, 9 * minwidth, mPaint);// 斜线
    canvas.drawLine(9 * minwidth, minwidth, 9 * minwidth, 9 * minwidth, mPaint);// 斜线
    //补瑕疵
    canvas.drawPoint(minwidth, minwidth, mPaint);
    canvas.drawPoint(9 * minwidth, minwidth, mPaint);
    canvas.drawPoint(minwidth, 9 * minwidth, mPaint);
    canvas.drawPoint(9 * minwidth, 9 * minwidth, mPaint);
    // //画围棋
    // canvas.drawCircle(3*minwidth, 3*minwidth, useWidth/16, mPaint);
    // canvas.drawCircle(3*minwidth, 7*minwidth, useWidth/16, mPaint);
    // canvas.drawCircle(5*minwidth, 5*minwidth, useWidth/16, mPaint);
    // canvas.drawCircle(7*minwidth, 3*minwidth, useWidth/16, mPaint);
    // canvas.drawCircle(7*minwidth, 7*minwidth, useWidth/16, mPaint);
    // mPaint.setColor(rightcolor);
    // canvas.drawCircle(3*minwidth, 5*minwidth, useWidth/16, mPaint);
    // canvas.drawCircle(5*minwidth, 3*minwidth, useWidth/16, mPaint);
    // canvas.drawCircle(5*minwidth, 7*minwidth, useWidth/16, mPaint);
    // canvas.drawCircle(7*minwidth, 5*minwidth, useWidth/16, mPaint);

    canvas.save();
    canvas.translate(ball.getX(), ball.getY());
    ball.getShape().draw(canvas);
    canvas.restore();

    canvas.save();
    canvas.translate(ball1.getX(), ball1.getY());
    ball1.getShape().draw(canvas);
    canvas.restore();
    }

    private ShapeHolder createBall(float x, float y, int color) {
    OvalShape circle = new OvalShape();
    circle.resize(useWidth / 8f, useWidth / 8f);
    ShapeDrawable drawable = new ShapeDrawable(circle);
    ShapeHolder shapeHolder = new ShapeHolder(drawable);
    shapeHolder.setX(x - useWidth / 16f);
    shapeHolder.setY(y - useWidth / 16f);
    Paint paint = drawable.getPaint();
    paint.setColor(color);
    RadialGradient gradient = new RadialGradient(useWidth / 16f, useWidth / 16f,
    useWidth / 8f, color, Color.GRAY, Shader.TileMode.CLAMP);
    paint.setShader(gradient);
    shapeHolder.setPaint(paint);
    return shapeHolder;
    }

    private void createAnimation() {
    if (bounceAnim == null) {
    XYHolder lstartXY = new XYHolder(3 * minwidth - useWidth / 16f, 3 * minwidth - useWidth / 16f);
    XYHolder processXY = new XYHolder(7 * minwidth - useWidth / 16f, 3 * minwidth - useWidth / 16f);
    XYHolder lendXY = new XYHolder(7 * minwidth - useWidth / 16f, 7 * minwidth - useWidth / 16f);
    bounceAnim = ObjectAnimator.ofObject(ballHolder, "xY",
    new XYEvaluator(), lstartXY, processXY, lendXY, lstartXY);
    bounceAnim.setDuration(animaltime);
    bounceAnim.setRepeatCount(ObjectAnimator.INFINITE);
    bounceAnim.setRepeatMode(ObjectAnimator.RESTART);
    bounceAnim.addUpdateListener(this);
    }
    if (bounceAnim1 == null) {
    XYHolder lstartXY = new XYHolder(7 * minwidth - useWidth / 16f, 7 * minwidth - useWidth / 16f);
    XYHolder processXY = new XYHolder(3 * minwidth - useWidth / 16f, 7 * minwidth - useWidth / 16f);
    XYHolder lendXY = new XYHolder(3 * minwidth - useWidth / 16f, 3 * minwidth - useWidth / 16f);
    bounceAnim1 = ObjectAnimator.ofObject(ballHolder1, "xY",
    new XYEvaluator(), lstartXY, processXY, lendXY, lstartXY);
    bounceAnim1.setDuration(animaltime);
    bounceAnim1.setRepeatCount(ObjectAnimator.INFINITE);
    bounceAnim1.setRepeatMode(ObjectAnimator.RESTART);
    bounceAnim1.addUpdateListener(this);
    }
    }

    public void startAnimation() {
    createAnimation();
    AnimatorSet animatorSet = new AnimatorSet();
    animatorSet.play(bounceAnim).with(bounceAnim1);
    animatorSet.start();
    }

    @Override
    public void onAnimationUpdate(ValueAnimator animation) {
    invalidate();
    }
    }

    QiziXYHolder.java

    public class QiziXYHolder {

    private ShapeHolder mBall;

    public QiziXYHolder(ShapeHolder ball) {
    mBall = ball;
    }

    public void setXY(XYHolder xyHolder) {
    mBall.setX(xyHolder.getX());
    mBall.setY(xyHolder.getY());
    }

    public XYHolder getXY() {
    return new XYHolder(mBall.getX(), mBall.getY());
    }
    }

    ShapeHolder.java

    public class ShapeHolder {
    private float x = 0, y = 0;
    private ShapeDrawable shape;
    private int color;
    private RadialGradient gradient;
    private float alpha = 1f;
    private Paint paint;

    public void setPaint(Paint value) {
    paint = value;
    }
    public Paint getPaint() {
    return paint;
    }

    public void setX(float value) {
    x = value;
    }
    public float getX() {
    return x;
    }
    public void setY(float value) {
    y = value;
    }
    public float getY() {
    return y;
    }
    public void setShape(ShapeDrawable value) {
    shape = value;
    }
    public ShapeDrawable getShape() {
    return shape;
    }
    public int getColor() {
    return color;
    }
    public void setColor(int value) {
    shape.getPaint().setColor(value);
    color = value;
    }
    public void setGradient(RadialGradient value) {
    gradient = value;
    }
    public RadialGradient getGradient() {
    return gradient;
    }

    public void setAlpha(float alpha) {
    this.alpha = alpha;
    shape.setAlpha((int)((alpha * 255f) + .5f));
    }

    public float getWidth() {
    return shape.getShape().getWidth();
    }
    public void setWidth(float width) {
    Shape s = shape.getShape();
    s.resize(width, s.getHeight());
    }

    public float getHeight() {
    return shape.getShape().getHeight();
    }
    public void setHeight(float height) {
    Shape s = shape.getShape();
    s.resize(s.getWidth(), height);
    }

    public ShapeHolder(ShapeDrawable s) {
    shape = s;
    }
    }

    XYEvaluator.java

    public class XYEvaluator implements TypeEvaluator {
    public Object evaluate(float fraction, Object startValue, Object endValue) {
    XYHolder startXY = (XYHolder) startValue;
    XYHolder endXY = (XYHolder) endValue;
    return new XYHolder(startXY.getX() + fraction * (endXY.getX() - startXY.getX()),
    startXY.getY() + fraction * (endXY.getY() - startXY.getY()));
    }
    }

    XYHolder.java

    public class XYHolder {
    private float mX;
    private float mY;

    public XYHolder(float x, float y) {
    mX = x;
    mY = y;
    }

    public float getX() {
    return mX;
    }

    public void setX(float x) {
    mX = x;
    }

    public float getY() {
    return mY;
    }

    public void setY(float y) {
    mY = y;
    }
    }

    attrs.xml

    <resources>
    <declare-styleable name="WeiqiView">
    <!-- 黑子颜色-->
    <attr name="leftscolor" format="reference|color"/>
    <!-- 白子颜色-->
    <attr name="rightscolor" format="reference|color"/>
    <!-- 棋盘颜色-->
    <attr name="qipancolor" format="reference|color"/>
    <!-- 动画时间-->
    <attr name="animalstime" format="integer"/>
    </declare-styleable>
    </resources>

    布局调用

    <com.shenzhen.jimeng.lookui.UI.WeiqiView
    android:layout_centerInParent="true"
    android:id="@+id/weiqi"
    android:layout_width="400dp"
    android:layout_height="400dp"/>

    activity文件中开启动画

         weiqi = (WeiqiView) findViewById(R.id.weiqi);
    weiqi.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
    weiqi.startAnimation();
    }
    });

    收起阅读 »

    Handler 源码分析

    Handler源码的学习理解一.相关类说明1.Handler作用①实现线程切换,可以在A个线程使用B线程创建的Handler发送消息,然后在B线程的Handler handleMessage回调中接收A线程的消息。②实现发送延时消息 hanlder.postD...
    继续阅读 »

    Handler源码的学习理解

    一.相关类说明

    1.Handler作用

    ①实现线程切换,可以在A个线程使用B线程创建的Handler发送消息,然后在B线程的Handler handleMessage回调中接收A线程的消息。

    ②实现发送延时消息 hanlder.postDelay(),sendMessageDelayed()

    2.Message

    消息的载体,包含发送的handler对象等信息,Message本身是一个单链表结构,里面维护了next Message对象;内部维护了一个Message Pool,使用时调用Message.obtain()方法来从Message 池子中获取对象,可以让我们在许多情况下避免new对象,减少内存开,Message种类有普通message,异步Message,同步屏障Message。

    3.MessageQueue

    MessageQueue:一个优先级队列,内部是一个按Message.when从小到大排列的Message单链表;可以通过enqueueMessage()添加Message,通过next()取出Message,但是必须配合Handler与Looper来实现这个过程。

    4.Looper

    通过Looper.prepare()去创建一个Looper,调用Looper.loop()去不断轮询MessageQueue队列,调用MessageQueue 的next()方法直到取出Msg,然后回调msg.target.dispatchMessage(msg);实现消息的取出与分发。

    二.原理分析

    我们在MainActivity的成员变量初始化一个Handler,然后子线程通过handler post/send msg发送一个消息 ,最后我们在主线程的Handler回调handleMessage(msg: Message)拿到我们的消息。理解了这个从发送到接收的过程,Handler原理就掌握的差不多了。下面来分析这个过程:

    1.发送消息

    handler post/send msg 对象到 MessageQueue ,无论调用Handler哪个发送方法,最后都会调用到Handler.enqueueMessage()方法:

     private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,long uptimeMillis) {
    //handler enqueneMessage 将handler赋值给msg.target,为了区分消息队列的消息属于哪个handler发送的
    msg.target = this;
    msg.workSourceUid = ThreadLocalWorkSource.getUid();

    if (mAsynchronous) {
    msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
    }
    复制代码

    然后再去调用MessageQueue.enqueueMessage(),将Message按照message 的when参数的从小到大的顺序插入到MessageQueue中.MessageQueue是一个优先级队列,内部是以单链表的形式存储Message的。这样我们完成了消息发送到MessageQueue的步骤。

    boolean enqueueMessage(Message msg, long when) {
    //、、、、、、
    msg.markInUse();
    msg.when = when;
    Message p = mMessages;
    boolean needWake;
    if (p == null || when == 0 || when < p.when) {
    //when == 0 就是直接发送的消息 将msg插到队列的头部
    // New head, wake up the event queue if blocked.
    msg.next = p;
    mMessages = msg;
    needWake = mBlocked;
    } else {
    // Inserted within the middle of the queue. Usually we don't have to wake
    // up the event queue unless there is a barrier at the head of the queue
    // and the message is the earliest asynchronous message in the queue.
    needWake = mBlocked && p.target == null && msg.isAsynchronous();
    Message prev;
    for (;;) {
    prev = p;
    p = p.next;
    //准备插入的msg.when 时间小于队列中某个消息的when 就跳出循环
    if (p == null || when < p.when) {
    break;
    }
    if (needWake && p.isAsynchronous()) {
    needWake = false;
    }
    }
    //插入msg 到队列中这个消息的前面
    msg.next = p; // invariant: p == prev.next
    prev.next = msg;
    }

    // We can assume mPtr != 0 because mQuitting is false.
    if (needWake) {
    nativeWake(mPtr);
    }
    }
    return true;
    }
    复制代码

    2.取出消息

    我们知道消息队列MessageQueue是死的,它不会自己去取出某个消息的。所以我们需要一个让MessageQueue动起来的动力--Looper.首先创建一个Looper,代码如下:

     //Looper.java    
    // sThreadLocal.get() will return null unless you've called prepare().
    @UnsupportedAppUsage
    static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
    private static void prepare(boolean quitAllowed) {
    //sThreadLocal.get() 得到Looper 不为null
    if (sThreadLocal.get() != null) {
    throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
    }

    //ThreadLocal.java
    public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
    //将thread本身最为key, looper为value存在ThreadLocalMap中
    map.set(this, value);
    else
    createMap(t, value);
    }
    复制代码

    从源码可以看出,一个线程只能存在一个Looper,接着来看looper.loop()方法,主要做了取message的工作:

    //looper.java  
    /**
    * Run the message queue in this thread. Be sure to call
    * {@link #quit()} to end the loop.
    */

    public static void loop() {
    final Looper me = myLooper();
    if (me == null) {
    throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue;
    //..............
    //死循环取出message
    for (;;) {
    Message msg = queue.next(); // might block 调用MessageQueue的next()方法取出消息,可能发生阻塞
    if (msg == null) {//msg == null 代表message queue 正在退出,一般不会为null
    // No message indicates that the message queue is quitting.
    return;
    }
    //...............
    try {//取出消息后,分发给对应的 msg.target 也就是handler
    msg.target.dispatchMessage(msg);
    // 、、、、、
    } catch (Exception exception) {
    // 、、、、、
    } finally {
    // 、、、、、
    }
    // 、、、、、重置属性并回收message到复用池
    msg.recycleUnchecked();
    }
    }
    //Message.java
    void recycleUnchecked() {
    // Mark the message as in use while it remains in the recycled object pool.
    // Clear out all other details.
    flags = FLAG_IN_USE;
    what = 0;
    arg1 = 0;
    arg2 = 0;
    obj = null;
    replyTo = null;
    sendingUid = UID_NONE;
    workSourceUid = UID_NONE;
    when = 0;
    target = null;
    callback = null;
    data = null;
    synchronized (sPoolSync) {
    if (sPoolSize < MAX_POOL_SIZE) {
    next = sPool;
    sPool = this;
    sPoolSize++;
    }
    }
    }
    复制代码

    3.MessageQueue的next()方法

    不断的从消息队列里拿消息,如果有异步消息,先所有的异步消息放在队列的前面优先执行,然后,拿到同步消息,分发给对应的handler,在MessageQueue中没有消息要执行时即MessageQueue空闲时,如果有idelHandler则会去执行idelHandler 的任务,通过idler.queueIdle()处理任务.

      //MessageQueue.java
    Message next() {
    //........
    int nextPollTimeoutMillis = 0;
    for (;;) {
    if (nextPollTimeoutMillis != 0) {
    Binder.flushPendingCommands();
    }
    //没消息时,主线程睡眠
    nativePollOnce(ptr, nextPollTimeoutMillis);

    synchronized (this) {
    // Try to retrieve the next message. Return if found.
    final long now = SystemClock.uptimeMillis();
    Message prevMsg = null;
    Message msg = mMessages;//mMessages保存链表的第一个元素
    if (msg != null && msg.target == null) {//当有屏障消息时,就去寻找最近的下一个异步消息

    // msg.target == null 时为屏障消息(参考MessageQueue.java 的postSyncBarrier()),找到寻找下一个异步消息
    // Stalled by a barrier. Find the next asynchronous message in the queue.
    do {
    prevMsg = msg;//记录prevMsg为异步消息的前一个同步消息

    msg = msg.next;//遍历下一个节点

    } while (msg != null && !msg.isAsynchronous());//当是同步消息时,执行循环,直到找到异步消息跳出循环


    }
    if (msg != null) {//消息处理
    if (now < msg.when) {
    // Next message is not ready. Set a timeout to wake up when it is ready.
    //下一条消息还没到执行时间,先睡眠一会儿
    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
    } else {
    // Got a message.
    mBlocked = false;
    if (prevMsg != null) {//有屏障消息
    prevMsg.next = msg.next;//这个步骤保证了原来的同步消息的顺序 将异步消息前的同步消息放在异步消息后的同步消息之前执行,优先执行了异步消息

    } else {//无屏障消息直接取出这个消息,并重置MessageQueue队列的头
    mMessages = msg.next;
    }
    msg.next = null;
    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
    msg.markInUse();
    //返回队列的一个message
    return msg;
    }
    } else {
    // No more messages.
    //没消息就睡眠
    nextPollTimeoutMillis = -1;
    }

    // Process the quit message now that all pending messages have been handled.
    if (mQuitting) {
    dispose();
    return null;
    }

    // If first time idle, then get the number of idlers to run.
    // Idle handles only run if the queue is empty or if the first message
    // in the queue (possibly a barrier) is due to be handled in the future.
    if (pendingIdleHandlerCount < 0
    && (mMessages == null || now < mMessages.when)) {
    //当消息对列没有要执行的message时,去赋值pendingIdleHandlerCount
    pendingIdleHandlerCount = mIdleHandlers.size();
    }
    if (pendingIdleHandlerCount <= 0) {
    // No idle handlers to run. Loop and wait some more.
    mBlocked = true;
    continue;
    }

    if (mPendingIdleHandlers == null) {
    //创建 IdleHandler[]
    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
    }
    mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
    }

    // Run the idle handlers.
    // We only ever reach this code block during the first iteration.
    for (int i = 0; i < pendingIdleHandlerCount; i++) {
    final IdleHandler idler = mPendingIdleHandlers[i];
    mPendingIdleHandlers[i] = null; // release the reference to the handler

    boolean keep = false;
    try {
    //执行IdleHandle[]的每个queueIdle(),Return true to keep your idle handler active
    keep = idler.queueIdle();
    } catch (Throwable t) {
    Log.wtf(TAG, "IdleHandler threw exception", t);
    }

    if (!keep) {//mIdleHandlers 被删除了
    synchronized (this) {
    mIdleHandlers.remove(idler);
    }
    }
    }

    // Reset the idle handler count to 0 so we do not run them again.
    pendingIdleHandlerCount = 0;

    // While calling an idle handler, a new message could have been delivered
    // so go back and look again for a pending message without waiting.
    nextPollTimeoutMillis = 0;
    }
    }
    复制代码

    三.常见问题

    通过以上源码的分析,了解到Handler的工作原理,根据原理可回答出一下几个经典题目:

    1.一个线程有几个handler?

    可以有多个handler,因为可以在一个线程 new多个handler ,并且handler 发送message时,会将handler 赋值给message.target

    2.一个线程有几个looper?如何保证?

    只能有一个,否则会抛异常

    3.Handler内存泄漏原因?为什么其他的内部类没有说过这个问题?

    Handler内存泄漏的根本原因时在于延时消息,因为Handler 发送一个延时消息到MessageQueue,MessageQueue中持有的Message中持有Handler的引用,而Handler作为Activity的内部类持有Activity的引用,所以当Activity销毁时因MessageQueue的Message无法释放,会导致Activity无法释放,造成内存泄漏

    4.为何主线程可以new Handler?如果想在子线程中new Handler要做哪些准备?

    因为APP启动后ActivityThread会帮我们自动创建Looper。如果想在子线程中new Handler要做调用Looper.prepare(),Looper.loop()方法

    //ActivityThread.java    
    public static void main(String[] args) {


    Looper.prepareMainLooper();
    //............
    Looper.loop();

    throw new RuntimeException("Main thread loop unexpectedly exited");
    }
    复制代码

    5.子线程维护的Looper,消息队列无消息时,处理方案是什么?有什么用?

    子线程中new Handler要做调用Looper.prepare(),Looper.loop()方法,并在结束时手动调用Looper.quit(),LooperquitSafely()方法来终止Looper,否则子线程会一直卡死在这个阻塞状态不能停止

    6.既然可以存在多个Handler往MessageQueue中添加数据(发消息时各个Handler可以能处于不同线程),那他内部如何保证线程安全的?

     boolean enqueueMessage(Message msg, long when) {
    //..............通过synchronized保证线程安全
    synchronized (this) {
    if (mQuitting) {
    IllegalStateException e = new IllegalStateException(
    msg.target + " sending message to a Handler on a dead thread");
    Log.w(TAG, e.getMessage(), e);
    msg.recycle();
    return false;
    }
    //..............
    }
    复制代码

    7.我们使用Message时应该如何创建它?

    Message.obtain()

    8.使用Handler的postDelay后消息队列会有什么变化?

    按照Message.when 插入message

    9.Looper死循环为啥不会导致应用卡死

    Looper死循环,没消息会进行休眠不会卡死调用linux底层的epoll机制实现;应用卡死时是ANR导致的;两者是不一样的概念

    ANR:用户输入事件或者触摸屏幕5S没响应或者广播在10S内未执行完毕,Service的各个生命周期函数在特定时间(20秒)内无法完成处理

    收起阅读 »

    JAVA面向对象之抽象类

    文章目录抽象类的概念举例1:绘制图形项目修改举例2:员工类抽象类的概念抽象类的基本概念1、很多具有相同特征和行为的对象可以抽象为一个类;很多具有相同特征和行为的类可以抽象为一个抽象类。2、使用abstract关键字声明的类为抽象类抽象类作用1、为子类提供通用代...
    继续阅读 »

    文章目录

    抽象类的概念

    抽象类的基本概念
    1、很多具有相同特征和行为的对象可以抽象为一个类;很多具有相同特征和行为的类可以抽象为一个抽象类。
    2、使用abstract关键字声明的类为抽象类

    抽象类作用
    1、为子类提供通用代码
    2、为子类提供通用方法的定义
    子类向上转型之后可以调用父类的这个通用方法(当然执行的时候是执行子类的方法),如果不定义这个抽象方法(所谓的抽象方法理解起来非常简单,就是没有完成的方法),只能向下转型成子类再调用子类中方法

    抽象类的规则
    a、抽象类可以没有抽象方法,有抽象方法的类必须是抽象类
    b、非抽象类继承抽象类必须实现所有抽象方法
    c、抽象类可以继承抽象类,可以不实现父类抽象方法。
    d、抽象类可以有方法实现和属性
    e、抽象类不能被实例化
    f、抽象类不能声明为final
    g、抽象类可以有构造方法

    举例1:绘制图形项目修改

    这个例子是根据上一章的绘制图形项目进行的修改,传送门:【达内课程】面向对象之多态

    前情回顾:

    我们有图形类 Shape(图形),它的子类有 Line(线)、Circle(圆)、Square(方)

    Shape:draw(画图)、clean(清除)
    |-Line:有自己的 draw 方法。有单独的 length 方法
    |-Circle:有自己的 draw 方法 |-Square:有自己的 draw 方法

    Shape类修改

    public abstract class Shape {
    public abstract void draw(TextView view);

    public void clean(TextView view) {
    view.setText("");
    }
    }

    其中继承 Shape 类 Circle、Line、Square 都不能使用 super.draw(view);了,所以应该在代码中去掉,例如 Circle 类:

    public class Circle extends Shape {
    @Override
    public void draw(TextView view) {
    //super.draw(view);
    view.setText("o");
    }
    }

    修改 MainActivity 中的 doClick 方法,其余点击事件都没有变,只不过由于抽象类不能创建实例,所以修改了 button1 的点击事件

    public void doClick(View view) {
    switch (view.getId()) {
    case R.id.button1:
    //f(new Shape());
    textView.setText("抽象类不能创建实例");
    break;
    case R.id.button2:
    f(new Line());
    break;
    ......
    }
    }

    运行结果:
    在这里插入图片描述
    这里重点看下 f(Shape shape) 方法,重点都写在注释里了:

    private void f(Shape shape) {
    //参数对象,保存到成员变量
    currentShape = shape;
    //调用抽象方法
    //执行的是子类实现的draw方法
    shape.draw(textView);
    //向上转型后只能访问父类定义的通用成员
    //不能访问子类特有成员
    //shape.length();
    if (shape instanceof Line) {
    Line line = (Line) shape;
    line.length(textView);
    }
    }

    举例2:员工类

    我们有一个抽象的员工类 Employee,抽象方法有 工资(gongzi())、奖金(jiangjin())。还有一个返回综合工资的方法(zonghe()

    程序员类 Programmer、经理类 Manager 继承了这个抽象方法

    Employee
    |-Programmer
    |-Manager

    Employee

    public abstract class Employee {
    public abstract double gongzi();

    public abstract double jiangjin();

    public double zonghe() {
    //抽象方法调用
    //执行具体子类中实现的方法
    return gongzi() + jiangjin();
    }
    }

    Programmer

    public class Programmer extends Employee {
    @Override
    public double gongzi() {
    return 8000;
    }

    @Override
    public double jiangjin() {
    return 1000;
    }
    }

    Manager

    public class Manager extends Employee {
    @Override
    public double gongzi() {
    return 10000;
    }

    @Override
    public double jiangjin() {
    return 3000;
    }
    }

    xml

    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">


    <Button
    android:id="@+id/button1"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="Employee" />


    <Button
    android:id="@+id/button2"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="Programmer" />


    <Button
    android:id="@+id/button3"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="Manager" />


    <TextView
    android:id="@+id/text"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:textColor="#222222"
    android:textSize="20sp"
    android:gravity="center" />

    </LinearLayout>

    MainActivity

    package com.example.testapplication;

    import android.os.Bundle;
    import android.view.View;
    import android.widget.Button;
    import android.widget.TextView;

    import androidx.appcompat.app.AppCompatActivity;

    public class MainActivity extends AppCompatActivity {
    Button button1;
    Button button2;
    Button button3;

    TextView textView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    textView = (TextView) findViewById(R.id.text);
    button1 = (Button) findViewById(R.id.button1);
    button2 = (Button) findViewById(R.id.button2);
    button3 = (Button) findViewById(R.id.button3);

    }

    public void doClick(View view) {
    switch (view.getId()) {
    case R.id.button1:
    textView.setText("抽象类不能创建实例");
    break;
    case R.id.button2:
    f(new Programmer());
    break;
    case R.id.button3:
    f(new Manager());
    break;
    }
    }

    private void f(Employee employee) {
    textView.setText("");
    textView.append(employee.gongzi() + "\n");
    textView.append(employee.jiangjin() + "\n");
    textView.append(employee.zonghe() + "\n");
    }
    }
    收起阅读 »

    【Flutter 组件集录】FadeInImage

    一、认识 FadeInImage 组件 我们都知道,图片无论是从资源、文件、网络加载,都不会立刻完成,这样会出现短暂的空白,尤其是网络图片。自己处理默认占位图也比较麻烦。FadeInImage 的作用就是:在目标图片加载完成前使用默认图片占位,加载完成后,目...
    继续阅读 »
    一、认识 FadeInImage 组件

    我们都知道,图片无论是从资源、文件、网络加载,都不会立刻完成,这样会出现短暂的空白,尤其是网络图片。自己处理默认占位图也比较麻烦。FadeInImage 的作用就是:在目标图片加载完成前使用默认图片占位,加载完成后,目标图片会渐变淡入,默认图片会渐变淡出,这样可以既解决图片加载占位问题,渐变的动画在视觉上也不显突兀。本文,就来全面介绍一下 FadeInImage 组件的使用以及简单的源码实现。




    1. FadeInImage 基本信息

    首先,它是一个 StatelessWidget,就说明它本身不会维护复杂的状态类,只是在 build 方法中负责组件的构建。



    在普通构造中,必须传入两个 ImageProvider 对象,image 表示待加载的目标图片资源,placeholder 表示目标图片加载过程中显示的占位图片资源。另外还有很多用于配置图片和动画的属性,后面再一一介绍。


    final ImageProvider placeholder;
    final ImageProvider image;



    2.FadeInImage 的简单使用

    只有知道两个图片资源就能最简单地使用 FadeInImage,另外可以通过 widthheight 限制图片的大小。下面头像是使用网络图片,黑色的是占位图,效果如下:






































    属性名 类型 默认值 用途
    placeholder ImageProvider required 占位图片资源
    image ImageProvider required 目标图片资源
    width double null 图片宽
    height double null 图片高

    class FadeInImageDemo extends StatelessWidget{
    final headUrl =
    'https://sf1-ttcdn-tos.pstatp.com/img/user-avatar/5b2b7b85d1c818fa71d9e2e8ba944a44~300x300.image';
    @override
    Widget build(BuildContext context) {
    return FadeInImage(
    width: 100,
    height: 100,
    placeholder: AssetImage(
    'assets/images/default_icon.png',
    ),
    image: NetworkImage(headUrl),
    );
    }
    }



    3.FadeInImage 动画配置

    淡出动画 fadeOut 是针对占位图 而言的,淡入动画 fadeIn 是针对目标图 而言的,我们可以配置两个动画的时长和曲线来达到期望的动画效果,如下是测试案例的效果:






































    属性名 类型 默认值 用途
    fadeOutDuration Duration 300 ms 占位图淡出时长
    fadeOutCurve Curves Curves.easeOut 占位图淡出动画曲线
    fadeInDuration Duration 700 ms 目标图淡入时长
    fadeInCurve Curves Curves.easeIn 目标图淡入动画曲线

    FadeInImage(
    width: 100,
    height: 100,
    fadeOutDuration:Duration(seconds: 1),
    fadeOutCurve: Curves.easeOutQuad,
    fadeInDuration: Duration(seconds: 2),
    fadeInCurve: Curves.easeInQuad,
    placeholder: AssetImage(
    'assets/images/default_icon.png',
    ),
    image: NetworkImage(headUrl),
    );



    4.FadeInImage 的图片错误构建器

    既然是图片加载,就可能出错,这两个 XXXErrorBuilder 就是用来处理当图片加载错误时应该如何显示。如果不处理,就会像下面这样:



    我们可以指定 XXXErrorBuilder 回调来构建错误时显示的组件,如下当占位符错误,显示蓝色 Container 示意一下,你可以指定任意的 Widget


























    属性名 类型 默认值 用途
    placeholderErrorBuilder ImageErrorWidgetBuilder null 占位图加载错误时构建器
    imageErrorBuilder ImageErrorWidgetBuilder null 目标图加载错误时构建器

    class FadeInImageDemo extends StatelessWidget{

    final headUrl =
    'https://sf1-ttcdn-tos.pstatp.com/img/user-avatar/5b2b7b85d1c818fa71d9e2e8ba944a44~300x300.image';

    @override
    Widget build(BuildContext context) {
    return
    FadeInImage(
    width: 100,
    height: 100,
    fadeOutDuration:Duration(seconds: 1),
    fadeOutCurve: Curves.easeOutQuad,
    fadeInDuration: Duration(seconds: 2),
    fadeInCurve: Curves.easeInQuad,
    placeholderErrorBuilder: _placeholderErrorBuilder,
    placeholder: AssetImage(
    'assets/images/default_icon2.png',
    ),
    image: NetworkImage(headUrl),
    );
    }

    Widget _placeholderErrorBuilder(BuildContext context, Object error, StackTrace? stackTrace) {
    return Container(
    width: 100,
    height: 100,
    color: Colors.blue,
    );
    }
    }



    5.FadeInImage 其他属性

    剩下的几个属性都是传给 Image 的,也就是说作用和 Image 中的属性一致,这里就不展开了。





    6.FadeInImage 的其他构造

    除了普通构造之外,FadeInImage 还有 assetNetworkmemoryNetwork ,这两者只是占位组件是 asset 路径 还是 Uint8List 字节数组的区别。这两个构造的目的是便于使用,可以指定缩放以及宽高。





    可以看到两个 ImageProvider 成员对象会通过 ResizeImage 进行处理,通过 ResizeImage 可以更改图片资源的大小,通常用于减少 ImageCache 的内存占用。



    到这里,FadeInImage 的使用方面就介绍完了。下面来看一下,作为一个 StatelessWidget , FadeInImage 为什么可以执行这么复杂的组件内容变化。




    二、 FadeInImage 组件的源码实现


    1. FadeInImage 组件的构建

    对于 StatelessWidget 而言,逻辑基本上只在 build 方法中如何构建组件。如下是 FadeInImage#build,会通过 _image 方法创建 result 组件,并且一个 frameBuilder 的构建回调,使用了 _AnimatedFadeOutFadeIn 组件。





    如果 excludeFromSemantics=false 会套上一个语义组件,Semantics 。这就是 FadeInImage 构造的全部内容。





    _image 方法就是根据入参和成员属性构建 Image 组件而已,也没什么特别的。现在核心就是 frameBuilder 的回调会构建 _AnimatedFadeOutFadeIn 。那 Image#frameBuilder 是什么时候会调用呢?先让子弹飞一会,现在看一下 _AnimatedFadeOutFadeIn 的实现。





    2. _AnimatedFadeOutFadeIn 组件的实现

    它继承自 ImplicitlyAnimatedWidget ,表示其是一个 隐式动画组件,在 AnimatedOpacity 一文中介绍过隐式组件的特性:外界只需要改变相关配置属性,进重构组件就能触发动画,无需操作动画控制器。



    _AnimatedFadeOutFadeInState#build 中可以看出,淡入淡出的动画实现是通过两个 FadeTransition完成的,两者通过 Stack 叠合。这样看来是不是豁然开朗。





    3. 渐变动画如何触发

    AnimatedOpacity 一文中也说过,对于隐式组件,动画的启动是通过改变属性和重建组件,来触发 State#didUpdateWidget ,开启动画。



    那问题来了,作为 StatelessWidgetFadeInImage ,如何重构 _AnimatedFadeOutFadeIn 。现在再来看 frameBuilder 就正是时候。Image 组件的 frameBuilder 是一个回调的构建,它会在 _ImageState 构建时触发。





    第一次是图片没有加载:



    第二次是图片加载完成:



    属性变化 + 组件重构,从而触发隐式组件的动画启动,完成需求。可以看出 FadeInImage 是非常巧妙的。FadeInImage 的使用方式到这里就介绍完毕,那本文到这里就结束了,谢谢观看,明天见~

    收起阅读 »

    LiveData:还没普及就让我去世?我去你的 Kotlin 协程

    在今年(2021 年)的 Google I/O 大会中的 Jetpack Q&A 环节,Android 团队被问了一个很有意思的问题:LiveData 是要被废弃了吗? 问题不是瞎问的 大家好,我是扔物线朱凯。今天来聊个轻松的,不那么硬核的...
    继续阅读 »



    在今年(2021 年)的 Google I/O 大会中的 Jetpack Q&A 环节,Android 团队被问了一个很有意思的问题:LiveData 是要被废弃了吗?




    问题不是瞎问的


    大家好,我是扔物线朱凯。今天来聊个轻松的,不那么硬核的——LiveData。


    LiveData 是 Android 官方在 2017 年推出的一系列架构组件中的一个,跟它一起的还有 ViewModel 和 Lifecycle 等等,以及这几年陆续出现的一个个新成员。这些组件后来有了统一的名字:Jetpack;而 Jetpack 的各个组件也越来越被 Android 开发者接受。LiveData 作为 Jetpack 的架构组件的元老级成员,发展势头也一直不错,可是——它从今往后要开始往下走了。就像你在视频开头看到的,有人问 Android 团队「你们是要废弃 LiveData 了吗?」这个问题可不是瞎问的。


    那是咋问的呢?这还得从当年的 RxJava 说起。


    从 RxJava 说起


    LiveData 在 2017 年刚一面世,就受到了很大的关注,其中一个原因是它让很多人想到了 RxJava。LiveData 是一个以观察者模式为核心,通过让界面对变量进行订阅来实现自动通知刷新的组件,而 RxJava 最核心的关键词就是观察者模式和事件流,所以当时很多人拿它去和 RxJava 做比较:有人说它比 RxJava 好用,有人说它没有 RxJava 强大,还有人说它俩根本就不是一个东西,放在一起比较是没有意义的。


    至于我的观点嘛……这就说。


    RxJava 是在 2014、2015 年这个时间火起来的,国内晚一些,大概在 2016 年开始爆火。当时全世界的劳动人民用 RxJava 一般是做两件事:网络请求,以及 event bus。网络请求这个就不用说了,RxJava 配合 Retrofit 来做网络请求,各种复杂操作和线程切换,谁用谁知道——现在用协程就可以了,比 RxJava 方便;而 event bus,当时比较火的是两个开源库:GreenRobot 的 EventBus——同名库——,和 Square 的 Otto,在 RxJava 流行起来之后,大家发现,哎,这 RxJava 稍微定制一下也能实现 event bus 的功能啊?那既然我都用 RxJava 了,我为啥不把 event bus 也交给它做?就这样,一种叫做 RxBus 的模式就流行了起来,后来也有人开源了这样的库。


    就在这样的时代背景下,LiveData 在 2017 年发布了。它的功能是让变量可以被订阅。跟一般的订阅比起来,LiveData 有两个特点:一是它的目标非常直接,直指界面刷新,所以它的数据更新只发生在主线程;二是它借助了另一个架构组件——Lifecycle——的功能,让它可以只在界面到了前台的时候才通知更新,在后台的时候就闷不吭声,避免浪费性能,也避免了 bug。


    为什么不用 RxJava?


    很方便,很好用。但是这里就会有一个问题:变量的订阅,用 RxJava 不能做吗?为什么要搞一个新库出来呢?RxJava 就是专门做事件订阅的呀?



    • 是因为…… LiveData 的数据更新发生在主线程?RxJava 也可以啊,一个操作符的事( observeOn(AndroidSchedulers.MainThread)) ),安排。

    • 那……是因为它结合了 Lifecycle,对生命周期的支持比较到位?RxJava 也可以啊,改吧改吧就能支持了,总比写一个新库容易吧?


    所以 LiveData 的功能,用 RxJava 可以实现吗?是完全可以的,没有任何问题。那 Android 官方为什么要做一个 LiveData 出来,而不是直接推荐大家去用 RxJava 来实现这样的功能?或者退一步,用 RxJava 来做 LiveData 的底层实现也行啊?为什么都没有?——因为 RxJava 太大了,而且它还不是 Android 自己官方的东西,而是别人的。


    这个倒不是说 Google 小心眼子,只许宣传我自己的东西,不许壮大别人,而是 Android 作为一个平台方,它肯定要考虑开发者们的普遍水平的。RxJava 说实话虽然好用,但是太复杂了,上手成本忒高,所以如果 Android 要用 RxJava 来实现 LiveData,或者推荐开发者们用 RxJava 来自己实现 LiveData 的功能,那么它就需要考虑怎么让我们开发者学会 RxJava。怎么让我们学会?就只能自己教呗!写文档、出视频,教大家用 RxJava。那这个动作就有点大了,就把事情变复杂了。再加上 RxJava 还既不是 Android 体系里的东西,也不是 Google 体系里的东西,那么如果 Android 团队就为了一个 LiveData 的功能要去全网推广和教学 RxJava,这个逻辑就有点不对了,事情不是这么玩的。所以 RxJava 太大了,并且是第三方的,这两个原因结合起来,就让 Android 的 LiveData 没有使用 RxJava。这并不是一个竞争或胸怀的问题,而是一个「不要把事情变复杂」的问题。——当然这是我自己的观点啊。


    2017 - 2021 的变化


    但!这只是当时的情况。当时是什么时候?2017 年。2017 是 Android 的大年,这一年发生了好几件大事:



    • 官方发布了几个架构组件;

    • 官方宣布对 Kotlin 的支持;

    • HenCoder 发布(假)。


    HenCoder 是我乱讲的啊。我要说的是 Kotlin,Kotlin 在 2017 得到了 Android 官方的公开支持,在接下来这几年里,Kotlin 自身越来越完善,它的协程也越来越完善。2017 年之前,事件订阅大部分人是用 EventBus 或者 Otto,并且在 RxJava 流行起来之后,EventBus 和 Otto 的使用开始持续下降;2017 之后,对于简单场景大家慢慢过渡到了 LiveData,复杂场景还在用 RxJava,因为 LiveData 不适合复杂场景;而现在,我们有了 Flow。协程的 Flow 和 RxJava 的功能范围非常相似——其实我觉得就是一样的——但是 Flow 是协程里必不可少的一部分,而协程是 Kotlin 里必不可少的一部分,而 Kotlin 是 Android 开发里必不可少的一部分——哦这个说的不对,重新说——而 Kotlin 又是 Android 现在主推的开发语言以及未来的趋势,这样的话,Flow 一出来,那就没 LiveData 什么事了。别说 LiveData 了,以后 RxJava 也没什么事了。不过这个肯定需要一个过程的,LiveData 和 RxJava——尤其是 RxJava——肯定会继续坚挺一段时间的,只是趋势会是这么一个趋势。


    「不会废弃 LiveData」……吗?


    视频(文章)开头那个问题,Yigit 的回答是:LiveData 不会被废弃,因为两个原因:



    1. 用 Java 写 Android 的人还需要它——Flow 是协程的东西,所以如果你是用 Java 的,那其实没办法用 Flow;

    2. LiveData 的使用比较简单,而且功能上对于简单场景也是足够的,而 RxJava 和 Flow 这种东西学起来就没 LiveData 那么直观。


    简单说就是,为了 Java 语言的使用者和不想学 RxJava 或者 Flow 的人,LiveData 会被保留。不过你如果用发展的眼光去看他这番话……你懂我意思吧?


    那我走?


    那……对于不会 LiveData 的人,还有必要学 LiveData 吗?以及已经在用 LiveData 的项目,需要快点移除 LiveData 吗?


    如果你不会 LiveData,对于当下(2021 年)来说,还是很有必要学一下的,因为 LiveData 现在的应用率还是很高的,所以你就算你现在不用,你未来工作的团队也可能会用,反正这东西很简单,学一下不费事。另一方面,在用 LiveData 的人,确实可以考虑摘除它了;但也不是着急忙慌地把它拿走,它不是毒药不是地雷,只是协程的 Flow 现在可以做这件事了,而未来 Flow 一定是会成为主流的,就像现在的 Kotlin 一样;在项目里用两样东西来做同一件事(事件订阅)不如只用一样,因此你可以考虑摘除 LiveData,是这么个逻辑。所以你就算是着急,也应该去着急学 Flow,而不是着急地把 LiveData 拆掉,它没有毒,等以后你觉得它给你带来不方便了,你自然会把它拆掉。


    好,今天就是这样,如果你喜欢我的内容,别忘了点赞订阅关注。我是扔物线,我不和你比高低,我只助你成长,我们下期见。



    收起阅读 »

    大厂Android岗高频面试问题:说说你对Zygote的理解!

    前言 Zygote可以说是Android开发面试很高频的一道问题,但总有小伙伴在回答这道问题总不能让面试满意, 在这你就要搞清楚面试问你对Zygote的理解时,面试官最想听到的和其实想问的应该是哪些?下面我们通过以下几点来剖析这道问题! 了解Zygo...
    继续阅读 »

    前言


    Zygote可以说是Android开发面试很高频的一道问题,但总有小伙伴在回答这道问题总不能让面试满意, 在这你就要搞清楚面试问你对Zygote的理解时,面试官最想听到的和其实想问的应该是哪些?下面我们通过以下几点来剖析这道问题!



    • 了解Zygote的作用

    • 熟悉Zygote的启动流程

    • 深刻理解Zygote的工作原理



    下面来我们来深入剖析



    一、 Zygote的作用


    Zygote的作用分为两点:



    • 启动SystemServer

    • 孵化应用进程


    关于这个问题答出了这两点那就是OK了。可能大部分小伙伴可能能答出第二点,第一点就不是很清楚。SystemServer也是Zygote启动的,因为SystemServer需要用到Zygote准备好的系统资源包括:


    img


    直接从Zygote继承过来就不需要重新加载过来,那么对性能将会有很大的提升。


    二、Zygote的启动流程


    2.1 启动三段式


    在说Zygote启动流程之前,**先明确一个概念:启动三段式,**这个可以理解为Android中进程启动的常用套路,分为三步骤:


    img


    这里要了解LOOP循环是什么,其实LOOP作用是不停的接受消息处理消息,消息的来源可以是SoketMessageQueueBinder驱动发过来的消息,但无论消息从哪里来,它整个流程都是去接受消息,处理消息。这个启动三段式,它不光是Zygote进程是这样的,只要是有独立进程的,比如说系统服务进程,自己的应用进程都是如此。


    2.2 Zygote进程是怎么启动的?


    Zygote进程的启动取决于init进程,init进程是它是linux启动之后用户空间的第一个进程,下面看一下启动流程



    1. linux启动init进程

    2. init进程启动之后加载init.rc配置文件


    img



    1. 启动配置文件中定义的系统服务,其中Zygote服务就是定义在配置中的


    img



    1. 同时启动的服务除了Zygote之外还有一些别的系统服务也是会启动的,比如说ServiceManager进程,它是通过fork+execve系统调用启动的


    img


    2.2.1加载Zygote的启动配置


    在init.rc 文件中会import /init.${ro.zygote}.rc,init.zygoteXX,XX指的是32或者64,对我们没差我们直接看init.zygote32.rc即可。配置文件比较长,这里做了截取保留了Zygot相关的部分。


    service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server    
    class main
    socket zygote stream 660 root system
    onrestart write /sys/android_power/request_state wake
    onrestart write /sys/power/state on
    onrestart restart audioserver
    writepid /dev/cpuset/foreground/tasks


    • service zygote:是进程名称,

    • /system/bin/app_process:可执行程序的路径,用于init进程fork,execve调用

    • -Xzygote /system/bin --zygote --start-system-server 为它的参数


    2.2.2启动进程


    说完了启动配置呢,这里来聊一下启动进程,启动进程有两种方式:


    第一种:fork+handle


    pid_t pid = fork();
    if (pid == 0){
    // child process
    } else {
    // parent process
    }

    第二种:fork+execve


    pid_t pid = fork();
    if (pid == 0) {
    // child process
    execve(path, argv, env);
    } else {
    // parent process
    }

    两者看起来差不多,首先首先都会调用fork函数创建子进程,这个函数比较奇特会返回两次,子进程返回一次,父进程返回一次。区别在于:



    • 子进程一次,返回的pid是0 但是父进程返回的pid是子进程的pid,因此可以根据判断pid来区分目前是子进程还是父进程

    • 对于handle默认的情况,子进程会继承父进程的所有资源,但当通过execve去加载二进制程序时,那父进程的资源则会被清除


    2.2.3信号处理-SIGCHLD


    当父进程fork子进程后,父进程需要关注这个信号。当子进程挂了,父进程就会收到SIGCHLD,这时候父进程就可以做一些处理。例如Zygote进程如果挂了,那父进程init进程就会收到信号将Zygote进程重启。


    img


    三、Zygote进程启动原理


    主要分为两部分Native层处理和Java层处理,Zygote进程启动之后,它执行了execve系统调用,它执行的是用C++写的二进制的可执行程序里的main函数作为入口,然后在Java层运行!


    先来看一下Native层的处理流程


    img


    在app_main.cpp文件,AndroidRuntime.cpp文件。我们可以找到几个主要函数名


    int main(int argc,char *argv[]){
    JavaVM *jvm;
    JNIEnv *env;
    JNI_CreateJavaVM(&jvm,(void**)&env,&vm_args); //创建Java虚拟机
    jclass clazz = env->FindClass("ZygoteInit"); //找到叫ZygoteInit的Java类
    jmethodID method = env->GetStaticMethodID(clazz,"Main","[Ljava/lang/String;)V"); //找到ZygoteInit类中的Main的静态函数
    env->CallStaticVoidMethod(clazz,method,args); //调用main函数
    jvm->DestroyJavaVM();
    }

    根据上述代码,你会发现在我们的应用里直接就可以 JNI 调用了,并不需要创建虚拟机。因为应用进程是Zygote进程孵化出来的,继承了父进程的拥有虚拟机,只需要重置数据即可。


    接着看一下Java层的处理,具体可参考ZygoteInit文件的main方法



    1. 预加载资源,比如常用类库、主题资源及一些共享库等


    img



    1. 启动SystemServer进程


    img



    1. 进入Socket 的Loop循环 会看到的ZygoteServer.runSelectLoop(…)调用


    boolean runOnce() {
    String[] args = readArgumentList(); //读取参数列表
    int pid = Zygote.forkAndSpecialize(); //根据读取到的参数启动子进程
    if(pid == 0) {
    //in child
    //执行ActivityThread的入口函数(main)
    handleChildProc(args,...);
    return true;
    }
    }

    img


    四、总结


    Zygote启动流程中需要主要以下2点问题



    1. Zygote fork要保证是单线程

    2. Zygote的IPC是采用socket




    收起阅读 »

    ConstraintLayout 中的 Barrier 和 Chains

    1. Barrier 是一个准则,可以说是对其的规则,这样说还不够名义,我们可以列表一些比较常见的场景; 官网 Barrier。 具体看图 “第二行的label”和“第二行value”是一个整体,他们距离上面是 100dp ,但是有可能“第二...
    继续阅读 »



    1. Barrier


    是一个准则,可以说是对其的规则,这样说还不够名义,我们可以列表一些比较常见的场景; 官网 Barrier



    1. 具体看图


    1883633-62653bd01cb70813.webp “第二行的label”和“第二行value”是一个整体,他们距离上面是 100dp ,但是有可能“第二行value”的值为空或者是空,也需要“第二行label”距离上面的距离是 100dp ,由于我们知道“第二行value”的高度高于第一个,所以采用的是“第二行label”跟“第二行value”对其,“第二行value”距离上边 100dp 的距离,但是由于“第二行value”有可能为空,所以当“第二行value”为空的时候就会出现下面的效果:


    1883633-043d00e43ff22557.webp 我们发现达不到预期,现在能想到的办法有,首先在代码控制的时候随便把“第二行label”的 marginTop 也添加进去;还有就是换布局,将“第二行label”和“第二行value”放到一个布局中,比如 LinearLayout ,这样上边的 marginTopLinearLayout 控制;这样的话即便“第二行value”消失了也会保持上边的效果。


    除了上边的方法还能使用其他的嘛,比如我们不使用代码控制,我们不使用其他的布局,因为我们知道布局嵌套太多性能也会相应的下降,所以在编写的时候能减少嵌套的情况下尽可能的减少,当然也不能为了减少嵌套让代码变得格外的复杂。


    为了满足上面的需求, Barrier 出现了,它能做到隐藏的也能依靠它,并且与它的距离保持不变对于隐藏的“第二行value”来说,虽然消失了,但保留了 marginTop 的数值。下面看看布局:


    <?xml version="1.0" encoding="utf-8"?>
    <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">


    <TextView
    android:id="@+id/textView4"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="头部"
    android:textSize="36sp"
    app:layout_constraintBottom_toTopOf="@id/barrier3"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toTopOf="parent" />



    <androidx.constraintlayout.widget.Barrier
    android:id="@+id/barrier3"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:barrierDirection="top"
    android:layout_marginTop="100dp"
    app:constraint_referenced_ids="textView2,textView3" />


    <TextView
    android:id="@+id/textView2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginStart="4dp"
    android:text="第二行label"
    android:textSize="36sp"
    app:layout_constraintBottom_toBottomOf="@+id/textView3"
    app:layout_constraintStart_toStartOf="@+id/textView4"
    app:layout_constraintTop_toTopOf="@+id/textView3"
    app:layout_constraintVertical_bias="0.538" />


    <TextView
    android:id="@+id/textView3"
    android:layout_width="wrap_content"
    android:layout_height="100dp"
    android:layout_marginStart="12dp"
    android:layout_marginTop="100dp"
    android:text="第二行value"
    android:textSize="36sp"
    app:layout_constraintStart_toEndOf="@+id/textView2"
    app:layout_constraintTop_toBottomOf="@+id/barrier3" />


    </androidx.constraintlayout.widget.ConstraintLayout>

    这样即便将“第二行value”消失,那么总体的布局仍然达到预期,并且也没有添加很多布局内容。在代码中:


    <androidx.constraintlayout.widget.Barrier
    android:id="@+id/barrier3"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:barrierDirection="top"
    android:layout_marginTop="100dp"
    app:constraint_referenced_ids="textView2,textView3" />


    这里主要有两个属性 app:barrierDirectionapp:constraint_referenced_ids



    • app:barrierDirection 是代表位置,也就是在包含内容的哪一个位置,我这里写的是 top ,是在顶部,还有其他的属性 top,bottom,left,right,startend 这几个属性,看意思就很明白了。

    • app:constraint_referenced_ids 上面说的内容就是包含在这里面的,这里面填写的是 id 的名称,如果有多个,那么使用逗号隔开;这里面的到 Barrier 的距离不会改变,即便隐藏了也不会变。


    这里可能会有疑惑,为啥我写的 idtextView4 的也依赖于 Barrier ,这是因为本身 Barrier 只是规则不是实体,它的存在只能依附于实体,不能单独存在于具体的位置,如果我们只有“第二行value”依赖于它,但是本身“第二行value”没有上依赖,也相当于没有依赖,这样只会导致“第二行label”和“第二行value”都消失,如果 textView4 依赖于 Barrier ,由于 textView4 的位置是确定的,所以 Barrier 的位置也就确定了。



    1. 类似表格的效果。看布局效果:


    1883633-c4b862a2df57fb96.webp 我要做成上面的样子。也就是右边永远与左边最长的保持距离。下面是我的代码:


    <?xml version="1.0" encoding="utf-8"?>
    <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">



    <TextView
    android:id="@+id/textView4"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginStart="8dp"
    android:text="头部"
    android:textSize="36sp"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toTopOf="parent" />


    <TextView
    android:id="@+id/textView2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginStart="4dp"
    android:text="第二行"
    android:textSize="36sp"
    app:layout_constraintBottom_toBottomOf="@+id/textView3"
    app:layout_constraintStart_toStartOf="@+id/textView4"
    app:layout_constraintTop_toTopOf="@+id/textView3" />


    <TextView
    android:id="@+id/textView3"
    android:layout_width="wrap_content"
    android:layout_height="50dp"
    android:layout_marginStart="20dp"
    android:layout_marginTop="10dp"
    android:text="第二行value"
    android:textSize="36sp"
    app:layout_constraintStart_toEndOf="@+id/barrier4"
    app:layout_constraintTop_toBottomOf="@+id/textView4" />



    <TextView
    android:id="@+id/textView5"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_marginStart="4dp"
    android:text="第三次测试"
    android:textSize="36sp"
    app:layout_constraintBottom_toBottomOf="@+id/textView6"
    app:layout_constraintStart_toStartOf="@+id/textView4"
    app:layout_constraintTop_toTopOf="@+id/textView6" />


    <TextView
    android:id="@+id/textView6"
    android:layout_width="wrap_content"
    android:layout_height="50dp"
    android:layout_marginStart="20dp"
    android:layout_marginTop="10dp"
    android:text="第三行value"
    android:textSize="36sp"
    app:layout_constraintStart_toEndOf="@+id/barrier4"
    app:layout_constraintTop_toBottomOf="@+id/textView3" />


    <androidx.constraintlayout.widget.Barrier
    android:id="@+id/barrier4"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:barrierDirection="end"
    app:constraint_referenced_ids="textView2,textView5"
    tools:layout_editor_absoluteX="411dp" />



    </androidx.constraintlayout.widget.ConstraintLayout>

    添加好了,记得让右边的约束指向 Barrier 。这里的 Barrier ,我们看到包含 textView2textView5 ,这个时候就能做到谁长听谁的,如果此时 textView2 变长了,那么就会将就 textView2


    2. Chains


    我们特别喜欢使用线性布局,因为我们发现 UI 图上的效果使用线性布局都可以使用,当然也有可能跟大部分人的思维方式有关系。比如我们非常喜欢的,水平居中,每部分的空间分布等等都非常的顺手。既然线性布局这么好用,那为啥还有约束布局呢,因为线性布局很容易写出嵌套很深的布局,但约束布局不会,甚至大部分情况都可以不需要嵌套就能实现,那是不是代表线性布局有的约束布局也有,答案是肯定的。


    使用普通的约束关系就很容易实现水平居中等常用效果,其他的如水平方向平均分布空间,使用一般的约束是实现不了的,于是就要使用 Chains ,这个就很容易实现下面的效果:


    1883633-78aa31c23dcb4c4f.webp 其实上一篇中我已经把官网的教程贴上去了,这里主要写双向约束怎么做,一旦双向约束形成,那么就自然进入到 Chains 模式。


    1)在视图模式中操作


    1883633-618f9b2eb563a637.webp


    如果直接操作,那么只能单向约束,如果要形成这样的约束,需要选择相关的的节点,比如我这里就是同时选择 AB ,然后点击鼠标右键,就可以看到 ChainsCreate Horizontal Chain


    对应的操作


    选择图中的选项即可完成从 A 指向 B ,修改的示意图为:


    1883633-cf3984e22df83c7c.webp


    我们发现已经实现了水平方向的排列效果了。至于怎么实现上面的效果,主要是改变 layout_constraintVertical_chainStylelayout_constraintHorizontal_chainStyle 属性。至于权重则是属性 layout_constraintHorizontal_weight


    layout_constraintHorizontal_chainStyle 属性说明:



    • spread 默认选项,效果就是上面的那种,也就是平均分配剩余空间;

    • spread_inside 两边的紧挨着非 Chains 的视图,中间的平均分配;


    1883633-49c52026c6797e51.webp



    • packed 所有的都在中间


    1883633-714e58d28eaab99c.webp 注意了, layout_constraintHorizontal_weight 这个属性只有在 A 身上设置才可以,也就是首节点上设置才可行,同时 layout_constraintHorizontal_weight 是代表水平方向,只能在水平方向才发生作用,如果水平的设置了垂直则不生效。


    layout_constraintHorizontal_weight 这个属性只有在当前视图的宽或者高是 0dp 。至于这个的取值跟线性布局相同。


    1883633-072f1f968528ef1a.webp


    2)代码的方式 跟上面的差别就是在做双向绑定,用代码就很容易实现双向绑定,可平时添加约束相同。

    收起阅读 »

    iOS - 多线程应用场景

    iOS
    实际项目开发中为了能够给用户更好的体验,有些延时操作我们都会放在子线程中进行。今天我们就来聊聊多线程在实际项目中的运用。我们先来看看多线程的基础知识:1.多线程的原理:        同一时间,CPU只能处理一条线程,也...
    继续阅读 »

    实际项目开发中为了能够给用户更好的体验,有些延时操作我们都会放在子线程中进行。

    今天我们就来聊聊多线程在实际项目中的运用。

    我们先来看看多线程的基础知识:

    1.多线程的原理:

            同一时间,CPU只能处理一条线程,也就是只有一条线程在工作。所谓多线程并发(同时)执行,

    其实是CPU快速的在多线程之间调度(切换)。如果CPU调度线程的时间足够快,就造成了多线程并

    发执行的假象。

    2.在实际项目开发中并不是线程越多越好,如果开了大量的线程,会消耗大量的CPU资源,CPU会

    被累死,所以一般手机只开1~3个线程为宜,不超过5个。

    3.多线程的优缺点:

    优点:1.能适当提高程序的执行效率

           2.能适当提高资源的利用率,这个利用率表现在(CPU,内存的利用率)

    缺点:1.开启线程需要占用一定的内存空间(默认情况下,主线程占用1M,

    子线程占用512KB,如果开启大量的线程,会占用大量的内存空间,降低程序

    的性能)

         2.线程越多,CPU在调度线程上的开销就越大

         3.程序设计就越复杂:比如线程之间的通信,多线程的数据共享,这些

    都需要程序的处理,增加了程序的复杂度。

    4.在iOS开发中使用线程的注意事项:

        1.别将比较耗时的操作放在主线程中

        2.耗时操作会卡住主线程,严重影响UI的流畅度,给用户一种“卡”的坏体验

    好了,多线程在iOS中的开发概念性的东西就讲这么多,下面我们来模拟一种开发中的场景:

    我们在开发中经常会遇到,当你要缓存一组图片,但是这些图片必须要等到你缓冲好了后再来展现在UI上,

    可是我们缓存图片的时候用的是SDWebImage框架,缓存的操作是异步进行的,我们如何来做到等缓存好了

    再来执行以后的操作呢?下面讲个实现起来非常简单,方便的方法:

    我先来放上代码,后面进行讲解:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    //1.添加一个组
            let group = dispatch_group_create()
             
            //缓存图片
            for url in picURLs! {
                 
                //2.将当前的下载操作添加到组中
                dispatch_group_enter(group)
                SDWebImageManager.sharedManager().downloadImageWithURL(url, options: SDWebImageOptions.init(rawValue: 0), progress: nil, completed: { (_, _, _, _, _) in
                     
                    //3.离开当前组
                    dispatch_group_leave(group)
                    print("正在缓存中...")
                })
            }
             
            //通过闭包将数据传递给调用者(通知图片缓存完毕)
            dispatch_group_notify(group, dispatch_get_main_queue()) {
                print("缓存完毕!")
                finished()
            }

     

    从输出结果我们就可以看出来:我们做到了缓存完毕后再来执行以后的操作。

    是如何做到的呢?

    我在代码中已经用数字标出来了:

    1.我们首先用

    let group = dispatch_group_create()

    函数来创建一个组,用来存放缓冲的操作

    2.用这个函数做到把每一次的缓冲操作都添加到组中

    1
    dispatch_group_enter(group)

     3.缓存图片我用的是SDWebImage框架,我们可以看到,我在缓冲完毕后离开当前组,用到如下函数

    dispatch_group_leave(group)

    用了这三步就能做到我们想要的功能吗?显然不是,做了这三部系统内部就会为我们做些事了,

     

    当我们离开当前组的时候,系统就会发出一个通知,我们来接收这个通知,当我们接收到这个通知的时候

    我们就可以执行finished的操作了,接收通知的函数是:

    dispatch_group_notify(group, dispatch_get_main_queue()) {
    print(
    "缓存完毕!")
    finished()
    }

    以上就是一个非常方便的实现我们需要的功能的方法

     

    https://blog.csdn.net/qq_24904667/article/details/52679473

    收起阅读 »

    swift 多线程下

    iOS
    Swift多线程编程方案: Thread Cocoa Operation (Operation 和 OperationQueue) Grand Central Dispath (GCD) 1. Thread在三种多线程技术中是最轻量级的, 但需要自己...
    继续阅读 »

    Swift多线程编程方案:



    • Thread


    • Cocoa Operation (OperationOperationQueue)


    • Grand Central Dispath (GCD)




    1. Thread在三种多线程技术中是最轻量级的, 但需要自己管理线程的生命周期和线程同步. 线程同步对数据的加锁会有一定的系统开销.



    • detachNewThread(_ block: @escaping () -> Void)

    • detachNewThreadSelector(_ selector: Selector, to Target target: Any, with argument: Any?)



    e.g.

    for i in 0...10 {
    Thread.detachNewThread {
    print("\(i) \(Thread.current)")
    }
    }

    输出结果:

    8 <NSThread: 0x6000000f8e40>{number = 12, name = (null)}
    10 <NSThread: 0x6000000f0240>{number = 17, name = (null)}
    7 <NSThread: 0x6000000cc0c0>{number = 10, name = (null)}
    1 <NSThread: 0x6000000c0180>{number = 14, name = (null)}
    6 <NSThread: 0x6000000efe80>{number = 9, name = (null)}
    4 <NSThread: 0x6000000efdc0>{number = 11, name = (null)}
    5 <NSThread: 0x6000000c8580>{number = 15, name = (null)}
    9 <NSThread: 0x6000000cc080>{number = 8, name = (null)}
    0 <NSThread: 0x6000000fd300>{number = 7, name = (null)}
    2 <NSThread: 0x6000000cc5c0>{number = 13, name = (null)}
    3 <NSThread: 0x6000000f0780>{number = 16, name = (null)}


    e.g.

    class ObjectForThread {
    func threadTest() -> Void {
    let thread = Thread(target: self, selector: #selector(threadWorker), object: nil)
    thread.start()
    print("threadTest")
    }
    @objc func threadWorker() -> Void {
    print("threadWorker Run")
    }
    }

    let obj = ObjectForThread()
    obj.threadTest()

    输出结果:

    threadTest
    threadWorker Run




    2. OperationOperationQueue


    Operation



    • 面向对象 (OperationBlockOperation)


    • Operation+ OperationQueue

    • 取消、依赖、任务优先级、复杂逻辑、保存业务状态、子类化


    Operation的四种状态 :



    • isReady

    • isExecuting

    • isFinished

    • isCancelled


    OperationQueue




    • OperationQueue队列里可以加入很多个Operation, 可以把OperationQueue看做一个线程池, 可以往线程池中添加操作(Operation)到队列中

    • 底层使用GCD


    • maxConcurrentOperationCount可以设置最大并发数


    • defaultMaxConcurrentOperationCount根据当前系统条件动态确定的最大并发数

    • 可以取消所有Operation, 但是当前正在执行的不会取消

    • 所有Operation执行完毕后退出销毁



    e.g. BlockOperation

    class ObjectForThread {
    func threadTest() -> Void {
    let operation = BlockOperation { [weak self] in
    self?.threadWorker()
    }
    let queue = OperationQueue()
    queue.addOperation(operation)
    print("threadTest")
    }
    }

    let obj = ObjectForThread()
    obj.threadTest()


    e.g. 自定义的Operation

    class ObjectForThread {
    func threadTest() -> Void {
    let operation = MyOperation()
    operation.completionBlock = {() -> Void in
    print("完成回调")
    }
    let queue = OperationQueue()
    queue.addOperation(operation)
    print("threadTest")
    }
    }
    class MyOperation: Operation {
    override func main() {
    sleep(1)
    print("MyOperation")
    }
    }

    let obj = ObjectForThread()
    obj.threadTest()



    3. GCD


    GCD特点



    • 任务+队列

    • 易用

    • 效率

    • 性能


    GCD - 队列



    • 主队列: 任务在主线程执行

    • 并行队列: 任务会以先进先出的顺序入列和出列, 但是因为多个任务可以并行执行, 所以完成顺序是不一定的.

    • 串行队列: 任务会以先进先出的顺序入列和出列, 但是同一时刻只会执行一个任务


    GCD - 队列API



    • Dispatch.main

    • Dispatch.global

    • DispatchQueue(label:,qos:,attributes:,autoreleaseFrequency:,target:)

    • queue.label

    • setTarget(queue:DispatchQueue)


    • 最终的目标队列都是主队列和全局队列

    • 如果把一个并行队列的目标队列都设置为同一个串行队列, 那么这多个队列连同目标队列里的任务都将串行执行

    • 如果设置目标队列成环了, 结果是不可预期的

    • 如果在一个队列正在执行任务的时候更换目标队列, 结果也是不可预期的



    e.g.

    let queue = DispatchQueue(label: "myQueue", qos: .default, attributes: .concurrent, autoreleaseFrequency: .inherit, target: nil)
    queue.async {
    sleep(3)
    print("queue")
    }
    print("end")


    e.g.

    let queue = DispatchQueue(label: "myQueue", qos: .default, attributes: .concurrent, autoreleaseFrequency: .inherit, target: nil)
    queue.asyncAfter(deadline: DispatchTime.now() + 10) {
    print("in asyncAfter")
    }
    print("end")

    DispatchTime 系统时钟

    DispatchWallTime生活时间


    GCD 高级特性- DispatchGroup



    e.g. 阻塞当前线程

    let group = DispatchGroup()
    let queue = DispatchQueue(label: "test.queue")

    group.enter()
    queue.async {
    sleep(3)
    print("操作 1")
    group.leave()
    }

    group.enter()
    queue.async {
    sleep(3)
    print("操作 2")
    group.leave()
    }

    print("操作1 操作2 安排完成")

    group.wait()
    print("操作1 操作2 全部执行完毕")


    e.g. 非阻塞方式:

    let group = DispatchGroup()
    let queue = DispatchQueue(label: "test.queue")

    group.enter()
    queue.async {
    sleep(3)
    print("操作 1")
    group.leave()
    }

    group.enter()
    queue.async {
    sleep(3)
    print("操作 2")
    group.leave()
    }

    print("操作1 操作2 安排完成")

    group.notify(queue: queue) {
    print("操作1 操作2 全部执行完毕")
    }
    print("非阻塞")

    GCD 高级特性- DispatchSource



    • 简单来说, dispatch source是一个监听某些类型事件的对象. 当这些事件方法时, 它自动将一个task放入一个dispatch queue的执行历程中.



    e.g. DispatchSource- Timer

    var seconds = 10
    let timer: DispatchSourceTimer = DispatchSource.makeTimerSource(flags: .strict, queue: .global())
    timer.schedule(deadline: .now(), repeating: 1.0)
    timer.setEventHandler {
    seconds -= 1
    if seconds < 0 {
    timer.cancel()
    }
    else {
    print(seconds)
    }
    }
    timer.resume()


    链接:https://www.jianshu.com/p/b52728779891

    收起阅读 »

    Swift 多线程上

    iOS
    提到多线程,无非就是关注二点,一是线程安全问题,二是在合适的地方合适的使用多线程(这个就有点广泛了,但是很重要不能为了去使用而使用)。 先看下OC中定义属性的关键字atomic/nonatomic,原子属性和非原子属性(此处先不谈内存相关的知识),有啥区别呢...
    继续阅读 »

    提到多线程,无非就是关注二点,一是线程安全问题,二是在合适的地方合适的使用多线程(这个就有点广泛了,但是很重要不能为了去使用而使用)。




    先看下OC中定义属性的关键字atomic/nonatomic,原子属性和非原子属性(此处先不谈内存相关的知识),有啥区别呢?property申明的属性会默认实现setter和get方法,而atomic默认会给setter方法加锁。也就是atomic线程安全,防止数据在被不同线程读写时发生了错误,设置属性时默认就是nonatomic。万能的苹果开发大神为啥不都设置为线程安全呢,主要是因为atomic很耗内存资源,相比这点安全远不能弥补在内存资源和运行速度上的缺陷,所以需要我们在开发时,适当的时候加锁。


    说到加锁(我自己了解的也不是很多),只能说说最基本的。先看我们在OC中创建单利时,用到的关键字synchronized('加锁对象'){'加锁代码'},互斥锁,简单粗暴,不需要释放啥的,在不考虑效率下还是很方便(创建个单利能耗啥效率了,如果在swift中使用那么就是objc_sync_enter('加锁对象')和objc_sync_exit('加锁对象'))。还有就是NSLock,这个或许偶尔会用到,对象锁,lock和unlock需要成对出现,不能频繁调用lock不然可能会出现线程锁死

    let lock = NSLock
    lock.lock()
    defer {
    lock.unlock()
    }

    只是简单说下锁(至于NSRecursiveLock,NSConditionLock等各种锁的我也不是很熟,应该说是没有用过),如果多线程出现问(愿你写的多线程永远不出现线程安全问题,但是需要谨记一句:线程复杂必死),至少知道有解决的方法,在使用多线程稍微注意下。关于线程锁和线程发生锁死,我也只是略懂,以后再总结。除了加锁还可以用其他方法避免线程问题,比如:串行队列(FMDB线程安全就是这种方式),合适的使用信号量DispatchSemaphore。


    我自己也是在开发中遇到二次线程安全问题,一次在使用CoreData,还有一次就是在多线程上传图片的时候,都是泪。CoreData,最后我是使用了串行队列解决线程安全问题,CoreData是有安全队列方法的,但是呢那个是接手的项目,别人写好了,我就在原来的基础上修改的。多线程上传图片出现问题,完全是自己不够细心导致的,过了好久才意识到的问题,先说下,OC中的系统对象基本都是线程不安全的,都是操作指针,swift中的系统对象基本都是线程安全的,都是直接读取内存。即使对象是线程安全的,但是也不能在不同的线程操作同一个对象,应该先copy在再操作,就是直接用=(OC是不行的)。




    说了一大堆线程相关的废话,那再看看怎样在Swift 中使用多线程,其实最常用的也就是GCD和Operation,如果说对线程安全,GCD,Operation,队列和线程关系不了解,那就去网上找资料补一补。


    最常用的API,主线程延迟执行: DispatchQueue.main.asyncAfter(deadline: DispatchTime) {}

    获取主线程(一个应用就一个主程):

    DispatchQueue.main.async {}


    再就是GCD创建队列了,分为串型队列和并发队列(串型队列只会开一个子线程,并发队列会创建多个子线程)


    /// 并发队列
    let queue = DispatchQueue.global(qos: DispatchQoS.QoSClass.background)
    /// 串行队列
    let queue = DispatchQueue(label: "test.queue")

    接着就是异步/同步(是否阻塞当前线程的区别,注意下线程相互锁死问题)执行任务的API了,任务放到队列里面去,由队列决定是否开辟新的线程执行任务,强调一点,任何UI相关的任务不能放到子线程中执行,子线程是不能刷新UI的,如果你看到你的子线程刷新了UI那是你的眼晴欺骗了你,原因是UIKit框架不是线程安全,可能会出现资源争夺,所以只能在主线程中绘制。只是简单的介绍下比较常用的API,相对于OC的写法已经简单很多了。具体的区别和参数可以参考官方的文档,貌似还很复杂。

    接下来就可以愉快的异步线程执行耗时任务了,执行完再回到主线程中,该干嘛就干嘛了,简单粗暴。但是还是有问题需要我们去注意:



    • 任务全部执行完成的回调

    • 怎样控制执行的先后顺序(不考虑串行)

    • 怎样控制并发的数量

    • 怎样暂停/挂起任务


    很明显,有些问题GCD可能不太容易解决。


    Operation 和OperationQueue,基于GCD封装的对象,支持KVO,处理多线程的API更方便,如果你看过其他第三方框架,可以经常看到这些对象,GCD反而用的比较少。最开始出来找工作时,其实我很不喜欢别人在没有给应用场景时问我什么时候使用GCD,什么时候使用OperationQueue有种被套路的感觉(在合适的地方合理的去使用合理的多线程),就现在而言,如果简单不复杂首选GCD,当然想用OperationQueue去封装,也完全赞同,主要是看业务需求,而不是看技术需求。关于GCD和OperationQueue的区别以及性能,具体还是推荐看网上的博客,最好是先了解里面处理多线程的API,知道各自的优缺点,再去看会有不一样的收获。Operation是一个抽象类不能直接使用,可以自定义其子类,或者直接使用系统提供的子类BlockOperation(swift中系统提供的子类貌似就剩这么一个了)。Operation直接使用是没有开辟新的线程的,只有放到OperationQueue 中才是多线程(OperationQueue可以直接使用,复杂场景时会使用到Operation的子类)。OperationQueue使用的优点会在下面解决问题中提到部分。


    再看GCD中的队列组DispatchGroup,也可以对队列做简单的管理。主要将某一个任务入组和出组,实现入组和出组主要用到二种方式,那么就可以监听入组的任务是否全部完成。

    let groupQueue = DispatchGroup()
    let queue = DispatchQueue.global(qos: DispatchQoS.QoSClass.background)
    defer {
    groupQueue.notify(queue: DispatchQueue.main) {
    debugPrint("执行完成\(Thread.current)")
    }
    }
    /// 第一种直接创建的时候就加到组中,执行完成自动出组
    queue.async(group: groupQueue) {
    for i in 0 ... 100 {
    debugPrint(Thread.current , i , "------1")
    }
    }
    /// 第二种自己执行前加入,完成后手动出组
    groupQueue.enter()
    queue.async() {
    for i in 0 ... 100 {
    debugPrint(Thread.current , i , "------2")
    }
    groupQueue.leave()
    }

    二种方式只有选择的差距,第一种比较简单,但是适用的场景就比较简单,但是缺点也很明显,当执行的任务也存在异步,那么就不能判断是否真的完成任务了,很简单的例子,同时发送5个请求,要数据全部返回才能执行回调,那么很明显就只能使用第二种方式了,只有数据真正的返回了才出组。




    先看第一个问题,比较简单,怎样知道队列中的任务全部执行完成?

    使用GCD就很简单了,将任务放到队列组中去执行,完成后自动回调,当然也可以使用OperationQueue,那就是要使用KVO了监听OperationQueue 的maxConcurrentOperationCount属性,当为0的时候任务全部执行完成。


    第二个问题,怎样控制执行的先后顺序?如果使用OperationQueue比较容易,方法比较多,举二个例子。看参数就知道,直到ops中的任务执行完成再接着执行其他的任务,如果每个任务都有严格的顺序,那么直接设置OperationQueue的maxConcurrentOperationCount为1就行了,为1时候其实也就是串行队列了。

    func addOperations(_ ops: [Operation], waitUntilFinished wait: Bool)

    第二种方式就是添加依耐关系

    let operation1 = BlockOperation {
    debugPrint("开始1", Thread.current)
    sleep(2)
    debugPrint("完成 ")
    }
    let operation2 = BlockOperation {
    debugPrint("开始2")
    sleep(2)
    debugPrint("完成")
    }
    operation2.addDependency(operation1)
    operationQueue.addOperation(operation1)
    operationQueue.addOperation(operation2)

    如果使用GCD的话,那么就需要使用栅栏函数了,这个可以具体看看官方的文档或者网上优秀博客,这就举一个简单的列子

    /// 栅栏函数要求队列参数为. concurrent 
    let queue = DispatchQueue(label: "text.queue", attributes: .concurrent)
    queue.async {
    for i in 0 ... 10 {
    debugPrint(i , Thread.current , "------1")
    }
    }
    queue.async {
    for i in 0 ... 10 {
    debugPrint(i , Thread.current , "-----2")
    }
    }
    /// 栅栏函数,前面的执行完,再执行栅栏函数里面的代码,执行完,再执行后面的任务
    queue.async(flags: .barrier) {
    for i in 0 ... 10 {
    debugPrint(i , Thread.current , "------3")
    }
    }
    queue.async {
    for i in 0 ... 10 {
    debugPrint(i , Thread.current , "------4")
    }
    }
    queue.async {
    for i in 0 ... 10 {
    debugPrint(i , Thread.current , "------5")
    }
    }

    举的例子比较简单,遇到实际问题其实是很复杂的(强烈建议多看第三方框架,看看别人怎么封装的,多学习),考虑的问题比较多。


    第三个问题,怎样控制并发数量?问题二中已经回答了设置OperationQueue的maxConcurrentOperationCount就可以控制并发量了。GCD中的话就可以使用信号量(DispatchSemaphore)去控制并发量了,用法也很简单。信号量还有很多其他的用法,比如将异步变成同步(这种骚操作不建议去使用信号量),资源的保护等等

    let queue = DispatchQueue.global(qos:    DispatchQoS.QoSClass.background)
    /// 初始化信号量为2,最大并发为2,为0时会等待
    let semap = DispatchSemaphore.init(value: 2)
    semap.wait() // 信号量减1
    queue.async {
    debugPrint("开始执行", Thread.current)
    sleep(2)
    debugPrint("执行完成" , Thread.current)
    semap.signal() // 信号量加1
    }
    semap.wait()
    queue.async {
    debugPrint("开始执行", Thread.current)
    sleep(2)
    debugPrint("执行完成" , Thread.current)
    semap.signal()
    }
    semap.wait()
    queue.async {
    debugPrint("开始执行", Thread.current)
    sleep(2)
    debugPrint("执行完成" , Thread.current)
    semap.signal()
    }

    第四个问题,怎样暂停/挂起任务?GCD可以但是相当麻烦,OperationQueue就很简单了,可以挂起,暂停所有的任务,也可以取消所有任务,在控制任务执行上,还是很方便的。这个可以参考下Alamofire中的设计,可以避免双重回调嵌套,在此不仔细详解,大概提下Alamofire设计的思路,有个方法是json序列化的,在我们最后获取数据的回调block中,但是,调用这个方法时,是将任务放到了OperationQueue中并且设置了maxConcurrentOperationCount为1,并且设置isSuspended为true,什么时候执行呢,当后台数据返回成功时isSuspended置为false,开始执行序列化的代码,执行完后我们在回调中获取后台返回的数据,没有嵌套block。


    整个总结比较简单,只是大概说了下可能会遇到的问题,提供下简单的解决思路,解决复杂的问题,还需要再去多尝试,多去了解相关的文档,了解每一个API甚至参数使用的场景,或许用不到,但是万一在解决bug时不小心找到灵感了呢,书到用时方恨少。但是还是想强调下:线程复杂必死。



    链接:https://www.jianshu.com/p/5fb6e565ee23

    收起阅读 »

    Android面试题(五)

    Android面试题系列:Android面试题(一)Android面试题(二)Android面试题(三)Android面试题(四)Android面试题(五)76.子线程发消息到主线程进行更新 UI,除了 handler 和 AsyncTask,还有什么? 用 ...
    继续阅读 »

    Android面试题系列:


    76.子线程发消息到主线程进行更新 UI,除了 handler 和 AsyncTask,还有什么?


    用 Activity 对象的 runOnUiThread 方法更新


    在子线程中通过 runOnUiThread()方法更新 UI
    如果在非上下文类中(Activity),可以通过传递上下文实现调用;

    用 View.post(Runnable r)方法更新 UI


    77.子线程中能不能 new handler?为什么?


    不能,如果在子线程中直接 new Handler()会抛出异常 java.lang.RuntimeException: Can'tcreate handler inside thread that has not called


    在没有调用 Looper.prepare()的时候不能创建 Handler,因为在创建 Handler 的源码中做了如下操作


    Handler 的构造方法中


    78.Android 中的动画有哪几类,它们的特点和区别是什么


    Frame Animation(帧动画)主要用于播放一帧帧准备好的图片,类似GIF图片,优点是使用简单方便、缺点是需要事先准备好每一帧图片;


    Tween Animation(补间动画)仅需定义开始与结束的关键帧,而变化的中间帧由系统补上,优点是不用准备每一帧,缺点是只改变了对象绘制,而没有改变View本身属性。因此如果改变了按钮的位置,还是需要点击原来按钮所在位置才有效。


    Property Animation(属性动画)是3.0后推出的动画,优点是使用简单、降低实现的复杂度、直接更改对象的属性、几乎可适用于任何对象而仅非View类,主要包括ValueAnimator和ObjectAnimator


    79.如何修改 Activity 进入和退出动画


    可 以 通 过 两 种 方 式 , 一 是 通 过 定 义 Activity 的 主 题 , 二 是 通 过 覆 写 Activity 的overridePendingTransition 方法。


    通过设置主题样式在 styles.xml 中编辑如下代码:


    添加 themes.xml 文件: 
    AndroidManifest.xml 中给指定的 Activity 指定 theme

    覆写 overridePendingTransition 方法


    overridePendingTransition(R.anim.fade, R.anim.hold); 

    80.Android与服务器交互的方式中的对称加密和非对称加密是什么?


    对称加密,就是加密和解密数据都是使用同一个key,这方面的算法有DES。
    非对称加密,加密和解密是使用不同的key。发送数据之前要先和服务端约定生成公钥和私钥,使用公钥加密的数据可以用私钥解密,反之。这方面的算法有RSA。ssh 和 ssl都是典型的非对称加密。


    82.事件分发中的 onTouch 和 onTouchEvent 有什么区别,又该如何使用?


    这两个方法都是在 View 的 dispatchTouchEvent 中调用的,onTouch 优先于 onTouchEvent执行。如果在 onTouch 方法中通过返回 true 将事件消费掉,onTouchEvent 将不会再执行。


    另外需要注意的是,onTouch 能够得到执行需要两个前提条件,第一 mOnTouchListener 的值不能为空,第二当前点击的控件必须是 enable 的。因此如果你有一个控件是非 enable 的,那么给它注册 onTouch 事件将永远得不到执行。对于这一类控件,如果我们想要监听它的 touch 事件,就必须通过在该控件中重写 onTouchEvent 方法来实现。


    83.属性动画,例如一个 button 从 A 移动到 B 点,B 点还是可以响应点击事件,这个原理是什么?


    补间动画只是显示的位置变动,View 的实际位置未改变,表现为 View 移动到其他地方,点击事件仍在原处才能响应。而属性动画控件移动后事件相应就在控件移动后本身进行处理


    都使用过哪些自定义控件


    pull2RefreshListView
    LazyViewPager
    SlidingMenu
    SmoothProgressBar
    自定义组合控件
    ToggleButton
    自定义Toast

    84.谈谈你在工作中是怎样解决一个 bug


    异常附近多打印 log 信息;
    分析 log 日志,实在不行的话进行断点调试;
    调试不出结果,上 Stack Overflow 贴上异常信息,请教大牛
    再多看看代码,或者从源代码中查找相关信息
    实在不行就 GG 了,找师傅来解决!

    85.嵌入式操作系统内存管理有哪几种, 各有何特性


    页式,段式,段页,用到了MMU,虚拟空间等技术


    86.开发中都使用过哪些框架、平台


    EventBus(事件处理)    
    xUtils(网络、图片、ORM
    JPush(推送平台)
    友盟(统计平台)
    有米(优米)(广告平台)
    百度地图
    bmob(服务器平台、短信验证、邮箱验证、第三方支付)
    阿里云 OSS(云存储)
    ShareSDK(分享平台、第三方登录)
    Gson(解析 json 数据框架)
    imageLoader (图片处理框架)
    zxing (二维码扫描)
    anroid-asyn-http(网络通讯)
    DiskLruCache(硬盘缓存框架)
    Viatimo(多媒体播放框架)
    universal-image-loader(图片缓存框架)
    讯飞语音(语音识别)

    87.谈谈你对 Bitmap 的理解, 什么时候应该手动调用 bitmap.recycle()


    Bitmap 是 android 中经常使用的一个类,它代表了一个图片资源。 Bitmap 消耗内存很严重,如果不注意优化代码,经常会出现 OOM 问题,优化方式通常有这么几种:


    使用缓存;
    压缩图片;
    及时回收;

    至于什么时候需要手动调用 recycle,这就看具体场景了,原则是当我们不再使用 Bitmap 时,需要回收之。另外,我们需要注意,2.3 之前 Bitmap 对象与像素数据是分开存放的,Bitmap 对象存在java Heap 中而像素数据存放在 Native Memory 中, 这时很有必要调用 recycle 回收内存。 但是 2.3之后,Bitmap 对象和像素数据都是存在 Heap 中,GC 可以回收其内存。


    88.请介绍下 AsyncTask 的内部实现和适用的场景


    AsyncTask 内部也是 Handler 机制来完成的,只不过 Android 提供了执行框架来提供线程池来执行相应地任务,因为线程池的大小问题,所以 AsyncTask 只应该用来执行耗时时间较短的任务,比如 HTTP 请求,大规模的下载和数据库的更改不适用于 AsyncTask,因为会导致线程池堵塞,没有线程来执行其他的任务,导致的情形是会发生 AsyncTask 根本执行不了的问题


    89.Activity间通过Intent传递数据大小有没有限制?


    Intent在传递数据时是有大小限制的,这里官方并未详细说明,不过通过实验的方法可以测出数据应该被限制在1MB之内(1024KB),笔者采用的是传递Bitmap的方法,发现当图片大小超过1024(准确地说是1020左右)的时候,程序就会出现闪退、停止运行等异常(不同的手机反应不同),因此可以判断Intent的传输容量在1MB之内。


    90.你一般在开发项目中都使用什么设计模式?如何来重构,优化你的代码?


    较为常用的就是单例设计模式,工厂设计模式以及观察者设计模式,


    一般需要保证对象在内存中的唯一性时就是用单例模式,例如对数据库操作的 SqliteOpenHelper 的对象。


    工厂模式主要是为创建对象提供过渡接口,以便将创建对象的具体过程屏蔽隔离起来,达到提高灵活性的目的。


    观察者模式定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新


    91.Android 应用中验证码登陆都有哪些实现方案


    从服务器端获取图片
    通过短信服务,将验证码发送给客户端

    92.定位项目中,如何选取定位方案,如何平衡耗电与实时位置的精度?


    开始定位,Application 持有一个全局的公共位置对象,然后隔一定时间自动刷新位置,每次刷新成功都把新的位置信息赋值到全局的位置对象, 然后每个需要使用位置请求的地方都使用全局的位置信息进行请求。


    该方案好处:请求的时候无需再反复定位,每次请求都使用全局的位置对象,节省时间。
    该方案弊端:耗电,每隔一定时间自动刷新位置,对电量的消耗比较大。

    按需定位,每次请求前都进行定位。这样做的好处是比较省电,而且节省资源,但是请求时间会变得相对较长。


    93.andorid 应用第二次登录实现自动登录


    前置条件是所有用户相关接口都走 https,非用户相关列表类数据走 http。


    步骤


    第一次登陆 getUserInfo 里带有一个长效 token,该长效 token 用来判断用户是否登陆和换取短 token 
    把长效 token 保存到 SharedPreferences
    接口请求用长效 token 换取短token,短 token 服务端可以根据你的接口最后一次请求作为标示,超时时间为一天。
    所有接口都用短效 token
    如果返回短效 token 失效,执行第3步,再直接当前接口
    如果长效 token 失效(用户换设备或超过一月),提示用户登录。

    94.说说 LruCache 底层原理


    LruCache 使用一个 LinkedHashMap 简单的实现内存的缓存,没有软引用,都是强引用。


    如果添加的数据大于设置的最大值,就删除最先缓存的数据来调整内存。maxSize 是通过构造方法初始化的值,他表示这个缓存能缓存的最大值是多少。


    size 在添加和移除缓存都被更新值, 他通过 safeSizeOf 这个方法更新值。 safeSizeOf 默认返回 1,但一般我们会根据 maxSize 重写这个方法,比如认为 maxSize 代表是 KB 的话,那么就以 KB 为单位返回该项所占的内存大小。


    除异常外,首先会判断 size 是否超过 maxSize,如果超过了就取出最先插入的缓存,如果不为空就删掉,并把 size 减去该项所占的大小。这个操作将一直循环下去,直到 size 比 maxSize 小或者缓存为空。


    95.jni 的调用过程?


    安装和下载 Cygwin,下载 Android NDK。
    ndk 项目中 JNI 接口的设计。
    使用 C/C++实现本地方法。
    JNI 生成动态链接库.so 文件。
    将动态链接库复制到 java 工程,在 java 工程中调用,运行 java 工程即可。

    96.一条最长的短信息约占多少byte?


    中文70(包括标点),英文160,160个字节。


    98.即时通讯是是怎么做的?


    使用asmark 开源框架实现的即时通讯功能.该框架基于开源的 XMPP 即时通信协议,采用 C/S 体系结构,通过 GPRS 无线网络用 TCP 协议连接到服务器,以架设开源的Openfn'e 服务器作为即时通讯平台。


    客户端基于 Android 平台进行开发。负责初始化通信过程,进行即时通信时,由客户端负责向服务器发起创建连接请求。系统通过 GPRS 无线网络与 Internet 网络建立连接,通过服务器实现与Android 客户端的即时通信脚。


    服务器端则采用 Openfire 作为服务器。 允许多个客户端同时登录并且并发的连接到一个服务器上。服务器对每个客户端的连接进行认证,对认证通过的客户端创建会话,客户端与服务器端之间的通信就在该会话的上下文中进行。


    99.怎样对 android 进行优化?


    对 listview 的优化。
    对图片的优化。
    对内存的优化。
    具体一些措施
    尽量不要使用过多的静态类 static
    数据库使用完成后要记得关闭 cursor
    广播使用完之后要注销

    100.如果有个100M大的文件,需要上传至服务器中,而服务器form表单最大只能上传2M,可以用什么方法。


    首先来说使用http协议上传数据,特别在android下,跟form没什么关系。


    传统的在web中,在form中写文件上传,其实浏览器所做的就是将我们的数据进行解析组拼成字符串,以流的方式发送到服务器,且上传文件用的都是POST方式,POST方式对大小没什么限制。


    回到题目,可以说假设每次真的只能上传2M,那么可能我们只能把文件截断,然后分别上传了,断点上传。


    作者:零次幂
    链接:https://juejin.cn/post/6844903464024145927
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    Android面试题(四)

    Android面试题系列:Android面试题(一)Android面试题(二)Android面试题(三)Android面试题(四)Android面试题(五)50.ListView 可以显示多种类型的条目吗 这个当然可以的,ListView 显示的每个条目都是通...
    继续阅读 »

    Android面试题系列:

    50.ListView 可以显示多种类型的条目吗


    这个当然可以的,ListView 显示的每个条目都是通过 baseAdapter 的 getView(int position,View convertView, ViewGroup parent)来展示的,理论上我们完全可以让每个条目都是不同类型的view。


    比如:从服务器拿回一个标识为 id=1,那么当 id=1 的时候,我们就加载类型一的条目,当 id=2的时候,加载类型二的条目。常见布局在资讯类客户端中可以经常看到。


    除此之外 adapter 还提供了 getViewTypeCount()和 getItemViewType(int position)两个方法。在 getView 方法中我们可以根据不同的 viewtype 加载不同的布局文件。


    51.ListView 如何定位到指定位置


    可以通过 ListView 提供的 lv.setSelection(listView.getPosition())方法。


    52.如何在 ScrollView 中如何嵌入 ListView


    通常情况下我们不会在 ScrollView 中嵌套 ListView。


    在 ScrollView 添加一个 ListView 会导致 listview 控件显示不全,通常只会显示一条,这是因为两个控件的滚动事件冲突导致。所以需要通过 listview 中的 item 数量去计算 listview 的显示高度,从而使其完整展示。


    现阶段最好的处理的方式是: 自定义 ListView,重载 onMeasure()方法,设置全部显示。


    53.Manifest.xml文件中主要包括哪些信息?


    manifest:根节点,描述了package中所有的内容。
    uses-permission:请求你的package正常运作所需赋予的安全许可。
    permission: 声明了安全许可来限制哪些程序能你package中的组件和功能。
    instrumentation:声明了用来测试此package或其他package指令组件的代码。
    application:包含package中application级别组件声明的根节点。
    activity:Activity是用来与用户交互的主要工具。
    receiver:IntentReceiver能使的application获得数据的改变或者发生的操作,即使它当前不在运行。
    service:Service是能在后台运行任意时间的组件。
    provider:ContentProvider是用来管理持久化数据并发布给其他应用程序使用的组件。复制代码

    54.ListView 中图片错位的问题是如何产生的


    图片错位问题的本质源于我们的 listview 使用了缓存 convertView, 假设一种场景, 一个 listview一屏显示九个 item,那么在拉出第十个 item 的时候,事实上该 item 是重复使用了第一个 item,也就是说在第一个 item 从网络中下载图片并最终要显示的时候,其实该 item 已经不在当前显示区域内了,此时显示的后果将可能在第十个 item 上输出图像,这就导致了图片错位的问题。所以解决办法就是可见则显示,不可见则不显示。


    55.Fragment 的 replace 和 add 方法的区别


    Fragment 本身并没有 replace 和 add 方法,FragmentManager才有replace和add方法。我们经常使用的一个架构就是通过RadioGroup切换Fragment,每个 Fragment 就是一个功能模块。


    Fragment 的容器一个 FrameLayout,add 的时候是把所有的 Fragment 一层一层的叠加到了。FrameLayout 上了,而 replace 的话首先将该容器中的其他 Fragment 去除掉然后将当前Fragment添加到容器中。


    一个 Fragment 容器中只能添加一个 Fragment 种类,如果多次添加则会报异常,导致程序终止,而 replace 则无所谓,随便切换。因为通过 add 的方法添加的 Fragment,每个 Fragment 只能添加一次,因此如果要想达到切换效果需要通过 Fragment 的的 hide 和 show 方法结合者使用。将要显示的 show 出来,将其他 hide起来。这个过程 Fragment 的生命周期没有变化。


    通过 replace 切换 Fragment,每次都会执行上一个 Fragment 的 onDestroyView,新 Fragment的 onCreateView、onStart、onResume 方法。基于以上不同的特点我们在使用的使用一定要结合着生命周期操作我们的视图和数据。


    56.Fragment 如何实现类似 Activity 栈的压栈和出栈效果的?


    Fragment 的事物管理器内部维持了一个双向链表结构,该结构可以记录我们每次 add 的Fragment 和 replace 的 Fragment,然后当我们点击 back 按钮的时候会自动帮我们实现退栈操作。


    57.Fragment 在你们项目中的使用


    Fragment 是 android3.0 以后引入的的概念,做局部内容更新更方便,原来为了到达这一点要把多个布局放到一个 activity 里面,现在可以用多 Fragment 来代替,只有在需要的时候才加载Fragment,提高性能。


    Fragment 的好处:


    Fragment 可以使你能够将 activity 分离成多个可重用的组件,每个都有它自己的生命周期和UI。
    Fragment 可以轻松得创建动态灵活的 UI 设计,可以适应于不同的屏幕尺寸。从手机到平板电脑。
    Fragment 是一个独立的模块,紧紧地与 activity 绑定在一起。可以运行中动态地移除、加入、交换等。
    Fragment 提供一个新的方式让你在不同的安卓设备上统一你的 UI。
    Fragment 解决 Activity 间的切换不流畅,轻量切换。
    Fragment 替代 TabActivity 做导航,性能更好。
    Fragment 在 4.2.版本中新增嵌套 fragment 使用方法,能够生成更好的界面效果。复制代码

    58.如何切换 fragement,不重新实例化


    翻看了 Android 官方 Doc,和一些组件的源代码,发现 replace()这个方法只是在上一个 Fragment不再需要时采用的简便方法.


    正确的切换方式是 add(),切换时 hide(),add()另一个 Fragment;再次切换时,只需 hide()当前,show()另一个。


    这样就能做到多个 Fragment 切换不重新实例化:


    59.如何对 Android 应用进行性能分析


    如果不考虑使用其他第三方性能分析工具的话,我们可以直接使用 ddms 中的工具,其实 ddms 工具已经非常的强大了。ddms 中有 traceview、heap、allocation tracker 等工具都可以帮助我们分析应用的方法执行时间效率和内存使用情况。


    Traceview 是 Android 平台特有的数据采集和分析工具,它主要用于分析 Android 中应用程序的 hotspot(瓶颈)。Traceview 本身只是一个数据分析工具,而数据的采集则需要使用 AndroidSDK 中的 Debug 类或者利用 DDMS 工具。


    heap 工具可以帮助我们检查代码中是否存在会造成内存泄漏的地方。


    allocation tracker 是内存分配跟踪工具


    60.Android 中如何捕获未捕获的异常


    UncaughtExceptionHandler


    自 定 义 一 个 Application , 比 如 叫 MyApplication 继 承 Application 实 现UncaughtExceptionHandler。
    覆写 UncaughtExceptionHandler 的 onCreate 和 uncaughtException 方法。 注意:上面的代码只是简单的将异常打印出来。在 onCreate 方法中我们给 Thread 类设置默认异常处理 handler,如果这句代码不执行则一切都是白搭。在 uncaughtException 方法中我们必须新开辟个线程进行我们异常的收集工作,然后将系统给杀死。
    在 AndroidManifest 中配置该 Application:

    Bug 收集工具 Crashlytics


    Crashlytics 是专门为移动应用开发者提供的保存和分析应用崩溃的工具。国内主要使用的是友盟做数据统计。
    Crashlytics 的好处:
    1.Crashlytics 不会漏掉任何应用崩溃信息。
    2.Crashlytics 可以象 Bug 管理工具那样,管理这些崩溃日志。
    3.Crashlytics 可以每天和每周将崩溃信息汇总发到你的邮箱,所有信息一目了然。复制代码

    61.如何将SQLite数据库(dictionary.db文件)与apk文件一起发布


    把这个文件放在/res/raw目录下即可。res\raw目录中的文件不会被压缩,这样可以直接提取该目录中的文件,会生成资源id。


    62.什么是 IntentService?有何优点?


    IntentService 是 Service 的子类,比普通的 Service 增加了额外的功能。先看 Service 本身存在两个问题:


    Service 不会专门启动一条单独的进程,Service 与它所在应用位于同一个进程中;
    Service 也不是专门一条新线程,因此不应该在 Service 中直接处理耗时的任务;复制代码

    IntentService 特征


    会创建独立的 worker 线程来处理所有的 Intent 请求;
    会创建独立的 worker 线程来处理 onHandleIntent()方法实现的代码,无需处理多线程问题;
    所有请求处理完成后,IntentService 会自动停止,无需调用 stopSelf()方法停止 Service
    ServiceonBind()提供默认实现,返回 null
    ServiceonStartCommand 提供默认实现,将请求 Intent 添加到队列中;复制代码

    63.谈谈对Android NDK的理解


    NDK是一系列工具的集合.NDK提供了一系列的工具,帮助开发者快速开发C或C++的动态库,并能自动将so和java应用一起打包成apk.这些工具对开发者的帮助是巨大的.NDK集成了交叉编译器,并提供了相应的mk文件隔离CPU,平台,ABI等差异,开发人员只需要简单修改 mk文件(指出"哪些文件需要编译","编译特性要求"等),就可以创建出so.


    NDK可以自动地将so和Java应用一起打包,极大地减轻了开发人员的打包工作.NDK提供了一份稳定,功能有限的API头文件声明.


    Google明确声明该API是稳定的,在后续所有版本中都稳定支持当前发布的API.从该版本的NDK中看出,这些 API支持的功能非常有限,包含有:C标准库(libc),标准数学库(libm ),压缩库(libz),Log库(liblog).


    64.AsyncTask使用在哪些场景?它的缺陷是什么?如何解决?


    AsyncTask 运用的场景就是我们需要进行一些耗时的操作,耗时操作完成后更新主线程,或者在操作过程中对主线程的UI进行更新。


    缺陷:AsyncTask中维护着一个长度为128的线程池,同时可以执行5个工作线程,还有一个缓冲队列,当线程池中已有128个线程,缓冲队列已满时,如果 此时向线程提交任务,将会抛出RejectedExecutionException。


    解决:由一个控制线程来处理AsyncTask的调用判断线程池是否满了,如果满了则线程睡眠否则请求AsyncTask继续处理。


    65.Android 线程间通信有哪几种方式(重要)


    共享内存(变量);
    文件,数据库;
    Handler
    Java 里的 wait(),notify(),notifyAll()复制代码

    66.请解释下 Android 程序运行时权限与文件系统权限的区别?


    apk 程序是运行在虚拟机上的,对应的是 Android 独特的权限机制,只有体现到文件系统上时才


    使用 linux 的权限设置。


    linux 文件系统上的权限
    -rwxr-x--x system system 4156 2010-04-30 16:13 test.apk
    代表的是相应的用户/用户组及其他人对此文件的访问权限,与此文件运行起来具有的权限完全不相关。比如上面的例子只能说明 system 用户拥有对此文件的读写执行权限;system 组的用户对此文件拥有读、执行权限;其他人对此文件只具有执行权限。而 test.apk 运行起来后可以干哪些事情,跟这个就不相关了。千万不要看 apk 文件系统上属于 system/system 用户及用户组,或者root/root 用户及用户组,就认为 apk 具有 system 或 root 权限复制代码

    Android 的权限规则


    Android 中的 apk 必须签名
    基于 UserID 的进程级别的安全机制
    默认 apk 生成的数据对外是不可见的
    AndroidManifest.xml 中的显式权限声明复制代码

    67.Framework 工作方式及原理,Activity 是如何生成一个 view 的,机制是什么?


    所有的框架都是基于反射 和 配置文件(manifest)的。


    普通的情况:


    Activity 创建一个 view 是通过 ondraw 画出来的, 画这个 view 之前呢,还会调用 onmeasure方法来计算显示的大小.复制代码

    特殊情况:


    Surfaceview 是直接操作硬件的,因为 或者视频播放对帧数有要求,onDraw 效率太低,不够使,Surfaceview 直接把数据写到显存。复制代码

    68.什么是 AIDL?如何使用?


    aidl 是 Android interface definition Language 的英文缩写,意思 Android 接口定义语言。


    使用 aidl 可以帮助我们发布以及调用远程服务,实现跨进程通信。


    将服务的 aidl 放到对应的 src 目录,工程的 gen 目录会生成相应的接口类
    我们通过 bindService(Intent,ServiceConnect,int)方法绑定远程服务,在 bindService中 有 一 个 ServiceConnec 接 口 , 我 们 需 要 覆 写 该 类 的onServiceConnected(ComponentName,IBinder)方法,这个方法的第二个参数 IBinder 对象其实就是已经在 aidl 中定义的接口,因此我们可以将 IBinder 对象强制转换为 aidl 中的接口类。我们通过 IBinder 获取到的对象(也就是 aidl 文件生成的接口)其实是系统产生的代理对象,该代理对象既可以跟我们的进程通信, 又可以跟远程进程通信, 作为一个中间的角色实现了进程间通信。复制代码

    69.AIDL 的全称是什么?如何工作?能处理哪些类型的数据?


    AIDL 全称 Android Interface Definition Language(AndRoid 接口描述语言) 是一种接口描述语言; 编译器可以通过 aidl 文件生成一段代码,通过预先定义的接口达到两个进程内部通信进程跨界对象访问的目的。需要完成两件事情:


    引入 AIDL 的相关类.; 
    调用 aidl 产生的 class复制代码

    理论上, 参数可以传递基本数据类型和 String, 还有就是 Bundle 的派生类, 不过在 Eclipse 中,目前的 ADT 不支持 Bundle 做为参数。


    70.Android 判断SD卡是否存在


    首先要在AndroidManifest.xml中增加SD卡访问权限


    71.Android中任务栈的分配


    Task实际上是一个Activity栈,通常用户感受的一个Application就是一个Task。从这个定义来看,Task跟Service或者其他Components是没有任何联系的,它只是针对Activity而言的。


    Activity有不同的启动模式, 可以影响到task的分配


    72.SQLite支持事务吗? 添加删除如何提高性能?


    在sqlite插入数据的时候默认一条语句就是一个事务,有多少条数据就有多少次磁盘操作 比如5000条记录也就是要5000次读写磁盘操作。


    添加事务处理,把多条记录的插入或者删除作为一个事务


    73.Android中touch事件的传递机制是怎样的?


    1.Touch事件传递的相关API有dispatchTouchEvent、onTouchEvent、onInterceptTouchEvent 
    2.Touch事件相关的类有View、ViewGroup、Activity
    3.Touch事件会被封装成MotionEvent对象,该对象封装了手势按下、移动、松开等动作
    4.Touch事件通常从Activity#dispatchTouchEvent发出,只要没有被消费,会一直往下传递,到最底层的View。
    5.如果Touch事件传递到的每个View都不消费事件,那么Touch事件会反向向上传递,最终交由Activity#onTouchEvent处理.
    6.onInterceptTouchEvent为ViewGroup特有,可以拦截事件.
    7.Down事件到来时,如果一个View没有消费该事件,那么后续的MOVE/UP事件都不会再给它复制代码

    74.描述下Handler 机制


    1)Looper: 一个线程可以产生一个Looper对象,由它来管理此线程里的MessageQueue(消息队列)。 
    2)Handler: 你可以构造Handler对象来与Looper沟通,以便push新消息到MessageQueue里;或者接收Looper从Message Queue取出)所送来的消息。
    3) Message Queue(消息队列):用来存放线程放入的消息。
    4)线程:UIthread 通常就是main thread,而Android启动程序时会替它建立一个MessageQueue。复制代码

    Hander持有对UI主线程消息队列MessageQueue和消息循环Looper的引用,子线程可以通过Handler将消息发送到UI线程的消息队列MessageQueue中。


    75.自定义view的基本流程


    自定义View的属性 编写attr.xml文件 
    layout布局文件中引用,同时引用命名空间
    View的构造方法中获得我们自定义的属性 ,在自定义控件中进行读取(构造方法拿到attr.xml文件值)
    重写onMesure
    重写onDraw复制代码


    作者:零次幂
    链接:https://juejin.cn/post/6844903464024145927
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    Android面试题(三)

    Android面试题系列:Android面试题(一)Android面试题(二)Android面试题(三)Android面试题(四)Android面试题(五)21.sim卡的EF 文件有何作用 sim卡就是电话卡,sim卡内有自己的操作系统,用来与手机通讯的。E...
    继续阅读 »

    Android面试题系列:

    21.sim卡的EF 文件有何作用


    sim卡就是电话卡,sim卡内有自己的操作系统,用来与手机通讯的。Ef文件用来存储数据的。


    22.Activity的状态有几种?


    运行
    暂停
    停止

    23.让Activity变成一个窗口


    设置activity的style属性=”@android:style/Theme.Dialog”


    24.android:gravity与android:layout_gravity的区别


    gravity:表示组件内元素的对齐方式
    layout_gravity:相对于父类容器,该视图组件的对齐方式


    25.如何退出Activity


    结束当前activity


    Finish()
    killProgress()
    System.exit(0)

    关闭应用程序时,结束所有的activity


    可以创建一个List集合,每新创建一个activity,将该activity的实例放进list中,程序结束时,从集合中取出循环取出activity实例,调用finish()方法结束


    26.如果后台的Activity由于某原因被系统回收了,如何在被系统回收之前保存当前状态?


    在onPuase方法中调用onSavedInstanceState()


    27.Android中的长度单位详解


    Px:像素
    Sp与dp也是长度单位,但是与屏幕的单位密度无关。

    28.activity,service,intent之间的关系


    这三个都是android应用频率非常的组件。Activity与service是四大核心组件。Activity用来加载布局,显示窗口界面,service运行后台,没有界面显示,intent是activity与service的通信使者。


    29.activity之间传递参数,除了intent,广播接收器,contentProvider之外,还有那些方法?


    Fie:文件存储,推荐使用sharedPreferecnces
    静态变量。

    30.Adapter是什么?你所接触过的adapter有那些?


    是适配器,用来为列表提供数据适配的。经常使用的adapter有baseadapter,arrayAdapter,SimpleAdapter,cursorAdapter,SpinnerAdapter等


    31.Fragment与activity如何传值和交互?


    Fragment对象有一个getActivity的方法,通过该方法与activity交互
    使用framentmentManager.findFragmentByXX可以获取fragment对象,在activity中直接操作fragment对象

    32.如果Listview中的数据源发生改变,如何更新listview中的数据


    使用adapter的notifyDataSetChanged方法


    33.广播接受者的生命周期?


    广播接收者的生命周期非常短。当执行onRecieve方法之后,广播就会销毁
    在广播接受者不能进行耗时较长的操作
    在广播接收者不要创建子线程。广播接收者完成操作后,所在进程会变成空进程,很容易被系统回收

    34.ContentProvider与sqlite有什么不一样的?


    ContentProvider会对外隐藏内部实现,只需要关注访问contentProvider的uri即可,contentProvider应用在应用间共享。
    Sqlite操作本应用程序的数据库。
    ContentProiver可以对本地文件进行增删改查操作

    35.如何保存activity的状态?


    默认情况下activity的状态系统会自动保存,有些时候需要我们手动调用保存。


    当activity处于onPause,onStop之后,activity处于未活动状态,但是activity对象却仍然存在。当内存不足,onPause,onStop之后的activity可能会被系统摧毁。


    当通过返回退出activity时,activity状态并不会保存。


    保存activity状态需要重写onSavedInstanceState()方法,在执行onPause,onStop之前调用onSavedInstanceState方法,onSavedInstanceState需要一个Bundle类型的参数,我们可以将数据保存到bundle中,通过实参传递给onSavedInstanceState方法。


    Activity被销毁后,重新启动时,在onCreate方法中,接受保存的bundle参数,并将之前的数据取出。


    36.Android中activity,context,application有什么不同。


    Content与application都继承与contextWrapper,contextWrapper继承于Context类。


    Context:表示当前上下文对象,保存的是上下文中的参数和变量,它可以让更加方便访问到一些资源。


    Context通常与activity的生命周期是一样的,application表示整个应用程序的对象。


    对于一些生命周期较长的,不要使用context,可以使用application。


    在activity中,尽量使用静态内部类,不要使用内部类。内部里作为外部类的成员存在,不是独立于activity,如果内存中还有内存继续引用到context,activity如果被销毁,context还不会结束。


    37.Service 是否在 main thread 中执行, service 里面是否能执行耗时的操作?


    默认情况service在main thread中执行,当service在主线程中运行,那在service中不要进行一些比较耗时的操作,比如说网络连接,文件拷贝等。


    38.Service 和 Activity 在同一个线程吗


    默认情况下service与activity在同一个线程,都在main Thread,或者ui线程中。


    如果在清单文件中指定service的process属性,那么service就在另一个进程中运行。


    39.Service 里面可以弹吐司么


    可以。


    40.在 service 的生命周期方法 onstartConmand()可不可以执行网络操作?如何在 service 中执行网络操作?


    可以的,就在onstartConmand方法内执行。


    41.说说 ContentProvider、ContentResolver、ContentObserver 之间的关系


    ContentProvider:内容提供者,对外提供数据的操作,contentProvider.notifyChanged(uir):可以更新数据
    contentResolver:内容解析者,解析ContentProvider返回的数据
    ContentObServer:内容监听者,监听数据的改变,contentResolver.registerContentObServer()

    42.请介绍下 ContentProvider 是如何实现数据共享的


    ContentProvider是一个对外提供数据的接口,首先需要实现ContentProvider这个接口,然后重写query,insert,getType,delete,update方法,最后在清单文件定义contentProvider的访问uri


    43.Intent 传递数据时,可以传递哪些类型数据?


    基本数据类型以及对应的数组类型
    可以传递bundle类型,但是bundle类型的数据需要实现Serializable或者parcelable接口

    44.Serializable 和 Parcelable 的区别?


    如果存储在内存中,推荐使用parcelable,使用serialiable在序列化的时候会产生大量的临时变量,会引起频繁的GC


    如果存储在硬盘上,推荐使用Serializable,虽然serializable效率较低


    Serializable的实现:只需要实现Serializable接口,就会自动生成一个序列化id


    Parcelable的实现:需要实现Parcelable接口,还需要Parcelable.CREATER变量


    45.请描述一下 Intent 和 IntentFilter


    Intent是组件的通讯使者,可以在组件间传递消息和数据。
    IntentFilter是intent的筛选器,可以对intent的action,data,catgory,uri这些属性进行筛选,确定符合的目标组件。

    46.什么是IntentService?有何优点?


    IntentService 是 Service 的子类,比普通的 Service 增加了额外的功能。先看 Service 本身存在两个问题:


    Service 不会专门启动一条单独的进程,Service 与它所在应用位于同一个进程中;
    Service 也不是专门一条新线程,因此不应该在 Service 中直接处理耗时的任务;

    特征


    会创建独立的 worker 线程来处理所有的 Intent 请求;
    会创建独立的 worker 线程来处理 onHandleIntent()方法实现的代码,无需处理多线程问题;
    所有请求处理完成后,IntentService 会自动停止,无需调用 stopSelf()方法停止 Service
    ServiceonBind()提供默认实现,返回 null
    ServiceonStartCommand 提供默认实现,将请求 Intent 添加到队列中

    使用


    让service类继承IntentService,重写onStartCommand和onHandleIntent实现 

    47.Android 引入广播机制的用意


    从 MVC 的角度考虑(应用程序内) 其实回答这个问题的时候还可以这样问,android 为什么要有那 4 大组件,现在的移动开发模型基本上也是照搬的 web 那一套 MVC 架构,只不过稍微做了修改。android 的四大组件本质上就是为了实现移动或者说嵌入式设备上的 MVC 架构,它们之间有时候是一种相互依存的关系,有时候又是一种补充关系,引入广播机制可以方便几大组件的信息和数据交互。


    程序间互通消息(例如在自己的应用程序内监听系统来电)


    效率上(参考 UDP 的广播协议在局域网的方便性)


    设计模式上(反转控制的一种应用,类似监听者模式)


    48.ListView 如何提高其效率?


    当 convertView 为空时,用 setTag()方法为每个 View 绑定一个存放控件的 ViewHolder 对象。当convertView 不为空, 重复利用已经创建的 view 的时候, 使用 getTag()方法获取绑定的 ViewHolder对象,这样就避免了 findViewById 对控件的层层查询,而是快速定位到控件。 复用 ConvertView,使用历史的 view,提升效率 200%


    自定义静态类 ViewHolder,减少 findViewById 的次数。提升效率 50%


    异步加载数据,分页加载数据。


    使用 WeakRefrence 引用 ImageView 对象


    49.ListView 如何实现分页加载


    设置 ListView 的滚动监听器:setOnScrollListener(new OnScrollListener{….})在监听器中有两个方法: 滚动状态发生变化的方法(onScrollStateChanged)和 listView 被滚动时调用的方法(onScroll)


    在滚动状态发生改变的方法中,有三种状态:手指按下移动的状态: SCROLL_STATE_TOUCH_SCROLL:触摸滑动,惯性滚动(滑翔(flgin)状态): SCROLL_STATE_FLING: 滑翔,静止状态: SCROLL_STATE_IDLE: // 静止,对不同的状态进行处理:


    分批加载数据,只关心静止状态:关心最后一个可见的条目,如果最后一个可见条目就是数据适配器(集合)里的最后一个,此时可加载更多的数据。在每次加载的时候,计算出滚动的数量,当滚动的数量大于等于总数量的时候,可以提示用户无更多数据了。



    作者:零次幂
    链接:https://juejin.cn/post/6844903464024145927
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    Android面试题(二)

    Android面试题系列:Android面试题(一)Android面试题(二)Android面试题(三)Android面试题(四)Android面试题(五)11.广播注册 首先写一个类要继承BroadCastReceiver 第一种:在清单文件中声明,添加 ...
    继续阅读 »

    Android面试题系列:

    11.广播注册


    首先写一个类要继承BroadCastReceiver


    第一种:在清单文件中声明,添加






    第二种:使用代码进行注册如:


    IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
    BroadCastReceiverDemo receiver = new BroadCastReceiver();
    registerReceiver(receiver, filter);

    两种注册类型的区别是:
    a.第一种是常驻型广播,也就是说当应用程序关闭后,如果有信息广播来,程序也会被系统调用自动运行。
    b.第二种不是常驻广播,也就是说广播跟随程序的生命周期。


    12.Android中的ANR


    ANR的全称application not responding 应用程序未响应。


    在android中Activity的最长执行时间是5秒。
    BroadcastReceiver的最长执行时间则是10秒。
    Service的最长执行时间则是20秒。

    超出执行时间就会产生ANR。注意:ANR是系统抛出的异常,程序是捕捉不了这个异常的。


    解决方法:



    1. 运行在主线程里的任何方法都尽可能少做事情。特别是,Activity应该在它的关键生命周期方法 (如onCreate()和onResume())里尽可能少的去做创建操作。(可以采用重新开启子线程的方式,然后使用Handler+Message 的方式做一些操作,比如更新主线程中的ui等)

    2. 应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务(因为 BroadcastReceiver的生命周期短),替代的是,如果响应Intent广播需要执行一个耗时的动作的话,应用程序应该启动一个 Service。


    13.ListView优化



    1. convertView重用,利用好 convertView 来重用 View,切忌每次 getView() 都新建。ListView 的核心原理就是重用 View,如果重用 view 不改变宽高,重用View可以减少重新分配缓存造成的内存频繁分配/回收;

    2. ViewHolder优化,使用ViewHolder的原因是findViewById方法耗时较大,如果控件个数过多,会严重影响性能,而使用ViewHolder主要是为了可以省去这个时间。通过setTag,getTag直接获取View。

    3. 减少Item View的布局层级,这是所有layout都必须遵循的,布局层级过深会直接导致View的测量与绘制浪费大量的时间。

    4. adapter中的getView方法尽量少使用逻辑

    5. 图片加载采用三级缓存,避免每次都要重新加载。

    6. 尝试开启硬件加速来使ListView的滑动更加流畅。

    7. 使用 RecycleView 代替。


    14.Android数字签名



    1. 所有的应用程序都必须有数字证书,Android系统不会安装一个没有数字证书的应用程序

    2. Android程序包使用的数字证书可以是自签名的,不需要一个权威的数字证书机构签名认证

    3. 如果要正式发布一个Android ,必须使用一个合适的私钥生成的数字证书来给程序签名。

    4. 数字证书都是有有效期的,Android只是在应用程序安装的时候才会检查证书的有效期。如果程序已经安装在系统中,即使证书过期也不会影响程序的正常功能。


    15.Android root机制


    root指的是你有权限可以再系统上对所有档案有 "读" "写" "执行"的权力。root机器不是真正能让你的应用程序具有root权限。它原理就跟linux下的像sudo这样的命令。在系统的bin目录下放个su程序并属主是root并有suid权限。则通过su执行的命令都具有Android root权限。当然使用临时用户权限想把su拷贝的/system/bin目录并改属性并不是一件容易的事情。这里用到2个工具跟2个命令。把busybox拷贝到你有权限访问的目录然后给他赋予4755权限,你就可以用它做很多事了。


    16.View、surfaceView、GLSurfaceView


    View


    显示视图,内置画布,提供图形绘制函数、触屏事件、按键事件函数等,必须在UI主线程内更新画面,速度较慢


    SurfaceView


    基于view视图进行拓展的视图类,更适合2D游戏的开发,是view的子类,类似使用双缓机制,在新的线程中更新画面所以刷新界面速度比view快


    GLSurfaceView


    基于SurfaceView视图再次进行拓展的视图类,专用于3D游戏开发的视图,是surfaceView的子类,openGL专用


    AsyncTask


    AsyncTask的三个泛型参数说明



    1. 第一个参数:传入doInBackground()方法的参数类型

    2. 第二个参数:传入onProgressUpdate()方法的参数类型

    3. 第三个参数:传入onPostExecute()方法的参数类型,也是doInBackground()方法返回的类型


    运行在主线程的方法:


    onPostExecute()
    onPreExecute()
    onProgressUpdate(Progress...)

    运行在子线程的方法:


    doInBackground() 

    控制AsyncTask停止的方法:


    cancel(boolean mayInterruptIfRunning) 

    AsyncTask的执行分为四个步骤



    1. 继承AsyncTask。

    2. 实现AsyncTask中定义的下面一个或几个方法onPreExecute()、doInBackground(Params...)、onProgressUpdate(Progress...)、onPostExecute(Result)。

    3. 调用execute方法必须在UI thread中调用。

    4. 该task只能被执行一次,否则多次调用时将会出现异常,取消任务可调用cancel。


    17.Android i18n


    I18n 叫做国际化。android 对i18n和L10n提供了非常好的支持。软件在res/vales 以及 其他带有语言修饰符的文件夹。如: values-zh 这些文件夹中 提供语言,样式,尺寸 xml 资源。


    18.NDK



    1. NDK是一系列工具集合,NDK提供了一系列的工具,帮助开发者迅速的开发C/C++的动态库,并能自动将so和Java应用打成apk包。

    2. NDK集成了交叉编译器,并提供了相应的mk文件和隔离cpu、平台等的差异,开发人员只需要简单的修改mk文件就可以创建出so文件。


    19.启动一个程序,可以主界面点击图标进入,也可以从一个程序中跳转过去,二者有什么区别?


    通过主界面进入,就是设置默认启动的activity。在manifest.xml文件的activity标签中,写以下代码





    从另一个组件跳转到目标activity,需要通过intent进行跳转。具体


    Intent intent=new Intent(this,activity.class),startActivity(intent) 


    作者:零次幂
    链接:https://juejin.cn/post/6844903464024145927
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    Android面试题(一)

    Android面试题系列:Android面试题(一)Android面试题(二)Android面试题(三)Android面试题(四)Android面试题(五)Android是一种基于Linux的自由及开放源代码的操作系统,主要使用于移动设备,如智能手机和平板电脑...
    继续阅读 »

    Android面试题系列:

    Android是一种基于Linux的自由及开放源代码的操作系统,主要使用于移动设备,如智能手机和平板电脑,由Google公司和开放手机联盟领导及开发。这里会不断收集和更新Android基础相关的面试题,目前已收集100题。

    1.Android系统的架构

    1. Android系统架构之应用程序
      Android会同一系列核心应用程序包一起发布,该应用程序包包括email客户端,SMS短消息程序,日历,地图,浏览器,联系人管理程序等。所有的应用程序都是使用JAVA语言编写的。
    2. Android系统架构之应用程序框架
      开发人员可以完全访问核心应用程序所使用的API框架(android.jar)。该应用程序的架构设计简化了组件的重用;任何一个应用程序都可以发布它的功能块并且任何其它的应用程序都可以使用其所发布的功能块。
    3. Android系统架构之系统运行库
      Android 包含一些C/C++库,这些库能被Android系统中不同的组件使用。它们通过 Android 应用程序框架为开发者提供服务。
    4. Android系统架构之Linux 内核
      Android 的核心系统服务依赖于 Linux 2.6 内核,如安全性,内存管理,进程管理, 网络协议栈和驱动模型。 Linux 内核也同时作为硬件和软件栈之间的抽象层。

    2.activity的生命周期

    Activity生命周期方法主要有onCreate()、onStart()、onResume()、onPause()、onStop()、onDestroy()和onRestart()等7个方法。

    • 启动一个A Activity,分别执行onCreate()、onStart()、onResume()方法。
    • 从A Activity打开B Activity分别执行A onPause()、B onCreate()、B onStart()、B onResume()、A onStop()方法。
    • 关闭B Activity,分别执行B onPause()、A onRestart()、A onStart()、A onResume()、B onStop()、B onDestroy()方法。
    • 横竖屏切换A Activity,清单文件中不设置android:configChanges属性时,先销毁onPause()、onStop()、onDestroy()再重新创建onCreate()、onStart()、onResume()方法,设置orientation|screenSize(一定要同时出现)属性值时,不走生命周期方法,只会执行onConfigurationChanged()方法。
    • Activity之间的切换可以看出onPause()、onStop()这两个方法比较特殊,切换的时候onPause()方法不要加入太多耗时操作否则会影响体验。

    3.Fragment的生命周期

    Fragment的生命周期

    Fragment与Activity生命周期对比

    Fragment的生命周期方法主要有onAttach()、onCreate()、onCreateView()、onActivityCreated()、onstart()、onResume()、onPause()、onStop()、onDestroyView()、onDestroy()、onDetach()等11个方法。

    • 切换到该Fragment,分别执行onAttach()、onCreate()、onCreateView()、onActivityCreated()、onstart()、onResume()方法。
    • 锁屏,分别执行onPause()、onStop()方法。
    • 亮屏,分别执行onstart()、onResume()方法。
    • 覆盖,切换到其他Fragment,分别执行onPause()、onStop()、onDestroyView()方法。
    • 从其他Fragment回到之前Fragment,分别执行onCreateView()、onActivityCreated()、onstart()、onResume()方法。

    4.Service生命周期

    在Service的生命周期里,常用的有:

    4个手动调用的方法

    startService()    启动服务
    stopService() 关闭服务
    bindService() 绑定服务
    unbindService() 解绑服务

    5个内部自动调用的方法

    onCreat()            创建服务
    onStartCommand() 开始服务
    onDestroy() 销毁服务
    onBind() 绑定服务
    onUnbind() 解绑服务
    1. 手动调用startService()启动服务,自动调用内部方法:onCreate()、onStartCommand(),如果一个Service被startService()多次启动,那么onCreate()也只会调用一次。
    2. 手动调用stopService()关闭服务,自动调用内部方法:onDestory(),如果一个Service被启动且被绑定,如果在没有解绑的前提下使用stopService()关闭服务是无法停止服务的。
    3. 手动调用bindService()后,自动调用内部方法:onCreate()、onBind()。
    4. 手动调用unbindService()后,自动调用内部方法:onUnbind()、onDestory()。
    5. startService()和stopService()只能开启和关闭Service,无法操作Service,调用者退出后Service仍然存在;bindService()和unbindService()可以操作Service,调用者退出后,Service随着调用者销毁。

    5.Android中动画

    Android中动画分别帧动画、补间动画和属性动画(Android 3.0以后的)

    帧动画

    帧动画是最容易实现的一种动画,这种动画更多的依赖于完善的UI资源,他的原理就是将一张张单独的图片连贯的进行播放,从而在视觉上产生一种动画的效果;有点类似于某些软件制作gif动画的方式。在有些代码中,我们还会看到android:oneshot="false" ,这个oneshot 的含义就是动画执行一次(true)还是循环执行多次。






    补间动画

    补间动画又可以分为四种形式,分别是 alpha(淡入淡出),translate(位移),scale(缩放大小),rotate(旋转)。
    补间动画的实现,一般会采用xml 文件的形式;代码会更容易书写和阅读,同时也更容易复用。Interpolator 主要作用是可以控制动画的变化速率 ,就是动画进行的快慢节奏。pivot 决定了当前动画执行的参考位置








    ...

    属性动画

    属性动画,顾名思义它是对于对象属性的动画。因此,所有补间动画的内容,都可以通过属性动画实现。属性动画的运行机制是通过不断地对值进行操作来实现的,而初始值和结束值之间的动画过渡就是由ValueAnimator这个类来负责计算的。它的内部使用一种时间循环的机制来计算值与值之间的动画过渡,我们只需要将初始值和结束值提供给ValueAnimator,并且告诉它动画所需运行的时长,那么ValueAnimator就会自动帮我们完成从初始值平滑地过渡到结束值这样的效果。除此之外,ValueAnimator还负责管理动画的播放次数、播放模式、以及对动画设置监听器等。

    6.Android中4大组件

    1. Activity:Activity是Android程序与用户交互的窗口,是Android构造块中最基本的一种,它需要为保持各界面的状态,做很多持久化的事情,妥善管理生命周期以及一些跳转逻辑。
    2. BroadCast Receiver:接受一种或者多种Intent作触发事件,接受相关消息,做一些简单处理,转换成一条Notification,统一了Android的事件广播模型。
    3. Content Provider:是Android提供的第三方应用数据的访问方案,可以派生Content Provider类,对外提供数据,可以像数据库一样进行选择排序,屏蔽内部数据的存储细节,向外提供统一的接口模型,大大简化上层应用,对数据的整合提 供了更方便的途径。
    4. service:后台服务于Activity,封装有一个完整的功能逻辑实现,接受上层指令,完成相关的事务,定义好需要接受的Intent提供同步和异步的接口。

    7.Android中常用布局

    常用的布局:

    FrameLayout(帧布局):所有东西依次都放在左上角,会重叠
    LinearLayout(线性布局):按照水平和垂直进行数据展示
    RelativeLayout(相对布局):以某一个元素为参照物,来定位的布局方式

    不常用的布局:

    TableLayout(表格布局): 每一个TableLayout里面有表格行TableRowTableRow里面可以具体定义每一个元素(Android TV上使用)
    AbsoluteLayout(绝对布局):用X,Y坐标来指定元素的位置,元素多就不适用。(机顶盒上使用)

    新增布局:

    PercentRelativeLayout(百分比相对布局)可以通过百分比控制控件的大小。
    PercentFrameLayout(百分比帧布局)可以通过百分比控制控件的大小。

    8.消息推送的方式

    • 方案1、使用极光和友盟推送。
    • 方案2、使用XMPP协议(Openfire + Spark + Smack)

      • 简介:基于XML协议的通讯协议,前身是Jabber,目前已由IETF国际标准化组织完成了标准化工作。
      • 优点:协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中,且已有开源的Java版的开发实例androidpn。
        缺点:协议较复杂、冗余(基于XML)、费流量、费电,部署硬件成本高。
    • 方案3、使用MQTT协议(更多信息见:mqtt.org/)

      • 简介:轻量级的、基于代理的“发布/订阅”模式的消息传输协议。
      • 优点:协议简洁、小巧、可扩展性强、省流量、省电,目前已经应用到企业领域(参考:mqtt.org/software),且…
      • 缺点:不够成熟、实现较复杂、服务端组件rsmb不开源,部署硬件成本较高。
    • 方案4、使用HTTP轮循方式
      • 简介:定时向HTTP服务端接口(Web Service API)获取最新消息。
      • 优点:实现简单、可控性强,部署硬件成本低。
      • 缺点:实时性差。

    9.android的数据存储

    1. 使用SharedPreferences存储数据;它是Android提供的用来存储一些简单配置信息的一种机制,采用了XML格式将数据存储到设备中。只能在同一个包内使用,不能在不同的包之间使用。
    2. 文件存储数据;文件存储方式是一种较常用的方法,在Android中读取/写入文件的方法,与Java中实现I/O的程序是完全一样的,提供了openFileInput()和openFileOutput()方法来读取设备上的文件。
    3. SQLite数据库存储数据;SQLite是Android所带的一个标准的数据库,它支持SQL语句,它是一个轻量级的嵌入式数据库。
    4. 使用ContentProvider存储数据;主要用于应用程序之间进行数据交换,从而能够让其他的应用保存或读取此Content Provider的各种数据类型。
    5. 网络存储数据;通过网络上提供给我们的存储空间来上传(存储)和下载(获取)我们存储在网络空间中的数据信息。

    10.Activity启动模式

    介绍 Android 启动模式之前,先介绍两个概念task和taskAffinity

    • task:翻译过来就是“任务”,是一组相互有关联的 activity 集合,可以理解为 Activity 是在 task 里面活动的。 task 存在于一个称为 back stack 的数据结构中,也就是说, task 是以栈的形式去管理 activity 的,所以也叫可以称为“任务栈”。
    • taskAffinity:官方文档解释是:"The task that the activity has an affinity for.",可以翻译为 activity 相关或者亲和的任务,这个参数标识了一个 Activity 所需要的任务栈的名字。默认情况下,所有Activity所需的任务栈的名字为应用的包名。 taskAffinity 属性主要和 singleTask 启动模式或者 allowTaskReparenting 属性配对使用。

    4种启动模式

    1. standard:标准模式,也是系统默认的启动模式。假如 activity A 启动了 activity B , activity B 则会运行在 activity A 所在的任务栈中。而且每次启动一个 Activity ,都会重新创建新的实例,不管这个实例在任务中是否已经存在。非 Activity 类型的 context (如 ApplicationContext )启动 standard 模式的 Activity 时会报错。非 Activity 类型的 context 并没有所谓的任务栈,由于上面第 1 点的原因所以系统会报错。此解决办法就是为待启动 Activity 指定 FLAG_ACTIVITY_NEW_TASK 标记位,这样启动的时候系统就会为它创建一个新的任务栈。这个时候待启动 Activity 其实是以 singleTask 模式启动的。
    2. singleTop:栈顶复用模式。假如 activity A 启动了 activity B ,就会判断 A 所在的任务栈栈顶是否是 B 的实例。如果是,则不创建新的 activity B 实例而是直接引用这个栈顶实例,同时 onNewIntent 方法会被回调,通过该方法的参数可以取得当前请求的信息;如果不是,则创建新的 activity B 实例。
    3. singleTask:栈内复用模式。在第一次启动这个 Activity 时,系统便会创建一个新的任务,并且初始化 Activity 的实例,放在新任务的底部。不过需要满足一定条件的。那就是需要设置 taskAffinity 属性。前面也说过了, taskAffinity 属性是和 singleTask 模式搭配使用的。

    1. singleInstance:单实例模式。这个是 singleTask 模式的加强版,它除了具有 singleTask 模式的所有特性外,它还有一点独特的特性,那就是此模式的 Activity 只能单独地位于一个任务栈,不与其他 Activity 共存于同一个任务栈。
    收起阅读 »

    Android实现旋转动画的两种方式

    练习案例 视差动画 - 雅虎新闻摘要加载 效果展示 前期准备 第一步:准备好颜色数组 res => values => colors.xml <color name="orange">#FF9600</col...
    继续阅读 »

    练习案例


    视差动画 - 雅虎新闻摘要加载


    效果展示



    前期准备


    第一步:准备好颜色数组 res => values => colors.xml


        <color name="orange">#FF9600</color>
    <color name="aqua">#02D1AC</color>
    <color name="yellow">#FFD200</color>
    <color name="bule">#00C6FF</color>
    <color name="green">#00E099</color>
    <color name="pink">#FF3891</color>

    <array name="splash_circle_colors">
    <item>@color/orange</item>
    <item>@color/aqua</item>
    <item>@color/yellow</item>
    <item>@color/bule</item>
    <item>@color/green</item>
    <item>@color/pink</item>
    </array>


    自定义 View java代码编写


    方法一


    关键思想: 属性动画 + 计算圆心



    package com.wust.mydialog;

    import android.animation.ObjectAnimator;
    import android.animation.ValueAnimator;
    import android.content.Context;
    import android.graphics.Canvas;
    import android.graphics.Paint;
    import android.util.AttributeSet;
    import android.view.View;
    import android.view.animation.LinearInterpolator;

    import androidx.annotation.Nullable;


    /**
    * ClassName: com.wust.mydialog.MyRotateView <br/>
    * Description: <br/>
    * date: 2021/8/7 12:13<br/>
    *
    * @author yiqi<br />
    * @QQ 1820762465
    * @微信 yiqiideallife
    * @技术交流QQ群 928023749
    */
    public class MyRotateView extends View {

    //设置旋转间隔时间
    private int SPLASH_CIRCLE_ROTATE_TIME = 3000;
    //设置中心圆半径
    private float CENTER_CIRCLE_RADIUS;
    private float SMALL_CIRCLE_RADIUS;
    private float mCurrentSingle = 0f;
    private int[] mColorArray;
    private Paint mCirclePaint;
    private ValueAnimator va;

    public MyRotateView(Context context) {
    super(context);
    }

    public MyRotateView(Context context, @Nullable AttributeSet attrs) {
    super(context, attrs);
    }

    public MyRotateView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
    super(context, attrs, defStyleAttr);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    int width = MeasureSpec.getSize(widthMeasureSpec);
    int height = MeasureSpec.getSize(heightMeasureSpec);

    //初始化参数
    initParams(width,height);

    setMeasuredDimension(width,height);
    }

    private void initParams(int w, int h) {
    //设置中心圆半径
    CENTER_CIRCLE_RADIUS = 1/4.0f * w;
    //设置小圆的半径
    SMALL_CIRCLE_RADIUS = 1/25.0f * w;
    //获取小球颜色
    mColorArray = getResources().getIntArray(R.array.splash_circle_colors);
    //初始化画笔
    mCirclePaint = new Paint();
    mCirclePaint.setDither(true);
    mCirclePaint.setAntiAlias(true);

    }

    @Override
    protected void onDraw(Canvas canvas) {
    super.onDraw(canvas);
    //绘制圆
    drawSplashCircle(canvas);
    }

    private void drawSplashCircle(Canvas canvas) {
    //设置属性动画,让小圆转起来
    //这里得注意,是个坑,你如果不判断那球就不会动 因为会陷入死循环 值动画将值设置为0 -> invalidate()重绘 -> 执行draw 又将值设为0
    if (va == null){
    va = ObjectAnimator.ofFloat(0f, 2 * (float) Math.PI);
    va.setDuration(SPLASH_CIRCLE_ROTATE_TIME);
    va.setRepeatCount(ValueAnimator.INFINITE);
    va.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator animation) {
    mCurrentSingle = (float) animation.getAnimatedValue();
    // System.out.println("mCurrentSingle ->" + mCurrentSingle);
    invalidate();
    }
    });
    va.setInterpolator(new LinearInterpolator());
    va.start();
    }

    //计算每个小球的间隔
    double spaceAngle = Math.PI*2/mColorArray.length;

    for (int i = 0; i < mColorArray.length; i++) {
    //为 每个球 画笔 设置颜色
    mCirclePaint.setColor(mColorArray[i]);

    //利用 勾股定理 计算 小圆 中心点
    float cx = getWidth()/2 + (float) (CENTER_CIRCLE_RADIUS*Math.cos(spaceAngle*i+mCurrentSingle));
    float cy = getHeight()/2 + (float) (CENTER_CIRCLE_RADIUS*Math.sin(spaceAngle*i+mCurrentSingle));

    canvas.drawCircle(cx,cy,SMALL_CIRCLE_RADIUS,mCirclePaint);
    }
    }
    }

    方法二


    关键思想:旋转画布法


    package com.wust.mydialog;

    import android.animation.ObjectAnimator;
    import android.animation.ValueAnimator;
    import android.content.Context;
    import android.graphics.Canvas;
    import android.graphics.Paint;
    import android.util.AttributeSet;
    import android.view.View;
    import android.view.animation.LinearInterpolator;

    import androidx.annotation.Nullable;


    /**
    * ClassName: com.wust.mydialog.MyRotateView <br/>
    * Description: <br/>
    * date: 2021/8/7 12:13<br/>
    *
    * @author yiqi<br />
    * @QQ 1820762465
    * @微信 yiqiideallife
    * @技术交流QQ群 928023749
    */
    public class MyRotateView extends View {

    //设置旋转间隔时间
    private int SPLASH_CIRCLE_ROTATE_TIME = 3000;
    //设置中心圆半径
    private float CENTER_CIRCLE_RADIUS;
    private float SMALL_CIRCLE_RADIUS;
    private float mCurrentSingle = 0f;
    private int[] mColorArray;
    private Paint mCirclePaint;
    private ValueAnimator va;

    public MyRotateView(Context context) {
    super(context);
    }

    public MyRotateView(Context context, @Nullable AttributeSet attrs) {
    super(context, attrs);
    }

    public MyRotateView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
    super(context, attrs, defStyleAttr);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    int width = MeasureSpec.getSize(widthMeasureSpec);
    int height = MeasureSpec.getSize(heightMeasureSpec);

    //初始化参数
    initParams(width,height);

    setMeasuredDimension(width,height);
    }

    private void initParams(int w, int h) {
    //设置中心圆半径
    CENTER_CIRCLE_RADIUS = 1/4.0f * w;
    //设置小圆的半径
    SMALL_CIRCLE_RADIUS = 1/25.0f * w;
    //获取小球颜色
    mColorArray = getResources().getIntArray(R.array.splash_circle_colors);
    //初始化画笔
    mCirclePaint = new Paint();
    mCirclePaint.setDither(true);
    mCirclePaint.setAntiAlias(true);

    }

    @Override
    protected void onDraw(Canvas canvas) {
    super.onDraw(canvas);
    //绘制圆
    drawSplashCircle(canvas);
    }

    private void drawSplashCircle(Canvas canvas) {
    //设置属性动画,让小圆转起来
    //这里得注意,是个坑,你如果不判断那球就不会动 因为会陷入死循环 值动画将值设置为0 -> invalidate()重绘 -> 执行draw 又将值设为0
    if (va == null){
    // va = ObjectAnimator.ofFloat(0f, 2 * (float) Math.PI);
    va = ObjectAnimator.ofFloat(0f, 360.0f);
    va.setDuration(SPLASH_CIRCLE_ROTATE_TIME);
    va.setRepeatCount(ValueAnimator.INFINITE);
    va.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator animation) {
    mCurrentSingle = (float) animation.getAnimatedValue();
    // System.out.println("mCurrentSingle ->" + mCurrentSingle);
    invalidate();
    }
    });
    va.setInterpolator(new LinearInterpolator());
    va.start();
    }

    //计算每个小球的间隔
    // double spaceAngle = Math.PI*2/mColorArray.length;
    double spaceAngle = 360.0d/mColorArray.length;
    System.out.println("spaceAngle -> " + spaceAngle);

    //利用旋转画布法
    canvas.save();
    canvas.rotate(mCurrentSingle,getWidth()/2,getHeight()/2);
    for (int i = 0; i < mColorArray.length; i++) {
    canvas.rotate((float) spaceAngle,getWidth()/2,getHeight()/2);
    //为 每个球 画笔 设置颜色
    mCirclePaint.setColor(mColorArray[i]);

    //利用 勾股定理 计算 小圆 中心点
    //float cx = getWidth()/2 + (float) (CENTER_CIRCLE_RADIUS*Math.cos(spaceAngle*i+mCurrentSingle));
    //float cy = getHeight()/2 + (float) (CENTER_CIRCLE_RADIUS*Math.sin(spaceAngle*i+mCurrentSingle));

    //利用旋转画布法
    float cx = getWidth()/2 + CENTER_CIRCLE_RADIUS;
    float cy = getHeight()/2;

    canvas.drawCircle(cx,cy,SMALL_CIRCLE_RADIUS,mCirclePaint);
    }
    canvas.restore();
    }
    }

    易错点总结: 


    1、canvas.rotate(mCurrentSingle,getWidth()/2,getHeight()/2);中 第一个参数传的是角度(360度的那种),而 Math.cos();中 参数传的是一个弧度(2π的那种


    2、canvas.rotate() 函数执行之后对后续画布上的操作都是有影响的,所以,得配合 canvas.save();和 canvas.restore();使用。因此,里面的canvas.rotate((float) spaceAngle,getWidth()/2,getHeight()/2);中spaceAngle不能乘 i 。


    3、画布的旋转除了 canvas.rotate() 函数 可以实现外,还可以利用矩阵。代码如下:


    //创建矩阵
    private Matrix mSpaceMatrix;
    //初始化旋转矩阵
    mSpaceMatrix = new Matrix();
    //初始化旋转矩阵
    mSpaceMatrix.reset();
    mSpaceMatrix.postRotate((float) spaceAngle,getWidth()/2,getHeight()/2);
    //画布旋转角度
    canvas.concat(mSpaceMatrix);

    完整代码


    package com.wust.mydialog;

    import android.animation.ObjectAnimator;
    import android.animation.ValueAnimator;
    import android.content.Context;
    import android.graphics.Canvas;
    import android.graphics.Matrix;
    import android.graphics.Paint;
    import android.util.AttributeSet;
    import android.view.View;
    import android.view.animation.LinearInterpolator;

    import androidx.annotation.Nullable;


    /**
    * ClassName: com.wust.mydialog.MyRotateView <br/>
    * Description: <br/>
    * date: 2021/8/7 12:13<br/>
    *
    * @author yiqi<br />
    * @QQ 1820762465
    * @微信 yiqiideallife
    * @技术交流QQ群 928023749
    */
    public class MyRotateView extends View {

    //设置旋转间隔时间
    private int SPLASH_CIRCLE_ROTATE_TIME = 3000;
    //设置中心圆半径
    private float CENTER_CIRCLE_RADIUS;
    private float SMALL_CIRCLE_RADIUS;
    private float mCurrentSingle = 0f;
    private int[] mColorArray;
    private Paint mCirclePaint;
    private ValueAnimator va;
    private Matrix mSpaceMatrix;

    public MyRotateView(Context context) {
    super(context);
    }

    public MyRotateView(Context context, @Nullable AttributeSet attrs) {
    super(context, attrs);
    }

    public MyRotateView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
    super(context, attrs, defStyleAttr);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    int width = MeasureSpec.getSize(widthMeasureSpec);
    int height = MeasureSpec.getSize(heightMeasureSpec);

    //初始化参数
    initParams(width,height);

    setMeasuredDimension(width,height);
    }

    private void initParams(int w, int h) {
    //设置中心圆半径
    CENTER_CIRCLE_RADIUS = 1/4.0f * w;
    //设置小圆的半径
    SMALL_CIRCLE_RADIUS = 1/25.0f * w;
    //获取小球颜色
    mColorArray = getResources().getIntArray(R.array.splash_circle_colors);
    //初始化画笔
    mCirclePaint = new Paint();
    mCirclePaint.setDither(true);
    mCirclePaint.setAntiAlias(true);
    //初始化旋转矩阵
    mSpaceMatrix = new Matrix();
    }

    @Override
    protected void onDraw(Canvas canvas) {
    super.onDraw(canvas);
    //绘制圆
    drawSplashCircle(canvas);
    }

    private void drawSplashCircle(Canvas canvas) {
    //设置属性动画,让小圆转起来
    //这里得注意,是个坑,你如果不判断那球就不会动 因为会陷入死循环 值动画将值设置为0 -> invalidate()重绘 -> 执行draw 又将值设为0
    if (va == null){
    // va = ObjectAnimator.ofFloat(0f, 2 * (float) Math.PI);
    va = ObjectAnimator.ofFloat(0f, 360.0f);
    va.setDuration(SPLASH_CIRCLE_ROTATE_TIME);
    va.setRepeatCount(ValueAnimator.INFINITE);
    va.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator animation) {
    mCurrentSingle = (float) animation.getAnimatedValue();
    // System.out.println("mCurrentSingle ->" + mCurrentSingle);
    invalidate();
    }
    });
    va.setInterpolator(new LinearInterpolator());
    va.start();
    }

    //计算每个小球的间隔
    // double spaceAngle = Math.PI*2/mColorArray.length;
    double spaceAngle = 360.0d/mColorArray.length;
    //初始化旋转矩阵
    mSpaceMatrix.reset();
    mSpaceMatrix.postRotate((float) spaceAngle,getWidth()/2,getHeight()/2);


    //利用旋转画布法
    canvas.save();
    canvas.rotate(mCurrentSingle,getWidth()/2,getHeight()/2);
    for (int i = 0; i < mColorArray.length; i++) {
    // canvas.rotate((float) spaceAngle,getWidth()/2,getHeight()/2);
    // System.out.println("spaceAngle -> " + spaceAngle);
    canvas.concat(mSpaceMatrix);
    //为 每个球 画笔 设置颜色
    mCirclePaint.setColor(mColorArray[i]);

    //利用 勾股定理 计算 小圆 中心点
    //float cx = getWidth()/2 + (float) (CENTER_CIRCLE_RADIUS*Math.cos(spaceAngle*i+mCurrentSingle));
    //float cy = getHeight()/2 + (float) (CENTER_CIRCLE_RADIUS*Math.sin(spaceAngle*i+mCurrentSingle));

    //利用旋转画布法
    float cx = getWidth()/2 + CENTER_CIRCLE_RADIUS;
    float cy = getHeight()/2;

    canvas.drawCircle(cx,cy,SMALL_CIRCLE_RADIUS,mCirclePaint);
    }
    canvas.restore();
    }
    }

    注意事项:


    1、canvas.concat(mSpaceMatrix);对画布的操作也会对后面进行影响


    2、Android中Matrix的set、pre、post的区别



    说set、pre、post的区别之前,先说说Matrix。



    Matrix包含一个3 X 3的矩阵,专门用于图像变换匹配。


    Matrix提供了四种操作:



    • translate(平移)

    • rotate(旋转)

    • scale(缩放)

    • skew(倾斜)


    也就是说这4种操作都是对这个3 X 3的矩阵设值来达到变换的效果。


    Matrix没有结构体,它必须被初始化,通过reset或set方法。


    OK,Matrix介绍完了,我们来看看set、pre、post的区别。


    pre是在队列最前面插入,post是在队列最后面追加,而set先清空队列在添加(这也是上文提到的“Matrix没有结构体,它必须被初始化,通过reset或set方法”的原因)。


    下面通过一些例子具体说明:



    1. matrix.preScale(2f,1f);    

    2. matrix.preTranslate(5f, 0f);   

    3. matrix.postScale(0.2f, 1f);    

    4. matrix.postTranslate(0.5f, 0f);  


    执行顺序:translate(5, 0) -> scale(2f, 1f) -> scale(0.2f, 1f) -> translate(0.5f, 0f)



    1. matrix.postTranslate(2f, 0f);   

    2. matrix.preScale(0.2f, 1f);     

    3. matrix.setScale(1f, 1f);   

    4. matrix.postScale(5f, 1f);   

    5. matrix.preTranslate(0.5f, 0f);   


    执行顺序:translate(0.5f, 0f) -> scale(1f, 1f) ->  scale(5f, 1)


    收起阅读 »

    Flutter AnimatedList 使用解析

    志在巅峰的攀登者,不会陶醉在沿途的某个脚印之中,在码农的世界里,优美的应用体验,来源于程序员对细节的处理以及自我要求的境界,年轻人也是忙忙碌碌的码农中一员,每天、每周,都会留下一些脚印,就是这些创作的内容,有一种执着,就是不知为什么,如果你迷茫,不妨来瞅瞅码农...
    继续阅读 »



    志在巅峰的攀登者,不会陶醉在沿途的某个脚印之中,在码农的世界里,优美的应用体验,来源于程序员对细节的处理以及自我要求的境界,年轻人也是忙忙碌碌的码农中一员,每天、每周,都会留下一些脚印,就是这些创作的内容,有一种执着,就是不知为什么,如果你迷茫,不妨来瞅瞅码农的轨迹。



    在 Flutter 中 ,AnimatedList 、ListView 、SliverListView 、SliverAnimatedList 用来显示列表数据样式,一般情况下 使用 ListView 就可实现大部分业务需求,AnimatedList 的特点是可以在插入数据与移除数据的时候添加动画效果


    本文章实现的效果是


    在这里插入图片描述


    AnimatedList 简述


      const AnimatedList({
    Key? key,
    required this.itemBuilder,
    this.initialItemCount = 0,
    this.scrollDirection = Axis.vertical,
    this.reverse = false,
    this.controller,
    this.primary,
    this.physics,
    this.shrinkWrap = false,
    this.padding,
    this.clipBehavior = Clip.hardEdge,
    })


    • itemBuilder 子 Item UI布局构建

    • initialItemCount 列表显示的条目 个数

    • scrollDirection 滑动方向

    • reverse scrollDirection 为 Axis.vertical 时,如果 reverse 为ture ,那么列表内容会自动滑动到底部

    • controller 滑动控制器

    • physics 滑动效果控制 ,BouncingScrollPhysics 是列表滑动 iOS 的回弹效果;AlwaysScrollableScrollPhysics 是 列表滑动 Android 的水波纹回弹效果;ClampingScrollPhysics 普通的滑动效果;

    • shrinkWrap 为true的时候 AnimatedList 会包裹所有的子Item


    本实例 Demo


    首先是我初始化了点数据‘


      List<String> _list = [];

    GlobalKey<AnimatedListState> _globalKey = new GlobalKey();

    @override
    void initState() {
    super.initState();
    for (int i = 0; i < 10; i++) {
    _list.add("早起的年轻人 $i");
    }
    }

    然后就是 AnimatedList 的使用如下:


      AnimatedList buildAnimatedList() {
    return AnimatedList(
    //关键key
    key: _globalKey,
    //列表个数
    initialItemCount: _list.length,
    //每个子Item
    itemBuilder:
    (BuildContext context, int index, Animation<double> animation) {
    return buildSizeTransition(animation, index);
    },
    );
    }

    然后列表中的每个 Item 的 UI 布局构建如下


     SizeTransition buildSizeTransition(Animation<double> animation, int index) {
    //来个动画
    return SizeTransition(
    //动画构建
    sizeFactor: animation,
    //子UI
    child: SizedBox(
    height: 80.0,
    child: Card(
    color: Colors.primaries[index % Colors.primaries.length],
    child: Center(
    child: Text(
    'Item $index ${_list[index]}',
    ),
    ),
    ),
    ),
    );
    }

    然后我们插入一条数据


    //插入源数据
    _list.insert(0, "插入数据 ${DateTime.now()}");
    //插入动画效果
    _globalKey.currentState.insertItem(
    0,//插入的位置
    duration: Duration(milliseconds: 400),
    );
    },

    然后移除一条数据


     //移除源数据
    _list.removeAt(0);
    //移除动画效果
    _globalKey.currentState.removeItem(
    0,
    (BuildContext context, Animation<double> animation) {
    return buildSizeTransition(animation, 0);
    },
    );

    收起阅读 »

    Android 65536启用 multidex

    前言         起因:项目使用的一直是multidex:1.0.3版本就想着版本低了要不要升级一下。惊喜就这么来了。 65536    &...
    继续阅读 »

    前言


            起因:项目使用的一直是multidex:1.0.3版本就想着版本低了要不要升级一下。惊喜就这么来了。


    65536


            当你的应用及其引用的库超过 65,536 个方法时,你会遇到构建错误,表明你的应用已达到 Android 构建架构的限制:


    trouble writing output:
    Too many field references: 131000; max is 65536.
    You may try using --multi-dex option.

            旧版本的构建系统报告了不同的错误,这表明存在相同的问题:


    Conversion to Dalvik format failed:
    Unable to execute dex: method ID not in [0, 0xffff]: 65536

            这两种错误情况都显示一个共同的数字:65536。这个数字表示单个 Dalvik 可执行文件 (DEX) 字节码文件中的代码可以调用的引用总数。本问介绍了如何通过启用称为multidex的应用程序配置来克服此限制,该配置允许你的应用程序构建和读取多个 DEX 文件。


    关于 64K 参考限制


            Android 应用 APK 文件包含 Dalvik 可执行文件 DEX 文件形式的可执行字节码文件,其中包含用于运行应用的编译代码。Dalvik Executable 规范将单个 DEX 文件中可以引用的方法总数限制为 65,536,包括 Android 框架方法、库方法和你自己代码中的方法。在计算机科学的上下文中,术语Kilo, K表示 1024(或 2^10)。由于 65,536 等于 64 X 1024,因此此限制称为64K 参考限制


    解决64K限制


    对 Android 5.0 及更高版本的 Multidex 支持


            Android 5.0(API 级别 21)及更高版本使用称为 ART 的运行时,该运行时本机支持从 APK 文件加载多个 DEX 文件。 ART 在应用安装时执行预编译,它会扫描 classesN.dex 文件并将它们编译成单个 .oat 文件以供 Android 设备执行。 因此,如果你的 minSdkVersion 为 21 或更高,则默认启用 multidex,并且你不需要 multidex 库



    注意: 当使用 Android Studio 运行你的应用程序时,构建会针对你部署到的目标设备进行优化。 这包括在目标设备运行 Android 5.0 及更高版本时启用 multidex。 由于此优化仅在使用 Android Studio 部署应用程序时应用,因此你可能仍需要为 multidex 配置发布版本以避免 64K 限制。




            看到没,这里最好的解决办法就是设置minSdkVersion设置为 21 或更高。这样网上的一些什么



    • multidex你遇到的坑


    • multidex与你不得不说的秘密


    • multidex原理及实现就和你没得关系了,当然你想了解也可以。



            Android SDK 为 21 或更高的问题解决了,那Android SDK 低于 21 的呢。咱接着往下看喽。


    Android 5.0 之前的 Multidex 支持


    为你的应用程序配置 multidex


            如果你的 minSdkVersion 设置为 21 或更高,则默认启用 multidex,你不需要 multidex 库。


            但是,如果你的 minSdkVersion 设置为 20 或更低,那么你必须使用 multidex 库并对你的应用项目进行以下修改:


    1.修改模块级 build.gradle 文件以启用 multidex 并添加 multidex 库作为依赖项,如下所示:



    • 使用AndroidX



    android {
        defaultConfig {
            ...
            minSdkVersion 15 
            targetSdkVersion 30
            multiDexEnabled true
        }
        ...
    }

    dependencies {
        implementation "androidx.multidex:multidex:2.0.1"
    }


    • 不使用AndroidX(已弃用)



    android {
        defaultConfig {
            ...
            minSdkVersion 15 
            targetSdkVersion 30
            multiDexEnabled true
        }
        ...
    }

    dependencies {
        implementation 'com.android.support:multidex:1.0.3'
    }

    2.根据你是否覆盖 Application 类,执行以下操作之一:



    • 如果你不覆盖 Application 类,请编辑你的清单文件以在 < application > 标记中设置 android:name,如下所示:



    <?xml version="1.0" encoding="utf-8"?>
    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.scc.demo">
        <application
                android:name="androidx.multidex.MultiDexApplication" >
            ...
        </application>
    </manifest>


    • 如果你确实覆盖了 Application 类,请将其更改为扩展 MultiDexApplication(非必须),如下所示:



    public class MyApplication extends MultiDexApplication { ... }


    • 或者,如果你确实覆盖了 Application 类但无法更改基类,那么你可以覆盖 attachBaseContext() 方法和 callMultiDex.install(this) 以启用 multidex:



    public class MyApp extends Application {
      @Override
      protected void attachBaseContext(Context base) {
         super.attachBaseContext(base);
         MultiDex.install(this);
      }
    }


     

    注意: 在 MultiDex.install() 完成之前,不要通过反射或 JNI 执行 MultiDex.install() 或任何其他代码。 Multidex 跟踪不会跟随这些调用,导致 ClassNotFoundException 或由于 DEX 文件之间的类分区错误而导致验证错误。



            现在,当你构建应用程序时,Android 构建工具会根据需要构建一个主要的 DEX 文件 (classes.dex) 和支持的 DEX 文件(classes2.dex、classes3.dex 等)。构建系统然后将所有 DEX 文件打包到你的 APK 中。


            在运行时,multidex API 使用特殊的类加载器来搜索所有可用的 DEX 文件以查找你的方法(而不是仅在主 classes.dex 文件中搜索)。


    multidex 库的限制


            multidex 库有一些已知的限制,当你将其合并到应用程序构建配置中时,你应该注意并测试这些限制:



    • 在启动期间将 DEX 文件安装到设备的数据分区上很复杂,如果辅助 DEX 文件很大,可能会导致应用程序无响应 (ANR) 错误。为避免此问题,请启用代码收缩以最小化 DEX 文件的大小并删除未使用的代码部分。


    • 在 Android 5.0(API 级别 21)之前的版本上运行时,使用 multidex 不足以解决 linearalloc 限制(问题 78035)。此限制在 Android 4.0(API 级别 14)中有所增加,但这并没有完全解决。在低于 Android 4.0 的版本上,你可能会在达到 DEX 索引限制之前达到线性分配限制。因此,如果你的目标 API 级别低于 14,请在平台的这些版本上进行彻底测试*,因为你的应用程序可能在启动时或加载特定类组时出现问题。



            代码缩减可以减少或可能消除这些问题。


    在主 DEX 文件中声明所需的类


            如果你收到 java.lang.NoClassDefFoundError,那么你必须通过在构建类型中使用 multiDexKeepFilemultiDexKeepProguard 属性声明它们,根据主 DEX 文件中的要求手动指定这些附加类。 如果某个类在 multiDexKeepFile 或 multiDexKeepProguard 文件中匹配,则该类将添加到主 DEX 文件中。


    multiDexKeepFile 属性


            你在multiDexKeepFile其中指定的文件应每行包含一个类,格式为com/example/MyClass.class. 例如,你可以创建一个如下所示的文件multidex-config.txt:


    com/scc/MyClass.class
    com/scc/MyOtherClass.class

            然后,你可以为构建类型声明该文件,如下所示:


    android {
        buildTypes {
            release {
                multiDexKeepFile file('multidex-config.txt')
                ...
            }
        }
    }


     

    注意: Gradle 读取相对于build.gradle文件的路径,因此如果multidex-config.txt与build.gradle文件位于同一目录中,则上述示例有效。



    multiDexKeepProguard 属性


            该multiDexKeepProguard文件使用与 Proguard 相同的格式,并支持整个 Proguard 语法。


            你在multiDexKeepProguard其中指定的文件应包含 -keep 任何有效 ProGuard 语法中的选项。例如, -keep com.scc.MyClass.class。你可以创建一个名为的文件 multidex-config.pro,如下所示:


    -keep class com.scc.MyClass
    -keep class com.scc.MyClassToo

            如果要指定包中的所有类,文件如下所示:


    -keep class com.scc.** { *; } // com.scc 包中的所有类 

            然后,你可以为构建类型声明该文件,如下所示:


    android {
        buildTypes {
            release {
                multiDexKeepProguard file('multidex-config.pro')
                ...
            }
        }
    }

    在开发版本中优化 multidex


            为了减少更长的增量构建时间,使用 pre-dexing在构建之间重用 multidex 输出。Pre-dexing 依赖于仅在 Android 5.0(API 级别 21)及更高版本上可用的 ART 格式。如果你使用的是 Android Studio 2.3 及更高版本,则在将你的应用程序部署到运行 Android 5.0(API 级别 21)或更高版本的设备时,IDE 会自动使用此功能



     

    注意: 适用于 Gradle 3.0.0及更高版本的Android 插件包括进一步改进以优化构建速度,例如按类进行 dexing(以便仅对你修改的类进行重新索引)。一般来说,为了获得最佳的开发体验,你应该始终升级到 最新版本的 Android Studio和 Android 插件。



            但是,如果你从命令行运行 Gradle 构建,则需要将 minSdkVersion 设置为 21 或更高以启用 pre-dexing。保留生产版本设置的一个有用策略是使用产品风格创建两个版本的应用程序 :开发风格和发布风格,具有不同的值minSdkVersion,如下所示。


    android {
        defaultConfig {
            ...
            multiDexEnabled true
            //最低 API 级别。 
            minSdkVersion 15
        }
        productFlavors {
            dev {
                //(API 级别 21)或更高 .
                minSdkVersion 21
            }
            prod {
                // 如果你已经为生产版本配置了 defaultConfig 块
                // 你的应用程序,你可以将此块留空,Gradle 会使用其中的配置
                // 代替 defaultConfig 块。 你仍然需要包括这种味道。
                // 否则,所有变体都使用“dev”配置。 
            }
        }
        buildTypes {
            release {
                minifyEnabled true
                proguardFiles getDefaultProguardFile('proguard-android.txt'),
                                                     'proguard-rules.pro'
            }
        }
    }
    dependencies {
        implementation "androidx.multidex:multidex:2.0.1"
    }

    避免 64K 限制


            在配置应用以启用 64K 或更多方法引用之前,你应该采取措施减少应用代码调用的引用总数,包括应用代码定义的方法或包含的库。以下策略可以帮助你避免达到 DEX 参考限制:



    • 检查你的应用程序的直接和传递依赖项 - 确保你在应用程序中包含的任何大型库依赖项的使用方式都超过添加到应用程序的代码量。一个常见的反模式是包含一个非常大的库,因为一些实用方法是有用的。减少你的应用程序代码依赖性通常可以帮助你避免 DEX 引用限制。


    • 使用 R8 删除未使用的代码 -启用代码收缩以运行 R8 以用于你的发布版本。启用收缩可确保你不会随 APK 一起发送未使用的代码。



            使用这些技术可能会帮助你避免在应用中启用 multidex,同时还可以减少 APK 的整体大小。


    以上就是本文的全部内容,希望对大家学习Android multidex有所帮助和启发。

    收起阅读 »

    实现activity跳转动画的若干种方式

    第一种: (使用overridePendingTransition方法实现Activity跳转动画) 在Activity中代码如下 /** * 点击按钮实现跳转逻辑 */ button1.setOnClickListener(new View.OnClic...
    继续阅读 »

    第一种: (使用overridePendingTransition方法实现Activity跳转动画)


    在Activity中代码如下


    /**
    * 点击按钮实现跳转逻辑
    */
    button1.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
    /**
    * 在调用了startActivity方法之后立即调用overridePendingTransition方法
    */
    Intent intent = new Intent(MainActivity.this, SecondActivity.class);
    startActivity(intent);
    overridePendingTransition(R.anim.slide_in_left, R.anim.slide_in_left);
    }
    });


    在anim文件下代码如下


    <?xml version="1.0" encoding="utf-8"?>
    <set xmlns:Android="http://schemas.Android.com/apk/res/Android"
    Android:shareInterpolator="false"
    Android:zAdjustment="top">

    <translate
    Android:duration="200"
    Android:fromXDelta="-100.0%p"
    Android:toXDelta="0.0" />
    </set>


    第二种: (使用style的方式定义Activity的切换动画)


    从清单文件入手


    <!-- 系统Application定义 -->
    <application
    Android:allowBackup="true"
    Android:icon="@mipmap/ic_launcher"
    Android:label="@string/app_name"
    Android:supportsRtl="true"
    Android:theme="@style/AppTheme">


    进入AppTheme


    <!-- Base application theme. -->
    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
    <!-- Customize your theme here. -->
    <item name="colorPrimary">@color/colorPrimary</item>
    <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
    <item name="colorAccent">@color/colorAccent</item>
    <item name="Android:windowAnimationStyle">@style/activityAnim</item>
    </style>


    <!-- 使用style方式定义activity切换动画 -->
    <style name="activityAnim">
    <item name="Android:activityOpenEnterAnimation">@anim/slide_in_top</item>
    <item name="Android:activityOpenExitAnimation">@anim/slide_in_top</item>
    </style>



    在windowAnimationStyle中存在四种动画


    activityOpenEnterAnimation // 用于设置打开新的Activity并进入新的Activity展示的动画
    activityOpenExitAnimation // 用于设置打开新的Activity并销毁之前的Activity展示的动画
    activityCloseEnterAnimation // 用于设置关闭当前Activity进入上一个Activity展示的动画
    activityCloseExitAnimation // 用于设置关闭当前Activity时展示的动画


    Activity中的测试代码如下


    /**
    * 点击按钮,实现Activity的跳转操作
    * 通过定义style的方式实现activity的跳转动画
    */
    button2.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
    /**
    * 普通的Intent跳转Activity实现
    */
    Intent intent = new Intent(MainActivity.this, SecondActivity.class);
    startActivity(intent);
    }
    });


    第三种: (使用ActivityOptions切换动画实现Activity跳转动画)


    第一步


    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // 设置contentFeature,可使用切换动画
    getWindow().requestFeature(Window.FEATURE_CONTENT_TRANSITIONS);
    Transition explode = TransitionInflater.from(this).inflateTransition(Android.R.transition.explode);
    getWindow().setEnterTransition(explode);

    setContentView(R.layout.activity_main);
    }


    第二步


    /**
    * 点击按钮,实现Activity的跳转操作
    * 通过Android5.0及以上代码的方式实现activity的跳转动画
    */
    button3.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
    Intent intent = new Intent(MainActivity.this, ThreeActivity.class);
    startActivity(intent, ActivityOptions.makeSceneTransitionAnimation(MainActivity.this).toBundle());
    }
    });


    第四种: (使用ActivityOptions之后内置的动画效果通过style的方式)


    先在Application项目res目录下新建一个transition目录,然后创建资源文件activity_explode,编写如下代码


    <explode xmlns:Android="http://schemas.Android.com/apk/res/Android"
    Android:duration="300" />


    定义style文件



    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
    <!-- Customize your theme here. -->
    <item name="colorPrimary">@color/colorPrimary</item>
    <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
    <item name="colorAccent">@color/colorAccent</item>

    <item name="Android:windowEnterTransition">@transition/activity_explode</item>
    <item name="Android:windowExitTransition">@transition/activity_explode</item>
    </style>


    执行跳转逻辑


    /**
    * 点击按钮,实现Activity的跳转操作
    * 通过Android5.0及以上style的方式实现activity的跳转动画
    */
    button4.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
    /**
    * 调用ActivityOptions.makeSceneTransitionAnimation实现过度动画
    */
    Intent intent = new Intent(MainActivity.this, FourActivity.class);
    startActivity(intent, ActivityOptions.makeSceneTransitionAnimation(MainActivity.this).toBundle());
    }
    });


    第五种: (使用ActivityOptions动画共享组件的方式实现跳转Activity动画)


    在Acitivity_A中布局文件中定义共享组件


    <Button
    Android:id="@+id/button5"
    Android:layout_width="match_parent"
    Android:layout_height="wrap_content"
    Android:layout_below="@+id/button4"
    Android:layout_marginTop="10dp"
    Android:layout_marginRight="10dp"
    Android:layout_marginLeft="10dp"
    Android:text="组件过度动画"
    Android:background="@color/colorPrimary"
    Android:transitionName="shareNames"
    />


    在Acitivity_B中布局文件中关联共享组件


    <?xml version="1.0" encoding="utf-8"?>
    <LinearLayout xmlns:Android="http://schemas.Android.com/apk/res/Android"
    Android:id="@+id/activity_second"
    Android:layout_width="match_parent"
    Android:layout_height="match_parent"
    Android:gravity="center_horizontal"
    Android:orientation="vertical"
    Android:transitionName="shareNames"
    >

    <TextView
    Android:layout_width="match_parent"
    Android:layout_height="match_parent"
    Android:background="@color/colorAccent"
    Android:layout_marginTop="10dp"
    Android:layout_marginBottom="10dp"
    />


    执行跳转逻辑


    /**
    * 点击按钮,实现Activity的跳转操作
    * 通过Android5.0及以上共享组件的方式实现activity的跳转动画
    */
    button5.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
    Intent intent = new Intent(MainActivity.this, FiveActivity.class);
    startActivity(intent, ActivityOptions.makeSceneTransitionAnimation(MainActivity.this, button5, "shareNames").toBundle());
    }
    });


    总结:




    • overridePendingTransition方法从Android2.0开始,基本上能够覆盖我们activity跳转动画的需求;




    • ActivityOptions API是在Android5.0开始的,可以实现一些炫酷的动画效果,更加符合MD风格;




    • ActivityOptions还可以实现两个Activity组件之间的过度动画;


    作者:印说十二越
    链接:https://juejin.cn/post/6993449863035748365
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

    iOS -性能优化 _RunLoop原理去监控

    iOS
    ios 利用RunLoop的原理去监控卡顿一、卡顿问题的几种原因复杂 UI 、图文混排的绘制量过大;在主线程上做网络同步请求;在主线程做大量的 IO 操作;运算量过大,CPU 持续高占用;死锁和主子线程抢锁。二、监测卡顿的思路监测FPS:FPS 是一秒显示的帧...
    继续阅读 »

    ios 利用RunLoop的原理去监控卡顿

    一、卡顿问题的几种原因

    • 复杂 UI 、图文混排的绘制量过大;
    • 在主线程上做网络同步请求;
    • 在主线程做大量的 IO 操作;
    • 运算量过大,CPU 持续高占用;
    • 死锁和主子线程抢锁。

    二、监测卡顿的思路

    1. 监测FPS:FPS 是一秒显示的帧数,也就是一秒内画面变化数量。如果按照动画片来说,动画片的 FPS 就是 24,是达不到 60 满帧的。也就是说,对于动画片来说,24 帧时虽然没有 60 帧时流畅,但也已经是连贯的了,所以并不能说 24 帧时就算是卡住了。 由此可见,简单地通过监视 FPS 是很难确定是否会出现卡顿问题了,所以我就果断弃了通过监视 FPS 来监控卡顿的方案。
    2. RunLoop:通过监控 RunLoop 的状态来判断是否会出现卡顿。RunLoop原理这里就不再多说,主要说方法,首先明确loop的状态有六个
    typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {

    kCFRunLoopEntry ,
    // 进入 loop

    kCFRunLoopBeforeTimers ,
    // 触发 Timer 回调

    kCFRunLoopBeforeSources ,
    // 触发 Source0 回调

    kCFRunLoopBeforeWaiting ,
    // 等待 mach_port 消息

    kCFRunLoopAfterWaiting ),
    // 接收 mach_port 消息

    kCFRunLoopExit ,
    // 退出 loop

    kCFRunLoopAllActivities
    // loop 所有状态改变

    }

    我们需要监测的状态有两个:RunLoop 在进入睡眠之前和唤醒后的两个 loop 状态定义的值,分别是 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting ,也就是要触发 Source0 回调和接收 mach_port 消息两个状态。

     

    三、如何检查卡顿

    先粗略说下步骤:

    • 创建一个 CFRunLoopObserverContext 观察者;
    • 将创建好的观察者 runLoopObserver 添加到主线程 RunLoop 的 common 模式下观察;
    • 创建一个持续的子线程专门用来监控主线程的 RunLoop 状态;
    • 一旦发现进入睡眠前的 kCFRunLoopBeforeSources 状态,或者唤醒后的状态 kCFRunLoopAfterWaiting,在设置的时间阈值内一直没有变化,即可判定为卡顿;
    • dump 出堆栈的信息,从而进一步分析出具体是哪个方法的执行时间过长;

    上代码:


    //
    // SMLagMonitor.h
    //
    // Created by DaiMing on 16/3/28.
    //

    #import <Foundation/Foundation.h>

    @interface SMLagMonitor : NSObject

    + (instancetype)shareInstance;

    - (void)beginMonitor; //开始监视卡顿
    - (void)endMonitor; //停止监视卡顿

    @end


    //
    // SMLagMonitor.m
    //
    // Created by DaiMing on 16/3/28.
    //

    #import "SMLagMonitor.h"
    #import "SMCallStack.h"
    #import "SMCPUMonitor.h"

    @interface SMLagMonitor() {
    int timeoutCount;
    CFRunLoopObserverRef runLoopObserver;
    @public
    dispatch_semaphore_t dispatchSemaphore;
    CFRunLoopActivity runLoopActivity;
    }
    @property (nonatomic, strong) NSTimer
    *cpuMonitorTimer;
    @end

    @implementation SMLagMonitor

    #pragma mark - Interface
    + (instancetype)shareInstance {
    static id instance = nil;
    static dispatch_once_t dispatchOnce;
    dispatch_once(
    &dispatchOnce, ^{
    instance
    = [[self alloc] init];
    });
    return instance;
    }

    - (void)beginMonitor {
    //监测 CPU 消耗
    self.cpuMonitorTimer = [NSTimer scheduledTimerWithTimeInterval:3
    target:self
    selector:@selector(updateCPUInfo)
    userInfo:nil
    repeats:YES];
    //监测卡顿
    if (runLoopObserver) {
    return;
    }
    dispatchSemaphore
    = dispatch_semaphore_create(0); //Dispatch Semaphore保证同步
    //创建一个观察者
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    runLoopObserver
    = CFRunLoopObserverCreate(kCFAllocatorDefault,
    kCFRunLoopAllActivities,
    YES,
    0,
    &runLoopObserverCallBack,
    &context);
    //将观察者添加到主线程runloop的common模式下的观察中
    CFRunLoopAddObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);

    //创建子线程监控
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
    //子线程开启一个持续的loop用来进行监控
    while (YES) {
    long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 20*NSEC_PER_MSEC));
    if (semaphoreWait != 0) {
    if (!runLoopObserver) {
    timeoutCount
    = 0;
    dispatchSemaphore
    = 0;
    runLoopActivity
    = 0;
    return;
    }
    //两个runloop的状态,BeforeSources和AfterWaiting这两个状态区间时间能够检测到是否卡顿
    if (runLoopActivity == kCFRunLoopBeforeSources || runLoopActivity == kCFRunLoopAfterWaiting) {
    // 将堆栈信息上报服务器的代码放到这里
    //出现三次出结果
    // if (++timeoutCount < 3) {
    // continue;
    // }
    NSLog(@"monitor trigger");
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH,
    0), ^{
    // [SMCallStack callStackWithType:SMCallStackTypeAll];
    });
    }
    //end activity
    }// end semaphore wait
    timeoutCount = 0;
    }
    // end while
    });

    }

    - (void)endMonitor {
    [self.cpuMonitorTimer invalidate];
    if (!runLoopObserver) {
    return;
    }
    CFRunLoopRemoveObserver(CFRunLoopGetMain(), runLoopObserver, kCFRunLoopCommonModes);
    CFRelease(runLoopObserver);
    runLoopObserver
    = NULL;
    }

    #pragma mark - Private

    static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){
    SMLagMonitor
    *lagMonitor = (__bridge SMLagMonitor*)info;
    lagMonitor
    ->runLoopActivity = activity;

    dispatch_semaphore_t semaphore
    = lagMonitor->dispatchSemaphore;
    dispatch_semaphore_signal(semaphore);
    }


    - (void)updateCPUInfo {
    thread_act_array_t threads;
    mach_msg_type_number_t threadCount
    = 0;
    const task_t thisTask = mach_task_self();
    kern_return_t kr
    = task_threads(thisTask, &threads, &threadCount);
    if (kr != KERN_SUCCESS) {
    return;
    }
    for (int i = 0; i < threadCount; i++) {
    thread_info_data_t threadInfo;
    thread_basic_info_t threadBaseInfo;
    mach_msg_type_number_t threadInfoCount
    = THREAD_INFO_MAX;
    if (thread_info((thread_act_t)threads[i], THREAD_BASIC_INFO, (thread_info_t)threadInfo, &threadInfoCount) == KERN_SUCCESS) {
    threadBaseInfo
    = (thread_basic_info_t)threadInfo;
    if (!(threadBaseInfo->flags & TH_FLAGS_IDLE)) {
    integer_t cpuUsage
    = threadBaseInfo->cpu_usage / 10;
    if (cpuUsage > 70) {
    //cup 消耗大于 70 时打印和记录堆栈
    NSString *reStr = smStackOfThread(threads[i]);
    //记录数据库中
    // [[[SMLagDB shareInstance] increaseWithStackString:reStr] subscribeNext:^(id x) {}];
    NSLog(@"CPU useage overload thread stack:\n%@",reStr);
    }
    }
    }
    }
    }

    @end

    使用,直接在APP didFinishLaunchingWithOptions 方法里面这样写:

    [[SMLagMonitor shareInstance] beginMonitor];

     

    搞定!

    链接:https://www.cnblogs.com/qiyiyifan/p/11089735.html

    收起阅读 »

    iOS 实例化讲解RunLoop

    iOS
    实例化讲解RunLoop之前看过很多有关RunLoop的文章,其中要么是主要介绍RunLoop的基本概念,要么是主要讲解RunLoop的底层原理,很少用真正的实例来讲解RunLoop的,这其中有大部分原因是由于大家在项目中很少能用到RunLoop吧。基于这种原...
    继续阅读 »

    实例化讲解RunLoop

    之前看过很多有关RunLoop的文章,其中要么是主要介绍RunLoop的基本概念,要么是主要讲解RunLoop的底层原理,很少用真正的实例来讲解RunLoop的,这其中有大部分原因是由于大家在项目中很少能用到RunLoop吧。基于这种原因,本文中将用很少的篇幅来对基础内容做以介绍,然后主要利用实例来加深大家对RunLoop的理解,本文中的代码已经上传GitHub,大家可以下载查看,有问题欢迎Issue我。本文主要分为如下几个部分:

    • RunLoop的基础知识
    • 初识RunLoop,如何让RunLoop进驻线程
    • 深入理解Perform Selector
    • 一直"活着"的后台线程
    • 深入理解NSTimer
    • 让两个后台线程有依赖性的一种方式
    • NSURLConnetction的内部实现
    • AFNetWorking中是如何使用RunLoop的?
    • 其它:利用GCD实现定时器功能
    • 延伸阅读

    一、RunLoop的基本概念:

    什么是RunLoop?提到RunLoop,我们一般都会提到线程,这是为什么呢?先来看下官方对RunLoop的定义:RunLoop系统中和线程相关的基础架构的组成部分(和线程相关),一个RunLoop是一个事件处理环,系统利用这个事件处理环来安排事务,协调输入的各种事件。RunLoop的目的是让你的线程在有工作的时候忙碌,没有工作的时候休眠(和线程相关)。可能这样说你还不是特别清楚RunLoop究竟是用来做什么的,打个比方来说明:我们把线程比作一辆跑车,把这辆跑车的主人比作RunLoop,那么在没有'主人'的时候,这个跑车的生命是直线型的,其启动,运行完之后就会废弃(没有人对其进行控制,'撞坏'被收回),当有了RunLoop这个主人之后,‘线程’这辆跑车的生命就有了保障,这个时候,跑车的生命是环形的,并且在主人有比赛任务的时候就会被RunLoop这个主人所唤醒,在没有任务的时候可以休眠(在IOS中,开启线程是很消耗性能的,开启主线程要消耗1M内存,开启一个后台线程需要消耗512k内存,我们应当在线程没有任务的时候休眠,来释放所占用的资源,以便CPU进行更加高效的工作),这样可以增加跑车的效率,也就是说RunLoop是为线程所服务的。这个例子有点不是很贴切,线程和RunLoop之间是以键值对的形式一一对应的,其中key是thread,value是runLoop(这点可以从苹果公开的源码中看出来)其实RunLoop是管理线程的一种机制,这种机制不仅在IOS上有,在Node.js中的EventLoop,Android中的Looper,都有类似的模式。刚才所说的比赛任务就是唤醒跑车这个线程的一个source;RunLoop Mode就是,一系列输入的source,timer以及observerRunLoop Mode包含以下几种: NSDefaultRunLoopMode,NSEventTrackingRunLoopMode,UIInitializationRunLoopMode,NSRunLoopCommonModes,NSConnectionReplyMode,NSModalPanelRunLoopMode,至于这些mode各自的含义,读者可自己查询,网上不乏这类资源;

    二、初识RunLoop,如何让RunLoop进驻线程

    我们在主线程中添加如下代码:

    1. while (1) {
    2. NSLog(@"while begin");
    3. // the thread be blocked here
    4. NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
    5. [runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
    6. // this will not be executed
    7. NSLog(@"while end");
    8. }

    这个时候我们可以看到主线程在执行完[runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];之后被阻塞而没有执行下面的NSLog(@"while end");同时,我们利用GCD,将这段代码放到一个后台线程中:

    1. dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    2. while (1) {
    3. NSLog(@"while begin");
    4. NSRunLoop *subRunLoop = [NSRunLoop currentRunLoop];
    5. [subRunLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
    6. NSLog(@"while end");
    7. }
    8. });

    这个时候我们发现这个while循环会一直在执行;这是为什么呢?我们先将这两个RunLoop分别打印出来:

    主线程的RunLoop


    由于这个日志比较长,我就只截取了上面的一部分。
    我们再看我们新建的子线程中的RunLoop,打印出来之后:

    backGroundThreadRunLoop.png


    从中可以看出来:我们新建的线程中:

     

    1. sources0 = (null),
    2. sources1 = (null),
    3. observers = (null),
    4. timers = (null),

    我们看到虽然有Mode,但是我们没有给它soures,observer,timer,其实Mode中的这些source,observer,timer,统称为这个Modeitem,如果一个Mode中一个item都没有,则这个RunLoop会直接退出,不进入循环(其实线程之所以可以一直存在就是由于RunLoop将其带入了这个循环中)。下面我们为这个RunLoop添加个source:

    1. dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    2. while (1) {
    3. NSPort *macPort = [NSPort port];
    4. NSLog(@"while begin");
    5. NSRunLoop *subRunLoop = [NSRunLoop currentRunLoop];
    6. [subRunLoop addPort:macPort forMode:NSDefaultRunLoopMode];
    7. [subRunLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
    8. NSLog(@"while end");
    9. NSLog(@"%@",subRunLoop);
    10. }
    11. });

    这样我们可以看到能够实现了和主线程中相同的效果,线程在这个地方暂停了,为什么呢?我们明天让RunLoop在distantFuture之前都一直run的啊?相信大家已经猜出出来了。这个时候线程被RunLoop带到‘坑’里去了,这个‘坑’就是一个循环,在循环中这个线程可以在没有任务的时候休眠,在有任务的时候被唤醒;当然我们只用一个while(1)也可以让这个线程一直存在,但是这个线程会一直在唤醒状态,及时它没有任务也一直处于运转状态,这对于CPU来说是非常不高效的。
    小结:我们的RunLoop要想工作,必须要让它存在一个Item(source,observer或者timer),主线程之所以能够一直存在,并且随时准备被唤醒就是应为系统为其添加了很多Item

    三、深入理解Perform Selector

    我们先在主线程中使用下performselector:

    1. - (void)tryPerformSelectorOnMianThread{
    2. [self performSelector:@selector(mainThreadMethod) withObject:nil]; }
    3. - (void)mainThreadMethod{
    4. NSLog(@"execute %s",__func__);
    5. // print: execute -[ViewController mainThreadMethod]
    6. }

    这样我们在ViewDidLoad中调用tryPerformSelectorOnMianThread,就会立即执行,并且输出:print: execute -[ViewController mainThreadMethod];
    和上面的例子一样,我们使用GCD,让这个方法在后台线程中执行

    1. - (void)tryPerformSelectorOnBackGroundThread{
    2. dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    3. [self performSelector:@selector(backGroundThread) onThread:[NSThread currentThread] withObject:nil waitUntilDone:NO];
    4. });
    5. }
    6. - (void)backGroundThread{
    7. NSLog(@"%u",[NSThread isMainThread]);
    8. NSLog(@"execute %s",__FUNCTION__);
    9. }

    同样的,我们调用tryPerformSelectorOnBackGroundThread这个方法,我们会发现,下面的backGroundThread不会被调用,这是什么原因呢?
    这是因为,在调用performSelector:onThread: withObject: waitUntilDone的时候,系统会给我们创建一个Timer的source,加到对应的RunLoop上去,然而这个时候我们没有RunLoop,如果我们加上RunLoop:

    1. - (void)tryPerformSelectorOnBackGroundThread{
    2. dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    3. [self performSelector:@selector(backGroundThread) onThread:[NSThread currentThread] withObject:nil waitUntilDone:NO];
    4. NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
    5. [runLoop run];
    6. });
    7. }

    这时就会发现我们的方法正常被调用了。那么为什么主线程中的perfom selector却能够正常调用呢?通过上面的例子相信你已经猜到了,主线程的RunLoop是一直存在的,所以我们在主线程中执行的时候,无需再添加RunLoop。从Apple的文档中我们也可以得到验证:

    Each request to perform a selector is queued on the target thread’s run loop and the requests are then processed sequentially in the order in which they were received. 每个执行perform selector的请求都以队列的形式被放到目标线程的run loop中。然后目标线程会根据进入run loop的顺序来一一执行。

    小结:当perform selector在后台线程中执行的时候,这个线程必须有一个开启的runLoop

    四、一直"活着"的后台线程

    现在有这样一个需求,每点击一下屏幕,让子线程做一个任务,然后大家一般会想到这样的方式:

    1. @interface ViewController ()
    2. @property(nonatomic,strong) NSThread *myThread;
    3. @end
    4. @implementation ViewController
    5. - (void)alwaysLiveBackGoundThread{
    6. NSThread *thread = [[NSThread alloc]initWithTarget:self selector:@selector(myThreadRun) object:@"etund"];
    7. self.myThread = thread;
    8. [self.myThread start];
    9. }
    10. - (void)myThreadRun{
    11. NSLog(@"my thread run");
    12. }
    13. - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event{
    14. NSLog(@"%@",self.myThread);
    15. [self performSelector:@selector(doBackGroundThreadWork) onThread:self.myThread withObject:nil waitUntilDone:NO];
    16. }
    17. - (void)doBackGroundThreadWork{
    18. NSLog(@"do some work %s",__FUNCTION__);
    19. }
    20. @end

    这个方法中,我们利用一个强引用来获取了后台线程中的thread,然后在点击屏幕的时候,在这个线程上执行doBackGroundThreadWork这个方法,此时我们可以看到,在touchesBegin方法中,self.myThread是存在的,但是这是为是什么呢?这就要从线程的五大状态来说明了:新建状态、就绪状态、运行状态、阻塞状态、死亡状态,这个时候尽管内存中还有线程,但是这个线程在执行完任务之后已经死亡了,经过上面的论述,我们应该怎样处理呢?我们可以给这个线程的RunLoop添加一个source,那么这个线程就会检测这个source等待执行,而不至于死亡(有工作的强烈愿望而不死亡):

    1. - (void)myThreadRun{
    2. [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
    3. [[NSRunLoop currentRunLoop] run]
    4. NSLog(@"my thread run");
    5. }

    这个时候再次点击屏幕,我们就会发现,后台线程中执行的任务可以正常进行了。
    小结:正常情况下,后台线程执行完任务之后就处于死亡状态,我们要避免这种情况的发生可以利用RunLoop,并且给它一个Source这样来保证线程依旧还在

    五、深入理解NSTimer

    我们平时使用NSTimer,一般是在主线程中的,代码大多如下:

    1. - (void)tryTimerOnMainThread{
    2. NSTimer *myTimer = [NSTimer scheduledTimerWithTimeInterval:0.5 target:self
    3. selector:@selector(timerAction) userInfo:nil repeats:YES];
    4. [myTimer fire];
    5. }
    6. - (void)timerAction{
    7. NSLog(@"timer action");
    8. }

    这个时候代码按照我们预定的结果运行,如果我们把这个Tiemr放到后台线程中呢?

    1. dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    2. NSTimer *myTimer = [NSTimer scheduledTimerWithTimeInterval:0.5 target:self selector:@selector(timerAction) userInfo:nil repeats:YES];
    3. [myTimer fire];
    4. });

    这个时候我们会发现,这个timer只执行了一次,就停止了。这是为什么呢?通过上面的讲解,想必你已经知道了,NSTimer,只有注册到RunLoop之后才会生效,这个注册是由系统自动给我们完成的,既然需要注册到RunLoop,那么我们就需要有一个RunLoop,我们在后台线程中加入如下的代码:

    1. NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
    2. [runLoop run];

    这样我们就会发现程序正常运行了。在Timer注册到RunLoop之后,RunLoop会为其重复的时间点注册好事件,比如1:10,1:20,1:30这几个时间点。有时候我们会在这个线程中执行一个耗时操作,这个时候RunLoop为了节省资源,并不会在非常准确的时间点回调这个Timer,这就造成了误差(Timer有个冗余度属性叫做tolerance,它标明了当前点到后,容许有多少最大误差),可以在执行一段循环之后调用一个耗时操作,很容易看到timer会有很大的误差,这说明在线程很闲的时候使用NSTiemr是比较傲你准确的,当线程很忙碌时候会有较大的误差。系统还有一个CADisplayLink,也可以实现定时效果,它是一个和屏幕的刷新率一样的定时器。如果在两次屏幕刷新之间执行一个耗时的任务,那其中就会有一个帧被跳过去,造成界面卡顿。另外GCD也可以实现定时器的效果,由于其和RunLoop没有关联,所以有时候使用它会更加的准确,这在最后会给予说明。

    六、让两个后台线程有依赖性的一种方式

    给两个后台线程添加依赖可能有很多的方式,这里说明一种利用RunLoop实现的方式。原理很简单,我们先让一个线程工作,当工作完成之后唤醒另外的一线程,通过上面对RunLoop的说明,相信大家很容易能够理解这些代码:

    1. - (void)runLoopAddDependance{
    2. self.runLoopThreadDidFinishFlag = NO;
    3. NSLog(@"Start a New Run Loop Thread");
    4. NSThread *runLoopThread = [[NSThread alloc] initWithTarget:self selector:@selector(handleRunLoopThreadTask) object:nil];
    5. [runLoopThread start];
    6. NSLog(@"Exit handleRunLoopThreadButtonTouchUpInside");
    7. dispatch_async(dispatch_get_global_queue(0, 0), ^{
    8. while (!_runLoopThreadDidFinishFlag) {
    9. self.myThread = [NSThread currentThread];
    10. NSLog(@"Begin RunLoop");
    11. NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
    12. NSPort *myPort = [NSPort port];
    13. [runLoop addPort:myPort forMode:NSDefaultRunLoopMode];
    14. [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
    15. NSLog(@"End RunLoop");
    16. [self.myThread cancel];
    17. self.myThread = nil;
    18. }
    19. });
    20. }
    21. - (void)handleRunLoopThreadTask
    22. {
    23. NSLog(@"Enter Run Loop Thread");
    24. for (NSInteger i = 0; i < 5; i ++) {
    25. NSLog(@"In Run Loop Thread, count = %ld", i);
    26. sleep(1);
    27. }
    28. #if 0
    29. // 错误示范
    30. _runLoopThreadDidFinishFlag = YES;
    31. // 这个时候并不能执行线程完成之后的任务,因为Run Loop所在的线程并不知道runLoopThreadDidFinishFlag被重新赋值。Run Loop这个时候没有被任务事件源唤醒。
    32. // 正确的做法是使用 "selector"方法唤醒Run Loop。 即如下:
    33. #endif
    34. NSLog(@"Exit Normal Thread");
    35. [self performSelector:@selector(tryOnMyThread) onThread:self.myThread withObject:nil waitUntilDone:NO];
    36. // NSLog(@"Exit Run Loop Thread");
    37. }

    七、NSURLConnection的执行过程

    在使用NSURLConnection时,我们会传入一个Delegate,当我们调用了[connection start]之后,这个Delegate会不停的收到事件的回调。实际上,start这个函数的内部会获取CurrentRunloop,然后在其中的DefaultMode中添加4个source。如下图所示,CFMultiplexerSource是负责各种Delegate回调的,CFHTTPCookieStorage是处理各种Cookie的。如下图所示:

    NSURLConnection的执行过程


    从中可以看出,当开始网络传输是,我们可以看到NSURLConnection创建了两个新的线程:com.apple.NSURLConnectionLoader和com.apple.CFSocket.private。其中CFSocket是处理底层socket链接的。NSURLConnectionLoader这个线程内部会使用RunLoop来接收底层socket的事件,并通过之前添加的source,来通知(唤醒)上层的Delegate。这样我们就可以理解我们平时封装网络请求时候常见的下面逻辑了:

     

    1. while (!_isEndRequest)
    2. {
    3. NSLog(@"entered run loop");
    4. [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
    5. }
    6. NSLog(@"main finished,task be removed");
    7. - (void)connectionDidFinishLoading:(NSURLConnection *)connection
    8. {
    9. _isEndRequest = YES;
    10. }

    这里我们就可以解决下面这些疑问了:

    1. 为什么这个While循环不停的执行,还需要使用一个RunLoop? 程序执行一个while循环是不会耗费很大性能的,我们这里的目的是想让子线程在有任务的时候处理任务,没有任务的时候休眠,来节约CPU的开支。
    2. 如果没有为RunLoop添加item,那么它就会立即退出,这里的item呢? 其实系统已经给我们默认添加了4个source了。
    3. 既然[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];让线程在这里停下来,那么为什么这个循环会持续的执行呢?因为这个一直在处理任务,并且接受系统对这个Delegate的回调,也就是这个回调唤醒了这个线程,让它在这里循环。

    八、AFNetWorking中是如何使用RunLoop的?

    在AFN中AFURLConnectionOperation是基于NSURLConnection构建的,其希望能够在后台线程来接收Delegate的回调。
    为此AFN创建了一个线程,然后在里面开启了一个RunLoop,然后添加item

    1. + (void)networkRequestThreadEntryPoint:(id)__unused object {
    2. @autoreleasepool {
    3. [[NSThread currentThread] setName:@"AFNetworking"];
    4. NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
    5. [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
    6. [runLoop run];
    7. }
    8. }
    9. + (NSThread *)networkRequestThread {
    10. static NSThread *_networkRequestThread = nil;
    11. static dispatch_once_t oncePredicate;
    12. dispatch_once(&oncePredicate, ^{
    13. _networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
    14. [_networkRequestThread start];
    15. });
    16. return _networkRequestThread;
    17. }

    这里这个NSMachPort的作用和上文中的一样,就是让线程不至于在很快死亡,然后RunLoop不至于退出(如果要使用这个MachPort的话,调用者需要持有这个NSMachPort,然后在外部线程通过这个port发送信息到这个loop内部,它这里没有这么做)。然后和上面的做法相似,在需要后台执行这个任务的时候,会通过调用:[NSObject performSelector:onThread:..]来将这个任务扔给后台线程的RunLoop中来执行。

    1. - (void)start {
    2. [self.lock lock];
    3. if ([self isCancelled]) {
    4. [self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    5. } else if ([self isReady]) {
    6. self.state = AFOperationExecutingState;
    7. [self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
    8. }
    9. [self.lock unlock];
    10. }

    GCD定时器的实现

    1. - (void)gcdTimer{
    2. // get the queue
    3. dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
    4. // creat timer
    5. self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue);
    6. // config the timer (starting time,interval)
    7. // set begining time
    8. dispatch_time_t start = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC));
    9. // set the interval
    10. uint64_t interver = (uint64_t)(1.0 * NSEC_PER_SEC);
    11. dispatch_source_set_timer(self.timer, start, interver, 0.0);
    12. dispatch_source_set_event_handler(self.timer, ^{
    13. // the tarsk needed to be processed async
    14. dispatch_async(dispatch_get_global_queue(0, 0), ^{
    15. for (int i = 0; i < 100000; i++) {
    16. NSLog(@"gcdTimer");
    17. }
    18. });
    19. });
    20. dispatch_resume(self.timer);

    链接:https://www.jianshu.com/p/536184bfd163
    收起阅读 »

    还不会Hook?一份React Hook学习笔记

    Hook 是 React 16.8.0 版本增加的新特性,可以在函数组件中使用 state 以及其他的 React 特性。 ✌️为什么要使用 Hook? 在组件之间复用状态逻辑很难 由providers,consumers,高阶组件,render prop...
    继续阅读 »

    Hook 是 React 16.8.0 版本增加的新特性,可以在函数组件中使用 state 以及其他的 React 特性。


    ✌️为什么要使用 Hook?




    • 在组件之间复用状态逻辑很难


      providersconsumers,高阶组件,render props等其他抽象层组成的组件会形成嵌套地狱,使用 Hook 可以从组件中提取状态逻辑,使得这些逻辑可以单独测试并复用。Hook 使你在无需修改组件结构的情况下复用状态逻辑




    • 复杂组件难以理解


      每个生命周期常常包含一些不相关的逻辑。例如,组件常常在 componentDidMountcomponentDidUpdate 中获取数据。但是,同一个 componentDidMount 中可能也包含很多其它的逻辑,如设置事件监听,而之后需在 componentWillUnmount 中清除。相互关联且需要对照修改的代码被进行了拆分,而完全不相关的代码却在同一个方法中组合在一起。




    • 难以理解的 class




    下面介绍几个常用的Hook。


    2. useState


    useState让函数组件也可以有state状态,并进行状态数据的读写操作。


    const [xxx, setXxx] = useState(initValue); // 解构赋值

    📐useState() 方法


    参数


    第一次初始化指定的值在内部作缓存。可以按照需要使用数字字符串对其进行赋值,而不一定是对象


    如果想要在state中存储两个不同的变量,只需调用 useState() 两次即可。


    返回值


    包含2个元素的数组,第1个为内部当前状态值,第2个为更新状态值的函数,一般直接采用解构赋值获取。


    📐setXxx() 的写法


    setXxx(newValue):参数为非函数值,直接指定新的状态值,内部用其覆盖原来的状态值


    setXxx(value => newValue):参数为函数接收原本的状态值,返回新的状态值,内部用其覆盖原来的状态值。


    📐 完整示例


    const App = () => {
    const [count, setCount] = useState(0);

    const add = () => {
    // 第一种写法
    // setCount(count + 1);
    // 第二种写法
    setCount(count => count + 1);
    };

    return (
    <Fragment>
    <h2>当前求和为:{count}</h2>
    <button onClick={add}>点我+1</button>
    </Fragment>
    );
    };

    useState就是一个 Hook,唯一的参数就是初始state,在这里声明了一个叫count的 state 变量,然后把它设为0。React会在重复渲染时记住它当前的值,并且提供最新的值给我们的函数。我们可以通过调用setCount来更新当前的count


    在函数中,我们可以直接用 count


    <h2>当前求和为:{count}</h2>

    更新state


    setCount(count + 1);
    setCount(count => count + 1);

    📐 使用多个 state 变量


    可以在一个组件中多次使用State Hook


    // 声明多个 state 变量
    const [age, setAge] = useState(42);
    const [fruit, setFruit] = useState('banana');
    const [todos, setTodos] = useState([{ text: '学习 Hook' }]);

    📌不是必须要使用多个state变量,仍然可以将相关数据分为一组。但是,不像 class 中的 this.setStateuseState中更新state变量是替换。不是合并


    3. useEffect


    useEffect可以在函数组件中执行副作用操作(用于模拟类组件中的生命周期钩子)。


    React 中的副作用操作



    • ajax 请求数据获取

    • 设置订阅 / 启动定时器

    • 手动更改真实 DOM


    📐 使用规则


    useEffect(() => {
    // 在此可以执行任何带副作用操作
    // 相当于componentDidMount()
    return () => {
    // 在组件卸载前执行
    // 在此做一些收尾工作, 比如清除定时器/取消订阅等
    // 相当于componentWillUnmount()
    };
    }, [stateValue]); // 监听stateValue
    // 如果省略数组,则检测所有的状态,状态有更新就又调用一次回调函数
    // 如果指定的是[], 回调函数只会在第一次render()后执行一次

    可以把 useEffect 看做如下三个函数的组合:



    • componentDidMount()

    • componentDidUpdate()

    • componentWillUnmount()


    📐 每次更新的时候都运行 Effect


    // ...
    useEffect(() => {
    // ...
    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
    ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
    });

    调用一个新的 effect 之前会对前一个 effect 进行清理。下面按时间列出一个可能会产生的订阅和取消订阅操作调用序列:


    // Mount with { friend: { id: 100 } } props
    ChatAPI.subscribeToFriendStatus(100, handleStatusChange); // 运行第一个 effect

    // Update with { friend: { id: 200 } } props
    ChatAPI.unsubscribeFromFriendStatus(100, handleStatusChange); // 清除上一个 effect
    ChatAPI.subscribeToFriendStatus(200, handleStatusChange); // 运行下一个 effect

    // Update with { friend: { id: 300 } } props
    ChatAPI.unsubscribeFromFriendStatus(200, handleStatusChange); // 清除上一个 effect
    ChatAPI.subscribeToFriendStatus(300, handleStatusChange); // 运行下一个 effect

    // Unmount
    ChatAPI.unsubscribeFromFriendStatus(300, handleStatusChange); // 清除最后一个 effect

    📐 通过跳过 Effect 进行性能优化


    如果某些特定值在两次重渲染之间没有发生变化,可以通知 React 跳过对 effect 的调用,只要传递数组作为 useEffect第二个可选参数即可:


    useEffect(() => {
    document.title = `You clicked ${count} times`;
    }, [count]); // 仅在 count 更改时更新

    如果 count 的值是 5,而且组件重渲染的时候 count 还是等于 5,React 将对前一次渲染的 [5] 和后一次渲染的 [5] 进行比较。因为数组中的所有元素都是相等的(5 === 5),React 会跳过这个 effect,这就实现了性能的优化。


    当渲染时,如果 count 的值更新成了 6,React 将会把前一次渲染时的数组 [5] 和这次渲染的数组 [6] 中的元素进行对比。这次因为 5 !== 6,React 就会再次调用 effect。


    📌 如果数组中有多个元素,即使只有一个元素发生变化,React 也会执行 effect。


    对于有清除操作的 effect 同样适用:


    useEffect(() => {
    function handleStatusChange(status) {
    setIsOnline(status.isOnline);
    }

    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
    ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
    }, [props.friend.id]); // 仅在 props.friend.id 发生变化时,重新订阅

    📐 使用多个 Effect 实现关注点分离


    使用 Hook 其中一个目的就是要解决 class 中生命周期函数经常包含不相关的逻辑,但又把相关逻辑分离到了几个不同方法中的问题。下述代码是将前述示例中的计数器好友在线状态指示器逻辑组合在一起的组件:


    function FriendStatusWithCounter(props) {
    const [count, setCount] = useState(0);
    useEffect(() => {
    document.title = `You clicked ${count} times`;
    });

    const [isOnline, setIsOnline] = useState(null);
    useEffect(() => {
    function handleStatusChange(status) {
    setIsOnline(status.isOnline);
    }

    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
    return () => {
    ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
    };
    });
    // ...
    }

    📐 完整示例


    import React, { useState, Fragment, useEffect } from 'react';
    import ReactDOM from 'react-dom';

    const App = () => {
    const [count, setCount] = useState(0);

    useEffect(() => {
    let timer = setInterval(() => {
    setCount(count => count + 1);
    }, 500);
    console.log('@@@@');
    return () => {
    clearInterval(timer);
    };
    }, [count]);
    // 检测count的变化,每次变化,都会输出'@@@@'
    // 如果是[],则只会输出一次'@@@@'

    const add = () => {
    setCount(count => count + 1);
    };

    const unmount = () => {
    ReactDOM.unmountComponentAtNode(document.getElementById('root'));
    };

    return (
    <Fragment>
    <h2>当前求和为:{count}</h2>
    <button onClick={add}>点我+1</button>
    <button onClick={unmount}>卸载组件</button>
    </Fragment>
    );
    };

    export default App;

    4. useRef


    useRef可以在函数组件中存储 / 查找组件内的标签或任意其它数据。保存标签对象,功能与 React.createRef() 一样。


    const refContainer = useRef(initialValue);

    useRef 返回一个可变的 ref 对象,其 .current 属性被初始化为传入的参数(initialValue)。返回的 ref 对象在组件的整个生命周期内保持不变。


    📌 当 ref 对象内容发生变化时,useRef不会通知你。变更 .current 属性不会引发组件重新渲染。


    import React, { Fragment, useRef } from 'react';

    const Demo = () => {
    const myRef = useRef();

    //提示输入的回调
    function show() {
    console.log(myRef.current.value);
    }

    return (
    <Fragment>
    <input type="text" ref={myRef} />
    <button onClick={show}>点击显示值</button>
    </Fragment>
    );
    };

    export default Demo;

    5. Hook规则


    Hook 就是 JavaScript 函数,但是使用它们会有两个额外的规则:


    只在最顶层使用 Hook


    不要在循环,条件或嵌套函数中调用 Hook ,在 React 函数的最顶层调用 Hook。


    如果想要有条件地执行一个 effect,可以将判断放到 Hook 的内部


    useEffect(function persistForm() {
    // 👍 将条件判断放置在 effect 中
    if (name !== '') {
    localStorage.setItem('formData', name);
    }
    });

    只在 React 函数中调用 Hook


    不要在普通的 JavaScript 函数中调用 Hook。可以:



    • 在 React 的函数组件中调用 Hook

    • 在自定义 Hook 中调用其他 Hook




    链接:https://juejin.cn/post/6992733298493489183
    收起阅读 »

    图解React源码 - React 应用的3种启动方式

    在前文reconciler 运作流程把reconciler的流程归结成 4 个步骤. 本章节主要讲解react应用程序的启动过程, 位于react-dom包, 衔接reconciler 运作流程中的输入步骤. 在正式分析源码之前, 先了解一下react应用的启...
    继续阅读 »

    在前文reconciler 运作流程reconciler的流程归结成 4 个步骤.


    本章节主要讲解react应用程序的启动过程, 位于react-dom包, 衔接reconciler 运作流程中的输入步骤.


    在正式分析源码之前, 先了解一下react应用的启动模式:


    在当前稳定版react@17.0.2源码中, 有 3 种启动方式. 先引出官网上对于这 3 种模式的介绍, 其基本说明如下:




    1. legacy 模式: ReactDOM.render(<App />, rootNode). 这是当前 React app 使用的方式. 这个模式可能不支持这些新功能(concurrent 支持的所有功能).


      // LegacyRoot
      ReactDOM.render(<App />, document.getElementById('root'), dom => {}); // 支持callback回调, 参数是一个dom对象



    2. Blocking 模式: ReactDOM.createBlockingRoot(rootNode).render(<App />). 目前正在实验中, 它仅提供了 concurrent 模式的小部分功能, 作为迁移到 concurrent 模式的第一个步骤.


      // BolckingRoot
      // 1. 创建ReactDOMRoot对象
      const reactDOMBolckingRoot = ReactDOM.createBlockingRoot(
      document.getElementById('root'),
      );
      // 2. 调用render
      reactDOMBolckingRoot.render(<App />); // 不支持回调



    3. Concurrent 模式: ReactDOM.createRoot(rootNode).render(<App />). 目前在v18.0.0-alpha,和experiment版本中发布. 这个模式开启了所有的新功能.


      // ConcurrentRoot
      // 1. 创建ReactDOMRoot对象
      const reactDOMRoot = ReactDOM.createRoot(document.getElementById('root'));
      // 2. 调用render
      reactDOMRoot.render(<App />); // 不支持回调



    注意: 虽然17.0.2的源码中有createRootcreateBlockingRoot方法(如果自行构建, 会默认构建experimental版本), 但是稳定版的构建入口排除掉了这两个 api, 所以实际在npm i react-dom安装17.0.2稳定版后, 不能使用该 api.如果要想体验非legacy模式, 需要显示安装alpha版本(或自行构建).


    启动流程


    在调用入口函数之前,reactElement(<App/>)和 DOM 对象div#root之间没有关联, 用图片表示如下:


    process-before.png


    创建全局对象


    无论Legacy, Concurrent或Blocking模式, react 在初始化时, 都会创建 3 个全局对象



    1. ReactDOM(Blocking)Root对象





    1. fiberRoot对象



      • 属于react-reconciler包, 作为react-reconciler在运行过程中的全局上下文, 保存 fiber 构建过程中所依赖的全局状态.

      • 其大部分实例变量用来存储fiber 构造循环(详见两大工作循环)过程的各种状态.react 应用内部, 可以根据这些实例变量的值, 控制执行逻辑.




    2. HostRootFiber对象



      • 属于react-reconciler包, 这是 react 应用中的第一个 Fiber 对象, 是 Fiber 树的根节点, 节点的类型是HostRoot.




    这 3 个对象是 react 体系得以运行的基本保障, 一经创建大多数场景不会再销毁(除非卸载整个应用root.unmount()).


    这一过程是从react-dom包发起, 内部调用了react-reconciler包, 核心流程图如下(其中红色标注了 3 个对象的创建时机).


    function-call.png


    下面逐一解释这 3 个对象的创建过程.


    创建 ReactDOM(Blocking)Root 对象


    由于 3 种模式启动的 api 有所不同, 所以从源码上追踪, 也对应了 3 种方式. 最终都 new 一个ReactDOMRootReactDOMBlockingRoot的实例, 需要创建过程中RootTag参数, 3 种模式各不相同. 该RootTag的类型决定了整个 react 应用是否支持可中断渲染(后文有解释).


    下面根据 3 种 mode 下的启动函数逐一分析.


    legacy 模式


    legacy模式表面上是直接调用ReactDOM.render, 跟踪ReactDOM.render后续调用legacyRenderSubtreeIntoContainer(源码链接)


    function legacyRenderSubtreeIntoContainer(
    parentComponent: ?React$Component<any, any>,
    children: ReactNodeList,
    container: Container,
    forceHydrate: boolean,
    callback: ?Function,
    ) {
    let root: RootType = (container._reactRootContainer: any);
    let fiberRoot;
    if (!root) {
    // 初次调用, root还未初始化, 会进入此分支
    //1. 创建ReactDOMRoot对象, 初始化react应用环境
    root = container._reactRootContainer = legacyCreateRootFromDOMContainer(
    container,
    forceHydrate,
    );
    fiberRoot = root._internalRoot;
    if (typeof callback === 'function') {
    const originalCallback = callback;
    callback = function() {
    // instance最终指向 children(入参: 如<App/>)生成的dom节点
    const instance = getPublicRootInstance(fiberRoot);
    originalCallback.call(instance);
    };
    }
    // 2. 更新容器
    unbatchedUpdates(() => {
    updateContainer(children, fiberRoot, parentComponent, callback);
    });
    } else {
    // root已经初始化, 二次调用render会进入
    // 1. 获取ReactDOMRoot对象
    fiberRoot = root._internalRoot;
    if (typeof callback === 'function') {
    const originalCallback = callback;
    callback = function() {
    const instance = getPublicRootInstance(fiberRoot);
    originalCallback.call(instance);
    };
    }
    // 2. 调用更新
    updateContainer(children, fiberRoot, parentComponent, callback);
    }
    return getPublicRootInstance(fiberRoot);
    }

    继续跟踪legacyCreateRootFromDOMContainer. 最后调用new ReactDOMBlockingRoot(container, LegacyRoot, options);


    function legacyCreateRootFromDOMContainer(
    container: Container,
    forceHydrate: boolean,
    ): RootType {
    const shouldHydrate =
    forceHydrate || shouldHydrateDueToLegacyHeuristic(container);
    return createLegacyRoot(
    container,
    shouldHydrate
    ? {
    hydrate: true,
    }
    : undefined,
    );
    }

    export function createLegacyRoot(
    container: Container,
    options?: RootOptions,
    ): RootType {
    return new ReactDOMBlockingRoot(container, LegacyRoot, options); // 注意这里的LegacyRoot是固定的, 并不是外界传入的
    }

    通过以上分析,legacy模式下调用ReactDOM.render有 2 个核心步骤:



    1. 创建ReactDOMBlockingRoot实例(在 Concurrent 模式和 Blocking 模式中详细分析该类), 初始化 react 应用环境.

    2. 调用updateContainer进行更新.


    Concurrent 模式和 Blocking 模式


    Concurrent模式和Blocking模式从调用方式上直接可以看出



    1. 分别调用ReactDOM.createRootReactDOM.createBlockingRoot创建ReactDOMRootReactDOMBlockingRoot实例

    2. 调用ReactDOMRootReactDOMBlockingRoot实例的render方法


    export function createRoot(
    container: Container,
    options?: RootOptions,
    ): RootType {
    return new ReactDOMRoot(container, options);
    }

    export function createBlockingRoot(
    container: Container,
    options?: RootOptions,
    ): RootType {
    return new ReactDOMBlockingRoot(container, BlockingRoot, options); // 注意第2个参数BlockingRoot是固定写死的
    }

    继续查看ReactDOMRootReactDOMBlockingRoot对象


    function ReactDOMRoot(container: Container, options: void | RootOptions) {
    // 创建一个fiberRoot对象, 并将其挂载到this._internalRoot之上
    this._internalRoot = createRootImpl(container, ConcurrentRoot, options);
    }
    function ReactDOMBlockingRoot(
    container: Container,
    tag: RootTag,
    options: void | RootOptions,
    ) {
    // 创建一个fiberRoot对象, 并将其挂载到this._internalRoot之上
    this._internalRoot = createRootImpl(container, tag, options);
    }

    ReactDOMRoot.prototype.render = ReactDOMBlockingRoot.prototype.render = function(
    children: ReactNodeList,
    ): void {
    const root = this._internalRoot;
    // 执行更新
    updateContainer(children, root, null, null);
    };

    ReactDOMRoot.prototype.unmount = ReactDOMBlockingRoot.prototype.unmount = function(): void {
    const root = this._internalRoot;
    const container = root.containerInfo;
    // 执行更新
    updateContainer(null, root, null, () => {
    unmarkContainerAsRoot(container);
    });
    };

    ReactDOMRootReactDOMBlockingRoot有相同的特性



    1. 调用createRootImpl创建fiberRoot对象, 并将其挂载到this._internalRoot上.

    2. 原型上有renderumount方法, 且内部都会调用updateContainer进行更新.


    创建 fiberRoot 对象


    无论哪种模式下, 在ReactDOM(Blocking)Root的创建过程中, 都会调用一个相同的函数createRootImpl, 查看后续的函数调用, 最后会创建fiberRoot 对象(在这个过程中, 特别注意RootTag的传递过程):


    // 注意: 3种模式下的tag是各不相同(分别是ConcurrentRoot,BlockingRoot,LegacyRoot).
    this._internalRoot = createRootImpl(container, tag, options);

    function createRootImpl(
    container: Container,
    tag: RootTag,
    options: void | RootOptions,
    ) {
    // ... 省略部分源码(有关hydrate服务端渲染等, 暂时用不上)
    // 1. 创建fiberRoot
    const root = createContainer(container, tag, hydrate, hydrationCallbacks); // 注意RootTag的传递
    // 2. 标记dom对象, 把dom和fiber对象关联起来
    markContainerAsRoot(root.current, container);
    // ...省略部分无关代码
    return root;
    }

    export function createContainer(
    containerInfo: Container,
    tag: RootTag,
    hydrate: boolean,
    hydrationCallbacks: null | SuspenseHydrationCallbacks,
    ): OpaqueRoot {
    // 创建fiberRoot对象
    return createFiberRoot(containerInfo, tag, hydrate, hydrationCallbacks); // 注意RootTag的传递
    }

    创建 HostRootFiber 对象


    createFiberRoot中, 创建了react应用的首个fiber对象, 称为HostRootFiber(fiber.tag = HostRoot)


    export function createFiberRoot(
    containerInfo: any,
    tag: RootTag,
    hydrate: boolean,
    hydrationCallbacks: null | SuspenseHydrationCallbacks,
    ): FiberRoot {
    // 创建fiberRoot对象, 注意RootTag的传递
    const root: FiberRoot = (new FiberRootNode(containerInfo, tag, hydrate): any);

    // 1. 这里创建了`react`应用的首个`fiber`对象, 称为`HostRootFiber`
    const uninitializedFiber = createHostRootFiber(tag);
    root.current = uninitializedFiber;
    uninitializedFiber.stateNode = root;
    // 2. 初始化HostRootFiber的updateQueue
    initializeUpdateQueue(uninitializedFiber);

    return root;
    }

    在创建HostRootFiber时, 其中fiber.mode属性, 会与 3 种RootTag(ConcurrentRoot,BlockingRoot,LegacyRoot)关联起来.


    export function createHostRootFiber(tag: RootTag): Fiber {
    let mode;
    if (tag === ConcurrentRoot) {
    mode = ConcurrentMode | BlockingMode | StrictMode;
    } else if (tag === BlockingRoot) {
    mode = BlockingMode | StrictMode;
    } else {
    mode = NoMode;
    }
    return createFiber(HostRoot, null, null, mode); // 注意这里设置的mode属性是由RootTag决定的
    }

    注意:fiber树中所节点的mode都会和HostRootFiber.mode一致(新建的 fiber 节点, 其 mode 来源于父节点),所以HostRootFiber.mode非常重要, 它决定了以后整个 fiber 树构建过程.


    运行到这里, 3 个对象创建成功, react应用的初始化完毕.


    将此刻内存中各个对象的引用情况表示出来:



    1. legacy


    process-legacy.png



    1. concurrent


    process-concurrent.png



    1. blocking


    process-blocking.png


    注意:



    1. 3 种模式下,HostRootFiber.mode是不一致的

    2. legacy 下, div#rootReactDOMBlockingRoot之间通过_reactRootContainer关联. 其他模式是没有关联的

    3. 此时reactElement(<App/>)还是独立在外的, 还没有和目前创建的 3 个全局对象关联起来


    调用更新入口



    1. legacy
      回到legacyRenderSubtreeIntoContainer函数中有:


    // 2. 更新容器
    unbatchedUpdates(() => {
    updateContainer(children, fiberRoot, parentComponent, callback);
    });


    1. concurrent 和 blocking
      ReactDOM(Blocking)Root原型上有render方法


    ReactDOMRoot.prototype.render = ReactDOMBlockingRoot.prototype.render = function(
    children: ReactNodeList,
    ): void {
    const root = this._internalRoot;
    // 执行更新
    updateContainer(children, root, null, null);
    };

    相同点:



    1. 3 种模式在调用更新时都会执行updateContainer. updateContainer函数串联了react-domreact-reconciler, 之后的逻辑进入了react-reconciler包.


    不同点:




    1. legacy下的更新会先调用unbatchedUpdates, 更改执行上下文为LegacyUnbatchedContext, 之后调用updateContainer进行更新.




    2. concurrentblocking不会更改执行上下文, 直接调用updateContainer进行更新.




    继续跟踪updateContainer函数


    export function updateContainer(
    element: ReactNodeList,
    container: OpaqueRoot,
    parentComponent: ?React$Component<any, any>,
    callback: ?Function,
    ): Lane {
    const current = container.current;
    // 1. 获取当前时间戳, 计算本次更新的优先级
    const eventTime = requestEventTime();
    const lane = requestUpdateLane(current);

    // 2. 设置fiber.updateQueue
    const update = createUpdate(eventTime, lane);
    update.payload = { element };
    callback = callback === undefined ? null : callback;
    if (callback !== null) {
    update.callback = callback;
    }
    enqueueUpdate(current, update);

    // 3. 进入reconcier运作流程中的`输入`环节
    scheduleUpdateOnFiber(current, lane, eventTime);
    return lane;
    }

    updateContainer函数位于react-reconciler包中, 它串联了react-domreact-reconciler. 此处暂时不深入分析updateContainer函数的具体功能, 需要关注其最后调用了scheduleUpdateOnFiber.


    在前文reconciler 运作流程中, 重点分析过scheduleUpdateOnFiber输入阶段的入口函数.


    所以到此为止, 通过调用react-dom包的api(如: ReactDOM.render), react内部经过一系列运转, 完成了初始化, 并且进入了reconciler 运作流程的第一个阶段.


    思考


    可中断渲染


    react 中最广为人知的可中断渲染(render 可以中断, 部分生命周期函数有可能执行多次, UNSAFE_componentWillMount,UNSAFE_componentWillReceiveProps)只有在HostRootFiber.mode === ConcurrentRoot | BlockingRoot才会开启. 如果使用的是legacy, 即通过ReactDOM.render(<App/>, dom)这种方式启动时HostRootFiber.mode = NoMode, 这种情况下无论是首次 render 还是后续 update 都只会进入同步工作循环, reconciliation没有机会中断, 所以生命周期函数只会调用一次.


    对于可中断渲染的宣传最早来自2017 年 Lin Clark 的演讲. 演讲中阐述了未来 react 会应用 fiber 架构, reconciliation可中断等(13:15 秒). 在v16.1.0中应用了 fiber.


    在最新稳定版v17.0.2中, 可中断渲染虽然实现, 但是并没有在稳定版暴露出 api. 只能安装alpha版本才能体验该特性.


    但是不少开发人员认为稳定版本的react已经是可中断渲染(其实是有误区的), 大概率也是受到了各类宣传文章的影响. 前端大环境还是比较浮躁的, 在当下, 更需要静下心来学习.


    总结


    本章节介绍了react应用的 3 种启动方式. 分析了启动后创建了 3 个关键对象, 并绘制了对象在内存中的引用关系. 启动过程最后调用updateContainer进入react-reconciler包,进而调用schedulerUpdateOnFiber函数, 与reconciler运作流程中的输入阶段相衔接.


    写在最后


    本文属于图解react源码系列中的运行核心板块, 本系列近 20 篇文章,真的是为了搞懂React源码, 进而提升架构和编码能力.


    目前图解部分初稿已经全部完成, 将在8月全部更新, 如文章有表述错误, 会在github第一时间修正.


    链接:https://juejin.cn/post/6992771308157141022
    收起阅读 »

    白话聊React为何采用函数式编程的不可变数据

    前言 大家好,今天来聊一下React采用函数式编程的理念:不可变数据。 看到标题的你不用担心,你可能在顾虑需要函数式编程的知识,完全不需要,今天我们就0基础聊聊什么是不可变数据?React采用这种方式有什么好处? 例子 React采用函数式编程的不可变数据特性...
    继续阅读 »

    前言


    大家好,今天来聊一下React采用函数式编程的理念:不可变数据。


    看到标题的你不用担心,你可能在顾虑需要函数式编程的知识,完全不需要,今天我们就0基础聊聊什么是不可变数据?React采用这种方式有什么好处?


    例子


    React采用函数式编程的不可变数据特性。


    而在React中不可变值的意思就是:始终保持state的原值不变。


    不要直接修改state,遇到数组或者对象,采用copy一份出去做改变。


    举个简单的例子:


    基本类型


    错误的做法:


    this.state.count++
    this.setState({
    count:this.state.count
    })

    正确的做法:


    this.setState({
    count:this.state.count + 1
    })

    引用类型


    错误的做法:



    this.state.obj1.a = 100
    this.state.obj2.a = 100
    this.setState({
    obj1: this.state.obj1,
    obj2: this.state.obj2
    })

    正确的做法:


    this.setState({
    obj1: Object.assign({}, this.state.obj1, {a: 100}),
    obj2: {...this.state.obj2, a: 100}
    })

    函数式编程不可变值的优势


    我们先聊聊函数式编程中不可变值的好处。


    减少bug


    好比我们用const定义一个变量,如果你要改变这个变量,你需要把变量copy出去修改。
    这样的做法,可以让你的代码少非常多的bug


    生成简单的状态管理便于维护


    因为,程序中的状态是非常不好维护的,特别是在并发的情况下更不好维护。
    试想一下:如果你的代码有一个复杂的状态,当以后别人改你代码的时候,是很容易出bug的。


    React中采用函数式编程的不可变值


    我们再来看看React中采用函数式编程


    性能优化


    在生命周期 shouldComponentUpdate 中,React会对新旧state进行比较,如果直接修改state去用于其他变量的计算,而实际上state并不需要修改,则会导致怪异的更新以及没必要的更新,因此采用这种方式是非常巧妙,且效率非常的高。


    可追踪修改痕迹,便于排错


    使用this.setState的方式进行修改state的值,相当于开了一个改变值的口子,所有的修改都会走这样的口子,相比于直接修改,这样的控制力更强,能够有效地记录与追踪每个state的改变,对排查bug十分有帮助。


    结尾


    关于React函数式编程你有什么观点或者想法,欢迎在评论区告诉我。


    链接:https://juejin.cn/post/6992919744165150751

    收起阅读 »

    这几个关键的数据结构都不会,你也配学react源码???

    不知道大家在学习react源码的时候有没有这样的感觉:fiber对象的结构太复杂了,不仅是属性繁多,而且有些属性还是个巨复杂的对象。我在学习hooks的时候,这种感觉尤为强烈。那么,这篇文章就以fiber.memoizedState和fiber.updateQ...
    继续阅读 »

    不知道大家在学习react源码的时候有没有这样的感觉:fiber对象的结构太复杂了,不仅是属性繁多,而且有些属性还是个巨复杂的对象。我在学习hooks的时候,这种感觉尤为强烈。那么,这篇文章就以fiber.memoizedStatefiber.updateQueue这两个重要属性为例,梳理一下他们的结构和作用,希望对大家阅读源码有帮助。


    先来看类组件


    首先来看类组件。类组件的fiber.memoizedStatefiber.updateQueue比较简单,memoizedState就是我们定义的state对象,updateQueue的结构如下:


    fiber.updateQueue {
    baseState,
    firstBaseUpdate,
    lastBaseUpdate,
    shared: {
    pending,
    },
    effects
    }

    首先,前三个属性baseStatefirstBaseUpdatelastBaseUpdate是和可中断更新相关的。在concurrent mode下,当前的更新可能被更高优先级的更新打断,而baseState就记录了被跳过的update节点之前计算出的statefirstBaseStatelastBaseUpdate构成一条链表,记录因为优先级不足而被跳过的所有更新。shared.pending才是真正记录了所有update对象的链表,这是一条环形链表,shared.pending指向该链表的最后一个update对象,effects则是一个数组,存储了setState的回调函数。关于类组件的state计算原理,可以看我的这篇文章,这里面有更加详细的讲解,本文还是主要介绍数据结构。


    看函数组件


    了解hooks原理的同学应该都知道,react使用链表来存储函数组件中用到的所有hooks,而这个链表就保存在fiber.memoizedState。这个hooks链表的每一项都是hook对象,hook对象的结构如下


    hook {
    memoizedState,
    baseState,
    baseQueue,
    queue,
    next
    }

    hooks链表.jpg



    没错,fiber.memoizedState指向了hook链表,而每个hook对象还有一个memoizedState对象!!!



    不论是哪种hook,都会使用这一种数据结构,而有些hook可能只会用到其中的几个属性。下面,就由简入繁,介绍不同的hook都用到了哪些属性。


    useCallback, useMemo, useRef


    这三个hook都只使用到了hook.memoizedState这一个属性。


    useCallback接受一个需要缓存的函数和依赖数组,而hook.memoizedState则保存了一个数组,数组内放了缓存函数和依赖数组


    function mountCallback(callback, deps) {
    var hook = mountWorkInProgressHook();
    var nextDeps = deps === undefined ? null : deps;
    hook.memoizedState = [callback, nextDeps];
    return callback;
    }

    useMemouseCallback基本一致,只不过useMemo保存了函数的返回值


    function mountMemo(nextCreate, deps) {
    var hook = mountWorkInProgressHook();
    var nextDeps = deps === undefined ? null : deps;
    var nextValue = nextCreate();
    hook.memoizedState = [nextValue, nextDeps];
    return nextValue;
    }

    至于useRef就能简单了,保存一个对象即可


    function mountRef(initialValue) {
    var hook = mountWorkInProgressHook();
    var ref = {
    current: initialValue
    };

    {
    Object.seal(ref);
    }

    hook.memoizedState = ref;
    return ref;
    }

    这里使用Object.seal封闭了ref对象,Object.seal就是在不可扩展(Object.preventExtensions)的基础上不可配置(configurable变为false)。


    useState


    看完了三个简单的hook,现在加大一点难度,看看useState


    useState就比较复杂了,用到了hook对象身上的所有属性


    hook {
    memoizedState: 保存的state,
    baseState:和类组件的updateQueue.baseState作用相同,
    baseQueue: 和类组件的updateQueue.firstBaseUpdate和lastBaseUpdate作用相同,
    queue: {
    pending: 保存update对象的环状链表,
    dispatch: dispatchAction,useState的第二个返回值,
    lastRenderedReducer: 上次更新时用到的reducer,
    lastRenderedState: 上次更新的state
    }
    }

    这里需要注意一点,useState中用到了hook.queue这个属性,而hook.queue.pending和类组件的updateQueue.shared.pending比较类似,都是用来保存update对象的。而使用useState时,fiber.updateQueuenull,也就是说和类组件不同,useState并没有用到updateQueue,这一点容易让人困惑。


    useEffect


    接下来看看我个人认为最复杂的hookuseEffect。说他复杂,是因为useEffect的数据结构很绕,下面一起来看一下


    首先,关于hook对象身上的几个属性,useEffect只用到了一个,就是memoizedState,而在memoizedState上保存的又是一个effect对象


    hook {
    memoized: {
    tag: 用于区分是useEffect还是useLayoutEffect,
    create: 就是useEffect的回调函数,
    destory: useEffect回调的返回值,
    deps: 依赖数组,
    next: 下一个effect对象,构成环装链表
    },
    baseState: null,
    baseQueue: null,
    queue: null
    }

    此外,useEffect还用到了fiber.updateQueue,这个updateQueue的结构还和类组件的不一样


    // 类组件的updateQueue
    {
    baseState,
    firstBaseUpdate,
    lastBaseUpdate,
    shared: {
    pending
    },
    effects
    }

    // useEffect的updateQueue
    {
    lastEffect
    }

    useEffect不仅将effect对象放在了hook.memoized上,还放在了fiber.updateQueue上,并且都是环形链表


    举个🌰


    前面说了这么多,可能大家还是比较困惑,下面看个实际的例子


    const App = () => {
    const [num, setNum] = useState(1)
    const handleClick1 = useCallback(() => {
    setNum((pre) => pre + 1)
    }, [])

    const [count, setCount] = useState(1)
    const handleClick2 = useCallback(() => {
    setCount((pre) => pre + 1)
    }, [])

    useEffect(() => {
    console.log('1st effect', num)
    }, [num])

    useEffect(() => {
    console.log('2nd effect', num)
    }, [num])

    useLayoutEffect(() => {
    console.log('use layout', count)
    }, [count])

    return (
    <div>
    <p>{num}</p>
    <p>{count}</p>
    <button onClick={handleClick1}>click me</button>
    <button onClick={handleClick2}>click me</button>
    </div>
    )
    }

    上面的例子中,我们使用了两个useState,并且每个事件处理函数都使用useCallback进行了包装,此外还有useEffectuseLayoutEffect,下面看一下



    1. 首先,执行useState,因此在fiber.memoizedState上挂载了一个useStatehook对象


    例子1.jpg



    1. 接下来执行到useCallback,在hooks链表中再添加一项


    例子2.jpg



    1. 接下来又是useStateuseCallback,因此和前两步一样


    例子3.jpg



    1. 之后来到比较复杂的useEffect了,useEffect不仅会添加hook对象到hooks链表中,还会修改updateQueue


    例子4.jpg



    1. 后面还是一个useEffect,这一步就比较复杂了


    例子5.jpg


    可以看到,使用useEffect时,不仅构成了hooks链表,effect对象也构成了一条环形链表



    1. 之后执行了useLayoutEffect


    例子6.jpg


    最后来总结一下这个例子


    例子总结.jpg


    链接:https://juejin.cn/post/6993150359317250085
    收起阅读 »

    react hooks 万字总结

    Hooks is what? react-hooks是react16.8以后,react新增的钩子API,它可以让你在不编写 class 的情况下使用 state 以及其他的 React 特性. Hook是一些可以让你在函数组件里“钩入” React sta...
    继续阅读 »

    Hooks is what?



    • react-hooks是react16.8以后,react新增的钩子API,它可以让你在不编写 class 的情况下使用 state 以及其他的 React 特性.

    • Hook是一些可以让你在函数组件里“钩入” React state 及生命周期等特性的函数。


    why use Hooks?


    类组件的缺点:(来自官网动机




    • 在组件之间复用状态逻辑很难




    • 复杂组件变得难以理解




    • 难以理解的 class




    你必须去理解 JavaScript 中 this 的工作方式,这与其他语言存在巨大差异。还不能忘记绑定事件处理器。没有稳定的语法提案,代码非常冗余。


    hooks的出现,解决了上面的问题。另外,还有一些其他的优点



    • 增加代码的可复用性,逻辑性,弥补无状态组件没有生命周期,没有数据管理状态state的缺陷

    • react-hooks思想更趋近于函数式编程。用函数声明方式代替class声明方式,虽说class也是es6构造函数语法糖,但是react-hooks写起来函数即是组件,无疑也提高代码的开发效率(无需像class声明组件那样写声明周期,写生命周期render函数等)


    Hooks没有破坏性改动



    • 完全可选的。  你无需重写任何已有代码就可以在一些组件中尝试 Hook。但是如果你不想,你不必现在就去学习或使用 Hook。

    • 100% 向后兼容的。  Hook 不包含任何破坏性改动。

    • 现在可用。  Hook 已发布于 v16.8.0。


    使用Hooks的规则


    1. 只在最顶层使用 Hook,不要在循环,条件或嵌套函数中调用 Hook


    确保总是在你的 React 函数的最顶层调用他们。遵守这条规则,你就能确保 Hook 在每一次渲染中都按照同样的顺序被调用。这让 React 能够在多次的 useState 和 useEffect 调用之间保持 hook 状态的正确。


    2. 只在 React 函数中调用 Hook


    不要在普通的 JavaScript 函数中调用 Hook,你可以:



    • ✅ 在 React 的函数组件中调用 Hook

    • ✅ 在自定义 Hook 中调用其他 Hook


    至于为什么会有这些规则,如果你感兴趣,请参考Hook 规则


    useState



    const [state, setState] = useState(initialState)




    • useState 有一个参数(initialState 可以是一个函数,返回一个值,但一般都不会这么用),该参数可以为任意数据类型,一般用作默认值.

    • useState 返回值为一个数组,数组的第一个参数为我们需要使用的 state,第二个参数为一个改变state的函数(功能和this.setState一样)


    来看一个计时器的案例


    import React,{useState} from "react";
    function Example() {
    const [count, setCount] = useState(0);
    return (
    <div>
    <p>You clicked {count} times</p>
    <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
    );
    }
    export default Example;


    • 第一行:  引入 React 中的 useState Hook。它让我们在函数组件中存储内部 state。

    • 第三行:  在 Example 组件内部,我们通过调用 useState Hook 声明了一个新的 state 变量。它返回一对值给到我们命名的变量上。我们把变量命名为 count,因为它存储的是点击次数。我们通过传 0 作为 useState 唯一的参数来将其初始化为 0。第二个返回的值本身就是一个函数。它让我们可以更新 count 的值,所以我们叫它 setCount

    • 第七行:  当用户点击按钮后,我们传递一个新的值给 setCount。React 会重新渲染 Example 组件,并把最新的 count 传给它。


    使用多个state 变量


     // 声明多个 state 变量
    const [age, setAge] = useState(42);
    const [fruit, setFruit] = useState('banana');
    const [todos, setTodos] = useState([{ text: '学习 Hook' }]);

    不必使用多个 state 变量。State 变量可以很好地存储对象和数组,因此,你仍然可以将相关数据分为一组。


    更新State


    import React,{useState} from "react";
    function Example() {
    const [count, setCount] = useState(0);
    const [person, setPerson] = useState({name:'jimmy',age:22});
    return (
    <div>
    <p>name {person.name} </p>
    // 如果新的 state 需要通过使用先前的 state 计算得出,那么可以将回调函数当做参数传递给 setState。
    // 该回调函数将接收先前的 state,并返回一个更新后的值。
    <button onClick={() => setCount(count=>count+1)}>Click me</button>
    <button onClick={() => setPerson({name:'chimmy'})}>Click me</button>
    </div>
    );
    }
    export default Example;
    复制代码

    setPerson更新person时,不像 class 中的 this.setState,更新 state 变量总是替换它而不是合并它。上例中的person为{name:'chimmy'} 而不是{name:'chimmy',age:22}


    useEffect


    Effect Hook 可以让你在函数组件中执行副作用(数据获取,设置订阅以及手动更改 React 组件中的 DOM 都属于副作用)操作



    useEffect(fn, array)



    useEffect在初次完成渲染之后都会执行一次, 配合第二个参数可以模拟类的一些生命周期。


    如果你熟悉 React class 的生命周期函数,你可以把 useEffect Hook 看做 componentDidMount``componentDidUpdate 和 componentWillUnmount 这三个函数的组合。


    useEffect 实现componentDidMount


    如果第二个参数为空数组,useEffect相当于类组件里面componentDidMount。


    import React, { useState, useEffect } from "react";
    function Example() {
    const [count, setCount] = useState(0);
    useEffect(() => {
    console.log("我只会在组件初次挂载完成后执行");
    }, []);
    return (
    <div>
    <p>You clicked {count} times</p>
    <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
    );
    }
    export default Example;

    页面渲染完成后,会执行一次useEffect。打印“我只会在组件初次挂载完成后执行”,当点击按钮改变了state,页面重新渲染后,useEffect不会执行。


    useEffect 实现componentDidUpdate


    如果不传第二个参数,useEffect 会在初次渲染和每次更新时,都会执行。


    import React, { useState, useEffect } from "react";
    function Example() {
    const [count, setCount] = useState(0);
    useEffect(() => {
    console.log("我会在初次组件挂载完成后以及重新渲染时执行");
    });
    return (
    <div>
    <p>You clicked {count} times</p>
    <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
    );
    }
    export default Example;

    初次渲染时,会执行一次useEffect,打印出“我会在初次组件挂载完成后以及重新渲染时执行”。
    当点击按钮时,改变了state,页面重新渲染,useEffect都会执行,打印出“我会在初次组件挂载完成后以及重新渲染时执行”。


    useEffect 实现componentWillUnmount


    effect 返回一个函数,React 将会在执行清除操作时调用它。


    useEffect(() => {
    console.log("订阅一些事件");
    return () => {
    console.log("执行清楚操作")
    }
    },[]);

    注意:这里不只是组件销毁时才会打印“执行清楚操作”,每次重新渲染时也都会执行。至于原因,我觉得官网解释的很清楚,请参考 解释: 为什么每次更新的时候都要运行 Effect


    控制useEffect的执行


    import React, { useState, useEffect } from "react";
    function Example() {
    const [count, setCount] = useState(0);
    const [number, setNumber] = useState(1);
    useEffect(() => {
    console.log("我只会在cout变化时执行");
    }, [count]);
    return (
    <div>
    <p>You clicked {count} times</p>
    <button onClick={() => setCount(count + 1)}>Click cout</button>
    <button onClick={() => setNumber(count + 1)}>Click number</button>
    </div>
    );
    }
    export default Example;

    上面的例子,在点击 click cout按钮时,才会打印“我只会在cout变化时执行”。 因为useEffect 的第二个参数的数组里面的依赖是cout,所以,只有cout发生改变时,useEffect 才会执行。如果数组中有多个元素,即使只有一个元素发生变化,React 也会执行 effect。


    使用多个 Effect 实现关注点分离


    使用 Hook 其中一个目的就是要解决 class 中生命周期函数经常包含不相关的逻辑,但又把相关逻辑分离到了几个不同方法中的问题。


    import React, { useState, useEffect } from "react";
    function Example() {
    useEffect(() => {
    // 逻辑一
    });
    useEffect(() => {
    // 逻辑二
    });
    useEffect(() => {
    // 逻辑三
    });
    return (
    <div>
    useEffect的使用
    </div>
    );
    }
    export default Example;

    Hook 允许我们按照代码的用途分离他们,  而不是像生命周期函数那样。React 将按照 effect 声明的顺序依次调用组件中的每一个 effect。


    useEffect中使用异步函数


    useEffect是不能直接用 async await 语法糖的


    /* 错误用法 ,effect不支持直接 async await*/
    useEffect(async ()=>{
    /* 请求数据 */
    const res = await getData()
    },[])

    useEffect 的回调参数返回的是一个清除副作用的 clean-up 函数。因此无法返回 Promise,更无法使用 async/await


    那我们应该如何让useEffect支持async/await呢?


    方法一(推荐)


    const App = () => {
    useEffect(() => {
    (async function getDatas() {
    await getData();
    })();
    }, []);
    return <div></div>;
    };

    方法二


      useEffect(() => {
    const getDatas = async () => {
    const data = await getData();
    setData(data);
    };
    getDatas();
    }, []);

    useEffect 做了什么


    通过使用这个 Hook,你可以告诉 React 组件需要在渲染后执行某些操作。React 会保存你传递的函数(我们将它称之为 “effect”),并且在执行 DOM 更新之后调用它。


    为什么在组件内部调用 useEffect


    将 useEffect 放在组件内部让我们可以在 effect 中直接访问 count state 变量(或其他 props)。我们不需要特殊的 API 来读取它 —— 它已经保存在函数作用域中。Hook 使用了 JavaScript 的闭包机制,而不用在 JavaScript 已经提供了解决方案的情况下,还引入特定的 React API。


    useContext


    概念



    const value = useContext(MyContext);



    接收一个 context 对象(React.createContext 的返回值)并返回该 context 的当前值。当组件上层最近的 <MyContext.Provider> 更新时,该 Hook 会触发重渲染,并使用最新传递给 MyContext provider 的 context value 值。即使祖先使用 React.memo 或 shouldComponentUpdate,也会在组件本身使用 useContext 时重新渲染。


    别忘记 useContext 的参数必须是 context 对象本身



    • 正确:  useContext(MyContext)

    • 错误:  useContext(MyContext.Consumer)

    • 错误:  useContext(MyContext.Provider)


    示例


    index.js


    import React from "react";
    import ReactDOM from "react-dom";
    import App from "./App";
    // 创建两个context
    export const UserContext = React.createContext();
    export const TokenContext = React.createContext();
    ReactDOM.render(
    <UserContext.Provider value={{ id: 1, name: "chimmy", age: "20" }}>
    <TokenContext.Provider value="我是token">
    <App />
    </TokenContext.Provider>
    </UserContext.Provider>,
    document.getElementById("root")
    );

    app.js


    import React, { useContext } from "react";
    import { UserContext, TokenContext } from "./index";

    function Example() {
    let user = useContext(UserContext);
    let token = useContext(TokenContext);
    console.log("UserContext", user);
    console.log("TokenContext", token);
    return (
    <div>
    name:{user?.name},age:{user?.age}
    </div>
    );
    }
    export default Example;

    打印的值如下


    41PXCT[XET_ZJ7]79K@~6JX.png


    提示


    如果你在接触 Hook 前已经对 context API 比较熟悉,那应该可以理解,useContext(MyContext) 相当于 class 组件中的 static contextType = MyContext 或者 <MyContext.Consumer>


    useContext(MyContext) 只是让你能够读取 context 的值以及订阅 context 的变化。你仍然需要在上层组件树中使用 <MyContext.Provider> 来为下层组件提供 context。


    useReducer


    概念



    const [state, dispatch] = useReducer(reducer, initialArg, init);



    useState 的替代方案。它接收一个形如 (state, action) => newState 的 reducer,并返回当前的 state 以及与其配套的 dispatch 方法。(如果你熟悉 Redux 的话,就已经知道它如何工作了。)


    在某些场景下,useReducer 会比 useState 更适用,例如 state 逻辑较复杂且包含多个子值,或者下一个 state 依赖于之前的 state 等。并且,使用 useReducer 还能给那些会触发深更新的组件做性能优化,因为你可以向子组件传递 dispatch 而不是回调函数


    注意点



    React 会确保 dispatch 函数的标识是稳定的,并且不会在组件重新渲染时改变。这就是为什么可以安全地从 useEffect 或 useCallback 的依赖列表中省略 dispatch



    示例


    import React, { useReducer } from "react";
    export default function Home() {
    function reducer(state, action) {
    switch (action.type) {
    case "increment":
    return { ...state, counter: state.counter + 1 };
    case "decrement":
    return { ...state, counter: state.counter - 1 };
    default:
    return state;
    }
    }
    const [state, dispatch] = useReducer(reducer, { counter: 0 });
    return (
    <div>
    <h2>Home当前计数: {state.counter}</h2>
    <button onClick={(e) => dispatch({ type: "increment" })}>+1</button>
    <button onClick={(e) => dispatch({ type: "decrement" })}>-1</button>
    </div>
    );
    }

    useCallback


    概念


    const memoizedCallback = useCallback(
    () => {
    doSomething(a, b);
    },
    [a, b],
    );

    返回一个 [memoized]回调函数。


    把内联回调函数及依赖项数组作为参数传入 useCallback,它将返回该回调函数的 memoized 版本,该回调函数仅在某个依赖项改变时才会更新。当你把回调函数传递给经过优化的并使用引用相等性去避免非必要渲染(例如 shouldComponentUpdate)的子组件时,它将非常有用。


    示例


    import React, { useState } from "react";
    // 子组件
    function Childs(props) {
    console.log("子组件渲染了");
    return (
    <>
    <button onClick={props.onClick}>改标题</button>
    <h1>{props.name}</h1>
    </>
    );
    }
    const Child = React.memo(Childs);
    function App() {
    const [title, setTitle] = useState("这是一个 title");
    const [subtitle, setSubtitle] = useState("我是一个副标题");
    const callback = () => {
    setTitle("标题改变了");
    };
    return (
    <div className="App">
    <h1>{title}</h1>
    <h2>{subtitle}</h2>
    <button onClick={() => setSubtitle("副标题改变了")}>改副标题</button>
    <Child onClick={callback} name="桃桃" />
    </div>
    );
    }

    执行结果如下图
    image.png


    当我点击改副标题这个 button 之后,副标题会变为「副标题改变了」,并且控制台会再次打印出子组件渲染了,这就证明了子组件重新渲染了,但是子组件没有任何变化,那么这次 Child 组件的重新渲染就是多余的,那么如何避免掉这个多余的渲染呢?


    找原因


    我们在解决问题的之前,首先要知道这个问题是什么原因导致的?


    咱们来分析,一个组件重新重新渲染,一般三种情况:



    1. 要么是组件自己的状态改变

    2. 要么是父组件重新渲染,导致子组件重新渲染,但是父组件的 props 没有改变

    3. 要么是父组件重新渲染,导致子组件重新渲染,但是父组件传递的 props 改变


    接下来用排除法查出是什么原因导致的:


    第一种很明显就排除了,当点击改副标题 的时候并没有去改变 Child 组件的状态;


    第二种情况,我们这个时候用 React.memo 来解决了这个问题,所以这种情况也排除。


    那么就是第三种情况了,当父组件重新渲染的时候,传递给子组件的 props 发生了改变,再看传递给 Child 组件的就两个属性,一个是 name,一个是 onClickname 是传递的常量,不会变,变的就是 onClick 了,为什么传递给 onClick 的 callback 函数会发生改变呢?其实在函数式组件里每次重新渲染,函数组件都会重头开始重新执行,那么这两次创建的 callback 函数肯定发生了改变,所以导致了子组件重新渲染。


    用useCallback解决问题


    const callback = () => {
    doSomething(a, b);
    }
    const memoizedCallback = useCallback(callback, [a, b])

    把函数以及依赖项作为参数传入 useCallback,它将返回该回调函数的 memoized 版本,这个 memoizedCallback 只有在依赖项有变化的时候才会更新。


    那么只需这样将传给Child组件callback函数的改造一下就OK了


    const callback = () => { setTitle("标题改变了"); };
    // 通过 useCallback 进行记忆 callback,并将记忆的 callback 传递给 Child
    <Child onClick={useCallback(callback, [])} name="桃桃" />

    这样我们就可以看到只会在首次渲染的时候打印出子组件渲染了,当点击改副标题和改标题的时候是不会打印子组件渲染了的。


    useMemo


    概念



    const cacheSomething = useMemo(create,deps)




    • create:第一个参数为一个函数,函数的返回值作为缓存值。

    • deps: 第二个参数为一个数组,存放当前 useMemo 的依赖项,在函数组件下一次执行的时候,会对比 deps 依赖项里面的状态,是否有改变,如果有改变重新执行 create ,得到新的缓存值。

    • cacheSomething:返回值,执行 create 的返回值。如果 deps 中有依赖项改变,返回的重新执行 create 产生的值,否则取上一次缓存值。


    useMemo原理


    useMemo 会记录上一次执行 create 的返回值,并把它绑定在函数组件对应的 fiber 对象上,只要组件不销毁,缓存值就一直存在,但是 deps 中如果有一项改变,就会重新执行 create ,返回值作为新的值记录到 fiber 对象上。


    示例


    function Child(){
    console.log("子组件渲染了")
    return <div>Child</div>
    }
    function APP(){
    const [count, setCount] = useState(0);
    const userInfo = {
    age: count,
    name: 'jimmy'
    }
    return <Child userInfo={userInfo}>
    }


    当函数组件重新render时,userInfo每次都将是一个新的对象,无论 count 发生改变没,都会导致 Child组件的重新渲染。


    而下面的则会在 count 改变后才会返回新的对象。


    function Child(){
    console.log("子组件渲染了")
    return <div>Child</div>
    }
    function APP(){
    const [count, setCount] = useState(0);
    const userInfo = useMemo(() => {
    return {
    name: "jimmy",
    age: count
    };
    }, [count]);
    return <Child userInfo={userInfo}>
    }

    实际上 useMemo 的作用不止于此,根据官方文档内介绍:以把一些昂贵的计算逻辑放到 useMemo 中,只有当依赖值发生改变的时候才去更新。


    import React, {useState, useMemo} from 'react';

    // 计算和的函数,开销较大
    function calcNumber(count) {
    console.log("calcNumber重新计算");
    let total = 0;
    for (let i = 1; i <= count; i++) {
    total += i;
    }
    return total;
    }
    export default function MemoHookDemo01() {
    const [count, setCount] = useState(100000);
    const [show, setShow] = useState(true);
    const total = useMemo(() => {
    return calcNumber(count);
    }, [count]);
    return (
    <div>
    <h2>计算数字的和: {total}</h2>
    <button onClick={e => setCount(count + 1)}>+1</button>
    <button onClick={e => setShow(!show)}>show切换</button>
    </div>
    )
    }

    当我们去点击 show切换按钮时,calcNumber这个计算和的函数并不会出现渲染了.只有count 发生改变时,才会出现计算.


    useCallback 和 useMemo 总结


    简单理解呢 useCallback 与 useMemo 一个缓存的是函数,一个缓存的是函数的返回就结果。useCallback 是来优化子组件的,防止子组件的重复渲染。useMemo 可以优化当前组件也可以优化子组件,优化当前组件主要是通过 memoize 来将一些复杂的计算逻辑进行缓存。当然如果只是进行一些简单的计算也没必要使用 useMemo。


    我们可以将 useMemo 的返回值定义为返回一个函数这样就可以变通的实现了 useCallback。useCallback(fn, deps) 相当于 useMemo(() => fn, deps)


    useRef



    const refContainer = useRef(initialValue);



    useRef 返回一个可变的 ref 对象,其 .current 属性被初始化为传入的参数(initialValue)。返回的 ref 对象在组件的整个生命周期内保持不变


    useRef 获取dom


    useRef,它有一个参数可以作为缓存数据的初始值,返回值可以被dom元素ref标记,可以获取被标记的元素节点.


    import React, { useRef } from "react";
    function Example() {
    const divRef = useRef();
    function changeDOM() {
    // 获取整个div
    console.log("整个div", divRef.current);
    // 获取div的class
    console.log("div的class", divRef.current.className);
    // 获取div自定义属性
    console.log("div自定义属性", divRef.current.getAttribute("data-clj"));
    }
    return (
    <div>
    <div className="div-class" data-clj="我是div的自定义属性" ref={divRef}>
    我是div
    </div>
    <button onClick={(e) => changeDOM()}>获取DOM</button>
    </div>
    );
    }
    export default Example;

    1.png


    useRef 缓存数据


    useRef还有一个很重要的作用就是缓存数据,我们知道usestate ,useReducer 是可以保存当前的数据源的,但是如果它们更新数据源的函数执行必定会带来整个组件从新执行到渲染,如果在函数组件内部声明变量,则下一次更新也会重置,如果我们想要悄悄的保存数据,而又不想触发函数的更新,那么useRef是一个很棒的选择。


    下面举一个,每次换成state 上一次值的例子


    import React, { useRef, useState, useEffect } from "react";
    function Example() {
    const [count, setCount] = useState(0);

    const numRef = useRef(count);

    useEffect(() => {
    numRef.current = count;
    }, [count]);

    return (
    <div>
    <h2>count上一次的值: {numRef.current}</h2>
    <h2>count这一次的值: {count}</h2>
    <button onClick={(e) => setCount(count + 10)}>+10</button>
    </div>
    );
    }
    export default Example;

    当 ref 对象内容发生变化时,useRef 并不会通知你。变更 .current 属性不会引发组件重新渲染。所以,上面的例子中虽然numRef.current的值,已经改变了,但是页面上还是显示的上一次的值,重新更新时,才会显示上一次更新的值。


    写在最后


    如果文章中有什么错误,欢迎指出。


    链接:https://juejin.cn/post/6993139082054336548

    收起阅读 »

    JAVA面向对象简介

    文章目录概念了解举例说明:创建一个Soldier类举例说明:创建一个FlashLight类举例说明:创建一个Car类类中包含的变量类中的方法概念了解Java是一种面向对象的程序设计语言,了解面向对象的编程思想对于学习Java开发相当重要。面向对象是一种符合人类...
    继续阅读 »

    文章目录

    概念了解

    Java是一种面向对象的程序设计语言,了解面向对象的编程思想对于学习Java开发相当重要。

    面向对象是一种符合人类思维习惯的编程思想。现实生活中存在各种形态不同的事物,这些事物之间存在着各种各样的联系。在程序中使用对象来映射现实中的事物,使用对象的关系来描述事物之间的联系,这种思想就是面向对象。

    面向对象和面向过程的区别
    提到面向对象,自然会想到面向过程,面向过程就是分析解决问题所需要的步骤,然后用函数把这些步骤一一实现,使用的时候一个一个依次调用就可以了。面向对象则是把解决的问题按照一定规则划分为多个独立的对象,然后通过调用对象的方法来解决问题。当然,一个应用程序会包含多个对象,通过多个对象的相互配合来实现应用程序的功能,这样当应用程序功能发生变动时,只需要修改个别的对象就可以了,从而使代码更容易得到维护。

    首先了解几个概念:


    类是一个模板,它描述一类对象的行为和状态。

    对象(实例)
    对象是类的一个实例(对象不是找个女朋友),有状态和行为。例如,一条狗是一个对象,它的状态有:颜色、名字、品种;行为有:摇尾巴、叫、吃等。
    每个对象占用独立的内存空间,保存各自的属性数据。
    每个对象可以独立控制,让它执行指定的方法代码。

    举例说明:创建一个Soldier类

    我们定义一个士兵类,他的属性有 id(表示他的唯一编号)、blood(表示他的血量)。他的行为有 go(前进)、attack(攻击)

    Soldier类

    public class Soldier {
    //成员变量
    int id;//唯一编号,默认0
    int blood = 100;//血量,默认满血


    //成员方法
    public void go(TextView tv) {
    if (blood == 0) {
    tv.setText(id + "已阵亡,无法前进" + "\n" + tv.getText());
    return;
    }
    tv.setText(id + "前进" + "\n" + tv.getText());
    }

    public void attack(TextView tv) {
    if (blood == 0) {
    tv.setText(id + "已阵亡,无法攻击" + "\n" + tv.getText());
    return;
    }

    tv.setText(+id + "号士兵发起进攻" + "]\n" + tv.getText());

    int b = new Random().nextInt(30);
    if (blood < b) {
    blood = b;
    }
    blood -= b;

    if (blood == 0) {
    tv.setText("["+id + "号士兵阵亡" + "\n" + tv.getText());
    } else {
    tv.setText("[士兵" + id + "进攻完毕,血量" + blood + "\n" + tv.getText());
    }
    }
    }

    xml

    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical">


    <Button
    android:id="@+id/button1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="新建士兵" />


    <Button
    android:id="@+id/button2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="前进" />


    <Button
    android:id="@+id/button3"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="进攻" />


    <TextView
    android:id="@+id/textView"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:textColor="#222222"
    android:textSize="15sp"/>

    </LinearLayout>

    MainActivity

    public class MainActivity extends AppCompatActivity {
    TextView textView;
    Soldier s1;//默认null

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    textView = findViewById(R.id.textView);
    }

    public void doClick(View view) {
    switch (view.getId()) {
    case R.id.button1:
    f1();
    break;
    case R.id.button2:
    f2();
    break;
    case R.id.button3:
    f3();
    break;
    }
    }

    public void f1() {
    s1 = new Soldier();
    s1.id = 9527;
    //用s1找到士兵对象内存空间
    //访问它的属性变量id
    textView.setText("士兵9527已创建" + "\n");
    }

    public void f2() {
    s1.go(textView);
    }

    public void f3() {
    s1.attack(textView);
    }
    }

    运行程序:
    在这里插入图片描述

    举例说明:创建一个FlashLight类

    我们来创建一个手电筒的类。它的属性有颜色、开光状态。它的方法有开灯、关灯

    FlashLight.java

    public class FlashLight {
    //属性变量,成员变量
    int color = Color.BLACK;
    boolean on = false;

    public void turnOn() {
    on = true;
    }

    public void turnOff() {
    on = false;
    }
    }

    xml

    <?xml version="1.0" encoding="utf-8"?>
    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/layout"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:background="@android:color/black"
    android:orientation="vertical">


    <ToggleButton
    android:id="@+id/toggleButton"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:textOff="关"
    android:textOn="开" />


    <Button
    android:id="@+id/button1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="红" />


    <Button
    android:id="@+id/button2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="白" />


    <Button
    android:id="@+id/button3"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="蓝" />


    </LinearLayout>

    MainActivity.java

    public class MainActivity extends AppCompatActivity {
    FlashLight flashLight = new FlashLight();
    LinearLayout linearLayout;
    ToggleButton toggleButton;

    Button red;
    Button white;
    Button blue;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    linearLayout = findViewById(R.id.layout);
    toggleButton = findViewById(R.id.toggleButton);
    red = findViewById(R.id.button1);
    white = findViewById(R.id.button2);
    blue = findViewById(R.id.button3);
    }

    public void doClick(View view) {
    switch (view.getId()) {
    case R.id.button1:
    f1();
    break;
    case R.id.button2:
    f2();
    break;
    case R.id.button3:
    f3();
    break;
    case R.id.toggleButton:
    f4();
    break;
    }
    }

    public void f1() {
    //用light变量找到手电筒对象的内存空间地址
    //访问它的color变量
    flashLight.color = Color.RED;
    show();
    }

    public void f2() {
    flashLight.color = Color.WHITE;
    show();
    }

    public void f3() {
    flashLight.color = Color.BLUE;
    show();
    }

    public void f4() {
    //判断开关指示按钮状态
    if (toggleButton.isChecked()) {
    flashLight.turnOn();
    } else {
    flashLight.turnOff();
    }
    show();
    }

    public void show() {
    //根据flashlight属性控制界面
    if (flashLight.on) {
    linearLayout.setBackgroundColor(flashLight.color);
    } else {
    linearLayout.setBackgroundColor(Color.BLACK);
    }
    }
    }

    运行程序:
    在这里插入图片描述

    举例说明:创建一个Car类

    我们来创建一个汽车类,它的属性有颜色color、品牌brand、速度speed。它的方法有前进、停止。
    Car.java

    public class Car {
    public String color;
    public String brand;
    public int speed;

    public void go(TextView tv) {
    tv.append("\n" + color + brand + "汽车以时速" + speed + "前进");
    }

    public void stop(TextView tv) {
    tv.append("\n" + color + brand + "汽车停止");
    }
    }

    xml

    <?xml version="1.0" encoding="utf-8"?>
    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">


    <Button
    android:id="@+id/button1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="创建汽车" />


    <Button
    android:id="@+id/button2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="go" />


    <Button
    android:id="@+id/button3"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="doClick"
    android:text="stop" />


    <TextView
    android:id="@+id/textView"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:textSize="18sp"
    android:textColor="#222222" />


    </LinearLayout>

    MainActivity

    public class MainActivity extends AppCompatActivity {
    Car car;

    Button create;
    Button go;
    Button stop;
    TextView textView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    create = findViewById(R.id.button1);
    go = findViewById(R.id.button2);
    stop = findViewById(R.id.button3);
    textView = findViewById(R.id.textView);
    }

    public void doClick(View view) {
    switch (view.getId()) {
    case R.id.button1:
    f1();
    break;
    case R.id.button2:
    f2();
    break;
    case R.id.button3:
    f3();
    break;
    }
    }

    private void f1() {
    car = new Car();
    //默认值如下
    //color="";
    //brand="";
    //speed=0;
    car.color = "红色";
    car.brand = "BMW";
    car.speed = 80;
    textView.setText("汽车已创建");
    }

    private void f2() {
    car.go(textView);
    }

    private void f3() {
    car.stop(textView);
    }
    }

    运行程序:
    在这里插入图片描述

    类中包含的变量

    一个类可以包含以下类型变量:
    1、局部变量
    在方法、构造方法或者语句块中定义的变量被称为局部变量。变量声明和初始化都是在方法中,方法结束后,变量就会自动销毁。
    局部变量有以下特点:
    ①必须手动初始化(分配内存空间),没有默认值
    ②局部变量作用域,到它定义的代码块为止
    ③作用域内不能重复定义

    void f1(){
    int a = 10;
    if(){
    int a = 9;//这样是不允许的,作用域范围内重复定义了
    print(a);
    }
    }
    void f1(){
    int a = 10;
    if(){
    print(a);
    int b = 100;
    }//此时b的作用范围已结束,可以再定义一个b,不是同一个
    int b = 1000;
    }

    2、成员变量
    成员变量是定义在类中,方法体之外的变量。这种变量在创建对象的时候实例化。成员变量可以被类中方法、构造方法和特定类的语句块访问。
    成员变量有以下特点:
    ①定义在类中,自动初始化,有默认值

    Int a;默认0
    boolean b;默认false
    int[] c;默认null

    例如我们第一个例子 Soldier 类中,唯一编号 id,默认值就是 0。
    ②访问范围:类中都可以访问,根据访问范围设置,类外也可以访问

    3、类变量
    类变量也声明在类中,方法体之外,但必须声明为 static 类型。
    关于关键字 static 后边的文章中会讲到


    收起阅读 »

    Android 渲染系列-绘制流程总览

    前言谈到Android的渲染,可能会想到测量、布局、绘制三大流程。但我们的view到底是如何一步一步显示到屏幕的?App的CPU/GPU渲染到底是什么?OpenGL/Vulkan/skia是什么? surfaceFlinger和HAL又是什么呢?带着这些问题,...
    继续阅读 »

    前言

    谈到Android的渲染,可能会想到测量、布局、绘制三大流程。但我们的view到底是如何一步一步显示到屏幕的?App的CPU/GPU渲染到底是什么?OpenGL/Vulkan/skia是什么? surfaceFlinger和HAL又是什么呢?

    带着这些问题,我们今天就深入的去学习Android绘制的整个流程吧。

    参考分层思想,我们大概把整个渲染分为App层和SurfaceFlinger层,先讲各层都做什么工作,后面在把二者联系起来。

    相关概念

    1. Vsync信号

    由系统设备产生。假设在60HZ的屏幕上,屏幕就会每16ms进行一次扫描,在两次扫描中间会有一个间隔,此时系统就会发出Vsync信号,来通知APP(Vsync-app)进行渲染,SurfaceFlinger(Vsync-sf)来进行swap缓冲区进行展示。因此,只要App的渲染过程(CPU计算+GPU绘制)不超过16ms,画面就会显得很流畅。

    说明:

    • 如果系统检测到硬件支持,则Vysnc信号由硬件产生,否则就由软件模拟产生。这个了解即可。
    • Vsync offset机制: Vsync-app、Vsync-sf并不是同时通知的,Vsync-sf会相对晚些,但对于我们App开发者来说,即可认为约等于同时发生。
    1. OpenGL、Vulkan、skia的关系
    • OpenGL: 是一种跨平台的3D图形绘制规范接口。OpenGL EL则是专门针对嵌入式设备,如手机做了优化。
    • Vulkan: 跟OpenGL相同功能,不过它同时支持3D、2D,比OpenGL更加的轻量、性能更高。
    • skia: skia是图像渲染库,2D图形绘制自己就能完成。3D效果(依赖硬件)由OpenGL、Vulkan、Metal支持。它不仅支持2D、3D,同时支持CPU软件绘制和GPU硬件加速。Android、flutter都是使用它来完成绘制。
    1. GPU和OpenGL什么关系

    OpenGL是规范,GPU就是该规范具体的设备实现者。

    1. Surface 与 graphic buffer

    插入一个问题: 一个Android程序有多少个window??

    应用本身+系统(menu+statusBar)+dialog+toast+popupWindow。

    Android的一个window对应一个surface(请注意: 一个surface不一定对应window。如surfaceView), 一个surface对应一个BufferQueue。 进程可以同时拥有多个surface,如使用surfaceView(封装了单独的surface,且在单独的子线程操作)。

    canvas 是通过surface.lockCnavas得到(最终调用JNI的framework层的surface.lock方法获取graphic buffer)。

    surface通过dequeue拿到graphic buffer,然后进行渲染绘制,渲染完成后回到BufferQueu队列,最后通知surfaceFlinger来消费。

    1. SurfaceFlinger 是什么?

    可以认为它是协调缓冲区数据和设备显示的协调者。 Vsync信号、三倍缓冲、缓冲区的合成操作都是由它来控制。

    1 Android渲染演变

    了解Android系统对渲染的不断优化历史,对于理解渲染很有帮助。

    • Android 4.1

    引入了project butter黄油计划:Vsync、三倍缓冲、choreography编舞者。

    • android 5.0

    引入了RenderThread线程(该线程是系统在framework层维护),把之前CPU直接操作绘制指令(OpenGL/vulkan/skia)部分,交给了单独的渲染线程。减少主线程的工作。即使主线程卡住,渲染也不受影响。

    • Android7.0 引入了Vulkan支持。 OpenGL是3D渲染API,VulKan是用来替换OpenGL的。它不仅支持3D,也支持2D,同时更加轻量级。

    2 App做了什么(重点)

    从invalidate()(它会在onVsync信号来的时候(也就是下一帧)触发onDraw()方法)方法调用开始来分析整个过程。Activity的显示最终会调用requestLayout方法,关于Activity的启动过程可以自行查阅(后续有空在写篇文章~)。

    invalidate()让 drawing cache(绘制缓存)无效,也就是所谓的标脏,所以才会要重新进行绘制。 requestLayout()方法跟invalidate()调用的是同一个方法:scheduleTraversals(),如下:

    ViewRootImpl.java

    void invalidate() {
    mDirty.set(0, 0, mWidth, mHeight);
    if (!mWillDrawSoon) {
    scheduleTraversals();
    }
    }
    @Override
    public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
    checkThread();
    mLayoutRequested = true;
    scheduleTraversals();
    }
    }
    void scheduleTraversals() {
    if (!mTraversalScheduled) {
    mTraversalScheduled = true;
    mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
    mChoreographer.postCallback(
    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    if (!mUnbufferedInputDispatch) {
    scheduleConsumeBatchedInput();
    }
    notifyRendererOfFramePending();
    pokeDrawLockIfNeeded();
    }
    }

    viewRootImpl的invalidate()方法会postCalback到choreography。

    choreography是在viewRootImpl创建的的时注册了监听系统的vsync信号。

    当onVsync回调下一帧的时候,就会执行choreography的doFrame()方法,然后执行callback,调用 viewRootImpl的performTraversal()--doTraversal()方法,从而执行onMeasure()、onLayout()、onDraw()三大流程。

    那UI线程如何与RenderThread交互呢? 什么时候把绘制好的数据交给SurfaceFlinger呢?

    image.png

    onMeasure()、onLayout()计算出view的大小和摆放的位置,这都是UI线程要做的事情。

    1. 在draw()方法中进行绘制,但此时是没有真正去绘制。而是把绘制的指令封装为displayList,进一步封装为RendNode,在同步给RenderThread。
    2. RenderThread通过 dequeue() 拿到graphic buffer(surfaceFlinger的缓冲区),根据绘制指令直接操作OpenGL的绘制接口,最终通过GPU设备把绘制指令渲染到了离屏缓冲区graphic buffer。
    3. 完成渲染后,把缓冲区交还给SurfaceFlinger的BufferQueue。SurfaceFlinger会通过硬件设备进行layer的合成,最终展示到屏幕。

    image.png

    以上流程也体现了生产者与消费者模式:

    image.png

    生产者: APP,再深入点就是canvas->surface。

    消费者:SurfaceFlinger

    BufferQueue 的大小一般是3。

    • 一块缓冲区用来被SurfaceFlinger交由设备展示
    • 一块用来App绘制缓冲数据
    • 还有一块,如果App绘制超过一帧时间16ms的时候,当下一帧vsync到来,其中两块都已经被占用,所以要用到第三块,避免此次vsync信号CPU和GPU处于空闲(因为如果空闲的话,下下帧就会出现jank)。

    SurfaceFlinger 做了什么

    SurfaceFlinger是显示合成系统。在应用程序请求创建surface的时候,SurfaceFlinger会创建一个Layer。Layer是SurfaceFlinger操作合成的基本单元。所以,一个surface对应一个Layer。

    当应用程序把绘制好的GraphicBuffer数据放入BufferQueue后,接下来的工作就是SurfaceFlinger来完成了。

    image.png

    说明:

    系统会有多个应用程序,一个程序有多个BufferQueue队列。SurfaceFlinger就是用来决定何时以及怎么去管理和显示这些队列的。

    SurfaceFlinger请求HAL硬件层,来决定这些Buffer是硬件来合成还是自己通过OpenGL来合成。

    最终把合成后的buffer数据,展示在屏幕上。

    最后,附上官方完整渲染架构:

    image.png

    收起阅读 »

    Android Activity通讯方式

    Android Activity通讯方式Activity 之间传递信息是很常见的方式,比如页面的跳转需要携带信息,比如第一个页面的参数需要到第二个页面显示,Android中对这种传值通讯提供了多种方式,这些方式又有什么异同呢。一、Bundle传递含义:把数据封...
    继续阅读 »

    Android Activity通讯方式

    Activity 之间传递信息是很常见的方式,比如页面的跳转需要携带信息,比如第一个页面的参数需要到第二个页面显示,Android中对这种传值通讯提供了多种方式,这些方式又有什么异同呢。

    一、Bundle传递

    含义:把数据封装在Bundle 对象中,通过 Intent 跳转时携带。

    伪代码

    传递基本数据类型和String类型


    // 传递
    Bundle bundle = new Bundle();
    bundle.putString("name", "Jack");
    bundle.putInt("id", 1);

    Intent intent = new Intent(this, MainActivity2.class);
    intent.putExtras(bundle);
    startActivity(intent);

    // 接收
    Bundle bundle = getIntent().getExtras();
    String name = bundle.getString("name");
    int id = bundle.getInt("id");

    Log.d("===", "name:" + name + " _ id:" + id);

    传递对象

    对象传递前需要对对象进行序列化,否则会报错。

    需要注意的是

    通过序列化传递的对象,传输和接收的对象虽然内容相同,但是引用地址是不同的。 也就是说改了接收的对象改了值,原始传递页面的对象不受影响

    • 何为序列化?

    序列化是为了将对象数据转换成字节流的形式,方便进行传输。 所以在传递的对象的时候我们需要进行序列化,在接收端再进行反序列化就可以恢复对象。

    • 如何实现序列化

    Serializable 和 Parcelable

    Serializable: 实体类直接实现Serializable接口


    import java.io.Serializable;
    public class Student implements Serializable {

    private int id;
    private String name;

    public Student() {
    }

    public Student(int id, String name) {
    this.id = id;
    this.name = name;
    }

    public int getId() {
    return id;
    }

    public void setId(int id) {
    this.id = id;
    }

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }
    }


    // 发送
    Student student = new Student(1, "Jack");
    Bundle bundle = new Bundle();bundle.putSerializable("student", student);
    Intent intent = new Intent(this, MainActivity2.class);
    intent.putExtras(bundle);startActivity(intent);


    // 接收
    Bundle bundle = getIntent().getExtras();
    Student student = (Student) bundle.getSerializable("student");
    Log.d("===", "person:"+student.getName());

    Parcelable: 实现接口并且实现方法

    import android.os.Parcel;
    import android.os.Parcelable;

    public class Student implements Parcelable {

    private int id;
    private String name;

    public Student() {
    }

    public Student(int id, String name) {
    this.id = id;
    this.name = name;
    }

    protected Student(Parcel in) {
    id = in.readInt();
    name = in.readString();
    }

    public static final Creator<Student> CREATOR = new Creator<Student>() {
    @Override
    public Student createFromParcel(Parcel in) {
    return new Student(in);
    }

    @Override
    public Student[] newArray(int size) {
    return new Student[size];
    }
    };

    public int getId() {
    return id;
    }

    public void setId(int id) {
    this.id = id;
    }

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }

    @Override
    public int describeContents() {
    return 0;
    }

    @Override
    public void writeToParcel(Parcel dest, int flags) {
    dest.writeInt(id);
    dest.writeString(name);
    }
    }


    // 发送
    Student student = new Student(1, "Jack");
    Bundle bundle = new Bundle();
    bundle.putParcelable("student", student);
    Intent intent = new Intent(this, MainActivity2.class);
    intent.putExtras(bundle);
    startActivity(intent);

    // 接收
    Bundle bundle = getIntent().getExtras();
    Student student = (Student) bundle.getParcelable("student");
    Log.d("===", "person:"+student.getName());

    从代码看来,Serializable 来自Java,而Parcelable 来自Android,Parcelable 是Android优化过后的产物,在相同条件下,Parcelable 可以减少很大的内存占用。

    二、广播传递

    广播是Android 中的四大组件之一,相当于一个全局监听器,可以监听其它App或者系统的广播消息。

    在Activity之间虽然也可以传递数据,但是有点大材小用。

    三、外部存储

    如果有大量的数据,在 A Activity 中可以将数据临时保存在存储卡中,跳转到B Activity 后再从存储卡中取出。

    四、静态变量

    将数据保存在静态变量中,在 A Activity 中对静态变量进行赋值,跳转到B Activity 后从静态变量获取数据,然后回收静态变量。

    五、Application 中转

    自定义的application类,临时保存变量,为了代码整洁,一般不用。

    六、ARouter

    Arouter 也有一些传递消息的方法。比如 withObject、withString 等

    看看它们的内部方法

    /**
    * Set object value, the value will be convert to string by 'Fastjson'
    *
    * @param key a String, or null
    * @param value a Object, or null
    * @return current
    */
    public Postcard withObject(@Nullable String key, @Nullable Object value) {
    serializationService = ARouter.getInstance().navigation(SerializationService.class);
    mBundle.putString(key, serializationService.object2Json(value));
    return this;
    }


    /**
    * Inserts a String value into the mapping of this Bundle, replacing
    * any existing value for the given key. Either key or value may be null.
    *
    * @param key a String, or null
    * @param value a String, or null
    * @return current
    */
    public Postcard withString(@Nullable String key, @Nullable String value) {
    mBundle.putString(key, value);
    return this;
    }


    同样是用Bundle传输,原理和Bundle一致。

    七、EventBus

    在使用Bundle传递数据时,当数据量过大(超过1M时),就会抛出 TransactionTooLargeException 异常。

    使用 EventBus 可以很轻松的解决这个问题。

    1. EventBus简介

    EventBus是一种用于Android的事件发布-订阅总线,由GreenRobot开发,可以很方便的进行数据传递。

    2. EventBus 三个组成部分

    • Event:事件,它可以是任意类型,EventBus会根据事件类型进行全局的通知。
    • Subscriber:事件订阅者,在EventBus 3.0之前我们必须定义以onEvent开头的那几个方法,分别是onEvent、onEventMainThread、onEventBackgroundThread和onEventAsync,而在3.0之后事件处理的方法名可以随意取,不过需要加上注解@subscribe,并且指定线程模型,默认是POSTING。
    • Publisher:事件的发布者,可以在任意线程里发布事件。一般情况下,使用EventBus.getDefault()就可以得到一个EventBus对象,然后再调用post(Object)方法即可。

    3. EventBus 四种线程模型

    • POSTING:默认,表示事件处理函数的线程跟发布事件的线程在同一个线程。
    • MAIN:表示事件处理函数的线程在主线程(UI)线程,因此在这里不能进行耗时操作。
    • BACKGROUND:表示事件处理函数的线程在后台线程,因此不能进行UI操作。如果发布事件的线程是主线程(UI线程),那么事件处理函数将会开启一个后台线程,如果果发布事件的线程是在后台线程,那么事件处理函数就使用该线程。
    • ASYNC:表示无论事件发布的线程是哪一个,事件处理函数始终会新建一个子线程运行,同样不能进行UI操作。

    4. EventBus 实战

    4.1 引入依赖

    implementation 'org.greenrobot:eventbus:3.1.1'

    4.2 新建一个实体类,作为传递的对象

    public class MessageInfo {

        private String message;

        public MessageInfo(String message) {
            this.message = message;
        }

        public String getMessage() {
            return message;
        }

        public void setMessage(String message) {
            this.message = message;
        }
    }

    4.3 定义接收事件

    Activity:

    public class MainActivity extends AppCompatActivity {
      
      private TextView tv;

        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);

            tv = findViewById(R.id.tv);

            EventBus.getDefault().register(this); //初始化EventBus
        }


        @Override
        protected void onDestroy() {
            super.onDestroy();

            EventBus.getDefault().unregister(this); //释放
        }


        // 定义接收的事件
        @Subscribe(threadMode = ThreadMode.MAIN)
        public void getMessage(MessageInfo messageInfo) {
            tv.setText(messageInfo.getMessage());
            Toast.makeText(this, "接收到的消息为:" + messageInfo.getMessage(), Toast.LENGTH_SHORT).show();
        }


        public void GoMain2Activity(View view) {
            Intent intent = new Intent(this, Main2Activity.class);
            startActivity(intent);
        }
    }

    layout:

    <?xml version="1.0" encoding="utf-8"?>
    <android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        xmlns:tools="http://schemas.android.com/tools"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".MainActivity">

        <Button
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:onClick="GoMain2Activity"
            android:text="Hello World!"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toTopOf="parent" />


        <TextView
            android:id="@+id/tv"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text=""/>

    </android.support.constraint.ConstraintLayout>

    4.4 定义发送事件

    Activity:

    public class Main2Activity extends AppCompatActivity {

        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main2);
        }


        /**
         * 发送消息
         *
         * @param view
         */
        public void publishMessage(View view) {
            EventBus.getDefault().post(new MessageInfo("小李子"));
        }
    }

    layout:

    <?xml version="1.0" encoding="utf-8"?>
    <android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        xmlns:tools="http://schemas.android.com/tools"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".Main2Activity">

        <Button
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Hello World!"
            app:layout_constraintBottom_toBottomOf="parent"
            app:layout_constraintLeft_toLeftOf="parent"
            app:layout_constraintRight_toRightOf="parent"
            app:layout_constraintTop_toTopOf="parent"
            android:onClick="publishMessage"/>

    </android.support.constraint.ConstraintLayout>

    4.5 粘性事件

    所谓的黏性事件,就是指发送了该事件之后再订阅者依然能够接收到的事件。使用黏性事件的时候有两个地方需要做些修改。一个是订阅事件的地方,这里我们在先打开的Activity中注册监听黏性事件: 添加 sticky = true 属性


    // 定义接收的事件
        @Subscribe(threadMode = ThreadMode.MAIN, sticky = true)
        public void getMessage(MessageInfo messageInfo) {
            tv.setText(messageInfo.getMessage());
            Toast.makeText(this, "接收到的消息为:" + messageInfo.getMessage(), Toast.LENGTH_SHORT).show();
        }

    在发送事件时使用postSticky来发送:

      /**
         * 发送消息
         *
         * @param view
         */
        public void publishMessage(View view) {
            EventBus.getDefault().postSticky(new MessageInfo("小李子"));
            Intent intent = new Intent(this, MainActivity.class);
            startActivity(intent);
        }


    4.6 优先级

    在Subscribe注解中总共有3个参数,上面我们用到了其中的两个,这里我们使用以下第三个参数,即priority。它用来指定订阅方法的优先级,是一个整数类型的值,默认是0,值越大表示优先级越大。在某个事件被发布出来的时候,优先级较高的订阅方法会首先接受到事件。 这里有几个地方需要注意:

    • 只有当两个订阅方法使用相同的ThreadMode参数的时候,它们的优先级才会与priority指定的值一致;
    • 只有当某个订阅方法的ThreadMode参数为POSTING的时候,它才能停止该事件的继续分发。

    八、EventBus 问题汇总(持续更新...)

    问题一、EventBus 粘性事件接收不到的问题

    1、起因

    由于EventBus发送的是对象,我们经常构建一个共用的对象,在共用对象中添加tag,用于方便在接收中区分作用。

    例如用EventBusHelper工具类发送EventBusMessage对象。

    2、遇到的问题

    在发送粘性事件时,在A场景发送了一次,然后还没有接收,然后在B场景又发送了一次,这时B发送的粘性事件可以收到,而A场景的粘性事件被替换掉了。

    这时因为在EventBus的源码中,粘性事件使用Map集合存储,key为 object.getClass(), 当我们自定义EventBusMessage的时候,导致object.getClass()一直是相同的,以至于会替换前一次的key。

        public void postSticky(Object event) {
    synchronized (stickyEvents) {
    stickyEvents.put(event.getClass(), event);
    }
    // Should be posted after it is putted, in case the subscriber wants to remove immediately
    post(event);
    }

    3、解决方法

    创造多个单独的对象,用于发送粘性服务。

    上面的方法比较Low,还没有想到比较优雅的方法,有的话分享出来吧。

    问题二、Post/postSticky 不能传递基本类型。

    eg: 使用post/postSticky直接传递,在Subscribe处接收int,此时收不到消息。 将int tag改为 Integer tag 就能收到。

    这时因为EventBus中要求传递的为Object,Object属于类类型,也就是复合数据类型,int属于简单数据类型。

     EventBus.getDefault().post(111);

    @Subscribe(threadMode = ThreadMode.MAIN)
    public void getMessage(int tag) {
    if (tag == 111)
    Log.d(TAG, "received");
    }



    收起阅读 »

    关于 PendingIntent 您需要知道的那些事

    PendingIntent 是 Android 框架中非常重要的组成部分,但是目前大多数与该主题相关的开发者资源更关注它的实现细节,即 "PendingIntent 是由系统维护的 token 引用",而忽略了它的用途。由于 Android 12 对 Pend...
    继续阅读 »

    PendingIntent 是 Android 框架中非常重要的组成部分,但是目前大多数与该主题相关的开发者资源更关注它的实现细节,即 "PendingIntent 是由系统维护的 token 引用",而忽略了它的用途。

    由于 Android 12 对 PendingIntent 进行了 重要更新,包括需要显式确定 PendingIntent 是否是可变的,所以我认为有必要和大家深入聊聊 PendingIntent 有什么作用,系统如何使用它,以及为什么您会需要可变类型的 PendingIntent。

    PendingIntent 是什么?

    PendingIntent 对象封装了 Intent 对象的功能,同时以您应用的名义指定其他应用允许哪些操作的执行,来响应用户未来会进行的操作。比如,所封装的 Intent 可能会在闹铃关闭后或者用户点击通知时被触发。

    PendingIntent 的关键点是其他应用在触发 intent 时是 以您应用的名义。换而言之,其他应用会使用您应用的身份来触发 intent。

    为了让 PendingIntent 具备和普通 Intent 一样的功能,系统会使用创建 PendingIntent 时的身份来触发它。在大多数情况下,比如闹铃和通知,其中所用到的身份就是应用本身。

    我们来看应用中使用 PendingIntent 的不同方式,以及我们使用这些方式的原因。

    常规用法

    使用 PendingIntent 最常规最基础的用法是作为关联某个通知所进行的操作。

    val intent = Intent(applicationContext, MainActivity::class.java).apply {
    action = NOTIFICATION_ACTION
    data = deepLink
    }
    val pendingIntent = PendingIntent.getActivity(
    applicationContext,
    NOTIFICATION_REQUEST_CODE,
    intent,
    PendingIntent.FLAG_IMMUTABLE
    )
    val notification = NotificationCompat.Builder(
    applicationContext,
    NOTIFICATION_CHANNEL
    ).apply {
    // ...
    setContentIntent(pendingIntent)
    // ...
    }.build()
    notificationManager.notify(
    NOTIFICATION_TAG,
    NOTIFICATION_ID,
    notification
    )

    可以看到我们构建了一个标准类型的 Intent 来打开我们的应用,然后,在添加到通知之前简单用 PendingIntent 封装了一下。

    在本例中,由于我们明确知道未来需要进行的操作,所以我们使用 FLAG_IMMUTABLE 标记构建了无法被修改的 PendingIntent

    调用 NotificationManagerCompat.notify() 之后工作就完成了。当系统显示通知,且用户点击通知时,会在我们的 PendingIntent 上调用 PendingIntent.send(),来启动我们的应用。

    更新不可变的 PendingIntent

    您也许会认为如果应用需要更新 PendingIntent,那么它需要是可变类型,但其实并不是。应用所创建的 PendingIntent 可通过 FLAG_UPDATE_CURRENT 标记来更新。

    val updatedIntent = Intent(applicationContext, MainActivity::class.java).apply {
    action = NOTIFICATION_ACTION
    data = differentDeepLink
    }

    // 由于我们使用了 FLAG_UPDATE_CURRENT 标记,所以这里可以更新我们在上面创建的
    // PendingIntent
    val updatedPendingIntent = PendingIntent.getActivity(
    applicationContext,
    NOTIFICATION_REQUEST_CODE,
    updatedIntent,
    PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
    )
    // 该 PendingIntent 已被更新

    在接下来的内容中我们会解释为什么将 PendingIntent 设置为可变类型。

    跨应用 API

    通常的用法并不局限于与系统交互。虽然在某些操作后使用 startActivityForResult() 和 onActivityResult() 来 接收回调 是非常常见的用法,但它并不是唯一用法。

    想象一下一个线上订购应用提供了 API 使其他应用可以集成。当 Intent 启动了订购食物的流程后,应用可以 Intent 的 extra 的方式访问 PendingIntent。一旦订单完成传递,订购应用仅需启动一次 PendingIntent

    在本例中,订购应用使用了 PendingIntent 而没有直接发送 activity 结果,因为订单可能需要更长时间进行提交,而让用户在这个过程中等待是不合理的。

    我们希望创建一个不可变的 PendingIntent,因为我们不希望线上订购应用修改我们的 Intent。当订单生效时,我们仅希望其他应用发送它,并保持它本身不变。

    可变 PendingIntent

    但是如果我们作为订购应用的开发者,希望添加一个特性可以允许用户回送消息至调用订购功能的应用呢?比如可以让调用的应用提示,"现在是披萨时间!"

    要实现这样的效果就需要使用可变的 PendingIntent 了。

    既然 PendingIntent 本质上是 Intent 的封装,有人可能会想可以通过一个 PendingIntent.getIntent() 方法来获得其中所封装的 Intent。但是答案是不可以的。那么该如何实现呢?

    PendingIntent 中除了不含任何参数的 send() 方法之外,还有其他 send 方法的版本,包括这个可以接受 Intent 作为参数的 版本:

    fun PendingIntent.send(
    context: Context!,
    code: Int,
    intent: Intent?
    )

    这里的 Intent 参数并不会替换 PendingIntent 所封装的 Intent,而是通过 PendingIntent 在创建时所封装的 Intent 来填充参数。

    我们来看下面的例子。

    val orderDeliveredIntent = Intent(applicationContext, OrderDeliveredActivity::class.java).apply {
    action = ACTION_ORDER_DELIVERED
    }
    val mutablePendingIntent = PendingIntent.getActivity(
    applicationContext,
    NOTIFICATION_REQUEST_CODE,
    orderDeliveredIntent,
    PendingIntent.FLAG_MUTABLE
    )

    这里的 PendingIntent 会被传递到我们的线上订购应用。当传递完成后,应用可以得到一个 customerMessage,并将其作为 intent 的 extra 回传,如下示例所示:

    val intentWithExtrasToFill = Intent().apply {
    putExtra(EXTRA_CUSTOMER_MESSAGE, customerMessage)
    }
    mutablePendingIntent.send(
    applicationContext,
    PENDING_INTENT_CODE,
    intentWithExtrasToFill
    )

    调用端的应用会在它的 Intent 中得到 EXTRA_CUSTOMER_MESSAGE extra,并显示消息。

    声明可变的 PendingIntent 时需要特别注意的事

    ⚠️当创建可变的 PendingIntent 时,始终 显式设置要启动的 Intent 的 component。可以通过我们上面的实现方式操作,即显式设置要接收的准确类名,不过也可以通过 Intent.setComponent() 实现。

    您的应用可能会在某些场景下调用 Intent.setPackage() 来实现更方便。但是请特别注意这样的做法有可能会 匹配到多个 component。如果可以的话,最好指定特定的 component。

    ⚠️如果您尝试覆写使用 FLAG_IMMUTABLE 创建的 PendingIntent 中的值,那么该操作会失败且没有任何提示,并传递原始封装未修改的 Intent

    请记住应用总是可以更新自身的 PendingIntent,即使是不可变类型。使 PendingIntent 成为可变类型的唯一原因是其他应用需要通过某种方式更新其中封装的 Intent

    关于标记的详情

    我们上面介绍了少数几个可用于创建 PendingIntent 的标记,还有一些标记也为大家介绍一下。

    FLAG_IMMUTABLE: 表示其他应用通过 PendingIntent.send() 发送到 PendingIntent 中的 Intent 无法被修改。应用总是可以使用 FLAG_UPDATE_CURRENT 标记来修改它自己的 PendingIntent。

    在 Android 12 之前的系统中,不带有该标记创建的 PendingIntent 默认是可变类型。

    ⚠️ Android 6 (API 23) 之前的系统中,PendingIntent 都是可变类型。

    🆕FLAG_MUTABLE: 表示由 PendingIntent.send() 传入的 intent 内容可以被应用合并到 PendingIntent 中的 Intent。

    ⚠️ 对于任何可变类型的 PendingIntent,始终 设置其中所封装的 Intent 的 ComponentName。如果未采取该操作的话可能会造成安全隐患。

    该标记是在 Android 12 版本中加入。Android 12 之前的版本中,任何未指定 FLAG_IMMUTABLE标记所创建的 PendingIntent 都是隐式可变类型。

    FLAG_UPDATE_CURRENT: 向系统发起请求,使用新的 extra 数据更新已有的 PendingIntent,而不是保存新的 PendingIntent。如果 PendingIntent 未注册,则进行注册。

    FLAG_ONE_SHOT: 仅允许 PendingIntent (通过 PendingIntent.send()) 被发送一次。对于传递 PendingIntent 时,其内部的 Intent 仅能被发送一次的场景就非常重要了。该机制可能便于操作,或者可以避免应用多次执行某项操作。

    🔐 使用 FLAG_ONE_SHOT 来避免类似 "重放攻击" 的问题。

    FLAG_CANCEL_CURRENT: 在注册新的 PendingIntent 之前,取消已存在的某个 PendingIntent。该标记用于当某个 PendingIntent 被发送到某应用,然后您希望将它转发到另一个应用,并更新其中的数据。使用 FLAG_CANCEL_CURRENT 之后,之前的应用将无法再调用 send 方法,而之后的应用可以调用。

    接收 PendingIntent

    有些情况下系统或者其他框架会将 PendingIntent 作为 API 调用的返回值。举一个典型例子是方法 MediaStore.createWriteRequest(),它是在 Android 11 中新增的。

    static fun MediaStore.createWriteRequest(
    resolver: ContentResolver,
    uris: MutableCollection<Uri>
    ): PendingIntent

    正如我们应用创建的 PendingIntent 一样,它是以我们应用的身份运行,而系统创建的 PendingIntent,它是以系统的身份运行。具体到这里 API 的使用场景,它允许应用打开 Activity 并赋予我们的应用 Uri 集合的写权限。

    总结

    我们在本文中介绍了 PendingIntent 如何作为 Intent 的封装使系统或者其他应用能够在未来某一时间以某个应用的身份启动该应用所创建的 Intent。

    我们还介绍了 PendingIntent 为何需要设置为不可变,以及这么做并不会影响应用修改自身所创建的 PendingIntent 对象。可以通过 FLAG_UPDATE_CURRENT 标记加上 FLAG_IMMUTABLE 来实现该操作。

    我们还介绍了如果 PendingIntent 是可变的,需要做的预防措施 — 保证对封装的 Intent 设置 ComponentName

    最后,我们介绍了有时系统或者框架如何向应用提供 PendingIntent,以便我们能够决定如何并且何时运行它们。

    收起阅读 »

    Android工程Gradle构建-笔记

    1、统一版本库管理1.1、统一版本号管理创建一个gradle文件统一管理 不同module下的第三方库和其他属性的配置参数 如下,在项目根目录创建config.gradleext { COMPILE_SDK = 30 APPLICATION_ID ...
    继续阅读 »

    1、统一版本库管理

    1.1、统一版本号管理

    创建一个gradle文件统一管理 不同module下的第三方库和其他属性的配置参数 如下,在项目根目录创建config.gradle

    ext {
    COMPILE_SDK = 30
    APPLICATION_ID = "com.chenyangqi.gradle"
    MIN_SDK = 19
    TARGET_SDK = 30
    VERSION_CODE = 1
    VERSION_NAME = "1.0.0"

    JVM_TARGET = '1.8'

    MULTIDEX = 'androidx.multidex:multidex:2.0.1'
    CORE_KTX = 'androidx.core:core-ktx:1.3.2'
    APPCOMPAT = 'androidx.appcompat:appcompat:1.2.0'
    ANDROID_MATERIAL = 'com.google.android.material:material:1.3.0'
    CONSTRAINTLAYOUT = 'androidx.constraintlayout:constraintlayout:2.1.0'
    TEST_JUNIT = 'junit:junit:4.+'
    ANDROID_EXT_JUNIT = 'androidx.test.ext:junit:1.1.2'
    ANDROID_TEST_ESPRESSO = 'androidx.test.espresso:espresso-core:3.3.0'
    }

    然后在项目的gradle中引用config.gradle

    apply from: project.file('config.gradle')

    1.2、local.perporties使用场景

    一些不便对外展示的敏感参数可以定义在local.properties中,如一些付费库的key,maven仓库的用户名和密码等

    sdk.dir=/Users/mutou/Library/Android/sdk
    username=chenyangqi
    password=123456

    编译时通过如下方式获取local.properties中定义的属性

    Properties properties = new Properties()
    properties.load(project.rootProject.file("local.properties").newDataInputStream())
    def username = properties.getProperty('username')
    def password = properties.getProperty('password')

    在运行时获得Local.properties属性要借助BuildConfig

    def getUsername() {
    Properties properties = new Properties()
    properties.load(project.rootProject.file('local.properties').newDataInputStream())
    return properties.getProperty("username");
    }

    android {
    defaultConfig {
    buildConfigField "String", "USERNAME", "\""+getUsername()+"\""
    }
    }

    1.3、版本冲突处理

    出现依赖冲突时可通过gradle的dependencies查看依赖树,定位冲突位置 ,比如我要查看的Build Variants为oppoNormalProdRelease,命令如下

    ./gradlew :app:dependencies --configuration oppoNormalProdReleaseCompileClasspath

    依赖树如下

    mutou@chenyangqi GradleDemo % ./gradlew :app:dependencies --configuration oppoNormalProdReleaseCompileClasspath
    ...
    oppoNormalProdReleaseCompileClasspath - Compile classpath for compilation 'oppoNormalProdRelease' (target (androidJvm)).
    +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.5.21
    | +--- org.jetbrains.kotlin:kotlin-stdlib:1.5.21
    | | +--- org.jetbrains:annotations:13.0
    | | \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.5.21
    | \--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.5.21
    | \--- org.jetbrains.kotlin:kotlin-stdlib:1.5.21 (*)
    +--- androidx.multidex:multidex:2.0.1
    +--- androidx.core:core-ktx:1.3.2
    | +--- org.jetbrains.kotlin:kotlin-stdlib:1.3.71 -> 1.5.21 (*)
    | +--- androidx.annotation:annotation:1.1.0
    | \--- androidx.core:core:1.3.2
    | +--- androidx.annotation:annotation:1.1.0
    | +--- androidx.lifecycle:lifecycle-runtime:2.0.0 -> 2.1.0
    | | +--- androidx.lifecycle:lifecycle-common:2.1.0
    | | | \--- androidx.annotation:annotation:1.1.0
    | | +--- androidx.arch.core:core-common:2.1.0
    | | | \--- androidx.annotation:annotation:1.1.0
    | | \--- androidx.annotation:annotation:1.1.0
    | \--- androidx.versionedparcelable:versionedparcelable:1.1.0
    | +--- androidx.annotation:annotation:1.1.0
    | \--- androidx.collection:collection:1.0.0 -> 1.1.0
    | \--- androidx.annotation:annotation:1.1.0
    +--- androidx.appcompat:appcompat:1.2.0
    | +--- androidx.annotation:annotation:1.1.0
    | +--- androidx.core:core:1.3.0 -> 1.3.2 (*)
    | +--- androidx.cursoradapter:cursoradapter:1.0.0
    | | \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | +--- androidx.fragment:fragment:1.1.0
    | | +--- androidx.annotation:annotation:1.1.0
    | | +--- androidx.core:core:1.1.0 -> 1.3.2 (*)
    | | +--- androidx.collection:collection:1.1.0 (*)
    | | +--- androidx.viewpager:viewpager:1.0.0
    | | | +--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | | +--- androidx.core:core:1.0.0 -> 1.3.2 (*)
    | | | \--- androidx.customview:customview:1.0.0
    | | | +--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | | \--- androidx.core:core:1.0.0 -> 1.3.2 (*)
    | | +--- androidx.loader:loader:1.0.0
    | | | +--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | | +--- androidx.core:core:1.0.0 -> 1.3.2 (*)
    | | | +--- androidx.lifecycle:lifecycle-livedata:2.0.0
    | | | | +--- androidx.arch.core:core-runtime:2.0.0
    | | | | | +--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | | | | \--- androidx.arch.core:core-common:2.0.0 -> 2.1.0 (*)
    | | | | +--- androidx.lifecycle:lifecycle-livedata-core:2.0.0
    | | | | | +--- androidx.lifecycle:lifecycle-common:2.0.0 -> 2.1.0 (*)
    | | | | | +--- androidx.arch.core:core-common:2.0.0 -> 2.1.0 (*)
    | | | | | \--- androidx.arch.core:core-runtime:2.0.0 (*)
    | | | | \--- androidx.arch.core:core-common:2.0.0 -> 2.1.0 (*)
    | | | \--- androidx.lifecycle:lifecycle-viewmodel:2.0.0 -> 2.1.0
    | | | \--- androidx.annotation:annotation:1.1.0
    | | +--- androidx.activity:activity:1.0.0
    | | | +--- androidx.annotation:annotation:1.1.0
    | | | +--- androidx.core:core:1.1.0 -> 1.3.2 (*)
    | | | +--- androidx.lifecycle:lifecycle-runtime:2.1.0 (*)
    | | | +--- androidx.lifecycle:lifecycle-viewmodel:2.1.0 (*)
    | | | \--- androidx.savedstate:savedstate:1.0.0
    | | | +--- androidx.annotation:annotation:1.1.0
    | | | +--- androidx.arch.core:core-common:2.0.1 -> 2.1.0 (*)
    | | | \--- androidx.lifecycle:lifecycle-common:2.0.0 -> 2.1.0 (*)
    | | \--- androidx.lifecycle:lifecycle-viewmodel:2.0.0 -> 2.1.0 (*)
    | +--- androidx.appcompat:appcompat-resources:1.2.0
    | | +--- androidx.annotation:annotation:1.1.0
    | | +--- androidx.core:core:1.0.1 -> 1.3.2 (*)
    | | +--- androidx.vectordrawable:vectordrawable:1.1.0
    | | | +--- androidx.annotation:annotation:1.1.0
    | | | +--- androidx.core:core:1.1.0 -> 1.3.2 (*)
    | | | \--- androidx.collection:collection:1.1.0 (*)
    | | \--- androidx.vectordrawable:vectordrawable-animated:1.1.0
    | | +--- androidx.vectordrawable:vectordrawable:1.1.0 (*)
    | | +--- androidx.interpolator:interpolator:1.0.0
    | | | \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | \--- androidx.collection:collection:1.1.0 (*)
    | \--- androidx.drawerlayout:drawerlayout:1.0.0
    | +--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | +--- androidx.core:core:1.0.0 -> 1.3.2 (*)
    | \--- androidx.customview:customview:1.0.0 (*)
    +--- com.google.android.material:material:1.3.0
    | +--- androidx.annotation:annotation:1.0.1 -> 1.1.0
    | +--- androidx.appcompat:appcompat:1.1.0 -> 1.2.0 (*)
    | +--- androidx.cardview:cardview:1.0.0
    | | \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | +--- androidx.coordinatorlayout:coordinatorlayout:1.1.0
    | | +--- androidx.annotation:annotation:1.1.0
    | | +--- androidx.core:core:1.1.0 -> 1.3.2 (*)
    | | +--- androidx.customview:customview:1.0.0 (*)
    | | \--- androidx.collection:collection:1.0.0 -> 1.1.0 (*)
    | +--- androidx.constraintlayout:constraintlayout:2.0.1 -> 2.1.0
    | +--- androidx.core:core:1.2.0 -> 1.3.2 (*)
    | +--- androidx.dynamicanimation:dynamicanimation:1.0.0
    | | +--- androidx.core:core:1.0.0 -> 1.3.2 (*)
    | | +--- androidx.collection:collection:1.0.0 -> 1.1.0 (*)
    | | \--- androidx.legacy:legacy-support-core-utils:1.0.0
    | | +--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | +--- androidx.core:core:1.0.0 -> 1.3.2 (*)
    | | +--- androidx.documentfile:documentfile:1.0.0
    | | | \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | +--- androidx.loader:loader:1.0.0 (*)
    | | +--- androidx.localbroadcastmanager:localbroadcastmanager:1.0.0
    | | | \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | | \--- androidx.print:print:1.0.0
    | | \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
    | +--- androidx.annotation:annotation-experimental:1.0.0
    | +--- androidx.fragment:fragment:1.0.0 -> 1.1.0 (*)
    | +--- androidx.lifecycle:lifecycle-runtime:2.0.0 -> 2.1.0 (*)
    | +--- androidx.recyclerview:recyclerview:1.0.0 -> 1.1.0
    | | +--- androidx.annotation:annotation:1.1.0
    | | +--- androidx.core:core:1.1.0 -> 1.3.2 (*)
    | | +--- androidx.customview:customview:1.0.0 (*)
    | | \--- androidx.collection:collection:1.0.0 -> 1.1.0 (*)
    | +--- androidx.transition:transition:1.2.0
    | | +--- androidx.annotation:annotation:1.1.0
    | | +--- androidx.core:core:1.0.1 -> 1.3.2 (*)
    | | \--- androidx.collection:collection:1.0.0 -> 1.1.0 (*)
    | +--- androidx.vectordrawable:vectordrawable:1.1.0 (*)
    | \--- androidx.viewpager2:viewpager2:1.0.0
    | +--- androidx.annotation:annotation:1.1.0
    | +--- androidx.fragment:fragment:1.1.0 (*)
    | +--- androidx.recyclerview:recyclerview:1.1.0 (*)
    | +--- androidx.core:core:1.1.0 -> 1.3.2 (*)
    | \--- androidx.collection:collection:1.1.0 (*)
    ...
    BUILD SUCCESSFUL in 1s

    1.3.1、去除冲突依赖

    当确定最终只保留的版本时,过滤掉其他版本,如下只保留ore:0.9.5.0

    api("com.afollestad.material-dialogs:core:0.9.5.0") {
    exclude group: 'com.android.support'
    }

    1.3.2、CompileOnly只编译不打包

    当我们开发SDK时如果需要依赖第三方库,使用CompileOnly引用第三方库,而让使用SDK的开发者去决定选择哪个版本的第三方库,避免他人调用你的SDK时出现版本冲突

    1.3.3、通过gradle脚本检测依赖库版本

    待实现...

    2、MultiDex分包

    2.1、65535产生原因

    默认情况下,Android工程代码编译后的.class文件会打包进一个dex中,dex中每一个方法会使用C++中的unsigned short类型的字段标记,unsigned short取值范围为0~65535,所以一旦方法数超过上限就会造成65536

    2.2、分包

    通过分包解决65535问题,根据minSdk版本不同分两种情况

    2.2.1、minSdk>=21时分包

    在app module下的build.gradle中设置multiDexEnabled=true即可

    android {
    compileSdk 30
    defaultConfig {
    applicationId "com.chenyangqi.gradle"
    minSdk 21
    targetSdk 30
    versionCode 1
    versionName "1.0"
    multiDexEnabled true
    testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }
    ...
    }

    2.2.2、minSdk<21时分包

    minSdk小于21时除了设置multidexEnabled=true还要引用androidx.multidex:multidex:2.0.1这个Google提供的分包库

    android {
    compileSdk 30

    defaultConfig {
    applicationId "com.chenyangqi.gradle"
    minSdk 19
    targetSdk 30
    versionCode 1
    versionName "1.0"
    multiDexEnabled true
    testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }
    ...
    }

    dependencies {
    implementation 'androidx.multidex:multidex:2.0.1'
    ...
    }

    然后再在application中继承分包库中的MultiDexApplication,又分三种情况

    没有自定义Application时,直接在清单文件中注册name=MultiDexApplication

    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.chenyangqi.gradle">

    <application
    android:name="androidx.multidex.MultiDexApplication"
    ...
    </application>

    </manifest>

    有自定义Application时直接继承

    class MyApplication:MultiDexApplication() {
    }

    当自定义Application已继承其他父类时重写attachBaseContext方法进行初始化

    class MyApplication:OtherApplication() {

    override fun onCreate() {
    super.onCreate()
    }

    override fun attachBaseContext(base: Context?) {
    super.attachBaseContext(base)
    MultiDex.install(this)
    }
    }

    3、代码混淆

    3.1、开启混淆

    buildTypes {
    debug {
    minifyEnabled false
    shrinkResources false
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
    release {
    minifyEnabled true
    shrinkResources true
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
    }

    设置minifyEnabled=true和shrinkResources=true启用压缩、混淆和优化功能, proguard-android-optimize.txt为存放在SDK中Android默认的混淆规则,存放路径~/SDK/tools/proguard/proguard-android-optimize.txt,proguard-rules.pro为项目中自己定义的混淆规则

    3.2、常用混淆规则

    关键字描述
    keep保留类和类中的成员,防止被混淆或者移除
    keepnames保留类和类中的成员,防止被混淆,但是当成员没有被引用时会被移除
    keepclassmembers只保留类中的成员,防止他们被混淆或者移除
    keepclassmembersnames只保留类中的成员,防止他们被混淆或者移除,但是当类中的成员没有被引用时还是会被移除
    keepclasseswithmembers保留类和类中的成员,前提是指明的类中必须含有该成员,没有的话还是会被混淆
    keepclasseswithmembersnames保留类和类中的成员,前提是指明的类中必须含有该成员,没有的话还是会被混淆。需要注意的是没有被引用的成员会被移除
     
    关键字描述
    <filed>匹配类中的所有字段
    <method>匹配类中的所有方法
    <init>匹配类中的所有构造函数
    *匹配任意长度字符,但不含包名分隔符(.)。比如说我们的完整类名是com.example.test.MyActivity,使用com.*,或者com.exmaple.*都是无法匹配的,因为*无法匹配包名中的分隔符,正确的匹配方式是com.exmaple.*.*,或者com.exmaple.test.*,这些都是可以的。但如果你不写任何其它内容,只有一个*,那就表示匹配所有的东西。
    **匹配任意长度字符,并且包含包名分隔符(.)。比如proguard-android.txt中使用的-dontwarn android.support.**就可以匹配android.support包下的所有内容,包括任意长度的子包。
    ***匹配任意参数类型。比如void set*(***)就能匹配任意传入的参数类型,*** get*()就能匹配任意返回值的类型。
    匹配任意长度的任意类型参数。比如void test(…)就能匹配任意void test(String a)或者是void test(int a, String b)这些方法。

    3.3、Android常用混淆模板

    #-------------------------------------------基本不用动区域--------------------------------------------
    #---------------------------------基本指令区----------------------------------
    -optimizationpasses 5
    -dontskipnonpubliclibraryclassmembers
    -printmapping proguardMapping.txt
    -optimizations !code/simplification/cast,!field/*,!class/merging/*
    -keepattributes *Annotation*,InnerClasses
    -keepattributes Signature
    -keepattributes SourceFile,LineNumberTable
    #----------------------------------------------------------------------------

    #---------------------------------默认保留区---------------------------------
    #继承activity,application,service,broadcastReceiver,contentprovider....不进行混淆
    -keep public class * extends android.app.Activity
    -keep public class * extends android.app.Application
    -keep public class * extends androidx.multidex.MultiDexApplication
    -keep public class * extends android.app.Service
    -keep public class * extends android.content.BroadcastReceiver
    -keep public class * extends android.content.ContentProvider
    -keep public class * extends android.app.backup.BackupAgentHelper
    -keep public class * extends android.preference.Preference
    -keep public class * extends android.view.View
    -keep class android.support.** {*;}

    -keep public class * extends android.view.View{
    *** get*();
    void set*(***);
    public <init>(android.content.Context);
    public <init>(android.content.Context, android.util.AttributeSet);
    public <init>(android.content.Context, android.util.AttributeSet, int);
    }
    -keepclasseswithmembers class * {
    public <init>(android.content.Context, android.util.AttributeSet);
    public <init>(android.content.Context, android.util.AttributeSet, int);
    }
    #这个主要是在layout 中写的onclick方法android:onclick="onClick",不进行混淆
    -keepclassmembers class * extends android.app.Activity {
    public void *(android.view.View);
    }

    -keepclassmembers class * implements java.io.Serializable {
    static final long serialVersionUID;
    private static final java.io.ObjectStreamField[] serialPersistentFields;
    private void writeObject(java.io.ObjectOutputStream);
    private void readObject(java.io.ObjectInputStream);
    java.lang.Object writeReplace();
    java.lang.Object readResolve();
    }

    -keep class **.R$* {
    *;
    }

    -keepclassmembers class * {
    void *(*Event);
    }

    #枚举
    -keepclassmembers enum * {
    public static **[] values();
    public static ** valueOf(java.lang.String);
    }

    -keep class * implements android.os.Parcelable {
    public static final android.os.Parcelable$Creator *;
    }

    #// natvie 方法不混淆
    -keepclasseswithmembernames class * {
    native <methods>;
    }

    #保持 Parcelable 不被混淆
    -keep class * implements android.os.Parcelable {
    public static final android.os.Parcelable$Creator *;
    }

    #---------------------------------webview------------------------------------
    -keepclassmembers class android.webkit.WebView {
    public *;
    }
    -keepclassmembers class * extends android.webkit.WebViewClient {
    public void *(android.webkit.WebView, java.lang.String, android.graphics.Bitmap);
    public boolean *(android.webkit.WebView, java.lang.String);
    }
    -keepclassmembers class * extends android.webkit.WebViewClient {
    public void *(android.webkit.WebView, java.lang.String);
    }
    #----------------------------------------------------------------------------
    #---------------------------------------------------------------------------------------------------
    #---------------------------------实体类---------------------------------
    #修改成你对应的包名
    -keep class com.chenyangqi.gradle.proguard.bean.** { *; }

    #---------------------------------第三方包-------------------------------

    #---------------------------------反射相关的类和方法-----------------------

    #---------------------------------与js互相调用的类------------------------

    #---------------------------------自定义View的类------------------------

    收起阅读 »

    iOS 组件化方案

    iOS
    为什么要组件化?易移植、易维护、易重构、易根据业务做加减法、易开发理想中的组件化组件化最终应该达到每个组件可以单独开发,单独维护,不会对其他组件进行强依赖。理想的架构应该在横向上能够拆分出容器层,开源三方库,基础组件,业务形态SDK组件,普通业务组件;在纵向上...
    继续阅读 »

    为什么要组件化?
    易移植、易维护、易重构、易根据业务做加减法、易开发

    理想中的组件化
    组件化最终应该达到每个组件可以单独开发,单独维护,不会对其他组件进行强依赖。
    理想的架构应该在横向上能够拆分出容器层,开源三方库,基础组件,业务形态SDK组件,普通业务组件;在纵向上能够进行组件解耦,组件之间可以单独开发、维护、复用以及组件之间合理的通信机制。随着业务的复杂度增加,理想中的架构也应该不断的变化,


    如何进行组件化
    先进行组件的拆分,然后进行组件的之间的服务调度,然后进行事件分发包含系统事件以及组件本身自定义的事件实现比较完善的解耦

    组件的拆分
    将不同的业务代码按照业务的划分整合成一个独立的组件成为独立repo。

    进行组件之间服务的调度实现接口依赖
    1、将组件之间的依赖实体转为依赖抽象、依赖接口
    2、不进行依赖直接依靠OC自身的动态性进行方法的调用

    完善组件之间的通信以及事件分发
    将系统事件、应用事件以及业务事件进行分发。基本可以做到每个组件之间,组件之间实现无耦合的通信,以及对系统、应用事件的感知。实现每一个组件都可以成为一个独立的APP运行

    通用方案调研
    目前业界有三大通用方案:面向接口进行解耦、使用URL路由的方式以及使用runtime进行解耦。各自的代表为:serviceCenter注册的BeeHive、URL注册的Router、使用runtime+Category的CTMediator
    BeeHive的架构与解析


    Beehive在服务调度上采用了protocol的方式,依赖指定的接口来实现组件之间的耦合。

    服务注册
    注册一个服务主要有两个问题:如何注册以及注册时间,BeeHive采用了三种服务注册的方式

    Annotation方式注册
    将所需要注册的服务通过注解的方式保存在可执行文件中,在可执行文件加载是的过程中实现protocol与class的注册。这种方式注册服务简单方便,每个组件可以在自己自行注册,不需要集中注册。整体流程对开发者比较友好

    保存服务名
    @BeeHiveService(UserTrackServiceProtocol,BHUserTrackViewController)
    //
    #define BeeHiveDATA(sectname) __attribute((used, section("__DATA,"#sectname" ")))
    #define BeeHiveService(servicename,impl) \
    class BeeHive; char * k##servicename##_service BeeHiveDATA(BeehiveServices) = "{ \""#servicename"\" : \""#impl"\"}";

    这里是将服务名字存在__Data(这是数据段用于存放初始化好的变量)段中的指定区域,到时候和其他资源一起打入ipa中
    __attribute((used))是为了防止release模式下被优化(在单测上尤其必要。有些接口只有单测代码引用了这个时候如果不加used进行修饰就无法进行单测)
    为什么#要带两个""
    进行注册
    通过constructor进行修饰,在可执行文件加载之前设置mach-o和动态共享库的加载后的回调
    在回调里面通过传过来的Mach-o的文件头地址以及之前设置好的__data段的section名字读取出存在该section的服务protocol以及class然后利用serviceCenter执行服务注册的逻辑,等待使用的时候进行初始化,避免内存常驻

    __attribute__((constructor))
    void initProphet() {
    _dyld_register_func_for_add_image(dyld_callback); //添加image的load回调
    }

    NSMutableArray *configs = [NSMutableArray array];
    unsigned long size = 0;
    #ifndef __LP64__
    // 读取存贮的服务的section地址
    uintptr_t *memory = (uintptr_t*)getsectiondata(mhp, SEG_DATA, BeehiveServiceSectName, &size);
    #else
    const struct mach_header_64 *mhp64 = (const struct mach_header_64 *)mhp;
    // 读取存贮的服务的section地址
    uintptr_t *memory = (uintptr_t*)getsectiondata(mhp64, SEG_DATA, BeehiveServiceSectName, &size);
    #endif
    // 遍历改section获取服务的protocol以及class
    unsigned long counter = size/sizeof(void*);
    for(int idx = 0; idx < counter; ++idx){
    char *string = (char*)memory[idx];
    NSString *str = [NSString stringWithUTF8String:string];
    if(!str)continue;

    BHLog(@"config = %@", str);
    if(str) [configs addObject:str];
    }
    //register services
    for (NSString *map in configs) {
    NSData *jsonData = [map dataUsingEncoding:NSUTF8StringEncoding];
    NSError *error = nil;
    id json = [NSJSONSerialization JSONObjectWithData:jsonData options:0 error:&error];
    if (!error) {
    if ([json isKindOfClass:[NSDictionary class]] && [json allKeys].count) {

    NSString *protocol = [json allKeys][0];
    NSString *clsName = [json allValues][0];

    if (protocol && clsName) {
    [[BHServiceManager sharedManager] registerService:NSProtocolFromString(protocol) implClass:NSClassFromString(clsName)];
    }

    }
    }
    }

    使用文件的方式进行注册
    将所需要注册的服务通过plist文件打包到app中,在APP启动的lauch回调中实现实现protocol与class的注册

    保存服务名
    在文件中以key-value的形式保存服务名到plist文件中

    进行注册
    在app的lauch中找到对应保存服务的plist文件进行读取,然后使用serviceCenter将服务保存字典中allServicesDict,等待使用的时候进行初始化,避免内存常驻

    NSString *plistPath = [[NSBundle mainBundle] pathForResource:serviceConfigName ofType:@"plist"];
    if (!plistPath) {
    return;
    }
    NSArray *serviceList = [[NSArray alloc] initWithContentsOfFile:plistPath];

    [self.lock lock];
    for (NSDictionary *dict in serviceList) {
    NSString *protocolKey = [dict objectForKey:@"service"];
    NSString *protocolImplClass = [dict objectForKey:@"impl"];
    if (protocolKey.length > 0 && protocolImplClass.length > 0) {
    [self.allServicesDict addEntriesFromDictionary:@{protocolKey:protocolImplClass}];
    }
    }
    // 使用的时候主动创建服务的实现方
    id<UserTrackServiceProtocol> v4 = [[BeeHive shareInstance] createService:@protocol(UserTrackServiceProtocol)];

    使用+load的方式进行注册
    无需保存文件名直接在+load方法中利用serviceCenter进行protocol与class的注册,等待使用的时候进行初始化,避免内存常驻

    总结
    三种注册方式,使用注解的注册方式整体来说比较优雅,对开发者也是比较友好的,注册的时机也是最靠前的。其次是+load也是执行main函数之前使用起来也比较简单。之后是文件注册,注册时间再main函数之后,APP启动中进行注册,一个是时间需要人为的去保证,其实使用起来需要统一改plist文件不是很好的处理方式。

    服务的调度
    服务的创建
    在使用服务之前进行进行服务的获取,使用懒加载避免了服务在内存中常驻

    id<UserTrackServiceProtocol> v4 = [[BeeHive shareInstance] createService:@protocol(UserTrackServiceProtocol)];
    1
    服务的实现类可以是普通实例也可以是单例,业务方可以自行实现singleton方法进行选择。内部还有一个shouldCache参数决定是否使用cache(看起来作用不是很大,如果是单例则无论是否使用cache,获取的都会是唯一的实例,如果不是单例则无论是否使用cache获取的都是新的实例)。
    shouldCache这里可以修改一下使用,由于业务方是不知道每次获取的服务是单例还是唯一的实例,所以确实可以增加shouldCache给业务方使用,当业务方选择使用缓存的时候,这时候如果没有缓存返回空给业务方一个感知,有缓存的时候正常返回。这样shouldCache才有意义

    if (shouldCache) {
    id protocolImpl = [[BHContext shareInstance] getServiceInstanceFromServiceName:serviceStr];
    if (protocolImpl) {
    return protocolImpl;
    }
    //增加else
    else {
    return nil
    }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    服务获取以及移除
    在已经创建的服务列表中移除所创建的服务或者获取服务。

    - (id)getServiceInstanceFromServiceName:(NSString *)serviceName
    {
    return [[BHContext shareInstance] getServiceInstanceFromServiceName:serviceName];
    }
    - (void)removeServiceWithServiceName:(NSString *)serviceName
    {
    [[BHContext shareInstance] removeServiceWithServiceName:serviceName];
    }
    1
    2
    3
    4
    5
    6
    7
    8
    服务的调用
    通过协议定义好的接口进行指定服务的调用

    总结
    能够进行较好的服务调度基本能满足需求,使用延迟创建的方式可以避免内存常驻。区分了单例获取与普通实例获取。在cache设计上可以稍作完善,使得cache变的更有意义

    进行组件之间的通信以及消息分发
    BeeHive在实现组件调度的同时,实现了组件的可插拨,同时实现了一套消息分发的机制,利用BHContext容器进行组件与组件,组件之前的通信以及消息分发,完善通信机制,一定程度上做到了每一个组件都是一个五脏俱全的小APP,以及彼此之间的一些相互影响

    总结
    BeeHive架构下组件实现了可插拔,可以独立存在进行开发。组件之间解耦相对彻底,可以进行通信。每个组件有自己的生命周期,独立管理。组件之间通过protocol进行服务之间的调度,对开发者比较友好。同时protocol对方法调用的参数等也进行了约束,

    MGJRouter架构解析


    MGJRouter使用URL路由的方式进行组件之间的服务调度

    服务的注册
    app启动期间注册指定的scheme与block

    服务的调度
    通过解析scheme,进行对应block的获取以及调用

    总结
    总体来说比较轻量,使用起来简单,但是可用范围也有限。
    1、只能注册block,可以增加protocol的注册或者实现解析指定参数利用NSInvocation进行方法的调用
    2、注册过程依赖字符串,容易引发问题

    CTMediator Target-Action方案
    该方案没有注册的流程,使用的runtime利用字符串来实现服务的调度

    服务的调度
    远程调度
    约定好URL规则之后,将远程调度在内部转为本地调度

    本地调度
    利用CTMediator使用performTarget:action:param进行方法的调度,在CTMediator中利用invocation的方式行方法的调用

    分类的使用
    为了避免方法签名的不确定性,CTMediator使用分类的方式明确了对外的接口同时在分类内部将参数转成字典传参,使用runtime主动发现服务方后在利用invocation进行方法的调用

    总结
    整体上利用runtime主动发现服务比注册服务来说解耦是比较完善的。使用category也一定程度上解决了参数的校验问题
    但是在mediator内部使用仍然是perfromSelector来调用,所以整体上始终是无法做到完美的参数校验。此外增加了Category层,在里面进行参数的中转以及一些适配逻辑相比较protocol而言并没有减轻增加服务的复杂度

    三种方案对比
    方案 S W 适用场景
    URLRouter 使用简单;支持远程调用 字符串的方式硬编码较多,维护成本大;内存常驻;组件依赖中间件;参数缺乏强约束(字典) 远程调用
    Service 面向接口更符合iOS开发者习惯;编编译阶段进行检查,使用上比rumtime方式更安全;支持复杂参数 组件依赖中间件,新增服务稍微麻烦 内部调用
    Runtime+category 新增组件更加快速;依赖最小;支持复杂参数 使用runtime缺少参数的校验;对开发者要求更高,使用不当容易产生问题,;不利于重构 内部调用
    公司内部解决方案
    抖音与头条使用的方案与Beehive类似主要使用的protocol-class的方案进行解耦

    使用 TTRoute进行页面之间的跳转.
    利用protocol-class进行方法的调用

    ————————————————

    原文链接:https://blog.csdn.net/songzhuo1991/article/details/115977726

    收起阅读 »

    iOS - http & https & 网络请求过程

    iOS
    给大家总结网络请求过程:三次握手图集: 看了此图, 于是乎,问题来了, 不是TCP链接的时候需要三次握手么( http://blog.csdn.net/whuslei/article/details/6667471 ),问题确实来...
    继续阅读 »

    给大家总结网络请求过程:

    三次握手图集:

     

    看了此图, 于是乎,问题来了, 不是TCP链接的时候需要三次握手么( http://blog.csdn.net/whuslei/article/details/6667471 ),问题确实来了, 三次握手每次都需要应用层的数据报文么, 于是乎搜得答案

     

    具体链接:http://blog.csdn.net/luozenghui529480823/article/details/12978957  了解了网络链接, 有必要了解HTTP 和Https ,  那么首先看一下Http :http://www.jianshu.com/p/81632fea327c 这都是深度好文啊,就连cookie你都知道原理了吧,那么看看https吧,

     

      一看我们的工程既有https又有http你会发现有这个东西,

     

    既然 https如此安全, 那机制是什么呢,我们都知道HTTPS能够加密信息,以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

    下面我们介绍下https:

    HTTPS其实是有两部分组成:HTTP +SSL/ TLS,也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。具体是如何进行加密,解密,验证的,且看下图。

    1. 客户端发起HTTPS请求

    这个没什么好说的,就是用户在浏览器里输入一个https网址,然后连接到server的443端口。

    2. 服务端的配置

    采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择,有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。

    3. 传送证书

    这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。

    4. 客户端解析证书

    这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。

    5. 传送加密信息

    这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

    6. 服务段解密信息

    服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。

    7. 传输加密后的信息

    这部分信息是服务段用私钥加密后的信息,可以在客户端被还原

    8. 客户端解密信息

    客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。

     

    SSL的位置

    SSL介于应用层和TCP层之间。应用层数据不再直接传递给传输层,而是传递给SSL层,SSL层对从应用层收到的数据进行加密,并增加自己的SSL头。

    RSA性能是非常低的,原因在于寻找大素数、大数计算、数据分割需要耗费很多的CPU周期,所以一般的HTTPS连接只在第一次握手时使用非对称加密,通过握手交换对称加密密钥,在之后的通信走对称加密。

    http://www.cnblogs.com/ttltry-air/archive/2012/08/20/2647898.html

    HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,TLS/SSL中使用了非对称加密,对称加密以及HASH算法。握手过程的具体描述如下:

    1.浏览器将自己支持的一套加密规则发送给网站。

    2.网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。

    3.浏览器获得网站证书之后浏览器要做以下工作

    a)验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。

    b) 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。

    c)使用约定好的HASH算法计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。

    4.网站接收浏览器发来的数据之后要做以下的操作:

    a) 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。

    b) 使用密码加密一段握手消息,发送给浏览器。

    5.浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密

    这里浏览器与网站互相发送加密的握手消息并验证,目的是为了保证双方都获得了一致的密码,并且可以正常的加密解密数据,为后续真正数据的传输做一次测试。另外,HTTPS一般使用的加密与HASH算法如下:

    非对称加密算法:RSA,DSA/DSS

    对称加密算法:AES,RC4,3DES

    HASH算法:MD5,SHA1,SHA256

    总结:

    服务器 用RSA生成公钥和私钥

    把公钥放在证书里发送给客户端,私钥自己保存

    客户端首先向一个权威的服务器检查证书的合法性,如果证书合法,客户端产生一段随机数,这个随机数就作为通信的密钥,我们称之为对称密钥,用公钥加密这段随机数,然后发送到服务器

    服务器用密钥解密获取对称密钥,然后,双方就已对称密钥进行加密解密通信了

    链接:https://blog.csdn.net/songzhuo1991/article/details/104349714?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_title~default-1.control&spm=1001.2101.3001.4242

    收起阅读 »

    OC与Swift API的交互

    互用性是让 Swift 和 Objective-C 相接合的一种特性,使你能够在一种语言编写的文件中使用另一种语言。当你准备开始把 Swift 融入到你的开发流程中时,你应该懂得如何利用互用性来重新定义并提高你写 Cocoa 应用的方案。互用性很重要的一点就是...
    继续阅读 »
    互用性是让 Swift 和 Objective-C 相接合的一种特性,使你能够在一种语言编写的文件中使用另一种语言。当你准备开始把 Swift 融入到你的开发流程中时,你应该懂得如何利用互用性来重新定义并提高你写 Cocoa 应用的方案。

    互用性很重要的一点就是允许你在写 Swift 代码时使用 Objective-C 的 API 接口。当你导入一个 Objective-C 框架后,你可以使用原生的 Swift 语法实例化它的 Class 并且与之交互。

    初始化

    为了使用 Swift 实例化 Objective-C 的 Class,你应该使用 Swift 语法调用它的一个初始化器。当 Objective-C 的init方法变化到 Swift,他们用 Swift 初始化语法呈现。“init”前缀被截断当作一个关键字,用来表明该方法是初始化方法。那些以“initWith”开头的init方法,“With”也会被去除。从“init”或者“initWith”中分离出来的这部分方法名首字母变成小写,并且被当做是第一个参数的参数名。其余的每一部分方法名依次变味参数名。这些方法名都在圆括号中被调用。

    举个例子,你在使用 Objective-C 时会这样做:

    1.  //Objective-C
    2. UITableView *myTableView = [[UITableView alloc]
    3. initWithFrame:CGRectZero style:UITableViewStyleGrouped];

    在 Swift 中,你应该这样做:

    1.  //Swift
    2. let myTableView: UITableView = UITableView(frame: CGRectZero, style: .Grouped)

    你不需要调用 alloc,Swift 能替你处理。注意,当使用 Swift 风格的初始化函数的时候,“init”不会出现。
    你可以在初始化时显式的声明对象的类型,也可以忽略它,Swift 能够正确判断对象的类型。


    1.  //Swift
    2. let myTextField = UITextField(frame: CGRect(0.0, 0.0, 200.0, 40.0))
    这里的UITableView和UITextField对象和你在 Objective-C 中使用的具有相同的功能。你可以用一样的方式使用他们,包括访问属性或者调用各自的类中的方法。
    为了统一和简易,Objective-C 的工厂方法也在 Swift 中映射为方便的初始化方法。这种映射能够让他们使用同样简洁明了的初始化方法。例如,在 Objective-C 中你可能会像下面这样调用一个工厂方法:

    1.  //Objective-C
    2. UIColor *color = [UIColor colorWithRed:0.5 green:0.0 blue:0.5 alpha:1.0];

    在 Swift 中,你应该这样做:

    1.  //Swift
    2. let color = UIColor(red: 0.5, green: 0.0, blue: 0.5, alpha: 1.0)

    访问属性

    在 Swift 中访问和设置 Objective-C 对象的属性时,使用点语法:

    1.  // Swift
    2. myTextField.textColor = UIColor.darkGrayColor()
    3. myTextField.text = "Hello world"
    4. if myTextField.editing {
    5. myTextField.editing = false
    6. }

    当 get 或 set 属性时,直接使用属性名称,不需要附加圆括号。注意,darkGrayColor后面附加了一对圆括号,这是因为darkGrayColor是UIColor的一个类方法,不是一个属性。

    在 Objective-C 中,一个有返回值的无参数方法可以被作为一个隐式的访问函数,并且可以与访问器使用同样的方法调用。但在 Swift 中不再能够这样做了,只有使用@property关键字声明的属性才会被作为属性引入。

    方法

    在 Swift 中调用 Objective-C 方法时,使用点语法。

    当 Objective-C 方法转换到 Swift 时,Objective-C 的selector的第一部分将会成为方法名并出现在圆括号的前面,而第一个参数将直接在括号中出现,并且没有参数名,而剩下的参数名与参数则一一对应的填入圆括号中。

    举个例子,你在使用 Objective-C 时会这样做:

    1.  //Objective-C
    2. [myTableView insertSubview:mySubview atIndex:2];

    在 Swift 中,你应该这样做:

    1.  //Swift
    2. myTableView.insertSubview(mySubview, atIndex: 2)

    如果你调用一个无参方法,仍必须在方法名后面加上一对圆括号

    1.  //Swift
    2. myTableView.layoutIfNeeded()

    id 兼容性(id Compatibility)

    Swift 包含一个叫做AnyObject的协议类型,表示任意类型的对象,就像 Objective-C 中的id一样。AnyObject协议允许你编写类型安全的 Swift 代码同时维持无类型对象的灵活性。因为AnyObject协议保证了这种安全,Swift 将 id 对象导入为 AnyObject。

    举个例子,跟 id 一样,你可以为AnyObject类型的对象分配任何其他类型的对象,你也同样可以为它重新分配其他类型的对象。

    1.  //Swift
    2. var myObject: AnyObject = UITableViewCell()
    3. myObject = NSDate()

    你也可以在调用 Objective-C 方法或者访问属性时不将它转换为具体类的类型。这包括了 Objcive-C 中标记为 @objc 的方法。

    1.  //Swift
    2. let futureDate = myObject.dateByAddingTimeInterval(10)
    3. let timeSinceNow = myObject.timeIntervalSinceNow
    然而,由于直到运行时才知道AnyObject的对象类型,所以有可能在不经意间写出不安全代码。另外,与 Objective-C 不同的是,如果你调用方法或者访问的属性 AnyObject 对象没有声明,将会报运行时错误。比如下面的代码在运行时将会报出一个 unrecognized selector error 错误:

    1.  //Swift
    2. myObject.characterAtIndex(5)
    3. // crash, myObject does't respond to that method

    但是,你可以通过 Swift 的 optinals 特性来排除这个 Objective-C 中常见的错误,当你用AnyObject对象调用一个 Objective-C 方法时,这次调用将会变成一次隐式展开 optional(implicitly unwrapped optional)的行为。你可以通过 optional 特性来决定 AnyObject 类型的对象是否调用该方法,同样的,你可以把这种特性应用在属性上。

    举个例子,在下面的代码中,第一和第二行代码将不会被执行因为length属性和characterAtIndex:方法不存在于 NSDate 对象中。myLength常量会被推测成可选的Int类型并且被赋值为nil。同样你可以使用if-let声明来有条件的展开这个方法的返回值,从而判断对象是否能执行这个方法。就像第三行做的一样。


    1.  //Swift
    2. let myLength = myObject.length?
    3. let myChar = myObject.characterAtIndex?(5)
    4. if let fifthCharacter = myObject.characterAtIndex(5) {
    5. println("Found \(fifthCharacter) at index 5")
    6. }


    对于 Swift 中的强制类型转换,从 AnyObject 类型的对象转换成明确的类型并不会保证成功,所以它会返回一个可选的值。而你需通过检查该值的类型来确认转换是否成功。

    1.  //Swift
    2. let userDefaults = NSUserDefaults.standardUserDefaults()
    3. let lastRefreshDate: AnyObject? = userDefaults.objectForKey("LastRefreshDate")
    4. if let date = lastRefreshDate as? NSDate {
    5. println("\(date.timeIntervalSinceReferenceDate)")
    6. }

    当然,如果你能确定这个对象的类型(并且确定不是nil),你可以添加as操作符强制调用。

    1.  //Swift
    2. let myDate = lastRefreshDate as NSDate
    3. let timeInterval = myDate.timeIntervalSinceReferenceDate

    使用nil

    在Objective-C中,对象的引用可以是值为NULL的原始指针(同样也是Objective-C中的nil)。而在Swift中,所有的值–包括结构体与对象的引用–都被保证为非空。作为替代,你将这个可以为空的值包装为optional type。当你需要宣告值为空时,你需要使用nil。你可以在Optionals中了解更多。

    因为Objective-C不会保证一个对象的值是否非空,Swift在引入Objective-C的API的时候,确保了所有函数的返回类型与参数类型都是optional,在你使用Objective-C的API之前,你应该检查并保证该值非空。 在某些情况下,你可能绝对确认某些Objective-C方法或者属性永远不应该返回一个nil的对象引用。为了让对象在这种情况下更加易用,Swift使用 implicitly unwrapped optionals 方法引入对象, implicitly unwrapped optionals 包含optional 类型的所有安全特性。此外,你可以直接访问对象的值而无需检查nil。当你访问这种类型的变量时, implicitly unwrapped optional 首先检查这个对象的值是否不存在,如果不存在,将会抛出运行时错误。

    扩展(Extensions)

    Swift 的扩展和 Objective-C 的类别(Category)相似。扩展为原有的类,结构和枚举丰富了功能,包括在 Objective-C 中定义过的。你可以为系统的框架或者你自己的类型增加扩展,只需要导入合适的模块并且保证你在 Objective-C 中使用的类、结构或枚举拥有相同的名字。

    举个例子,你可以扩展UIBezierPath类来为它增加一个等边三角形,这个方法只需提供三角形的边长与起点。

    1.  //Swift
    2. extension UIBezierPath {
    3. convenience init(triangleSideLength: Float, origin: CGPoint) {
    4. self.init()
    5. let squareRoot = Float(sqrt(3))
    6. let altitude = (squareRoot * triangleSideLength) / 2
    7. moveToPoint(origin)
    8. addLineToPoint(CGPoint(triangleSideLength, origin.x))
    9. addLineToPoint(CGPoint(triangleSideLength / 2, altitude))
    10. closePath()
    11. }
    12. }
    你也可以使用扩展来增加属性(包括类的属性与静态属性)。然而,这些属性必须是通过计算才能获取的,扩展不会为类,结构体,枚举存储属性。下面这个例子为CGRect类增加了一个叫area的属性。

    1.  //Swift
    2. extension CGRect {
    3. var area: CGFloat {
    4. return width * height
    5. }
    6. }
    7. let rect = CGRect(x: 0.0, y: 0.0, width: 10.0, height: 50.0)
    8. let area = rect.area
    9. // area: CGFloat = 500.0

    你同样可以使用扩展来为类添加协议而无需增加它的子类。如果这个协议是在 Swift 中被定义的,你可以添加 comformance 到它的结构或枚举中无论它们在 Objective-C 或在 Swift 中被定义。

    你不能使用扩展来覆盖 Objective-C 类型中存在的方法与属性。

    闭包(Closures)

    Objective-C 中的blocks会被自动导入为 Swift 中的闭包。例如,下面是一个 Objective-C 中的 block 变量:


    1.  //Objective-C
    2. void (^completionBlock)(NSData *, NSError *) = ^(NSData *data, NSError *error) {/* ... */}

    而它在 Swift 中的形式为

    1.  //Swift
    2. let completionBlock: (NSData, NSError) -> Void = {data, error in /* ... */}

    Swift 的闭包与 Objective-C 中的 blocks 能够和睦相处,所以你可以把一个 Swift 闭包传递给一个把 block 作为参数的 Objective-C 函数。Swift 闭包与函数具有互通的类型,所以你甚至可以传递 Swift 函数的名字。
    闭包与 blocks 语义上想通但是在一个地方不同:变量是可以直接改变的,而不是像 block 那样会拷贝变量。换句话说,Swift 中变量的默认行为与 Objective-C 中 __block 变量一致。

    比较对象

    当比较两个 Swift 中的对象时,可以使用两种方式。第一种,使用(==),判断两个对象内容是否相同。第二种,使用(===),判断常量或者变量是否为同一个对象的实例。

    Swift 与 Objective-C 一般使用 == 与 === 操作符来做比较。Swift 的 == 操作符为源自 NSObject 的对象提供了默认的实现。在实现 == 操作符时,Swift 调用 NSObject 定义的 isEqual: 方法。

    NSObject 类仅仅做了身份的比较,所以你需要在你自己的类中重新实现 isEqual: 方法。因为你可以直接传递 Swift 对象给 Objective-C 的 API,你也应该为这些对象实现自定义的 isEqual: 方法,如果你希望比较两个对象的内容是否相同而不是仅仅比较他们是不是由相同的对象派生。

    作为实现比较函数的一部分,确保根据Object comparison实现对象的hash属性。更进一步的说,如果你希望你的类能够作为字典中的键,也需要遵从Hashable协议以及实现hashValues属性。

    Swift 类型兼容性

    当你定义了一个继承自NSObject或者其他 Objective-C 类的 Swift 类,这些类都能与 Objective-C 无缝连接。所有的步骤都有 Swift 编译器自动完成,如果你从未在 Objective-C 代码中导入 Swift 类,你也不需要担心类型适配问题。另外一种情况,如果你的 Swift 类并不来源自 Objectve-C 类而且你希望能在 Objecive-C 的代码中使用它,你可以使用下面描述的 @objc 属性。

    @objc可以让你的 Swift API 在 Objective-C 中使用。换句话说,你可以通过在任何 Swift 方法、类、属性前添加@objc,来使得他们可以在 Objective-C 代码中使用。如果你的类继承自 Objective-C,编译器会自动帮助你完成这一步。编译器还会在所有的变量、方法、属性前加 @objc,如果这个类自己前面加上了@objc关键字。当你使用@IBOutlet,@IBAction,或者是@NSManaged属性时,@objc也会自动加在前面。这个关键字也可以用在 Objetive-C 中的 target-action 设计模式中,例如,NSTimer或者UIButton。

    当你在 Objective-C 中使用 Swift API,编译器基本对语句做直接的翻译。例如,Swift API func playSong(name: String)会被解释为- (void)playSong:(NSString *)name。然而,有一个例外:当在 Objective-C 中使用 Swift 的初始化函数,编译器会在方法前添加“initWith”并且将原初始化函数的第一个参数首字母大写。例如,这个 Swift 初始化函数init (songName: String, artist: String将被翻译为- (instancetype)initWithSongName:(NSString *)songName artist:(NSString *)artist 。

    Swift 同时也提供了一个@objc关键字的变体,通过它你可以自定义在 Objectiv-C 中转换的函数名。例如,如果你的 Swift 类的名字包含 Objecytive-C 中不支持的字符,你就可以为 Objective-C 提供一个可供替代的名字。如果你给 Swift 函数提供一个 Objecytive-C 名字,要记得为带参数的函数添加(:)

    1.  //Swift
    2. @objc(Squirrel)
    3. class Белка {
    4. @objc(initWithName:)
    5. init (имя: String) { /*...*/ }
    6. @objc(hideNuts:inTree:)
    7. func прячьОрехи(Int, вДереве: Дерево) { /*...*/ }
    8. }

    当你在 Swift 类中使用@objc(<#name#>)关键字,这个类可以不需要命名空间即可在 Objective-C 中使用。这个关键字在你迁徙 Objecive-C 代码到 Swift 时同样也非常有用。由于归档过的对象存贮了类的名字,你应该使用@objc(<#name#>)来声明与旧的归档过的类相同的名字,这样旧的类才能被新的 Swift 类解档。

    Objective-C 选择器(Selectors)

    一个 Objective-C 选择器类型指向一个 Objective-C 的方法名。在 Swift 时代,Objective-C 的选择器被Selector结构体替代。你可以通过字符串创建一个选择器,比如let mySelector: Selector = "tappedButton:"。因为字符串能够自动转换为选择器,所以你可以把字符串直接传递给接受选择器的方法。


    1.  //Swift
    2. import UIKit
    3. class MyViewController: UIViewController {
    4. let myButton = UIButton(frame: CGRect(x: 0, y: 0, width: 100, height: 50))

    6. init(nibName nibNameOrNil: String!, bundle nibBundleOrNil: NSBundle!) {
    7. super.init(nibName: nibName, bundle: nibBundle)
    8. myButton.targetForAction("tappedButton:", withSender: self)
    9. }

    11. func tappedButton(sender: UIButton!) {
    12. println("tapped button")
    13. }
    14. }

    注意: performSelector:方法和相关的调用选择器的方法没有导入到 Swift 中因为它们是不安全的。

    如果你的 Swift 类继承自 Objective-C 的类,你的所有方法都可以用作 Objective-C 的选择器。另外,如果你的 Swift 类不是继承自 Objective-C,如果你想要当选择器来使用你就需要在前面添加@objc关键字,详情请看Swift 类型兼容性。


    作者:iOS鑫
    链接:https://www.jianshu.com/p/c17977fd96aa




    收起阅读 »

    iOS 优雅的处理网络数据,你真的会吗?不如看看这篇.

    相信大家平时在用 App 的时候, 往往有过这样的体验,那就是加载网络数据等待的时间过于漫长,滚动浏览时伴随着卡顿,甚至在没有网络的情况下,整个应用处于不可用状态。那么我们该怎么去提高用户体验,保证用户没有漫长的等待感,还可以轻松自在的享受等待,对加载后的内容...
    继续阅读 »
    相信大家平时在用 App 的时候, 往往有过这样的体验,那就是加载网络数据等待的时间过于漫长,滚动浏览时伴随着卡顿,甚至在没有网络的情况下,整个应用处于不可用状态。那么我们该怎么去提高用户体验,保证用户没有漫长的等待感,还可以轻松自在的享受等待,对加载后的内容有明确的预期呢?

    案例分享

    在现代的工作生活中,手机早已不是单纯的通信工具了,它更像是一个集办公,娱乐,消费的终端,潜移默化的成为了我们生活的一部分。所以作为 iOS 开发者的我们,在日常的开发中,也早已不是处理显示零星的数据这么简单,为了流量往往我们需要在 App 里显示大量有价值的信息来吸引用户,如何优雅的显示这些海量的数据,考量的就是你的个人经验了。

    正如大多数 iOS 开发人员所知,显示滚动数据是构建移动应用中常见的任务,Apple 的 SDK 提供了 UITableView 和 UICollectionVIew 这俩大组件来帮助执行这样的任务。但是,当需要显示大量数据时,确保平滑如丝的滚动可能会非常的棘手。所以今天正好趁这个机会,和大家分享一下处理大量可滚动数据方面的个人经验。

    在这篇文章中,你将会学到以下内容:

    1.让你的 App 可以无限滚动(infinite scrolling),并且滚动数据无缝加载

    2.让你的 App 数据滚动时避免卡顿,实现平滑如丝的滚动

    3.异步存储(Cache)和获取图像,来使你的 App 具有更高的响应速度


    无限滚动,无缝加载

    提到列表分页,相信大家第一个想到的就是 MJRefresh,用于上拉下拉来刷新数据,当滚动数据到达底部的时候向服务器发送请求,然后在控件底部显示一个 Loading 动画,待请求数据返回后,Loading 动画消失,由 UITableView 或者 UICollectionView 控件继续加载这些数据并显示给用户,效果如下图所示





    在这种情况下就造成了一种现象,那就是 App 向服务器请求数据到数据返回这段时间留下了一个空白,如果在网络差的情况下,这段空白的时间将会持续,这给人的体验会很不好。那该如何去避免这种现象呢!或者说我们能否去提前获取到其余的数据,在用户毫无感知的情况下把数据请求过来,看上去就像无缝加载一样呢!

    答案当然是肯定的!

    为了改善应用程序体验,在 iOS 10 上,Apple 对 UICollectionView 和 UITableView 引入了 Prefetching API,它提供了一种在需要显示数据之前预先准备数据的机制,旨在提高数据的滚动性能。

    首先,我先和大家介绍一个概念:无限滚动,无限滚动是可以让用户连续的加载内容,而无需分页。在 UI 初始化的时候 App 会加载一些初始数据,然后当用户滚动快要到达显示内容的底部时加载更多的数据。

    多年来,像 Instagram, Twitter 和 Facebook 这样的社交媒体公司都使这种技术。如果查看他们的 App ,你就可以看到无限滚动的实际效果,这里我就给大伙展示下 Instagram 的效果吧!





    如何实现

    由于 Instagram 的 UI 过于复杂,在这我就不去模仿实现了,但是我模仿了它的加载机制,同样的实现了一个简单的数据无限滚动和无缝加载的效果。

    简单的说下我的思路:

    先自定义一个 Cell 视图,这个视图由一个 UILabel 和 一个 UIImageView 构成,用于显示文本和网络图片;然后模拟网络请求来获取数据,注意该步骤一定是异步执行的;最后用 UITableView 来显示返回的数据,在 viewDidLoad 中先请求网络数据来获取一些初始化数据,然后再利用 UITableView 的 Prefetching API 来对数据进行预加载,从而来实现数据的无缝加载。

    那关于无限滚动该如何实现呢!其实这个无限滚动并不是真正意义上的永无止尽,严格意义上来讲它是有尽头的,只不过这个功能背后的数据是不可估量的,只有大量的数据做支持才能让应用一直不断的从服务端获取数据。

    正常情况下,我们在构建 UITableView 这个控件的时候,需要对它的行数(numsOfRow)做一个初始化,这个行数对我们实现无限加载和无缝加载是一个很关键的因素,假设我们每次根据服务端返回的数据量去更新 UITableView 的行数并 Reload,那我之前说的 Prefetching API 在这种情况下就失去作用了,因为它起作用的前提是要保证预加载数据时 UITableView 当前的行数要小于它的总行数。当然前者也可以实现数据加载,但它的效果就不是无缝加载,它在每次加载数据的时候都会有一个 Loading 等待的时间。

    回到我上面所说的无限滚动, 其实实现起来并不难,正常情况下,我们向服务端请求大量相同类型的数据的时候,都会提供一个接口,我称之为分页请求接口,该接口在每次数据返回的时候,都会告诉客户端总共有多少页数据,每页的数据量是多少,当前是第几页,这样我们就能计算出来总共的数据有多少,而这就是 UITableView 的总行数。

    响应数据的示范如下(为清楚起见,它仅显示与分页有关的字段):


    {

    "has_more": true,
    "page": 1,
    "total": 84,
    "items": [

    ...
    ...
    ]
    }




    下面,我就用代码来一步步的实现它吧!

    模拟分页请求

    由于没有找到合适的分页测试接口,于是我自己模拟一了一个分页请求接口,每次调用该接口的时候都延时 2s 来模拟网络请求的状态,代码如下:

     func fetchImages() {
    guard !isFetchInProcess else {
    return
    }

    isFetchInProcess = true
    // 延时 2s 模拟网络环境
    print("+++++++++++ 模拟网络数据请求 +++++++++++")
    DispatchQueue.global().asyncAfter(deadline: DispatchTime.now() + 2) {
    print("+++++++++++ 模拟网络数据请求返回成功 +++++++++++")
    DispatchQueue.main.async {
    self.total = 1000
    self.currentPage += 1
    self.isFetchInProcess = false
    // 初始化 30个 图片
    let imagesData = (1...30).map {
    ImageModel(url: baseURL+"\($0).png", order: $0)
    }
    self.images.append(contentsOf: imagesData)

    if self.currentPage > 1 {
    let newIndexPaths = self.calculateIndexPathsToReload(from: imagesData)
    self.delegate?.onFetchCompleted(with: newIndexPaths)
    } else {
    self.delegate?.onFetchCompleted(with: .none)
    }
    }
    }
    }

    数据回调处理:

    extension ViewController: PreloadCellViewModelDelegate {

    func onFetchCompleted(with newIndexPathsToReload: [IndexPath]?) {
    guard let newIndexPathsToReload = newIndexPathsToReload else {
    tableView.tableFooterView = nil
    tableView.reloadData()
    return
    }

    let indexPathsToReload = visibleIndexPathsToReload(intersecting: newIndexPathsToReload)
    indicatorView.stopAnimating()
    tableView.reloadRows(at: indexPathsToReload, with: .automatic)
    }

    func onFetchFailed(with reason: String) {
    indicatorView.stopAnimating()
    tableView.reloadData()
    }
    }

    预加载数据

    首先如果你想要 UITableView 预加载数据,你需要在 viewDidLoad() 函数中插入如下代码,并且请求第一页的数据:

    override func viewDidLoad() {
    super.viewDidLoad()
    // Do any additional setup after loading the view.
    ...
    tableView.prefetchDataSource = self
    ...
    // 模拟请求图片
    viewModel.fetchImages()
    }

    然后,你需要实现 UITableViewDataSourcePrefetching 的协议,它的协议里包含俩个函数:

    // this protocol can provide information about cells before they are displayed on screen.

    @protocol UITableViewDataSourcePrefetching <NSObject>

    @required

    // indexPaths are ordered ascending by geometric distance from the table view
    - (void)tableView:(UITableView *)tableView prefetchRowsAtIndexPaths:(NSArray<NSIndexPath *> *)indexPaths;

    @optional

    // indexPaths that previously were considered as candidates for pre-fetching, but were not actually used; may be a subset of the previous call to -tableView:prefetchRowsAtIndexPaths:
    - (void)tableView:(UITableView *)tableView cancelPrefetchingForRowsAtIndexPaths:(NSArray<NSIndexPath *> *)indexPaths;

    @end

    第一个函数会基于当前滚动的方向和速度对接下来的 IndexPaths 进行 Prefetch,通常我们会在这里实现预加载数据的逻辑。

    第二个函数是一个可选的方法,当用户快速滚动导致一些 Cell 不可见的时候,你可以通过这个方法来取消任何挂起的数据加载操作,有利于提高滚动性能, 在下面我会讲到。

    实现这俩个函数的逻辑代码为:

    extension ViewController: UITableViewDataSourcePrefetching {
    // 翻页请求
    func tableView(_ tableView: UITableView, prefetchRowsAt indexPaths: [IndexPath]) {
    let needFetch = indexPaths.contains { $0.row >= viewModel.currentCount}
    if needFetch {
    // 1.满足条件进行翻页请求
    indicatorView.startAnimating()
    viewModel.fetchImages()
    }

    for indexPath in indexPaths {
    if let _ = viewModel.loadingOperations[indexPath] {
    return
    }

    if let dataloader = viewModel.loadImage(at: indexPath.row) {
    print("在 \(indexPath.row) 行 对图片进行 prefetch ")
    // 2 对需要下载的图片进行预热
    viewModel.loadingQueue.addOperation(dataloader)
    // 3 将该下载线程加入到记录数组中以便根据索引查找
    viewModel.loadingOperations[indexPath] = dataloader
    }
    }
    }

    func tableView(_ tableView: UITableView, cancelPrefetchingForRowsAt indexPaths: [IndexPath]){
    // 该行在不需要显示的时候,取消 prefetch ,避免造成资源浪费
    indexPaths.forEach {
    if let dataLoader = viewModel.loadingOperations[$0] {
    print("在 \($0.row) 行 cancelPrefetchingForRowsAt ")
    dataLoader.cancel()
    viewModel.loadingOperations.removeValue(forKey: $0)
    }
    }
    }
    }

    最后,再加上俩个有用的方法该功能就大功告成了:

        // 用于计算 tableview 加载新数据时需要 reload 的 cell
    func visibleIndexPathsToReload(intersecting indexPaths: [IndexPath]) -> [IndexPath] {
    let indexPathsForVisibleRows = tableView.indexPathsForVisibleRows ?? []
    let indexPathsIntersection = Set(indexPathsForVisibleRows).intersection(indexPaths)
    return Array(indexPathsIntersection)
    }

    // 用于确定该索引的行是否超出了目前收到数据的最大数量
    func isLoadingCell(for indexPath: IndexPath) -> Bool {
    return indexPath.row >= (viewModel.currentCount)
    }

    见证时刻的奇迹到了,请看效果:




    通过日志,我们也可以清楚的看到,在滚动的过程中是有 Prefetch 和 CancelPrefetch 操作的:


    好了,到这里我就简单的实现了 UITableView 无尽滚动和对数据无缝加载的效果,你学会了吗?

    如何避免滚动时的卡顿

    当你遇到滚动卡顿的应用程序时,通常是由于任务长时间运行阻碍了 UI 在主线程上的更新,想让主线程有空来响应这类更新事件,第一步就是要将消耗时间的任务交给子线程去执行,避免在获取数据时阻塞主线程。

    苹果提供了很多为应用程序实现并发的方式,例如 GCD,我在这里对 Cell 上的图片进行异步加载使用的就是它。

    代码如下:


    class DataLoadOperation: Operation {
    var image: UIImage?
    var loadingCompleteHandle: ((UIImage?) -> ())?
    private var _image: ImageModel
    private let cachedImages = NSCache<NSURL, UIImage>()

    init(_ image: ImageModel) {
    _image = image
    }

    public final func image(url: NSURL) -> UIImage? {
    return cachedImages.object(forKey: url)
    }

    override func main() {
    if isCancelled {
    return
    }

    guard let url = _image.url else {
    return
    }
    downloadImageFrom(url) { (image) in
    DispatchQueue.main.async { [weak self] in
    guard let ss = self else { return }
    if ss.isCancelled { return }
    ss.image = image
    ss.loadingCompleteHandle?(ss.image)
    }
    }

    }

    // Returns the cached image if available, otherwise asynchronously loads and caches it.
    func downloadImageFrom(_ url: NSURL, completeHandler: @escaping (UIImage?) -> ()) {
    // Check for a cached image.
    if let cachedImage = image(url: url) {
    DispatchQueue.main.async {
    print("命中缓存")
    completeHandler(cachedImage)
    }
    return
    }

    URLSession.shared.dataTask(with: url as URL) { data, response, error in
    guard
    let httpURLResponse = response as? HTTPURLResponse, httpURLResponse.statusCode == 200,
    let mimeType = response?.mimeType, mimeType.hasPrefix("image"),
    let data = data, error == nil,
    let _image = UIImage(data: data)
    else { return }
    // Cache the image.
    self.cachedImages.setObject(_image, forKey: url, cost: data.count)
    completeHandler(_image)
    }.resume()
    }
    }

    那具体如何使用呢!别急,听我娓娓道来,这里我再给大家一个小建议,大家都知道 UITableView 实例化 Cell 的方法是:tableView:cellForRowAtIndexPath: ,相信很多人都会在这个方法里面去进行数据绑定然后更新 UI,其实这样做是一种比较低效的行为,因为这个方法需要为每个 Cell 调用一次,它应该快速的执行并返回重用 Cell 的实例,不要在这里去执行数据绑定,因为目前在屏幕上还没有 Cell。我们可以在 tableView:willDisplayCell:forRowAtIndexPath: 这个方法中进行数据绑定,这个方法在显示cell之前会被调用。

    为每个 Cell 执行下载任务的实现代码如下:

     func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    guard let cell = tableView.dequeueReusableCell(withIdentifier: "PreloadCellID") as? ProloadTableViewCell else {
    fatalError("Sorry, could not load cell")
    }

    if isLoadingCell(for: indexPath) {
    cell.updateUI(.none, orderNo: "\(indexPath.row)")
    }

    return cell
    }

    func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) {
    // preheat image ,处理将要显示的图像
    guard let cell = cell as? ProloadTableViewCell else {
    return
    }

    // 图片下载完毕后更新 cell
    let updateCellClosure: (UIImage?) -> () = { [unowned self] (image) in
    cell.updateUI(image, orderNo: "\(indexPath.row)")
    viewModel.loadingOperations.removeValue(forKey: indexPath)
    }

    // 1\. 首先判断是否已经存在创建好的下载线程
    if let dataLoader = viewModel.loadingOperations[indexPath] {
    if let image = dataLoader.image {
    // 1.1 若图片已经下载好,直接更新
    cell.updateUI(image, orderNo: "\(indexPath.row)")
    } else {
    // 1.2 若图片还未下载好,则等待图片下载完后更新 cell
    dataLoader.loadingCompleteHandle = updateCellClosure
    }
    } else {
    // 2\. 没找到,则为指定的 url 创建一个新的下载线程
    print("在 \(indexPath.row) 行创建一个新的图片下载线程")
    if let dataloader = viewModel.loadImage(at: indexPath.row) {
    // 2.1 添加图片下载完毕后的回调
    dataloader.loadingCompleteHandle = updateCellClosure
    // 2.2 启动下载
    viewModel.loadingQueue.addOperation(dataloader)
    // 2.3 将该下载线程加入到记录数组中以便根据索引查找
    viewModel.loadingOperations[indexPath] = dataloader
    }
    }
    }

    对预加载的图片进行异步下载(预热):


    func tableView(_ tableView: UITableView, prefetchRowsAt indexPaths: [IndexPath]) {
    let needFetch = indexPaths.contains { $0.row >= viewModel.currentCount}
    if needFetch {
    // 1.满足条件进行翻页请求
    indicatorView.startAnimating()
    viewModel.fetchImages()
    }

    for indexPath in indexPaths {
    if let _ = viewModel.loadingOperations[indexPath] {
    return
    }

    if let dataloader = viewModel.loadImage(at: indexPath.row) {
    print("在 \(indexPath.row) 行 对图片进行 prefetch ")
    // 2 对需要下载的图片进行预热
    viewModel.loadingQueue.addOperation(dataloader)
    // 3 将该下载线程加入到记录数组中以便根据索引查找
    viewModel.loadingOperations[indexPath] = dataloader
    }
    }
    }

    取消 Prefetch 时,cancel 任务,避免造成资源浪费

    func tableView(_ tableView: UITableView, cancelPrefetchingForRowsAt indexPaths: [IndexPath]){
    // 该行在不需要显示的时候,取消 prefetch ,避免造成资源浪费
    indexPaths.forEach {
    if let dataLoader = viewModel.loadingOperations[$0] {
    print("在 \($0.row) 行 cancelPrefetchingForRowsAt ")
    dataLoader.cancel()
    viewModel.loadingOperations.removeValue(forKey: $0)
    }
    }
    }

    经过这般处理,我们的 UITableView 滚动起来肯定是如丝般顺滑,小伙伴们还等什么,还不赶紧试一试。


    图片缓存

    虽然我在上面对我的应用增加了并发操作,但是我一看 Xcode 的性能分析,我不禁陷入了沉思,我的应用程序太吃内存了,假如我不停的刷,那我的手机应该迟早会把我的应用给终止掉,下图是我刷到 200 行的时候的性能分析图:

    内存



    可以看到我的应用的性能分析很不理想,究其原因在于我的应用里显示了大量的图片资源,每次来回滚动的时候,都会重新去下载新的图片,而没有对图片做缓存处理。

    所以,针对这个问题,我为我的应用加入了缓存 NSCache 对象,来对图片做一个缓存,具体代码实现如下:


    class ImageCache: NSObject {

    private var cache = NSCache<AnyObject, UIImage>()
    public static let shared = ImageCache()
    private override init() {}

    func getCache() -> NSCache<AnyObject, UIImage> {
    return cache
    }
    }

    在下载开始的时候,检查有没有命中缓存,如果命中则直接返回图片,否则重新下载图片,并添加到缓存中:

    func downloadImageFrom(_ url: URL, completeHandler: @escaping (UIImage?) -> ()) {
    // Check for a cached image.
    if let cachedImage = getCacheImage(url: url as NSURL) {
    print("命中缓存")
    DispatchQueue.main.async {
    completeHandler(cachedImage)
    }
    return
    }

    URLSession.shared.dataTask(with: url) { data, response, error in
    guard
    let httpURLResponse = response as? HTTPURLResponse, httpURLResponse.statusCode == 200,
    let mimeType = response?.mimeType, mimeType.hasPrefix("image"),
    let data = data, error == nil,
    let _image = UIImage(data: data)
    else { return }

    // Cache the image.
    ImageCache.shared.getCache().setObject(_image, forKey: url as NSURL)

    completeHandler(_image)
    }.resume()
    }
    有了缓存的加持后,再用 Xcode 来查看我的应用的性能,就会发现内存和磁盘的占用已经下降了很多:




    关于图片缓存的技术,这里只是用了最简单的一种,外面很多开源的图片库都有不同的缓存策略,感兴趣的可以去 GitHub 上学习一下它们的源码,我在这里就不做赘述了。




    作者:iOS鑫
    链接:https://www.jianshu.com/p/f00f43e401da

    收起阅读 »

    iOS 对接系统“fileAPP” - 文件操作

    1、前言iOS文件存储机制每个iOS程序都有一个独立的文件系统(存储空间),而且只能在对应的文件系统中进行操作,此区域被称为沙盒。应用必须待在自己的沙盒里,其他应用不能访问该沙盒。所有的非代码文件都要保存在此,例如属性文件plist、文本文件、图像、图标、媒体...
    继续阅读 »

    1、前言

    iOS文件存储机制

    每个iOS程序都有一个独立的文件系统(存储空间),而且只能在对应的文件系统中进行操作,此区域被称为沙盒。应用必须待在自己的沙盒里,其他应用不能访问该沙盒。所有的非代码文件都要保存在此,例如属性文件plist、文本文件、图像、图标、媒体资源等

    沙盒中相关路径

    AppName.app 应用程序的程序包目录,包含应用程序的本身。由于应用程序必须经过签名,所以不能在运行时对这个目录中的内容进行修改,否则会导致应用程序无法启动。

    Documents/ 保存应用程序的重要数据文件和用户数据文件等。用户数据基本上都放在这个位置(例如从网上下载的图片或音乐文件),该文件夹在应用程序更新时会自动备份,在连接iTunes时也可以自动同步备份其中的数据。

    Library:这个目录下有两个子目录,可创建子文件夹。可以用来放置您希望被备份但不希望被用户看到的数据。该路径下的文件夹,除Caches以外,都会被iTunes备份.

    Library/Caches: 保存应用程序使用时产生的支持文件和缓存文件(保存应用程序再次启动过程中需要的信息),还有日志文件最好也放在这个目录。iTunes 同步时不会备份该目录并且可能被其他工具清理掉其中的数据。
    Library/Preferences: 保存应用程序的偏好设置文件。NSUserDefaults类创建的数据和plist文件都放在这里。会被iTunes备份。

    相关问题

    因为每个app下的沙盒路径都是封闭的,其他应用访问不到,也就导致了文件不能共享。只能自己在代码中维护本app内的文件。这给用户带来很多的不便。因此,苹果除了一个系统的“文件”的app,用来管理app内的文件。但是系统的“文件”这个app不是可以管理全部的app下的文件,他只能管理对“文件”这个app开放权限的APP。

    计划

    最近在做IM开发,涉及到文件传输,我们不想做的特别封闭,所以就想可以发送app以外的文件(比如微信中保存下来的)具体实现就是:从微信里下载的文件保存到“ fileAPP”内,然后我们在发送文件时,可以发送本地文件,也可以发送“ fileAPP”内保存的文件

    2、让自己的app对“ fileAPP”开放管理权限

    2.1、在Identifiers下选择你要添加icloud的boundid把icloud配置勾选上


    2.2、工程配置



    点击Caoablity左侧的加号,搜索iCloud,然后添加即可

    2.3、 设置info.plist

    第一个是 UIFileSharingEnabled,这个可以使 iTunes 分享你文件夹内的内容;第二个是 LSSupportsOpeningDocumentsInPlace ,它保证了你文件夹内本地文件的获取权限,你需要将这两个键值对的值设置为 YES

    以上设置完,重新运行app之后,在系统的“ fileAPP”中会出现一个以你的APP命名的文件夹,里面包含了APP内沙盒的目录和文件






    但是这里面的文件很乱,而且会将沙盒内 Documents 文件夹内的所有文件都显示出来

    2.4、如何在fileAPP里隐藏重要的文件?

    如果它不是那么重要的,我们可以将它们存放在 cachesDirectory 或者是 temporaryDirectory 文件夹下面;如果它是重要的文件,大多数情况下,我们是需要将它们备份在 iCloud 上的,这样的文件我们建议将它存放在 applicationSupportDirectory 目录下




    以上,是将自己的文件共享给 fileAPP

    3、app如何获取到“文件”app下管理的文件到本app内

    3.1、调起fileAPP 文件目录

    //打开文件APP
    - (void)presentDocumentCloud {
    NSArray *documentTypes = @[@"public.content", @"public.text", @"public.source-code ", @"public.image", @"public.audiovisual-content", @"com.adobe.pdf", @"com.apple.keynote.key", @"com.microsoft.word.doc", @"com.microsoft.excel.xls", @"com.microsoft.powerpoint.ppt"];

    UIDocumentPickerViewController *documentPickerViewController = [[UIDocumentPickerViewController alloc] initWithDocumentTypes:documentTypes inMode:UIDocumentPickerModeOpen];
    documentPickerViewController.delegate = self;
    [self presentViewController:documentPickerViewController animated:YES completion:nil];
    }

    这里的documentTypes数组内设置要拿的文件格式

    UIDocumentPickerMode有四种:

    typedef NS_ENUM(NSUInteger, UIDocumentPickerMode) {
    UIDocumentPickerModeImport,
    UIDocumentPickerModeOpen,
    UIDocumentPickerModeExportToService,
    UIDocumentPickerModeMoveToService
    } API_DEPRECATED("Use appropriate initializers instead",ios(8.0,14.0)) API_UNAVAILABLE(tvOS);


    UIDocumentPickerModeImport : 将文件拿出来UIDocumentPickerModeOpen:打开文件
    后面是将文件传到fileAPP内的操作,类似于微信的保存文件到fileAPP内的操作。这里官方文档之给了前两个,后面的我们也没涉及到,以后研究吧。

    3.2、设置代理
    <UIDocumentPickerDelegate, UIDocumentInteractionControllerDelegate>
    3.3、实现代理
    #pragma mark - UIDocumentPickerDelegate
    - (void)documentPicker:(UIDocumentPickerViewController *)controller didPickDocumentAtURL:(NSURL *)url {

    BOOL fileUrlAuthozied = [url startAccessingSecurityScopedResource];
    if (fileUrlAuthozied && [self iCloudEnable]) {
    //通过文件协调工具来得到新的文件地址,以此得到文件保护功能
    NSFileCoordinator *fileCoordinator = [[NSFileCoordinator alloc] init];
    NSError *error;

    [fileCoordinator coordinateReadingItemAtURL:url options:0 error:&error byAccessor:^(NSURL *newURL) {
    //读取文件
    NSString *fileName = [newURL lastPathComponent];
    fileName = [fileName stringByRemovingPercentEncoding];
    NSData * data = [NSData dataWithContentsOfURL:newURL];

    self.completionBlock(data,fileName);
    self.completionBlock = nil;
    }];
    [url stopAccessingSecurityScopedResource];
    }
    }

    这里需要将拿到的url做处理,应为这里拿到的url是fileAPP文件的本地文件路径,在自己的app内通过[NSData dataWithContentsOfURL:url]方法是无法拿到数据的,应该是只能拿自己沙盒文件路径的设置的原因。

     [fileCoordinator coordinateReadingItemAtURL:url options:0 error:&error byAccessor:^(NSURL *newURL) {

    }];

    这么处理后,拿到的newUrl就是本地的路径了,通过[NSData dataWithContentsOfURL:url]即可拿到文件data。

    之后即可对文件进行发送上传等操作。


    作者:冰棍儿好烫嘴
    链接:https://www.jianshu.com/p/19b1c0f124e2



    收起阅读 »

    基于环信MQTT消息云,Web客户端快速实现消息收发

    仓库地址: https://gitee.com/yoki_ss_admin/task-1-web使用说明:实例化客户端client.connect();var topic = 'topic/chat'; if(clienct.isConnect){ ...
    继续阅读 »

    基于环信封装的mqtt的Web客户端,实现了基础的获取 token、服务器连接、消息订阅、取消订阅、消息发送、断开连接


    仓库地址: https://gitee.com/yoki_ss_admin/task-1-web

    使用说明:

    • 文件引用
    • 实例化客户端
    • 服务器连接
    client.connect();
    • 订阅
    var topic = 'topic/chat';
    if(clienct.isConnect){
    client.subscribe(topic);
    }
    • 取消订阅
    var topic = 'topic/chat';
    if(clienct.isConnect){
    client.unsubscribe(topic);
    }
    • 消息发送
    var topic = 'topic/chat';
    var message = '这是我要发送的消息';
    if(clienct.isConnect){
    client.sendMessage(topic,message);
    }
    • 连接断开
    if(clienct.isConnect){
    client.discounnect(topic);
    }

    运行截图

    image

    项目依赖

    收起阅读 »

    CameraX 入门食用方法

    CameraX 已经发布了 1.0正式版 对于涉及到使用摄像头的 App , 能否充分利用摄像头有着很大的区别,为此 对 CameraX 进行了解与认知有一定的必要性.📑即将学会用 Jetpack 组件支持库 CameraX 创建相机、拍摄、预览⭕要求Goog...
    继续阅读 »

    CameraX 已经发布了 1.0正式版 对于涉及到使用摄像头的 App , 能否充分利用摄像头有着很大的区别,为此 对 CameraX 进行了解与认知有一定的必要性.

    📑即将学会

    用 Jetpack 组件支持库 CameraX 创建相机、拍摄、预览

    ⭕要求

    Google官方声明 CameraX 是 Jetpack组件支持库,帮助我们简化相机相关应用的开发工作。并且提供了一致且易用的 API 接口,适用于大多数 Android 设备,并向后兼容至 Android 5.0(API 级别 21)

    因此 创建Android应用的时候mininumSDK 需要选择5.0

    前置内容

    使用 Intent 进行拍照

    在应用中拍照的最简便的方法便是使用MediaStore.ACTION_IMAGE_CAPTURE,传入Intent并启动

    image.png 这会启动系统照相机,并为用户提供一套完整的拍照功能 这时,如果用户授予了用户拍照权限,并对拍照图片满意,我们将在onActivityResult中获取图片.默认情况下,拍摄的照片会以缩略图的形式返回,使用键data可以获得缩略图

    Bundle extras = data.getExtras();
    Bitmap imageBitmap = (Bitmap) extras.get("data");

    而要获取完整图片,需要在启动相机的Intent中,在intent的意图中,添加MediaStore.EXTRA_OUTPUT 参数中设置文件的输出URI,该URI会存储完整的照片

    image.png 存储后进行完整图片路径后的图片 并进行设置 该存储设置有一定的局限性,请参考官方对拍照的操作 拍照  |  Android 开发者  |  Android Developers (google.cn)image.png 这是我们日常中会使用到的一些摄像头获取图片的操作. 而在开发过程中,我们对camera2的API使用时还是会有很多脏代码,而CameraX作为Google推出的jetpack组件.简化了对Camera的开发,让我们看看如何使用CameraX

    实战

    创建项目

    image.png

    在 App 模块中添加 CameraX 依赖 并同步

    image.png

    使用 PreviewView 实现 CameraX 预览

    1.修改布局文件 布局中添加 PreviewView

    在布局文件中进行修改 image.png

    Manifest声明相机权限
    <uses-permission android:name="android.permission.CAMERA" />
    动态申请相机权限
    //覆写onRequestPermissionsResult()方法 
    override fun onRequestPermissionsResult(
    requestCode: Int, permissions: Array<String>, grantResults: IntArray) {
    if (requestCode == REQUEST_CODE_PERMISSIONS) {
    if (allPermissionsGranted()) {
    startCamera()
    } else {
    Toast.makeText(this,
    "权限未得到用户授予",
    Toast.LENGTH_SHORT).show()
    finish()
    }
    }
    2.请求 ProcessCameraProvider

    ProcessCameraProvider是一个单例 用于将相机的生命周期绑定到应用程序进程中的任何 生命周期持有者。因为cameraX具有生命周期感应 这可以使我们的应用程序省去打开和关闭相机的任务

    val cameraProviderFuture = ProcessCameraProvider.getInstance(this)
    3.检查 ProcessCameraProvider 可用性
    cameraProviderFuture.addListener(Runnable {}, ContextCompat.getMainExecutor(this))
    4.ProcessCameraProvider可用后 选择相机并绑定生命周期和用例
    • 创建 Preview
    • 指定所需的相机
    • 将所选相机和任意用例绑定到生命周期
    • 将 Preview 连接到 PreviewView
     cameraProviderFuture.addListener(Runnable {
    // 1将camera 绑定到 生命周期持有者
    val cameraProvider: ProcessCameraProvider = cameraProviderFuture.get()

    // 2创建 Preview。
    val preview = Preview.Builder()
    .build()
    .also {
    //preview 连接 previewView
    it.setSurfaceProvider(findViewById<PreviewView>(R.id.viewFinder).getSurfaceProvider())
    }

    //3指定所需的相机
    val cameraSelector = CameraSelector.DEFAULT_BACK_CAMERA

    try {
    // 4绑定前解绑
    cameraProvider.unbindAll()

    // 5绑定用户用例和相机到生命周期
    cameraProvider.bindToLifecycle(
    this, cameraSelector, preview)

    } catch(exc: Exception) {
    Log.e(TAG, "Use case binding failed", exc)
    }

    }, ContextCompat.getMainExecutor(this))

    效果图

    image.png

    这是camera的预览功能

    cameraX相片拍摄

    配置应用拍摄图片
    • 利用 ImageCapture.Builder 构建 imageCapture
    • 绑定用户用例和相机到生命周期 多了一个 imageCapture
    cameraProvider.bindToLifecycle(this, cameraSelector, preview, imageCapture)
    拍照
    • 获取对 ImageCapture 用例的引用
    • 创建图片存储容纳文件
    • 创建OutputFileOptions指定输出方式 输出路径等内容
    val outputFileOptions = ImageCapture.OutputFileOptions.Builder(File(...)).build()
    • 对 imageCapture 对象调用 takePicture()方法。传入刚才构建的 outputOptions 以及保存图片的回调

    最终修改代码

    cameraProviderFuture.addListener(Runnable {
    // 1将camera 绑定到 生命周期持有者
    val cameraProvider: ProcessCameraProvider = cameraProviderFuture.get()

    // 2创建 Preview。
    val preview = Preview.Builder()
    .build()
    .also {
    //preview 连接 previewView
    it.setSurfaceProvider(findViewById<PreviewView>(R.id.viewFinder).getSurfaceProvider())
    }
    //todo 新增行
    //图像捕获 构建
    imageCapture = ImageCapture.Builder()
    .build()

    //3指定所需的相机
    val cameraSelector = CameraSelector.DEFAULT_BACK_CAMERA

    try {
    // 4绑定前解绑
    cameraProvider.unbindAll()

    //todo 新增修改行
    // 5绑定用户用例和相机到生命周期
    cameraProvider.bindToLifecycle(
    this, cameraSelector, preview, imageCapture)

    } catch(exc: Exception) {
    Log.e(TAG, "Use case binding failed", exc)
    }

    }, ContextCompat.getMainExecutor(this))


    private fun takePhoto() {
    // 获取图像捕获用例
    val imageCapture = imageCapture ?: return


    // 创建存储文件对象
    val photoFile = File(
    outputDirectory,
    SimpleDateFormat(FILENAME_FORMAT, Locale.CHINA
    ).format(System.currentTimeMillis()) + ".jpg")

    // 输出条件构建
    val outputOptions = ImageCapture.OutputFileOptions.Builder(photoFile).build()

    // 拍照 传入输出条件 以及拍照回调
    imageCapture.takePicture(
    outputOptions, ContextCompat.getMainExecutor(this), object : ImageCapture.OnImageSavedCallback {
    override fun onError(exc: ImageCaptureException) {
    //异常打印
    Log.e(TAG, "拍照失败: ${exc.message}", exc)
    }

    override fun onImageSaved(output: ImageCapture.OutputFileResults) {
    val savedUri = Uri.fromFile(photoFile)
    val msg = "拍照成功: $savedUri"
    Toast.makeText(baseContext, msg, Toast.LENGTH_SHORT).show()
    Log.d(TAG, msg)
    }
    })
    }

    运行展示

    image.png


    收起阅读 »

    RecyclerView列表动画

    一 ItemAnimator的使用触发删除动画mDatas.remove(position); notifyItemRemoved(position) 触发添加动画mDatas.add(position,data); notifyItemInserted(p...
    继续阅读 »

    一 ItemAnimator的使用

    触发删除动画

    mDatas.remove(position);
    notifyItemRemoved(position)

    触发添加动画

    mDatas.add(position,data);
    notifyItemInserted(position)

    触发改变动画

    mDatas.set(position,newData);
    notifyItemChanged(position)

    使用简单动画

    //RecyclerView.LayoutManager.java
    public boolean supportsPredictiveItemAnimations() {
    return false;
    }

    添加/删除/改变都是渐入渐出动画:

    使用预测性动画

    //RecyclerView.LayoutManager.java
    public boolean supportsPredictiveItemAnimations() {
    return true;
    }

    二 配合LayoutAnimation使用

    RecyclerView和普通的ViewGroup一样支持LayoutAnimation.使用起来比较简单,设置RecyclerView的 animateLayoutChangeslayoutAnimation属性即可.

    案例

    layout_animation_recyclerview.gif
    图片出处:Layout animations on RecyclerView

    layoutanimation1.gif
    图片出处:RecyclerView 与 LayoutAnimation 实现的进入动画(一 ): List

    三 自定义RecyclerView列表动画

    案例学习:自定义change动画

    效果:

    代码实现:

    1.新建MyChangeAnimator类继承DefaultItemAnimator

    private class MyChangeAnimator extends DefaultItemAnimator {
    }

    2.重写DefaultItemAnimatorcanReuseUpdatedViewHolder()方法.

    @Override
    public boolean canReuseUpdatedViewHolder(RecyclerView.ViewHolder viewHolder) {
    //change动画在同一个ItemHolder上执行
    return true;
    }

    3.新建ColorTextInfo类继承ItemHolderInfo,新增两个字段记录item的颜色和文字.

    private class ColorTextInfo extends ItemHolderInfo {
    int color;
    String text;
    }

    4.重写DefaultItemAnimatorobtainHolderInfo()方法,新建一个ColorTextInfo对象返回.

    @Override
    public ItemHolderInfo obtainHolderInfo() {
    return new ColorTextInfo();
    }
    1. 重写DefaultItemAnimatorrecordPreLayoutInformation()recordPostLayoutInformation()方法.在item变化前和变化后记录颜色和文字信息.
    public ItemHolderInfo recordPreLayoutInformation(RecyclerView.State state,
    RecyclerView.ViewHolder viewHolder, int changeFlags, List<Object> payloads) {
    ColorTextInfo info = (ColorTextInfo) super.recordPreLayoutInformation(state, viewHolder,changeFlags, payloads);
    //记录item变化前的颜色和文字
    return getItemHolderInfo((MyViewHolder) viewHolder, info);
    }

    public ItemHolderInfo recordPostLayoutInformation(@NonNull RecyclerView.State state,
    @NonNull RecyclerView.ViewHolder viewHolder) {
    ColorTextInfo info = (ColorTextInfo) super.recordPostLayoutInformation(state, viewHolder);
    //记录item变化后的颜色和文字
    return getItemHolderInfo((MyViewHolder) viewHolder, info);
    }

    //从viewHolder上获取ColorTextInfo信息
    private ItemHolderInfo getItemHolderInfo(MyViewHolder viewHolder, ColorTextInfo info) {
    final MyViewHolder myHolder = viewHolder;
    final int bgColor = ((ColorDrawable) myHolder.container.getBackground()).getColor();
    info.color = bgColor;
    info.text = (String) myHolder.textView.getText();
    return info;
    }

    6.重写DefaultItemAnimatoranimateChange()方法,执行自定义的change动画

    顺序执行
    顺序执行
    开始change动画
    旧的颜色到黑色的渐变
    旧的文字绕x轴旋转0->90度
    黑色到新的颜色的渐变
    新的文字绕x轴旋转-90->0度
    change动画结束
    public boolean animateChange(@NonNull final RecyclerView.ViewHolder oldHolder,
    @NonNull final RecyclerView.ViewHolder newHolder,
    @NonNull ItemHolderInfo preInfo, @NonNull ItemHolderInfo postInfo) {

    ...

    final MyViewHolder viewHolder = (MyViewHolder) newHolder;

    //读取change前后的颜色和文字信息
    ColorTextInfo oldInfo = (ColorTextInfo) preInfo;
    ColorTextInfo newInfo = (ColorTextInfo) postInfo;
    int oldColor = oldInfo.color;
    int newColor = newInfo.color;
    final String oldText = oldInfo.text;
    final String newText = newInfo.text;

    LinearLayout newContainer = viewHolder.container;
    final TextView newTextView = viewHolder.textView;


    // 构造旧的颜色到黑色的渐变动画
    ObjectAnimator fadeToBlack = null, fadeFromBlack;
    fadeToBlack = ObjectAnimator.ofInt(newContainer, "backgroundColor",
    startColor, Color.BLACK);
    fadeToBlack.setEvaluator(mColorEvaluator);

    // 构造黑色到新的颜色的渐变动画
    fadeFromBlack = ObjectAnimator.ofInt(newContainer, "backgroundColor",
    Color.BLACK, newColor);

    // 这两个渐变动画顺序执行
    AnimatorSet bgAnim = new AnimatorSet();
    bgAnim.playSequentially(fadeToBlack, fadeFromBlack);

    //构造旧的文字绕x轴旋转0->90度的动画
    ObjectAnimator oldTextRotate = null, newTextRotate;
        oldTextRotate = ObjectAnimator.ofFloat(newTextView, View.ROTATION_X, 0, 90);
        oldTextRotate.setInterpolator(mAccelerateInterpolator);
        oldTextRotate.addListener(new AnimatorListenerAdapter() {
         boolean mCanceled = false;
         @Override
         public void onAnimationStart(Animator animation) {
         //动画开始时显示旧的文字
         newTextView.setText(oldText);
         }

         @Override
         public void onAnimationCancel(Animator animation) {
         mCanceled = true;
         }

         @Override
         public void onAnimationEnd(Animator animation) {
         if (!mCanceled) {
         //动画结束时显示新的文字
         newTextView.setText(newText);
         }
         }
        });

    // 构造新的文字绕x轴旋转-90->0度的动画
    newTextRotate = ObjectAnimator.ofFloat(newTextView, View.ROTATION_X, -90, 0);
    newTextRotate.setInterpolator(mDecelerateInterpolator);

    //两个旋转动画顺序执行
    AnimatorSet textAnim = new AnimatorSet();
    textAnim.playSequentially(oldTextRotate, newTextRotate);

    // 渐变的动画和旋转的动画同时执行
    AnimatorSet changeAnim = new AnimatorSet();
    changeAnim.playTogether(bgAnim, textAnim);
    changeAnim.addListener(new AnimatorListenerAdapter() {
    @Override
    public void onAnimationEnd(Animator animation) {
    dispatchAnimationFinished(newHolder);
    ...
    }
    });
    changeAnim.start();

    return true;
    }

    7.设置RecyclerViewItemAnimator为自定义的MyChangeAnimator

    mRecyclerView.setItemAnimator(mChangeAnimator);

    这是简化后的代码.官方完整的demo里还包括了边界情况的处理,处理了上一次change动画没执行完时触发新的change动画的情况.
    代码地址:github.com/android/vie…

    自定义add和del动画

    目标效果:

    代码实现:

    1.拷贝DefaultItemAnimator源码,命名为DefaultItemAnimatorOpen.java

    2.重写添加和删除的动画实现.(这一步需要修改DefaultItemAnimatorOpen中一些方法和属性的可见性为protected).

    参考DefaultItemAnimatorOpen中对应方法的实现,修改动画相关的代码即可:

    class CustomAddDelAnimation : DefaultItemAnimatorOpen() {


    override fun animateAdd(holder: RecyclerView.ViewHolder): Boolean {
    //重写item添加的动画
    resetAnimation(holder)
    //将新增的item绕x轴旋转90度
    holder.itemView.rotationX = 90f
    mPendingAdditions.add(holder)
    return true
    }

    override fun animateAddImpl(holder: RecyclerView.ViewHolder) {
    //添加item时执行绕x轴90->0度的旋转
    mAddAnimations.add(holder)
    holder.itemView.animate().apply {
    rotationX(0f)
    duration = addDuration
    interpolator = DecelerateInterpolator(3f)
    setListener(object : AnimatorListenerAdapter() {

    override fun onAnimationStart(animation: Animator?) {
    dispatchAddStarting(holder)
    }

    override fun onAnimationCancel(animation: Animator?) {
    ViewHelper.clear(holder.itemView)
    }

    override fun onAnimationEnd(animation: Animator) {
    ViewHelper.clear(holder.itemView)
    dispatchAddFinished(holder)
    mAddAnimations.remove(holder)
    dispatchFinishedWhenDone()
    }
    })
    }.start()
    }

    override fun animateRemove(holder: RecyclerView.ViewHolder): Boolean {
    //重写item删除的动画
    resetAnimation(holder)
    mPendingRemovals.add(holder)
    return true
    }

    override fun animateRemoveImpl(holder: RecyclerView.ViewHolder) {
    //删除item时执行绕x轴0->90度的旋转
    mRemoveAnimations.add(holder)
    holder.itemView.animate().apply {
    rotationX(90f)
    duration = addDuration
    interpolator = DecelerateInterpolator(3f)
    setListener(object : AnimatorListenerAdapter() {

    override fun onAnimationStart(animation: Animator?) {
    dispatchRemoveStarting(holder)
    }

    override fun onAnimationCancel(animation: Animator?) {
    ViewHelper.clear(holder.itemView)
    }

    override fun onAnimationEnd(animation: Animator) {
    ViewHelper.clear(holder.itemView)
    dispatchRemoveFinished(holder)
    mRemoveAnimations.remove(holder)
    dispatchFinishedWhenDone()
    }
    })
    }.start()
    }

    }

    demo地址:HoopAndroidDemos

    四 RecyclerView列表动画的原理简析

    «abstract»ItemAnimator«interface»ItemAnimatorListener«interface»ItemAnimatorFinishedListenerItemHolderInfo«abstract»SimpleItemAnimatorDefaultItemAnimator依赖依赖依赖继承继承

    默认可预测动画执行的顺序

    执行删除动画
    移动动画
    改变动画
    item动画执行结束
    执行延迟的item动画(下一帧)
    默认效果为渐出
    默认效果为平移
    默认效果为渐出+渐入
    添加动画(默认效果为渐入)
    重置状态

    列表动画是立即执行吗?
    animateXXX()方法返回true时,延迟到在下一帧率执行.返回false时立即执行.
    DefaultItemAnimator的动画都是在下一帧执行.

    列表动画的实现流程

    自定义立即执行的change动画:

    RecyclerViewItenAnimatordispatchLayoutStep1()recordPreLayoutInformation()dispatchLayoutStep3()recordPostLayoutInformation()animateChange()RecyclerViewItenAnimator

    默认延迟执行的add动画:

    RecyclerViewItenAnimatordispatchLayoutStep3()animateMove()animateAdd()postAnimationRunner()animateMoveImplanimateAddImplRecyclerViewItenAnimator

    收起阅读 »

    【开源库剖析】KOOM V1.0.5 源码解析

    一、官方项目介绍1.1 描述:KOOM是快手性能优化团队在处理移动端OOM问题的过程中沉淀出的一套完整解决方案。其中Android Java内存部分在LeakCanary的基础上进行了大量优化,解决了线上内存监控的性能问题,在不影响用户体验的前提下线上采集内存...
    继续阅读 »

    一、官方项目介绍

    1.1 描述:

    KOOM是快手性能优化团队在处理移动端OOM问题的过程中沉淀出的一套完整解决方案。其中Android Java内存部分在LeakCanary的基础上进行了大量优化,解决了线上内存监控的性能问题,在不影响用户体验的前提下线上采集内存镜像并解析。从 2020 年春节后在快手主APP上线至今解决了大量OOM问题,其性能和稳定性经受住了海量用户与设备的考验,因此决定开源以回馈社区。

    1.2 特点:

    • 比leakCanary更丰富的泄漏场景检测;
    • 比leakCanary更好的检测性能;
    • 功能全面的支持线上大规模部署的闭环监控系统;

    1.3 KOOM框架

    image.png

    1.4 快手KOOM核心流程包括:

    • 配置下发决策;
    • 监控内存状态;
    • 采集内存镜像;
    • 解析镜像文件(以下简称hprof)生成报告并上传;
    • 问题聚合报警与分配跟进。

    1.5 泄漏检测触发机制优化:

    泄漏检测触发机制leakCanary做法是GC过后对象WeakReference一直不被加入 ReferenceQueue,它可能存在内存泄漏。这个过程会主动触发GC做确认,可能会造成用户可感知的卡顿,而KOOM采用内存阈值监控来触发镜像采集,将对象是否泄漏的判断延迟到了解析时,阈值监控只要在子线程定期获取关注的几个内存指标即可,性能损耗很低。

    image.png

    1.6 heap dump优化:

    传统方案会冻结应用几秒,KOOM会fork新进程来执行dump操作,对父进程的正常执行没有影响。暂停虚拟机需要调用虚拟机的art::Dbg::SuspendVM函数,谷歌从Android 7.0开始对调用系统库做了限制,快手自研了kwai-linker组件,通过caller address替换和dl_iterate_phdr解析绕过了这一限制。

    image.png

    随机采集线上真实用户的内存镜像,普通dump和fork子进程dump阻塞用户使用的耗时如下:

    image.png

    而从官方给出的测试数据来看,效果似乎是非常好的。

    二、官方demo演示

    这里就直接跑下官方提供的koom-demo

    点击按钮,经过dump heap -> heap analysis -> report cache/koom/report/三个流程(heap analysis时间会比较长,但是完全不影响应用的正常操作),最终在应用的cache/koom/report里生成json报告:

    cepheus:/data/data/com.kwai.koom.demo/cache/koom/report # ls
    2020-12-08_15-23-32.json

    模拟一个最简单的单例CommonUtils持有LeakActivity实例的内存泄漏,看下json最终上报的内容是个啥:

    {
       "analysisDone":true,
       "classInfos":[
           {
               "className":"android.app.Activity",
               "instanceCount":4,
               "leakInstanceCount":3
           },
           {
               "className":"android.app.Fragment",
               "instanceCount":4,
               "leakInstanceCount":3
           },
           {
               "className":"android.graphics.Bitmap",
               "instanceCount":115,
               "leakInstanceCount":0
           },
           {
               "className":"libcore.util.NativeAllocationRegistry",
               "instanceCount":1513,
               "leakInstanceCount":0
           },
           {
               "className":"android.view.Window",
               "instanceCount":4,
               "leakInstanceCount":0
           }
       ],
       "gcPaths":[
           {
               "gcRoot":"Local variable in native code",
               "instanceCount":1,
               "leakReason":"Activity Leak",
               "path":[
                   {
                       "declaredClass":"java.lang.Thread",
                       "reference":"android.os.HandlerThread.contextClassLoader",
                       "referenceType":"INSTANCE_FIELD"
                   },
                   {
                       "declaredClass":"java.lang.ClassLoader",
                       "reference":"dalvik.system.PathClassLoader.runtimeInternalObjects",
                       "referenceType":"INSTANCE_FIELD"
                   },
                   {
                       "declaredClass":"",
                       "reference":"java.lang.Object[]",
                       "referenceType":"ARRAY_ENTRY"
                   },
                   {
                       "declaredClass":"com.kwai.koom.demo.CommonUtils",
                       "reference":"com.kwai.koom.demo.CommonUtils.context",
                       "referenceType":"STATIC_FIELD"
                   },
                   {
                       "reference":"com.kwai.koom.demo.LeakActivity",
                       "referenceType":"instance"
                   }
               ],
               "signature":"378fc01daea06b6bb679bd61725affd163d026a8"
           }
       ],
       "runningInfo":{
           "analysisReason":"RIGHT_NOW",
           "appVersion":"1.0",
           "buildModel":"MI 9 Transparent Edition",
           "currentPage":"LeakActivity",
           "dumpReason":"MANUAL_TRIGGER",
           "jvmMax":512,
           "jvmUsed":2,
           "koomVersion":1,
           "manufacture":"Xiaomi",
           "nowTime":"2020-12-08_16-07-34",
           "pss":32,
           "rss":123,
           "sdkInt":29,
           "threadCount":17,
           "usageSeconds":40,
           "vss":5674
       }
    }

    这里主要分三个部分:类信息、gc引用路径、运行基本信息。这里从gcPaths中能看出LeakActivity被CommonUtils持有了引用。

    框架使用这里参考官方接入文档即可,这里不赘述: github.com/KwaiAppTeam…

    三、框架解析

    3.1 类图

    image.png

    3.2 时序图

    KOOM初始化流程

    image.png

    KOOM执行初始化方法,10秒延迟之后会在threadHandler子线程中先通过check状态判断是否开始工作,工作内容是先检查是不是有未完成分析的文件,如果有就就触发解析,没有则监控内存。

    heap dump流程

    image.png

    HeapDumpTrigger

    • startTrack:监控自动触发dump hprof操作。开启内存监控,子线程5s触发一次检测,看当前是否满足触发heap dump的条件。条件是由一系列阀值组织,这部分后面详细分析。满足阀值后会通过监听回调给HeapDumpTrigger去执行trigger。
    • trigger:主动触发dump hprof操作。这里是fork子进程来处理的,这部分也到后面详细分析。dump完成之后通过监听回调触发HeapAnalysisTrigger.startTrack触发heap分析流程。

    heap analysis流程

    image.png

    HeapAnalysisTrigger

    • startTrack 根据策略触发hprof文件分析。
    • trigger 直接触发hprof文件分析。由单独起进程的service来处理,工作内容主要分内存泄漏检测(activity/fragment/bitmap/window)和泄漏数据整理缓存为json文件以供上报。

    四、核心源码解析

    经过前面的分析,基本上对框架的使用和结构有了一个宏观了解,这部分就打算对一些实现细节进行简单分析。

    4.1 内存监控触发dump规则

    这里主要是研究HeapMonitor中isTrigger规则,每隔5S都会循环判断该触发条件。

    com/kwai/koom/javaoom/monitor/HeapMonitor.java
    @Override
    public boolean isTrigger() {
      if (!started) {
       return false;
      }
      HeapStatus heapStatus = currentHeapStatus();
      if (heapStatus.isOverThreshold) {
       if (heapThreshold.ascending()) {
         if (lastHeapStatus == null || heapStatus.used >= lastHeapStatus.used) {
           currentTimes++;
         } else {
           currentTimes = 0;
         }
       } else {
         currentTimes++;
       }
      } else {
       currentTimes = 0;
      }
      lastHeapStatus = heapStatus;
      return currentTimes >= heapThreshold.overTimes();
    }
    private HeapStatus lastHeapStatus;
    private HeapStatus currentHeapStatus() {
      HeapStatus heapStatus = new HeapStatus();
      heapStatus.max = Runtime.getRuntime().maxMemory();
      heapStatus.used = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
      heapStatus.isOverThreshold = 100.0f * heapStatus.used / heapStatus.max > heapThreshold.value();
      return heapStatus;
    }

    com/kwai/koom/javaoom/common/KConstants.java

    public static class HeapThreshold {
      public static int VM_512_DEVICE = 510;
      public static int VM_256_DEVICE = 250;
      public static int VM_128_DEVICE = 128;
      public static float PERCENT_RATIO_IN_512_DEVICE = 80;
      public static float PERCENT_RATIO_IN_256_DEVICE = 85;
      public static float PERCENT_RATIO_IN_128_DEVICE = 90;

      public static float getDefaultPercentRation() {
       int maxMem = (int) (Runtime.getRuntime().maxMemory() / MB);
       if (maxMem >= VM_512_DEVICE) {
         return KConstants.HeapThreshold.PERCENT_RATIO_IN_512_DEVICE;
       } else if (maxMem >= VM_256_DEVICE) {
         return KConstants.HeapThreshold.PERCENT_RATIO_IN_256_DEVICE;
       } else if (maxMem >= VM_128_DEVICE) {
         return KConstants.HeapThreshold.PERCENT_RATIO_IN_128_DEVICE;
       }
       return KConstants.HeapThreshold.PERCENT_RATIO_IN_512_DEVICE;
      }

      public static int OVER_TIMES = 3;
      public static int POLL_INTERVAL = 5000;
    }

    这里就是针对不同内存大小做了不同的阀值比例:

    • 应用内存>512M 80%
    • 应用内存>256M 85%
    • 应用内存>128M 90%
    • 低于128M的默认按80%

    应用已使用内存/最大内存超过该比例则会触发heapStatus.isOverThreshold。连续满足3次触发heap dump,但是这个过程会考虑内存增长性,3次范围内出现了使用内存下降或者使用内存/最大内存低于对应阀值了则清零。

    因此规则总结为:3次满足>阀值条件且内存一直处于上升期才触发。这样能减少无效的dump。

    4.2 fork进程执行dump操作实现

    这里先对比下目前市面上三方框架的主流实现方案:

    image.png

    LeakCanaray、Matrix、Probe采用的方案:
    直接执行Debug.dumpHprofData(),它执行过程会先挂起当前进程的所有线程,然后执行dump操作,生成完成hprof文件之后再唤醒所有线程。整个过程非常耗时,会带来比较明显的卡顿,因此这个痛点严重影响该功能带到线上环境。

    KOOM采用的方案:
    主进程fork子进程来处理hprof dump操作,主进程本身只有在fork 子进程过程会短暂的suspend VM, 之后耗时阻塞均发生在子进程内,对主进程完全不产生影响。suspend VM本身过程时间非常短,从测试结果来看完全可以忽略不计

    接下来详细分析下fork dump方案的实现: 目前项目中默认使用ForkJvmHeapDumper来执行dump。

    com/kwai/koom/javaoom/dump/ForkJvmHeapDumper.java
    @Override
    public boolean dump(String path) {
      boolean dumpRes = false;
      try {
       int pid = trySuspendVMThenFork();//暂停虚拟机,copy-on-write fork子进程
       if (pid == 0) {//子进程中
         Debug.dumpHprofData(path);//dump hprof
         exitProcess();//_exit(0) 退出进程
       } else {//父进程中
         resumeVM();//resume当前虚拟机
         dumpRes = waitDumping(pid);//waitpid异步等待pid进程结束
       }
      } catch (Exception e) {
       e.printStackTrace();
      }
      return dumpRes;
    }

    为什么需要先suspendVM然后再fork?
    起初我理解主要是让fork前后的内存镜像保存一致性,但是对于内存泄漏来说这个造成的影响并不大,demo直接fork好像也没有什么问题,何况这块做了大量工作绕过Android N的限制去suspendVM肯定是有其必要性的。
    最终才发现,单线程是没问题的,因为线程已经停了,demo加多线程dump会卡在suspendVM。因此需要先suspendVM,再fork,最后resumeVM。

    好,确认工作流之后,来尝试实现:

    native层:

    这里fork、waitPid 、exitProcess都比较简单,直接忽略,重点看vm相关操作:

    正常操作就应该是:

    void *libHandle = dlopen("libart.so", RTLD_NOW);//打开libart.so, 拿到文件操作句柄
    void *suspendVM = dlsym(libHandle, LIBART_DBG_SUSPEND);//获取suspendVM方法引用
    void *resumeVM = dlsym(libHandle, LIBART_DBG_RESUME);//获取resumeVM方法引用
    dlclose(libHandle);//关闭libart.so文件操作句柄

    这在Android N以下的版本这么操作是OK了,但是谷歌从Android 7.0开始对调用系统库做了限制,基于此前提,快手自研了kwai-linker组件,通过caller address替换和dl_iterate_phdr解析绕过了这一限制,官方文档对限制说明,那么接下来就分析下KOOM是如何绕过此限制的。

    源码参考:Android 9.0

    /bionic/libdl/libdl.cpp
    02__attribute__((__weak__))
    103void* dlopen(const char* filename, int flag) {
    104 const void* caller_addr = __builtin_return_address(0);//得到当前函数返回地址
    105 return __loader_dlopen(filename, flag, caller_addr);
    106}

    /bionic/linker/dlfcn.cpp
    152void* __loader_dlopen(const char* filename, int flags, const void* caller_addr) {
    153 return dlopen_ext(filename, flags, nullptr, caller_addr);
    154}

    131static void* dlopen_ext(const char* filename,
    132 int flags,
    133 const android_dlextinfo* extinfo,
    134 const void* caller_addr) {
    135 ScopedPthreadMutexLocker locker(&g_dl_mutex);
    136 g_linker_logger.ResetState();
    137 void* result = do_dlopen(filename, flags, extinfo, caller_addr);//执行do_dlopen
    138 if (result == nullptr) {
    139 __bionic_format_dlerror("dlopen failed", linker_get_error_buffer());
    140 return nullptr;
    141 }
    142 return result;
    143}

    /bionic/linker/linker.cpp
    2049void* do_dlopen(const char* name, int flags,
    2050 const android_dlextinfo* extinfo,
    2051 const void* caller_addr) {
    2052 std::string trace_prefix = std::string("dlopen: ") + (name == nullptr ? "(nullptr)" : name);
    2053 ScopedTrace trace(trace_prefix.c_str());
    2054 ScopedTrace loading_trace((trace_prefix + " - loading and linking").c_str());
    2055 soinfo* const caller = find_containing_library(caller_addr);
    2056 android_namespace_t* ns = get_caller_namespace(caller);
    ...
    2141 return nullptr;
    2142}

    这里dlopen最终执行是通过__loader_dlopen,只不过默认会传入当前函数地址,这个地址其实就是做了caller address校验,如果检测出是三方地址则校验不通过,这里传入系统函数地址则能通过校验,例如dlerror。

    那么KOOM的做法是:

    大于N小于Q的Android版本

    using __loader_dlopen_fn = void *(*)(const char *filename, int flag, void *address);
    void *handle = ::dlopen("libdl.so", RTLD_NOW);//打开libel.so
    //这里直接调用其__loader_dlopen方法,它与dlopen区别是可以传入caller address
    auto __loader_dlopen = reinterpret_cast<__loader_dlopen_fn>(::dlsym(handle,"__loader_dlopen"));
    __loader_dlopen(lib_name, flags, (void *) dlerror);//传入dlerror系统函数地址,保证caller address校验通过,绕过Android N限制。

    Android Q及其以上的版本

    因为Q引入了runtime namespace,因此__loader_dlopen返回的handle为nullptr

    这里通过dl_iterate_phdr在当前进程中查询已加载的符合条件的动态库基对象地址。

    int DlFcn::dl_iterate_callback(dl_phdr_info *info, size_t size, void *data) {
    auto target = reinterpret_cast<dl_iterate_data *>(data);
    if (info->dlpi_addr != 0 && strstr(info->dlpi_name, target->info_.dlpi_name)) {
    target->info_.dlpi_addr = info->dlpi_addr;
    target->info_.dlpi_phdr = info->dlpi_phdr;
    target->info_.dlpi_phnum = info->dlpi_phnum;
    // break iterate
    return 1;
    }

    // continue iterate
    return 0;
    }

    dl_iterate_data data{};
    data.info_.dlpi_name = "libart.so";
    dl_iterate_phdr(dl_iterate_callback, &data);
    CHECKP(data.info_.dlpi_addr > 0)
    handle = __loader_dlopen(lib_name, flags, (void *) data.info_.dlpi_addr);

    这里dl_iterate_callback会回调当前进程所装载的每一个动态库,这里过滤出libart.so对应的地址:data.info_.dlpi_addr,再通过__loader_dlopen尝试打开libart.so。

    附:

    struct dl_phdr_info {
    ElfW(Addr) dlpi_addr;//基对象地址
    const ElfW(Phdr)* dlpi_phdr;//指针数组
    ElfW(Half) dlpi_phnum;//
    ...
    };

    这便是快手自研的kwai-linker组件通过caller address替换和dl_iterate_phdr解析绕过Android 7.0对调用系统库做的限制的具体实现。也是fork dump方案的核心技术点。

    4.3 内存泄漏检测实现

    内存泄漏检测核心代码在于SuspicionLeaksFinder.find

    public Pair<List<ApplicationLeak>, List<LibraryLeak>> find() {
      boolean indexed = buildIndex();
      if (!indexed) {
       return null;
      }
      initLeakDetectors();
      findLeaks();
      return findPath();
    }

    这里是针对Bitmap size做判断,超过768*1366这个size的认为泄漏。

    另外,NativeAllocationRegistryLeakDetector和WindowLeakDetector两类还没做具体泄漏判断规则,不参与对象泄漏检测,只是做了统计。

    总结: 整体看下来,KOOM有两个值得借鉴的点:

    • 1.触发内存泄漏检测,常规是watcher activity/fragment的onDestroy,而KOOM是定期轮询查看当前内存是否到达阀值;
    • 2.dump hprof,常规是对应进程dump,而KOOM是fork进程dump。

    收起阅读 »

    深入理解内存泄漏

    一、JVM内存模型常见jvm内存模型,主要分为堆区,本地方法栈,虚拟机栈,程序计数器,和方法区。如下图所示: (1)程序计数器每个线程都会有自己私有的程序计数器(PC)。可以看作是当前线程所执行的字节码的行号指示器。 也可以理解为下一条将要执行的指令...
    继续阅读 »

    一、JVM内存模型

    常见jvm内存模型,主要分为堆区,本地方法栈,虚拟机栈,程序计数器,和方法区。如下图所示: image.png

    (1)程序计数器

    每个线程都会有自己私有的程序计数器(PC)。可以看作是当前线程所执行的字节码的行号指示器。 也可以理解为下一条将要执行的指令的地址或者行号。字节码解释器就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,分支、 循环、 跳转、 异常处理、 线程上下文切换,线程恢复时,都要依赖PC.

    • 如果线程正在执行的是一个Java方法,PC值为正在执行的虚拟机字节码指令的地址
    • 如果线程正在执行的是Native方法,PC值为空(未定义)

    (2)虚拟机栈(VM Stack)

    简介

    VM Stack也是线程私有的区域。他是java方法执行时的字典:它里面记录了局部变量表、 操作数栈、 动态链接、 方法出口等信息。 **在《java虚拟机规范》一书中对这部分的描述如下:**栈帧( Frame)是用来存储数据和部分过程结果的数据结构,同时也被用来处理动态链接 (Dynamic Linking)、 方法返回值和异常分派( Dispatch Exception)。栈帧随着方法调用而创建,随着方法结束而销毁——无论方法是正常完成还是异常完成(抛出了在方法内未被捕获的异常)都算作方法结束。栈帧的存储空间分配在 Java 虚拟机栈( §2.5.5)之中,每一个栈帧都有自己的局部变量表( Local Variables, §2.6.1)、操作数栈( OperandStack, §2.6.2)和指向当前方法所属的类的运行时常量池( §2.5.5)的引用。 VM-Stack 说白了,VM Stack是一个栈,也是一块内存区域。 所以,他是有大小的。虽然有大小,但是一般而言,各种虚拟机的实现都支持动态扩展这部分内存。

    • 如果线程请求的栈深度太大,则抛出StackOverflowError
    • 如果动态扩展时没有足够的大小,则抛出OutOfMemoryError以下代码肯定会导致StackOverflowError:

    StackOverflowError

    public static void method() {
    method();
    }

    public static void main(String[] args) {
    method();
    }

    Exception in thread "main" java.lang.StackOverflowError
    at xxx.xxx.xxx.method(JavaVMStackSOF.java:10)
    复制代码

    (3)本地方法栈

    Java 虚拟机实现可能会使用到传统的栈(通常称之为“ C Stacks”)来支持 native 方法( 指使用 Java 以外的其他语言编写的方法)的执行,这个栈就是本地方法栈( Native MethodStack)。 VM Stack是为执行java方法服务的,此处的Native Method Stack是为执行本地方法服务的。 此处的本地方法指定是和具体的底层操作系统层面相关的接口调用了(这部分太高高级了,不想深究……)。 《java虚拟机规范》中没有对这部分做具体的规定。所以就由VM的实现者自由发挥了。 有的虚拟机(比如HotSpot)将VM Stack和Native Method Stack合二为一,所以VM的另一种内存区域图就如下面所示了: image.png

    (4)方法区

    方法区是由所有线程共享的内存区域。 方法区存储的大致内容如下:

    • 每一个类的结构信息
      • 运行时常量池( Runtime Constant Pool)
      • 字段和方法数据
      • 构造函数和普通方法的字节码内容
    • 类、实例、接口初始化时用到的特殊方法

    以下是本人对《java虚拟机规范》一书中对方法区的介绍的总结:

    • 在虚拟机启动的时候被创建
    • 虽然方法区是堆的逻辑组成部分,但是简单的虚拟机实现可以选择在这个区域不实现垃圾收集
    • 不限定实现方法区的内存位置和编译代码的管理策略
    • 容量可以是固定大小的,也可以随着程序执行的需求动态扩展,并在不需要过多空间时自动收缩。
    • 方法区在实际内存空间中可以是不连续的
    • Java 虚拟机实现应当提供给程序员或者最终用户调节方法区初始容量的手段
      • 对于可以动态扩展和收缩方法区来说,则应当提供调节其最大、最小容量的手段
    • 如果方法区的内存空间不能满足内存分配请求,那 Java 虚拟机将抛出一个OutOfMemoryError 异常

    (5)堆

    简介

    在 Java 虚拟机中,堆( Heap)是可供各条线程共享的运行时内存区域,也是供所有类实例和数组对象分配内存的区域。 以下是本人对《java虚拟机规范》一书中对Java堆的介绍的总结:

    • 在虚拟机启动的时候就被创建
    • 是所有线程共享的内存区域
    • 存储了被自动内存管理系统所管理的各种对象
    • Java 堆的容量可以是固定大小的,也可以随着程序执行的需求动态扩展,并在不需要过多空间时自动收缩
    • Java 堆所使用的内存不需要保证是连续的
    • 如果实际所需的堆超过了自动内存管理系统能提供的最大容量,那 Java 虚拟机将会抛出一个OutOfMemoryError 异常
    • 实现者应当提供给程序员或者最终用户调节 Java 堆初始容量的手段
    • 所有的对象实例以及数组都要在堆上分配
    • 至于堆内存的详细情况,将在后续的GC相关文章中介绍。

    堆内存中的OutOfMemoryError以下示例代码肯定导致堆内存溢出:

    public static void main(String[] args) {
       ArrayList<Integer> list = Lists.newArrayList();
       while (true) {
           list.add(1);
      }
    }
    复制代码

    无限制的往list中添加元素,无论你的堆内存分配的多大,都会有溢出的时候。

    java.lang.OutOfMemoryError: Java heap space
    复制代码

    二、内存优化工具

    (1)LeakCanary

    介绍

    leakCanary这是一个集成方便, 使用便捷,配置超级简单的框架,实现的功能却是极为强大的线下内存检测工具。 screenshot-2.0.png

    如何使用

    dependencies {
    // debugImplementation because LeakCanary should only run in debug builds.
    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.7'
    }
    复制代码

    在项目集成之后,在Android Studio Logcat日志通过筛选LeakCanary可以看到如下日志,标志LeakCanary已经安装成功,并且已经启动。 image.png

    内存泄漏

    我们经常会用到很多单例的工具类,往往这些单例也是经常容易发生内存泄漏的地方。下面我们模拟一下单例工具类造成内存泄漏的情况,封装一个ToastUtils的单例类,内部持有context的引用,这样在页面销毁之后依然持有context的引用,造成无法销毁,从而造成内存泄漏。

    object ToastUtils {
    private var context: Context? = null

    fun toast(context: Context, text: String) {
    this.context =context
    Toast.makeText(context, text, Toast.LENGTH_LONG)
    }
    }
    复制代码

    在控制台和手机上都可以看到内存泄漏的信息。如下所示: image.pngimage.png 手机上可以明显看到内存泄漏的列表,通过点击item即可看到详细的堆栈信息。

    ====================================
    1 APPLICATION LEAKS

    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.

    76243 bytes retained by leaking objects
    Signature: 409f986871fac1acf6527c76b4d658d03ffa8e11
    ┬───
    │ GC Root: Local variable in native code

    ├─ android.os.HandlerThread instance
    │ Leaking: NO (PathClassLoader↓ is not leaking)
    │ Thread name: 'LeakCanary-Heap-Dump'
    │ ↓ Thread.contextClassLoader
    ├─ dalvik.system.PathClassLoader instance
    │ Leaking: NO (ToastUtils↓ is not leaking and A ClassLoader is never leaking)
    │ ↓ ClassLoader.runtimeInternalObjects
    ├─ java.lang.Object[] array
    │ Leaking: NO (ToastUtils↓ is not leaking)
    │ ↓ Object[].[620]
    ├─ com.caichen.article_caichen.ToastUtils class
    Leaking: NO (a class is never leaking)
    │ ↓ static ToastUtils.context
    │ ~~~~~~~
    ╰→ com.caichen.article_caichen.LeakActivity instance
    Leaking: YES (ObjectWatcher was watching this because com.caichen.article_caichen.LeakActivity received
    Activity#onDestroy() callback and Activity#mDestroyed is true)
    Retaining 76.2 kB in 1135 objects
    key = 42b604fb-b746-48f5-8ff5-f56cd01a570e
    watchDurationMillis = 5204
    retainedDurationMillis = 190
    mApplication instance of android.app.Application
    mBase instance of androidx.appcompat.view.ContextThemeWrapper
    ====================================
    复制代码

    同时通过控制台也可以看到详细的信息。

    如何分析

        ├─ com.caichen.article_caichen.ToastUtils class
    Leaking: NO (a class is never leaking)
    │ ↓ static ToastUtils.context
    │ ~~~~~~~
    ╰→ com.caichen.article_caichen.LeakActivity instance
    复制代码

    通过堆栈信息,大致会得到内存泄漏的大致引用调用路径,最终定位到ToastUtils类中,存在内存泄漏的地方就是内部的context变量,因为被单例对象所持有那么他引用的context和单例的生命周期相同。所以当页面消失时,无法被垃圾回收器销毁从而造成内存泄漏。

    (2)Profile Memory

    介绍

    Profile Memory是 Android Profiler 中的一个组件,可帮助您识别可能会导致应用卡顿、冻结甚至崩溃的内存泄漏和内存抖动。它显示一个应用内存使用量的实时图表,让您可以捕获堆转储、强制执行垃圾回收以及跟踪内存分配。

    如何使用

    如需打开内存性能分析器,请按以下步骤操作:

    1. 依次点击 View > Tool Windows > Profiler(您也可以点击工具栏中的 Profile 图标 )。
    2. 从 Android Profiler 工具栏中选择要分析的设备和应用进程。如果您已通过 USB 连接设备但系统未列出该设备,请确保您已启用 USB 调试
    3. 点击 MEMORY 时间轴上的任意位置以打开内存性能分析器。

    如图所示: image.png 点击Memory选项可以进入内存性能分析器界面, image.png 右上角分别展示出jvm对应的内存的情况。 内存计数中的类别如下:

    • Total:内存占用的总和值
    • Java:从 Java 或 Kotlin 代码分配的对象的内存。
    • Native:从 C 或 C++ 代码分配的对象的内存。即使您的应用中不使用 C++,您也可能会看到此处使用了一些原生内存,因为即使您编写的代码采用 Java 或 Kotlin 语言,Android 框架仍使用原生内存代表您处理各种任务,如处理图像资源和其他图形。
    • Graphics:图形缓冲区队列为向屏幕显示像素(包括 GL 表面、GL 纹理等等)所使用的内存。(请注意,这是与 CPU 共享的内存,不是 GPU 专用内存。)
    • Stack:您的应用中的原生堆栈和 Java 堆栈使用的内存。这通常与您的应用运行多少线程有关。
    • Code:您的应用用于处理代码和资源(如 dex 字节码、经过优化或编译的 dex 代码、.so 库和字体)的内存。
    • Others:您的应用使用的系统不确定如何分类的内存。
    • Allocated:您的应用分配的 Java/Kotlin 对象数。此数字没有计入 C 或 C++ 中分配的对象。如果连接到搭载 Android 7.1 及更低版本的设备,只有在内存性能分析器连接到您运行的应用时,才开始此分配计数。因此,您开始分析之前分配的任何对象都不会被计入。但是,Android 8.0 及更高版本附带一个设备内置性能剖析工具,该工具可跟踪所有分配,因此,在 Android 8.0 及更高版本上,此数字始终表示您的应用中待处理的 Java 对象总数。

    内存抖动

    什么是内存抖动,内存抖动就是内存在短暂时间频繁的GC和分配内存,导致内存不稳定。体现在profile中就是内存曲线呈现锯齿状的形状。 image.png

    影响

    1. 频繁的创建对象造成内存碎片和不足
    2. 碎片的内存无法被分配从而容易导致内存溢出
    3. 频繁GC导致应用性能下降

    如何分析

    1. 通过点击Record然后可以记录出内存片的内存信息

    image.png

    1. 通过分析可以看出,string,char,int和StringBuilder都是占用内存比较多的对象
    2. 分析源码可以看出,在handleMessage中不断的进行创建intArray的对象,然后handlerMessage执行完毕之后创建的对象进行销毁,所以内存曲线呈现出来的形状呈锯齿状。
    3. 其中可以看出int占用的内存并没有string占有的内存大,那是因为通过log日志打印的字符串,通过StringBuilder进行了拼接,所以string和stringBuilder占用的内存比Int占用的内存还要大。
    private fun initHandler() {
    handler = Handler(Looper.getMainLooper(), Handler.Callback {
    for (index in 0..1000) {
    val asc = IntArray(100000) { 0 }
    Log.d("YI", "$asc")
    }
    handler?.sendEmptyMessageDelayed(0, 300)
    true
    })

    handler?.sendEmptyMessageDelayed(0, 300)
    }
    复制代码

    (3)Memory Analyzer

    介绍

    Eclipse Memory Analysis Tools (MAT) 是一个分析 Java堆数据的专业工具,用它可以定位内存泄漏的原因。

    如何使用

    1. 通过As导出的Heap文件不能直接使用需要通过SDK/platform-tools中的Hprof可执行文件将androidhea文件进行转化。
    2. 打开MAT程序,通过Open heap打开文件。

    image.pngimage.png

    如何分析

    1. 通过筛选类进行查看实例

    image.png

    1. 通过包名进行查看实例

    image.png 图中1处可可以指定分类的方式,图中2处可以找到自己包名下面的类,图中3处可以看到所有的包名下的实例和个数。可以看出图中LeakActivity的实例的个数11个,我们可以大致猜测出这个Activity是泄漏了。 接着我们查看Dominator Tree然后可以看出,罗列出leakActivity的所有的实例。 image.png 右键选中,然后点击Merge Shortest Paths to GC Roots可以看到引用路径。LeakActivity的引用呗Toastutils所持有。然后通过检查源码,可以看出内部context持有外部的引用,ToastUtils又是单例造成了activity的泄漏。 image.png


    收起阅读 »

    轻量级APP启动信息构建方案

    背景在头条的启动框架下,启动任务已经划分的较为明确,而启动时序是启动任务中的关键信息。目前我们获取这些信息的主要手段是看systrace,但直接读systrace存在一些问题:systrace在release下一些信息不全,例如IO线程信息,而启动优化的主要评...
    继续阅读 »

    背景

    在头条的启动框架下,启动任务已经划分的较为明确,而启动时序是启动任务中的关键信息。目前我们获取这些信息的主要手段是看systrace,但直接读systrace存在一些问题:

    • systrace在release下一些信息不全,例如IO线程信息,而启动优化的主要评估场景是release
    • systrace信息相对较重,可阅读性差,同时对启动任务的阅读的干扰性大

    在上述问题的影响下,会增加开发人员排查、验证启动任务问题,以及优化启动任务的难度。

    因此本文考虑设计一个轻量级的信息描述、收集与信息重建方案,灵活适应release模式与debug模式,同时增加可阅读性,降低开发人员排查问题的成本。

    1 方案设计

    轻量级启动信息构建方案主要由三部分组成:

    • 启动信息构建:负责提炼关键信息做成新数据结构
    • 启动信息收集:负责收集、输出各个任务的信息到重建模块
    • 启动信息重建:负责信息构建、输出可视化图形

    2 具体模块实现

    2.1 启动信息构建

    data class InitDataStruct(
    var startTime: Long = 0,
    var duration: Long = 0,
    var currentProcess: String = "",
    var taskName: String = ""
    )
    复制代码

    关键的启动信息主要有这么几个维度:

    • 启动时间(归一化)
    • 启动耗时
    • 启动线程
    • 启动名称

    而并不关心,即需要剔除掉的任务:

    • 非启动任务信息(这并不是说它不重要,只是在启动框架这一环它并不是高优)
    • 启动任务stack

    Format形如

    {"task_name":"class com.xxx.xxxTask","start_time":5,"duration":9,"current_process":"AA xxxThread#4"}
    复制代码

    2.2 启动信息收集

    由于没接入公司平台(太小),因此考虑就以log的方式输出结果。

    大概是希望实现下面的功能,但一个一个加就有点复制粘贴有点太low了

    调研了一下有一种AspectJ的做法,可以利用

    @PointCut("execution(* com.xxx.xxx.xxxTask.run(*))")

    在task周围埋下切入点

    利用@Before@After注入切入代码即可。

    2.3 启动信息收集与绘制

    由于目前是依赖人工进行启动分析,因此我们收集启动信息的手段依赖于Console打印的日志,形如

    {"task_name":"class com.xxx.Task","start_time":0,"duration":2,"current_process":"main"}
    复制代码

    这里我们直接写个读取工具给他转义一下,让他变成具有可读性的数据结构

    # 在Client中以json保存下来的
    def toInitInfo(json):
    return InitInfo(json["start_time"], json["duration"], json["current_process"], str(json["task_name"]).split('.')[-1])

    class InitInfo:
    #startTime和duration均做了归一化
    def __init__(self, startTime, duration, currentProcessName, taskName):
    self.startTime = startTime
    self.taskName = taskName
    self.duration = duration
    self.currentProcessName = currentProcessName

    def printitself(self):
    print("task_name : " + self.taskName)
    print("\tstartTime : " + str(self.startTime))
    print("\tduration : " + str(self.duration))
    print("\tcurrentProcessName : " + self.currentProcessName)

    # 获取task时长
    def getNameCombineDuration(self):
    return self.taskName + " " + str(self.duration)

    # 获取当前打印的最大长度
    def getConstructLen(self):
    return len(self.getNameCombineDuration()) + 2

    def generateFormatStr(self, perTime, perBlank):
    totalLen = max(3, int(1.0 * perBlank * max(1, self.duration) / perTime))
    cntLen = max(0, totalLen - self.getConstructLen())
    strr = "|" + (cntLen / 2 + cntLen % 2) * "-" + self.getNameCombineDuration()[0:min(totalLen - 2, len(self.getNameCombineDuration()))]+ cntLen / 2 * "-" + "|"
    return strr

    def generateBlank(self, timeNow, perTime, perBlank):
    strr = max(0, int((self.startTime - timeNow) / perTime) * perBlank) * " "
    return strr
    复制代码

    并将所有task插入到list中,以完成时间作为sort Function

    def sortByEnd(initInfo1, initInfo2):
    return (initInfo1.startTime + initInfo1.duration) <= (initInfo2.startTime + initInfo2.duration)

    def dealWithList():
    for item in line_jsons:
    if(taskMap.has_key(item.currentProcessName)):
    taskMap[item.currentProcessName].append(item)
    else:
    taskMap[item.currentProcessName] = []
    taskMap[item.currentProcessName].append(item)
    复制代码

    现在到了问题的核心,我们该采用什么规则把绘图绘制出来,这取决于我们需要得到的信息有哪些:

    • 第一种:分析启动任务耗时,可采用类似systrace,横轴为固定的单位时间长度,纵轴是currentProcess
    def drawMp():
    duraLen = 0
    maxLen = 0

    # 10ms间隔
    currentPerTime = 10
    endFile = open("timeline.txt","w")

    # 先保证起始坐标轴一致
    for key in taskMap.keys():
    maxLen = max(maxLen, len(key))

    # 计算最长字符串

    for item in line_jsons:
    duraLen = max(duraLen, item.getConstructLen())

    # 画个坐标轴
    xplot = maxLen * " " + " :"
    for index in range(0, (line_jsons[-1].startTime + line_jsons[-1].duration) / currentPerTime):
    cntLen = duraLen - 2 - len(str(index * currentPerTime))
    xplot += "|" + (cntLen / 2 + cntLen % 2) * "-" + str(index * currentPerTime) + cntLen / 2 * "-" + "|"

    endFile.write(xplot + "\n")

    # 画图
    for key in taskMap.keys():
    strr = key + (maxLen - len(key)) * " " + " :"
    timeNow = 0
    for item in taskMap[key]:
    item.printitself()
    strr += item.generateBlank(timeNow, perTime = currentPerTime, perBlank = duraLen)
    strr += item.generateFormatStr(10, duraLen)
    timeNow = item.startTime + item.duration

    strr += "\n"
    endFile.write(strr)

    endFile.close()
    复制代码
    • 第二种:分析启动任务排布的合理性,即是否存在长尾型的启动路径,这里考虑横轴为离散化后的启动任务时间,纵轴为currentProcess
    ## 第二种画图法:离散

    # 离散点阵图
    duraCordi = []

    def drawMp2():
    # 离散单位区间长度
    duraLen = 0

    def addBlank(st, ed):
    return (ed - st) * duraLen * " "

    def formatString(st, ed, taskName, duraLen):
    strr = "|"
    leftBlank = (ed - st) * duraLen - 2 - len(taskName)
    strr += (leftBlank / 2 + leftBlank % 2) * "-"
    strr += taskName
    strr += leftBlank / 2 * "-" + "|"
    return strr

    # 先离散
    # 最短是 -> |maxLen(xxxTask)|
    dura = []
    filee = open("timeline2.txt","w")
    for item in line_jsons:
    duraLen = max(duraLen, len(item.getNameCombineDuration()) + 2)
    dura.append(item.startTime)
    dura.append(item.startTime + item.duration)

    duraCordi = list(set(dura))
    duraCordi.sort()
    print(duraCordi)

    #再遍历塞值进去
    maxLen = 0
    for key in taskMap.keys():
    maxLen = max(maxLen, len(key))

    for key in taskMap.keys():
    currentIndex = 0
    strr = key + (maxLen - len(key)) * " " + " :"
    for item in taskMap[key]:
    stIndex = bisect.bisect_left(duraCordi, item.startTime)
    edIndex = bisect.bisect_left(duraCordi, item.startTime + max(item.duration, 1))
    strr += addBlank(currentIndex, stIndex)
    strr += formatString(stIndex, edIndex, item.getNameCombineDuration(), duraLen = duraLen)
    currentIndex = edIndex

    strr += "\n"
    filee.write(strr)

    filee.close()
    复制代码

    3 效果对比

    • 第一种启动耗时为单位的

    • 第二种启动时间离散化后的

    比如我们需要分析启动任务的排布是否合理,就可以看第二种图像,可以看到主线程启动任务较多,可能存在一定的长尾效应。

    相比systrace,更为轻量

    收起阅读 »

    JetpackMVVM七宗罪之二:在launchWhenX中启动协程

    首先承认这个系列有点标题党,Jetpack 的 MVVM 本身没有错,错在开发者的某些使用不当。本系列将分享那些 AAC 中常见的错误用法,帮助大家打造更健康的应用架构 Flow vs LiveData 自 StateFlow/ SharedFlow ...
    继续阅读 »




    首先承认这个系列有点标题党,Jetpack 的 MVVM 本身没有错,错在开发者的某些使用不当。本系列将分享那些 AAC 中常见的错误用法,帮助大家打造更健康的应用架构



    Flow vs LiveData


    自 StateFlow/ SharedFlow 出现后, 官方开始推荐在 MVVM 中使用 Flow 替换 LiveData。 ( 见文章:从 LiveData 迁移到 Kotlin 数据流 )


    Flow 基于协程实现,具有丰富的操作符,通过这些操作符可以实现线程切换、处理流式数据,相比 LiveData 功能更加强大。 但唯有一点不足,无法像 LiveData 那样感知生命周期。


    感知生命周期为 LiveData 至少带来以下两个好处:




    1. 避免泄漏:当 lifecycleOwner 进入 DESTROYED 时,会自动删除 Observer

    2. 节省资源:当 lifecycleOwner 进入 STARTED 时才开始接受数据,避免 UI 处于后台时的无效计算。



    Flow 也需要做到上面两点,才能真正地替代 LiveData。


    lifecycleScope


    lifecycle-runtime-ktx 库提供了 lifecycleOwner.lifecycleScope 扩展,可以在当前 Activity 或 Fragment 销毁时结束此协程,防止泄露。


    Flow 也是运行在协程中的,lifecycleScope 可以帮助 Flow 解决内存泄露的问题:


    lifecycleScope.launch {
    viewMode.stateFlow.collect {
    updateUI(it)
    }
    }

    虽然解决了内存泄漏问题, 但是 lifecycleScope.launch 会立即启动协程,之后一直运行直到协程销毁,无法像 LiveData 仅当 UI 处于前台才执行,对资源的浪费比较大。


    因此,lifecycle-runtime-ktx 又为我们提供了 LaunchWhenStartedLaunchWhenResumed ( 下文统称为 LaunchWhenX


    launchWhenX 的利与弊


    LaunchWhenX 会在 lifecycleOwner 进入 X 状态之前一直等待,又在离开 X 状态时挂起协程。 lifecycleScope + launchWhenX 的组合终于使 Flow 有了与 LiveData 相媲美的生命周期可感知能力:




    1. 避免泄露:当 lifecycleOwner 进入 DESTROYED 时, lifecycleScope 结束协程

    2. 节省资源:当 lifecycleOwner 进入 STARTED/RESUMED 时 launchWhenX 恢复执行,否则挂起。



    但对于 launchWhenX 来说, 当 lifecycleOwner 离开 X 状态时,协程只是挂起协程而非销毁,如果用这个协程来订阅 Flow,就意味着虽然 Flow 的收集暂停了,但是上游的处理仍在继续,资源浪费的问题解决地不够彻底。



    资源浪费


    举一个资源浪费的例子,加深理解


    fun FusedLocationProviderClient.locationFlow() = callbackFlow<Location> {
    val callback = object : LocationCallback() {
    override fun onLocationResult(result: LocationResult?) {
    result ?: return
    try { offer(result.lastLocation) } catch(e: Exception) {}
    }
    }
    // 持续获取最新地理位置
    requestLocationUpdates(
    createLocationRequest(), callback, Looper.getMainLooper())

    }

    如上,使用 callbackFlow 封装了一个 GoogleMap 中获取位置的服务,requestLocationUpdates 实时获取最新位置,并通过 Flow 返回


    class LocationActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    // 进入 STATED 时,collect 开始接收数据
    // 进入 STOPED 时,collect 挂起
    lifecycleScope.launchWhenStarted {
    locationProvider.locationFlow().collect {
    // Update the UI
    }
    }
    }
    }

    LocationActivity 进入 STOPED 时, lifecycleScope.launchWhenStarted 挂起,停止接受 Flow 的数据,UI 也随之停止更新。但是 callbackFlow 中的 requestLocationUpdates 仍然还在持续,造成资源的浪费。


    因此,即使在 launchWhenX 中订阅 Flow 仍然是不够的,无法完全避免资源的浪费


    解决办法:repeatOnLifecycle


    lifecycle-runtime-ktx 自 2.4.0-alpha01 起,提供了一个新的协程构造器 lifecyle.repeatOnLifecycle, 它在离开 X 状态时销毁协程,再进入 X 状态时再启动协程。从其命名上也可以直观地认识这一点,即围绕某生命周期的进出反复启动新协程



    使用 repeatOnLifecycle 可以弥补上述 launchWhenX 对协程仅挂起而不销毁的弊端。因此,正确订阅 Flow 的写法应该如下(以在 Fragment 中为例):


    onCreateView(...) {
    viewLifecycleOwner.lifecycleScope.launch {
    viewLifecycleOwner.lifecycle.repeatOnLifecycle(STARTED) {
    viewMode.stateFlow.collect { ... }
    }
    }
    }

    当 Fragment 处于 STARTED 状态时会开始收集数据,并且在 RESUMED 状态时保持收集,最终在 Fragment 进入 STOPPED 状态时结束收集过程。


    需要注意 repeatOnLifecycle 本身是个挂起函数,一旦被调用,将走不到后续代码,除非 lifecycle 进入 DESTROYED。


    冷流 or 热流


    顺道提一点,前面举得地图SDK的例子是个冷流的例子,对于热流(StateFlow/SharedFlow)是否有必要使用 repeatOnLifecycle 呢? 个人认为热流的使用场景中,像前面例子那样的情况会少一些,但是在 StateFlow/SharedFlow 的实现中,需要为每个 FlowCollector 分配一些资源,如果 FlowCollector 能即使销毁也是有利的,同时为了保持写法的统一,无论冷流热流都建议使用 repeatOnLifecycle


    最后:Flow.flowWithLifecycle


    当我们只有一个 Flow 需要收集时,可以使用 flowWithLifecycle 这样一个 Flow 操作符的形式来简化代码


    lifecycleScope.launch {
    viewMode.stateFlow
    .flowWithLifecycle(this, Lifecycle.State.STARTED)
    .collect { ... }
    }

    当然,其本质还是对 repeatOnLifecycle 的封装:


    public fun <T> Flow<T>.flowWithLifecycle(
    lifecycle: Lifecycle,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED
    )
    : Flow<T> = callbackFlow {
    lifecycle.repeatOnLifecycle(minActiveState) {
    this@flowWithLifecycle.collect {
    send(it)
    }
    }
    close()
    }


    收起阅读 »

    客户端网络优化(一)-原理篇

    0x01 前言 网络优化是客户端技术方向中公认的一个深度领域,对于 App 性能和用户体验至关重要。本文除了 DNS 、连接和带宽方面的优化技术外,会结合着优化的一些实践,以及在成本和收益的衡量,会有区别于市面上其他的分享,希望对大家有所帮助。 为什么优化...
    继续阅读 »

    0x01 前言


    网络优化是客户端技术方向中公认的一个深度领域,对于 App 性能和用户体验至关重要。本文除了 DNS 、连接和带宽方面的优化技术外,会结合着优化的一些实践,以及在成本和收益的衡量,会有区别于市面上其他的分享,希望对大家有所帮助。


    为什么优化


    肯定有同学会有疑问,网络请求不就是通过网络框架 SDK 去服务端请求数据吗,尤其在这个性能过剩的年代,时间都不会差多少,我们还有没有必要再去抠细节做优化了,废话不多说咱们直接看数据,来证明优化的价值



    • BBC 发现网站加载时间每延长 1 秒 用户便会流失 10%


    • Google 发现页面加载时间超过 353% 的用户将停止访问


    • Amazon 发现加载时间每延长 1 秒一年就会减少 16 亿美元的营收



    如何优化


    想知道如何优化,首先我们需要先确定优化方向:



    • 提高成功率

    • 减少请求耗时

    • 减少网络带宽


    接下来我们了解下 https 网络连接流程,如下图:


    connection.png


    从上图我们能清晰的看出 https 连接经历了以下几个流程:



    • DNS Query: 1 个 RTT

    • TCP 需要经历 SYNSYN/ACKACK 三次握手1.5个RTT,不过 ACKClientHello 合并了: 1 个 RTT

    • TLS 需要经过握手和密钥交换: 2 个 RTT

    • Application Data 数据传输


    综上所述,一个 https 连接需要 4 个 RTT 才到数据传输阶段,如果我们能减少建连的 RTT 次数,或者降低数据传输量,会对网络的稳定和速度带来很大的提升。


    0x02 DNS 优化



    • DNS & HttpDNS



    DNS(Domain Name System,域名系统),DNS 用于用户在网络请求时,根据域名查出 IP 地址,使用户更方便的访问互联网。传统DNS面临DNS缓存、解析转发、DNS攻击等问题,具体的DNS流程如下图所示:


    local_dns.png


    HttpDNS 优先通过 HTTP 协议与自建 DNS 服务器交互,如果有问题再降级到运营商的 LocalDNS 方案,既有效防止域名劫持,提高域名解析效率又保证了稳定可靠,HttpDNS 的原理如下图所示:


    httpdns.png


    HttpDNS优势



    • 稳定性:绕过运营商 LocalDNS,避免域名劫持,解决了由于 Local DNS 缓存导致的变更域名后无法即时生效的问题

    • 精准调度:避免 LocalDNS 调度不准确问题,自己做解析,返回最优服务端 IP 地址

    • 缩短解析延迟:通过域名预解析、缓存 DNS 解析结果等方式实现缩短域名解析延迟的效果


    综述


    先来看看主要的两点收益



    • 防止劫持,不过由于客户端大都已经全栈 HTTPS 了,HTTP 时代的中间人攻击已经基本没有了,但是还是有收益的。

    • 解析延迟带来的速度提升,目前全栈 HTTP/2 后,大都已经是长连接,数据统计单域名下通过 DNS Query 占比 5%+,DNS 解析平均耗时 80ms 左右,如果平摊到全量的网络请求 HttpDNS 会带来 1% 左右的提升


    上面的收益没有提到精准调度,是因为我们的 APP 流量主要在国内,国内节点相对丰富,服务整体质量也较高,即使出现调度不准确的情况,差值也不会太大,但如果在国外情况可能会差很多。


    0x03 连接优化


    长连接


    长连接指在一个连接上可以连续发送多个数据包,做到连接复用 我们知道从 HTTP/1.1 开始就支持了长连接,但是 HTTP/2 中引入了多路复用的技术。 大家可以通过 该链接 直观感受下 HTTP/2HTTP/1.1 到底快了多少。


    http1_2.png


    这是 Akamai 公司建立的一个官方的演示,用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。同时请求 379 张图片,从加载时间 的对比可以看出HTTP/2在速度上的优势。


    HTTP/2的多路复用技术代替了原来的序列和阻塞机制。 HTTP/1.x 中,如果想并发多个请求,必须使用多个 TCP 链接,且浏览器为了控制资源,还会对单个域名有连接数量限制,有了二进制分帧之后,HTTP/2不再依赖 TCP 链接去实现多流并行了,所有请求都是通过一个 TCP 连接并发送完成,利用请求优先级解决关键请求阻塞问题,使得重要的请求优先得到响应。这样更容易实现全速传输,减少 TCP 慢启动时间,提高传输的速度。传输流程如下图:


    multiplexing.png


    说了这么多优点,那多路复用有缺点么,主要是受限TCP的限制,一般来说同一域名下只需要使用一个 TCP 连接。但当连接中出现频繁丢包情况,就会有队头阻塞问题,所有的包都会等待丢包重传成功后传输,这样HTTP/2的表现情况反倒不如 HTTP/1.1了,HTTP/1.1还可以通过多个 TCP 连接并行传输数据。


    域名合并


    随着开发规模逐渐扩大,各业务团队出于独立性和稳定性的考虑,纷纷申请了自己的接口域名,域名会越来越多。我们知道 HTTP 属于应用层协议,在传输层使用 TCP 协议,在网络层使用IP协议,所以 HTTP 的长连接本质上是 TCP 长连接,是对一个域名( IP )来说的,如果域名过多面临下面几个问题:



    • 长连接的复用效率降低

    • 每个域名都需要经过 DNS 服务来解析服务器 IP。

    • HTTP 请求需要跟不同服务器同时保持长连接,增加了客户端和服务端的资源消耗。


    具体方案如下图所示


    domain_merge.png


    TLS-v1.2 会话恢复


    会话恢复主要是通过减少 TLS 密钥协商交换的过程,在第二次建连时提高连接效率 2-RTT -> 1-RTT 。具体是如何实现的呢?包含两种方式,一种是 Sesssion ID,一种是 Session Ticket。下面讲解了 Session Ticket 的原理:


    img



    • Session ID

      Session ID 类似我们熟知的 Session 的概念。 由服务器端支持,协议中的标准字段,因此基本所有服务器都支持,客户端只缓存会话 ID,服务器端保存会话 ID 以及协商的通信信息,占用服务器资源较多。


    • Session Ticket

      Session ID 存在一些弊端,比如分布式系统中的 Session Cache 同步问题,如果不能同步则大大限制了会话复用效率,但 Session Ticket 没问题。Session Ticket 更像我们熟知的 Cookie 的概念,Session Ticket 用只有服务端知道的安全密钥加密过的会话信息,保存在客户端上。客户端在 ClientHello 时带上了 Session Ticket,服务器如果能成功解密就可以完成快速握手。



    不管是 Session ID 还是 Session Ticket 都存在时效性问题,不是永久有效的。


    TLS-v1.3


    首先需要明确的是,同等情况下,TLS/1.3TLS/1.2 少一个 RTT 时间。并且废除了一些不安全的算法,提升了安全性。首次握手,TLS/1.2完成 TLS 密钥协商需要 2 个 RTT 时间,TLS/1.3只需要 1 个 RTT 时间。会话恢复 TLS/1.2 需要 1 个 RTT 时间,TLS/1.3 则因为在第一个包中携带数据(early data),只需要 0 个 RTT,有点类似 TLS 层的 TCP Fast Open



    • 首次握手流程

      img


    • 会话恢复-0RTT

      TLS/1.3 中更改了会话恢复机制,废除了原有的 Session IDSession Ticket 的方式,使用 PSK 的机制,并支持了 0RTT模式下的恢复模式(实现 0-RTT 的条件比较苛刻,目前不少浏览器虽然支持 TLS/1.3 协议,但是还不支持发送 early data,所以它们也没法启用 0-RTT 模式的会话恢复)。当 client 和 server 共享一个 PSK(从外部获得或通过一个以前的握手获得)时,TLS/1.3 允许 client 在第一个发送出去的消息中携带数据("early data")。Client 使用这个 PSK 生成 client_early_traffic_secret 并用它加密 early data。Server 收到这个 ClientHello 之后,用 ClientHello 扩展中的 PSK 导出 client_early_traffic_secret 并用它解密 early data0-RTT 会话恢复模式如下:

      img



    HTTP/3


    QUIC 首次在2013年被提出,互联网工程任务组在 2018 年的时候将基于 QUIC 协议的 HTTP (HTTP over QUIC) 重命名为 HTTP/3。不过目前 HTTP/3 还没有最终定稿,最新我看已经到了第 34 版,应该很快就会发布正式版本。某些意义上说 HTTP/3 协议实际上就是IETF QUICQUICQuick UDP Internet Connections,快速 UDP 网络连接) 基于 UDP,利用 UDP 的速度与效率。同时 QUIC 也整合了 TCPTLSHTTP/2 的优点,并加以优化。用一张图可以清晰地表示他们之间的关系。


    HTTP/3主要带来了零 RTT 建立连接、连接迁移、队头阻塞/多路复用等诸多优势,具体细节暂不介绍了。推出HTTP/3(QUIC)的原理与实践,敬请期待。


    0x04 带宽优化


    HTTP/2 头部压缩


    HTTP1.xheader 中的字段很多时候都是重复的,例如 method:getscheme:https 等。随着请求增长,这些请求中的冗余标头字段不必要地消耗带宽,从而显著增加了延迟,因此,HTTP/2 头部压缩技术应时而生,使用的压缩算法为 HPACK。借用 Google 的性能专家 Ilya Grigorik 在 Velocity 2015 ? SC 会议中分享的一张图,让我们了解下头部压缩的原理:


    head_compress1.png


    上述图主要涉及两个点



    • 静态表中定义了61个 header 字段与 Index,可以通过传输 Index 进而获取 header,极大减少了报文大小。静态表中的字段和值固定,而且是只读的。详见静态表

    • 动态表接在静态表之后,结构与静态表相同,以先进先出的顺序维护的 header 字段列表,可随时更新。同一个连接上产生的请求和响应越多,动态字典积累得越全,头部压缩效果也就越好。所以尽量上面提到的域名合并,不仅提升连接性能也能提高带宽优化效果


    简单描述一下 HPACK 算法的过程:



    • 发送方和接受方共同维护一份静态表和动态表

    • 发送方根据字典表的内容,编码压缩消息头部

    • 接收方根据字典表进行解码,并且根据指令来判断是否需要更新动态表


    看完了 HTTP/2 头部压缩的介绍,那在没有头部压缩技术的 HTTP/1 时代,当处理一些通用参数时,我们当时只能把参数压缩后放入 body 传输,因为 header 只支持 ascii 码,压缩导致乱码,如果放入 header 还得 encode 或者 base64 编码,不仅增大了体积还要浪费解码的性能。


    数据表明通用参数通过 HTTP/2header 传输,由于长连通道大概在 90%+ 复用比例,压缩率可以达到惊人的 90%,同样比压缩后放在 body 中减少约 50% 的 size,如果遇到一些无规则的文本数据,zip 压缩率也会随着变低,这时候提升将会更明显。说了这么多,最后让我们通过抓包看下,HTTP/2 头部压缩的效果吧:


    head_compress2.png


    Json vs Protobuffer


    Protobuffer 是 Google 出品的一种轻量 & 高效的结构化数据存储格式,性能比 Json 好,Size 比 Json 要小



    • Protobuffer 数据格式

      因为咱们这里说的是带宽,所以咱们详细说下 size 这块的优化,相比 json 来说,Protobuffer 节省了字段名字和分隔符,具体格式如下:

      // tag: 字段标识号,不可重复
      // type: 字段类型
      // length: 字段长度,当data可以用Varint表示的时候不需要 (可选)
      // data: 字段数据

      <tag> <type> [<length>] <data>

    • Protobuffer 数据编码方式

      Protobuffer 的数据格式不可避免的存在定长数据和变长数据的表示问题,编码方式用到了 Varint & Zigzag。 这里主要介绍下 Varint,因为 Zigzag 主要是对于负数时的一个补充( VarInt 不太适合表示负数,有兴趣的同学可以自行查下资料 ) ,Varint 其实是一种变长的编码方式,用字节表示数字,征用了每个字节的最高位 (MSB), MSB 是 1 话,则表示还有后序字节,一直到 MSB 为 0 的字节为止,具体表示如下表:

         0 ~ 2^07 - 1 0xxxxxxx
      2^07 ~ 2^14 - 2 1xxxxxxx 0xxxxxxx
      2^14 ~ 2^21 - 3 1xxxxxxx 1xxxxxxx 0xxxxxxx
      2^21 ~ 2^28 - 4 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx

      不难看出值越小的数字,使用越少的字节数表示。如对于 int32 类型的数字,一般需要 4 个字节 表示,但是用了 Varint 小于 128 一个字节就够了,但是对于大的 int32 数字(大于2^28)会需要 5 个 字节 来表示,但大多数情况下,数据中不会有很大的数字,所以采用 Varint 方法总是可以用更少的字节数来表示数字


    • 具体示例

      首先定义一个实体类

      // bean
      class Person {
      int age = 1;
      }

      Json 的序列化结果

      // json
      {
      "age":1
      }

      Protobuffer 的序列化结果

      // Protobuffer
      00001000 00000001

      简单说下 Protobuffer 的序列化逻辑吧,Personage 字段取值为 1 的话,类型为 int32 则对应的编码是:0x08 0x01age 的类型是 int32,对应的 type 取 0。而它的 tag 又是 1,所以第一个字节是 (1 << 3) | 0 = 0x08,第二个字节是数字 1 的 VarInt 编码,即 0x01

      // bean
      class Person {
      int age = 1;
      }

      // Protobuffer 描述文件
      message Person {
      int32 age = 1;
      }

      // protobuf值
      +-----+---+--------+
      |00001|000|00000001|
      +-----+---+--------+
      tag type data

    • 优化数据

      原始数据 Size ProtobufferJson 小 30%左右,压缩后 Size 差距 10%+



    0x05 总结


    上面说了这么多技术的原理,接下来分享下我们的技术选型以及思考,希望能给大家带来帮助



    • HttpDNS

      我们的应用主要在国内使用,这个功能只对首次建连有提升,目前首次建连的比例较小,也就在5%左右,所以对性能提升较小;安全问题再全栈切了 https 后也没有那么突出;并且 HttpDNS 也会遇到一些技术难点,比如自建 DNS 需要维护一套聪明的服务端IP调度策略;客户端需要注意 IP 缓存 以及 IPV4 IPV6 的双栈探测和选取策略等,综合考虑下目前我们没有使用HttpDNS


    • 长连接&域名合并

      长连接和域名合并,这两个放在一起说下吧,因为他们是相辅相成的,域名合并后,不同业务线使用一个长连接通道,减少了TCP 慢启动时间,更容易实现全速传输,优势还是很明显的。

      长连接方案还是有很多的,涉及到 HTTP/1.1HTTP/2HTTP/3、自建长链等方式,最终我们选择了HTTP/2,并不是因为这个方案性能最优,而是综合来看这个方案最有优势,HTTP/1.1 就不用说了,这个方案早就淘汰了,而 HTTP/3 虽然性能好,但是目前阶段并没有完整稳定的前后端框架,所以只适合尝鲜,是我们接下来的一个目标,自建长链虽然能结合业务定制逻辑,达到最优的性能,但是比较复杂,也正是由于特殊的定制导致没办法方便的切换官方的协议(如HTTP/3


    • TLS 协议

      TLS 协议我们积极跟进了官方最新稳定版 TLS/1.3 版本的升级,客户端在 Android 10iOS 12.2 后已经开始默认支持 TLS/1.3,想在低系统版本上支持需要接入三方扩展库,由于支持的系统版本占比已经很高,后面也会越来越高,并且 TLS 协议是兼容式的升级,允许客户端同时存在TLS/1.2TLS/1.3两个版本,综合考虑下我们的升级策略就是只升级服务端

      TLS 协议升级主要带来两个方面的提升,性能和安全。先来说下性能的提升,TLS/1.3 对比TLS/1.2版本来说,性能的提升体现在减少握手时的一次 RTT 时间,由于连接复用率很高,所以性能的提升和 HttpDNS 一样效果很小。至于安全前面也有提到,废弃了一些相对不安全的算法,提升了安全性


    • 带宽优化

      带宽优化对于网络传输的速度和用户的流量消耗都是有帮助的,所以我们要尽量减少数据的传输,那么在框架层来说主要的策略有两种:

      一是减少相同数据的传输次数,也就是对应着 HTTP/2 的头部压缩,原理上面也有介绍,这里就不在赘述了,对于目前长连接的通道,header 中不变化的数据只传输一个标识即可,这个的效果还是很明显的,所以框架可以考虑一些通用并且不长变化的参数放在 Header 中传输,但是此处需要注意并不是所有的参数都适合在 Header 中,因为 Header 中的数据只支持 ASCII 编码,所以有一些敏感数据放在此处会容易被破解,如果加密后在放进来,还需要在进行 Base64 编码处理,这样可能会加大很多传输的 size,所以框架侧要进行取舍 (PS:在补充个 Header 字段的小坑:HTTP/2 Header都会转成小写,而 HTTP/1.x 大小写均可,在升级 HTTP/2 协议的时候需要注意下)

      二是减少传输 size,常规的做法如切换更省空间的数据格式 Protobuffer,因为关联到数据格式的变动,需要前后端一起调整,所以改造历史业务成本会比较高有阻力,比较适合在新的业务上尝鲜,总结出一套最佳实践后,再去尝试慢慢改造旧的业务


    收起阅读 »

    SpringBoot实战基于异常日志的邮件报警

    SpringBoot实战基于异常日志的邮件报警 相信所有奋斗在一线的小伙伴,会很关心自己的系统的运行情况,一般来说,基础设施齐全一点的公司都会有完善的报警方案,那么如果我们是一个小公司呢,不能因为基础设施没有,就失去对象的感知能力吧;如果我们的系统大量异...
    继续阅读 »





    SpringBoot实战基于异常日志的邮件报警



    相信所有奋斗在一线的小伙伴,会很关心自己的系统的运行情况,一般来说,基础设施齐全一点的公司都会有完善的报警方案,那么如果我们是一个小公司呢,不能因为基础设施没有,就失去对象的感知能力吧;如果我们的系统大量异常却不能实时的触达给我们,那么也就只会有一个结果--杀个程序猿祭天


    本文简单的介绍一种实现思路,基于error日志来实现邮件的报警方案


    I. 项目环境


    1. 项目依赖


    本项目借助SpringBoot 2.2.1.RELEASE + maven 3.5.3 + IDEA进行开发


    开一个web服务用于测试


    <dependencies>
    <!-- 邮件发送的核心依赖 -->
    <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-mail</artifactId>
    </dependency>
    </dependencies>

    2. 配置


    邮件相关配置如下,注意使用自己的用户名 + 授权码填充下面缺失的配置


    spring:
    #邮箱配置
    mail:
    host: smtp.163.com
    from: xhhuiblog@163.com
    # 使用自己的发送方用户名 + 授权码填充
    username:
    password:
    default-encoding: UTF-8
    properties:
    mail:
    smtp:
    auth: true
    starttls:
    enable: true
    required: true

    II. 异常日志的邮件预警


    1. 设计思路


    接下来这个方案的主要出发点在于,当程序出现大量的异常,表明应用多半出现了问题,需要立马发送给项目owner


    要实现这个方案,关键点就在于异常出现的感知与上报



    • 异常的捕获,并输出日志(这个感觉属于标配了吧,别告诉我现在还有应用不输出日志文件的...)

      • 对于这个感知,借助logback的扩展机制,可以实现,后面介绍


    • 异常上报:邮件发送


    关于email的使用姿势,推荐参考博文 SpringBoot 系列之邮件发送姿势介绍


    2. 自定义appender


    定义一个用于错误发送的Appender,如下


    public class MailUtil extends AppenderBase<ILoggingEvent> {

    public static void sendMail(String title, String context) {
    SimpleMailMessage simpleMailMessage = new SimpleMailMessage();
    //邮件发送人
    simpleMailMessage.setFrom(ContextUtil.getEnvironment().getProperty("spring.mail.from", "bangzewu@126.com"));
    //邮件接收人,可以是多个
    simpleMailMessage.setTo("bangzewu@126.com");
    //邮件主题
    simpleMailMessage.setSubject(title);
    //邮件内容
    simpleMailMessage.setText(context);

    JavaMailSender javaMailSender = ContextUtil.getApplicationContext().getBean(JavaMailSender.class);
    javaMailSender.send(simpleMailMessage);
    }

    private static final long INTERVAL = 10 * 1000 * 60;
    private long lastAlarmTime = 0;

    @Override
    protected void append(ILoggingEvent iLoggingEvent) {
    if (canAlarm()) {
    sendMail(iLoggingEvent.getLoggerName(), iLoggingEvent.getFormattedMessage());
    }
    }

    private boolean canAlarm() {
    // 做一个简单的频率过滤
    long now = System.currentTimeMillis();
    if (now - lastAlarmTime >= INTERVAL) {
    lastAlarmTime = now;
    return true;
    } else {
    return false;
    }
    }
    }

    3. Spring容器


    上面的邮件发送中,需要使用JavaMailSender,写一个简单的SpringContext工具类,用于获取Bean/Propertiy


    @Component
    public class ContextUtil implements ApplicationContextAware, EnvironmentAware {

    private static ApplicationContext applicationContext;

    private static Environment environment;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    ContextUtil.applicationContext = applicationContext;
    }

    @Override
    public void setEnvironment(Environment environment) {
    ContextUtil.environment = environment;
    }

    public static ApplicationContext getApplicationContext() {
    return applicationContext;
    }

    public static Environment getEnvironment() {
    return environment;
    }
    }

    4. logback配置


    接下来就是在日志配置中,使用我们上面定义的Appender


    logback-spring.xml文件内容如下:


    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
    <pattern>%d [%t] %-5level %logger{36}.%M\(%file:%line\) - %msg%n</pattern>
    <!-- 控制台也要使用UTF-8,不要使用GBK,否则会中文乱码 -->
    <charset>UTF-8</charset>
    </encoder>
    </appender>

    <appender name="errorAlarm" class="com.git.hui.demo.mail.util.MailUtil">
    <!--如果只是想要 Error 级别的日志,那么需要过滤一下,默认是 info 级别的,ThresholdFilter-->
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    <level>ERROR</level>
    </filter>
    </appender>


    <!-- 指定项目中某个包,当有日志操作行为时的日志记录级别 -->
    <!-- 级别依次为【从高到低】:FATAL > ERROR > WARN > INFO > DEBUG > TRACE -->
    <!-- additivity=false 表示匹配之后,不再继续传递给其他的logger-->
    <logger name="com.git.hui" level="DEBUG" additivity="false">
    <appender-ref ref="STDOUT"/>
    <appender-ref ref="errorAlarm"/>
    </logger>

    <!-- 控制台输出日志级别 -->
    <root level="INFO">
    <appender-ref ref="STDOUT"/>
    </root>
    </configuration>

    5. 测试demo


    接下来演示一下,是否可以达到我们的预期


    @Slf4j
    @RestController
    @SpringBootApplication
    public class Application {

    public static void main(String[] args) {
    SpringApplication.run(Application.class);
    }

    @GetMapping("div")
    public String div(int a, int b) {
    try {
    return String.valueOf(a / b);
    } catch (Exception e) {
    log.error("div error! {}/{}", a, b, e);
    return "some error!";
    }
    }
    }


    5.小结


    本篇博文主要提供了一个思路,借助logback的扩展机制,来实现错误日志与预警邮件绑定,实现一个简单的应用异常监控


    上面这个实现只算是一个雏形,算是抛砖引玉,有更多可以丰富的细节,比如



    • 飞书/钉钉通知(借助飞书钉钉的机器来报警,相比较于邮件感知性更高)

    • 根据异常类型,做预警的区分

    • 更高级的频率限制等


    在这里推荐一个我之前开源的预警系统,可以实现灵活预警方案配置,频率限制,重要性升级等



    III. 不能错过的源码和相关知识点


    0. 项目


    收起阅读 »