自从更新ios11.2之后任务栏下拉之后小白条上滑就会有咔咔的异常声音伴随震感_iphonex吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：220,813贴子：
自从更新ios11.2之后任务栏下拉收藏
自从更新ios11.2之后任务栏下拉之后小白条上滑就会有咔咔的异常声音伴随震感。直到今天更新ios11.2.1尚未修正
苏宁易购苹果,品牌授权,正品行货保证,买正品,就上苏宁易购网上商城!苏宁易购苹果,全国联保,货到付款!
楼主我也是
这应该不是BUG. 是这样的
点亮12星座印记,
这是系统震动反馈
一样 这个问题一直让我头疼
我也是，垃圾的11.2
登录百度帐号iOS11 & iPhoneX 适配总结-ZAKER新闻
CocoaChina
一、前言iOS11 发布也有一段时间了，每次版本升级，相关的适配工作当然是下个版本的核心工作之一。而且这次 iOS11 的更新，相对于 iOS10 的更新来说，改动点还是比较多的。除了 iOS11 系统的更新之外，iPhoneX 刘海的打理工作也是必不可少。以前我们总是庆幸作为 iOS 开发者，不必像 Android 开发者需要考虑各种不同机型的适配问题。但是现在，随着 iPhone 各种历史版本的存在，各种花式的新版本产生，不同版本之间的适配问题，也是未来我们作为 iOS 开发者必然要考虑的重要问题之一。这次我主要负责我们这边两款 App ( 滴滴代驾司机端 + 驾管 App ) iOS11&iPhoneX 适配工作。中间也躺过很多坑，一一记录了下来写成这篇文章，既是对自己工作的一次总结，也可以分享给其他 iOS 开发者，能够让大家少趟一些坑。本文将分为三个部分，分别从三方库适配、UI 适配、权限适配、补充知识等方面分别进行展开。二、三方库适配问题。2.1 CocoaLumberjack 编译出错CocoaLumberjack 编译报错问题原因：从错误提示可以看出在 Xcode9 中 os_log_error 的第二个参数 format 必须要为不可变的 string 类型，而不是 char*。解决方案：我们只要改成如下形式就可以了os_log_error ( OS_LOG_DEFAULT,
msg ) ;CocoaLumberjack 的作者也在 [ issue883 ] (
) 中解决了该问题。如果你的工程是 pod 依赖的话，将 pod 版本升级到 3.3.0 版本即可。2.2 WebViewJavascriptBridge 崩溃处理我们代驾司机端 web 容器使用的是 WKWebView，jsBridge 使用的是 WebViewJavascriptBridge 这个三方库，更新到 Xcode9 之后，只要进入 WKWebView 容器，就会产生如下 crash:WebViewJavascriptBridge crash当你使用 WKWebView 作为你的 H5 容器的时候，WKNavigationDelegate 有个回调就是-
( void ) webView: ( WKWebView
* ) webView
decidePolicyForNavigationAction: ( WKNavigationAction
* ) navigationAction
decisionHandler: ( void
( ^ ) ( WKNavigationActionPolicy ) ) decisionH这个回调主要负责根据 webView、navigationAction 相关信息决定这次跳转是否可以继续进行。调用 decisionHandler ( WKNavigationActionPolicyAllow ) ; 响应这次跳转请求。调用 decisionHandler ( WKNavigationActionPolicyCancel ) ; 就是不响应这次跳转请求。查看 WebViewJavascriptBridge 源码可以看出，在 WKWebViewJavascriptBridge.m 文件中WKVebViewCrash.png在 Xcode9 中，如果连续看了两次调用 decisionHandler 方法就会 crash。这个问题在之前版本的 Xcode 均是没有问题的。方案一：修改源码在上面代码的 149 行和 150 行之间添加方案二：pod 依赖，原作者没有修改此问题，无法修改源码，也可以在业务代码中进行规避。在你自己业务代码的对应对调中添加排除代码，如下：WKWebViewCrash2.png2.3 LumberjackConsole UI 适配问题原因 :iOS7 之后，如何你设置 self.edgesForExtendedLayout = UIRectEdgeNone 的话 , 系统通过设置 UIViewController 的 automaticallyAdjustsScrollViewInsets 属性来自动调整 UIScrollView 的 contentInset，使 UIscrollView 能够呈现在我们的可是范围之内，而不会被 navBar 挡住。这个属性在 iOS11 中被废弃掉了，在 iOS11 中代替该属性功能的则是 UIScrollView 类中的 contentInsetAdjustmentBehavior 和 adjustedContentInset 属性 . 在 iOS11 中用来决定 scrollView 超出安全区域与边缘距离的属性是 adjustedContentInset 而不是 contentInset。当 scrollView 超出安全区域时系统会自动调整 SafeAreaInsets 值，进而影响 adjustedContentInset，所以导致 scrollView 下移 20pt 或者 64pt。当使用自定义的 navigationbar，并且 scrollView 的 frame 超出安全区域，SafeAreaInsets 为 ( 20,0,0,0 ) ; 当使用系统的 navigationbar，SafeAreaInsets 为 ( 64,0,0,0 ) 。解决方案 :在 UIScrollView 或者 UITableView 初始化的地方，加入如下代码即可。针对 LumberjackConsole 这个开源库，我们可以在 PTEConsoleTableView.m 文件中的 commonInit 最后加入如下代码即可。if ( [ self
respondsToSelector:@selector ( setContentInsetAdjustmentBehavior: ) ] ) {
setContentInsetAdjustmentBehavior:UIScrollViewContentInsetAdjustmentNever ] ;}三、UI 适配3.1 NavBar 中右上角的 customView 产生偏移在 iOS11 中，新的导航视图，使用了 AutoLayout 布局。而我们这边右上角的两个按钮组合成一个 customView，然后把这个 customView 设置给 setRightBarButtonItems 而来。customView 内部都是 frame 布局，所以在自动布局下面出错。解决方案 :NavBar 中的 customView 里面针对 iOS11，均要采用自动布局。3.2 NavBar 中自定义 TitleView 产生偏移同上这里需要注意一点，自动布局的 UI 是延迟设置 frame 的。如果 aView 采用自动布局。然后你马上调用它的 aView.bounds 是不正确的。3.3 NavBar 中按钮的响应区域都变小了。iOS11 之前，虽然我们设置了 NavBar 上每一个 [ btn sizeToFit ] 。苹果依然会帮我们把每一个按钮的点击区域扩大，可以点击区域如上图绿色区域所示。但是在 iOS11 中，你的按钮的 bounds 为多大，那你的点击区域就只有多大。估计这个改动也与这次 NavBar 的大概有关系。扩大每一个 btn 的 bounds，而不要使用 sizeToFit 方法。3.4 NavBar 的 BarButtonItem 无法贴边。有（非 plus 手机 16pt，plus 手机 20pt）的区域浪费。造成 UI 偏移，并且最左侧和最右侧区域无法点击。这个 UINavigationBarContentView 平铺在导航栏中作为 iOS11 的各个按钮的父视图 , 该视图的所有的子视图都会有一个 layoutMargins 被占用 , 也就是系统调整的占位。去掉系统默认占位。系统并没有提供我们直接去掉系统默认占位的方法，那怎么做呢？我们新建一个 UINavigationBar 的分类，hook 住 UINavigationBar 的 layoutSubviews 方法。然后遍历 View，重新设置 layoutMargin 约束。重新设置 layoutMargin 约束3.5 UITableView 默认开启 Self-Sizing，导致 UI 显示有问题。在 iOS11 中 UITableView 会默认使 Self-Sizing, 这会导致 tableView的 estimatedRowHeight 、 estimatedSectionHeaderHeight 、 estimatedSectionFooterHeight 的高度估算属性由默认的 0 变成 UITableViewAutomaticDimension ,reloadData 时可能会导致最后显示的 contentSize 与预想的不一致 ;同时在 iOS11 中如果不实现 -tableView: viewForHeaderInSection: 和 tableView: viewForFooterInSection: 方法，则 -tableView: heightForHeaderInSection: 和 - tableView: heightForFooterInSection: 不会被调用，而 iOS11 之前则没问题。上述都可能会导致界面出现错乱。单独关闭摸一个 UITableView 的 Self-Sizing。
_tableView.estimatedRowHeight
_tableView.estimatedSectionFooterHeight
_tableView.estimatedSectionHeaderHeight
0.;关闭所有的 UIScroolView、UITableView 和 UICollectionView 的 Self-Sizing：
UIScrollView.appearance.contentInsetAdjustmentBehavior
UIScrollViewContentInsetAdjustmentN
UITableView.appearance.estimatedRowHeight
UITableView.appearance.estimatedSectionFooterHeight
UITableView.appearance.estimatedSectionHeaderHeight
0;3.6 keyWindow 获取错误 , 导致 UI 问题。机器猫图标是一个 UIWindow，windowLevel 级别比 UIWindowLevelStatusBar 还高，所以可以常驻 UI 最上方。第一次进入该页面，点击 " 更多 "，弹出 popView，点击收藏，弹出系统 UIAlertView，此时 UIAlertView 变成了 keyWindow。当 UIAlertView 消失的时候，keyWindow 会被谁接管呢？iOS11 之前，弹出 UIAlertView 之前的 keyWindow 是 [ [ UIApplication sharedApplication ] .delegate window ] ，那么消失的时候，keyWindow 还是 [ [ UIApplication sharedApplication ] .delegate window ] 。iOS11, 弹出 UIAlertView 之前的 keyWindow 是 [ [ UIApplication sharedApplication ] .delegate window ] ，那么消失的时候，keyWindow 变成 z 轴最高的 UIWindow，即变成了机器猫那个 window。所以导致 popView 被添加到机器猫 window 中，造成 UI 样式问题。重写自定义 UIWindow 的 becomeKeyWindow 的方法，每次自定义 window 将会变为 keyWindow 的时候，把 keyWindow 改成 [ [ UIApplication sharedApplication ] .delegate window ] 。-
( void ) becomeKeyWindow{
*appWindow
[ [ UIApplication
sharedApplication ] .delegate
window ] ;
[ appWindow
makeKeyWindow ] ;}3.7 状态栏高度写死为 20pt，导致在 iPhoneX 上面遮挡住 statusBar。iPhoneX 上的 statusBar 的高度为 44pt，跟其他 iPhone 型号的 20pt 不一样。所以以后我们在以 statusBar 为定位点的时候，不能写死 20pt。而要使用 [ UIApplication sharedApplication ] .statusBarFrame.size.height 来获取，为了方便，可以定义为宏，放到 pch 文件中，如下：#define
kApplicationStatusBarHeight
[ UIApplication
sharedApplication ] .statusBarFrame.size.height
// 状态栏的高度状态栏高度定位的时候不要写死 20，要使用 [ UIApplication sharedApplication ] .statusBarFrame.size.height 来获取。补充iOS11 之前导航栏默认高度为 64pt ( 这里高度指 statusBar + NavigationBar ) ，iOS11 之后如果设置 prefersLargeTitles = YES 则为 96pt，默认情况下还是 64pt，但在 iPhoneX 上由于刘海的出现 statusBar 由以前的 20pt 变成 44pt，所以 iPhoneX 上高度变为 88pt，如果项目里隐藏了导航栏加了自定义按钮之类的，这里需要注意适配一下。3.8 通过遍历 statusBar 的 subviews 中的 UIStatusBarDataNetworkItemView 获取网络状态在 iPhoneX 上会 crash。问题原因 :之前我们采用遍历 statusBar，获取 UIStatusBarDataNetworkItemView 实例，再获取网络状态的。代码如下：+
( NSNumber
dataNetworkTypeFromStatusBar
UIApplication
[ UIApplication
sharedApplication ] ;
valueForKey:@"statusBar" ]
valueForKey:@"foregroundView" ]
subviews ] ;
*dataNetworkItemView
( [ subviews
subviews )
if ( [ subview
isKindOfClass: [ NSClassFromString ( @"UIStatusBarDataNetworkItemView" )
class ] ] )
dataNetworkItemView
( NSException
*exception )
[ dataNetworkItemView
valueForKey:@"dataNetworkType" ] ;}但是在 iphoneX 的 statusBar 的内部结构已经改变，不能根据遍历获取 UIStatusBarDataNetworkItemView 的状态获取网络状态状态。可以通过po [ statusBar recursiveDescription ] 打印出来 iphoneX 内部结构了，可以看出变化非常的大。使用 AFNetworking 中的 AFNetworkReachabilityManager 类，或者使用获取网络连接状态。四、权限适配4.1 无法获取定位信息，第一次打开 app 也无法弹出定位权限提示框iOS11 定位相关的权限做了更改，在 iOS11 上使用了新的定位权限 key。如果原来申请的权限是始终允许 NSLocationAlwaysUsageDescription，那么需要在保留原来的 key 的基础上增加 NSLocationWhenInUseUsageDescription 和 NSLocationAlwaysAndWhenInUsageDescription。五、其他一些补充5.1 如何判断该设备是不是 iPhoneX5.2 一些常用的宏定义#define
IS_IPHONE_X
[ KDDeviceHelper
is_iPhone_X ] #define
IPHONE_NAVIGATIONBAR_HEIGHT
( IS_IPHONE_X
64 ) #define
IPHONE_STATUSBAR_HEIGHT
( IS_IPHONE_X
20 ) #define
IPHONE_SAFEBOTTOMAREA_HEIGHT
( IS_IPHONE_X
0 ) #define
IPHONE_TOPSENSOR_HEIGHT
( IS_IPHONE_X
0 ) 六、参考文献七、联系方式
相关标签：
原网页已经由 ZAKER 转码排版
中关村在线13小时前
天极网16小时前
IT之家6小时前
智友社区11小时前
凤凰科技1小时前
猫眼科技昨天
凤凰科技2小时前
IT之家昨天
凤凰科技1小时前
凤凰科技1小时前
泡泡网3小时前
IT之家3小时前
太平洋电脑网4小时前
IT1683小时前
凤凰科技5小时前博主最新文章
博主热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)苹果公司于9月份如期发布了新的iPhone-iPhone8，iPhone8 Plus，iPhoneX，前两个不用多说，正常形态的iPhone和前代外观上没有太大区别。iPhoneX则带来了不同的样式，不同的体验，18:9的全面屏屏幕，小刘海，去掉Home键后超前的交互方式。当然对于开发者也带来了对于这块屏幕的适配问题。我想苹果爸爸决定在11月初开售iPhoneX也有一部分让开发者对自己的App做iPhoneX适配的一部分原因，毕竟现在Xcode已经有iPhoneX的模拟器了。过去，我们拿到的手机是方方正正的矩形，所以整个屏幕都可以看做是安全区域Safe Area，而如今由于iPhone X屏幕上的“刘海”以及屏幕四周采用圆角的设计，需要设计师对绘图区域做出调整。苹果给出的安全区域如下页面内容不能超出安全区域（Safe Area）下面我们以通讯录和News应用为例看下iPhoneX模拟器中原生应用对于这块全面屏如何适配的通过例子我们可以发现主要的三点原则:1. 带有空间按钮的顶部导航栏（NavigationBar）要处在“刘海”下面2. 底部导航栏（Tabbar）不能在虚拟横条Home键（不知道咋叫，暂且这么叫吧）下面，也就是说要和屏幕底部保持距离3. 可滚动的列表整块屏幕都是可展示的，但是滚动条要和顶部和底部保持距离不能超出基本以上三点原则可以概括为一句话，所有不可滚动的控件推荐在安全区域内展示，可滚动的控件整个屏幕都可以用来展示这么做也算是充分利用了这块屏幕，并且不影响用户正常使用iPhoneX了Toon的适配初期Toon对于iPhoneX的适配基本为0，所以出现不少问题，主要集中以下几点：1. 顶部导航栏和底部导航栏超出安全区域2. 没有导航栏的列表没有全屏展现3. 吸底按钮超出安全区域4. 顶部导航栏UI错乱5. 列表加载控件在安全区域外部展示下面通过一个Gif图来看下未经过适配的Toon的部分界面在iPhoneX上表现可见未经适配的Toon将会以16:9的样子展现在用户手中，这对于产品在iPhoneX中的体验来说将会是极大的灾难，没有充分利用iPhoneX的全面屏，用户体验将是缺失的经过一段时间的适配，现在开发版的Toon在iPhoneX上已经可以有良好的展示了，虽然还有很多地方没有经过重新设计和优化，不过已经利用了iPhoneX的屏幕展示了经过一段时间的适配，解决了16:9展示，导航栏错位等问题，在的问题主要集中在列表底部加载控件的问题等问题上，接下来本文将通过Demo和Toon的部分界面来具体讲一下iPhoneX UI适配上的问题启动页的适配如果对于启动页不做任何适配，那么App启动后你会发现应用是16:9的样式展示的解决方案有两种：1. Xib或者Stroyboard来作为应用的启动图2. 添加iPhoneX下启动页的图片Toon工程中采取的方案是第二种顶部的适配以前通过加减20来覆盖或者避免状态的代码都会出问题在iPhoneX上状态栏高度不是20了，iOS11安全区的提出，在iPhoneX上状态栏的高变为44
代码中需要通过[UIApplication sharedApplication].statusBarFrame.size.height获取状态栏高度[self.tableView mas_remakeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(self.view.mas_top).offset([UIApplication sharedApplication].statusBarFrame.size.height);
make.bottom.equalTo(self.view.mas_bottom);
make.left.equalTo(self.view.mas_left);
make.right.equalTo(self.view.mas_right);
iOS11 automaticallyAdjustsScrollViewInsets属性废弃了会出现ScorllView下沉20的现象可以调用scrollview新的api`contentInsetAdjustmentBehavior`self.automaticallyAdjustsScrollViewInsets = NO;
if (@available(iOS 11.0, *)) {
self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentN
但是这么写会导致在iPhoneX下出现，由于在X下安全区域的出现，顶部异形区域不建议覆盖，会造成视觉的差异在代码中我们需要来根据设备高度来判断iPhoneX，从而来避免这种情况[self.tableView mas_remakeConstraints:^(MASConstraintMaker *make) {
if (CGRectGetHeight([UIScreen mainScreen].bounds) == 812.0) {
if (@available(iOS 11.0, *)) {
make.top.equalTo(self.view.mas_safeAreaLayoutGuideTop);
make.top.equalTo(self.view.mas_top);
make.bottom.equalTo(self.view.mas_bottom);
make.left.equalTo(self.view.mas_left);
make.right.equalTo(self.view.mas_right);
如果用了MJRefresh在iPhoneX下列表顶部会出现这样的情况，顶部刷新控件会有露出，UI不美观如果设置`contentInsetAdjustmentBehavior`为`UIScrollViewContentInsetAdjustmentNever`，并且设置顶部距离为导航栏距离，又会造成全面屏展示不充分也不是很好- (void)viewDidLoad {
[super viewDidLoad];
&!--省略部分代码--&
if (@available(iOS 11.0, *)) {
self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentN
&!--省略部分代码--&
- (void)viewWillLayoutSubviews {
[super viewWillLayoutSubviews];
[self.tableView mas_remakeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(self.view.mas_top).offset(self.view.layoutMargins.top);
&!--省略部分代码--&
我建议的适配方式，根据具体情况来设置`contentInset`的值- (void)viewDidLoad {
[super viewDidLoad];
&!--省略部分代码--&
if (@available(iOS 11.0, *)) {
self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentN
&!--省略部分代码--&
- (void)viewWillLayoutSubviews {
[super viewWillLayoutSubviews];
if (CGRectGetHeight([UIScreen mainScreen].bounds) == 812.0) {
// 只在iPhoneX下适配
if (@available(iOS 11.0, *)) {
self.tableView.contentInset = UIEdgeInsetsMake(self.view.safeAreaInsets.top, 0, 0, 0);
[self.tableView mas_remakeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(self.view.mas_top).offset(0);
&!--省略部分代码--&
使用以上代码，或者UI设计顶部刷新控件都样式都可以解决该问题，但是我觉得最终极的解决方案还是UI设计根据iPhoneX的异性全面屏给以良好的适配方案，如果有更好的设计方案，比如当列表为初始滚动状态时不显示顶部刷新控件，可以跟我交流顶部的适配问题主要集中体现在以前通过写死状态高度20造成的，对于这个问题，只要调用系统提供获取状态栏高度的方法，就可以避免，至于顶部刷新控件的问题，这个本文建议采取和本文建议的处理底部加载控件的方案来实施，具体可以关注我接下来的文章底部的适配底部导航栏如果是采用系统默认的底部导航栏，没有采用自定义的方式，底部导航栏iOS系统级就做了处理，会保证在Tabbar是在安全区域之内如果是采取自定义的方式那么则要对做出响应的处理+ (CGFloat)computeTabbarHeight {
NSInteger style = [[TNAppStackManager shareInstance] rootStyle];
if (style == RootControllerStyle_TabCircleDrawer || style == RootControllerStyle_TabCircleNoDrawer) {
return 70.;
} else if (style == RootControllerStyle_TabNormal) {
return [[UIDevice currentDevice] systemVersion].doubleValue &= 11.0 ? (fabs(CGRectGetHeight([UIScreen mainScreen].bounds) - 812.) &= 1.0 ? 49. : 83.) : 53.;
以上是Toon工程在处理底部导航栏高度的示例代码，通过系统版本和设备来判断具体导航栏的高度列表底部加载控件的的处理列表的底部加载控件和在全屏下的顶部刷新控件的问题是我认为不不好给出解决方案的问题iOS11废弃了原有的`automaticallyAdjustsScrollViewInsets`属性，为scrollview添加了新的属性`contentInsetAdjustmentBehavior`现在对于我列表的适配，我看大都是这个样子的self.automaticallyAdjustsScrollViewInsets = NO;
if (@available(iOS 11.0, *)) {
self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentN
这两个属性都是为了让列表对于全屏和异形屏幕下有良好的展示设计的，对于非全屏状态下的列表，这两个属性不处理没有关系，因为只有在全屏或者半全屏（只有顶部导航或者）对于Toon来说，刚开我们对于所有的列表都将上面的属性置为了`UIScrollViewContentInsetAdjustmentNever`，这样在iPhoneX部分界面就变成这样了会发现在iPhoneX下，tableView展示区域是到底的，这样会影响用户使用home虚拟横条，所以这个值是需要根据具体情况分析的，例如如果tableView是全屏展示的就需要设置为`UIScrollViewContentInsetAdjustmentNever`在此基础上需要适配就是tableView的刷新控件和加载控件了，假设大家使用的都是MjRefresh,那么对于刷新控件出现的问题上文已经讲过了，不在赘述。我们来讨论下加载控件会出现的问题。刷新控件还好，大部分刷新控件都是在有顶部导航栏的情况下，可是底部加载控件不同，又很多处理方式，本文只做一个抛砖引玉的示例，具体处理方式还是要结合产品、UI、技术来以前讨论针对具体情况具体分析，接下来我将会以Toon中小组模块我的评论界面为例，给出我的解决方案如果`contentInsetAdjustmentBehavior`设置为`UIScrollViewContentInsetAdjustmentNever`，那么出现的问题是，底部加载控件会在安全区域意外露出。为了明显我讲底部加载控件的背景色置成了橙色，可以看到正常情况，加载控件是暴露在安全区域外部，上面的文字也能看到，这样一来既不没关也显得不够专业，并且文字也被home虚拟横条挡住了那么怎么处理这种情况才会更好些呢，本文给的解决方案是给底部加载控件加一个遮罩，而这个遮罩是根据，tableView的偏移量来展示的，最后的效果如下。核心代码如下：- (void)setLoadFooter {
self.tableView.mj_footer = [MJRefreshBackStateFooter footerWithRefreshingTarget:self refreshingAction:@selector(loadCommentData)];
self.tableView.mj_footer.backgroundColor = [UIColor orangeColor];
self.tableView.mj_footer.maskView = [[UIView alloc] init];
self.tableView.mj_footer.maskView.backgroundColor = [UIColor whiteColor];
[self.tableView addObserver:self forKeyPath:@"contentOffset" options:NSKeyValueObservingOptionNew context:nil];
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary&NSKeyValueChangeKey,id& *)change context:(void *)context {
if (object == self.tableView && [keyPath isEqualToString:@"contentOffset"]) {
if (@available(iOS 11.0, *)) {
判断设备为iPhoneX时，
并且contentInsetAdjustmentBehavior不为UIApplicationBackgroundFetchIntervalNever
if (CGRectGetHeight([UIScreen mainScreen].bounds) == 812.0 && self.tableView.contentInsetAdjustmentBehavior == UIScrollViewContentInsetAdjustmentAutomatic) {
CGFloat distanceToSafeBottom = (self.tableView.contentOffset.y + CGRectGetHeight(self.tableView.frame) - self.view.safeAreaInsets.bottom) - self.tableView.contentSize.
if (distanceToSafeBottom & 0) {
self.tableView.mj_footer.maskView.frame = CGRectZ
CGFloat showFooterHeight = distanceToSafeB
if (showFooterHeight & CGRectGetHeight(self.tableView.mj_footer.bounds)) {
showFooterHeight = CGRectGetHeight(self.tableView.mj_footer.bounds);
if (self.tableView.mj_footer.state != MJRefreshStateRefreshing) {
self.tableView.mj_footer.maskView.frame = CGRectMake(0, 0, CGRectGetWidth(self.tableView.mj_footer.bounds), showFooterHeight);
248 条评论分享收藏中国奉上iPhoneX第一次拆 双电池/主板缩小一半
　　【PConline资讯】一直以来，iPhone新机拆解总是被国外抢先，尤其是那个大名鼎鼎的iFixit，但现在国内玩家速度越来越快，iPhone 7/8系列都走在了前列，明天才会正式发售的iPhone X也是如此，网上已经出现了一段来自国内的iPhone X拆解视频。　　视频虽然只有短短10秒钟，而且只是修了一下拆掉屏幕前面板的内部概览，但已经暴露了很多真相。　　拿到了多张更高清晰度的图片，并进行了细致分析，发现了不少有趣的地方，不得不承认iPhone X内部设计极为精妙。　　可以看到，内部元件整体布局和之前几代iPhone很相似，但也有明显的变化，尤其是电池首次配备了两块(总容量2716mAh)，为续航也是拼了，同时也应该是为了配合OLED屏幕。 　　同时，PCB主板面积也小了很多，差不多只有iPhone 8 Plus的一半，从而留下更多空间放置其他元件，不过也正是因为如此，电池做成了L形状 。　　缩小后的主板集成度非常高，可以看到密集的电容等元件和接口，但不知道发热控制得如何，而且拆解和维修难度也必然加大。　　另外，边框四周有大量泡棉双面胶，点胶量明显高于iPhone 8 Plus，密闭性和防水性应该会更高；刘海部位的传感器确实很复杂，结构也异常紧凑，空间利用率极高。　　更详细的拆解和分析，还是等iFixit出手吧&&相关阅读:评论家：iPhoneX是最好的iPhone 缺点就是有点贵人脸识别体验不错 iOS11贴心功能 iPhoneX被优待iPhoneX开卖 5小时卖460亿 华为小米倒吸冷气？&
最新资讯离线随时看
聊天吐槽赢奖品
相关软件：
大小：44.5 MB
授权：免费
大小：141.47 MB
授权：免费