注册
环信即时通讯云

环信即时通讯云

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

环信开发文档

Demo体验

Demo体验

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

RTE开发者社区

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

技术讨论区

技术交流、答疑
资源下载

资源下载

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

iOS Library

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

Android Library

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

丢掉丑陋的 toast,会动的 toast 更有趣!

前言我们通常会用 toast(也叫吐司)来显示提示信息,例如网络请求错误,校验错误等等。大多数 App的 toast 都很简单,简单的半透明黑底加上白色文字草草了事,比如下面这种. 说实话,这种toast 的体验很糟糕。假设是新手用户,他们并不知道 toas...
继续阅读 »



前言

我们通常会用 toast(也叫吐司)来显示提示信息,例如网络请求错误,校验错误等等。大多数 App的 toast 都很简单,简单的半透明黑底加上白色文字草草了事,比如下面这种.

说实话,这种toast 的体验很糟糕。假设是新手用户,他们并不知道 toast 从哪里出来,等出现错误的时候,闪现出来的时候,可能还没抓住内容的重点就消失了(尤其是想截屏抓错误的时候,更抓狂)。这是因为一个是这种 toast 一般比较小,而是动效非常简单,用来提醒其实并不是特别好。怎么破?本篇来给大家介绍一个非常有趣的 toast 组件 —— motion_toast

motion_toast 介绍

从名字就知道,motion_toast 是支持动效的,除此之外,它的颜值还很高,下面是它的一个示例动图,仔细看那个小闹钟图标,是在跳动的哦。这种提醒效果比起常用的 toast 来说醒目多了,也更有趣味性。 下面我们看看 motion_toast 的特性:

  • 可以通过动画图标实现动效;

  • 内置了成功、警告、错误、提醒和删除类型;

  • 支持自定义;

  • 支持不同的主题色;

  • 支持 null safety;

  • 心跳动画效果;

  • 完全自定义的文本内容;

  • 内置动画效果;

  • 支持自定义布局(LTR 和 RTL);

  • 自定义持续时长;

  • 自定义展现位置(居中,底部或顶部);

  • 支持长文本显示;

  • 自定义背景样式;

  • 自定义消失形式。

可以看到,除了能够开箱即用之外,我们还可以通过自定义来丰富 toast 的样式,使之更有趣。

示例

介绍完了,我们来一些典型的示例吧,首先在 pubspec.yaml 中添加依赖motion_toast: ^2.0.0(最低Dart版本需要2.12)。

最简单用法

只需要一行代码搞定!其他参数在 success 的命名构造方法中默认了,因此使用非常简单。

MotionToast.success(description: '操作成功!').show(context);

其他内置的提醒

内置的提醒也支持我们修改默认参数进行样式调整,如标题、位置、宽度、显示位置、动画曲线等等。

// 错误提示
MotionToast.error(
 description: '发生错误!',
 width: 300,
 position: MOTION_TOAST_POSITION.center,
).show(context);

//删除提示
MotionToast.delete(
 description: '已成功删除',
 position: MOTION_TOAST_POSITION.bottom,
 animationType: ANIMATION.fromLeft,
 animationCurve: Curves.bounceIn,
).show(context);

// 信息提醒(带标题)
MotionToast.info(
 description: '这是一条提醒,可能会有很多行。toast 会自动调整高度显示',
 title: '提醒',
 titleStyle: TextStyle(fontWeight: FontWeight.bold),
 position: MOTION_TOAST_POSITION.bottom,
 animationType: ANIMATION.fromBottom,
 animationCurve: Curves.linear,
 dismissable: true,
).show(context);

不过需要注意的是,一个是 dismissable 参数只对显示位置在底部的有用,当在底部且dismissabletrue 时,点击空白处可以让 toast 提前消失。另外就是显示位置 positionanimationType 是存在某些互斥关系的。从源码可以看到底部显示的时候,animationType不能是 fromTop,顶部显示的时候 animationType 不能是 fromBottom

void _assertValidValues() {
 assert(
  (position == MOTION_TOAST_POSITION.bottom &&
           animationType != ANIMATION.fromTop) ||
      (position == MOTION_TOAST_POSITION.top &&
           animationType != ANIMATION.fromBottom) ||
      (position == MOTION_TOAST_POSITION.center),
);
}

自定义 toast

自定义其实就是使用 MotionToast 构建一个实例,其中,descriptioniconprimaryColor参数是必传的。自定义的参数很多,使用的时候建议看一下源码注释。

MotionToast(
 description: '这是自定义 toast',
 icon: Icons.flag,
 primaryColor: Colors.blue,
 secondaryColor: Colors.green[300],
 descriptionStyle: TextStyle(
   color: Colors.white,
),
 position: MOTION_TOAST_POSITION.center,
 animationType: ANIMATION.fromRight,
 animationCurve: Curves.easeIn,
).show(context);

下面对自定义的一些参数做一下解释:

  • icon:图标,IconData 类,可以使用系统字体图标;

  • primaryColor:主颜色,也就是大的背景底色;

  • secondaryColor:辅助色,也就是图标和旁边的竖条的颜色;

  • descriptionStyle:toast 文字的字体样式;

  • title:标题文字;

  • titleStyle:标题文字样式;

  • toastDuration:显示时长;

  • backgroundType:背景类型,枚举值,共三个可选值,transparentsolidlighter,默认是 lighterlighter其实就是加了一层白色底色,然后再将原先的背景色(主色调)加上一定的透明度叠加到上面,所以看起来会泛白。

  • onClose:关闭时回调,可以用于出现多个错误时依次展示,或者是关闭后触发某些动作,如返回上一页。

总结

看完之后,是不是觉得以前的 toast 太丑了?用 motion_toast来一个更有趣的吧。另外,整个 motion_toast 的源码并不多,有兴趣的可以读读源码,了解一下toast 的实现也是不错的。

作者:岛上码农
来源:https://juejin.cn/post/7042301322376265742

收起阅读 »

web错误处理/错误捕获方案

前言花了一些时间整理完善项目的错误处理/错误捕获能力,借此进行一次总结。为了方便阅读,先概括下大概的思路:// 错误处理,避免报错导致程序无法继续执行1、自行对重要步骤进行容灾和try...catch...finally等处理;  2、通过打包工具(...
继续阅读 »



前言

花了一些时间整理完善项目的错误处理/错误捕获能力,借此进行一次总结。为了方便阅读,先概括下大概的思路:

// 错误处理,避免报错导致程序无法继续执行
1、自行对重要步骤进行容灾和try...catch...finally等处理;  
2、通过打包工具(我用的是vite,自己实现的是rollup的plugin)将绝大部分语句包裹try...catch语句,并补全错误信息(文件名,方法名);  

// 错误捕获
1、onerror 事件捕获全局错误;  
2、unhandledrejection 捕获异步错误;  
3、框架层面错误监听(e.g. Vue.config.errorHandler, react ErrorBoundary);  
3、axios等tcp/ip错误处理;  
4、静态资源加载异常捕获(window.addEventListener('error',(event)=>{});  

// 错误分析,补全错误信息
1、通过sourcemap解析错误信息,定位到具体错误代码;

错误处理

我实现的插件是rollup-plugin-trycatch,这个方案不算成熟:

涉及到业务代码的translate,单元测试覆盖面可能不足(目前仅处理几种类型函数,欢迎pr);

如果项目比较稳定,测试覆盖率较高,不建议使用此方案。

rollup-plugin-trycatch

跟webpack有些区别,rollup不分plugin和loader,只通过plugin来实现插件。主要流程如下:
1、创建rollup插件;
2、通过rollup的acorn插件将code转为ast语法树;
3、通过stack-utils插件将当前文件/文件名行数等信息添加到err里;
3、通过estree-walker遍历语法树,将相关的语句(函数)增加wrap节点;
4、通过escodegen插件将语法树转为code;
功能:
1、给所有函数(FunctionDeclaration, FunctionExpression, ArrowFunctionExpression, ObjectMethod)包一层try...catch捕获异常;
2、try...catch错误补全(增加报错信息,原文件名,方法名等错误分析,但仍不够精确,未能定位到具体报错的语句);
具体内容和使用方式可以查看源码,里面有vite的使用demo;

错误捕获

错误捕获的难点在于两个方面:
1、如何全面的捕获到错误;
2、如果通过错误分析到具体问题(一般来说线上代码都是打包压缩过的,如何通过打包压缩后的代码定位到问题);

全面(尽可能)的错误捕获

在我们尝试错误捕获之前,需要先了解有哪些错误,分三类(这里其实有很多分类的方式,我尝试用我自己的分类方式来解读):

1、远程资源加载错误;

window.addEventListener('error', (err) => {
let _url = ''

// 远程资源加载异常
if(err.target instanceof HTMLElement) {
  if(err.target instanceof HTMLAnchorElement) {
    _url = err.target.href
  } else {
    // maybe other htmlelement has src property
    _url = (err.target as HTMLImageElement).src
  }
  // 这里进行上报
  console.log(err, _url)
}
}, true) // 注意有三个参数,第三个参数表捕获阶段传播到该EventTarget时触发

2、同步代码错误 && 异步代码(setTimeout/setInterval,等);

window.onerror = (message, source, lineno, colno, error) => {
// 这里进行错误上报操作
console.log(message, source, lineno, colno, error)
}

3、异步代码错误;

// promise
window.addEventListener("unhandledrejection", (e) => {
// 这里进行上报
console.log(e.reason)
e.preventDefault() // 阻止错误冒泡
}, true)

4、框架提供的错误处理,e.g.

// vue3
app.config.errorHandler = (err, vm, info) => {
// 这里进行错误上报
console.log(err, vm, info)
}

5、xhr, fetch等异步请求方式;

// xhr
function xhr() {
const oReq = new XMLHttpRequest();
const url = "http://www.example.org/example.txt"
 
oReq.addEventListener("error", (err) => {
  console.log(err, url)
});
oReq.open("GET", url);
oReq.send();
}
// fetch
function fetchMethod() {
const url = 'http://www.example.org/example.txt'

fetch(url,
  {
    method: 'GET',
    mode: 'cors',
    cache: 'default'
  }
).then(data => {
  console.log(data)
}).catch(err => {
  // 错误处理
  console.log(url, err)
})
}

具体代码可参考 demo;

错误位置

我们的代码一般是打包压缩后的代码,错误提示的位置有时候很难定位到具体的内容,特别是很难重现的错误内容,我们常常需要更精准的错误信息进行定位。

对于以上方案以及对应的处理方式如下

1、rollup-plugin-trycatch插件wrap一层try...catch;  
在插件中已对错误记录路径,方法名等信息;  
2、远程静态资源;  
错误已记录路径信息;  
3、promise异步代码错误;  
建议自行全部加上catch处理错误;  
4、框架内部的错误处理;  
框架已提供错误定位信息(vue3, `info` is a Vue-specific error info, e.g. which lifecycle hook);  
5、xhr, fetch等;  
建议自行记录处理;  
5、同步代码错误 && 异步代码(setTimeout/setInterval,等);  
其实这个错误是主要错误之一,目前的方案是通过提前打包sourcemap来进行解析

sourcemap解析错误

这里主要介绍下如何实现解析功能(有些服务,e.g. sentry已提供sourcemap的服务,但我们是自己搭建的,所以需要自己来实现这个功能):
1、打包时候将最新的sourcemap覆盖上传到解析服务上(如果有不同版本的查询问题的需求,可以考虑多版本,我暂时没做);

现在大部分公司都是通过自动化工具(jenkins, gitlab等)在打包机进行打包编译,在打包成功后将sourcemap文件上传到解析的服务目录上即可(可以运维通过ssh上传,也可以自行搭建文件上传服务); 

2、通过source-map解析文件,返回具体错误位置;

// 需要传入参数,source, lineno, colno

解析sourcemap源码

问题记录

1、Error.prototype.stack是实验性功能,在不同浏览器,不同版本有不同的处理方式(包括try...catch, unhandledrejection等error都是Error的实例)。
可以参考stackoverflow兼容主流浏览器(未测试);
另外一种就是像我的plugin中自动化wrap try...catch方法时记录下行信息;对于promise,建议尽量全部通过catch处理(或变成同步代码async await);

2、rollup或者acorn并没有提供ast->code的方法,如何进行转换?
在修改ast后需要通过另外的插件来实现ast->code,较多人在issue里推荐的是escodegen。

3、estree-walker在jest调用时候出现module not found的问题;
用2.0.2版本是ok的, 有issue跟进

4、有一些浏览器支持但rollup尚未支持的实验属性需要慎用。

1、class 私有属性 相关issue: https://github.com/rollup/rollup/issues/4292,可以通过插件@rollup/plugin-typescript转化后使用;

参考文档

1、 React,优雅的捕获异常: juejin.cn/post/697438…
2、Allow plugin transforms to only return AST: github.com/rollup/roll…
3、source-map-demo: github.com/Joeoeoe/sou…

作者:vb
来源:https://juejin.cn/post/7046320743973388295

收起阅读 »

关于MobX,知无不言,言无不尽~

MobX 实践指南一、概览篇简介MobX 是一个专注于状态管理的库,在 React 世界的流行程度仅次于拥有官方背景的 Redux。但 MobX 有自己独特的优势,它通过运用透明的函数式响应编程使状态管理变得简单、高效、自由。MobX哲学任何源自应用状态的东西...
继续阅读 »

MobX 实践指南

一、概览篇

简介

MobX 是一个专注于状态管理的库,在 React 世界的流行程度仅次于拥有官方背景的 Redux。但 MobX 有自己独特的优势,它通过运用透明的函数式响应编程使状态管理变得简单、高效、自由。

MobX哲学

任何源自应用状态的东西都应该自动地获得。

核心原理

利用defineProperty(<=v5)或Proxy(v6)拦截对象属性的变化,实现数据的Observable,在 get 中依赖收集,set 中触发依赖绑定的监听函数。
假如你之前关注过 Vue.js、Knockout 等的一些 MVVM 框架的响应式原理,那么你应该会感到非常熟悉。是的,它们的原理如出一辙。

核心概念

不仅是原理,基础概念、顶层的 Api 设计也十分相似。Vue.js 中 data、computed、watch,几乎可以与 Mobx 中的observable-statecomputedreaction等概念一一对应。最大的不同是,MobX 通过 actions 约束对 state 的更新方式,实现了对状态的管理这一重要步骤。整体运行流程如下图所示。

alt 运行流程

安装

mobx 这个包,提供了 MobX 所有的与具体框架平台无关的基础 Api。比如(observable、makeObservable、action等)。

npm i mobx

如果在 react 中使用,需要添加针对 react 开发的包 mobx-react

npm i mobx mobx-react

如果你在 react 开发中,只使用函数式组件,没有使用类组件,那么可以将 mobx-react 替换为一个更轻量的包 mobx-react-lite

npm i mobx mobx-react-lite

相比mobx-react这个全量包,
1. 去掉了对class components的支持,
2. 并且移除了provider、inject
(原因:这两个HOC在React官方已经提供了React.createContext之后变得不是那么必要了)

二、实践篇

1. 声明Store

相比直接使用普通对象,MobX 更推荐使用的方式去创建 Store,主要原因是 class 对 TS 的类型系统更友好,更容易被索引实现自动补全等功能。

三种声明方式

方式一、直接使用普通对象的方式 (不推荐)

import { observable,action } from 'mobx'

const userStore = observable({
roleType:1
})

export const changeRoleType = action((val)=>{
userStore.roleType = val
})

export default userStore

方式二、使用类 + 装饰器 (V6 版本之前的推荐方式)

import { observable } from 'mobx'

class UserStore{
@observable roleType=1
@action changeRoleType(val){
this.data = val
}
}

export default UserStore

方式三、使用类 + makeObservable (V6 版本的推荐方式)(不再推荐装饰器的原因可以在Q&A章节找到)

import { makeObservable,observable,computed,action } from 'mobx'

class UserStore{
constructor(){
makeObservable(this,{
roleType:observable,
roleName:computed,
changeRoleType:action
})
}
roleType = 1
get roleName(){
return roleMap[roleType]
}
changeRoleType(val){
this.roleType = val
}
}
export default UserStore

//or

import { makeAutoObservable } from 'mobx'

class UserStore{
constructor(){
makeAutoObservable(this)
/* 无需显示的声明,会自动应用合适的MobX-Api去修饰。比如
(1)值字段会被推断为observable、
(2)get 修饰的方法,会推断为computed、
(3)普通方法,会自动应用action
(4)如果你有自定义调整某些字段的需求,请参考此方法的[其他入参](https://zh.mobx.js.org/observable-state.html#makeautoobservable)
*/
}
roleType = 1
get roleName(){
return roleMap[roleType]
}
changeRoleType(val){
this.roleType = val
}
}
export default UserStore

实现 store 间通信

例子:在一个角色管理的模块,因为自己拥有管理员权限,权力大到甚至能够更改自己的角色类型,那么果真这样操作时,就需要将RoleStore的修改同步到UserStore,这时就涉及到多个store间通信。
思路:创建一个公共的上级 rootStore,实现多个Store间的状态读取,方法调用。

// 用户信息Store
class UserStore{
constructor(rootStore){
this.rootStore = rootStore
makeAutoObservable(this)
}
uid = 'zyd123'
roleType = 1
changeRoleType(val){
this.roleType = val
}
}
// 角色管理Store
class RoleStore{
constructor(rootStore){
this.rootStore = rootStore
makeAutoObservable(this)
}
changeUserRoleType(uid,type){
const {userStore} = this.rootStore
//更改自己的角色类型
if(uid === userStore.uid){
//*** 同步UserStore ***
userStore.changeRoleType(type)
...
}else{
//更改别人的角色类型
...
}
}
}

// 新建一个上层rootStore,方便Stores间沟通
class RootStore {
constructor() {
this.userStore = new UserStore(this)
this.roleStore = new RoleStore(this)
}
}

const rootStore = new RootStore()
export default rootStore

2. 在React组件中使用

2.1 observer

作用:自动订阅在react组件渲染期间被使用到的可观察对象属性,当他们变化发生时,组件就会自动进行重新渲染。 前边在概览篇提到过MobX的核心能力就是能够将数据get中收集到的所有依赖,在set中一次性发布出去。在react场景中,就是要将状态与组件渲染建立联系,一旦状态变化,所有使用到此状态的组件都需要重新渲染,而这一切的关键就是observer。
用法如下:(demo:实现一个更改全局角色的功能,RoleManage组件负责更改,UserInfo组件负责展示)
src/demos/UserInfo.jsx

import { observer } from "mobx-react";
// 导入rootStore
import rootStore from './../store';
// 拿到对应的子Store
const { userStore } = rootStore;

class UserInfo extends Component {
render() {
//(1) 触发get,收集依赖(ps:当前组件已加入MobX的购物车)
const { roleName } = userStore;
return (
<Row justify="space-between">
<Col></Col>
<Col span={5} className='border'>
<Space align='center'>
<span>当前角色类型:</span>
<h2>{roleName}</h2>
</Space>
</Col>
</Row>
);
}
}
// (关键)observer HOC包裹住组件,将MobX强大的响应式更新能力赋予react组件。
export default observer(UserInfo)

src/demos/RoleManage.jsx

import rootStore from './../store'

const { userStore } = rootStore;

class RoleManage extends Component {
handleUpdateRoleType = ()=>{
//(2) 使用一个action去触发数据set,在set中发布依赖(触发组件更新,ps:Mobx要清空购物车啦)
userStore.changeRoleType(2)
}
render() {
return <Button onClick={this.handleUpdateRoleType}>更改角色</Button>
}
}
export default RoleManage;

2.2 Provider、inject

作用:刚才的例子中,大家可以看到全局Store的引入方式是文件的方式引入的。

import rootStore from './../store'

const { userStore } = rootStore;

这种方式繁琐且不利于维护,假如store文件重新组织,引入的地方需要处处更改与check。所以,有没有方式,在项目开发中Store只需一次注入,就可以在所有组件内非常便捷的引用呢?
答案就是使用 Provider、inject。
让我们重构上边的例子: src/index.jsx

import App from "./App";

import { Provider } from 'mobx-react'
import store from './store'
//利用Provider将Store注入全局
ReactDOM.render(
<Provider {...store}>
<App/>
</Provider>,
document.getElementById("root")
);

src/demos/UserInfo.jsx

class UserInfo extends Component {
render() {
//通过props的方式在render函数中引用
const { roleName } = this.props.userStore;

return (
<Row justify="space-between">
<Col></Col>
<Col span={5} className='border'>
<Space align='center'>
<span>当前角色类型:</span>
<h2>{roleName}</h2>
</Space>
</Col>
</Row>
);
}
}

// inject是高阶函数,所以inject('store')返回值还是个函数,最终入参是组件
export default inject('userStore')(observer(UserInfo))

Provider及inject看上去与react官方推出的context Api用法非常相似,要解决的问题也基本一致。
事实上,最新版的mobx-react,前者就是基于后者去做的封装,这也从侧面说明,这俩Api现在来看,并不是开发react应用的必需品。所以MobX官方在推出针对React平台的轻量包(mobx-react-lite)时,首先就把这俩api排除在外了。
但笔者认为,你如果使用的是class组件,Provider及inject依然建议使用,因为class组件内使用contextApi并不十分方便,但如果你用的hooks,则大可不必再使用Provider及inject了,得益于useContext的方便简洁,大大降低了使用他们的必要性(具体用法,后边会讲到)。

2.3 MobX + Hooks

函数组件+hooks是目前开发React应用的首选方式。MobX顺应趋势,推出了新的hook Api,这已经成为使用MobX的主流方式。

2.3.1 使用全局Store

自定义useStore替换Provider、inject 下边示例笔者会统一采用mobx-react-lite这个轻量包来编写。前边提到这个包并不提供Provider、inject,但是没有关系,有React官方提供的createContext及useContext就足够了。 下边我们自己动手封装一个好用的useStore-hook。
src/store/index.js

...

//创建rootStore的Context
export const rootStoreContext = React.createContext(rootStore)

/**
* @description 提供hook方式,方便组件内部获取Store
* @param {*} storeName 组件名字。作用类似inject(storeName),不传默认返回rootStore
*/

export const useStore = (storeName) => {
const rootStore = React.useContext(rootStoreContext)
if (storeName) {
const childStore = rootStore[storeName]
if (!childStore) {
throw new Error('根据传入storeName,找不到对应的子store')
}
return childStore
}
return rootStore
}

src/index.jsx

- import { Provider } from 'mobx-react'

+ import rootStore, {rootStoreContext} from './store'
+ const { Provider } = rootStoreContext

ReactDOM.render(
<Provider value={rootStore}>
<App/>
</Provider>,
document.getElementById("root")

src/demos/UserInfo.jsx

//换用更轻量的lite包
- import { observer } from "mobx-react";
+ import { observer } from "mobx-react-lite";
import { Row, Col, Space } from "antd";

+ import { useStore } from '../store';

// 函数式组件
const UserInfo = ()=> {
//使用自定义useStore获取全局store
const { roleName } = useStore('userStore')

return (
<Row justify="space-between">
<Col></Col>
<Col span={5} className='border'>
<Space align='center'>
<span>当前角色类型:</span>
<h2>{roleName}</h2>
</Space>
</Col>
</Row>
)
}
export default observer(UserInfo)

假如日常项目中,只希望MobX负责全局的状态管理,以上内容就完全够用了。下边我会介绍MobX+hook在局部状态管理方面的强大能力。
全局状态管理:store在组件外定义,经常放在全局一个单独的store文件夹。适合管理一些公共或者相对某模块是公共的状态。
局部状态管理:store常常定义在组件内部,适用于复杂的组件设计场景,用来解决组件多层嵌套下的状态层层传递、组件状态多且更新复杂等问题。

2.3.2 创建一个局部的Store

先介绍两个hook

useLocalObservable

作用:通过hook的方式声明一个组件内的Store,返回传入普通对象的响应式版本,并在函数组件之后的每一次渲染中保持对这个响应式对象的唯一引用(这点与useState是一致的)(useLocalStore是这个api的前身,但是将要废弃,这里不做介绍)。

useObserver

作用:前边讲的observer是HOC的方式,只能在外部通过包裹整个组件的方式去使用。想要在组件内部实现局部状态管理,在类组件中必须通过内置的Observer组件以renderProps的方式去解决,但在函数式中,hook一定是解决问题的首选,所以可以理解为useObserver是Observer的hook版实现。 示例:useLocalObservable + useObserver实现一个局部的状态管理 src/demos/UserInfoScopeStore.jsx

import { useLocalObservable, useObserver } from "mobx-react-lite";
import { Row, Col, Space,Button } from "antd";

const UserInfo = ()=> {
//定义组件内的响应式Store
const store = useLocalObservable(()=>({
name:'xxx',
changeName(text){
this.name = text
}
}))
// 对比以下两种组件内局部状态视图更新方式。
// useObserver
return useObserver(()=> <Row justify="space-between">
<Col></Col>
<Col span={5} className='border'>
<Space align='center'>
<span>当前用户:</span>
<h2>{store.name}</h2>
<Button onClick={()=>store.changeName('小米')}>修改</Button>
</Space>
</Col>
</Row>)
// or Observer
return <Observer>
{() => <Row justify="space-between">
<Col></Col>
<Col span={5} className='border'>
<Space align='center'>
<span>当前用户:</span>
<h2>{store.name}</h2>
<Button onClick={() => store.changeName('小米')}>修改</Button>
</Space>
</Col>
</Row>}
</Observer>
}
export default UserInfo

简单总结:(1)observer HOC的方式适合组件的整体更新场景(2)useObserver or Observer 都可用来处理局部的组件内更新场景,区别前者是hook的方式,只支持函数式组件,后者使用renderProps的方式,类与函数组件都兼容。

3. 开发者工具

chrome插件

三、Q&A

  1. IE项目能不能用?

V4版本默认可用,V5及以上如果需要兼容不支持Proxy的IE / React Native,请在应用初始化修改全局配置useProxies

import { configure } from "mobx"
// 如果需要兼容ie或rn,请通过全局配置,禁止使用代理
configure({ useProxies: "never" })

  1. 为什么MobX新的V6版本,不再推荐类的装饰器语法,而是建议用makeObservable的方式去修饰Store?

不再推荐装饰器的理由:因为装饰器语法尚未定案,纳入 ES 标准的时间遥遥无期,且未来制定的标准可能与当前的装饰器实现方案有所不同。所以出于兼容性,MobX 6中不推荐使用装饰器,并建议使用 makeObservable / makeAutoObservable 代替。但项目中如果使用的是 TS,笔者认为可以基本忽略影响,毕竟装饰器确实使用起来更简洁一些。

  1. 为什么我的组件并没有随着Store数据的更新而更新?

(1)忘记了observer,useObserver的包裹(大部分原因都是这个)。 (2)defineProperty的响应式方案会有一些针对数组和对象的限制,需要格外注意,必要时候需要使用mobx提供的set方法来解决。 (3)只要你始终传递响应式对象的引用,observer就可以很好的工作,如果只是传递属性值,就造成了响应式丢失,常发生在使用ES6解构的场景,或只传个响应式对象的属性进去。如果读者了解vue3,那么其中的toRefs就是为了解决类似的问题,但是Mobx中你可以通过下边的例子避免这种情况。

   //错误 ❌
const TimerView = observer(({ secondsPassed }) => <span>Seconds passed: {secondsPassed}</span>)

React.render(<TimerViewer secondPassed={myTimer.secondsPassed} />, document.body)

// 正确 🙆
const TimerView = observer(({ myTimer }) => <span>Seconds passed: {myTimer.secondsPassed}</span>)

React.render(<TimerViewer secondPassed={myTimer} />, document.body)
```

4. **必须要通过action去更新Store?**
原理上不必要,原则上必要。你直接**mutable**的方式直接更改Store也是能够触发响应式更新,但是mobx强烈不建议你这样做,因为你会丢失以下好处:
(1) 能够清晰表达出一个函数修改状态的意图,有**利于项目维护**
(2) action结合开发者工具,提供了非常**有用的调试**信息
当启用**严格模式**时,修改store状态需要强制使用action,参见全局配置enforceActions。MobX并不像redux那样,从原理上就限制了state的更新方式,只能靠这种约定的方式去限制。所以**强烈建议开启此选项**。

5. **频繁使用observer,会不会出现性能问题?**
当组件相关的 observable 发生变化时,组件将自动重新渲染,反之,它能够确保在没有相关更改时组件不会重新渲染。真正做到了组件的按需渲染,在实践中,这使得 MobX 应用程序开箱即用地进行了很好的优化,它们通常不需要任何额外的代码来防止过度渲染。

6. **MobX相比Redux最大的优势是什么?**
具体来说:MobX的开箱即用,简洁灵活,对现有项目侵入小,这都是相比Redux的优势方面。
抽象来讲:MobX相比Redux,它天然对实体模型是友好的,它在内部巧妙的借助拦截代理把数据做了observable转换,让你依然在使用层面感知到的是实体模型,但是它却拥有了响应式能力,这就是mobx最厉害的地方,它适合抽象**领域模型**!
## 结尾
以上所有例子都可在这个[github仓库](https://github.com/FEyudong/mobx-study.git)找到。
# END THANKS~

原文:


https://juejin.cn/post/6979095356302688286

收起阅读 »

js 实现双指缩放

前言随着智能手机、平板电脑等触控设备的普及,交互方式也发生了改变。相对于使用鼠标和键盘进行交互的电脑,触控设备可以直接使用手指进行交互,而且基本上都支持多点触控。多点触控最常见的操作莫过于双指缩放了。比如双指缩放网页大小、朋友圈双指缩放图片进行查看。那么如此常...
继续阅读 »

前言

随着智能手机、平板电脑等触控设备的普及,交互方式也发生了改变。相对于使用鼠标和键盘进行交互的电脑,触控设备可以直接使用手指进行交互,而且基本上都支持多点触控。多点触控最常见的操作莫过于双指缩放了。比如双指缩放网页大小、朋友圈双指缩放图片进行查看。那么如此常见的手势操作,你有没有想过它是如何实现的呢?下面跟着我一探究竟吧!

缩放原理

原理其实很简单,双指向外扩张表示放大,向内收缩表示缩小,缩放比例是通过计算双指当前的距离 / 双指上一次的距离获得的。详见下图:

p.jpg

计算出缩放比例后再通过下面两种方式实现缩放。

  1. 通过transform进行缩放
  2. 通过修改宽高来实现缩放

主流的方法都是采用transform来实现,因为性能更好。本篇文章两种方式都会介绍,任你选择。不过在讲之前,还是要先搞懂两个数学公式以及PointerEvent指针事件。因为接下来会用到。如果对PointerEvent指针事件不太熟悉的小伙伴,也可以看看这篇文章js PointerEvent指针事件简单介绍

两点间距离公式

设两个点A、B以及坐标分别为A(x1, y1)、B(x2, y2),则A和B两点之间的距离为:

e693d73856f43706273b0197b3cc42bf.svg

/**
* 获取两点间距离
* @param {object} a 第一个点坐标
* @param {object} b 第二个点坐标
* @returns
*/

function getDistance(a, b) {
const x = a.x - b.x;
const y = a.y - b.y;
return Math.hypot(x, y); // Math.sqrt(x * x + y * y);
}

中点坐标公式

设两个点A、B以及坐标分别为A(x1, y1)、B(x2, y2),则A和B两点的中点P的坐标为:

4a36acaf2edda3cce013415d11e93901203f92dc.png

/**
* 获取中点坐标
* @param {object} a 第一个点坐标
* @param {object} b 第二个点坐标
* @returns
*/

function getCenter(a, b) {
const x = (a.x + b.x) / 2;
const y = (a.y + b.y) / 2;
return { x: x, y: y };
}

获取图片缩放尺寸

<img id="image" alt="">
const image = document.getElementById('image');

let result, // 图片缩放宽高
x, // x轴偏移量
y, // y轴偏移量
scale = 1, // 缩放比例
maxScale,
minScale = 0.5;

// 由于图片是异步加载,需要在load方法里获取naturalWidth,naturalHeight
image.addEventListener('load', function () {
result = getImgSize(image.naturalWidth, image.naturalHeight, window.innerWidth, window.innerHeight);
maxScale = Math.max(Math.round(image.naturalWidth / result.width), 3);
// 图片宽高
image.style.width = result.width + 'px';
image.style.height = result.height + 'px';
// 垂直水平居中显示
x = (window.innerWidth - result.width) * 0.5;
y = (window.innerHeight - result.height) * 0.5;
image.style.transform = 'translate3d(' + x + 'px, ' + y + 'px, 0) scale(1)';
});

// 图片赋值需放在load回调之后,因为图片缓存后读取很快,有可能不执行load回调
image.src='../images/xxx.jpg';

/**
* 获取图片缩放尺寸
* @param {number} naturalWidth
* @param {number} naturalHeight
* @param {number} maxWidth
* @param {number} maxHeight
* @returns
*/

function getImgSize(naturalWidth, naturalHeight, maxWidth, maxHeight) {
const imgRatio = naturalWidth / naturalHeight;
const maxRatio = maxWidth / maxHeight;
let width, height;
// 如果图片实际宽高比例 >= 显示宽高比例
if (imgRatio >= maxRatio) {
if (naturalWidth > maxWidth) {
width = maxWidth;
height = maxWidth / naturalWidth * naturalHeight;
} else {
width = naturalWidth;
height = naturalHeight;
}
} else {
if (naturalHeight > maxHeight) {
width = maxHeight / naturalHeight * naturalWidth;
height = maxHeight;
} else {
width = naturalWidth;
height = naturalHeight;
}
}
return { width: width, height: height }
}

双指缩放逻辑

// 全局变量
let isPointerdown = false, // 按下标识
pointers = [], // 触摸点数组
point1 = { x: 0, y: 0 }, // 第一个点坐标
point2 = { x: 0, y: 0 }, // 第二个点坐标
diff = { x: 0, y: 0 }, // 相对于上一次pointermove移动差值
lastPointermove = { x: 0, y: 0 }, // 用于计算diff
lastPoint1 = { x: 0, y: 0 }, // 上一次第一个触摸点坐标
lastPoint2 = { x: 0, y: 0 }, // 上一次第二个触摸点坐标
lastCenter; // 上一次中心点坐标

// 绑定 pointerdown
image.addEventListener('pointerdown', function (e) {
pointers.push(e);
point1 = { x: pointers[0].clientX, y: pointers[0].clientY };
if (pointers.length === 1) {
isPointerdown = true;
image.setPointerCapture(e.pointerId);
lastPointermove = { x: pointers[0].clientX, y: pointers[0].clientY };
} else if (pointers.length === 2) {
point2 = { x: pointers[1].clientX, y: pointers[1].clientY };
lastPoint2 = { x: pointers[1].clientX, y: pointers[1].clientY };
lastCenter = getCenter(point1, point2);
}
lastPoint1 = { x: pointers[0].clientX, y: pointers[0].clientY };
});

// 绑定 pointermove
image.addEventListener('pointermove', function (e) {
if (isPointerdown) {
handlePointers(e, 'update');
const current1 = { x: pointers[0].clientX, y: pointers[0].clientY };
if (pointers.length === 1) {
// 单指拖动查看图片
diff.x = current1.x - lastPointermove.x;
diff.y = current1.y - lastPointermove.y;
lastPointermove = { x: current1.x, y: current1.y };
x += diff.x;
y += diff.y;
image.style.transform = 'translate3d(' + x + 'px, ' + y + 'px, 0) scale(' + scale + ')';
} else if (pointers.length === 2) {
const current2 = { x: pointers[1].clientX, y: pointers[1].clientY };
// 计算相对于上一次移动距离比例 ratio > 1放大,ratio < 1缩小
let ratio = getDistance(current1, current2) / getDistance(lastPoint1, lastPoint2);
// 缩放比例
const _scale = scale * ratio;
if (_scale > maxScale) {
scale = maxScale;
ratio = maxScale / scale;
} else if (_scale < minScale) {
scale = minScale;
ratio = minScale / scale;
} else {
scale = _scale;
}
// 计算当前双指中心点坐标
const center = getCenter(current1, current2);
// 计算图片中心偏移量,默认transform-origin: 50% 50%
// 如果transform-origin: 30% 40%,那origin.x = (ratio - 1) * result.width * 0.3
// origin.y = (ratio - 1) * result.height * 0.4
// 如果通过修改宽高或使用transform缩放,但将transform-origin设置为左上角时。
// 可以不用计算origin,因为(ratio - 1) * result.width * 0 = 0
const origin = {
x: (ratio - 1) * result.width * 0.5,
y: (ratio - 1) * result.height * 0.5
};
// 计算偏移量,认真思考一下为什么要这样计算(带入特定的值计算一下)
x -= (ratio - 1) * (center.x - x) - origin.x - (center.x - lastCenter.x);
y -= (ratio - 1) * (center.y - y) - origin.y - (center.y - lastCenter.y);
image.style.transform = 'translate3d(' + x + 'px, ' + y + 'px, 0) scale(' + scale + ')';
lastCenter = { x: center.x, y: center.y };
lastPoint1 = { x: current1.x, y: current1.y };
lastPoint2 = { x: current2.x, y: current2.y };
}
}
e.preventDefault();
});

// 绑定 pointerup
image.addEventListener('pointerup', function (e) {
if (isPointerdown) {
handlePointers(e, 'delete');
if (pointers.length === 0) {
isPointerdown = false;
} else if (pointers.length === 1) {
point1 = { x: pointers[0].clientX, y: pointers[0].clientY };
lastPointermove = { x: pointers[0].clientX, y: pointers[0].clientY };
}
}
});

// 绑定 pointercancel
image.addEventListener('pointercancel', function (e) {
if (isPointerdown) {
isPointerdown = false;
pointers.length = 0;
}
});

/**
* 更新或删除指针
* @param {PointerEvent} e
* @param {string} type
*/

function handlePointers(e, type) {
for (let i = 0; i < pointers.length; i++) {
if (pointers[i].pointerId === e.pointerId) {
if (type === 'update') {
pointers[i] = e;
} else if (type === 'delete') {
pointers.splice(i, 1);
}
}
}
}

注意事项

由于transform书写顺序并不满足交换律,换句话说transform: translateX(300px) scale(2);和transform: scale(2) translateX(300px);是不相等的。开发时请根据相应的书写顺序做处理。详见下图:

微信图片_20210802192116.png


原文:https://juejin.cn/post/7020243158529212423

收起阅读 »

为什么祖传代码会被称为屎山

有一天,有几条虫子,干扰了老板赚钱,老板希望你能抓住它们。 你带着年轻的锐气,青春的活力,学艺多年积累的程序设计艺术,打开了公司的代码仓库。 远看,似乎一个运转的机器,巨大的代码堆积在一起形成了大致的轮廓,蠕动着前进。 凑近了一看,在不净的框架中,乱码般的语句...
继续阅读 »

有一天,有几条虫子,干扰了老板赚钱,老板希望你能抓住它们。


你带着年轻的锐气,青春的活力,学艺多年积累的程序设计艺术,打开了公司的代码仓库。


远看,似乎一个运转的机器,巨大的代码堆积在一起形成了大致的轮廓,蠕动着前进。


凑近了一看,在不净的框架中,乱码般的语句在运转,像生了麻风病的蛞蝓一样在喷吐,粘稠的水在流动,而穿着格子衫的人群则在焰柱旁围成了一个半圆,这就是码农的仪式。他们环绕着那不可名状植物,不断的伸手进去拨弄,又不断的掏出一些东西填上去,使他堆积的更高,为了防止到他,又掏出黏糊糊的糊糊,用力的涂抹,试图把它们黏在一起。


这是一个前人留下的屎堆起来的一个克苏鲁缝合怪,看起来摇摇欲坠,有无数的虫子爬来爬去。但勉强堆起了山一样的形体,蠕动着为老板赚钱。



你满心热血,要对这座山进行清理,使它成为一个鲁棒的钢铁巨兽,可以随时更换最新的部件,奔腾如飞,坚固异常,带着兄弟们走向人生巅峰。


你经过缜密的分析,顺着虫子留下的痕迹,终于找到了问题的源头,发现一坨很多年前某码农因为时代局限或者水平有限拉的陈年旧屎,你觉得只要对它改良一下,梳理清楚结构,加强判断与容错,就可以变化成一个钢铁部件,让这坨怪物离巨兽更近一步。


你用力的挖掘其中的信息,却发现,事情没有那么简单,这一坨实际上不是孤立的一坨,而是和整个山体融合在一起。或者说,这座山实际上是一坨坨粘稠滑腻的克苏鲁,通过无数的触角和粘液连接在了一起,这些克苏鲁伸出无数的触角,伸进这座山体中未知的角落。


有看起来结构相同,但是出现了几十上百次的重复逻辑。有无数道不知道伸向何处的判断分支。有七零八落到处都是又无法解释的神秘数字。有从表面直接伸向最底层的神秘调用。还有猜不出,看不懂,无法预计什么时候会触发,什么时候会爆发的无数定时器。还有无数神秘的线程在独立的挂在那里,猜不出哪个什么时候会忽然启动,什么时候会忽然挂起,什么时候会忽然互相抢资源而死锁,哪些资源会莫名其妙的被改动。神秘的链接,神秘的任务队列,神秘的池,神秘的环形缓存,神秘的堆栈。


他们耦合在一起,互相支撑,构成了一坨更大的克苏鲁屎怪,缓慢的蠕动。


你极其困难的清理和修改了其中的一点点内容,让这一点点的内容脱离出耦合态,看起来清晰一点。结果,忽然屎山对面十万八千行外,你永远意想不到的一块功能,忽然挂了。一个你完全在工作上没接触过的同事,通过他的盘查,发现是他维护的一个函数/方法、类、线程、内存块,池,和你改动的部分是深度耦合的,你的解耦导致了难以理解的错误使他们的部分产生了错误。于是你被骂了,你只能再退一步,在一个更小的范围内进行调整,但是发现,虫子不止是由这一块构成的,于是你追踪者虫子的足迹,去改良一个一个的模块。


在经历了一轮又一轮的批评,几乎结识了全公司所有模块的负责人之后,你终于抓住了一条虫子。但是在这个漫长的过程中,你早已忘却初心。在无数次的赶工加班熬夜的迷糊中,被同事老板挨骂后的愤懑中,表白失败/和女朋友吵架/发现自己头顶有点绿的低落中;无数次当做临时代码写下,计划单元测试完成后就重写却忘记的过程中,因为偷懒或者不舍得打断思路而而懒得抽出轮子而产生的超大代码块中。


留下了无数看起来结构相同,但是出现了几十上百次的重复逻辑。无数道不知道伸向何处的判断分支。大量的无法解释的神秘数字。从表面直接伸向最底层的神秘调用。猜不出,看不懂,无法预计什么时候会触发,什么时候会爆发的无数定时器。无数猜不出哪个什么时候会忽然启动,什么时候会忽然挂起,什么时候会忽然互相抢资源而死锁,莫名其妙改动资源的神秘线程。神秘的链接,神秘的任务队列,神秘的池,神秘的环形缓存,神秘的堆栈。


你要抓的哪条虫子确实抓出来了。然而,在你没看到的地方,随着运转,更多的新的虫子正在茁壮的成长。


这时,你突然发现你的脚抽不出来了,几条触手顺着你的腿向上攀延,你的手被深深地吸入泥沼一样的屎山,你使尽全力想要抽出胳膊,但越是挣扎,陷得越深,仿佛屎山中心有一个冰冷的黑洞,要将所有接近的物体吞噬殆尽。你的精气在一点点流失,一种极度的疲惫,但是又释然的感觉涌了上来。此刻,你觉得舒适又满足,渐渐地闭上了双眼,你甘愿奉献头发与生命,将自己化作一块补丁,维系着系统的苟延残喘。它再也没法离开你了,你和你的头发,成了它的一部分。


不知道过了多久。终于又有一条虫子在运行中暴露,干扰了老板赚钱。


老板又安排了一个年轻人来抓住这条虫子。这个年轻人带着锐气,青春和活力来到这座山前。


看到这摇摇欲坠的克苏鲁大山,不仅倒吸一口冷气。


“oh shit ! shit mountain !”



作者:码农出击666
链接:https://juejin.cn/post/7045924498461163533

收起阅读 »

[翻译]你不可错过的 10 个 Xcode 技巧和快捷键

iOS
原文地址:10 Tips and Shortcuts You Should Be Using Right Now in Xcode 原文作者:Mike Pesate 译文出自:掘金翻译计划 本文永久链接:github.com/xitu/gold-m… 译者:F...
继续阅读 »


你不可错过的 10 个 Xcode 技巧和快捷键


Image source: Author


在我作为 iOS 开发人员的职业生涯中,养成了一些使得工作变得更加轻松快捷的 Xcode 习惯。很多好用的快捷键一直都存在,只是我们没有发现而已。


所以我收集了一些我最喜欢的,在这里和大家分享。


我们开始吧!


1. 快速自动缩进


当你的代码没有对齐时,这个快捷键非常有用。



control + i / ⌃ + i



它会自动缩进光标所在的行。如果你选中了一些代码,甚至整个文件,这个快捷键就会调整选中部分的缩进。


Demo of ⌃ + i


这对及时保持代码整洁非常有帮助。


2. 在所有作用域中修改


假设你发现某个方法或变量名有错误,你想要修复它。当然你不会一个个去修改,因为你知道有重构(Refactor)功能可以批量重命名,但有时候 Xcode 的重构功能可能不太靠谱。


此时你可以使用以下快捷键,选中当前文件中所有用到该变量的位置。



command + control + e / ⌘ + ⌃ + e



这将选中所有用到这个变量的位置,让你可以非常方便地更改变量名。


Demo of ⌘ + ⌃ + e


3. 查找下一个


现在,假设你不想在所有作用域中修改变量名称,而只想找到下一处;或者只想在一个函数中重命名,而不是整个类中,或者其他类似情况。有一个(和上面)非常相似的快捷键。



option + control + e / ⌥ + ⌃ + e



Demo of ⌥ + ⌃ + e


当你选中某个字符串,按下这个快捷键,Xcode 将选中下一个出现该字符串的位置。但这意味着,如果某些变量和函数同名,则下一个选中的,也许和你预期的不一样。(译注:这里指的是,并不判断是否真的是同一个变量,只是单纯的字符串匹配)。


4. 查找上一个


上面我们介绍了“查找下一个”,再多按一个键,则变成了“查找上一个”。



shift + option + control + e / ⇧ + ⌥ + ⌃ + e



Demo of ⇧ + ⌥ + ⌃ + e


5. 整行向上或向下移动


我们可能会对代码进行一些顺序调整,当然可以用经典的“剪切粘贴”,但如果我们只想将代码向上移动一行或向下移动一行,那么以下快捷键肯定会对你有所帮助。


向上移动:



option + command + [ / ⌥ + ⌘ + [



向下移动:



option + command + ] / ⌥ + ⌘ + ]



Demo of ⌥ + ⌘ + [ and ⌥ + ⌘ + ]


额外提示!你可以移动多行


如果选中多行之后再使用前面的快捷键,那么这些行将作为一个整体进行移动。


Demo of previous shortcut moving several lines as block


6. 多行光标(使用鼠标)


有时你需要在文件的不同部分中写入相同的内容,你很烦恼,因为你必须编写一次并复制粘贴几次。好吧,别再烦了。你可以使用一个快捷键同时写入多行。



shift + control + click / ⇧ + ⌃ + click



Demo of ⇧ + ⌃ + click


7. 多行光标(使用键盘)


此快捷键与上一个基本相同,但是我们不是使用鼠标来选择光标的位置,而是使用箭头向上或向下来移动光标。



shift + control + up or down /⇧ + ⌃ + ↑ or ↓




8. 快速创建带有多个参数的初始化(init)函数


上面的快捷键,我最喜欢用法之一,就是快速创建一个初始化函数,比之前的任何方法都快。



通过使用多行光标,配合其他一些快捷键,例如复制粘贴或选中整行,我们可以快速创建初始化函数。这只是这个按键的几种用途之一。


8.1 另一种方式


还有一个编辑功能,可以让你轻松地生成 “成员初始化器”(Memberwise Initializer)。你可以将光标放在类的名称上,然后找到 Editor > Refactor > Generate Memberwise Initializer。


但是,由于本文介绍快捷键,所以这里给一个小提示:可以进入 Preferences > Key Bindings,再查找对应命令,并添加快捷键。


这是操作示例:


How to add a key binding


9. 返回光标之前所在的位置


有时候你需要处理很大的文件,向上滚动查看某些内容之后,可能很难找到原来位置。有了这个快捷键,只要我们没有将光标移开,我们就可以快速跳回之前的位置。



option + command + L / ⌥ + ⌘ + L



Demo of ⌥ + ⌘ + L


10. 跳到某一行


和上一条相关,如果我们知道要跳转的那一行的行号,那么使用此快捷键,我们可以直接跳到该行。



command + L / ⌘ + L



Demo of ⌘ + L


最后的想法


这些就是我每天用来高效使用 Xcode 的十个快捷键和技巧。他们经常会派上用场。


我希望他们对你也一样有用。


如果你已经知道了这些快捷键,或者还不知道,都可以与我交流,我会很高兴。也欢迎和我分享你用到的其他有用的快捷键。


小贴士


理想情况下,你可以使用同样的快捷键,来实现前面提到的所有技巧。但是也可能取决于你的操作系统语言设置,其中一些可能略有不同。


你可以在 Xcode > Preferences… > Key Bindings 中查看特定快捷键的按键组合。


额外提示! 快速打开偏好设置(Preferences)



command + , / ⌘ + ,




如果发现译文存在错误或其他需要改进的地方,欢迎到 掘金翻译计划 对译文进行修改并 PR,也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。







作者:FranzWang
收起阅读 »

Xcode 13 更新了哪些内容

iOS
直接进入主题。外观对比 Xcode 12,风格和显示都发生了变化:去掉了文件拓展名图标也可以识别文件类型自动调整了导航栏布局重新进行了分布和调整右下角增加了光标所在行列数文件拓展名设置:打开 设置 - 通用 选择 Fil...
继续阅读 »

直接进入主题。

外观

005XGWPvly1gun3djnsn4j627y1cku0x02

对比 Xcode 12,风格和显示都发生了变化:

  • 去掉了文件拓展名
  • 图标也可以识别文件类型自动调整了
  • 导航栏布局重新进行了分布和调整
  • 右下角增加了光标所在行列数
文件拓展名设置:

打开 设置 - 通用 选择 File Extensions

image-20210920152905766

文件拓展名的显示隐藏控制,选项有三种:

image-20210920153816172

  • Hide All:隐藏全部拓展名

  • Show All:显示全部拓展名

  • Show Only:自定义显示拓展名 ↓↓↓↓

    QQ20210921-024658-HD

    问题提醒设置:

    在 设置 - 通用 里还多了一个 Xcode 12没有的选项:Issues,对应的子选项为:Show InlineShow Minimized

    Show InlineShow Minimized
    image-20210920155859979image-20210920155918641

    对比 Show InlineShow Minimized 把问题提醒最小化到了右侧,当开发者点击对应的问题时,会显示出来。

    优点一目了然,界面整洁,没有一堆提示文字和红蓝色。

    缺点则是无法直接的查看问题原因,即使是点击出来,也没有像前者那样直接的把问题精准的定位具体代码中。

    image-20210920160709412

    不过这个也不能够算是缺点,只是说提示的没有那么的明显,这点根据个人喜好选择就行。

    info.plist

    info.plist 文件内容减少,甚至使用 SwiftUI 创建项目,已经移除了 info.plist 文件,真是把简洁做到了极致

    Storyboard 创建SwiftUI 创建
    image-20210921172421609image-20210921173002487

    当然,只是当前 info.plist 文件没有显示之前的内容,在 Project - Target - Info 下,对应的信息还是存在的,且如果你在 info.plist 文件内新增了的话,依旧会在 Project - Target - Info 下显示出来的。

    至于 SwiftUI 下没有 info.plist 文件,开发者可以自行创建,具体方式可以看这里

    我不能接受

    有一个地方的改变我不能接受,那就是:编译成功失败的提醒框没有啦

    Xcode 12Xcode13
    005XGWPvly1gun4lqd89kg60ig0b80vi02005XGWPvly1gun4lsjs0jg60ig0b841m02

    Xcode 13 中,不管是编译还是运行,都没有了最后的提示框。在设置中也没有找到对应的选项。

    对于我这种经常写 Bug 的人来说,看不到弹出来的 Build Succeeeded,简直是要命。苹果你赶紧给我改回来...

更新:

评论区小伙伴给出解决方案:通知栏会提示编译成功或者失败的提示。

感谢指出,Xcode 13 版本之前也有这个提示, 我一直都忽略了这个地方,平时都把大多数应用的通知都给关了。

让我意外的是:我自己的笔记本 设置 - 通知 里面竟然没有找到 Xcode 这个应用。。。我又不会玩了~

自动补全

import

在开发过程中,经常会出现没有导入头文件就开始直接调用文件,这个时候就会比较尴尬,特别是当代码行数比较多的时候,要先回到顶部导入头文件,再回来继续写,有时候甚至都找不到刚才的位置在哪了...

Xcode 13 解决了这个问题,当你使用一个没有导入头文件的库时,会智能帮助你导入对应的头文件,非常 nice

QQ20210920-163257-HD

switch

Xcode 13 以前,使用 switch 调用枚举的时候,如果想快速调出全部的 case,就只能输入代码后等着 Xcode 给你提示 Switch must be exhaustive 然后 Fix 加载全部的 case

QQ20210920-172130-HD

Xcode 13 中,你是需要正常输入代码,就会自动的显示出来了

QQ20210920-171833-HD

摸鱼的时间又增加了

不过并不是所有的情况都支持,在使用接口请求的时候,回调的Result 类型目前就无法自动补全,只能手动输入。不知道是苹果故意为之还是。。。。

QQ20210920-172656-HD

if / guard let

Xcode 13 中,使用 if 、guard 判断一个 Optional 参数的时候,也会同名自动补全。就很舒服

QQ20210920-173543-HD

for

使用 for...in 循环语句遍历一个数组的时候,Xcode 13 会根据数组名自动生成子元素名自动补全循环

QQ20210920-175028-HD

当然,即使你输入的数组名不是那么的标准,Xcode 也还是会根据它自动识别的进行补全,比如:如果你的数组名是 number 而不是 numbers 的时候,Xcode 的自动补全依旧是 for number in number。所以,还是尽量保证代码命名的正确性吧。

列断点

Swift 链式语法在开发过程中会使代码变得非常美观和整洁,与之带来的部分问题也会出现,就是无法直观的看到每块代码的具体值,每次想查看的时候只能通过声明一个新的变量来赋值查看,这很不Swift

Xcode 13 可以使用给每行代码的任意位置设置断点,通过打印日志来查看详细内容。

可能对于这个 列断点 描述的不是太清楚。可以通过具体操作来了解。

首先创建 列断点:再所选代码位置右键 - Show Code Actions - Create Column Breakpoint

QQ20210920-182540-HD

列断点 跟之前的 行断点 一样,可以 单击、双击、和拖拽。对应的功能也一样。

运行代码,在断点位置处,通过打印日志查看:

QQ20210920-183129-HD

这个功能增加的蛮不错的。

vim

现在你可以从 Xcode 13 中使用 vim 模式来编写代码了。

beta 5 版本中,通过 Editor - Vim Mode 来开启和关闭 vim 模式了。

开启后,Xcode 底部会有对应的快捷键提示。非常友好

image-20210921022842159

其他

除了以上这些之外,Xcode 13 还增加和完善了很多的功能,比如:优化了版本控制功能、新增了 Xcode Cloud 和可以直接在 Xcode 中构件展示官方文档了等等..

image-20210921024217111

更多更详细的内容就需要各位开发者自己亲自去研究和探索了。

总结

相对于之前的版本来说,Xcode 13 看起来让人感觉更加的舒服了,不管是文件风格还是展示形式都显得干净简洁。

当然安装包也还是那么大、还是那么的吃内存。无解~

目前使用起来还是比较顺手的,就是赶紧把编译提醒框退回来,不然每次 command + B 后都要网上看,多别扭。

收起阅读 »

升级到xcode13碰到的问题

iOS
经过了半个月的时间, xcode 没有暴露出来大的 BUG , 可以安心的升级了 然后问题来了, 各种适配问题, 开始撸起来 问题 : The Legacy Build System will be removed in a future release...
继续阅读 »

经过了半个月的时间, xcode 没有暴露出来大的 BUG , 可以安心的升级了


Xcode版本


然后问题来了, 各种适配问题, 开始撸起来



  1. 问题


: The Legacy Build System will be removed in a future release. You can configure the selected build system and this deprecation message in File > Workspace Settings.


错误详情


解决方案:



菜单栏 File->Workspace Settings-> BuildSystem

选择使用 New Buile System(Default)


错误详情



  1. 问题, 文件引入问题(Xcode12之前没有问题)



Multiple commands produce '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/PEDat_wb.bundle':

1) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/WBCloudReflectionFaceVerify_framework/Resources/PEDat_wb.bundle' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/PEDat_wb.bundle'

2) That command depends on command in Target 'dudu' (project 'dudu'): script phase “[CP] Copy Pods Resources”

Multiple commands produce '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/WBCloudReflectionFaceVerify.bundle':

1) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/WBCloudReflectionFaceVerify_framework/Resources/WBCloudReflectionFaceVerify.bundle' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/WBCloudReflectionFaceVerify.bundle'

2) That command depends on command in Target 'dudu' (project 'dudu'): script phase “[CP] Copy Pods Resources”

Multiple commands produce '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/detector_wb.bundle':

1) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/WBCloudReflectionFaceVerify_framework/Resources/detector_wb.bundle' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/detector_wb.bundle'

2) That command depends on command in Target 'dudu' (project 'dudu'): script phase “[CP] Copy Pods Resources”

Multiple commands produce '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/ufa_wb.bundle':

1) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/WBCloudReflectionFaceVerify_framework/Resources/ufa_wb.bundle' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/ufa_wb.bundle'

2) That command depends on command in Target 'dudu' (project 'dudu'): script phase “[CP] Copy Pods Resources”



解决方案:



target->Build Phases

具体如图, 报错的文件就行了



错误详情



  1. 问题: info.plist 文件问题, 由于项目中使用的库手动拉进来的,



Multiple commands produce '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/Info.plist':

1) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/dudu/Libs/AliyunOSSiOS/Info.plist' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/Info.plist'

2) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/dudu/SupportingFiles/Info.plist' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/Info.plist'

3) Target 'dudu' (project 'dudu') has process command with output '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/Info.plist'



解决方案:



直接删除手动拉进来的库里面的 `info.plist` 文件




  1. 项目里面有个 VERSION 的文件, 想不明白这个为啥



Multiple commands produce '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/VERSION':

1) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/dudu/Libs/ST_Mobile/SenseArSourceService/VERSION' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/VERSION'

2) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/dudu/Libs/ST_Mobile/VERSION' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/VERSION'



解决方案:



修改一下 `VERSION` 的文件名称: 或者删除文件




  1. 处理了上面的问题, 依旧还是有问题, 接着修改



Multiple commands produce '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/Info.plist':

1) Target 'dudu' (project 'dudu') has copy command from '/Users/imac/Desktop/dudu_dev/dudu/dudu/SupportingFiles/Info.plist' to '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/Info.plist'

2) Target 'dudu' (project 'dudu') has process command with output '/Users/imac/Library/Developer/Xcode/DerivedData/dudu-awglbcqfapsmfngrajrwibtvgoph/Build/Products/Debug-iphoneos/dudu.app/Info.plist'



解决方案:



1. 找到 Products 文件夹下的 项目, 邮件 show in finder, 然后向上找, 找到 DerivedData 文件下, 删除对用的文件

到这里这个问题应该已经修复了, 如果还有问题, 继续

2. Build Settings 里面 找到 info.plist 文件夹的位置, (先复制一下路径) 删除, 编译一下, 然后再添加上路径

如果还是不行:

3 Build Phases 里面 Copy Bundle Resources 删除 info.plist 文件



错误详情


好了, 到现在, 我的项目已经能正常运行了,


在翻阅的时候发现 JWAutumn 同学的文章 Xcode 13 更新了哪些内容 这个文章已经更新的比较全了, 可以参考一下


不知道有没有碰到其他问题的, 可以私信我一下, 给加在上面, 供大家参考




  1. Xcode 编译结果的提示, 中间的 Build Successed 和 小锤子不出来了, 没找到在哪里能修改的, 只能在软件上面提示, 感觉习惯了小锤子的提示, 这个修改感觉很不友好




  2. XcodeSnippets (就是自定义的代码块) 不自动提示了, 需要将自定义的名称打全才出来提示 , 比如: 设置的 mark 只有全部打出来才提示代码块, 不然不提示, 也是不友好, 目前没发现在哪里可以提示的




  3. 以前修改的文件, 当前文件的名字变灰, 知道编译后有哪些文件修改过了, 现在直接没了, 没找到哪里设置的 (这个修改很不友好)







作者:Keya
链接:https://juejin.cn/post/7016195057266999304

收起阅读 »

Xcode调试技巧总结

iOS
前言 本来觉得调试是一件很简单的事情,但是看了很多介绍调试方法的文章,发现有些技巧并不知道,有必要对常用的Xcode调试技巧做一个总结,提高工作效率。 一、调试面板 上方:断点开关、继续执行、单步执行、单步步入、单步步过等命令; 左边:watch窗口,负责变...
继续阅读 »

前言


本来觉得调试是一件很简单的事情,但是看了很多介绍调试方法的文章,发现有些技巧并不知道,有必要对常用的Xcode调试技巧做一个总结,提高工作效率。


一、调试面板


image.png


上方:断点开关、继续执行、单步执行、单步步入、单步步过等命令;

左边:watch窗口,负责变量信息显示,如果想查看寄存器的内容,可以将左下角的Auto切换为All

右边:日志窗口,接受和显示程序日志,左下角可以选择All/Debugger/Target output


二、断点


1- 普通断点


找到下断点的代码行,可以通过下面3种方式下断点:

(1)导航栏:Debug->Breakpoint->Add Breakpoint at Current Line

(2)快捷键:command +

(3)鼠标:直接在编辑区域左边行号的地方左键


大部分情况普通断点就满足需求了,但是对于一些特殊的调试情况,还需要掌握一些其他类型的断点。


2- 条件断点


适用场景

(1)一个函数重复多次被调用,但是只需要调试其中某一次的情况时;

(2)对于一些因为异常数据导致的bug调试也很实用;

下断点: 右键普通断点 -> Edit Breakpoint,条件断点和普通断点相比只是多了一个条件判断而已,和我们手动在断点代码加一个if条件判断效果一样,只有满足条件的情况才会断下来;


image.png


3- 符号断点


符号断点: 其实就是对一个特定的函数名下断点,这里的方法可以是OC方法或者C++函数名;

适用场景: 调试一些没有源码的模块时比较有用,比如调试一个第三方提供的Lib库,或者系统模块,可以给相应函数下断点,调试程序的运行流程,查看一些参数信息;

下断点 :断点Tab页 -> 点击下面+号 -> Symbolic Breakpoint


image.png


image.png


设置符号断点可以输入类名+函数名,也可以只输入函数名,xcode会自动匹配不同类中同名的方法进行断点,如下DJTPerson和DJTAnimal都有-(void)djt_run方法,会自动生成两个断点,一旦被调用就会命中断点:


image.png


4- 异常断点


适用场景: 异常断点用来调试程序抛出异常而导致退出,下个异常断点很快就能定位运行到那行代码出了问题;

下断点: 断点Tab -> 左下角+号 -> Exception Breakpoint

Exception Breakpoint也是可以编辑的,可以选择Exception类型,也可以选择在抛出异常或者捕获异常的时候断点等;


image.png


注:有的程序会使用异常来组织程序逻辑,比如微信扫一扫,所以如果Exception选了All,那么异常断点会频繁触发,所以这种情况可以只选择Objective-C异常。


下面是一个异常断点,在DJTPerson类中只有djt_run方法的声明没有实现,触发断点:


image.png


5- watch断点


顾名思义:watch断点就是当某个变量发生改变时触发的断点;

适用场景: watch断点对于要跟踪某个变量或者某个状态的变化时非常有用的,可以方便的跟踪到哪些地方改变了变量的值。

下断点: 在xcode的watch窗口 -> 右键需要watch的变量 -> watch "Xxx":


image.png


如例子中,当_name变量发生变化时调试器会自动断下来,同时输出变化信息:
image.png


6- 线程断点


线程断点: 线程断点适用在调试多线程代码的时候,一段代码可能会被多个线程同时执行,如果下普通断点,那么你会在不同线程之间切来切去,最后自己都迷糊了,这个时候可以使用多线程断点。

下断点: 调试区域右边控制台输出 -> breakpoint set –f 文件名 –l 行号 –t 线程id


下面例子在28行设置普通断点,就可以在控制台打印 thread-id,控制台输入:


thread info

获取当前线程id,在控制台通过命令行给32行设置线程断点:


breakpoint set -f ViewController.m -l 32 -t 0x331854

image.png


7- 断点后的Action


断点后的Action: 当断点被触发可以执行的一些操作;

下断点: 右键断点 -> Edit Breakpoint -> Add action


action类型很多,有调试命令、apple script、shell script等:

image.png


下边是在运行到断点后po一下person.name,直接打印了name的值:
image.png


如果觉得仅仅输出对象信息不够,还想加一些自己指定的内容,可以使用Log Message。


image.png


三、常用命令


1- p命令


p命令:查看基本数据类型的值

po命令:查看oc对象

简单查看一个变量或者OC对象的值在watch窗口完全可以满足,但是如果需要查看一个oc对象的属性,或者一个oc对象方法的返回值怎么办呢?p和po命令后面都可以接相应的表达式,如:


image.png


2- expr命令


expr命令:全称expression,可以在调试时动态修改变量的值,同时打印出结果。使用expr命令动态修改变量的值,可以在调试的时候覆盖一些异常路径,对调试异常处理的代码很有用。


image.png


3- call命令


call命令用来动态调用函数,可以在不增加代码不重新编译的情况下动态调用一个方法。下例动态将view1从父view移除:


image.png


4- image命令


image命令可以列出当前app中的所有模块,可以查找一个地址对应的代码位置,在调试越狱插件时,可以用image list命令查看越狱插件是否注入自己的App。当遇到crash时,查看线程栈只能看到栈帧的地址,使用image lookup -address 地址命令可以方便的定位这个地址对应的代码行。


5- bt命令


bt命令可以查看线程的堆栈信息,该信息也可以在导航区的Debug Navigator看到;

bt:打印当前线程栈
bt all:打印所有线程栈


image.png


分割线:上边介绍了基本的调试技巧,下面是一些不同场景下的调试经验


四、多线程


场景:在调试的时候bug不出现,一旦关闭调试直接运行bug就出现:这种问题大部分是因为多线程bug,而调试影响了多线程的执行顺序。

技巧:这种问题可以在关键点输出log,之前介绍的断点action中的Log Message就派上用场,这样的好处是不需要在代码中添加冗余的log即可调试;在调试多线程问题时,合理使用线程断点和条件断点也是很有帮助的;


五、UI调试


1-控件信息


查看控件信息除了使用p和po命令,还可以使用expr命令修改控件属性,如内容、坐标、大小等,这样可以不重启程序看到界面的变化;


2-界面结构


查看界面结构:po [view recursiveDescription],该命令可以打印出view的所有子view的结构关系,对于调试界面层级关系很有用;


3-快速预览


xcode支持在调试时对变量进行快速预览,调试时将鼠标放在变量上,然后点击快速预览按钮即可看到控件的显示。


image.png


4-符号断点跟踪UI变化


对于一些系统控件的信息,如果发现最终显示和自己设置的不一样,可以使用符号断点,在一些设置函数下断点,这样就可以很清晰的看到是从哪里改变了这个属性的值。比如一个UIButton的title在显示的时候和设置的不一样,只需要符号断点设置setTitle就可以跟踪哪里改了值;



作者:D___
链接:https://juejin.cn/post/6950852311346315271

收起阅读 »

我做了一款vuepress的音乐可视化播放插件

体验地址:博客,github,npm前言博客上的音乐播放器,大多都长一个样,小小的,塞在页面的一个角落里,在别人阅读文章的同时可以听音乐,增加某些体验的满意指数。而我,做了一件不太一样的事情:博客不就是让人看文章的么?再播放音乐甚至有可能会降低阅读的质量,那听...
继续阅读 »



体验地址:博客githubnpm

前言

博客上的音乐播放器,大多都长一个样,小小的,塞在页面的一个角落里,在别人阅读文章的同时可以听音乐,增加某些体验的满意指数。而我,做了一件不太一样的事情:

博客不就是让人看文章的么?再播放音乐甚至有可能会降低阅读的质量,那听歌就好好听歌不好么?既然要体验,那就沉浸体验到爽不好么?

某天,偶然打开了豆瓣FM网页版,很符合豆瓣的感觉,干净简洁,当然网上类似的音乐播放有很多,这里为我后面做的事情埋下了伏笔。

我博客是用 vuepress 搭建的,主题是 vuepress-reco,最开始想找一个播放音乐的插件,于是去找了 awesome-vuepress,搜到唯一和音乐相关的插件,只有一个叫:vuepress-plugin-music-bar 的插件.....还是个bar....有点失落。于是,没人做?那...我做个试试?最终的效果图就是上面看到的四张图了:亮/暗系歌词,亮暗系可视化解码。在看完 vuepress 官网的插件api,就开始搞了!

开搞

不管怎么画页面,初衷是沉浸式体验,找了很多播放器的大体结构,还是觉得网易云的播放界面算比较舒服的,自己也有尝试画过脑海里的播放界面,但是最终还是选择用网易云的效果(拿来吧你):左侧黑胶唱片滚动,右侧歌词滚动, 目前不需要上一曲下一曲,就有播放和分享按钮,也就是长这个样子:

一天半时间,匆匆忙忙做完之后,npm link 调试成功就发了一版npm包。好用?不好说。能不能用?能!

优化

做到这里之后,沉浸式有那么点感觉了,体验?照搬过来就是好的体验么?不,还是要加点东西,比如可视化

这里特别感谢网易云大前端团队的一篇文章:Web Audio在音频可视化中的应用,基本上照着看下来,里面的文献也看一下,就可以做出来上面的效果。说实话,文献是真头大....波长,正余弦,频域时域,奈奎斯特定理,还有什么快速傅里叶变换,头发在偷偷的掉...顺便附上一张某个文献的截图:

不过不看这些也可以做出来!

基本上的思路就是:

  1. 创建 AudioContext,关联音频输入,进行解码、控制音频播放和暂停

  2. 创建 analyser ,获取音频的频率数据(FrequencyData)和时域数据(TimeDomainData)

  3. 设置快速傅里叶变换值,信号样本的窗口大小,区间为32-32768,默认2048

  4. 创建音频源,音频源关联到分析器,分析器关联到输出设备(耳机、扬声器等)

  5. 获取频率数组,转格式,然后用 requestAnimationFrame 通过 canvas 画出来

这些东西上面的文章里讲的很详细,我这种门外汉就不多说啥了。

遇到的问题

npm link

之前使用 npm link 的时候,依赖包没有三方/四方的依赖,所以没注意到,如果开发的npm包带有别的依赖,那么调试的时候要在主项目里的 package.json 先加上这些包,就不会报错说 resolve 失败什么的了,调试结束记得 npm unlink 断开。

接口

本来想用的是 网易云音乐 NodeJS 版 API,但是有些东西不好找,比如我需要歌曲id,封面和歌词,但是文档里没有歌曲id反查专辑id的(封面在专辑id里),只有一个歌曲详情的,但是这个接口,还需要认证跳转....对于使用者来说,我没必要让使用者多这么一步操作,而且很容易出错。于是就换了一个api:保罗API,这个API可以解析的网易云歌曲不是那么的多,不过一般的够了,唯一的缺点就是,多频次刷新会一直 pending,应该是后端设置了ip频次。

既然都有问题,不使用接口行么?尝试找一种 mp3 文件解析出来歌词和封面呢?找到一个 jsmediatags 的仓库,可以解析ID3v2,MP4,FLAC等字段,但是.....这不就是给用户添加麻烦么?需要找专辑,歌词,歌曲,艺人信息全部合一的音源文件....如果我是用户,我不会用它。

翻来覆去,最终还是决定,歌曲用户传进来,然后再传一个歌曲id,封面和歌词走接口,歌曲就是传进来的音源链接,使用方法如下:

<MusicPlayer musicId="xxx" musicSrc="xxx.mp3" style="margin:0 auto">

音源我个人建议要么放vuepress的静态资源,要么就搞成类似图床一样的音源仓库,这样也好维护。

后期想办法优化吧。

主题色

亮系和暗系是适配 vuepress-reco 的主题切换做的适配。

结尾

灵感来自 豆瓣FM,结构参考了昊神的 音乐播放器,可视化播放参考了 Web Audio在音频可视化中的应用,接口感谢 保罗API,这么一说我好像也没做什么事.....

该插件已发npm包,awesome-vuepress 仓库也已收录,可能多少还会有点体验上的小问题,会慢慢修复的。大家也可以提建议,能听进去算我输!

项目写的匆匆忙忙,希望可以做一点更有深度的东西吧——致自己。


作者:道道里
来源:https://juejin.cn/post/7045944008190722079

收起阅读 »

微信小程序反编译获取源码

文章目录 前言一、前置条件二、操作步骤1.进入adb shell2.提取源码编译文件3.反编译前言 对微信小程序进行源码反编译,一般目的为:获取js签名算法,过数据包的防篡改策略获取接口的判断逻辑,一般用于修改返回包来达到未授权的效果,在尝试无法找到争取的返回...
继续阅读 »



文章目录

前言

对微信小程序进行源码反编译,一般目的为:

  • 获取js签名算法,过数据包的防篡改策略

  • 获取接口的判断逻辑,一般用于修改返回包来达到未授权的效果,在尝试无法找到争取的返回值的时候,需要从源码来进行构造

本文旨在记录如何对一个微信小程序进行编译获取其源码,后续分析不做分享,因目的不同,分析的方式也会不同

一、前置条件

需要一台root了的安卓测试手机,root的方式请自行查找。如果是红米手机,可以参考我的root方式,博客链接

本文演示的步骤,基于macbook m1进行,其他设备操作基本也差不多

二、操作步骤

1.进入adb shell

命令如下(示例):

(base)   ~ adb shell
davinci:/ $ whoami
shell
# 提权
davinci:/ $ su root
davinci:/ # whoami
root

2.提取源码编译文件

代码如下(示例):

davinci:/ # cd /data/data/com.tencent.mm                                                                                                               
davinci:/data/data/com.tencent.mm # ls
982178cdd5589cb042c4efb99be0333c  WebNetFile                        ipcallCountryCodeConfig.cfg  recovery        version_history.cfg
CheckResUpdate                    appbrand                          last_avatar_dir              regioncode      webcompt
ClickFlow                         autoauth.cfg                      luckymoney                   snsreport.cfg   webservice
CompatibleInfo.cfg                channel_history.cfg               media_export.proto           staytime.cfg    webview_tmpl
CronetCache                       configlist                        mmslot                       systemInfo.cfg
NowRev.ini                        deviceconfig.cfg                  mobileinfo.ini               textstatus
ProcessDetector                   ee1da3ae2100e09165c2e52382cfe79f  newmsgringtone               tmp
WebCanvasPkg                      heavy_user_id_mapping.dat         patch_ver_history.bin        trace

重点关注一个很长的用户随机码,比如ee1da3ae2100e09165c2e52382cfe79f和982178cdd5589cb042c4efb99be0333c,分别访问判断即可

davinci:/data/data/com.tencent.mm/MicroMsg # cd ./982178cdd5589cb042c4efb99be0333c/                                                        
davinci:/data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c # cd appbrand/                                                          
davinci:/data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c/appbrand # ls
pagesidx  pkg  web_renderingcache
davinci:/data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c/appbrand # cd pkg/  
davinci:/data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c/appbrand/pkg # ls
_-1223314631_166.wxapkg  _-1991183043_171.wxapkg  _-86252332_166.wxapkg   _1233860900_205.wxapkg  _1233860900_230.wxapkg  _2106768478_166.wxapkg
_-1223314631_167.wxapkg  _-289032338_166.wxapkg   _-86252332_167.wxapkg   _1233860900_206.wxapkg  _1233860900_231.wxapkg  _2106768478_171.wxapkg
_-1223314631_168.wxapkg  _-289032338_167.wxapkg   _-86252332_168.wxapkg   _1233860900_207.wxapkg  _1233860900_232.wxapkg  _288413523_8.wxapkg

这些wxapkg即编译后的小程序源码,为了准确找到目标小程序对应的wxapkg文件,可以重新访问目标小程序,之后对这些包进行排序,找到最新的

davinci:/data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c/appbrand/pkg # ls -lt                                                    
total 238092
-rw------- 1 u0_a239 u0_a239   907997 2021-12-26 15:25 _255193015_171.wxapkg
-rw------- 1 u0_a239 u0_a239   427489 2021-12-25 09:37 _1245338104_171.wxapkg
-rw------- 1 u0_a239 u0_a239   258272 2021-12-25 09:35 _2106768478_171.wxapkg
-rw------- 1 u0_a239 u0_a239   745490 2021-12-25 09:35 _927440678_171.wxapkg

找到了目标文件之后,需要将其挪到电脑的目录下。mac环境下,可以下载一个Android文件传输工具,之后通过mv命令,将该文件移动到可访问的目录,即可拖到电脑目录下

mv /data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c/appbrand/pkg/_255193015_171.wxapkg  /mnt/sdcard/Download

注意:有些情况下是分包,需要删除pkg目录下所有文件,重新访问该小程序,之后将所有的wxapkg都移动出来

davinci:/data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c/appbrand # mv /data/data/com.tencent.mm/MicroMsg/982178cdd5589cb042c4efb99be0333c/appbrand/pkg/*  /mnt/sdcard/Download/wxpkg           

davinci:/mnt/sdcard/Download/wxpkg # ls
_-1223314631_171.wxapkg _-1820590985_171.wxapkg _-372062782_171.wxapkg _1123949441_612.wxapkg _255193015_171.wxapkg
_-1325581962_171.wxapkg _-1991183043_171.wxapkg _-86252332_171.wxapkg   _2041131240_171.wxapkg _453111957_171.wxapkg
_-1536422934_171.wxapkg _-289032338_171.wxapkg   _-942297262_171.wxapkg _2106768478_171.wxapkg _927440678_171.wxapkg

3.反编译

使用wxappUnpacker

# 安装依赖(具体参考下官方github)
npm install

node wuWxapkg.js /Users/spark/tools/安卓武器库/_255193015_171.wxapkg

忽略分包爆错,直接进去格式化一下js,Ctrl+F搜索接口

作者:Sp4rkW
来源:https://blog.csdn.net/wy_97/article/details/122155518

收起阅读 »

解决小程序里面的图片之间有空隙的问题

1、将图片转换为块级对象  即,设置img为:  display:block;  在本例中添加一组CSS代码:  #sub img {display:block;}2、设置图片的垂直对齐方式  即设置图片的vertical-align属性为“top,text-...
继续阅读 »

1、将图片转换为块级对象

  即,设置img为:

  display:block;

  在本例中添加一组CSS代码:

  #sub img {display:block;}

2、设置图片的垂直对齐方式

  即设置图片的vertical-align属性为“top,text-top,bottom,text-bottom”也可以解决。如本例中增加一组CSS代码:

  #sub img {vertical-align:top;}

3、设置父对象的文字大小为0px

  即,在#sub中添加一行:

  font-size:0;

  可以解决问题。但这也引发了新的问题,在父对象中的文字都无法显示。就算文字部分被子对象括起来,设置子对象文字大小依然可以显示,但在CSS效验的时候会提示文字过小的错误。

4、改变父对象的属性

  如果父对象的宽、高固定,图片大小随父对象而定,那么可以设置:

  overflow:hidden;

  来解决。如本例中可以向#sub中添加以下代码:

  width:88px;height:31px;overflow:hidden;

5、设置图片的浮动属性

  即在本例中增加一行CSS代码:

  #sub img {float:left;}

  如果要实现图文混排,这种方法是很好的选择。

6、取消图片标签和其父对象的最后一个结束标签之间的空格。

原文:https://blog.csdn.net/Function_JX_/article/details/79588578

收起阅读 »

【科幻】为何宇宙中有智能生命,基于量子退火的一种解释:“必然论”

原文链接: zhuanlan.zhihu.com之前在知乎写过一个宇宙层面的推理链条,类似"黑暗森林"的那种"纯靠推理猜测宇宙真相",也许能对人类和宇宙的目的给出一种解释。在这里略作整理,欢迎大家讨论。【公设1】宇宙遵循量子力学。例如,宇宙有 Lag...
继续阅读 »
原文链接: zhuanlan.zhihu.com

之前在知乎写过一个宇宙层面的推理链条,类似"黑暗森林"的那种"纯靠推理猜测宇宙真相",也许能对人类和宇宙的目的给出一种解释。在这里略作整理,欢迎大家讨论。

【公设1】宇宙遵循量子力学。

例如,宇宙有 Lagrangian,遵循路径积分。或者简化些,宇宙有波函数(忽略 t 在宇宙尺度上的微妙性),有 Hamiltonian,有"能量"。

通俗地说,路径积分的意思是:给定初态和末态,宇宙会找到概率大的演化路径(实际更类似找相位稳的路径,实际还更复杂,这里忽略细节),实现末态(不妨称为宇宙的目标)。

更通俗地说,就像量子退火,无论目标有多么遥远,宇宙都会逐渐找到办法降低自己的"能量"(实际更复杂,这里忽略细节),而且,宇宙找到的方案,一定非常高效,因为量子退火是一个强力的优化方法。

其实,训练深度神经网络的过程,已经告诉我们,在参数空间足够大时,梯度下降是很强的方法。而量子退火,比经典的梯度下降更强得多,宇宙的相空间更是非常巨大,所以宇宙尺度的量子退火,会非常非常强。

【公设2】宇宙的 Hamiltonian / Lagrangian,不仅包括现在的"标准模型"的微观的项目(各种微观粒子之间的耦合),还包括宇宙的大尺度的特性。

例如,维数(其实"标准模型"的项目,已经与维数有关)。

也可能包括更科幻的项目,例如"增大自己的尺寸"(吞并其它宇宙,等等),"分化出更多宇宙","尽快自我毁灭","完成某种循环","展现可能性","改变熵",等等。

具体是什么,不知道,不过,如果这里的理论是对的,那么,迟早有生命会知道,也许宇宙某处已经有生命知道了。

【公设3】智能生命有能力改造宇宙的大尺度的特性,就像降维升维之类。而且,由于智能生命有意识,所以,改造宇宙的速度,会相当快,比无生命的宇宙自己演化的速度更快。

可以这么比喻,无生命的宇宙完成目标,需要穿越很强的壁垒,而智能生命是催化剂,可以让宇宙快速完成目标。

【公设4】智能生命的进化和发展,也受量子力学的控制。

例如,某个基因应该如何变异,遵循量子规律,用拟人的语言说,宇宙对此有很强的"选择偏向"。

当然,量子的特点,是有误差,只要最终能达到类似的目标,宇宙不在意细节。偶然的倒退也不要紧。

【结论】

我们得到了一个有趣的结论:

宇宙会发现,在自己之中形成智能生命,然后让智能生命改造自己,是实现自己的目标的最佳方法。

换而言之,智能生命的出现和发展,不是偶然,是必然。

由于量子退火的高效,我们会发现,智能生命的形成和发展,会像是被看不见的手引导着一般,几乎每一次进化,每一个事件,都会走在接近正确的道路上,宛如神迹。宇宙的规律,就是看不见的手。

我一直感觉,虽然地球有46亿年,虽然宇宙有亿亿亿颗星,但人类还是出现得太快了。

如果只是以进化论的"尽可能传播自己"为目标,完全没必要进化出人类。用 AI 的语言说,这个"目标函数"太弱。

但是,如果宇宙的目标,需要科技极其发达的智能生命,那就不一样,这个目标函数非常非常强。

我的感觉是,即使在人类出现之后,人类的发展,有时看上去也有些"逢凶化吉",包括从前几乎走不出非洲,包括两次世界大战对于现在的和平发展做出了不可磨灭的贡献,包括冷战的过程。人类曾多次在毁灭的边缘,但都逃了过去,危险变成了历史,留给人类无数宝贵的经验和教训。当然,这些都可以用生存者偏差来解释,但仍然是很令人深思的。

【尾声】

这个理论,不妨称为"必然论"。它有很多有趣的推论,这就不用多说了,大家讨论比较有意思。

可能大家会问,这么看来,宇宙中是否应该到处都是生命?我觉得不一定。因为如果一种生命就足够完成目标,是没有必要进化出多种生命,毕竟,进化生命的过程,是"逆天"的过程(减熵)。

当然,也可能由于大家可以想象的原因,必须进化出多种生命。也可能,人类只是这个过程的一个阶段。人类不一定是"天选之族"。宇宙的目标也可能是很奇异的,而且现在我们也无法知道是否生存在模拟之中。总而言之,可以有很多有趣的推论。

收起阅读 »

漫话:如何给女朋友解释灭霸的指响并不是真随机"消灭"半数宇宙人口的?

周末,陪女朋友去电影院看了《复仇者联盟4:终局之战》,作为一个漫威粉三个小时看的是意犹未尽。出来之后,准备和女朋友聊一聊漫威这十年。在《复仇者联盟》电影中,灭霸毕生都有一个目标,那就是通过抹除一半的生命来维持宇宙的平衡。并且,灭霸还说,这个抹除过程是:随机性的...
继续阅读 »


周末,陪女朋友去电影院看了《复仇者联盟4:终局之战》,作为一个漫威粉三个小时看的是意犹未尽。出来之后,准备和女朋友聊一聊漫威这十年。

在《复仇者联盟》电影中,灭霸毕生都有一个目标,那就是通过抹除一半的生命来维持宇宙的平衡。

并且,灭霸还说,这个抹除过程是:随机性的、不夹私情、绝对公平、无论贵贱。

那么,到底什么是随机?他所谓的随机真的如他所说是不夹私情、绝对公平以及无论贵贱的吗?

随机性

随机性这个词是用来表达目的、动机、规则或一些非科学用法的可预测性的缺失。一个随机的过程是一个不定因子不断产生的重复过程。

提到随机性,不得不提的就是随机数,随机数在计算机应用中使用的比较广泛,最为熟知的便是在通信安全和现代密码学等领域中的应用。

随机数分为真随机数和伪随机数,我们程序中使用的基本都是伪随机数。

  • 真随机数,通过物理实验得出,比如掷钱币、骰子、转轮、使用电子元件的噪音、核裂变等。需要满足随机性、不可预测性、不可重现性。

  • 伪随机数,通过一定算法和种子得出。软件实现的是伪随机数。

只要这个随机数是由确定算法生成的,那就是伪随机。只能通过不断算法优化,使你的随机数更接近随机。

有限状态机不能产生真正的随机数的。所以,现代计算机中,无法通过一个纯算法来生成真正的随机数。无论是哪种语言,单纯的算法生成的数字都是伪随机数,都是由可确定的函数通过一个种子,产生的伪随机数。

为啥灭霸并不公平?

前面我们提到过,真随机数要满足随机性、不可预测性、不可重现性。

我们按照这三个性质逐一分析下,看看灭霸到底是不是公平的。

随机性

随机性,指的是不存在统计学偏差,是完全杂乱的数列。

复联3中,灭霸打了指响之后,复仇者联盟中存活和死亡的名单其实并不是随机的。其中很多对CP都是杀1留1的。如钢铁侠——蜘蛛侠、美队——冬兵、火箭浣熊——格鲁特、蚁人——黄蜂女等。

而且,还有一点就是,如果真的是随机性的话,那么灭霸自己也是有一定的概率会被抹除的,但是,他早就知道自己不会被抹除,并且已经制定好了退休计划。

并且,在复联3中,奇异博士用时间宝石和灭霸换了钢铁侠的生命,说明灭霸其实是选择性的进行抹除的。

可见,灭霸的指响抹除过程并不是随机的。

不可预测性

不可预测性,指的是不能从过去的数列推测出下一个出现的数。

这一点了解电影的朋友应该都知道,奇异博士曾经利用时间宝石穿越了时空,预测了未来,并看到了14000605种可能。

可见,灭霸的指响抹除过程并不是不可预测的。

不可重现性

不可重现性,除非将数列本身保存下来,否则不能重现相同的数列。

在复联3中,钢铁侠问奇异博士,14000605种可能中,胜利的有多少种。奇异博士回答:1种。

在复联4中,最后奇异博士对钢铁侠比了下面这样一个手势。说明,他看到的那唯一一种胜利的可能要复现了。

可见,灭霸的指响抹除过程并不是不可复现的。

综上,灭霸的指响抹除过程不符合随机性、不可预测性以及不可复现性。所以,灭霸的指响抹除过程并不是真正的随机的。

通过现象来看,灭霸的抹除操作很可能只是通过简单的分层抽样实现的。简单操作过程如下:

  • 1、把需要特殊处理,不做抹除的人的DNA单独从所有物种的DNA库中识别出来,并保存到缓存中。

  • 2、根据不同的条件把DNA库中的所有生命体划分成若干区块,如地球人、阿斯加德人等。把他们的DNA信息保存到不同的数据库中。在遍历的过程中,如果遇到缓存中已有的数据,则跳过。

  • 3、再根据物种多样性,如性别、年龄段、职业等把同一个分库中的数据分别划分到不同的表中,保证每一张分表中都包含了完整的物种多样性。

  • 4、遍历所有数据库,按顺序的删除每个数据库中一半的分表。如地球人的数据库中共有1024张表,只保留512张即可。

  • 5、再把缓存中的数据同步到数据库中。

这样,在后面需要复活这些人的时候,只需要找到数据库的Binlog,把数据重新写入数据库就行了。

真随机数生成器

真正的随机数是使用物理现象产生而不是计算机程序产生的。生成随机数的设备我们称之为真随机数生成器。

这样的设备通常是基于一些能生成低等级、统计学随机的“噪声”信号的微观现象,如热力学噪声、光电效应和量子现象。

从某种程度上来说,基于经典热噪声的随机数芯片读取当前物理环境中的噪声,并据此获得随机数。这类装置相对于基于软件算法的实现,由于环境中的变量更多,因此更难预测。

然而在牛顿力学的框架下,即使影响随机数产生的变量非常多,但在每个变量的初始状态确定后,整个系统的运行状态及输出在原理上是可以预测的,因此这一类装置也是基于确定性的过程,只是某种更难预测的伪随机数。

但是,量子力学的发现从根本上改变了这一局面,因为其基本物理过程具有经典物理中所不具有的内禀随机性,从而可以制造出真正的随机数产生器。

据美国国家标准与技术研究院(NIST)官网消息,该机构研究人员在2018年4月出版的《自然》杂志上撰文指出,他们开发出一种新方法,可生成由量子力学保证的随机数字。新技术超越了此前获得随机数字的所有方法,得到了“真正的随机数字”,有助增强密码系统的安全性。(原文地址:https://www.nature.com/articles/s41586-018-0019-0.epdf )

NIST数学家彼特·比尔霍斯特进一步解释说:“诸如翻转硬币之类的情况似乎是随机的,但如果能看到硬币确切的下落路径,最终结果也是可以预测的。因此,很难保证给定经典来源真正不可预测。量子力学在产生随机性方面表现更好,量子随机是真正的随机,因为对处于‘叠加’状态的量子粒子进行测量,得到的结果基本上是不可预测的。”

在复联4中,也有很多和量子物理有关的知识,甚至最终可以扭转乾坤也是依靠的量子领域。漫威电影的宗旨可以高度概括成以下四句话:遇事不决,量子力学。 解释不通,穿越时空。 篇幅不够,平行宇宙。 定律不足,高维人族。

Java中的随机数生成器

Java中生成随机数还是比较简单的,Java提供了很多种API可以供开发者使用。

通过时间获取

在Java中,可以通过System.currentTimeMillis()来获取当前时间毫秒数:

final long l = System.currentTimeMillis();

若要获取指定范围的数字,只需要对数字进行取模就行了,如下方法可以获得0-99的随机数:

final long l = System.currentTimeMillis();
final int i = (int)( l % 100 );

Math.random()

通过Math.random()可以返回0(包含)到1(不包含)之间的double值。使用方法如下:

final double d = Math.random();

若要获取int类型的整数,只需要将上面的结果转行成int类型即可。比如,获取[0, 100)之间的int整数。方法如下:

final double d = Math.random();
final int i = (int)(d*100);

Random类

Java提供的伪随机数发生器有java.util.Random类和java.util.concurrent.ThreadLocalRandom类。

Random类采用AtomicLong实现,保证多线程的线程安全性,但正如该类注释上说明的,多线程并发获取随机数时性能较差。

多线程环境中可以使用ThreadLocalRandom作为随机数发生器,ThreadLocalRandom采用了线程局部变量来改善性能,这样就可以使用long而不是AtomicLong,此外,ThreadLocalRandom还进行了字节填充,以避免伪共享。

如使用Random获取[0, 100)之间的int整数,方法如下:

Random random = new Random();
int i2 = random.nextInt(100);

强随机数发生器

强随机数发生器依赖于操作系统底层提供的随机事件。强随机数生成器的初始化速度和生成速度都较慢,而且由于需要一定的熵累积才能生成足够强度的随机数,所以可能会造成阻塞。熵累积通常来源于多个随机事件源,如敲击键盘的时间间隔,移动鼠标的距离与间隔,特定中断的时间间隔等。所以,只有在需要生成加密性强的随机数据的时候才用它。

Java提供的强随机数发生器是java.security.SecureRandom类,该类也是一个线程安全类,使用synchronize方法保证线程安全,但jdk并没有做出承诺在将来改变SecureRandom的线程安全性。因此,同Random一样,在高并发的多线程环境中可能会有性能问题。

这个锅,研发人员不背!!!

根据我的猜想。对于无限手套这个产品,产品经理最初的需求可能只是满足使用者的一个愿望而已,而几颗宝石就像是七龙珠一样,集齐之后打个指响就可以实现愿望。

开发者只是提供了一个可以满足愿望的API接口,参数是一个Callback,具体做什么事情,完全是使用者传进来的想法而已。就像灭霸要抹除一半的生命、绿巨人想要把被抹掉的人救回来、而钢铁侠只是想把坏人抹掉而已。

最后,Tony, Love You 3000 Times.

收起阅读 »

黑科技- iOS静态cell和动态cell结合使用

iOS
1. 什么是静态Cell。 静态cell,可以直接布局cell样式的、group、insert group等直接拖@IBOutlet 布局简单,实用,比如我们同一类型的登陆、密码、设置、WIFI等页面 2. 怎么使用静态Cell。 必须使用StoryBo...
继续阅读 »

1. 什么是静态Cell。



  • 静态cell,可以直接布局cell样式的、group、insert group等直接拖@IBOutlet

  • 布局简单,实用,比如我们同一类型的登陆、密码、设置、WIFI等页面


2. 怎么使用静态Cell。



  • 必须使用StoryBoard来创建UITableViewController

  • image-20210823133103767.png

  • 然后你就可以直接使用cell的布局,运行出来就是StoryBoard的布局

  • image-20210823133226364.png

  • 运行以后的效果

  • image-20210823133337424.png


3. 和动态Cell结合。



  • 如例子:Wi-Fi的截图,我的网络和其他网络可以用动态cell来创建、其他的都可以直接用静态cell来创建


image-20210823132756571.png


使用步骤:




  1. 先在StoryBoard创建静态的cell,需要复用的cell留出一个位置即可

  2. 复用的cell必须单独创建(或者使用单独的xib文件)

  3. 这使用的时候,必须注册cell

  4. 动态的cell必须实现UITableViewDelegate的indentationLevelForRowAt这个方法

  5. 在这个方法里indentationLevelForRowAt返回第一个这StoryBoard留出位置的cell的indexPath


详情请看下列代码实现;



image-20210823133226364.png


第二个section 留白的就是给动态cell实现的


image-20210823134208316.png


创建一个xib的动态cell实现(可复用)


// 注册Cell
tableView.register(UINib(nibName: "CostomTableViewCell", bundle: nil), forCellReuseIdentifier: "CostomTableViewCell")


override func tableView(_ tableView: UITableView, indentationLevelForRowAt indexPath: IndexPath) -> Int {
   if indexPath.section == 1 {
       return super.tableView(tableView, indentationLevelForRowAt: IndexPath(row: 0, section: 1))
   }
   return super.tableView(tableView, indentationLevelForRowAt: indexPath)
}


实现indentationLevelForRowAt方法,返回IndexPath(row: 0, section: 1)第一section 的第一个row,其他不需要复用的自己返回父类即可


override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
   if indexPath.section == 1 {
       let cell = tableView.dequeueReusableCell(withIdentifier: "CostomTableViewCell", for: indexPath) as! CostomTableViewCell
       cell.dynamic.text = "dynamicRow:(dynamicRowArray[indexPath.row])"
       return cell
   }
   return  super.tableView(tableView, cellForRowAt: indexPath)
}

在cellForRowAt复用里写已经要实现的复用的cell,其他静态cell直接返回父类即可


最终实现的效果


image-20210823134654515.png


4. Row、Section使用的技巧,以及常出现的问题。



  • 如果复用的是row,直接实现indentationLevelForRowAt这个方法和cellForRowAt方法即可 必须实现,不然会崩溃

  • 但是如果是复用的section,就必须实现UITableViewDataSource的和数据源相关的方法以下的几个方法


// 自定义动态section 的时候,以下方法必须实现,否则会崩溃
override func tableView(_ tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {
   nil
}

override func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
   nil
}

override func tableView(_ tableView: UITableView, viewForFooterInSection section: Int) -> UIView? {
   nil
}

override func tableView(_ tableView: UITableView, titleForFooterInSection section: Int) -> String? {
   nil
}

override func tableView(_ tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
   5
}

override func tableView(_ tableView: UITableView, heightForFooterInSection section: Int) -> CGFloat {
   .leastNonzeroMagnitude
}



  • 默认情况下会调用父类的数据,静态cell是不实现这些方法是越界的


注意事项:



  1. indentationLevelForRowAt 这个方法是动态和静态结合必须实现的方法

  2. Row、Section所需要实现的方法有差别,当是Section的时候需要实现与section相关的代理和数据源,例如sectionHeaderView、Footer等

  3. 动态cell一定要在storyboard里留白,自定义需要复用的cell必须使用xib、或者自定义,不能在原有的storyboard里创建

  4. 如果遇到崩溃,大多数是因为数据越界,数据源的问题,如果以上都实现,基本是没有问题的


Demo地址


作者:芭菲猫
链接:https://juejin.cn/post/6999504422065831943

收起阅读 »

std::out_of_range异常

iOS
使用C++容器类访问成员时由于使用问题可能会遇到"terminate called after throwing an instance of 'std::out_of_range'"或者"Abort message: 'terminating with un...
继续阅读 »

使用C++容器类访问成员时由于使用问题可能会遇到"terminate called after throwing an instance of 'std::out_of_range'"或者"Abort message: 'terminating with uncaught exception of type std::out_of_range"。问题的大概意思是:访问越界了。没有捕获std::out_of_range类型的异常终止。

通常在使用vector、map这样的C++容器类型时会遇到,这里我们以map类型为例,加以说明。

std::out_of_range异常的描述

假设我们定义了一个map类型的变量g_mapIsDestroyedRefCount,要访问容器中的数据项有多种方式。例如,获取g_mapIsDestroyedRefCount中key值为cameraId的值,可以这样:

  1. g_mapIsDestroyedRefCount[cameraId]
  2. g_mapIsDestroyedRefCount.at(cameraId)

两种写法都可以获取key为cameraId的value,一般效果看不出来差别,但是当g_mapIsDestroyedRefCount中不存在key为cameraId的<key, value>时就会出现“std::out_of_range”访问越界问题。

导致std::out_of_range的原因

容器类型访问方法使用有问题

对于std::map::at官方声明:

  mapped_type& at (const key_type& k);
const mapped_type& at (const key_type& k) const;

对于std::map::at使用有如下说明: Access element        访问元素

Returns a reference to the mapped value of the element identified with key k.      返回元素键为k的映射值的引用,即Key为k的元素的对应value值。
If k does not match the key of any element in the container, the function throws an out_of_range exception.   如果容器中没有匹配的k键,该函数将抛出一个out_of_range异常

 

std::map::at的使用

  • 正确使用
  • 错误使用

1.std::map::at的正确使用

 

#include <iostream>
#include <string>
#include <map>

std
::map<int, int> g_mapIsDestroyedRefCount;

int main()
{
int cameraId = 1;
cout
<< "Let's try"<< endl;

//向map中添加测试数据
g_mapIsDestroyedRefCount
.insert(std::pair<int, int>(0, 2))'
cout << "cameraId:"<< cameraId<< "count:";
try {
cout<< g_mapIsDestroyedRefCount.at(cameraId) <<endl;
} catch (const std::out_of_range& oor) {
std::cerr << "\nOut of range error:" << oor.what()<< endl;
}
cout << "try done"<< endl;
return 0;
}

 

运行结果:

 

2.std::map::at错误使用

#include <iostream>
#include <string>
#include <map>
using namespace std;

std
::map<int, int> g_mapIsDestroyedRefCount;

int main()
{
int cameraId = 2;

cout
<< "Let's try"<< endl;
g_mapIsDestroyedRefCount
.insert(std::pair<int, int>(0, 2));
cout
<< "cameraId:"<< cameraId<< "count:";

//介绍中说的方法一,可以访问
cout
<< g_mapIsDestroyedRefCount[cameraId]<< endl;
//方法二,异常
cameraId = 2;
count
<< g_mapIsDestroyedRefCount.at(cameraId)<< endl;
cout<< "try done"<< endl;
}

运行结果:(程序异常退出)


收起阅读 »

傻傻分不清之 Cookie、Session、Token、JWT

什么是认证(Authentication)通俗地讲就是验证当前用户的身份,证明“你是你自己”(比如:你每天上下班打卡,都需要通过指纹打卡,当你的指纹和系统里录入的指纹相匹配时,就打卡成功)互联网中的认证:用户名密码登录邮箱发送登录链接手机号接收验证码只要你能收...
继续阅读 »



什么是认证(Authentication)

  • 通俗地讲就是验证当前用户的身份,证明“你是你自己”(比如:你每天上下班打卡,都需要通过指纹打卡,当你的指纹和系统里录入的指纹相匹配时,就打卡成功)

  • 互联网中的认证:

    • 用户名密码登录

    • 邮箱发送登录链接

    • 手机号接收验证码

    • 只要你能收到邮箱/验证码,就默认你是账号的主人

什么是授权(Authorization)

  • 用户授予第三方应用访问该用户某些资源的权限

    • 你在安装手机应用的时候,APP 会询问是否允许授予权限(访问相册、地理位置等权限)

    • 你在访问微信小程序时,当登录时,小程序会询问是否允许授予权限(获取昵称、头像、地区、性别等个人信息)

  • 实现授权的方式有:cookie、session、token、OAuth

什么是凭证(Credentials)

  • 实现认证和授权的前提

    是需要一种

    媒介(证书)

    来标记访问者的身份

    • 在战国时期,商鞅变法,发明了照身帖。照身帖由官府发放,是一块打磨光滑细密的竹板,上面刻有持有人的头像和籍贯信息。国人必须持有,如若没有就被认为是黑户,或者间谍之类的。

    • 在现实生活中,每个人都会有一张专属的居民身份证,是用于证明持有人身份的一种法定证件。通过身份证,我们可以办理手机卡/银行卡/个人贷款/交通出行等等,这就是认证的凭证。

    • 在互联网应用中,一般网站(如掘金)会有两种模式,游客模式和登录模式。游客模式下,可以正常浏览网站上面的文章,一旦想要点赞/收藏/分享文章,就需要登录或者注册账号。当用户登录成功后,服务器会给该用户使用的浏览器颁发一个令牌(token),这个令牌用来表明你的身份,每次浏览器发送请求时会带上这个令牌,就可以使用游客模式下无法使用的功能。

什么是 Cookie

  • HTTP 是无状态的协议(对于事务处理没有记忆能力,每次客户端和服务端会话完成时,服务端不会保存任何会话信息):每个请求都是完全独立的,服务端无法确认当前访问者的身份信息,无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪(知道是谁在访问我),就必须主动的去维护一个状态,这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现。

  • cookie 存储在客户端: cookie 是服务器发送到用户浏览器并保存在本地的一小块数据,它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

  • cookie 是不可跨域的: 每个 cookie 都会绑定单一的域名,无法在别的域名下获取使用,一级域名和二级域名之间是允许共享使用的靠的是 domain)

cookie 重要的属性

属性说明
name=value键值对,设置 Cookie 的名称及相对应的值,都必须是字符串类型 - 如果值为 Unicode 字符,需要为字符编码。 - 如果值为二进制数据,则需要使用 BASE64 编码。
domain指定 cookie 所属域名,默认是当前域名
path指定 cookie 在哪个路径(路由)下生效,默认是 '/'。 如果设置为 /abc,则只有 /abc 下的路由可以访问到该 cookie,如:/abc/read
maxAgecookie 失效的时间,单位秒。如果为整数,则该 cookie 在 maxAge 秒后失效。如果为负数,该 cookie 为临时 cookie ,关闭浏览器即失效,浏览器也不会以任何形式保存该 cookie 。如果为 0,表示删除该 cookie 。默认为 -1。 - 比 expires 好用
expires过期时间,在设置的某个时间点后该 cookie 就会失效。 一般浏览器的 cookie 都是默认储存的,当关闭浏览器结束这个会话的时候,这个 cookie 也就会被删除
secure该 cookie 是否仅被使用安全协议传输。安全协议有 HTTPS,SSL等,在网络上传输数据之前先将数据加密。默认为false。 当 secure 值为 true 时,cookie 在 HTTP 中是无效,在 HTTPS 中才有效。
httpOnly如果给某个 cookie 设置了 httpOnly 属性,则无法通过 JS 脚本 读取到该 cookie 的信息,但还是能通过 Application 中手动修改 cookie,所以只是在一定程度上可以防止 XSS 攻击,不是绝对的安全


什么是 Session

  • session 是另一种记录服务器和客户端会话状态的机制

  • session 是基于 cookie 实现的,session 存储在服务器端,sessionId 会被存储到客户端的cookie 中

session.png

  • session 认证流程:

    • 用户第一次请求服务器的时候,服务器根据用户提交的相关信息,创建对应的 Session

    • 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器

    • 浏览器接收到服务器返回的 SessionID 信息后,会将此信息存入到 Cookie 中,同时 Cookie 记录此 SessionID 属于哪个域名

    • 当用户第二次访问服务器的时候,请求会自动判断此域名下是否存在 Cookie 信息,如果存在自动将 Cookie 信息也发送给服务端,服务端会从 Cookie 中获取 SessionID,再根据 SessionID 查找对应的 Session 信息,如果没有找到说明用户没有登录或者登录失效,如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知,SessionID 是连接 Cookie 和 Session 的一道桥梁,大部分系统也是根据此原理来验证用户登录状态。

Cookie 和 Session 的区别

  • 安全性: Session 比 Cookie 安全,Session 是存储在服务器端的,Cookie 是存储在客户端的。

  • 存取值的类型不同:Cookie 只支持存字符串数据,想要设置其他类型的数据,需要将其转换成字符串,Session 可以存任意数据类型。

  • 有效期不同: Cookie 可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般失效时间较短,客户端关闭(默认情况下)或者 Session 超时都会失效。

  • 存储大小不同: 单个 Cookie 保存的数据不能超过 4K,Session 可存储数据远高于 Cookie,但是当访问量过多,会占用过多的服务器资源。

什么是 Token(令牌)

Acesss Token

  • 访问资源接口(API)时所需要的资源凭证

  • 简单 token 的组成: uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,token 的前几位以哈希算法压缩成的一定长度的十六进制字符串)

  • 特点:

    • 服务端无状态化、可扩展性好

    • 支持移动端设备

    • 安全

    • 支持跨程序调用

  • token 的身份验证流程:

img

  1. 客户端使用用户名跟密码请求登录

  2. 服务端收到请求,去验证用户名与密码

  3. 验证成功后,服务端会签发一个 token 并把这个 token 发送给客户端

  4. 客户端收到 token 以后,会把它存储起来,比如放在 cookie 里或者 localStorage 里

  5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 token

  6. 服务端收到请求,然后去验证客户端请求里面带着的 token ,如果验证成功,就向客户端返回请求的数据

  • 每一次请求都需要携带 token,需要把 token 放到 HTTP 的 Header 里

  • 基于 token 的用户认证是一种服务端无状态的认证方式,服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间,从而减轻服务器的压力,减少频繁的查询数据库

  • token 完全由应用管理,所以它可以避开同源策略

Refresh Token

  • 另外一种 token——refresh token

  • refresh token 是专用于刷新 access token 的 token。如果没有 refresh token,也可以刷新 access token,但每次刷新都要用户输入登录用户名与密码,会很麻烦。有了 refresh token,可以减少这个麻烦,客户端直接用 refresh token 去更新 access token,无需用户进行额外的操作。

img

  • Access Token 的有效期比较短,当 Acesss Token 由于过期而失效时,使用 Refresh Token 就可以获取到新的 Token,如果 Refresh Token 也失效了,用户就只能重新登录了。

  • Refresh Token 及过期时间是存储在服务器的数据库中,只有在申请新的 Acesss Token 时才会验证,不会对业务接口响应时间造成影响,也不需要向 Session 一样一直保持在内存中以应对大量的请求。

Token 和 Session 的区别

  • Session 是一种记录服务器和客户端会话状态的机制,使服务端有状态化,可以记录会话信息。而 Token 是令牌访问资源接口(API)时所需要的资源凭证。Token 使服务端无状态化,不会存储会话信息。

  • Session 和 Token 并不矛盾,作为身份认证 Token 安全性比 Session 好,因为每一个请求都有签名还能防止监听以及重放攻击,而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话,仍然可以增加 Session 来在服务器端保存一些状态。

  • 所谓 Session 认证只是简单的把 User 信息存储到 Session 里,因为 SessionID 的不可预测性,暂且认为是安全的。而 Token ,如果指的是 OAuth Token 或类似的机制的话,提供的是 认证 和 授权 ,认证是针对用户,授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上,也不可以转到其它用户上。Session 只提供一种简单的认证,即只要有此 SessionID ,即认为有此 User 的全部权利。是需要严格保密的,这个数据应该只保存在站方,不应该共享给其它网站或者第三方 App。所以简单来说:如果你的用户数据可能需要和第三方共享,或者允许第三方调用 API 接口,用 Token 。如果永远只是自己的网站,自己的 App,用什么就无所谓了。

什么是 JWT

  • JSON Web Token(简称 JWT)是目前最流行的跨域认证解决方案。

  • 是一种认证授权机制

  • JWT 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准(RFC 7519)。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源。比如用在用户登录上。

  • 可以使用 HMAC 算法或者是 RSA 的公/私秘钥对 JWT 进行签名。因为数字签名的存在,这些传递的信息是可信的。

  • 阮一峰老师的 JSON Web Token 入门教程 讲的非常通俗易懂,这里就不再班门弄斧了

生成 JWT

jwt.io/
http://www.jsonwebtoken.io/

JWT 的原理

img

  • JWT 认证流程:

    • 用户输入用户名/密码登录,服务端认证成功后,会返回给客户端一个 JWT

    • 客户端将 token 保存到本地(通常使用 localstorage,也可以使用 cookie)

    • 当用户希望访问一个受保护的路由或者资源的时候,需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT,其内容看起来是下面这样

Authorization: Bearer <token>
复制代码
  • 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息,如果合法,则允许用户的行为

  • 因为 JWT 是自包含的(内部包含了一些会话信息),因此减少了需要查询数据库的需要

  • 因为 JWT 并不使用 Cookie 的,所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题(CORS)

  • 因为用户的状态不再存储在服务端的内存中,所以这是一种无状态的认证机制

JWT 的使用方式

  • 客户端收到服务器返回的 JWT,可以储存在 Cookie 里面,也可以储存在 localStorage。

方式一

  • 当用户希望访问一个受保护的路由或者资源的时候,可以把它放在 Cookie 里面自动发送,但是这样不能跨域,所以更好的做法是放在 HTTP 请求头信息的 Authorization 字段里,使用 Bearer 模式添加 JWT。

    GET /calendar/v1/events
    Host: api.example.com
    Authorization: Bearer <token>
    复制代码
    • 用户的状态不会存储在服务端的内存中,这是一种 无状态的认证机制

    • 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息,如果合法,则允许用户的行为。

    • 由于 JWT 是自包含的,因此减少了需要查询数据库的需要

    • JWT 的这些特性使得我们可以完全依赖其无状态的特性提供数据 API 服务,甚至是创建一个下载流服务。

    • 因为 JWT 并不使用 Cookie ,所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题(CORS)

方式二

  • 跨域的时候,可以把 JWT 放在 POST 请求的数据体里。

方式三

  • 通过 URL 传输

http://www.example.com/user?token=xxx
复制代码

项目中使用 JWT

项目地址

Token 和 JWT 的区别

相同:

  • 都是访问资源的令牌

  • 都可以记录用户的信息

  • 都是使服务端无状态化

  • 都是只有验证成功后,客户端才能访问服务端上受保护的资源

区别:

  • Token:服务端验证客户端发送过来的 Token 时,还需要查询数据库获取用户信息,然后验证 Token 是否有效。

  • JWT: 将 Token 和 Payload 加密后存储于客户端,服务端只需要使用密钥解密进行校验(校验也是 JWT 自己实现的)即可,不需要查询或者减少查询数据库,因为 JWT 自包含了用户信息和加密的数据。

常见的前后端鉴权方式

  1. Session-Cookie

  2. Token 验证(包括 JWT,SSO)

  3. OAuth2.0(开放授权)

常见的加密算法

image.png

  • 哈希算法(Hash Algorithm)又称散列算法、散列函数、哈希函数,是一种从任何一种数据中创建小的数字“指纹”的方法。哈希算法将数据重新打乱混合,重新创建一个哈希值。

  • 哈希算法主要用来保障数据真实性(即完整性),即发信人将原始消息和哈希值一起发送,收信人通过相同的哈希函数来校验原始数据是否真实。

  • 哈希算法通常有以下几个特点:

    • 正像快速:原始数据可以快速计算出哈希值

    • 逆向困难:通过哈希值基本不可能推导出原始数据

    • 输入敏感:原始数据只要有一点变动,得到的哈希值差别很大

    • 冲突避免:很难找到不同的原始数据得到相同的哈希值,宇宙中原子数大约在 10 的 60 次方到 80 次方之间,所以 2 的 256 次方有足够的空间容纳所有的可能,算法好的情况下冲突碰撞的概率很低:

      • 2 的 128 次方为 340282366920938463463374607431768211456,也就是 10 的 39 次方级别

      • 2 的 160 次方为 1.4615016373309029182036848327163e+48,也就是 10 的 48 次方级别

      • 2 的 256 次方为 1.1579208923731619542357098500869 × 10 的 77 次方,也就是 10 的 77 次方

注意:

  1. 以上不能保证数据被恶意篡改,原始数据和哈希值都可能被恶意篡改,要保证不被篡改,可以使用RSA 公钥私钥方案,再配合哈希值。

  2. 哈希算法主要用来防止计算机传输过程中的错误,早期计算机通过前 7 位数据第 8 位奇偶校验码来保障(12.5% 的浪费效率低),对于一段数据或文件,通过哈希算法生成 128bit 或者 256bit 的哈希值,如果校验有问题就要求重传。

常见问题

使用 cookie 时需要考虑的问题

  • 因为存储在客户端,容易被客户端篡改,使用前需要验证合法性

  • 不要存储敏感数据,比如用户密码,账户余额

  • 使用 httpOnly 在一定程度上提高安全性

  • 尽量减少 cookie 的体积,能存储的数据量不能超过 4kb

  • 设置正确的 domain 和 path,减少数据传输

  • cookie 无法跨域

  • 一个浏览器针对一个网站最多存 20 个Cookie,浏览器一般只允许存放 300 个Cookie

  • 移动端对 cookie 的支持不是很好,而 session 需要基于 cookie 实现,所以移动端常用的是 token

使用 session 时需要考虑的问题

  • 将 session 存储在服务器里面,当用户同时在线量比较多时,这些 session 会占据较多的内存,需要在服务端定期的去清理过期的 session

  • 当网站采用集群部署的时候,会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的,但是处理用户请求的服务器不一定是那个创建 session 的服务器,那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。

  • 当多个应用要共享 session 时,除了以上问题,还会遇到跨域问题,因为不同的应用可能部署的主机不一样,需要在各个应用做好 cookie 跨域的处理。

  • sessionId 是存储在 cookie 中的,假如浏览器禁止 cookie 或不支持 cookie 怎么办? 一般会把 sessionId 跟在 url 参数后面即重写 url,所以 session 不一定非得需要靠 cookie 实现

  • 移动端对 cookie 的支持不是很好,而 session 需要基于 cookie 实现,所以移动端常用的是 token

使用 token 时需要考虑的问题

  • 如果你认为用数据库来存储 token 会导致查询时间太长,可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。

  • token 完全由应用管理,所以它可以避开同源策略

  • token 可以避免 CSRF 攻击(因为不需要 cookie 了)

  • 移动端对 cookie 的支持不是很好,而 session 需要基于 cookie 实现,所以移动端常用的是 token

使用 JWT 时需要考虑的问题

  • 因为 JWT 并不依赖 Cookie 的,所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题(CORS)

  • JWT 默认是不加密,但也是可以加密的。生成原始 Token 以后,可以用密钥再加密一次。

  • JWT 不加密的情况下,不能将秘密数据写入 JWT。

  • JWT 不仅可以用于认证,也可以用于交换信息。有效使用 JWT,可以降低服务器查询数据库的次数。

  • JWT 最大的优势是服务器不再需要存储 Session,使得服务器认证鉴权业务可以方便扩展。但这也是 JWT 最大的缺点:由于服务器不需要存储 Session 状态,因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了,到期之前就会始终有效,除非服务器部署额外的逻辑。

  • JWT 本身包含了认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证。

  • JWT 适合一次性的命令认证,颁发一个有效期极短的 JWT,即使暴露了危险也很小,由于每次操作都会生成新的 JWT,因此也没必要保存 JWT,真正实现无状态。

  • 为了减少盗用,JWT 不应该使用 HTTP 协议明码传输,要使用 HTTPS 协议传输。

使用加密算法时需要考虑的问题

  • 绝不要以明文存储密码

  • 永远使用 哈希算法 来处理密码,绝不要使用 Base64 或其他编码方式来存储密码,这和以明文存储密码是一样的,使用哈希,而不要使用编码。编码以及加密,都是双向的过程,而密码是保密的,应该只被它的所有者知道, 这个过程必须是单向的。哈希正是用于做这个的,从来没有解哈希这种说法, 但是编码就存在解码,加密就存在解密。

  • 绝不要使用弱哈希或已被破解的哈希算法,像 MD5 或 SHA1 ,只使用强密码哈希算法。

  • 绝不要以明文形式显示或发送密码,即使是对密码的所有者也应该这样。如果你需要 “忘记密码” 的功能,可以随机生成一个新的 一次性的(这点很重要)密码,然后把这个密码发送给用户。

分布式架构下 session 共享方案

1. session 复制

  • 任何一个服务器上的 session 发生改变(增删改),该节点会把这个 session 的所有内容序列化,然后广播给所有其它节点,不管其他服务器需不需要 session ,以此来保证 session 同步

优点: 可容错,各个服务器间 session 能够实时响应。
缺点: 会对网络负荷造成一定压力,如果 session 量大的话可能会造成网络堵塞,拖慢服务器性能。

2. 粘性 session /IP 绑定策略

  • 采用 Ngnix 中的 ip_hash 机制,将某个 ip的所有请求都定向到同一台服务器上,即将用户与服务器绑定。 用户第一次请求时,负载均衡器将用户的请求转发到了 A 服务器上,如果负载均衡器设置了粘性 session 的话,那么用户以后的每次请求都会转发到 A 服务器上,相当于把用户和 A 服务器粘到了一块,这就是粘性 session 机制。

优点: 简单,不需要对 session 做任何处理。
缺点: 缺乏容错性,如果当前访问的服务器发生故障,用户被转移到第二个服务器上时,他的 session 信息都将失效。
适用场景: 发生故障对客户产生的影响较小;服务器发生故障是低概率事件 。
实现方式: 以 Nginx 为例,在 upstream 模块配置 ip_hash 属性即可实现粘性 session。

3. session 共享(常用)

  • 使用分布式缓存方案比如 Memcached 、Redis 来缓存 session,但是要求 Memcached 或 Redis 必须是集群

  • 把 session 放到 Redis 中存储,虽然架构上变得复杂,并且需要多访问一次 Redis ,但是这种方案带来的好处也是很大的:

    • 实现了 session 共享;

    • 可以水平扩展(增加 Redis 服务器);

    • 服务器重启 session 不丢失(不过也要注意 session 在 Redis 中的刷新/失效机制);

    • 不仅可以跨服务器 session 共享,甚至可以跨平台(例如网页端和 APP 端)

img

4. session 持久化

  • 将 session 存储到数据库中,保证 session 的持久化

优点: 服务器出现问题,session 不会丢失
缺点: 如果网站的访问量很大,把 session 存储到数据库中,会对数据库造成很大压力,还需要增加额外的开销维护数据库。

只要关闭浏览器 ,session 真的就消失了?

不对。对 session 来说,除非程序通知服务器删除一个 session,否则服务器会一直保留,程序一般都是在用户做 log off 的时候发个指令去删除 session。
然而浏览器从来不会主动在关闭之前通知服务器它将要关闭,因此服务器根本不会有机会知道浏览器已经关闭,之所以会有这种错觉,是大部分 session 机制都使用会话 cookie 来保存 session id,而关闭浏览器后这个 session id 就消失了,再次连接服务器时也就无法找到原来的 session。如果服务器设置的 cookie 被保存在硬盘上,或者使用某种手段改写浏览器发出的 HTTP 请求头,把原来的 session id 发送给服务器,则再次打开浏览器仍然能够打开原来的 session。
恰恰是由于关闭浏览器不会导致 session 被删除,迫使服务器为 session 设置了一个失效时间,当距离客户端上一次使用 session 的时间超过这个失效时间时,服务器就认为客户端已经停止了活动,才会把 session 删除以节省存储空间。

项目地址

在项目中使用 JWT

后语

  • 本文只是基于自己的理解讲了理论知识,因为对后端/算法知识不是很熟,如有谬误,还请告知,万分感谢

  • 如果本文对你有所帮助,还请点个赞~~

参考

百度百科-cookie

百度百科-session

详解 Cookie,Session,Token

一文彻底搞懂Cookie、Session、Token到底是什么

3种web会话管理的方式!!!

Token ,Cookie和Session的区别!!!

彻底理解 cookie、session、token!!!

前端鉴权

SHA-1

SHA-2

SHA-3

不要再使用MD5和SHA1加密密码了!

廖雪峰 Node 教程之 crypto


作者:秋天不落叶
来源:https://juejin.cn/post/6844904034181070861

收起阅读 »

不常见但是有用的chrome调试技巧

dom添加选中dom节点为全局变量方便需要调试多个dom的场景适用对dom有多次操作的场景force node state (触发)状态调试dom的某个状态copy element拷贝选中dom的信息style/class给选中元素添加一个 class 名快速...
继续阅读 »



dom

添加选中dom节点为全局变量方便需要调试多个dom的场景

适用对dom有多次操作的场景

force node state (触发)状态

调试dom的某个状态

copy element

拷贝选中dom的信息

style/class

给选中元素添加一个 class 名

快速给元素添加class

修改元素的盒模型大小

快速修改元素的盒模型大小(margin/padding/width/height等)

network

block specific request

block特定的请求

快捷键:command + shift + p -> show request blocking

改变请求的 user agent

修改请求的user agent

快捷键:command + shift + p -> network conditions 切换 user agent

javascript

断点,断浏览器的行为(比如 click、mouse 等等)

拦截浏览器的行为


快速改变拦截的变量的值

双击改变拦截变量的值

添加 watch 表达式

添加watch表达式

条件断点

设置断点的条件

快速调试代码片段

Snippet(片段)代码调试,不需要创建特定的页面

参考文档


作者:seventhMa
来源:https://juejin.cn/post/6963600839587921927

收起阅读 »

前端工程师生产环境 debugger 技巧

导言:那我们今天讲一讲如何使用 chrome 在生产环境进行 debug 。生产环境 debug 需要几步?这问题和“把大象装进冰箱拢共分几步”一样简单。第二步,把大象装进冰箱。找到需要 debug 的前端文件,格式化,打断点,调试上下文,定位问题;如何快速定...
继续阅读 »

导言:

开发环境 debug 是每个程序员上岗的必备技能。生产环境呢?虽然生产环境 debug 是一件非常不优雅的行为,但是由于种种原因,我们又不得不这么干。

那我们今天讲一讲如何使用 chrome 在生产环境进行 debug 。

生产环境 debug 步骤

生产环境 debug 需要几步?这问题和“把大象装进冰箱拢共分几步”一样简单。

第一步,把冰箱门打开。F12 打开 devTools;

第二步,把大象装进冰箱。找到需要 debug 的前端文件,格式化,打断点,调试上下文,定位问题;

第三部,关闭冰箱门。解决问题。

如何快速定位错误是前端还是后端接口返回的?

在把大象装进冰箱之前,先初步判断下,是否真的需要由你将大象装进冰箱。

首先我们需要判断,错误是前端还是后端报的,那么如何快速判断?

方案一:根据对代码的实现的了解,判断报错属于前端还是后端。

这个方案前提是需要你对代码实现很熟悉,也是最简单的方式。

方案二:前端代码全局搜索关键字,工程代码里搜索/控制台打开搜索。

对应工程 gitlab 或者 vscode 或者 devTools global search 里去进行全局搜索。

方案三:翻阅 network 面板中的请求。

翻阅 network 面板中的请求,看下返回的 response 是否携带错误提示,有则表示后端返回的;如果报错的接口刚好是以非200 的状态返回,或者是由新的操作触发调用接口,我们很快就能查找到对应的接口,如下:

方案四:使用 network search 进行搜索。

但是很多情况,接口业务错误会以 http status 200 的状态码返回,如果此时请求了大量的接口(举个例子:进入页面调用了大量的接口,其中有一个接口返回了错误信息),那么除了逐个翻阅 network 这种低效的方式,chrome devTools 还提供了 network search 面板这种更便捷的方式,可以搜索接口详细信息(包括详细的返回信息),返回匹配结果。

如何打开 network search 面板?

在 network 面板中,按快捷键 ⌘ + F(Mac)、 CTRL + F(Windows)可呼出 network search 面板。

如果确定需要你把大象装进冰箱,那把大象装进冰箱的技巧有哪些?

如何快速定位到问题相关的代码

global search ,全局搜素关键字,再定位到关键的代码

chrome devTools 的 global search 是一个非常实用的一个功能,当你不知道需要调试的代码在哪个文件时,当你是一个非常大的系统,引用了很多的资源文件,你可以使用 global search 进行搜索关键字,这个操作会搜索所有加载进来的资源,点击搜索结果,就可以使用 source 面板打开对应的资源文件,然后格式化代码,再然后在当前的文件内 再次搜索关键字,打断点。

打开 global search 快捷键:

⌘ + ⌥ + F (Mac),CTRL + SHIFT + F (Windows)

看下图例子,我们随便找个页面根据提示搜索代码:

可以尝试使用哪些关键字进行搜索:

(1) 页面存在明确的报错信息,且已经明确该错误文案是写在前端代码中错误信息文案。提示信息在 coding 过程中一般是使用 字符串,压缩混淆过程中一般是不会进行处理的,会保留原文,当然代码打包构建过程中,对代码压缩混淆也可以选择对中文进行 unicode 转码,此时如果关键字是中文,就需要先转码再搜索了。

(2) 已知相关代码中存在的编译混淆后依然还保留的的关键代码,会向外暴露的方法名;

如何 debug 混淆后的 js ?

生产环境的 js 基本上都是混淆过的(点击了解前端代码的压缩混淆),压缩混淆的优点就不赘述了,压缩混淆后随之来的是生产环境调试的难度,虽然通过打断点,勉强还能看的懂,但是已经很反人类了。

我们用一个最简单的 demo ,对比一下代码生产环境构建编译前后的差距。

这里选择用 vue-cli 创建了一个最简单的 demo ,看下源代码和编译后的代码。

源代码:

构建编译后的代码(此处关闭了 sourceMap ):

这里我们看到构建编译后的代码做了压缩混淆,出现了出现了大量大的 abcd 替换了原有的函数方法名、变量名,编译后的代码已经不是能通过单纯的读代码码能读懂的了。但是我们通过 debug ,大概还是能看得懂。

那么有没有方式使用本地的 sourceMap 调试生产环境的代码?答案当然是有的。

如何在生产环境使用本地 sourceMap 调试?

第一步:打开混淆代码

第二步:右键 -> 选择【Add source map】

第三步:输入本地 sourceMap 的地址(此处需要启用一个静态资源服务,可以使用 http-server),完成。本地代码执行构建命令,注意需要打开 sourceMap 配置,编译产生出构建后的代码,此时构建后的结果会包含 sourceMap 文件。

关联上 sourceMap 后,我们就可以看到 sources -> page 面板上的变化了

如何在 chrome 中修改代码并调试?

开发环境中,我们可以直接在 IDE 中修改代码,代码的变更就直接更新到了浏览器中了。那么生产环境,我们可以直接在 chrome 中修改代码,然后立马看代码修改后的效果吗?

当然,你想要的 chrome devTools 都有。chrome devTools 提供了 local overrides 能力。

local overrides 如何工作的?

指定修改后的文件的本地保存目录,当修改完代码保存的时候,就会将修改后的文件保存到你指定的目录目录下,当再次加载页面的时候,对应的文件不再读取网络上的文件,而是读取存储在本地修改过的文件。

local overrides 如何使用?

首先,打开 sources 下的 overrides 面板;

然后,点击【select folder overrides】选择修改后的文件存储地址;

再然后,点击顶部的授权,确认同意;

最后,我们就可以打开文件修改,修改完成后保存,重新刷新页面后,修改后的代码就被执行到了。

⚠️注意,原js文件直接 format 是无法修改的;在代码 format 之前先添加无效代码进行代码变更进行保存,然后再 format 就可以修改;

总结

chrome 调试技巧远远当然不只这些,以上只是生产环境 debug 的小技巧,祝愿大家用不到,最好的 bug 处理方式当然是事前,在上线前得到就解决;如果真的发生问题,如果做好监控和日志,在问题发生的第一时间发现并解决。

参考文献

作者:七喜
来源:https://zoo.team/article/prod-debugger

收起阅读 »

JS 的 6 种打断点的方式,你用过几种?

Debugger 是前端开发很重要的一个工具,它可以在我们关心的代码处断住,通过单步运行来理清逻辑。而 Debugger 用的好坏与断点打得好坏有直接的关系。Chrome Devtools 和 VSCode 都提供了 Debugger,它们支持的打断点的方式有...
继续阅读 »

Debugger 是前端开发很重要的一个工具,它可以在我们关心的代码处断住,通过单步运行来理清逻辑。而 Debugger 用的好坏与断点打得好坏有直接的关系。

Chrome Devtools 和 VSCode 都提供了 Debugger,它们支持的打断点的方式有 6 种。

普通断点

在想断住的那一行左侧单击一下就可以添加一个断点,运行到该处就会断住。

这是最基础的断点方式,VSCode 和 Chrome Devtools 都支持这种断点。

条件断点

右键单击代码所在的行左侧,会出现一个下拉框,可以添加一个条件断点。

输入条件表达式,当运行到这一行代码并且表达式的值为真时就会断住,这比普通断点灵活些。

这种根据条件来断住的断点 VSCode 和 Chrome Devtools 也都支持。

DOM 断点

在 Chrome Devtools 的 Elements 面板的对应元素上右键,选择 break on,可以添加一个 dom 断点,也就是当子树有变动、属性有变动、节点移除这三种情况的时候会断住。可以用来调试导致 dom 变化的代码。

因为是涉及到 DOM 的调试,只有 Chrome Devtools 支持这种断点。

URL 断点

在 Chrome Devtools 的 Sources 面板可以添加 XHR 的 url 断点,当 ajax 请求对应 url 时就会断住,可以用来调试请求相关的代码。

这个功能只有 Chrome Devtools 有。

Event Listener 断点

在 Chrome Devtools 的 Sources 面板还可以添加 Event Listener 的断点,指定当发生什么事件时断住,可以用来调试事件相关代码。

这个功能也是只有 Chrome Devtools 有。

异常断点

在 VSCode 的 Debugger 面板勾选 Uncaught Exceptions 和 Caught Exceptions 可以添加异常断点,在抛出异常未被捕获或者被捕获时断柱。用来调试一些发生异常的代码时很有用。

总结

Debugger 打断点的方式除了直接在对应代码行单击的普通断点以外,还有很多根据不同的情况来添加断点的方式。

一共有六种:

  • 普通断点:运行到该处就断住
  • 条件断点:运行到该处且表达式为真就断住,比普通断点更灵活
  • DOM 断点:DOM 的子树变动、属性变动、节点删除时断住,可以用来调试引起 DOM 变化的代码
  • URL 断点:URL 匹配某个模式的时候断住,可以用来调试请求相关代码
  • Event Listener 断点:触发某个事件监听器的时候断住,可以用来调试事件相关代码
  • 异常断点:抛出异常被捕获或者未被捕获的时候断住,可以用来调试发生异常的代码

这些打断点方式大部分都是 Chrome Devtools 支持的(普通、条件、DOM、URL、Event Listener、异常),也有的是 VSCode Debugger 支持的(普通、条件、异常)。

不同情况下的代码可以用不同的打断点方式,这样调试代码会高效很多。

JS 的六种打断点方式,你用过几种呢?

原文:https://juejin.cn/post/7041946855592165389

收起阅读 »

这些都能成为 Web 语法规范,强迫症看不下去了

JavaScript 一直是饱受诟病,源于网景公司在 1995 年用了 10 天的时间创造。没有什么能用 10 天创造就是完美的,可是某些特性一旦发布,错误或不完善的地方迅速成为必不可少的特色,并且是几乎不可能改变。 Javascript 的发展非常快,根本没...
继续阅读 »

JavaScript 一直是饱受诟病,源于网景公司在 1995 年用了 10 天的时间创造。没有什么能用 10 天创造就是完美的,可是某些特性一旦发布,错误或不完善的地方迅速成为必不可少的特色,并且是几乎不可能改变。


Javascript 的发展非常快,根本没有时间调整设计。在推出一年半之后,国际标准就问世了。设计缺陷还没有充分暴露就成了标准。


历史遗留


比如常见的历史设计缺陷:



  • nullundefined 两者非常容易混淆

  • == 类型转换的问题

  • var 声明创建全局变量

  • 自动插入行尾分号

  • 加号可以表示数字之和,也可以表示字符的连接

  • NaN 奇怪的特性

  • 更多...


Javascript 很多不严谨的特性我们可以添加 eslint 来规避。比如禁用 var== 成了大多数人写代码的必备条件。


现在/未来


如今 CSS、DOM、HTML 规范由 W3C 来制定,JavaScript 规范由 TC39 制定。那些历史缺陷也成为了过去,但是现在也出现了一些不尽人意的规范。


CSS 变量


声明变量的时候,变量名前面要加两根连词线 --


body {
--foo: #7f583f;
--bar: #f7efd2;
}

var() 函数用于读取变量。


a {
color: var(--foo);
text-decoration-color: var(--bar, #7f583f);
}

为什么选择两根连词线(--)表示变量?因为 $Sass 用掉,@Less 用掉。_-,用作为 IEchrome 兼容写法。CSS 中已经找不出来字符可以代替变量声明了。为了不产生冲突,官方的 CSS 变量就改用两根连词线。


作为一个官方的标准规范,时刻影响后面的行业发展。竟然能被第三方的插件所左右,令人大跌眼镜。有开发者吐槽:微软的架构师也是够窝囊。


现在很多应用都放弃了 Sassless,转向了 PostCSS 的怀抱。面向组件编程,根本用不到 Sassless 里面的一些复杂功能。那么 -- 两个字符的繁琐将成为开发者永远的痛。


类私有属性(proposal-class-fields)


JavaScript 中的 class 大家已经不陌生了,简直跟 Javaclass 一模一样。


基本用法:


class BaseClass {
msg = 'hello world';

basePublicMethod() {
return this.msg;
}
}

继承:


class SubClass extends BaseClass {
subPublicMethod() {
return super.basePublicMethod();
}
}

静态属性:


class ClassWithStaticField {
static baseStaticMethod() {
return 'base static method output';
}
}

异步方法


class ClassWithFancyMethods {
*generatorMethod() {}
async asyncMethod() {}
async *asyncGeneratorMethod() {}
}

而类私有属性的提案目前已经进入标准,它用了 # 关键字前缀来修饰一个类的属性。


class ClassWithPrivateField {
#privateField;

constructor() {
this.#privateField = 42;
}
}

你没看错,不是 typescript 中的 private 关键字。


class BaseClass {
readonly msg = 'hello world';

private basePrivateMethod() {
return this.msg;
}
}

然而 # 的语法丑陋本身引起了社区的争议:



「class fields 提案提供了一个极具争议的私有字段访问语法——并成功地做对了唯一一件事情,让社区把全部的争议焦点放在了这个语法上」。




TS 投降主义已经被迫实现了。




No dynamic access, no destructuring is a deal breaker for me




我们制作一个 eslint 插件 no-private-class-fields 并使用下载计数来说明社区反对




'#' 作为名称的一部分会导致混淆,因为 this.#x !== this['#x'] 太奇怪了



前端架构师、TC39 成员贺师俊也在知乎连发好几篇文章吐槽 class fields


不妨大家看看关于 private 的 side: johnhax.net/2017/js-pri…


提案地址:github.com/tc39/propos…


globalThis


在不同的 JavaScript 环境中拿到全局对象是需要不同的语句的。在 Web 中,可以通过 windowself 取到全局对象,但是在 Web Workers 中只有 self 可以。在 Node.js 中,必须使用 global。非严格模式下,可以在函数中返回 this 来获取全局对象,否则会返回 undefined


因此一个叫 global 的提案出现。主要用 global 变量统一上面的行为,但后面绕来绕去改成了 globalThis,引起了激烈讨论。


globalThis 这个名字会让 this 变得更加复杂。



  1. this 一直是困扰程序员的话题,尤其是 JavaScript 新手,关于它的博客文章源源不断

  2. ES6 让事情变得更简单,因为可以告诉人们更喜欢箭头函数并且只使用 this 内部方法定义

  3. 在现代 JS(modules) 中,并没有真正的全局 this,所以 globalThis 甚至不引用现有的概念


现在说这一切都是徒劳的,因为它已经进入 stage 4


提案地址:github.com/tc39/propos…


总结


JavaScript 中遗留的糟粕太多。现在受到这些糟粕的影响,很多新的提案又不得不妥协。在未来,它会变得极其复杂。


也许某一天,会出现一个没有历史包袱的 JavaScript 子集来替换它。



作者:MinJie
链接:https://juejin.cn/post/7043340139049222152

收起阅读 »

13 行 JavaScript 代码让你看起来像是高手

Javascript 可以做许多神奇的事情,也有很多东西需要学习,今天我们介绍几个短小精悍的代码段。 获取随机布尔值(True/False) 使用 Math.random() 会返回 0 到 1 的随机数,之后判断它是否大于 0.5,将会得到一个 50% 概率...
继续阅读 »

Javascript 可以做许多神奇的事情,也有很多东西需要学习,今天我们介绍几个短小精悍的代码段。


获取随机布尔值(True/False)


使用 Math.random() 会返回 0 到 1 的随机数,之后判断它是否大于 0.5,将会得到一个 50% 概率为 TrueFalse 的值


const randomBoolean = () => Math.random() >= 0.5;
console.log(randomBoolean());

判断一个日期是否是工作日


判断给定的日期是否是工作日


const isWeekday = (date) => date.getDay() % 6 !== 0;
console.log(isWeekday(new Date(2021, 0, 11)));
// Result: true (周一)
console.log(isWeekday(new Date(2021, 0, 10)));
// Result: false (周日)

反转字符串


有许多反转字符串的方法,这里使用一种最简单的,使用了 split()reverse()join()


const reverse = str => str.split('').reverse().join('');
reverse('hello world');
// Result: 'dlrow olleh'

判断当前标签页是否为可视状态


浏览器可以打开很多标签页,下面 👇🏻 的代码段就是判断当前标签页是否是激活的标签页


const isBrowserTabInView = () => document.hidden;
isBrowserTabInView();

判断数字为奇数或者偶数


取模运算符 % 可以很好地完成这个任务


const isEven = num => num % 2 === 0;
console.log(isEven(2));
// Result: true
console.log(isEven(3));
// Result: false

从 Date 对象中获取时间


使用 Date 对象的 .toTimeString() 方法转换为时间字符串,之后截取字符串即可


const timeFromDate = date => date.toTimeString().slice(0, 8);
console.log(timeFromDate(new Date(2021, 0, 10, 17, 30, 0)));
// Result: "17:30:00"
console.log(timeFromDate(new Date()));
// Result: 返回当前时间

保留指定的小数位


const toFixed = (n, fixed) => ~~(Math.pow(10, fixed) * n) / Math.pow(10, fixed);
// Examples
toFixed(25.198726354, 1); // 25.1
toFixed(25.198726354, 2); // 25.19
toFixed(25.198726354, 3); // 25.198
toFixed(25.198726354, 4); // 25.1987
toFixed(25.198726354, 5); // 25.19872
toFixed(25.198726354, 6); // 25.198726

检查指定元素是否处于聚焦状态


可以使用 document.activeElement 来判断元素是否处于聚焦状态


const elementIsInFocus = (el) => (el === document.activeElement);
elementIsInFocus(anyElement)
// Result: 如果处于焦点状态会返回 True 否则返回 False

检查当前用户是否支持触摸事件


const touchSupported = () => {
('ontouchstart' in window || window.DocumentTouch && document instanceof window.DocumentTouch);
}
console.log(touchSupported());
// Result: 如果支持触摸事件会返回 True 否则返回 False

检查当前用户是否是苹果设备


可以使用 navigator.platform 判断当前用户是否是苹果设备


const isAppleDevice = /Mac|iPod|iPhone|iPad/.test(navigator.platform);
console.log(isAppleDevice);
// Result: 是苹果设备会返回 True

滚动至页面顶部


window.scrollTo() 会滚动至指定的坐标,如果设置坐标为(0,0),就会回到页面顶部


const goToTop = () => window.scrollTo(0, 0);
goToTop();
// Result: 将会滚动至顶部

获取所有参数的平均值


可以使用 reduce() 函数来计算所有参数的平均值


const average = (...args) => args.reduce((a, b) => a + b) / args.length;
average(1, 2, 3, 4);
// Result: 2.5

转换华氏/摄氏


再也不怕处理温度单位了,下面两个函数是两个温度单位的相互转换。


const celsiusToFahrenheit = (celsius) => celsius * 9/5 + 32;
const fahrenheitToCelsius = (fahrenheit) => (fahrenheit - 32) * 5/9;
// Examples
celsiusToFahrenheit(15); // 59
celsiusToFahrenheit(0); // 32
celsiusToFahrenheit(-20); // -4
fahrenheitToCelsius(59); // 15
fahrenheitToCelsius(32); // 0

感谢阅读,希望你会有所收获😄


作者:夜色镇歌
链接:https://juejin.cn/post/7043062481954013197

收起阅读 »

由于包名引发的惨案(安装 apk 闪退,拍照闪退,manifest》Provider》authorities导致的)

我们项目原本是这样的,在项目开始之初定的报名是 com.b.c ,然后为了让用户能成功从 1.0 升级到 2.0 ,在项目要开发完成以后改了包名 com.a.b,由于直接改整个项目目录结果并不简单,于是我们直接改了 app/build.gradle 下的 ap...
继续阅读 »

我们项目原本是这样的,在项目开始之初定的报名是 com.b.c ,然后为了让用户能成功从 1.0 升级到 2.0 ,在项目要开发完成以后改了包名 com.a.b,由于直接改整个项目目录结果并不简单,于是我们直接改了 app/build.gradle 下的 applicationId ,改成了最新的 com.a.b 。之前在编写程序内升级的时候,在 AndroidManifest.xml 中编写的 <provider> 是下面这样的:


<provider
    android:name="androidx.core.content.FileProvider"
    android:authorities="com.b.c.fileprovider"
    android:exported="false"
android:grantUriPermissions="true">
    <meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_paths" />
</provider>

在使用的过程中是这样的(部分代码):


Uri uri = FileProvider.getUriForFile(context, context.getPackageName() + ".fileprovider", apk);

我们项目中包含有 react-native 代码,同时装了不少插件,其中一个插件 react-native-webviewAndroidManifest.xml 中也定义了 <provider> ,是这样的:


<provider
android:name=".RNCWebViewFileProvider"
    android:authorities="${applicationId}.fileprovider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_provider_paths" />
</provider>

之前我们的升级一直都很完美,每一次都很成功;有一天我们领导决定抛弃 react-native ,全部改用 h5 ,于是我就负责把 react-native 相关的代码从项目中删除,删除的过程非常愉快与自然,删除成功以后我验证了删除部分的相关功能,发现一切正常。


很快项目迎来了更新,一切都那么理所当然,用户正常升级,删除的 react-native 并没有给项目带来问题,随着时间的推进,很快第二批功能开发完毕,即将迎来再一次的更新,我认为这次更新内容少,还加上测试也测试通过,应该没啥问题,但是坏消息在第二天早上发生了,大面积的升级失败,闪退率直线上升,于是我们根据现象尝试复现,发现这是必现的 bug


在这个时候我很高兴,但也很悲伤,高兴的是 bug 是百分之百复现,悲伤的是,由于我的原因让用户体验急剧下滑,我知道,目前要做的是用最快的速度修复 bug ,让更少的人“受伤”。


通过我的排查,发现是包名导致的,因为报错信息直指报错的那一行,信息提示:


Caused by: java.lang.IllegalArgumentException: Couldn't find meta-data for provider with authority com.a.b.fileprovider

于是我看了看 AndroidManifest.xml 文件,发现我们的 <provider>authorities 是写死的 com.b.c.fileprovider ,我知道出现问题的原因就是在这里,于是我就将配置改成下面这样:


<provider
    android:name="androidx.core.content.FileProvider"
    android:authorities="${applicationId}.fileprovider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_paths" />
</provider>

改完以后赶快打了一个补救包,上传了上去,我认为问题已经解决,但是我们没有找到原因,首先要定位的是什么代码导致的这个问题,为什么以前可以,于是开始查看提交记录和合并记录,最终定位到是因为 react-native 的删除导致的,但是又产生了一个问题,为什么我删除 react-native 会导致这个问题,等我还在纠结的时候,突然反馈 app 拍照功能不能使用,这个功能是我们 app 的核心功能,一下从原来的无伤大雅变成了遍体鳞伤,这下整个部门都在问什么原因,于是我赶快放下脑中的疑惑,开始去项目的茫茫大海中寻找答案,我知道答案就在那里,也就是跟包相关的,于是根据问题,我检查了跟包相关的代码,发现在拍照的地方由于要保存,代码(部分)如下:


private const val authorities = "com.b.a.fileprovider"
FileProvider.getUriForFile(requireContext(), authorities, file)

我知道是由于我之前把 AndroidManifest.xml 改了以后导致的。于是我就把相关的代码都检查了一遍,确定都跟包名想通了,我才打包给测试,测试完成以后才再一次上线。


这下问题都被我解决了,只不过脑袋里面仍然有很多疑惑,之前我从 react-native 开发的时候由于看原生代码比较困难,现在我觉得我能找到这个问题的最终答案,于是开始了我的寻找问题之旅。


首先回到刚才的问题,为啥删除 react-native 会对包名造成影响呢,于是我开始复原删除之前,通过递减删除的方式排查,看看到底是那一行删除导致的。


其实认真看到这里的小伙伴肯定知道,并不是 react-native 的问题,而是本身我们代码编写的有问题,所以准确的说是 react-native 的什么代码屏蔽了问题。其中 react-native 嵌入原生是根据集成到现有原生应用引入的。在使用排除法的过程中,发现在 app/build.gradle 中配置:


apply from: file("../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesAppBuildGradle(project)

是这行代码导致的,于是我尝试看这个 native_modules.gradle 文件,首先我从构造函数看起,其实我不会 groovy 语言,只是我大致看了看发现跟 java 差不多,所以上面的代码大差不差能够看懂,先看构造:


ReactNativeModules(Logger logger, File root) {
    this.logger = logger
    this.root = root
    def (nativeModules, packageName) = this.getReactNativeConfig()
    this.reactNativeModules = nativeModules
    this.packageName = packageName
}

这里有 packageName ,于是我就想是不是因为执行这个 this.getReactNativeConfig() 修改了 packageName ,其实我一直不相信会修改包名,但是我不敢确定,毕竟我刚接触 android 不久。于是我就继续看这个函数的实现:


ArrayList<HashMap<String, String>> getReactNativeConfig() {
    if (this.reactNativeModules != null) return this.reactNativeModules
    ArrayList<HashMap<String, String>> reactNativeModules = new ArrayList<HashMap<String, String>>()
    def cliResolveScript = "console.log(require('react-native/cli').bin);"
    String[] nodeCommand = ["node", "-e", cliResolveScript]
    def cliPath = this.getCommandOutput(nodeCommand, this.root)
    String[] reactNativeConfigCommand = ["node", cliPath, "config"]
    def reactNativeConfigOutput = this.getCommandOutput(reactNativeConfigCommand, this.root)
    def json
    try {
      json = new JsonSlurper().parseText(reactNativeConfigOutput)
    } catch (Exception exception) {
      throw new Exception("Calling `${reactNativeConfigCommand}` finished with an exception. Error message: ${exception.toString()}. Output: ${reactNativeConfigOutput}");
    }
    def dependencies = json["dependencies"]
    def project = json["project"]["android"]
    if (project == null) {
      throw new Exception("React Native CLI failed to determine Android project configuration. This is likely due to misconfiguration. Config output:\n${json.toMapString()}")
    }
    dependencies.each { name, value ->
      def platformsConfig = value["platforms"];
      def androidConfig = platformsConfig["android"]
      if (androidConfig != null && androidConfig["sourceDir"] != null) {
        this.logger.info("${LOG_PREFIX}Automatically adding native module '${name}'")
        HashMap reactNativeModuleConfig = new HashMap<String, String>()
        reactNativeModuleConfig.put("name", name)
        reactNativeModuleConfig.put("nameCleansed", name.replaceAll('[~*!\'()]+', '_').replaceAll('^@([\\w-.]+)/', '$1_'))
        reactNativeModuleConfig.put("androidSourceDir", androidConfig["sourceDir"])
        reactNativeModuleConfig.put("packageInstance", androidConfig["packageInstance"])
        reactNativeModuleConfig.put("packageImportPath", androidConfig["packageImportPath"])
        this.logger.trace("${LOG_PREFIX}'${name}': ${reactNativeModuleConfig.toMapString()}")
        reactNativeModules.add(reactNativeModuleConfig)
      } else {
        this.logger.info("${LOG_PREFIX}Skipping native module '${name}'")
      }
    }
    return [reactNativeModules, json["project"]["android"]["packageName"]];
  }
}

发现这里实际上是从 nodejs 执行结果拿到的信息,而执行的 js 文件的位置在 rn项目/node_modules/react-native/node_modules/@react-native-community/cli/build/index.js 下,这里是具体执行的 js 文件,前面还有一个 js 文件,只不过没有代码,就是执行这里面的 run 方法:


async function run() {
  try {
    await setupAndRun();
  } catch (e) {
    handleError(e);
  }
}

接着看 setupAndRun() 函数:


async function setupAndRun() {
  if (process.argv.includes('config')) {
    _cliTools().logger.disable();
  }
  _cliTools().logger.setVerbose(process.argv.includes('--verbose')); // We only have a setup script for UNIX envs currently
  if (process.platform !== 'win32') {
    const scriptName = 'setup_env.sh';
    const absolutePath = _path().default.join(__dirname, '..', scriptName);
    try {
      _child_process().default.execFileSync(absolutePath, {
        stdio: 'pipe',
      });
    } catch (error) {
      _cliTools().logger.warn(
        `Failed to run environment setup script "${scriptName}"\n\n${_chalk().default.red(
          error,
        )}`,
      );
      _cliTools().logger.info(
        `React Native CLI will continue to run if your local environment matches what React Native expects. If it does fail, check out "${absolutePath}" and adjust your environment to match it.`,
      );
    }
  }
  for (const command of _commands.detachedCommands) {
    attachCommand(command);
  }
  try {
    const config = (0, _config.default)();
    _cliTools().logger.enable();
    for (const command of [..._commands.projectCommands, ...config.commands]) {
      attachCommand(command, config);
    }
  } catch (error) {
    if (error.message.includes("We couldn't find a package.json")) {
      _cliTools().logger.enable();
      _cliTools().logger.debug(error.message);
      _cliTools().logger.debug(
        'Failed to load configuration of your project. Only a subset of commands will be available.',
      );
    } else {
      throw new (_cliTools().CLIError)(
        'Failed to load configuration of your project.',
        error,
      );
    }
  }
  _commander().default.parse(process.argv);
  if (_commander().default.rawArgs.length === 2) {
    _commander().default.outputHelp();
  }
  if (
    _commander().default.args.length === 0 &&
    _commander().default.rawArgs.includes('--version')
  ) {
    console.log(pkgJson.version);
  }
}

经过我打印日志,最终发现是 _commander().default.parse(process.argv) 这行代码返回给 groovy 的,但是我发现这行代码也只是读取配置的,跟修改不相关,于是我就开始假设,有没有可能是 groovy 最终修改,只是从 js 拿到相关的信息,于是我就直接把拿到的值进行修改,也就是 native_modules.gradle 里面的 this.getReactNativeConfig 函数返回值,于是我做了修改了:


ArrayList<HashMap<String, String>> getReactNativeConfig() {
    if (this.reactNativeModules != null) return this.reactNativeModules
    ArrayList<HashMap<String, String>> reactNativeModules = new ArrayList<HashMap<String, String>>()
    def dependencies = new JsonSlurper().parseText('{"react-native-webview":{"root":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview","name":"react-native-webview","platforms":{"ios":{"sourceDir":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview/ios","folder":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview","pbxprojPath":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview/ios/RNCWebView.xcodeproj/project.pbxproj","podfile":null,"podspecPath":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview/react-native-webview.podspec","projectPath":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview/ios/RNCWebView.xcodeproj","projectName":"RNCWebView.xcodeproj","libraryFolder":"Libraries","sharedLibraries":[],"plist":[],"scriptPhases":[]},"android":{"sourceDir":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview/android","folder":"/Users/wujingyue/Works/yq-bss-tour-rn/node_modules/react-native-webview","packageImportPath":"import com.reactnativecommunity.webview.RNCWebViewPackage;","packageInstance":"new RNCWebViewPackage()"}},"assets":[],"hooks":{},"params":[]}}')
dependencies.each { name, value ->
      def platformsConfig = value["platforms"];
      def androidConfig = platformsConfig["android"]
      if (androidConfig != null && androidConfig["sourceDir"] != null) {
        this.logger.info("${LOG_PREFIX}Automatically adding native module '${name}'")
        HashMap reactNativeModuleConfig = new HashMap<String, String>()
        reactNativeModuleConfig.put("name", name)
        reactNativeModuleConfig.put("nameCleansed", name.replaceAll('[~*!\'()]+', '_').replaceAll('^@([\\w-.]+)/', '$1_'))
        reactNativeModuleConfig.put("androidSourceDir", androidConfig["sourceDir"])
        reactNativeModuleConfig.put("packageInstance", androidConfig["packageInstance"])
        reactNativeModuleConfig.put("packageImportPath", androidConfig["packageImportPath"])
        this.logger.trace("${LOG_PREFIX}'${name}': ${reactNativeModuleConfig.toMapString()}")
        reactNativeModules.add(reactNativeModuleConfig)

      } else {
        this.logger.info("${LOG_PREFIX}Skipping native module '${name}'")
      }
    }
// 这儿直接返回我想要的值 com.a.b
    return [reactNativeModules, "com.a.b"];
  }
}

其中 dependencies 变量的值远不止这些,很多个。首先我让 dependencies 的值是一个空值,也就是 new JsonSlurper().parseText('{}') ,然后我发现居然不行了,也就是升级闪退,之前是可以的;于是我根据这个现象提出假设,是由于这个字符串中的某一个插件导致的,于是我就根据这个假设开始把一个个插件放入其中进行测试,最后发现 react-native-webview ,你不知道的是 react-native-webview 是最后一个插件,我把前面所有的都测试了,真的是又喜又悲,终于我把范围进一步缩小了,接下来,我就开始对插件 react-native-webview 的代码进行检查。


我最喜欢的还是“注释法”,也就是经典的“排除法”,我首先把所有代码都注释掉,只剩下空壳,发现仍然可以正常安装,说明不是在代码上,然后我再对插件的 build.gradle 采用“注释法”,结果还是可以,说明不是在这里,这时我感觉到无力,但是这个时候我突然想到“山重水复疑无路,柳暗花明又一村”,于是我开始对整个插件的每个文件进行检查,然后一个文件出现在我眼前 AndroidManifest.xml ,我打开看了看,看到了这个插件也定义了 <provider> 。而且是正确的方式,于是我又提出假设来解释现象,如果 AndroidManifest.xml 最终采用的是插件 react-native-webview<provider> ,那么就能解释这个原因了,但这仅仅是假设,我得在实践中证明我的假设是正确的。


首先我尝试修改 react-native-webview 插件中的 AndroidManifest.xml 下的 authorities ,我首先修改成跟项目的相同,结果闪退,符合我得猜想,说明项目的确会进行合并,于是我开始翻阅文档进一步证明我的结论,首先我看了看 AndroidManifest.xml 配置相关的文档 ,我看到了下面这句描述,也就是代表 authorities 支持多个。



android:authorities

一个或多个 URI 授权方的列表,这些 URI 授权方用于标识内容提供程序提供的数据。列出多个授权方时,用分号将其名称分隔开来。为避免冲突,授权方名称应遵循 Java 样式的命名惯例(如com.example.provider.cartoonprovider)。通常,它是实现提供程序的ContentProvider子类的名称。

没有默认值。必须至少指定一个授权方。



第一次看到这个我没想到啥,只不过后面文档让我想到了这个,然后做了验证,最终找到了答案。首先是同事找到了合并多个清单文件这个,证实了 AndroidManifest.xml 会合并的假设,然后又看到了这个检查合并后的清单并查找冲突
image.png
然后我去看了看我们的项目,发现了这个,并且我看了看合并后的内容,发现 react-native-webview 的在最后,也就是会替换项目中 authorities ,但是我仔细看了看这个文件,发现下面还有定义的 authorities ,也就是说,如果是覆盖是说不通的,因为后面的 authorities 就会导致报错,但是实际上并没有,于是我尝试修改使用的地方,把 FileProvider.getUriForFile(requireContext(), authorities, file) 中的第二个参数改成这些定义的,发现仍然能成功,也就是说我们定义的所有这些都会生效,于是我想到了上面的那句被我标记为红色的话,发现一切迷雾都解开了。


到这里可以说结束了,但我在想为啥会这样设计呢?我最后想到的答案是,对于那些插件来说,他并不知道别人项目中的 authorities 定义,那怎么保证插件可以到处使用呢,答案很显然,那就是多个生效,插件不需要知道项目中是怎样定义的,只需要使用自己插件中定义好的。


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

Activity基础知识—四大组件

Activity Activity的生命周期 真的没什么难度,大家自行了解。 有些会问到横竖屏切换的生命周期。 Activity A 启动 Activity B,然后B再返回A,他们的生命周期怎么走 需要考虑一下B是不是透明的,透明盒不透明生命周期是不一样...
继续阅读 »

Activity


Activity的生命周期


真的没什么难度,大家自行了解。
有些会问到横竖屏切换的生命周期。

Activity A 启动 Activity B,然后B再返回A,他们的生命周期怎么走


需要考虑一下B是不是透明的,透明盒不透明生命周期是不一样的。
需要考虑 B 的启动模式,不同的启动模式会有一定的区别。

Activity在走了哪个生命周期之后会显示出来


onResume()
简单来说就是:在onResume回调之后,会创建一个 ViewRootImpl ,有了它之后应用端就可以和 WMS 进行双向调用了。

Activity的启动模式有哪些


没什么难度,大家自行了解。

Activity的启动流程


1、点击桌面App图标,Launcher进程采用Binder IPC(AMS)向system_server进程发起startActivity请求; 
2、system_server进程接收到请求后,向zygote进程发送创建进程的请求;
3、Zygote进程fork出新的子进程,即App进程;
4、App进程,通过Binder IPC向sytem_server进程发起attachApplication请求;
5、system_server进程在收到请求后,进行一系列准备工作后,再通过binder IPC向App进程发送scheduleLaunchActivity请求;
6、App进程的binder线程(ApplicationThread)在收到请求后,通过handler向主线程发送LAUNCH_ACTIVITY消息;
7、主线程在收到Message后,通过发射机制创建目标Activity,并回调Activity.onCreate()等方法。

Fragment的生命周期,Fragment和Activity之间的传参


需要区别Fragment和Activity之间的生命周期
1.Activity–onCreate();
2.Fragment–onAttach();
3.Fragment–onCreate();
4.Fragment–onCreateView();
5.Fragment–onActivityCreated();

接着是这样的:
6.Activity–onStart();
7.Fragment–onStart();
8.Activity–onResume();
9.Fragment–onResume();

当销毁的时候
10.Fragment–onPause();
11.Activity–onPause();
12.Fragment–onStop();
13.Activity–onStop();
14.Fragment–onDestroyView();
15.Fragment–onDestroy();
16.Fragment–onDetach();
17.Activity–onDestroy();

Service


Service的生命周期


image.png


IntentService和Service区别


IntentService内部实现了一个线程,可以去执行耗时操作

HandlerThread


继承自Thread,内部创建了一个Looper

Service和Thread的区别还有优缺点


Service 是android的一种机制Service 是运行在主进程的 main 线程上的。
Thread会开辟一个线程去执行它是分配CPU的基本单位。

进程的几种类型


前台进程
可视进程
服务进程
后台进程

Broadcast


有哪几类广播


普通广播(自定义广播)
系统广播
有序广播
粘性广播
应用内广播

LocalBroadcast的实现原理


ContentProvider


image.png


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

SwiftUI开发小技巧总结(不定期更新)

iOS
目前SwiftUI还不完善,而且实际使用还会存在一些缺陷。网上的教程目前还很少,有也是收费的。因此特地整理一些平时开发中遇到的问题,免费提供给读者。 (注:本文主要面向对SwiftUI有一定基础的读者。) 调整状态栏样式 StatusBarStyle 尝试In...
继续阅读 »

目前SwiftUI还不完善,而且实际使用还会存在一些缺陷。网上的教程目前还很少,有也是收费的。因此特地整理一些平时开发中遇到的问题,免费提供给读者。


(注:本文主要面向对SwiftUI有一定基础的读者。)


调整状态栏样式 StatusBarStyle


尝试Info.plistUIApplication.statusBarStyle方法无效。如果有UIViewController作为根视图,重写方法preferredStatusBarStyle,这样可以控制全局;如果要设置单个页面的样式用preferredColorScheme(.light),但测试似乎设置无效。还有另一个方法:stackoverflow.com/questions/5…


调整导航栏样式 NavigationBar


let naviAppearance = UINavigationBarAppearance()
naviAppearance.configureWithOpaqueBackground() // 不透明背景样式
naviAppearance.backgroundColor = UIColor.whiteColor // 背景色
naviAppearance.shadowColor = UIColor.whiteColor // 阴影色
naviAppearance.titleTextAttributes = [:] // 标题样式
naviAppearance.largeTitleTextAttributes = [:] // 大标题样式
UINavigationBar.appearance().standardAppearance = naviAppearance
UINavigationBar.appearance().compactAppearance = naviAppearance
UINavigationBar.appearance().scrollEdgeAppearance = naviAppearance
UINavigationBar.appearance().tintColor = UIColor.blackColor // 导航栏按钮颜色


注意configureWithOpaqueBackground()需要在其它属性设置之前调用,除此之外还有透明背景configureWithTransparentBackground(),设置背景模糊效果backgroundEffect(),背景和阴影图片等,以及导航栏按钮样式也可修改。


调整标签栏样式 TabBar


let itemAppearance = UITabBarItemAppearance()
itemAppearance.normal.iconColor = UIColor.whiteColor // 正常状态的图标颜色
itemAppearance.normal.titleTextAttributes = [:] // 正常状态的文字样式
itemAppearance.selected.iconColor = UIColor.whiteColor // 选中状态的图标颜色
itemAppearance.selected.titleTextAttributes = [:] // 选中状态的文字样式
let tabBarAppearance = UITabBarAppearance()
tabBarAppearance.configureWithOpaqueBackground() // 不透明背景样式
tabBarAppearance.stackedLayoutAppearance = itemAppearance
tabBarAppearance.backgroundColor = UIColor.whiteColor // 背景色
tabBarAppearance.shadowColor = UIColor.clear // 阴影色
UITabBar.appearance().standardAppearance = tabBarAppearance


注意configureWithOpaqueBackground()同样需要在其它属性设置之前调用,和UINavigationBarAppearance一样有同样的设置,除此之外还可以为每个标签项设置指示器外观。


标签视图 TabView


设置默认选中页面:方法如下,同时每个标签项需要设置索引值tag()


TabView(selection: $selectIndex, content: {})
复制代码

控制底部标签栏显示和隐藏:


UITabBar.appearance().isHidden = true


NavigationView与TabView结合使用时,进入子页面TabBar不消失问题:不用默认的TabBar,将其隐藏,自己手动实现一个TabBar,放在根视图中。


键盘


输入框获得焦点(弹出键盘):在iOS15上增加了方法focused(),注意这个方法在视图初始化时是无效的,需要在onAppear()中延迟一定时间调用才可以。在此之前的系统只能自定义控件的方法实现参考这个:stackoverflow.com/questions/5…


关闭键盘,两种方法都可以:


UIApplication.shared.keyWindow?.endEditing(true)
UIApplication.shared.sendAction(#selector(UIResponder.resignFirstResponder), to: nil, from: nil, for: nil)


添加键盘工具栏:


.toolbar()


手势


获得按下和松开的状态:


.simultaneousGesture(
DragGesture(minimumDistance: 0)
    .onChanged({ _ in })
    .onEnded({ _ in })
)


通过代码滚动ScrollView到指定位置:借助ScrollViewReader可以获取位置,在onAppear()中设置位置scrollTo(),我们实际使用发现,需要做个延迟执行才会有效,可以把执行放在DispatchQueue.main.async()中执行。


TextEditor


修改背景色:


UITextView.appearance().backgroundColor


处理Return键结束编辑:


.onChange(of: text) { value in
if value.last == "\n" {
UIApplication.shared.keyWindow?.endEditing(true)
}
}


Text文本内部对齐方式


multilineTextAlignment(.center)


页面跳转


容易出错的情况:开发中会经常遇到这样的需求,列表中选择一项,进入子页面。点击按钮返回上一页。此时再次点击列表中的某一项,会发现显示的页面内容是错误的。如果你是用NavigationLink做页面跳转,并传递了isActive参数,那么是会遇到这样的问题。原因在于多个页面的使用的是同一个isActive参数。解决办法是,列表中每一项都用独立的变量控制。NavigationView也尽量不要写在TabView外面,可能会导致莫名其妙的问题。


属性包装器在init中的初始化


init方法中直接赋值会发现无法成功,应该用属性包装器自身的方法包装起来,赋值的属性名前加_,例如:


_value = State<Int>(initialValue: 1)
_value = Binding<Bool>.constant(true) // 也可以使用Swift语法特性直接写成.constant(true)


View如何忽略触摸事件


allowsHitTesting(false)

作者:iOS技术小组
链接:https://juejin.cn/post/7037780197076123685

收起阅读 »

设计一套完整的日志系统

iOS
需求日志对于线上排查问题是非常重要的,很多问题其实是很偶现的,同样的系统版本,同样的设备,可能就是用户的复现,而开发通过相同的操作和设备就是不复现。但是这个问题也不能一直不解决,所以可以通过日志的方式排查问题。可能是后台导致的问题,也可能是客户端逻辑问题,在关...
继续阅读 »

需求

日志对于线上排查问题是非常重要的,很多问题其实是很偶现的,同样的系统版本,同样的设备,可能就是用户的复现,而开发通过相同的操作和设备就是不复现。但是这个问题也不能一直不解决,所以可以通过日志的方式排查问题。可能是后台导致的问题,也可能是客户端逻辑问题,在关键点记录日志可以快速定位问题。

假设我们的用户量是一百万日活,其中有1%的用户使用出现问题,即使这个问题并不是崩溃,就是业务上或播放出现问题。那这部分用户就是一万的用户,一万的用户数量是很庞大的。而且大多数用户在遇到问题后,并不会主动去联系客服,而是转到其他平台上。

虽然我们现在有Kibana网络监控,但是只能排查网络请求是否有问题,用户是否在某个时间请求了服务器,服务器下发的数据是否正确,但是如果定位业务逻辑的问题,还是要客户端记录日志。

现状

我们项目中之前有日志系统,但是从业务和技术的角度来说,存在两个问题。现有的日志系统从业务层角度,需要用户手动导出并发给客服,对用户有不必要的打扰。而且大多数用户并不会答应客服的请求,不会导出日志给客服。从技术的角度,现有的日志系统代码很乱,而且性能很差,导致线上不敢持续记录日志,会导致播放器卡顿。

而且现有的日志系统仅限于debug环境开启主动记录,线上是不开启的,线上出问题后需要用户手动打开,并且记录时长只有三分钟。正是由于现在存在的诸多问题,所以大家对日志的使用并不是很积极,线上排查问题就比较困难。

方案设计

思路

正是针对现在存在的问题,我准备做一套新的日志系统,来替代现有的日志系统。新的日志系统定位很简单,就是纯粹的记录业务日志。Crash、埋点这些,我们都不记录在里面,这些可以当做以后的扩展。日志系统就记录三种日志,业务日志、网络日志、播放器日志。

日志收集我们采用的主动回捞策略,在日志平台上填写用户的uid,通过uid对指定设备下发回捞指令,回捞指令通过长连接的方式下发。客户端收到回捞指令后,根据筛选条件对日志进行筛选,随后以天为单位写入到不同的文件中,压缩后上传到后端。

在日志平台可以根据指定的条件进行搜索,并下载文件查看日志。为了便于开发者查看日志,从数据库取出的日志都会写成.txt形式,并上传此文件。

API设计

对于调用的API设计,应该足够简单,业务层使用时就像调用NSLog一样。所以对于API的设计方案,我采用的是宏定义的方式,调用方法和NSLog一样,调用很简单。

#if DEBUG
#define SVLogDebug(frmt, ...) [[SVLogManager sharedInstance] mobileLogContent:(frmt), ##__VA_ARGS__]
#else
#define SVLogDebug(frmt, ...) NSLog(frmt, ...)
#endif

日志总共分为三种类型,业务日志、播放器日志、网络日志,对于三种日志分别对应着不同的宏定义。不同的宏定义,写入数据库的类型也不一样,可以用户日志筛选。

  • 业务日志:SVLogDebug
  • 播放器日志:SVLogDebugPlayer
  • 网络日子:SVLogDebugQUIC

淘汰策略

不光是要往数据库里写,还需要考虑淘汰策略。淘汰策略需要平衡记录的日志数量,以及时效性的问题,日志数量尽量够排查问题,并且还不会占用过多的磁盘空间。所以,在日志上传之后会将已上传日志删除掉,除此之外日志淘汰策略有以下两种。

  1. 日志最多只保存三天,三天以前的日志都会被删掉。在应用启动后进行检查,并后台线程执行这个过程。
  2. 日志增加一个最大阈值,超过阈值的日志部分,以时间为序,从前往后删除。我们定义的阈值大小为200MB,一般不会超过这个大小。

记录基础信息

在排查问题时一些关键信息也很重要,例如用户当时的网络环境,以及一些配置项,这些因素对代码的执行都会有一些影响。对于这个问题,我们也会记录一些用户的配置信息及网络环境,方便排查问题,但不会涉及用户经纬度等隐私信息。

数据库

旧方案

之前的日志方案是通过DDLog实现的,这种方案有很严重的性能问题。其写入日志的方式,是通过NSData来实现的,在沙盒创建一个txt文件,通过一个句柄来向本地写文件,每次写完之后把句柄seek到文件末尾,下次直接在文件末尾继续写入日志。日志是以NSData的方式进行处理的,相当于一直在频繁的进行本地文件写入操作,还要在内存中维持一个或者多个句柄对象。

这种方式还有个问题在于,因为是直接进行二进制写入,在本地存储的是txt文件。这种方式是没有办法做筛选之类的操作的,扩展性很差,所以新的日志方案我们打算采用数据库来实现。

方案选择

我对比了一下iOS平台主流的数据库,发现WCDB是综合性能最好的,某些方面比FMDB都要好,而且由于是C++实现的代码,所以从代码执行的层面来讲,也不会有OC的消息发送和转发的额外消耗。

根据WCDB官网的统计数据,WCDBFMDB进行对比,FMDB是对SQLite进行简单封装的框架,和直接用SQLite差别不是很大。而WCDB则在sqlcipher的基础上进行的深度优化,综合性能比FMDB要高,以下是性能对比,数据来自WCDB官方文档。

单次读操作WCDB要比FMDB5%左右,在for循环内一直读。

15906481049447.jpg

单次写操作WCDB要比FMDB28%,一个for循环一直写。

15906481114970.jpg

批量写操作比较明显,WCDB要比FMDB180%,一个批量任务写入一批数据。

15906481277664.jpg

从数据可以看出,WCDB在写操作这块性能要比FMDB要快很多,而本地日志最频繁的就是写操作,所以这正好符合我们的需求,所以选择WCDB作为新的数据库方案是最合适的。而且项目中曝光模块已经用过WCDB,证明这个方案是可行并且性能很好的。

表设计

我们数据库的表设计很简单,就下面四个字段,不同类型的日志用type做区分。如果想增加新的日志类型,也可以在项目中扩展。因为使用的是数据库,所以扩展性很好。

  • index:主键,用来做索引。
  • content:日志内容,记录日志内容。
  • createTime:创建时间,日志入库的时间。
  • type:日志类型,用来区分三种类型。

数据库优化

我们是视频类应用,会涉及播放、下载、上传等主要功能,这些功能都会大量记录日志,来方便排查线上问题。所以,避免数据库太大就成了我在设计日志系统时,比较看重的一点。

根据日志规模,我对播放、下载、上传三个模块进行了大量测试,播放一天两夜、下载40集电视剧、上传多个高清视频,累计记录的日志数量大概五万多条。我发现数据库文件夹已经到200MB+的大小,这个大小已经是比较大的,所以需要对数据库进行优化。

我观察了一下数据库文件夹,有三个文件,dbshmwal,主要是数据库的日志文件太大,db文件反而并不大。所以需要调用sqlite3_wal_checkpointwal内容写入到数据库中,这样可以减少walshm文件的大小。但WCDB并没有提供直接checkpoint的方法,所以经过调研发现,执行database的关闭操作时,可以触发checkpoint

我在应用程序退出时,监听了terminal通知,并且把处理实际尽量靠后。这样可以保证日志不被遗漏,而且还可以在程序退出时关闭数据库。经过验证,优化后的数据库磁盘占用很小。143,987条数据库,数据库文件大小为34.8MB,压缩后的日志大小为1.4MB,解压后的日志大小为13.6MB

wal模式

这里顺带讲一下wal模式,以方便对数据库有更深入的了解。SQLite3.7版本加入了wal模式,但默认是不开启的,iOS版的WCDBwal模式自动开启,并且做了一些优化。

wal文件负责优化多线程下的并发操作,如果没有wal文件,在传统的delete模式下,数据库的读写操作是互斥的,为了防止写到一半的数据被读到,会等到写操作执行完成后,再执行读操作。而wal文件就是为了解决并发读写的情况,shm文件是对wal文件进行索引的。

SQLite比较常用的deletewal两种模式,这两种模式各有优势。delete是直接读写db-page,读写操作的都是同一份文件,所以读写是互斥的,不支持并发操作。而walappend新的db-page,这样写入速度比较快,而且可以支持并发操作,在写入的同时不读取正在操作的db-page即可。

由于delete模式操作的db-page是离散的,所以在执行批量写操作时,delete模式的性能会差很多,这也就是为什么WCDB的批量写入性能比较好的原因。而wal模式读操作会读取dbwal两个文件,这样会一定程度影响读数据的性能,所以wal的查询性能相对delete模式要差。

使用wal模式需要控制wal文件的db-page数量,如果page数量太大,会导致文件大小不受控制。wal文件并不是一直增加的,根据SQLite的设计,通过checkpoint操作可以将wal文件合并到db文件中。但同步的时机会导致查询操作被阻塞,所以不能频繁执行checkpoint。在WCDB中设置了一个1000的阈值,当page达到1000后才会执行一次checkpoint

这个1000是微信团队的一个经验值,太大会影响读写性能,而且占用过多的磁盘空间。太小会频繁执行checkpoint,导致读写受阻。

# define SQLITE_DEFAULT_WAL_AUTOCHECKPOINT  1000

sqlite3_wal_autocheckpoint(db, SQLITE_DEFAULT_WAL_AUTOCHECKPOINT);

int sqlite3_wal_autocheckpoint(sqlite3 *db, int nFrame){
#ifdef SQLITE_OMIT_WAL
UNUSED_PARAMETER(db);
UNUSED_PARAMETER(nFrame);
#else
#ifdef SQLITE_ENABLE_API_ARMOR
if( !sqlite3SafetyCheckOk(db) ) return SQLITE_MISUSE_BKPT;
#endif
if( nFrame>0 ){
sqlite3_wal_hook(db, sqlite3WalDefaultHook, SQLITE_INT_TO_PTR(nFrame));
}else{
sqlite3_wal_hook(db, 0, 0);
}
#endif
return SQLITE_OK;
}

也可以设置日志文件的大小限制,默认是-1,也就是没限制,journalSizeLimit的意思是,超出的部分会被覆写。尽量不要修改这个文件,可能会导致wal文件损坏。

i64 sqlite3PagerJournalSizeLimit(Pager *pPager, i64 iLimit){
if( iLimit>=-1 ){
pPager->journalSizeLimit = iLimit;
sqlite3WalLimit(pPager->pWal, iLimit);
}
return pPager->journalSizeLimit;
}

下发指令

日志平台

日志上报应该做到用户无感知,不需要用户主动配合即可进行日志的自动上传。而且并不是所有的用户日志都需要上报,只有出问题的用户日志才是我们需要的,这样也可以避免服务端的存储资源浪费。对于这些问题,我们开发了日志平台,通过下发上传指令的方式告知客户端上传日志。

037C8667-914E-43A7-8B6D-7B6EDD80E3A5.png

我们的日志平台做的比较简单,输入uid对指定的用户下发上传指令,客户端上传日志之后,也可以通过uid进行查询。如上图,下发指令时可以选择下面的日志类型和时间区间,客户端收到指令后会根据这些参数做筛选,如果没选择则是默认参数。搜索时也可以使用这三个参数。

日志平台对应一个服务,点击按钮下发上传指令时,服务会给长连接通道下发一个jsonjson中包含上面的参数,以后也可以用来扩展其他字段。上传日志是以天为单位的,所以在这里可以根据天为单位进行搜索,点击下载可以直接预览日志内容。

长连接通道

指令下发这块我们利用了现有的长连接,当用户反馈问题后,我们会记录下用户的uid,如果技术需要日志进行排查问题时,我们会通过日志平台下发指令。

指令会发送到公共的长连接服务后台,服务会通过长连接通道下发指令,如果指令下发到客户端之后,客户端会回复一个ack消息回复,告知通道已经收到指令,通道会将这条指令从队列中移除。如果此时用户未打开App,则这条指令会在下次用户打开App,和长连接通道建立连接时重新下发。

未完成的上传指令会在队列中,但最多不超过三天,因为超过三天的指令就已经失去其时效性,问题当时可能已经通过其他途径解决。

静默push

用户如果打开App时,日志指令的下发可以通过长连接通道下发。还有一种场景,也是最多的一种场景,用户未打开App怎么解决日志上报的问题,这块我们还在探索中。

当时也调研了美团的日志回捞,美团的方案中包含了静默push的策略,但是经过我们调研之后,发现静默push基本意义不大,只能覆盖一些很小的场景。例如用户App被系统kill掉,或者在后台被挂起等,这种场景对于我们来说并不多见。另外和push组的人也沟通了一下,push组反馈说静默push的到达率有些问题,所以就没采用静默push的策略。

日志上传

分片上传

进行方案设计的时候,由于后端不支持直接展示日志,只能以文件的方式下载下来。所以当时和后端约定的是以天为单位上传日志文件,例如回捞的时间点是,开始时间4月21日19:00,结束时间4月23日21:00。对于这种情况会被分割为三个文件,即每天为一个文件,第一天的文件只包含19:00开始的日志,最后一天的文件只包含到21:00的日志。

这种方案也是分片上传的一种策略,上传时以每个日志文件压缩一个zip文件后上传。这样一方面是保证上传成功率,文件太大会导致成功率下降,另一方面是为了做文件分割。经过观察,每个文件压缩成zip后,文件大小可以控制在500kb以内,500kb这个是我们之前做视频切片上传时的一个经验值,这个经验值是上传成功率和分片数量的一个平衡点。

日志命名使用时间戳为组合,时间单位应该精确到分钟,以方便服务端做时间筛选操作。上传以表单的方式进行提交,上传完成后会删除对应的本地日志。如果上传失败则使用重试策略,每个分片最多上传三次,如果三次都上传失败,则这次上传失败,在其他时机再重新上传。

安全性

为了保证日志的数据安全性,日志上传的请求我们通过https进行传输,但这还是不够的,https依然可以通过其他方式获取到SSL管道的明文信息。所以对于传输的内容,也需要进行加密,选择加密策略时,考虑到性能问题,加密方式采用的对称加密策略。

但对称加密的秘钥是通过非对称加密的方式下发的,并且每个上传指令对应一个唯一的秘钥。客户端先对文件进行压缩,对压缩后的文件进行加密,加密后分片再上传。服务端收到加密文件后,通过秘钥解密得到zip并解压缩。

主动上报

新的日志系统上线后,我们发现回捞成功率只有40%,因为有的用户反馈问题后就失去联系,或者反馈问题后一直没有打开App。对于这个问题,我分析用户反馈问题的途径主要有两大类,一种是用户从系统设置里进去反馈问题,并且和客服沟通后,技术介入排查问题。另一种是用户发生问题后,通过反馈群、App Store评论区、运营等渠道反馈的问题。

这两种方式都适用于日志回捞,但第一种由于有特定的触发条件,也就是用户点击进入反馈界面。所以,对于这种场景反馈问题的用户,我们增加了主动上报的方式。即用户点击反馈时,主动上报以当前时间为结束点,三天内的日志。这样可以把日志上报的成功率提升到90%左右,成功率上来后也会推动更多人接入日志模块,方便排查线上问题。

手动导出

日志上传的方式还包含手动导出,手动导出就是通过某种方式进入调试页面,在调试页面选择对应的日志分享,并且调起系统分享面板,通过对应的渠道分享出去。在新的日志系统之前,就是通过这种方式让用户手动导出日志给客服的,可想而知对用户的打扰有多严重吧。

现在手动导出的方式依然存在,但只用于debug阶段测试和开发同学,手动导出日志来排查问题,线上是不需要用户手动操作的。

dsasdlalfjsdafas.png


作者:刘小壮
链接:https://juejin.cn/post/7028229305050071071

收起阅读 »

iOS-组件化

iOS
小知识,大挑战!本文正在参与“程序员必备小知识”创作活动 通过问题看本质!!! 组件化目的: 组件化可以明确业务模块职责及边界,降低模块之间的耦合以减少复杂依赖,提高代码可维护性,提高业务模块调度的规范性、灵活性,后续也可进一步优化编译速度。 那什么时候要做组...
继续阅读 »

小知识,大挑战!本文正在参与“程序员必备小知识”创作活动


通过问题看本质!!!


组件化目的:


组件化可以明确业务模块职责及边界,降低模块之间的耦合以减少复杂依赖,提高代码可维护性,提高业务模块调度的规范性、灵活性,后续也可进一步优化编译速度。


那什么时候要做组件化呢?随着项目功能的复杂提升,各个业务代码耦合越来越多。这个时候就可以开始考虑组件化了。


通俗的讲,就好比你去宿舍附近的便利店买东西,直接走过去就到了。就没有必要打车了,打车效率还更低了呢。


如果你去公司(车程半小时),就有必要打车或者公交车了,走路那得多慢啊,等你走到了,估计都矿工几小时了。


组件化方案


1. URL路由方案;


2. runtime反射调用(简单反射及二次封装Target-action)


3. Target-action(category及动态调度);


4. protocol方案;


5. notification方案;


组件化的方案有很多种,没有哪种最好,只有哪种最合适。常见的是url-block、protocol-class、target-action方案。所以参考了网上的一些文章,对这3种方案做了一下简单的对比。


url-block 蘑菇街


路由中心维护一张路由表,url为key,block为value。


优点:

1、统一iOS、安卓的平台差异性


缺点:

1、url参数收到限制,只能传常规的字符串参数,无法传递data、image参数;


2、无法区分本地和远程情况;


3、组件本身依赖中间件,且分散注册的耦合较多;


4、启动时提供注册服务,保存在内存中。


protocol-class


优点:

1、扩展了本地调用的功能;


2、通过实现接口来提供服务,只是中间加了一层wrapper;


3、通过protocol-class做一个映射,在内存中保存一张映射表;


缺点:

还是存在内存中维护注册表的问题


target-action


使用target-action方式实现组件间的解耦,本身功能完全独立,不依赖中间件。


1、通过runtime进行反射,直接调用。


2、生成方法签名,通过invocation对象,直接执行invoke方法。


3、通过组件包装一层wrapper来给外界提供服务,不会对原组件代码造成入侵。


4、中间件是通过runtime来调用组件服务的,中间件的catergory提供服务给调度者。


5、使用者只需要依赖中间件,中间件又不需要依赖组件。


作者:龙在掘金62077
链接:https://juejin.cn/post/7023972006957678599
收起阅读 »

Swift 重构:通过预设视图样式,缩减代码量

iOS
通过预设常用视图基础属性,缩减每次创建时需要声明的属性行数(之后创建时不需要再重复声明),项目越大收益越高; 🌰🌰: { func application(_ application: UIApplication, didFinishLaunchin...
继续阅读 »

通过预设常用视图基础属性,缩减每次创建时需要声明的属性行数(之后创建时不需要再重复声明),项目越大收益越高;



🌰🌰:


{
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

UIApplication.setupAppearance(.white, barTintColor: .systemBlue)
}


源码:


@objc public extension UIApplication{

/// 配置 app 外观主题色
static func setupAppearance(_ tintColor: UIColor, barTintColor: UIColor) {
_ = {
$0.barTintColor = barTintColor
$0.tintColor = tintColor
$0.titleTextAttributes = [NSAttributedString.Key.foregroundColor: tintColor,]
}(UINavigationBar.appearance())


_ = {
$0.setTitleTextAttributes([NSAttributedString.Key.foregroundColor: UIColor.black], for: .normal)
}(UIBarButtonItem.appearance(whenContainedInInstancesOf: [UIImagePickerController.self]))


_ = {
$0.setTitleColor(tintColor, for: .normal)
$0.titleLabel?.adjustsFontSizeToFitWidth = true;
$0.titleLabel?.minimumScaleFactor = 1.0;
$0.imageView?.contentMode = .scaleAspectFit
$0.isExclusiveTouch = true
$0.adjustsImageWhenHighlighted = false
}(UIButton.appearance(whenContainedInInstancesOf: [UINavigationBar.self]))


_ = {
$0.tintColor = tintColor

$0.setTitleTextAttributes([NSAttributedString.Key.foregroundColor: tintColor,
], for: .normal)
$0.setTitleTextAttributes([NSAttributedString.Key.foregroundColor: barTintColor,
], for: .selected)
}(UISegmentedControl.appearance(whenContainedInInstancesOf: [UINavigationBar.self]))


_ = {
$0.tintColor = tintColor
}(UISegmentedControl.appearance())


_ = {
$0.autoresizingMask = [.flexibleWidth, .flexibleHeight]
$0.showsHorizontalScrollIndicator = false
$0.keyboardDismissMode = .onDrag;
if #available(iOS 11.0, *) {
$0.contentInsetAdjustmentBehavior = .never;
}
}(UIScrollView.appearance())


_ = {
$0.separatorInset = .zero
$0.separatorStyle = .singleLine
$0.rowHeight = 60
$0.backgroundColor = .groupTableViewBackground
if #available(iOS 11.0, *) {
$0.estimatedRowHeight = 0.0;
$0.estimatedSectionHeaderHeight = 0.0;
$0.estimatedSectionFooterHeight = 0.0;
}
}(UITableView.appearance())


_ = {
$0.layoutMargins = .zero
$0.separatorInset = .zero
$0.selectionStyle = .none
$0.backgroundColor = .white
}(UITableViewCell.appearance())


_ = {
$0.scrollsToTop = false
$0.isPagingEnabled = true
$0.bounces = false
}(UICollectionView.appearance())


_ = {
$0.layoutMargins = .zero
$0.backgroundColor = .white
}(UICollectionViewCell.appearance())


_ = {
$0.titleLabel?.adjustsFontSizeToFitWidth = true;
$0.titleLabel?.minimumScaleFactor = 1.0;
$0.imageView?.contentMode = .scaleAspectFit
$0.isExclusiveTouch = true
$0.adjustsImageWhenHighlighted = false
}(UIButton.appearance())


_ = {
$0.isUserInteractionEnabled = true;
}(UIImageView.appearance())


_ = {
$0.isUserInteractionEnabled = true;
}(UILabel.appearance())


_ = {
$0.pageIndicatorTintColor = barTintColor
$0.currentPageIndicatorTintColor = tintColor
$0.isUserInteractionEnabled = true;
$0.hidesForSinglePage = true;
}(UIPageControl.appearance())


_ = {
$0.progressTintColor = barTintColor
$0.trackTintColor = .clear
}(UIProgressView.appearance())


_ = {
$0.datePickerMode = .date;
$0.locale = Locale(identifier: "zh_CN");
$0.backgroundColor = .white;
if #available(iOS 13.4, *) {
$0.preferredDatePickerStyle = .wheels
}
}(UIDatePicker.appearance())


_ = {
$0.minimumTrackTintColor = tintColor
$0.autoresizingMask = .flexibleWidth
}(UISlider.appearance())


_ = {
$0.onTintColor = tintColor
$0.autoresizingMask = .flexibleWidth
}(UISwitch.appearance())

}
}

作者:SoaringHeart
链接:https://juejin.cn/post/6974338640784654350

收起阅读 »

iOS Reachability

iOS
大多数App都严重依赖于网络,一款用户体验良好的的app是必须要考虑网络状态变化的。为了更好的用户体验,我们会在无网络时展现本地或者缓存的内容,并对用户进行合适的提示。对于网络状态的检测,苹果提供了Reachability,由此也衍生出各种 Reachabil...
继续阅读 »

大多数App都严重依赖于网络,一款用户体验良好的的app是必须要考虑网络状态变化的。

为了更好的用户体验,我们会在无网络时展现本地或者缓存的内容,并对用户进行合适的提示。对于网络状态的检测,苹果提供了Reachability,由此也衍生出各种 Reachability 框架,比较著名的有Github上的 tonymillion/Reachability 以及 AFNetworking 中的 AFNetworkReachabilityManager 模块,它们的实现原理基本上都是对苹果公司的SCNetworkReachability API进行的封装。

1、SCNetworkReachability (SystemConfiguration.framework)

0.png

获取网络状态:

@property (nonatomic, strong) dispatch_source_t timer;
@property (nonatomic, assign) SCNetworkReachabilityRef reachability;
@property (nonatomic, strong) dispatch_queue_t serialQueue;

-(void)dealloc {
if (_reachability != NULL) {
CFRelease(_reachability);
_reachability = NULL;
}
}

- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.

//创建零地址,0.0.0.0地址表示查询本机的网络连接状态
struct sockaddr_in zeroAddress;
bzero(&zeroAddress, sizeof(zeroAddress));
zeroAddress.sin_len = sizeof(zeroAddress);
zeroAddress.sin_family = AF_INET;

_reachability = SCNetworkReachabilityCreateWithAddress(NULL, (struct sockaddr *)&zeroAddress);
_serialQueue = dispatch_queue_create("com.xmy.serialQueue", DISPATCH_QUEUE_SERIAL);

__weak __typeof(self) weakSelf = self;
_timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
dispatch_source_set_timer(_timer, DISPATCH_TIME_NOW, 1.0 * NSEC_PER_SEC, 0.0 * NSEC_PER_SEC);
dispatch_source_set_event_handler(_timer, ^{
__strong __typeof(weakSelf) strongSelf = weakSelf;
NSLog(@"连接状态: %d", [strongSelf isConnectionAvailable]);
});
dispatch_resume(_timer);

[self startMonitor];
}

- (BOOL)isConnectionAvailable
{
SCNetworkReachabilityFlags flags;
//获取连接的标志
BOOL didRetrieveFlags = SCNetworkReachabilityGetFlags(_reachability, &flags);

//如果不能获取连接标志,则不能进行网络连接,直接返回
if (!didRetrieveFlags) {
NSLog(@"Error. Could not recover network reachability flags");
return NO;
}

//根据连接标志进行判断
BOOL isReachable = ((flags & kSCNetworkFlagsReachable) != 0);
BOOL needConnection = ((flags & kSCNetworkFlagsConnectionRequired) != 0);

return (isReachable && !needConnection) ? YES : NO;
}

- (void)startMonitor
{
SCNetworkReachabilityContext context = {0, (__bridge void *)self, NULL, NULL, NULL};
if (SCNetworkReachabilitySetCallback(_reachability, ReachabilityCallback, &context)) {
// Schedules the given target with the given run loop and mode.
// SCNetworkReachabilityScheduleWithRunLoop(_reachability, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode);

// Schedule or unschedule callbacks for the given target on the given dispatch queue.
SCNetworkReachabilitySetDispatchQueue(_reachability, _serialQueue);
}
}

- (void)stopMonitor
{
SCNetworkReachabilitySetCallback(_reachability, NULL, NULL);

// Unschedules the given target from the given run loop and mode.
// SCNetworkReachabilityUnscheduleFromRunLoop(_reachability, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode);
SCNetworkReachabilitySetDispatchQueue(_reachability, NULL);
}

static void ReachabilityCallback(SCNetworkReachabilityRef target, SCNetworkReachabilityFlags flags, void* info)
{
NSLog(@"%@, %d, %@", target, flags, info);
}

优点:

  • 使用简单,只有一个类,官方还有Demo,容易上手
  • 灵敏度高,基本网络一有变化,基本马上就能判断出来

缺点:

  • 现在很流行的公用wifi,需要网页鉴权,鉴权之前无法上网,但本地连接已经建立
  • 存在本地网络连接,但信号很差,实际无法连接到服务器情况
  • 能否连接到指定服务器,比如国内访问墙外的服务器

苹果的Reachability有如下说明,告诉我们其能力受限于此:
The SCNetworkReachability programming interface allows an application to determine the status of a system's current network configuration and the reachability of a target host.
A remote host is considered reachable when a data packet, sent by an application into the network stack, can leave the local device. Reachability does not guarantee that the data packet will actually be received by the host.
当应用程序发送到网络堆栈的数据包可以离开本地设备时,就可以认为远程主机是可访问的,不能保证主机是否实际接收到数据包。

2、SimplePing

ping 是 Windows、Unix 、Linux和macOS 等系统下一个常用的命令,利用 ping 命令可以用来测试数据包能否通过IP 协议到达特定主机,并收到主机的应答,以检查网络是否连通和网络连接速度,帮助我们分析和判定网络故障。

SimplePing是苹果封装好的ping的功能,它利用resolve host,create socket(send&recv data),解析ICMP 包验证 checksum 等实现了 ping功能。并且支持iPv4 和 iPv6。

ping 功能使用是 ICMP 协议(Internet Control Message Protocol),ICMP 协议定义了一组错误信息,当路由器或者主机无法成功处理一个IP 封包的时候,能够将错误信息回送给来源主机:

1.png ICMP用途:差错通知、信息查询、重定向等

2.png [1]给送信者的错误通知;[2]送信者的信息查询。

[1]是到IP 数据包被对方的计算机处理的过程中,发生了什么错误时被使用。不仅传送发生了错误这个事实,也传送错误原因等消息。

[2]的信息询问是在送信方的计算机向对方计算机询问信息时被使用。被询问内容的种类非常丰富,他们有目标IP 地址的机器是否存在这种基本确认,调查自己网络的子网掩码,取得对方机器的时间信息等。

Ping实现:

3.png Ping超时原因:

  • 目标服务器不存在
  • 花在数据包交流上的时间太长ping命令认为超时
  • 目标服务器不回答ping命令

SimplePing实现:

4.png SimplePing初始化:

let hostName = "www.baidu.com"
var pinger: SimplePing?
var sendTimer: NSTimer?

/// Called by the table view selection delegate callback to start the ping.
func start(forceIPv4 forceIPv4: Bool, forceIPv6: Bool) {
let pinger = SimplePing(hostName: self.hostName)
self.pinger = pinger

// By default we use the first IP address we get back from host resolution (.Any)
// but these flags let the user override that.
if (forceIPv4 && !forceIPv6) {
pinger.addressStyle = .ICMPv4
} else if (forceIPv6 && !forceIPv4) {
pinger.addressStyle = .ICMPv6
}

pinger.delegate = self
pinger.start()
}

/// Called by the table view selection delegate callback to stop the ping.
func stop() {
self.pinger?.stop()
self.pinger = nil

self.sendTimer?.invalidate()
self.sendTimer = nil

self.pingerDidStop()
}

/// Sends a ping.
/// Called to send a ping, both directly (as soon as the SimplePing object starts up) and
/// via a timer (to continue sending pings periodically).
func sendPing() {
self.pinger!.sendPingWithData(nil)
}

代理方法:

/// pinger.start()成功之后,解析HostName拿到ip地址后的回调
func simplePing(pinger: SimplePing, didStartWithAddress address: NSData) {
NSLog("pinging %@", MainViewController.displayAddressForAddress(address))

// Send the first ping straight away.
self.sendPing()

// And start a timer to send the subsequent pings.
assert(self.sendTimer == nil)
self.sendTimer = NSTimer.scheduledTimerWithTimeInterval(1.0, target: self, selector: #selector(MainViewController.sendPing), userInfo: nil, repeats: true)
}

/// pinger.start()功能启动失败的回调
func simplePing(pinger: SimplePing, didFailWithError error: NSError) {
NSLog("failed: %@", MainViewController.shortErrorFromError(error))

self.stop()
}

/// sendPingWithData发送数据成功
func simplePing(pinger: SimplePing, didSendPacket packet: NSData, sequenceNumber: UInt16) {
NSLog("#%u sent", sequenceNumber)
}

/// sendPingWithData发送数据失败,并返回错误信息
func simplePing(pinger: SimplePing, didFailToSendPacket packet: NSData, sequenceNumber: UInt16, error: NSError) {
NSLog("#%u send failed: %@", sequenceNumber, MainViewController.shortErrorFromError(error))
}

/// ping发送后收到响应
func simplePing(pinger: SimplePing, didReceivePingResponsePacket packet: NSData, sequenceNumber: UInt16) {
NSLog("#%u received, size=%zu", sequenceNumber, packet.length)
}

/// ping接收响应封包发生异常
func simplePing(pinger: SimplePing, didReceiveUnexpectedPacket packet: NSData) {
NSLog("unexpected packet, size=%zu", packet.length)
}

如代码所示,每隔一段时间就ping下host,看看是否畅通无阻,因此ping不可能做到及时判断网络变化,会有一定的延迟:
利用Reachability判断当前设备是否联网,利用SimplePing来检查服务器是否连通。

3、RealReachability (Star: 3k)

5.png

4、扩展:traceroute

由于ping命令不一定能判断对方是否存在,为了查看主机及目标主机之间的路由路径,我们使用traceroute 命令。它与ping 并列,也是ICMP 的典型实现之一。

traceroute是利用增加存活时间(TTL)值来实现功能的。每当一个icmp包经过一个路由器时,其存活时间值就会减1,当其存活时间为0时,路由器便会取消包发送,并发送一个ICMP TTL超时封包给原封包发出者。

6.png

7.png 命令行测试:

测试1
> traceroute -I baidu.com
traceroute: Warning: baidu.com has multiple addresses; using 220.181.38.148
traceroute to baidu.com (220.181.38.148), 64 hops max, 72 byte packets
1 172.25.62.254 (172.25.62.254) 2.198 ms 1.690 ms 1.437 ms
2 172.25.100.17 (172.25.100.17) 2.175 ms 1.795 ms 1.769 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 220.181.38.148 (220.181.38.148) 29.700 ms 29.135 ms 29.127 ms

测试2
> traceroute -I baidu.com
traceroute: Warning: baidu.com has multiple addresses; using 39.156.69.79
traceroute to baidu.com (39.156.69.79), 64 hops max, 72 byte packets
1 172.25.62.254 (172.25.62.254) 3.339 ms 1.993 ms 4.845 ms
2 172.25.100.17 (172.25.100.17) 2.146 ms 1.792 ms 1.971 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 39.156.69.79 (39.156.69.79) 29.015 ms 27.569 ms 28.232 ms

net-diagnosis (Star: 0.3k)
通过集成net-diagnosis,您可以轻松地在iOS上实现ping / traceroute /移动公共网络信息/端口扫描等网络诊断相关的功能。

8.png

9.png


收起阅读 »

iOS开发Crash之内存暴涨

iOS
今天遇到了一个线上的Crash,线上包,用户打开APP后就一直闪退,但是我们开发和测试都没有这样的问题,后面等到Bugly上报后,看到问题,找到了相对应的测试包开始复现,同事在某一个tf上的build版本QA测试成功出了这个Crash.找到对应的组件分支,全m...
继续阅读 »

今天遇到了一个线上的Crash,线上包,用户打开APP后就一直闪退,但是我们开发和测试都没有这样的问题,后面等到Bugly上报后,看到问题,找到了相对应的测试包开始复现,同事在某一个tf上的build版本QA测试成功出了这个Crash.找到对应的组件分支,全master指定版本真机测试.


全master真机运行出现的结果为


image.png


Message from debugger:Terminated due to memory issue
复制代码

看见这个错误大概就知道是内存暴涨被看门狗杀死了


关键是如何排查


使用instrument中的leaks工具来查看,但是我们并没有这样排查,我们发现一进APP过了main以后就被杀死了,那么可以初步确定是工作台发生的错误.


那么工作台的主要功能就是加载相应权限,然后配置菜单等功能,想到会不会是因为这个客户的数据异常,我们把网络关了,然后进入工作台,不会Crash了。


然后我们把工作台所用到的几个请求一一排查下来,发现在工作台有一个功能卡片组件,组件里面使用了富文本,而富文本是根据后端来的数据来进行对应的加载。


后端接口返回有一个字段,是否采用富文本,然后哪一段启用富文本,字体,颜色,样式都是由后端决定。


因为是一个tableView的Cell,里面又嵌套了for循环,for循环里面又嵌套了for来展示item,item又记录的一条条的富文本还有图片,犹豫cell每次数据源都会addSubviews,没有remove掉,再加上后端返回了N条,同事写的时候没有限制,我们这边只显示4条,显示的图片占用内存很大,从而导致内存暴涨,这一块因为是很老的代码了,需要重构一下,为了线上先不崩溃,跟后端商量图片压缩以及返回条数限制


最后记录一下crash日志
image.png


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

leetcode-最接近的三数之和

往常周末都是睡懒觉,今天早起去体检了。每年都是到了体检的时候,才会想起来身体才是革命的本钱吧。还好都不是什么大问题,最大的问题就是自己没有坚持锻炼。 先立个Flag,每周至少有5天,专门锻炼30分钟以上吧。先把标准定的低一点,能做到最重要,不然都是5分钟热情,...
继续阅读 »

往常周末都是睡懒觉,今天早起去体检了。每年都是到了体检的时候,才会想起来身体才是革命的本钱吧。还好都不是什么大问题,最大的问题就是自己没有坚持锻炼。

先立个Flag,每周至少有5天,专门锻炼30分钟以上吧。先把标准定的低一点,能做到最重要,不然都是5分钟热情,过了几天这个目标就抛在脑后了吧。

当然,说起坚持,一个比较好的方法是定期review,如果有1天没做到,也不要觉得反正已经没做到,破罐子破摔,后面根本就不再做的。每天坚持是每天新的挑战,能够比之前的自己坚持做更久,就是自己的突破。

每天做1题算法题,也是上个月立下的Flag,虽然已经倒了,还是希望后面能多坚持,毕竟进一寸就有进一寸的欢喜。今天继续刷leetcode第16题,跟昨天的题目非常类似,昨天要求3个数之和=0,今天要求是跟target偏离最小。


题目



给定一个包括 n 个整数的数组 nums 和 一个目标值 target。找出 nums 中的三个整数,使得它们的和与 target 最接近。返回这三个数的和。假定每组输入只存在唯一答案。




示例

输入: nums = [-1,2,1,-4], target = 1

输出: 2

解释: 与 target 最接近的和是 2 (-1 + 2 + 1 = 2) 。



思路


跟昨天的题目是非常类似的,首先肯定还是排序。
排序后,假定一个最小值a,然后从a右边的数里面找出2个b和c,使得abs(a+b+c-target)的值最小。因为a右边的数组也是有序的,这时候找b和c其实也不需要2层for循环来遍历,可以使用双指针,分别指向剩余数组的最小和最大,如果a+b+c-target小于0,就让最小值往右边走一个,如果a+b+c-target大于0,就让最大值往左边走一个。


Java版本代码


class Solution {
public int threeSumClosest(int[] nums, int target) {
int len = nums.length;
int ans = 3001;
Arrays.sort(nums);
for (int i = 0; i < len -2; i++) {
if (i > 0 && nums[i] == nums[i-1]) {
continue;
}
int start = i + 1;
int end = len - 1;
while (start < end) {
int sum = nums[i] + nums[start] + nums[end];
if (sum == target) {
ans = sum;
return ans;
}
if (Math.abs(sum - target) < Math.abs(ans - target)) {
ans = sum;
}
if (sum > target) {
end--;
} else if (sum < target) {
start++;
}
}
}
return ans;
}
}

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

Android正确的保活方案,不要掉进保活需求死循环陷进

在开始前,还是给大家简单介绍一下,以前出现过的一些黑科技: 大概在6年前Github中出现过一个叫MarsDaemon,这个库通过双进程守护的方式实现保活,一时间风头无两。好景不长,进入 Android 8.0时代之后,这个库就废掉了。 最近2年Github上...
继续阅读 »

在开始前,还是给大家简单介绍一下,以前出现过的一些黑科技:


大概在6年前Github中出现过一个叫MarsDaemon,这个库通过双进程守护的方式实现保活,一时间风头无两。好景不长,进入 Android 8.0时代之后,这个库就废掉了。


最近2年Github上面出来一个Leoric 感兴趣的可以去看一下源码,谁敢用在生产环境呢,也就自己玩玩的才会用吧(不能因为保活而导致手机卡巴斯基),我没有试过这个,我想说的是:黑科技能黑的了一时,能黑的了一世吗?


没有规矩,不成方圆,要提升产品的存活率,最终还是要落到产品本身上面来,尊重用户,提升用户体验才是正道。


以前我也是深受保活需求的压迫,最近发现QQ群里有人又提到了如何保活,那么我们就来说一说,如何来正确保活App?




Android 8.0之后: 加强了应用后台限制,当时测试过一组数据:



应用处于前台,启动一个前台Service,里面使用JobScheduler启动定时任务(30秒触发一次),
此时手机锁屏,前10分钟内,定时任务都是正常执行;

大概在12分钟左右,发现应用进程就被kill掉了,解锁屏幕,app也不在前台了;



各大国产手机厂商底层都经过自己魔改,自家都有自己的一套自启动管理,小米手机更乱(当时有个神隐模式的概念,那也是杀后台高手),只能说当时Android手机各种性能方面都不足,各家都会有自己的一套省电模式,以此来达到省电和提高手机性能,Android 系统变得越来越完善,但是厂商定制的自启动、省电模式还在,所以我们要做保活。


1.Android 8.0之前-常用的保活方案



1.开启一个前台Service

2.Android 6.0+ 忽略电池优化开关(稍后会有代码)

3.无障碍服务(只针对有用这个功能的app,如支付宝语音增强提醒用了它)





2.Android 8.0之后-常用的保活方案



1.开启一个前台Service(可以加上,单独启用的话无法满足保活需求)

2.Android 6.0+ 忽略电池优化开关(稍后会有代码)

3.无障碍服务(只针对有用这个功能的app,如支付宝语音增强提醒用了它)

4.应用自启动权限(最简单的方案是针对不同系统提供教程图片-让用户自己去打开)

5.多任务列表窗口加锁(提供GIF教程图片-让用户自己去打开)

6.多任务列表窗口隐藏App(仅针对有这方面需求的App)

7.应用后台高耗电(仅针对Vivo手机)



3.保活方案实现步骤


(1). 前台Service


//前台服务
class ForegroundCoreService : Service() {
override fun onBind(intent: Intent?): IBinder? = null
private var mForegroundNF:ForegroundNF by lazy {
ForegroundNF(this)
}
override fun onCreate() {
super.onCreate()
mForegroundNF.startForegroundNotification()
}
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
if(null == intent){
//服务被系统kill掉之后重启进来的
return START_NOT_STICKY
}
mForegroundNF.startForegroundNotification()
return super.onStartCommand(intent, flags, startId)
}
override fun onDestroy() {
mForegroundNF.stopForegroundNotification()
super.onDestroy()
}
}

//初始化前台通知,停止前台通知
class ForegroundNF(private val service: ForegroundCoreService) : ContextWrapper(service) {
companion object {
private const val START_ID = 101
private const val CHANNEL_ID = "app_foreground_service"
private const val CHANNEL_NAME = "前台保活服务"
}
private var mNotificationManager: NotificationManager? = null

private var mCompatBuilder:NotificationCompat.Builder?=null

private val compatBuilder: NotificationCompat.Builder?
get() {
if (mCompatBuilder == null) {
val notificationIntent = Intent(this, MainActivity::class.java)
notificationIntent.action = Intent.ACTION_MAIN
notificationIntent.addCategory(Intent.CATEGORY_LAUNCHER)
notificationIntent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
//动作意图
val pendingIntent = PendingIntent.getActivity(
this, (Math.random() * 10 + 10).toInt(),
notificationIntent, PendingIntent.FLAG_UPDATE_CURRENT
)
val notificationBuilder: NotificationCompat.Builder = NotificationCompat.Builder(this,CHANNEL_ID)
//标题
notificationBuilder.setContentTitle(getString(R.string.notification_content))
//通知内容
notificationBuilder.setContentText(getString(R.string.notification_sub_content))
//状态栏显示的小图标
notificationBuilder.setSmallIcon(R.mipmap.ic_coolback_launcher)
//通知内容打开的意图
notificationBuilder.setContentIntent(pendingIntent)
mCompatBuilder = notificationBuilder
}
return mCompatBuilder
}

init {
createNotificationChannel()
}

//创建通知渠道
private fun createNotificationChannel() {
mNotificationManager =
getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
//针对8.0+系统
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
val channel = NotificationChannel(
CHANNEL_ID,
CHANNEL_NAME,
NotificationManager.IMPORTANCE_LOW
)
channel.lockscreenVisibility = Notification.VISIBILITY_PUBLIC
channel.setShowBadge(false)
mNotificationManager?.createNotificationChannel(channel)
}
}

//开启前台通知
fun startForegroundNotification() {
service.startForeground(START_ID, compatBuilder?.build())
}

//停止前台服务并清除通知
fun stopForegroundNotification() {
mNotificationManager?.cancelAll()
service.stopForeground(true)
}
}

(2).忽略电池优化(Android 6.0+)


1.我们需要在AndroidManifest.xml中声明一下权限


<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />

2.通过Intent来请求忽略电池优化的权限(需要引导用户点击)


//在Activity的onCreate中注册ActivityResult,一定要在onCreate中注册
//监听onActivityForResult回调
mIgnoreBatteryResultContract = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { activityResult ->
//查询是否开启成功
if(queryBatteryOptimizeStatus()){
//忽略电池优化开启成功
}else{
//开启失败
}
}

通过Intent打开忽略电池优化弹框:


val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS)
intent.data = Uri.parse("package:$packageName")
//启动忽略电池优化,会弹出一个系统的弹框,我们在上面的
launchActivityResult(intent)

查询是否成功开启忽略电池优化开关:


fun Context.queryBatteryOptimizeStatus():Boolean{
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager?
return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
powerManager?.isIgnoringBatteryOptimizations(packageName)?:false
} else {
true
}
}

(3).无障碍服务


看官方文档:创建自己的无障碍服务

它也是一个Service,它的优先级比较高,提供界面增强功能,初衷是帮助视觉障碍的用户或者是可能暂时无法与设备进行全面互动的用户完成操作。

可以做很多事情,使用了此Service,在6.0+不需要申请悬浮窗权限,直接使用WindowManager.LayoutParams.TYPE_ACCESSIBILITY_OVERLAY 挺方便的

(仅针对有需要此服务的app,可以开启增强后台保活)


(4).自启动权限(即:白名单管理列表页面)


是系统给用户自己去打开“自启动权限”开关的入口,我们需要针对不同的手机厂商和系统版本,弹出提示引导用户是否前去打开“自启动权限”

有的手机厂商叫:白名单管理,有的叫:自启动权限,两个是一个概念;

点击查看跳转到『手机自启动设置页面』完整代码


(需要注意:如果是代码控制跳转,无法保证永远可以调整,系统升级可能就给你屏蔽了,
最简单的方法是:显示一个如何找到自启动页面的引导图,下面以华为手机为例:)



华为手机-自启动管理

(5).多任务列表窗口加锁


可以针对不同手机厂商,显示引导用户,开启App窗口加锁之后,点击清理加速不会导致应用被kill



华为手机窗口加锁-教程图

(6).多任务列表窗口隐藏App窗口


刚刚上面多任务窗口加锁完,再提示用户去App里面把隐藏App窗口开关打开,这样用户就不会多任务列表里面把App窗口给手抖划掉


多任务窗口中『隐藏App窗口』,可以用如下代码控制:

(这个也只是针对有这方面需求App提供的一种增强方案罢了:因为隐藏了窗口,用户就不会去想他,不会去手痒去划掉它)


//在多任务列表页面隐藏App窗口
fun hideAppWindow(context: Context,isHide:Boolean){
try {
val activityManager: ActivityManager = context.getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
//控制App的窗口是否在多任务列表显示
activityManager.appTasks[0].setExcludeFromRecents(isHide)
}catch (e:Exception){
.....
}
}

(7).应用后台高耗电(Vivo手机独有)


开启的入口:“设置”>“电池”>“后台高耗电”>“找到xxxApp打开开关”



vivo允许后台高耗电



最后还是奉劝那些,仍然执着于找寻黑科技的开发者,醒醒吧,太阳晒屁股了。


如果说你的App用户群体不是普通用户,是专门给一些玩机大神们用的,都可以root手机的话,那么直接 move 到系统目录 priv/system/app 即可, 即使被用户强杀也会自动重新拉起。


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

Android 优雅处理重复点击(建议收藏)

一般手机上的 Android App,主要的交互方式是点击。用户在点击后,App 可能做出在页面内更新 UI、新开一个页面或者发起网络请求等操作。Android 系统本身没有对重复点击做处理,如果用户在短时间内多次点击,则可能出现新开多个页面或者重复发起网络请...
继续阅读 »

一般手机上的 Android App,主要的交互方式是点击。用户在点击后,App 可能做出在页面内更新 UI、新开一个页面或者发起网络请求等操作。Android 系统本身没有对重复点击做处理,如果用户在短时间内多次点击,则可能出现新开多个页面或者重复发起网络请求等问题。因此,需要对重复点击有影响的地方,增加处理重复点击的代码。


之前的处理方式


之前在项目中使用的是 RxJava 的方案,利用第三方库 RxBinding 实现了防止重复点击:


fun View.onSingleClick(interval: Long = 1000L, listener: (View) -> Unit) {
    RxView.clicks(this)
        .throttleFirst(interval, TimeUnit.MILLISECONDS)
        .subscribe({
            listener.invoke(this)
        }, {
            LogUtil.printStackTrace(it)
        })
}

但是这样有一个问题,比如使用两个手指同时点击两个不同的按钮,按钮的功能都是新开页面,那么有可能会新开两个页面。因为 Rxjava 这种方式是针对单个控件实现防止重复点击,不是多个控件。


现在的处理方式


现在使用的是时间判断,在时间范围内只响应一次点击,通过将上次单击时间保存到 Activity Window 中的 decorView 里,实现一个 Activity 中所有的 View 共用一个上次单击时间。


fun View.onSingleClick(
    interval: Int = SingleClickUtil.singleClickInterval,
    isShareSingleClick: Boolean = true,
    listener: (View) -> Unit
) {
    setOnClickListener {
        val target = if (isShareSingleClick) getActivity(this)?.window?.decorView ?: this else this
        val millis = target.getTag(R.id.single_click_tag_last_single_click_millis) as? Long ?: 0
        if (SystemClock.uptimeMillis() - millis >= interval) {
            target.setTag(
                R.id.single_click_tag_last_single_click_millis, SystemClock.uptimeMillis()
            )
            listener.invoke(this)
        }
    }
}

private fun getActivity(view: View): Activity? {
    var context = view.context
    while (context is ContextWrapper) {
        if (context is Activity) {
            return context
        }
        context = context.baseContext
    }
    return null
}

参数 isShareSingleClick 的默认值为 true,表示该控件和同一个 Activity 中其他控件共用一个上次单击时间,也可以手动改成 false,表示该控件自己独享一个上次单击时间。


mBinding.btn1.onSingleClick {
    // 处理单次点击
}

mBinding.btn2.onSingleClick(interval = 2000, isShareSingleClick = false) {
    // 处理单次点击
}

其他场景处理重复点击


间接设置点击


除了直接在 View 上设置的点击监听外,其他间接设置点击的地方也存在需要处理重复点击的场景,比如说富文本和列表。


为此将判断是否触发单次点击的代码抽离出来,单独作为一个方法:


fun View.onSingleClick(
    interval: Int = SingleClickUtil.singleClickInterval,
    isShareSingleClick: Boolean = true,
    listener: (View) -> Unit
) {
    setOnClickListener { determineTriggerSingleClick(interval, isShareSingleClick, listener) }
}

fun View.determineTriggerSingleClick(
    interval: Int = SingleClickUtil.singleClickInterval,
    isShareSingleClick: Boolean = true,
    listener: (View) -> Unit
) {
    ...
}

直接在点击监听回调中调用 determineTriggerSingleClick 判断是否触发单次点击。下面拿富文本和列表举例。


富文本


继承 ClickableSpan,在 onClick 回调中判断是否触发单次点击:


inline fun SpannableStringBuilder.onSingleClick(
    listener: (View) -> Unit,
    isShareSingleClick: Boolean = true,
    ...
): SpannableStringBuilder = inSpans(
    object : ClickableSpan() {
        override fun onClick(widget: View) {
            widget.determineTriggerSingleClick(interval, isShareSingleClick, listener)
        }
        ...
    },
    builderAction = builderAction
)

这样会有一个问题, onClick 回调中的 widget,就是设置富文本的控件,也就是说如果富文本存在多个单次点击的地方, 就算 isShareSingleClick 值为 false,这些单次点击还是会共用设置富文本控件的上次单击时间。


因此,这里需要特殊处理,在 isShareSingleClick 为 false 的时候,创建一个假的 View 来触发单击事件,这样富文本中多个单次点击 isShareSingleClick 为 false 的地方都有一个自己的假的 View 来独享上次单击时间。


class SingleClickableSpan(
    ...
) : ClickableSpan() {

    private var mFakeView: View? = null

    override fun onClick(widget: View) {
        if (isShareSingleClick) {
            widget
        } else {
            if (mFakeView == null) {
                mFakeView = View(widget.context)
            }
            mFakeView!!
        }.determineTriggerSingleClick(interval, isShareSingleClick, listener)
    }
    ...
}

在设置富文本的地方,使用设置 onSingleClick 实现单次点击:


mBinding.tvText.movementMethod = LinkMovementMethod.getInstance()
mBinding.tvText.highlightColor = Color.TRANSPARENT
mBinding.tvText.text = buildSpannedString {
    append("normalText")
    onSingleClick({
        // 处理单次点击
    }) {
        color(Color.GREEN) { append("clickText") }
    }
}

列表


列表使用 RecyclerView 控件,适配器使用第三方库 BaseRecyclerViewAdapterHelper。


Item 点击:


adapter.setOnItemClickListener { _, view, _ ->
    view.determineTriggerSingleClick {
        // 处理单次点击
    }
}

Item Child 点击:


adapter.addChildClickViewIds(R.id.btn1, R.id.btn2)
adapter.setOnItemChildClickListener { _, view, _ ->
    when (view.id) {
        R.id.btn1 -> {
            // 处理普通点击
        }
        R.id.btn2 -> view.determineTriggerSingleClick {
            // 处理单次点击
        }
    }
}

数据绑定


使用 DataBinding 的时候,有时会在布局文件中直接设置点击事件,于是在 View.onSingleClick 上增加 @BindingAdapte 注解,实现在布局文件中设置单次点击事件,并对代码做出调整,这个时候需要将项目中 listener: (View) -> Unit 替换成 listener: View.OnClickListener。


@BindingAdapter(
    *["singleClickInterval", "isShareSingleClick", "onSingleClick"],
    requireAll = false
)
fun View.onSingleClick(
    interval: Int? = SingleClickUtil.singleClickInterval,
    isShareSingleClick: Boolean? = true,
    listener: View.OnClickListener? = null
) {
    if (listener == null) {
        return
    }

    setOnClickListener {
        determineTriggerSingleClick(
            interval ?: SingleClickUtil.singleClickInterval, isShareSingleClick ?: true, listener
        )
    }
}

在布局文件中设置单次点击:


<androidx.appcompat.widget.AppCompatButton
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:text="@string/btn"
    app:isShareSingleClick="@{false}"
    app:onSingleClick="@{()->viewModel.handleClick()}"
    app:singleClickInterval="@{2000}" />

在代码中处理单次点击:


class YourViewModel : ViewModel() {

    fun handleClick() {
        // 处理单次点击
    }
}

总结


对于直接在 View 上设置点击的地方,如果需要处理重复点击使用 onSingleClick,不需要处理重复点击则使用原来的 setOnClickListener。


对于间接设置点击的地方,如果需要处理重复点击,则使用 determineTriggerSingleClick 判断是否触发单次点击。


项目地址


https://github.com/TaylorKunZhang/single-click


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

【Flutter App】GetX框架的实践

正在做的这款App是一个打卡软件,旨在让用户能够更好地坚持自己所设置的目标,坚持自己的初心。由于项目还只是在前期阶段,目前根据需要建立了以下结构: 参考了部分官方插件以及结合官方getX文档中建议的目录:暂时没有对state分离出来一层的想法。 以下...
继续阅读 »

正在做的这款App是一个打卡软件,旨在让用户能够更好地坚持自己所设置的目标,坚持自己的初心。

由于项目还只是在前期阶段,目前根据需要建立了以下结构: image.png

参考了部分官方插件以及结合官方getX文档中建议的目录:

image.png

暂时没有对state分离出来一层的想法。 以下是各层详细内容:

image.png

image.png

在使用GetX的时候,往往每次都是用需要手动实例化一个控制器final controller = Get.put(CounterController());,如果每个界面都要实例化一次,有些许麻烦。使用Binding 能解决上述问题,可以在项目初始化时把所有需要进行状态管理的控制器进行统一初始化,直接使用Get.find()找到对应的GetxController使用。

  • 可以将路由、状态管理器和依赖管理器完全集成
  • 这里介绍三种使用方式,推荐第一种使用getx的命名路由的方式
  • 不使用binding,不会对功能有任何的影响。
  • 第一种:使用命名路由进行Binding绑定
/// 入口类
class MyApp extends StatelessWidget {
const MyApp({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
/// 这里使用 GetMaterialApp
/// 初始化路由
return GetMaterialApp(
initialRoute: RouteConfig.onePage,
getPages: RouteConfig.getPages,
);
}
}

/// 路由配置
class RouteConfig {
static const String onePage = "/onePage";
static const String twoPage = "/twoPage";

static final List<GetPage> getPages = [
GetPage(
name: onePage,
page: () => const OnePage(),
binding: OnePageBinding(),
),
// GetPage(
// name: twoPage,
// page: () => TwoPage(),
// binding: TwoPageBinding(),
// ),
];
}

/// binding层
class OnePageBinding extends Bindings {
@override
void dependencies() {
Get.lazyPut(() => CounterController());
}
}

/// 逻辑层
class CounterController extends GetxController{
var count = 0;
/// 自增方法
void increase(){
count++;
update();
}
}
  • 第二种:使用initialBinding初始化所有的Binding
/// 入口类
class MyApp extends StatelessWidget {
const MyApp({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
return GetMaterialApp(
/// 初始化所有的Binding
initialBinding: AllControllerBinding(),
home: const OnePage(),
);
}
}

/// 所有的Binding层
class AllControllerBinding extends Bindings {
@override
void dependencies() {
Get.lazyPut(() => CounterController());
///Get.lazyPut(() => OneController());
///Get.lazyPut(() => TwoController());
}
}


作者:_Archer
链接:https://juejin.cn/post/7042904386799927332
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

美团跨端一体化富文本管理技术实践

为了减少产品和前端开发人员之间的矛盾,不断降本提效,美团医药技术部构建了跨端一体化富文本管理平台Page-佩奇。本文系统介绍了该平台的定位、设计思路、实现原理以及取得的成效。希望这些实战经验与总结,能给大家带来一些启发或帮助。一、引言在互联网圈,开发和产品经理...
继续阅读 »



为了减少产品和前端开发人员之间的矛盾,不断降本提效,美团医药技术部构建了跨端一体化富文本管理平台Page-佩奇。本文系统介绍了该平台的定位、设计思路、实现原理以及取得的成效。希望这些实战经验与总结,能给大家带来一些启发或帮助。

一、引言

在互联网圈,开发和产品经理之间相爱相杀的故事,相信大家都有所耳闻。归根结底,往往都是从简单的改需求开始,然后你来我往、互不相让,接着吵架斗嘴,最后导致矛盾不断升级,甚至带来比较严重的后果。

pic_4bf1ae9b.png

图1

在这种背景下,如果把一些功能相对简单的、需求变动比较频繁的页面,直接交给产品或者运营自己去通过平台实现,是不是就可以从一定程度上减少产品和开发人员之间的矛盾呢?

二、背景

当然上述的情况,美团也不例外。近些年,美团到家事业群(包括美团外卖、美团配送、闪购、医药、团好货等)的各个业务稳步发展,业务前端对接的运营团队有近几十个,每个运营团队又有不同的运营规则,这些规则还存在一些细微的样式差别,同时规则内容还会随着运营季节、节日、地理位置等进行变化和更新。这些需求具体来说有以下几个特点:

  1. 需求量大:业务稳步发展,业务需求不断叠加,甚至部分业务呈指数级增长,且业务方向涉及到一些业务规则、消息通知、协议文档、规则介绍等需求。

  2. 变更频繁:面对市场监管和法务的要求,以及新业务调整等因素的影响,会涉及到需求的频繁变更,像一些业务FAQ、产品介绍、协议文档、业务规则、系统更新日志等页面,需要做到快速响应和及时上线。

  3. 复杂度低:这些页面没有复杂的交互逻辑,如果能把这些简单的页面交给运营/产品去实现,开发人员就能有更多的时间去进行复杂功能的研发。

  4. 时效性高:临时性业务需求较多,且生命周期较短,具有定期下线和周期性上线等特点。

基于以上特点,为了提高研发效率,美团医药技术部开始构建了一个跨端一体化富文本管理平台,希望提供解决这一大类问题的产研方案。不过,部门最初的目标是开发一套提效工具,解决大量诸如帮助文档、协议页、消息通知、规则说明等静态页面的生产与发布问题,让产品和运营同学能够以所见即所得的方式自主完成静态页面制作与发布,进而缩短沟通成本和研发成本。

但是,随着越来越多业务部门开始咨询并使用这个平台,我们后续不断完善并扩充了很多的功能。经过多次版本的设计和迭代开发后,将该平台命名为Page-佩奇,并且注册成为美团内部的公共服务,开始为美团内部更多同学提供更好的使用体验。

本文将系统地介绍Page-佩奇平台的定位、设计思路、实现原理及取得成效。我们也希望这些实战经验与总结,能给更多同学带来一些启发和思考。

三、跨端一体化富文本管理解决方案

3.1 平台定位

我们希望将Page-佩奇打造成一款为产品、运营、开发等用户提供快速一站式发布网页的产研工作台,这是对该平台的一个定位。

  • 对产品运营而言,他们能够可视化地去创建或修改一些活动说明、协议类、消息类的文章,无需开发排期,省去向开发二次传递消息等繁琐的流程,也无需等待漫长的发布时间,从而达到灵活快速地进行可视化页面的发布与管理。

  • 对开发同学而言,他们能够在线编写代码,并实现秒级的发布上线,并且支持ES 6、JavaScript 、Less、CSS语法,我们还提供了基础的工具、图表库等,能够生成丰富多样的页面。帮助开发同学快速实现数据图表展示,设计特定样式,完成各种交互逻辑等需求。

  • 对项目管理方而言,他们能够清晰地看到整个需求流转状态和开发日志信息,为运营管理提供强大的“抓手”。

一般来讲,传统开发流程是这样的:首先产品提出需求,然后召集研发评审,最后研发同学开发并且部署上线;当需求上线之后,如果有问题需要反馈,产品再找研发同学进行沟通并修复,这种开发流程也是目前互联网公司比较常见的开发流程。

pic_b81cd143.png

图2 传统开发流程图

而美团Page-佩奇平台的开发流程是:首先产品同学提出需求,然后自己在Page平台进行编辑和发布上线,当需求上线之后有问题需要反馈,直接就能触达到产品同学,他们通常可自行进行修复。如果需求需要定制化,或者需要做一些复杂的逻辑处理,那么再让研发人员配合在平台上进行开发并发布上线。

pic_b3e5d331.png

图3 Page-佩奇平台开发流程图

简单来说,对那些功能相对简单、需求变动比较频繁的页面,如果用传统的开发流程将会增加产研沟通和研发排期成本,因此传统方案主要适用于功能复杂型的需求。而Page-佩奇平台开发流程,并不适合功能复杂型的需求,特别适用于功能相对简单、需求变动比较频繁的页面需求。

综上所述,可以看出这两种开发流程其实起到了一个互补的作用,如果一起使用,既可以减少工作量,又可以达到降本提效的目的。

3.2 设计思路

我们最初设计Page-佩奇平台的初心其实很简单,为了给产品和运营提供一个通过富文本编辑器快速制作并发布网页的工具。但是,在使用的过程中,很多缺陷也就慢慢地开始暴露,大致有下面这些问题:

  1. 简单的富文本编辑器满足不了想要的页面效果,怎么办?

  2. 如果能导入想要的模板,是否会更友好?

  3. 怎么查看这个页面的访问数据?如何能监控这个页面的性能问题?

  4. 发布的页面是否有存在安全风险?

于是,我们针对这些问题进行了一些思考和调研:

  • 当富文本编辑器满足不了想要实现的效果的时候,可以引入了WebIDE编辑器,可以让研发同学再二次编辑进行实现。

  • 一个系统想要让用户用得高效便捷,那么就要完善它的周边生态。就需要配备完善的模板素材和物料供用户灵活选择。

  • 如果用户想要了解页面的运行情况,那么页面运行的性能数据、访问的数据也是必不可少的。

  • 如果发布的内容存在不当言论,就会造成不可控的法律风险,所以内容风险审核也是必不可少的。

实现一个功能很容易,但是想要实现一个相对完善的功能,就必须好好下功夫,多思考和多调研。于是,围绕着这些问题,我们不断挖掘和延伸出了一系列功能:

  1. 富文本编辑:强大而简单的可视化编辑器,让一切操作变得简单、直观。产品同学可以通过编辑器自主创建、编辑网页,即使无程序开发经验也可以通过富文本编辑器随意操作,实现自己想要的效果,最终可以实现一键快速发布上线。

  2. WebIDE:定制化需求,比如,与客户端和后端进行一些通信和请求需求,以及针对产品创建的HTML进行二次加工需求,均可以基于WebIDE通过JavaScript代码实现。具备专业开发经验的同学也可以选择通过前端框架jQuery、Vue,Echarts或者工具库Lodash、Axios实现在线编辑代码。

  3. 页面管理:灵活方便地管理页面。大家可以对有权限的文档进行查看、编辑、授权、下线、版本对比、操作日志、回滚等操作,且提供便捷的文档搜索功能。

  4. 模板市场:丰富多样的网页模板,简易而又具备个性。模板市场提供丰富的页面模板,大家可选择使用自己的模板快速创建网页,且发布的每个页面又可以作为自己的模板,再基于这个模板,可随时添加个性化的操作。

  5. 物料平台:提供基础Utils、Echart、Vue、jQuery等物料,方便开发基于产品的页面进行代码的二次开发。

  6. 多平台跨端接入:高效快捷地接入业务系统。通过通信SDK,其他系统可以快速接入Page-佩奇平台。同时支持以HTTP、Thrift方式的开放API供大家选择,支持客户端、后端调用开放API。

  7. 内容风险审核:严谨高效的审核机制。接入美团内部的风险审核公共服务,针对发布的风险内容将快速审核,防止误操作造成不可控的法律风险。

  8. 数据大盘:提供页面的数据监测,帮助大家时刻掌握流量动向。接入美团内部一站式数据分析平台,帮助大家安全、快速、高效地掌握页面的各种监测数据。

  9. 权限管理:创建的每个页面都有相对独立的权限,只有经过授权的人才能查看和操作该页面。

  10. 业务监控:提供页面级别JavaScript错误和资源加载成功率等数据,方便开发排查和解决线上问题。

功能流程图如下所示:

pic_9d007bab.png

图4 Page-佩奇平台功能流程图

3.3 实现原理

3.3.1 基础服务

Page-佩奇平台的基础服务有四个部分,包括物料服务、编译服务、产品赋能、扩展服务。

pic_f0bf9912.png

图5 整体架构图

3.3.2 核心架构

pic_bbb3bb9a.png

图6 核心架构图

Page-佩奇平台核心架构主要包含页面基础配置层、页面组装层以及页面生成层。我们通过Vuex全局状态对数据进行维护。

  • 页面基础配置层主要提供生成页面的各种能力,包括富文本的各种操作能力、编辑源码(HTML、CSS、JavaScript)的能力、自定义域名配置、适配的容器(PC/H5)、发布环境等。

  • 页面组装层则会基于基础配置层所提供的的能力,实现页面的自由编辑,承载大量的交互逻辑,用户的所有操作都在这一层进行。

    • 业务PV和UV埋点,错误统计,访问成功率上报。

    • 自动适配PC和移动端样式。

    • 内网页面显示外网不可访问标签。

  • 页面生成层则需要根据组装后的配置进行解析和预处理、编译等操作,最终生成HTML、CSS、JavaScript渲染到网页当中。

3.3.3 关键流程

pic_b5adef78.png

图7 关键流程图

如上图7所示,平台的核心流程主要包含页面创建之后的页面预览、编译服务、生成页面。

  • 页面预览:创建、编辑之后的页面,将会根据内容进行页面重组,对样式和JavaScript进行预编译之后,对文本+JavaScript+CSS进行组装,生成HTML代码块,然后将代码块转换成Blob URL,最终以iframe的方式预览页面。

  • 编译服务:文件树状结构和代码发送请求到后端接口,基于Webpack将Less编译成CSS,ES 6语法编译成ES 5。通用物料使用CDN进行引入,不再进行二次编译。

  • 生成页面:当创建、编辑之后的页面进行发布时,服务端将会进行代码质量检测、内容安全审查、代码质量检测、单元测试、上传对象存储平台、同步CDN检测,最终生成页面链接进行访问。

3.3.4 多平台接入

Page-佩奇平台也可以作为一个完善的富文本编辑器供业务系统使用,支持内嵌到其他系统内。作为消息发布等功能承载,减少重复的开发工作,同时我们配备完善的SDK供大家选择使用。通过Page-SDK可以直接触发Page平台发布、管理等操作,具体的流程如下图所示:

pic_e3c8e777.png

图8 Page-SDK流程图

3.3.5 Open API

在使用Page-佩奇平台的时候,美团内部一些业务方提出想要通过Page-佩奇平台进行页面的发布,同时想要拿到发布的内容做一些自定义的处理。于是,我们提供了Open API开放能力,支持以HTTP和Thrift两种方式进行调用。下面主要讲一下Thrift API实现的思路,首先我们先了解下Thrift整体流程:

pic_a6286e54.png

图9 Thrift整体流程图

Thrift的主要使用过程如下:

  1. 服务端预先编写接口定义语言 IDL(Interface Definition Language)文件定义接口。

  2. 使用Thrift提供的编译器,基于IDL编译出服务语言对应的接口文件。

  3. 被调用服务完成服务注册,调用发起服务完成服务发现。

  4. 采用统一传输协议进行服务调用与数据传输。

下面具体讲讲,Node语言是如何实现和其他服务语言实现调用的。由于我们的服务使用的Node语言,因此我们的Node服务就充当了服务端的角色,而其他语言(Java等)调用就充当了客户端的角色。

pic_ca36c11d.png

图10 Thrift使用详细流程图

  • 生成文件:由服务端定义IDL接口描述文件,然后基于IDL文件转换为对应语言的代码文件,由于我们用的是Node语言,所以转换成JavaScript文件。

  • 服务端启动服务:引入生成的JavaScript文件,解析接口、处理接口、启动并监听服务。

  • 服务注册:通过服务器内置的“服务治理代理”,将服务注册到美团内部的服务注册路由中心(也就是命名服务),让服务可被调用方发现。

  • 数据传输:被调用时,根据“服务治理服务”协议序列化和反序列化,与其他服务进行数据传输。

目前,美团内部已经有相对成熟的NPM包服务,已经帮我们实现了服务注册、数据传输、服务发现和获取流程。客户端如果想调用我们所提供的的Open API开放能力,首先申请AppKey,然后选择使用Thrift方式或者HTTP的方式,按照所要求的参数进行请求调用即可。

3.4 方案实践

3.4.1 H5协议

能力:富文本编辑。

描述:提供富文本可视化编辑,产品和运营无需前端就可以发布和二次编辑页面。

场景:文本协议,消息通知,产品FAQ。

具体案例:

pic_f883a4d1.png

图11 H5静态文本协议案例

3.4.2 业务自定义渲染

能力:开放API(Thirft + HTTP)。

描述:提供开放API,支持业务自定义和样式渲染到业务系统,同时解决了iframe体验问题。

场景:客户端、后端、小程序的同学,可根据API渲染文案,实现动态化管理富文本信息。

具体案例:

小程序使用组件、Vue使用v-html指令实现动态化渲染商品选择说明。

{
   "code": 0,
   "data": {
     "tag": "苹果,标准",
     "title": "如何挑选苹果",
     "html": "<h1>如何挑选苹果</h1>><p>以下标准可供消费者参考</p><ul><li>酸甜</li><li>硬度</li></ul>",
     "css": "",
     "js": "",
     "file": {}
  },
   "msg": "success"
}

3.4.3 投放需求

能力:WebIDE代码编辑。

描述:开发基于WebIDE代码开发工作,基于渠道和环境修改下载链接,能够做到分钟级支撑。

场景:根据产品创建静态页面进行逻辑和样式开发。

具体案例:

var ua = window.navigator.userAgent
   var URL_MAP = {
       ios: 'https://apps.apple.com/cn/app/xxx',
       android: 'xxx.apk',
       ios_dpmerchant: 'itms-apps://itunes.apple.com/cn/app/xxx'
  }
   
   if (ua.match(/android/i)) location.href = URL_MAP.android
   if (ua.match(/(ipad|iphone|ipod).*os\s([\d_]+)/i)) {
       if (/xx\/com\.xxx\.xx\.mobile/.test(ua)) {
           location.href = URL_MAP.ios_dpmerchant
      } else {
           location.href = URL_MAP.ios
      }
  }

3.4.4 客户端通信中间页

能力:WebIDE代码编辑 + 物料平台。

描述:通过物料平台,引入公司客户端桥SDK,可以快速完成客户端通信需求。方便前端调试客户端基础桥功能。

场景:客户端跳转,通信中间页。

具体案例:

// 业务伪代码
   XXX.ready(() => {
       XXX.sendMessage({
          sign: true,
           params: {
               id: window.URL
          }
      }, () => {
           console.error('通信成功')
      }, () => {
           console.error('通信失败')
      })
  })

3.4.5 业务系统内嵌Page

能力:提供胶水层Page-SDK,连接业务系统和Page。

描述:业务系统与Page-佩奇平台可进行通信,业务系统可调用Page发布、预览、编辑等功能,Page可返回业务系统页面链接、内容、权限等信息。减少重复前后端工作,提升研发效率。

场景:前端富文本信息渲染,后端富文本信息管理后台。

具体案例:

pic_ec5b5f49.png

图12 业务系统内嵌Page案例

3.5 业务成绩

截止目前数据统计,Page-佩奇平台生成网页5000多个,编辑页面次数16000多次,累计页面访问PV超过8260万。现在,美团已经有十多个部门和三十多条业务线接入并使用了Page-佩奇平台。

pic_becbff8a.png

图13 Page-佩奇平台每日生成页面统计

四、总结与展望

富文本编辑器和WebIDE不仅是复杂的系统,而且还是比较热门的研究方向。特别是在和美团的基建结合之后,能够解决团队内部很多效率和质量问题。这套系统还提供了语法智能提示、Diff对比、前置检测、命令行调试等功能,不仅要关注业务发布出去页面的稳定性和质量,更要有内置的一系列研发插件,主动帮助研发提高代码质量,降低不必要的错误。

经过长期的技术和业务演进,Page-佩奇平台已经能够有效地帮助研发人员大幅提升开发效率,具备初级的Design To Code能力,但是仍有许多业务场景值得去我们探索。我们也期待优秀的你参与进来,一起共同建设。

  • WebIDE融合:完善基础设施建设和功能需求,更好地支持Vue、React、ES 6、TS、Less语法,预览模式采用浏览器编译,能有效地提高预览的速度,发布使用后端编译的模式。

  • 研发流程链路:针对代码进行有效评估,包括ESlint、代码重复率、智能提示是否可以三方库替代。出具开发代码质量、业务上线的质量报告。

  • 综合研发平台:减少团队同学了解整体基建的时间成本,内置了监控、性能、任务管理等功能,提升业务开发效率。建设自动化日报、周报系统,降低非开发工作量占比。

  • 物料开放能力:接入公共组件平台,沉淀更多的物料,快速满足产品更多样化的需求。

五、作者简介

高瞻、宇立、肖莹、浩畅,来自美团医药终端团队。王咏、陈文,来自美团闪购终端团队。
来源:https://blog.csdn.net/MeituanTech/article/details/121551030

收起阅读 »

Gradle 与 AGP 构建 API: 配置您的构建文件

欢迎阅读全新的 MAD Skills 系列 之 Gradle 及 Android Gradle plugin API 的第一篇文章。我们将在本文中了解 Android 构建系统的工作方式以及 Gradle 的基础知识。 我们将会从 Gradle 的构建阶段开始...
继续阅读 »

欢迎阅读全新的 MAD Skills 系列GradleAndroid Gradle plugin API 的第一篇文章。我们将在本文中了解 Android 构建系统的工作方式以及 Gradle 的基础知识。


我们将会从 Gradle 的构建阶段开始,讨论如何使用 AGP (Android Gradle Plugin) 的配置选项自定义您的构建,并讨论如何使您的构建保持高效。如果您更喜欢通过视频了解此内容,请在 此处 查看。


通过了解构建阶段的工作原理及配置 Android Gradle plugin 的配置方法,可以帮您基于项目的需求自定义构建。让我们回到 Android Studio,一起看看构建系统是如何工作的吧。


Gradle 简介


Gradle 是一个通用的自动化构建工具。当然,您可以使用 Gradle 来构建 Android 项目,但实际上您可以使用 Gradle 来构建任何类型的软件。


Gradle 支持单一或多项目构建。如果要将项目配置为使用 Gradle,您需要在项目文件夹中添加 build.gradle 文件。


在多项目层级结构中,根项目中会包含一个 settings.gradle 文件,其中列出了构建中包含的其他项目。Android 使用多项目构建来帮您模块化应用。


△ Android 项目结构与 build.gradle 及 settings.gradle 文件


△ Android 项目结构与 build.gradle 及 settings.gradle 文件


由于插件的存在,Gradle 可以处理不同类型的项目,比如 Android 或 Java。这些插件会包含预定义的功能,用于配置和构建特定类型的项目。


例如,为了构建 Android 项目,您需要使用 Android Gradle 插件配置您的 Gradle 构建文件。无论当前的 Android 项目是应用还是依赖库,Android Gradle 插件都知道如何对其进行构建和打包。


Task (任务)


Gradle 的构建流程围绕名为 Task (任务) 的工作单元展开。您可以通过终端查看 Task 列表,或通过启用 Android Studio Gradle 面板中的 Task 列表来查看任务。


△ Gradle Task 列表


△ Gradle Task 列表


这些 Task 可以接收输入、执行某些操作,并根据执行的操作产生输出。


Android Gradle Plugin 定义了自己的 Task,并且知道构建 Android 项目时,需要以何种顺序执行这些 Task。


Gradle 构建文件由许多不同的部分组成。Gradle 的配置语法被称为 Gradle DSL,其为开发者定义了配置插件的方式。Gradle 会解析 build.gradle 文件中的 android DSL 块并创建 AGP DSL 对象,例如 ApplicationExtensionBuildType


典型的 Android 项目会包含一个顶层 Gradle 构建文件。Android 项目中的每个模块又分别有一个 Gradle 构建文件。在示例项目中,我仅有一个应用模块。


在模块层的 build.gradle 文件中,我需要声明和应用构建项目所需的插件。为了让 Gradle 知道我正在构建 Android 项目,我需要应用 com.android.applicationcom.android.library 插件。这两个插件分别定义了如何配置和构建 Android 应用和依赖库。在本例中,我要构建的是 Android 应用项目,所以我需要应用 com.android.application 插件。由于我需要使用 Kotlin,所以在示例中也应用了 kotlin.android 插件。


plugins {
id 'com.android.application'
id 'org.jetbrains.kotlin.android'
}

Android Gradle Plugin 提供了它自己的 DSL,您可以用它配置 AGP,并使该配置在构建时应用于 Task。


想要配置 Android Gradle Plugin,您需要使用 android 块。在该代码块中,您可以为不同的构建类型 (如 debug 或 release) 定义 SDK 版本、工具版本、应用详情及其它一些配置。如需了解更多有关 gradle 如何使用这些信息来创建变体,以及您可以使用哪些其他选项,请参阅 构建文档:


android {
compileSdk 31

defaultConfig {
applicationId "com.example.myapp"
minSdk 21
targetSdk 31
versionCode 1
versionName "1.0"

testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}

buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
kotlinOptions {
jvmTarget = '1.8'
}
}

在下一部分中,您可以定义依赖。Gradle 的依赖管理支持兼容 MavenIvy 的仓库,以及来自文件系统的本地二进制文件。


dependencies {

implementation 'androidx.core:core-ktx:1.7.0'
implementation 'com.google.android.material:material:1.4.0'
implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.4.0'
testImplementation 'junit:junit:4.13.2'
androidTestImplementation 'androidx.test.ext:junit:1.1.3'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'

}

构建阶段


Gradle 分三个阶段评估和运行构建,分别是 Initialization (初始化)、Configuration (配置) 和 Execution (执行),更多请参阅 Gradle 文档


在 Initialization (初始化) 阶段,Gradle 会决定构建中包含哪些项目,并会为每个项目创建 Project实例。为了决定构建中会包含哪些项目,Gradle 首先会寻找 settings.gradle 来决定此次为单项目构建还是多项目构建。


在 Configuration (配置) 阶段,Gradle 会评估构建项目中包含的所有构建脚本,随后应用插件、使用 DSL 配置构建,并在最后注册 Task,同时惰性注册它们的输入。


需要注意的是,无论您请求执行哪个 Task,配置阶段都会执行。为了保持您的构建简洁高效,请避免在配置阶段执行任何耗时操作。


最后,在 Execution (执行) 阶段,Gradle 会执行构建所需的 Task 集合。


下篇文章中,在编写我们自己的插件时,我们将深入剖析这些阶段。


Gradle DSL 支持使用 Groovy 与 Kotlin 脚本编写构建文件。到目前为止,我都在使用 Groovy DSL 脚本来配置此工程的构建。您可以在下面看到分别由 Kotlin 和 Groovy 编写的相同构建文件。注意 Kotlin 脚本文件名后缀为 ".kts"。


△ Kotlin 与 Groovy 脚本对比


△ Kotlin 与 Groovy 脚本对比


从 Groovy 迁移到 Kotlin 或其他配置脚本的方法,不会改变您执行 Task 的方式。


总结


以上便是本文的全部内容。Gradle 与 Android Gradle Plugin 有许多可以让您自定义构建的功能。在本文中,您已经了解了 Gradle Task、构建阶段、配置 AGP 以及使用 DSL 配置构建的基础知识。



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

换一个方式组织你的Axios代码?

自从Jquery被mvvm平替了之后,$.ajax 也被 axios 平替了,在使用这个方式之前,我想大部分的人也想到了去封装一个请求,然后每一次调用去做Get 、Post的请求服务,也有一些人习惯在vue里直接编写 this.$axios.get() ,萝卜...
继续阅读 »

自从Jquery被mvvm平替了之后,$.ajax 也被 axios 平替了,在使用这个方式之前,我想大部分的人也想到了去封装一个请求,然后每一次调用去做Get 、Post的请求服务,也有一些人习惯在vue里直接编写 this.$axios.get() ,萝卜青菜各有所爱,没有优劣之分。



灵感来源


d4axios的灵感来源于open-figen,现在功能还没有那么丰富,但是足以应付多大多数的场景,比如上传、下载、get、post等等请求,配合上ts,可以解决数据类型前后台一致性,数据类型的转换,保证了请求的便利性。让代码专注于数据处理,而非复制粘贴模版代码



别忘了 在 [ts | js]config.json 文件里开启对装饰器的支持。"experimentalDecorators":true



在项目中使用 d4axios



d4axios (Decorators for Axios) 是一款基于axios请求方式的装饰器方法组,可以快速地对服务进行管理和控制,增强前端下服务请求方式,有效降低服务的认知难度,并且在基于ts的情况下可以保证服务的前后台的数据接口一致性



npm i d4axios

yarn add d4axios

一、 引入配置信息


在这里提供了几种配置方式,可以采用原始的axios的配置方法,也可以采用 d4axios 提供的方法


// 在 vue3下我们建议使用 `createService` 
// 其他情况下使用 `serviceConfig`
import { createApp } from 'vue'
import {createService,serviceConfig} from 'd4axios'


createApp(App).use(createService({ ... /* 一些配置信息 */}))


1.1 提供的axios配置项


createServiceserviceConfig 使用的配置项是一样的,并且完全兼容axios的配置。在现有的项目中改造的话,可以使用:


// 可以直接使用由d4axios提供的服务
createService()

// 可直接传入axios的相关配置,由d4axios自动基于配置相关构建
createService({axios:{ baseURL:"domain.origin" }})

// 可直接传入已经配置好的 `axios` 实例对象
const axios = Axios.create({ /* 你的配置*/ });


createService({axios})

1.2 提供基于请求和相应数据的配置


createService({
beforeRequest(requestData){
// form对象会被转为JSON对象的浅拷贝,但是会在该方法执行完后重新转为form对象
// 你可在请求前追加一些补充的请求参数
// 比如对请求体进行签名等等
return requestData
},
beforeResponse(responseData){
// 默认情况下会返回 axios的response.data值,而不会返回response的完整对象
// 可以修改返回的响应结果
return responseData
}
})

1.3 提供快速的axios interceptors 配置


createService({
interceptors:{
request:{
use(AxiosRequestConfig){},
reject(){}
},
response{
use(AxiosResponse){},
reject(){}
}
}
})

配置完成后,会返回一个axios实例对象,可以继续对axios对象做更多的操作,可以绑定到vue.prototype.$axios下使用


Vue.prototype.$axios = serviceConfig({... /*一些配置*/})

二、创建请求服务


为了更好的组织业务逻辑,d4axios提供了一系列的组织方法,供挑选使用


import {Service,Prefix,Get,Post,Download,Upload,Param,After,Header} from 'd4axios'

@Service("UserService") // 需要提供一个服务名称,该名称将在使用服务的时候被用到
@Prefix("/user") // 可以给当前的服务添加一个请求前缀
export class UserService {

@Get("/:id") // 等同于 /user/:id
@After((respData)=>{
//在输出给最终结果前,可以对结果做一些简单处理
return respData
})
async getUserById(id:string){
// 异步请求需要增加 `async` 属性以便语法识别
// 支持restful的方式
}


@Post("/regist")
@Header({'plantform':'android'}) // 请求前追加一些header参数
async registUser(form:UserForm){
// 可以在请求的时候做一些参数修改
form.nickName = createNickName(form.nickName);

// return的值是最终请求的参数
return {
...form,
plant:"IOS"
};
}

@Download("/user/card") // 支持文件下载
async downloadCard(@Param("id") id:stirng){
// 当我们的参数较少并且不是一个key-value形式的值时
// 可以使用@Param辅助,确定传参名称
}

@Upload("/user/card") // 支持文件上传
async uploadCard(file:File){
return {file}
}

// 可以定义同步函数,直接做服务计算
someSyncFunc(){
return 1+1
}

// 我们还可以直接定义非请求函数
async someFunc(){
// 所有的当前函数都是可以直接调用的
return await this.getUserById(this.someSyncFunc());
}

}


三、使用服务



使用服务分为几种方式,第一种是在一个服务中调用另一个服务。第二种是在react或者vue中调用服务,对于这两种有不同的方法,也可以用相同的方法。



3.1 在 vue或者react中使用useService 导入服务


// 在 vue 或者 react中,可以直接使用 useService 导入一个服务对象
import {useService} from 'd4axios'
import SomeService from './some.service'

const someService = useService(SomeService)

复制代码

3.2 在一个服务中Use调用另一个服务


import {Use} from 'd4axios'
import SomeService from './some.service'
// 也可以直接像上面一样的导入进来是用
const someService = useService(SomeService)

@Service("MyService")
export class MyService {
@Use(SomeService) // use 导入服务
// 默认的属性名为小写驼峰
// 用 S<T> 包裹服务名称,这样可以得到相应的async方法的响应类型
someService !: S<SomeService>

async someMethod(){
// 就可以使用了,
await this.someService.something();
}
}

四、响应重写


默认情况下,d4axios支持async响应类型值,该值为


 export interface ResponseDataType<T> { }

在项目根路径下定义 d4axios.d.ts文件
然后文件内定义,通过重写该类型,可以得到响应的 response type类型,比如



export interface ResponseDataType<T> {
data : T;
msg:string ;
code:string ;
}

后即可以得到相关内容的提示信息


dataType.png


五、其他一些基于 Decorators 的操作


5.1 在使用装饰器的class上都可以使用 Use 导入服务 比如:


import {Component,Vue,} from 'vue-class-decorator'
import SomeService from './some.service'

@VueServiceBind(MyService,OtherService) // 只能在vue的这种形式下使用,可以绑定多个值
@Component
export default class MyVueComp extends Vue {

@Use(SomeService) // use 导入服务
// 默认的属性名为小写驼峰
// 用 S<T> 包裹服务名称,这样可以得到相应的async方法的响应类型
someService !: S<SomeService>

myService !: S<MyService>

otherService !: S<OtherService>
}

5.2 在一般的vue的服务下可以使用这种 mapService 形式


// 传统的模式下

import { mapService } from 'd4axios';
import MyService from './MyService.service'

export default {
computed:{
...mapService(MyService,OtherService)
},
created(){
this.myService.getName(10086);
}

作者:非思不可
链接:https://juejin.cn/post/7041930275458285582

收起阅读 »

如何在浏览器 console 控制台中播放视频?

如何在浏览器 console 控制台中播放视频? 要实现这个目标,主要涉及到这几个点: 如何获取和解析视频流? 如何在 console 里播放动态内容? 如何在 console 里播放彩色内容? 如何连接视频流和 console? 事实上最后的代码极其简单...
继续阅读 »

如何在浏览器 console 控制台中播放视频?


要实现这个目标,主要涉及到这几个点:



  1. 如何获取和解析视频流?

  2. 如何在 console 里播放动态内容?

  3. 如何在 console 里播放彩色内容?

  4. 如何连接视频流和 console?


事实上最后的代码极其简单,我们就一步一步简单讲一下


效果



测试地址:yu-tou.github.io/colors-web/…


如何获取和解析视频流?


这里我们用电脑摄像头捕获视频流,然后获取视频流每一帧的图像数据,作为下一步的输入。


// 捕捉电脑摄像头的视频流
const mediaStream = await navigator.mediaDevices.getUserMedia({
video: true,
audio: true,
});
// 创建一个 video 标签
const video = document.createElement("video");
document.body.appendChild(video);

video.onloadedmetadata = function (e) {
video.play(); // 等摄像头数据加载完成后,开始播放
};
// video 标签播放视频流
video.srcObject = mediaStream;

如何获取每一帧图像的数据?创建一个 canvas 画布,可以将 video 当前的内容绘制到画布上,然后通过 canvas 的方法即可拿到图像的像素数据。


const ctx = canvas.getContext("2d");
canvas.width = width;
canvas.height = height;

ctx.drawImage(video, 0, 0, width, height);
const imageData = ctx.getImageData(0, 0, width, height);
const data = imageData.data;
// imageData 的结构是平铺的,需要自己去学习下

如何在 console 里播放动态内容?


视频每帧的图像内容我们已经可以拿到了,继续下一步,如果需要在 console 中完成播放视频,首先需要能够一帧一帧绘制内容,但是这个好像是不太现实的,console.log 只能输出文本。


回想远古时代,在终端里大家怎么播放视频的?没错,用字符画一帧一帧绘制,连起来不就是动态的视频了。


当然 chrome dev tool 里如果每一帧绘制后都调用 console.clear() 清空重绘,体验不是很好,闪烁会很严重,所以我们采用持续输出的方式绘制,当你停留在 console 的最后的时候,看起来也算是动态内容了。


如何在 console 里播放彩色内容?


console.log 支持部分 css 特性,可以为输出的字符串指定简单的样式,最基本的支持背景色、字体颜色、下划线等,甚至支持 background-image、padding 等特性,利用这些特性,甚至可以插入图片,但是这些特性在不同浏览器的 console 中或多或少有些兼容问题,不过要实现字体着色,或者输出色块(用背景色),问题不大。


我们在此使用 colors-web 来更方便地输出彩色内容到控制台。


这是一个非常方便的库,可以使用链式调用在控制台快速输出彩色内容,并且支持诸多特性,无需自己去了解,直接使用对应的方法即可。


如:


import { logger, colors } from "colors-web";
logger(
colors().red().fontsize(48).fontfamily("SignPainter").log("hello"),
colors().white.redBg("hello").linethrough(),
"world",
colors().white.padding(2, 5).underline().lightgrey("芋头")
);

相信我不解释,大家也基本理解这些用法,非常简单和自由,而且支持 typescript。


我们这里,用 colors-web 输出色块:


for (let i = 0; i < height; i++) {
for (let j = 0; j < width; j++) {
if (i * width + j < data.length) {
const color = `rgb(${data[(i * width + j) * 4 + 0]},${data[(i * width + j) * 4 + 1]},${
data[(i * width + j) * 4 + 2]
})`;
colors()
.bg(color)
.color(color)
.fontfamily(/Chrome/.test(navigator.userAgent) ? "Courier" : "")
.log("╳");
}
}
}

最终逻辑


最终我将每一帧所有的像素值都转换成一个 colors 的实例,记录到数组之后,最终统一调用 logger 即可完成一帧的渲染。


const frameColors = [];
for (let i = 0; i < height; i++) {
for (let j = 0; j < width; j++) {
if (i * width + j < data.length) {
const color = `rgb(${data[(i * width + j) * 4 + 0]},${data[(i * width + j) * 4 + 1]},${
data[(i * width + j) * 4 + 2]
})`;
frameColors.push(
colors()
.bg(color)
.color(color)
.fontfamily(/Chrome/.test(navigator.userAgent) ? "Courier" : "")
.log("╳")
);
}
}
}
// 绘制,colors() 只是在准备数据结构,logger 才是真正的输出
logger(...frameColors);

大公告成啦!


作者:芋头君
链接:https://juejin.cn/post/7013620775143866376

收起阅读 »

某科技公司前端三面面经

okay, it's me again. 哈哈哈我怎么也没想到,我又会经历多一次三面,这次可以说是被狠狠的按在地上摩擦了,没办法,只能奉行一贯的“技术不够,吹牛来凑”原则 btw 应该看多点别人的面经,而不是自己写面经,当然自己写也可以当作一个很好的复盘 这次...
继续阅读 »

okay, it's me again.


哈哈哈我怎么也没想到,我又会经历多一次三面,这次可以说是被狠狠的按在地上摩擦了,没办法,只能奉行一贯的“技术不够,吹牛来凑”原则


btw 应该看多点别人的面经,而不是自己写面经,当然自己写也可以当作一个很好的复盘


这次是某家准备上市的公司,公司的技术部门也是挺强大的,所以也才会有三面吧可能


其实复盘过程中记的也不太清楚,只能说想起来一点写一点,这里建议将整个面试过程录音,以便做一次彻底的复盘,当然最好还是取得面试官同意才这么做


面试流程:boss直聘聊 -> 发邮件邀约面试 -> 一面技术面 -> 二面技术面 -> 三面HR面 -> 电话沟通薪资和入职事宜 -> offer


一面技术面




  1. 自我介绍




  2. 一个业务场景,PC端用vue做后台管理系统的时候,一般路由是动态生成的,前端的文件与路由是一一对应的,假如不小心删了一个文件,这个时候就会跳404页面,会有不好的用户体验,怎么做才能比较好的防止跳去404页面?




  3. 有一个页面,一个绝对够长的背景图,我们知道不给盒子设定高度的情况下默认是100%的高度,盒子高度会被内容所撑开。那么怎么做到第一屏完全显示背景图,第二屏也能继续显示呢?


    好,来看我的第一个错误回答🤣


    <style>
    * {
    margin: 0;
    padding: 0;
    }
    .container {
    width: 100%;
    height: 100vh;
    background-image: url('./assets/images/long.jpeg');
    }
    </style>

    <body>
    <div class="container">
    <p>1</p>
    这里复制出足够多的<p>1</p>就好,我就不贴出来重复代码占据太大篇幅了
    </div>
    </body>


    这是第一屏的效果,嗯很好完全没有问题! 但是当我们鼠标来到第二屏就哦豁了🙈




WechatIMG83.jpeg


然后我的第二个回答是:将图片绝对定位,这样图片就能适应不管多少屏了,但是图片绝对定位的话,没有内容撑开,那么第一屏根本都不会出现背景,所以这样也是不行的😅


答案:将 height: 100vh; 换成 min-height: 100vh;就可以了😂




  1. 我们都知道在谷歌浏览器里面字体的最低像素是 12px ,就算设置font-size: 8px;也会变成 12px ,我现在有一个需求需要 8px 的字体,怎么才能突破 12px 的限制?


    基本原理是使用css3的 transform: scale(); 属性


    需求是 8px 的字体,那我们就 font-size: 16px; transform: scale(0.5); 即可




  2. 讲一下 ES6 的新特性




  3. 说一些你经常用到的数组的方法




  4. 前端性能优化


    传送门:聊一聊前端性能优化




  5. 原型链


    传送门:继承与原型链


    传送门:JavaScript原型系列(三)Function、Object、null等等的关系和鸡蛋问题




  6. 假设在一个盒子里,里面所有小盒子的宽高都是相等的(PS技术不好,画的不相等),大盒子刚好放得下7个小盒子,使用css实现下面的布局




WechatIMG84.png




  1. 讲一下微信登录流程




  2. 怎么给每个请求加上 Authorization token ? (考察封装请求,axios 拦截器)




  3. 讲一下 vue 的双向数据绑定原理




  4. 移动端防止重复点击,防抖节流




  5. 怎么触发BFC,有什么应用场景?




  6. Promise有哪几种状态?




  7. 如果现在有一个任务,让你来做主力开发,架构已经搭好了,UI设计图也已经出完了,那你第一步会做什么?




  8. 后台管理系统怎么做权限分配?




  9. 怎么判断一个对象是否为空对象?




  10. 数字1-50的累加,不用 for 循环,用递归写


    因为我很抗拒当场写代码,然后满脑子都是1-50的累加为什么不用 for 循环,用 for 循环不是更快吗?为什么要用递归?但是面试官都把纸笔递过来了,没办法也是只能硬着头皮上了,但是这也是很简单的一道题,下面贴出当时手写的代码(是错的)


        // 这是错的这是错的这是错的
    function add(n) {
    let sum = 0;

    if (n > 0) {
    sum += add(n - 1);
    } else {
    return sum;
    }
    }

    // 这是根据上面改进之后的写法
    function add(n, sum) {
    if (n > 0) {
    return add(n - 1, (sum += n));
    } else {
    return sum;
    }
    }

    // 当然还有一种更为优雅与简便的写法
    function add(n) {
    return n === 0 ? 0 : n + add(n - 1);
    }

    // 想一行代码搞定的话就是
    const add = (n) => (n === 0 ? 0 : n + add(n - 1));



  11. 怎么解决 vuex 里的数据在页面刷新后丢失的问题?




  12. 说一下 vue 组件通信有几种方式(老生常谈的问题)




  13. 说一下 vue 和微信小程序各自的生命周期




  14. 看一下这个 ts 问题


        let num: string = '1';
    转一下数据类型转成 number



  15. 说一下 ts 总共有多少种数据类型




二面技术面




  1. 封装一个级联组件,讲一下思路




  2. 封装 v-model




  3. POST请求的 Content-Type 有多少种?




  4. css flex: 1; 是哪几个属性的组合写法




  5. vue provide/inject 的数据不会及时回流到父组件的问题(我记得没错的话好像是这么问的)




  6. 不用Promise的情况下,怎么实现一个Promise.all()方法




  7. [1, 2, 3].map((item, index) => parseInt(item, index))的结果


    这里考察了两点,1是parseInt()方法的第二个参数有什么作用,2是进制转换的相关知识




  8. cookie,sessionStorage,localStorage 3者之间有什么区别?




  9. http://www.xxx.com (a网站) 和 http://www.api.xxx.com (b网站) 两个网站,在b网站里登录授权拿到了 cookie ,怎么在a网站里拿到这个 cookie ?




  10. 说一下 forEach, map, for...in, for...of 的区别




  11. git fetch和git pull的区别(最后一道题)


    git pull:相当于是从远程获取最新版本并 merge 到本地


    git fetch:相当于是从远程获取最新版本到本地,不会自动 merge


    区别就是会不会自动 merge




三面HR面


这里就不展开了,HR面差不多都是那些东西


以上


其实一面二面还有很多问题都没有写出来,但是碍于当时也没有录音,只记得这么多


严格来讲,这并不太算是一篇面经,在上面很多都只是抛出了问题,因为技术的原因并没有做出相应的解答,还是有些遗憾的



作者:Lieo
链接:https://juejin.cn/post/7021394272519716872

收起阅读 »

亲身经历,大龄程序员找工作,为什么这么难!

背景 临近年底,公司还在招人,可筛选的人才真是越来越少,这可能是因为大家都在等年终奖吧。于是在简历筛选时,将学历和年龄都适当的放松了。正因为如此,面试了不少大龄的程序员。 网络上一直有讨论大龄程序员找工作困境的话题,对于我个人来说,是将信将疑的,但作为程序员对...
继续阅读 »

背景


临近年底,公司还在招人,可筛选的人才真是越来越少,这可能是因为大家都在等年终奖吧。于是在简历筛选时,将学历和年龄都适当的放松了。正因为如此,面试了不少大龄的程序员。


网络上一直有讨论大龄程序员找工作困境的话题,对于我个人来说,是将信将疑的,但作为程序员对自己职业生涯和未来的危机感还是有的。同时,作为技术部门领导,我是不介意年龄比我大,能力比我强的人加入的,只要能把事做好,这都不是事。


随着互联网的发展,大量程序员必然增多,都找不到工作是不可能的。而且中国的未来必然也会像发达国家一样,几十岁甚至一辈子都在写代码,也不是有可能的。


那么,我们担忧的是什么呢?又是什么影响了找工作呢?本文就通过自己亲身面试的几个典型案例来说说,可能样本有些小,仅供参考,不喜勿喷。


大厂与小厂招人的区别


前两天在朋友圈发了一条招人的感慨,关于大厂招人和小公司招人的区别。


大厂:有影响力,有钱,能够吸引了大量的应聘者。因此,也就有了筛选的资格,比如必须985名校毕业,必须35岁以下,不能5年3跳,必须这个……不能那个……当员工不合适时,绩效分给的低点或直接赔钱让其出局。


小公司:没有品牌,资金有限,每一分钱都要精打细算。招聘的人选有限,在这有限的选择范围内,还要考虑成本、能不能用、能不能留住等问题。能力太强,给不起钱,留不住;能力太弱,只会让项目越来越糟糕;所以,最好的选择只能是稍微高于现有团队能力,又不至于轻易跳槽的人。


有了上面的基本前提,再来看看大厂与小厂对待大龄程序员的差别。


对于35岁以后的程序员,有的大厂已经直接卡死,也就别死磕了。另外一些大厂还是开放的,但肯定是有一定的要求的,比如职位必须达到什么等级,能力必须达到什么要求。换句话说,如果你是牛人,其实35岁并不是什么问题,如果不是,那么这个选项几乎不存在。


所以,大厂的选择基本上等于没什么选择。再来看看小公司,小公司追求的核心是性价比,或者直白点说就是能干事且节省成本。另外就是能不能一职多能,能不能带新人,能不能加班……


个人看来,相对于大厂的要求,小公司的要求稍微努力一下还是可以满足的。对于加班这一项,不是所有的公司都有加班文化,也不是所有的公司常年需要加班。


招聘案例


挑选面试中几个比较典型的案例来聊聊,看看对你有什么启发。


案例一


84年的应聘者,自己在简历上填写的是应聘“中高级Java开发”。面试中,各项技能都平平,属于有功能开发经验,但没有深钻技术,没有考虑更好解决方案的状态。明确加班不能超过9点。也有写博客和公众号。9月份离职,目前暂未未找到工作。


就这位应聘者而言:第一,能接受员工比自己年龄大的领导不多,因为担心管不住;第二,技能没有亮点,就像他自己定位的那样,十多年工作经验,只是中高级开发;第三,加班这一项卡的太死,哪家公司上个线不到10点以后了,有突发需求不加个班?


案例二


86年的应聘者,别家公司裁员,推荐过来的简历。十来年工作经验,一直负责一个简单彩会不会是敏感词票业务的开发,中间有几年还没有项目履历。简历上写的功能还是:用户管理、权限管理、XX接口对接。推荐他的老板,给他的定位是中级开发。


这位应聘者,真的是将一年的代码写了十年。上家老板裁员选择了他,定位也只是中级,然后帮忙推荐了他到其他公司。这背后的故事,你仔细品,再仔细品。


案例三


87年的应聘者,学历一般,这两年的工作履历有点糟糕,跳槽的时机选择的也不好。长期从事支付行业,十来年的工作履历中,有七八年在做支付及相关的行业,其中在一家支付公司工作了四年。面试中,特意问了行业中的一些解决方案、技术实现,都没问题。基础知识稍微有点弱,但影响不大。面试过后,发了Offer,其中我还在老板面前帮忙争取了一把。


这位应聘者,虽然在学历,近两年的经历,基础知识上都略有不足。但他的行业经验丰富,给人一种踏实做事的感觉。整体能力恰好符合上面提到的小公司选择标准:比现有团队人能力强,有行业经验,薪资适中,稳定性较好。他的长板完全弥补了短板。


案例四


91年的应聘者,一家小有名气二线互联网公司出来。最近半年未工作,给出的原因是:家中有事,处理了半年,现在决定找工作了。聊半年前做过的项目,基本上记不起逻辑了;聊技术知识,也只能说个大概,但能感觉还是做过一些功能的,但没有深入思考过或没有做过复杂逻辑。


这位应聘者,不确定已经面试多久了,但应该不那么容易找工作。第一,半年未工作,即使有原因,也让人多少有些顾虑;第二,面试前完全没做功课,这不是能力问题,而是态度的问题了。


上面的案例,有成功的也有失败的。总结一下失败的原因,基本上有几点:能力与年龄不匹配、不能加班、家庭影响、没有特长……当然,你如果能看到其他的失败原因,那就更好了。


小结


上面只是最近一段时间面试的几个典型案例,至于你能从中获得什么,能不能提前行动,做好准备。那就是大家自己的事了。当然,还是那句话,样本有些小,但也能说明一些问题。仅个人观点,不抬杠,不喜勿喷。


我也曾为职场的未来担忧,也曾为年龄担忧,但始终未放弃的就是持续学习和思考。多位朋友都曾说过:无论你是否当上领导,是否还在写代码,技术能力都不能丢,你必须是团队中技术最牛的那一个。我一直在努力做到,你呢


作者:程序新视界
链接:https://juejin.cn/post/7043589223345029133

收起阅读 »

当 Adapter 遇上 Kotlin DSL,无比简单的调用方式

早在去年的时候我就提到过使用工厂的方式获取 Adapter 而不是为每个 Adapter 定义一个类文件。这样的好处是,对于不是那么复杂的 Adapter 可以节省大量的代码,提升开发效率和解放双手,同时更好的支持多类型布局效果。 1、Kotlin DSL 和...
继续阅读 »

早在去年的时候我就提到过使用工厂的方式获取 Adapter 而不是为每个 Adapter 定义一个类文件。这样的好处是,对于不是那么复杂的 Adapter 可以节省大量的代码,提升开发效率和解放双手,同时更好的支持多类型布局效果。


1、Kotlin DSL 和 Adapter 工厂方法


可以把 Kotlin DSL 当作构建者使用。这里有一篇不错的文章,想了解的可以阅读下,



http://www.ximedes.com/2020-04-21/…



Kotlin DSL 是拓展函数的延申,比如我们常用的 with 等函数就是函数的拓展,


public inline fun <T, R> with(receiver: T, block: T.() -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return receiver.block()
}

这里是泛型 T 的拓展。这里的 T 可以类比到 Java 构建者模式中的 Builder,通过方法接收外部参数之后调用 build() 方法创建一个最终的对象即可。


对于 Adapter 工厂方法,之前我是通过如下方式使用的,


fun <T> getAdapter(
@LayoutRes itemLayout:Int,
converter: (helper: BaseViewHolder, item: T) -> Unit,
data: List<T>
): Adapter<T> = Adapter(itemLayout, converter, data)

class Adapter<T>(
@LayoutRes private val layout: Int,
private val converter: (helper: BaseViewHolder, item: T) -> Unit,
val list: List<T>
): BaseQuickAdapter<T, BaseViewHolder>(layout, list) {
override fun convert(helper: BaseViewHolder, item: T) {
converter(helper, item)
}
}

也就是每次想要得到 Adapter 的时候只要调用 getAdapter() 方法即可。这种封装方式比较简陋,支持的功能有限。后来慢慢采用了 Kotlin DSL 之后,我封装了 Kotlin DSL 风格的工厂方法。采用 Kotlin DSL 风格之后更加优雅和方便快捷,同时更好的支持多类型布局效果。


2、使用


2.1 引入依赖


首先,该项目依赖于 BRVAH,所以,你需要引入该库之后才可以使用。BRVAH 可以说是目前开源的最好用的 Adapter,我们没必要再另起炉灶自己再造轮子。这个框架设计最好地方在于通过 SpareArray 收集了 ViewHolder 控件,从而避免了自定义 ViewHolder,这是我们框架设计的基础思想。


该项目已经上传到了 MavenCentral,你需要先在项目中引入该仓库,


allprojects {
repositories {
mavenCentral()
}
}

然后在项目中添加如下依赖,


implementation "com.github.Shouheng88:xadapter:${latest_version}"

2.2 使用 Adapter 工厂方法


使用 xAdapter 之后,当你需要定义一个 Adapter 的时候,你无需单独创建一个类文件,只需要通过 createAdapter() 方法获取一个 Adapter,


adapter = createAdapter {
withType(Item::class.java, R.layout.item_eyepetizer_home) {
// Bind data with viewholder.
onBind { helper, item ->
helper.setText(R.id.tv_title, item.data.title)
helper.setText(R.id.tv_sub_title, item.data.author?.name + " | " + item.data.category)
helper.loadCover(requireContext(), R.id.iv_cover, item.data.cover?.homepage, R.drawable.recommend_summary_card_bg_unlike)
helper.loadRoundImage(requireContext(), R.id.iv_author, item.data.author?.icon, R.mipmap.eyepetizer, 20f.dp2px())
}
// Item level click and long click events.
onItemClick { _, _, position ->
adapter?.getItem(position)?.let {
toast("Clicked item: " + it.data.title)
}
}
}
}

在这种新的调用方式中,你需要通过 withType() 方法指定数据类型及其对应的布局文件,然后在 onBind() 方法中即可实现数据到 ViewHolder 的绑定操作。这里的 onBind() 方法的使用与 BRVAH 中的 convert() 方法使用一致,可以通过阅读该库了解如何使用。总之,xAapter 在 BRVAH 的基础上做了二次封装,可以说,比简单更简单。


xAdapter 支持为每个 ViewHolder 绑定点击和长按事件,同时也支持为 ViewHolder 上的某个单独的 View 添加点击和长按事件。使用方式如上所示,只需要添加 onItemClick() 方法并实现自己的逻辑即可。其他的点击事件可以参考项目的示例代码。


效果,





2.3 使用多类型 Adapter


多类型 Adapter 的使用方式非常简单,类似于上面的调用方式,只需要在 createAdapter() 内再添加一个 withType() 方法即可。下面是一个写起来可能相当复杂的 Adapter,但是采用了 xAdpater 的调用方式之后,一切变得非常简单,


private fun createAdapter() {
adapter = createAdapter {
withType(MultiTypeDataGridStyle::class.java, R.layout.item_list) {
onBind { helper, item ->
val rv = helper.getView<RecyclerView>(R.id.rv)
rv.layoutManager = GridLayoutManager(context, 3)
val adapter = createSubAdapter(R.layout.item_home_page_data_module_1, 1)
rv.adapter = adapter
adapter.setNewData(item.items)
}
}
withType(MultiTypeDataListStyle1::class.java, R.layout.item_home_page_data_module_2) {
onBind { helper, item ->
converter.invoke(helper, item)
}
onItemClick { _, _, position ->
(adapter?.getItem(position) as? MultiTypeDataListStyle1)?.let {
toast("Clicked style[2] item: " + it.item.data.title)
}
}
}
withType(MultiTypeDataListStyle2::class.java, R.layout.item_list) {
onBind { helper, item ->
val rv = helper.getView<RecyclerView>(R.id.rv)
rv.layoutManager = LinearLayoutManager(context, RecyclerView.HORIZONTAL, false)
val adapter = createSubAdapter(R.layout.item_home_page_data_module_4, 3)
rv.adapter = adapter
adapter.setNewData(item.items)
}
}
withType(MultiTypeDataListStyle3::class.java, R.layout.item_home_page_data_module_3) {
onBind { helper, item ->
converter.invoke(helper, item)
}
onItemClick { _, _, position ->
(adapter?.getItem(position) as? MultiTypeDataListStyle3)?.let {
toast("Clicked style[4] item: " + it.item.data.title)
}
}
}
}
}

xAdapter 对多类型布局方式的支持是在 BRVAH 之上进行的改造,在这种封装方式中,数据类无需实现任何类和接口。Adpater 内部通过 Class 区分各个 ViewHolder.


效果,





总结


相对于为各种类型的数据定义 Adapter 的使用方式,以上封装方式的优势是:



  1. 借助 BRVAH 的优势,封装了大量的方法,进一步简化了 Adapter 的使用;

  2. 通过工厂和 DSL 封装,简化了调用 Adapter 的方式,你无需为数据类型定义 Adapter 文件,减少了项目中需要维护的代码和类文件数量;

  3. 通过以上封装,使用 Adapter 更加简洁,节省了大量的代码,提升开发效率和解放双手;

  4. 自由地在单一类型布局和多类型布局之间进行切换,但是少了没必要的工厂方法。


当有更加简洁的使用方式的时候,继续采用复杂的调用方式无异于抱残守缺,对于程序员而言,做这种重复而没有太大价值的工作,付出再多的汗水都不值得同情。以上是部分功能和代码的展示,可以通过阅读源码了解更多。后续我参考其他优秀的库的设计思想,支持更多 Adapter 特性的封装来实现快速调用。


项目已开源,感兴趣的可以直接阅读项目源码,源码地址:github.com/Shouheng88/…


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

我用Flutter写了一个上班摸鱼应用

网上最近看到了个摸鱼应用,还挺好玩的。我打算自己用flutter写了一个之前我有用flutter制作过mobile应用,但是没有在desktop尝试过;毕竟2.0大更新,我这里就在这试手一下,并说说flutter的体验.当前flutter环境 2.8增加flu...
继续阅读 »

网上最近看到了个摸鱼应用,还挺好玩的。

moyu.jpeg

我打算自己用flutter写了一个

之前我有用flutter制作过mobile应用,但是没有在desktop尝试过;毕竟2.0大更新,我这里就在这试手一下,并说说flutter的体验.

当前flutter环境 2.8

截屏2021-12-18 上午9.59.29.png

增加flutter desktop支持 (默认项目之存在ios,android项目包)

flutter config --enable-<platform>-desktop

我这里是mac,因此platform=macos,详细看flutter官网

代码十分简单,UI部分就不讲了

在摸鱼界面,我是用了 Bloc 做倒计时计算逻辑,默认摸鱼时长15分钟

 MoYuBloc() : super(MoyuInit()) {
on(_handleMoyuStart);
on(_handleUpdateProgress);
on(_handleMoyuEnd);
}

摸鱼开始事件处理

// handle moyu start action
FutureOr<void> _handleMoyuStart(
MoyuStarted event, Emitter<MoyuState> emit) async {
if (_timer != null && _timer!.isActive) {
_timer?.cancel();
}

final totalTime = event.time;
int progressTime = state is MoyuIng ? (state as MoyuIng).progressTime : 0;

_timer = Timer.periodic(const Duration(seconds: 1), (timer) {
add(MoyuProgressUpdated(totalTime, ++progressTime));

if (progressTime >= totalTime) {
timer.cancel();
add(MoyuEnded());
}
});
emit(MoyuIng(progress: 0, progressTime: 0));
}

摸鱼进度更新

// handle clock update
FutureOr<void> _handleUpdateProgress(
MoyuProgressUpdated event, Emitter<MoyuState> emit) async {
final totalTime = event.totalTime;
final progressTime = event.progressTime;
emit(
MoyuIng(progress: progressTime / totalTime, progressTime: progressTime),
);
}

摸鱼结束,释放结束事件

// handle clock end
FutureOr<void> _handleMoyuEnd(
MoyuEnded event, Emitter<MoyuState> emit) async {
emit(MoyuFinish());
}
总结3个event (摸鱼开始,进程更新,摸鱼结束)

abstract class MoyuEvent {}

class MoyuStarted extends MoyuEvent {
final int time;
final System os;

MoyuStarted({required this.time, required this.os});
}

class MoyuProgressUpdated extends MoyuEvent {
final int totalTime;
final int progressTime;

MoyuProgressUpdated(this.totalTime, this.progressTime);
}

class MoyuEnded extends MoyuEvent {
MoyuEnded();
}

其中3个state (摸鱼初始,正在摸鱼,摸鱼结束)

abstract class MoyuState {}

class MoyuInit extends MoyuState {}

class MoyuIng extends MoyuState {
final double progress;
final int progressTime;

MoyuIng({required this.progress, required this.progressTime});
}

class MoyuFinish extends MoyuState {}

启动摸鱼使用, 记录总时长和消耗时间,计算进度百分比,更新UI进度条

下面是界面更新逻辑

BlocConsumer<MoYuBloc, MoyuState>(
builder: (context, state) {
if (state is MoyuIng) {
final progress = state.progress;

return _moyuIngView(progress);
} else if (state is MoyuFinish) {
return _replayView();
}
return const SizedBox();
},
listener: (context, state) {},
listenWhen: (pre, cur) => pre != cur,
),

很简单 最重要的是进度状态,其次结束后是否重新摸鱼按钮

构建运行flutter应用

flutter run -d macos 

最后结果展示

windows_update.png

mac_update.png

总结下flutter desktop使用

  1. 简单上手,按着官网走基本没问题,基本上没踩上什么雷,可能项目比较简单
  2. 构建流程简单,hot reload强大
  3. 性能强大,启动速度很快,并且界面无顿挫感

比较遗憾的事desktop电脑构建系统独立,mac环境下无法构建windows应用,有点小遗憾.

项目完全开源 可以前往GitHub查看 不要忘点个star😊

github.com/lau1944/moy…


作者:1vau
链接:https://juejin.cn/post/7042864240817864740
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

丢掉丑陋的 toast,会动的 toast 更有趣!

前言 我们通常会用 toast(也叫吐司)来显示提示信息,例如网络请求错误,校验错误等等。大多数 App的 toast 都很简单,简单的半透明黑底加上白色文字草草了事,比如下面这种. 说实话,这种toast 的体验很糟糕。假设是新手用户,他们并不知道 toa...
继续阅读 »

前言


我们通常会用 toast(也叫吐司)来显示提示信息,例如网络请求错误,校验错误等等。大多数 App的 toast 都很简单,简单的半透明黑底加上白色文字草草了事,比如下面这种.
image.png
说实话,这种toast 的体验很糟糕。假设是新手用户,他们并不知道 toast 从哪里出来,等出现错误的时候,闪现出来的时候,可能还没抓住内容的重点就消失了(尤其是想截屏抓错误的时候,更抓狂)。这是因为一个是这种 toast 一般比较小,而是动效非常简单,用来提醒其实并不是特别好。怎么破?本篇来给大家介绍一个非常有趣的 toast 组件 —— motion_toast


motion_toast 介绍


从名字就知道,motion_toast 是支持动效的,除此之外,它的颜值还很高,下面是它的一个示例动图,仔细看那个小闹钟图标,是在跳动的哦。这种提醒效果比起常用的 toast 来说醒目多了,也更有趣味性。
center_motion_toast_2.gif
下面我们看看 motion_toast 的特性:



  • 可以通过动画图标实现动效;

  • 内置了成功、警告、错误、提醒和删除类型;

  • 支持自定义;

  • 支持不同的主题色;

  • 支持 null safety;

  • 心跳动画效果;

  • 完全自定义的文本内容;

  • 内置动画效果;

  • 支持自定义布局(LTR 和 RTL);

  • 自定义持续时长;

  • 自定义展现位置(居中,底部或顶部);

  • 支持长文本显示;

  • 自定义背景样式;

  • 自定义消失形式。


可以看到,除了能够开箱即用之外,我们还可以通过自定义来丰富 toast 的样式,使之更有趣。


示例


介绍完了,我们来一些典型的示例吧,首先在 pubspec.yaml 中添加依赖motion_toast: ^2.0.0(最低Dart版本需要2.12)。


最简单用法


只需要一行代码搞定!其他参数在 success 的命名构造方法中默认了,因此使用非常简单。


MotionToast.success(description: '操作成功!').show(context);

其他内置的提醒


内置的提醒也支持我们修改默认参数进行样式调整,如标题、位置、宽度、显示位置、动画曲线等等。


// 错误提示
MotionToast.error(
description: '发生错误!',
width: 300,
position: MOTION_TOAST_POSITION.center,
).show(context);

//删除提示
MotionToast.delete(
description: '已成功删除',
position: MOTION_TOAST_POSITION.bottom,
animationType: ANIMATION.fromLeft,
animationCurve: Curves.bounceIn,
).show(context);

// 信息提醒(带标题)
MotionToast.info(
description: '这是一条提醒,可能会有很多行。toast 会自动调整高度显示',
title: '提醒',
titleStyle: TextStyle(fontWeight: FontWeight.bold),
position: MOTION_TOAST_POSITION.bottom,
animationType: ANIMATION.fromBottom,
animationCurve: Curves.linear,
dismissable: true,
).show(context);

不过需要注意的是,一个是 dismissable 参数只对显示位置在底部的有用,当在底部且dismissabletrue 时,点击空白处可以让 toast 提前消失。另外就是显示位置 positionanimationType 是存在某些互斥关系的。从源码可以看到底部显示的时候,animationType不能是 fromTop,顶部显示的时候 animationType 不能是 fromBottom


void _assertValidValues() {
assert(
(position == MOTION_TOAST_POSITION.bottom &&
animationType != ANIMATION.fromTop) ||
(position == MOTION_TOAST_POSITION.top &&
animationType != ANIMATION.fromBottom) ||
(position == MOTION_TOAST_POSITION.center),
);
}

自定义 toast


自定义其实就是使用 MotionToast 构建一个实例,其中,descriptioniconprimaryColor参数是必传的。自定义的参数很多,使用的时候建议看一下源码注释。


MotionToast(
description: '这是自定义 toast',
icon: Icons.flag,
primaryColor: Colors.blue,
secondaryColor: Colors.green[300],
descriptionStyle: TextStyle(
color: Colors.white,
),
position: MOTION_TOAST_POSITION.center,
animationType: ANIMATION.fromRight,
animationCurve: Curves.easeIn,
).show(context);

下面对自定义的一些参数做一下解释:



  • icon:图标,IconData 类,可以使用系统字体图标;

  • primaryColor:主颜色,也就是大的背景底色;

  • secondaryColor:辅助色,也就是图标和旁边的竖条的颜色;

  • descriptionStyle:toast 文字的字体样式;

  • title:标题文字;

  • titleStyle:标题文字样式;

  • toastDuration:显示时长;

  • backgroundType:背景类型,枚举值,共三个可选值,transparentsolidlighter,默认是 lighterlighter其实就是加了一层白色底色,然后再将原先的背景色(主色调)加上一定的透明度叠加到上面,所以看起来会泛白。

  • onClose:关闭时回调,可以用于出现多个错误时依次展示,或者是关闭后触发某些动作,如返回上一页。


总结


看完之后,是不是觉得以前的 toast 太丑了?用 motion_toast来一个更有趣的吧。另外,整个 motion_toast 的源码并不多,有兴趣的可以读读源码,了解一下toast 的实现也是不错的。


作者:岛上码农
链接:https://juejin.cn/post/7042301322376265742
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Android 常见内存泄漏总结、避免踩坑、提供解决方案

对常见的内存泄漏进行一波总结,希望可以帮到大家。静态实例持有非静态内部类描述🤦♀️非静态内部类会持有外部类的实例,所以如果非静态内部类的实例是静态的话,那么它的生命周期就是整个APP的生命周期,而它则会一直持有外部类的引用,阻止外部类实例被系统回收。举个例子🌰...
继续阅读 »



对常见的内存泄漏进行一波总结,希望可以帮到大家。

静态实例持有非静态内部类

描述🤦♀️

非静态内部类会持有外部类的实例,所以如果非静态内部类的实例是静态的话,那么它的生命周期就是整个APP的生命周期,而它则会一直持有外部类的引用,阻止外部类实例被系统回收。

举个例子🌰:

public class TestActivity extends AppCompatActivity {

   static InnerClass innerClass;

   @Override
   protected void onCreate(@Nullable Bundle savedInstanceState) {

       super.onCreate(savedInstanceState);
       setContentView(R.layout.item_layout);
       findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {

           @Override
           public void onClick(View v) {
               innerClass = new InnerClass();
          }
      });
  }

   class InnerClass{
 
    }
}

此时点击button时,会创建InnerClass实例并且赋值给innerClass。因为innerClassstatic修饰,所以InnerClass实例的生命周期会和应用程序一样长,但是它会持有TestActivity的实例,所以就会导致如果系统需要回收不了TestActivity的实例。造成内存泄漏😮。

解决办法🙆♀️

  • 将非静态内部类替换成静态内部类,因为静态内部类不会持有外部类的引用

  • 一定要用非静态内部类的话,要保证内部类的生命周期短于外部类

耗时任务相关的匿名内部类/非静态内部类

描述🤦♀️

这个和上一个类似,非静态内部类持有外部类的实例大家都知道了,这里不在叙述了;匿名内部类也会持有外部类的实例,而且匿名内部类会结合线程使用得多,这里就拉出来讲一下。

同理因为匿名内部类会持有外部类的实例,比如线程的Runable如果在里面做了耗时任务,在外部类对象需要回收的时候,但是线程任务没有执行完,那么就会因为匿名内部类持有外部类的引用,进而阻止系统回收外部类对象了。

简单举个例子

public class TestActivity extends AppCompatActivity {

   @Override
   protected void onCreate(@Nullable Bundle savedInstanceState) {

       super.onCreate(savedInstanceState);
       setContentView(R.layout.item_layout);
       findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {

           @Override
           public void onClick(View v) {
               ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.MICROSECONDS, new SynchronousQueue(), new ThreadFactory() {
                   @Override
                   public Thread newThread(Runnable r) {
                       return new Thread(new ThreadGroup("test-thread"),r);
                  }
              });
               threadPoolExecutor.submit(new Runnable() {
                   @Override
                   public void run() {
                       while (true){
                           Log.d("TAG", "run: test");
                      }
                  }
              });
          }
      });
  }
}

点击button执行线程任务,提交了一个runable进去,因为里面死循环永远不会结束。所以匿名内部类会一直持有TestActivitty对象。不会被系统回收掉😮。因为匿名内部类这玩意进场使用,所以还是需要注意的!!!🤦♀️

解决方案🙆♀️

  • 将匿名内部类/非静态内部类替换成静态内部类,因为静态内部类不会持有外部类的引用

  • 一定要用匿名内部类/非静态内部类的话,要保证内部类的生命周期短于外部类

Handle内存泄漏

描述🤦♀️

这个就有点老生常谈了😂,但还是的说一下。

Handler发送的Message会存储在MessageQueue里面,但是他们不一定马上就被处理了。

另外我们知道Message的Target会持有记录当前的Handler对象,用于进行消息分发。所以如果Message不被及时处理,那么Handler就无法被回收。

那么如果此时Handler是非静态的,则Handler也会导致引用它的Activity不能被回收😮。

举个例子🌰

public class TestActivity extends AppCompatActivity {

   @Override
   protected void onCreate(@Nullable Bundle savedInstanceState) {

       super.onCreate(savedInstanceState);
       setContentView(R.layout.item_layout);
       Handler mHandler = new Handler(){

           @Override
           public void handleMessage(Message msg) {
               super.handleMessage(msg);
          }
      };
       findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {

           @Override
           public void onClick(View v) {
   
               mHandler.sendMessageDelayed(new Message(),100000);
               finish();
          }
      });
  }
}

当点击button时,会finish当前activity。但是因为消息没有被及时处理,间接引用了Handler对象,Handler又是匿名内部类实例,持有了activity对象。所以导致内存泄漏🤦♀️。

解决方案🙆♀️

  • 使用静态Handler内部类,handler的持有者用弱引用。

  • 在onDestroy中将未执行的消息和Callbacks清除。

    if (mHandler != null) {
        mHandler.removeCallbacksAndMessages(null);
    }

Context被长期持有

描述🤦♀️

这个也很简单,比如你把Activity的Context传给了一个长期存在的对象,那其实activity的context就是它自身,那么因为被持有就回收不了。造成内存泄漏

解决方案🙆♀️

  • 对于不是必须使用Activity的Context的情况(Dialog的Context必须使用Activity的Context),可以考虑使用Application来代替Activity的Context,因为一般使用Context无非时获取一些资源而已。

  • 一定要传入Activity的Context的话,一定要注意生命周期,不可以被长期引用。

View被静态修饰

描述🤦♀️

这个。。。。我估计没有多少人这么使用吧。如果View被静态修饰的话,因为View会持有Context,所以就会导致当前Activity不会被回收。🤦♀️

举个例子🌰

public class TestActivity extends AppCompatActivity {

   static View button;

   @Override
   protected void onCreate(@Nullable Bundle savedInstanceState) {

       super.onCreate(savedInstanceState);
       setContentView(R.layout.item_layout);
       button = findViewById(R.id.button);
  }
}

解决方案🙆♀️

  • 在onDestory中将view置null。

大对象/监听器释放

描述🤦♀️

大对象比如Bitmap

Bitmap对象一般比较大,而且好多操作都需要变换产生新的对象。所以需要注意一定要尽快释放临时的Bitmap对象用于节省内存。尽量避免被静态修饰或者其他长生命周期引用。

监听器的释放

很多服务需要register和unregister监听器,需要在合适的时候及时的unregister这些监听器否则容易产生内存泄漏。

解决方案🙆♀️

  • 大对象及时释放

  • 监听器在合适的时候进行释放

资源对象注意关闭

描述🤦♀️

资源对象比如File、Cursor等,如果不进行正常关闭,会造成内存泄漏。

解决方案🙆♀️

  • 通常使用异常代码块捕获,在finally语句中进行关闭,防止出现异常资源没有被正常释放问题。

集合对象

描述🤦♀️

注意一些生命周期很长的集合,比如被static修饰的集合,它的生命周期会时APP的生命周期,那么它里面维持的对象,如果在没用之后要即使清理掉,否则就会造成内存泄漏。

举个例子🌰

public class TestActivity extends AppCompatActivity {

   static List<View> vies;

   @Override
   protected void onCreate(@Nullable Bundle savedInstanceState) {

       super.onCreate(savedInstanceState);
       setContentView(R.layout.item_layout);
       vies.add(findViewById(R.id.button));
  }
}

view被加入集合,因为集合生命周期为APP的生命周期,所以View、Activity也回收不了,内存泄漏。

解决方案🙆♀️

  • 这个完全需要自己注意,对于长生命周期集合内部对象的管理。

————————————————
作者:pumpkin的玄学
来源:https://blog.csdn.net/weixin_44235109/article/details/122029725

收起阅读 »

JavaScript函数封装随机颜色验证码

数字或者字母或者数字字母混合的n位验证码带随机的颜色。下面是完整的代码,需要的自取哈!function verify(a = 6,b = "num"){ //定义三个随机验证码验证码库 var num ="0123456789" var str ="ab...
继续阅读 »

数字或者字母或者数字字母混合的n位验证码带随机的颜色。下面是完整的代码,需要的自取哈!

function verify(a = 6,b = "num"){
//定义三个随机验证码验证码库
var num ="0123456789"
var str ="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNIPQRSTUVWXYZ"
var mixin = num +str;
 
//定义一个空字符串用来存放验证码
var verify=""
if(a == undefined || b == undefined){
  //验证输入是否合法 不通过就抛出一个异常
  throw new Error("参数异常");
}else{
    if(a ==""||b==""){
      //判断用户是否没有输入
      throw new Error("参数非法.");
    }else{
      //检测输入的类型来判断是否进入
      var typea = typeof(a);
      var typeb = typeof(b);
      if(typea =="number" && typeb =="string"){
          if(b == "num"){
                 
              //定义一个循环来接收验证码   纯数字验证码
              for(var i=0;i<a;i++){
                    //定义一个变量来存储颜色的随机值
                    var r1 = Math.random()*255;
                    var g1 = Math.random()*255;
                    var b1 = Math.random()*255;

                    //确定随机索引
                    var index = Math.floor(Math.random()*(num.length-1))
                    //确定随机的验证码
                    var char = num[index];
                    //给随机的验证码加颜色
                    verify += `<span style ='color:rgb(${r1},${g1},${b1})'>${char}</span>`
                }
                //返回到数组本身
              return verify;
          }else if(b =="str"){
                for(var i=0;i<a;i++){
                  //纯字母的验证码
                  var r1 = Math.random()*255;
                  var g1 = Math.random()*255;
                  var b1 = Math.random()*255;

                  var index = Math.floor(Math.random()*(str.length-1));
                  var char = str[index];

                  verify += `<span style ='color:rgb(${r1},${g1},${b1})'>${char}</span>`
                }
                return verify;  
          }else if(b == "mixin"){
                // 混合型的验证码
              for(var i=0;i<a;i++){
                  var r1 = Math.random()*255;
                  var g1 = Math.random()*255;
                  var b1 = Math.random()*255;

                  var index = Math.floor(Math.random()*(mixin.length-1));
                  var char = mixin[index];

                  verify += `<span style ='color:rgb(${r1},${g1},${b1})'>${char}</span>`
              }
              return verify;
          }else{
              //验证没通过抛出一个异常
              throw new Error("输入类型非法.")
          }
       
      }else{
          //验证没通过抛出一个异常
          throw new Error("输入类型非法.")
      }
    }
}
}

下面我们来调用函数试试看

  //第一个值为用户输入的长度,第二个为类型! 
var arr = verify(8,"mixin");
    document.write(arr)

上面就是结果啦!

这个记录下来为了方便以后使用的方便,也希望大佬们多多交流,多多留言,指出我的不足的之处啦!

有需要的小伙伴可以研究研究啦!!
————————————————
作者:土豆切成丝
来源:https://blog.csdn.net/A20201130/article/details/122030872

收起阅读 »

localhost、127.0.0.1和0.0.0.0和本机IP的区别

localhostlocalhost其实是域名,一般windows系统默认将localhost指向127.0.0.1,但是localhost并不等于127.0.0.1,localhost指向的IP地址是可以配置的 127.0.0.1首先我们要先知道一...
继续阅读 »
localhost
localhost其实是域名,一般windows系统默认将localhost指向127.0.0.1,但是localhost并不等于127.0.0.1,localhost指向的IP地址是可以配置的
 
127.0.0.1
首先我们要先知道一个概念,凡是以127开头的IP地址,都是回环地址(Loop back address),其所在的回环接口一般被理解为虚拟网卡,并不是真正的路由器接口。
所谓的回环地址,通俗的讲,就是我们在主机上发送给127开头的IP地址的数据包会被发送的主机自己接收,根本传不出去,外部设备也无法通过回环地址访问到本机。
 
小说明:正常的数据包会从IP层进入链路层,然后发送到网络上;而给回环地址发送数据包,数据包会直接被发送主机的IP层获取,后面就没有链路层他们啥事了。
而127.0.0.1作为{127}集合中的一员,当然也是个回环地址。只不过127.0.0.1经常被默认配置为localhost的IP地址。
一般会通过ping 127.0.0.1来测试某台机器上的网络设备是否工作正常。
 
0.0.0.0
首先,0.0.0.0是不能被ping通的。在服务器中,0.0.0.0并不是一个真实的的IP地址,它表示本机中所有的IPV4地址。监听0.0.0.0的端口,就是监听本机中所有IP的端口。
 
本机IP
本机IP通常仅指在同一个局域网内,能同时被外部设备访问和本机访问的那些IP地址(可能不止一个)。像127.0.0.1这种一般是不被当作本机IP的。本机IP是与具体的网络接口绑定的,比如以太网卡、无线网卡或者PPP/PPPoE拨号网络的虚拟网卡,想要正常工作都要绑定一个地址,否则其他设备就不知道如何访问它。
 
 

localhost
首先 localhost 是一个域名,在过去它指向 127.0.0.1 这个IP地址。在操作系统支持 ipv6 后,它同时还指向ipv6 的地址 [::1] 
在 Windows 中,这个域名是预定义的,从 hosts 文件中可以看出:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
 
而在 Linux 中,其定义位于 /etc/hosts 中:
127.0.0.1 localhost
 
注意这个值是可修改的,比如把它改成
192.068.206.1 localhost
 
然后再去 ping localhost,提示就变成了
PING localhost (192.168.206.1) 56(84) bytes of data.
 
127.0.0.1
127.0.0.1 这个地址通常分配给 loopback 接口。loopback 是一个特殊的网络接口(可理解成虚拟网卡),用于本机中各个应用之间的网络交互。只要操作系统的网络组件是正常的,loopback 就能工作。Windows 中看不到这个接口,Linux中这个接口叫 lo:
#ifconfig
eth0 Link encap:Ethernet hwaddr 00:00:00:00:00:00
  inet addr :192.168.0.1 Bcase:192.168.0.255 Mask:255.255.255.0
  ......
lo     Link encap:Local Loopback
  inetaddr: 127.0.0.1 Mask: 255.0.0.0
       ......
 
可以看出 lo 接口的地址是 127.0.0.1。事实上整个 127.* 网段都算能够使用,比如你 ping 127.0.0.2 也是通的。 
但是使用127.0.0.1作为loopback接口的默认地址只是一个惯例,比如下面这样:
#ifconfig lo 192.168.128.1
#ping localhost  #糟糕,ping不通了
#ping 192.128.128.1 # 可以通
#ifconfig lo
lo  Link encap:Local Loopback
  inetaddr: 192.168.128.1 Mask: 255.255.255.0
     ......
 
如果随便改这些配置,可能导致很多只认 127.0.0.1 的软件挂掉。
 
本机IP
确切地说,“本机地址”并不是一个规范的名词。通常情况下,指的是“本机物理网卡所绑定的网络协议地址”。由于目前常用网络协议只剩下了IPV4,IPX/Apple Tak消失了,IPV6还没普及,所以通常仅指IP地址甚至ipv4地址。一般情况下,并不会把 127.0.0.1当作本机地址——因为没必要特别说明,大家都知道。 
本机地址是与具体的网络接口绑定的。比如以太网卡、无线网卡或者PPP/PPPoE拨号网络的虚拟网卡,想要正常工作都要绑定一个地址,否则其他设备就不知道如何访问它。
● localhost 是个域名,不是地址,它可以被配置为任意的 IP 地址,不过通常情况下都指向 127.0.0.1(ipv4)和 ::1 
● 整个127.* 网段通常被用作 loopback 网络接口的默认地址,按惯例通常设置为 127.0.0.1。这个地址在其他计算机上不能访问,就算你想访问,访问的也是自己,因为每台带有TCP/IP协议栈的设备基本上都有 localhost/127.0.0.1。 
● 本机地址通常指的是绑定在物理或虚拟网络接口上的IP地址,可供其他设备访问到。 
● 最后,从开发度来看 
○ localhost是个域名,性质跟 “www.baidu.com” 差不多。不能直接绑定套接字,必须先gethostbyname转成IP才能绑定。 
○ 127.0.0.1 是绑定在 loopback 接口上的地址,如果服务端套接字绑定在它上面,你的客户端程序就只能在本机访问

原文链接:https://www.cnblogs.com/absoluteli/p/13958072.html
收起阅读 »

Android 使用 Span 打造丰富多彩的文本

1.引言 在开发过程中经常需要使用文本,有时候需要对一段文字中的部分文字进行特殊的处理,如改变其中部分文字的大小、颜色、加下划线等,这个时候使用Span就能方便地解决这些问题。本文将主要介绍SpannableStringBuilder和各种Span的使用。 2...
继续阅读 »

1.引言


在开发过程中经常需要使用文本,有时候需要对一段文字中的部分文字进行特殊的处理,如改变其中部分文字的大小、颜色、加下划线等,这个时候使用Span就能方便地解决这些问题。本文将主要介绍SpannableStringBuilder和各种Span的使用。


2.SpannableStringBuilder的基本用法


新建一个SpannableStringBuilder对象的操作如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");

SpannableStringBuilder的setSpan()方法如下:


//what:各种文本Span,如BackgroundColorSpan、ForegroundColorSpan等
//start:应用Span的文本的开始位置索引
//end:应用Span的文本的结束位置索引
//flags:标志
public void setSpan(Object what, int start, int end, int flags) {
setSpan(true, what, start, end, flags, true/*enforceParagraph*/);
}

3.使用Span给文本添加效果


3.1 AbsoluteSizeSpan

此Span用来改变文本的绝对大小,示例如下:


 SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new AbsoluteSizeSpan(60),3,9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.2 BackgroundColorSpan

此Span用来改变文本的背景颜色大小,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new BackgroundColorSpan(Color.GREEN),3,9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.3 ClickableSpan

此Span用来给文本添加点击效果,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new ClickableSpan() {
@Override
public void onClick(@NonNull View widget) {
Toast.makeText(MainActivity.this,"ClickableSpan",Toast.LENGTH_SHORT).show();
}
}, 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);
tv_content.setMovementMethod(LinkMovementMethod.getInstance());
tv_content.setHighlightColor(Color.TRANSPARENT);

3.4 DrawableMarginSpan

此Span用来给段落添加drawable和padding,这个padding指的是drawable和文本之间的距离,默认值是0,Span要从文本的起始位置设置,否则Span将不会渲染或者错误地渲染,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
Drawable drawable = AppCompatResources.getDrawable(MainActivity.this,R.drawable.ic_launcher);
builder.setSpan(new DrawableMarginSpan(drawable,30), 0, builder.length(), Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.5 DynamicDrawableSpan

此Span使用drawable替换文本内容,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new DynamicDrawableSpan() {
@Override
public Drawable getDrawable() {
Drawable drawable =
AppCompatResources.getDrawable(MainActivity.this,R.drawable.ic_launcher);
drawable.setBounds(0,0,drawable.getIntrinsicWidth(),drawable.getIntrinsicHeight());
return drawable;
}
}, 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.6 ForegroundColorSpan

此Span可以用来改变文本的颜色,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new ForegroundColorSpan(Color.GREEN), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.7 IconMarginSpan

此Span可以在文本开始的地方添加位图,而且可以在位图和文本之间设置padding,padding的默认值是0px,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.ic_launcher);
builder.setSpan(new IconMarginSpan(bitmap,30), 0, builder.length(), Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.8 ImageSpan

此Span可以使用Drawable替换文本,创建ImageSpan的构造方法有很多,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new ImageSpan(MainActivity.this,R.drawable.ic_launcher), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.9 MaskFilterSpan

此Span可以给文本设置MaskFilter,例如给文本设置模糊效果,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
MaskFilter maskFilter = new BlurMaskFilter(10f, BlurMaskFilter.Blur.NORMAL);
builder.setSpan(new MaskFilterSpan(maskFilter), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.10 QuoteSpan

此Span可以在文本开始的地方添加一个垂直的线条,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new QuoteSpan(Color.GREEN), 0, builder.length(), Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.11 RelativeSizeSpan

此Span可以按一定的比例缩放文本的大小,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new RelativeSizeSpan(2.0f), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.12 ScaleXSpan

此Span以一定的系数在水平方向缩放文本的大小,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new ScaleXSpan(2.5f), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.13 StrikethroughSpan

此Span可以在文本上添加下划线,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new StrikethroughSpan(), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.14 StyleSpan

此Span可以设置文本的样式,可用的样式有Typeface.NORMAL、Typeface.BOLD、Typeface.ITALIC、Typeface.BOLD_ITALIC,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new StyleSpan(Typeface.BOLD), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.15 SubscriptSpan

此Span可以将文本的基线移动到更低的地方,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new SubscriptSpan(), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.16 SuperscriptSpan

此Span可以将文本的基线移动到更高的地方,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new SuperscriptSpan(), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

3.17 UnderlineSpan()

此Span可以在文本下面添加下划线,示例如下:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new UnderlineSpan(), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

4.多个Span组合使用


Span不但可以单独使用,还可以组合在一起使用,以下示例演示了如何同时加粗文字,改变文字的颜色和添加下滑线:


SpannableStringBuilder builder = new SpannableStringBuilder("Hello World!");
builder.setSpan(new UnderlineSpan(), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
builder.setSpan(new ForegroundColorSpan(Color.GREEN), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
builder.setSpan(new StyleSpan(Typeface.BOLD), 3, 9, Spannable.SPAN_EXCLUSIVE_INCLUSIVE);
tv_content.setText(builder);

5.总结


Span的功能相当丰富,如改变文本颜色、大小、添加点击效果、加下划线等功能,本文介绍了经常用到的各种Span,Span支持单独使用和组合使用,使用它能够对文本进行各种灵活的操作,去实现个性化的需求。


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

看完这篇Broadcast你还不会,来找我

看完这篇文章,你将明白以下内容: broadcast是什么,使用场景 Android中广播的分类 广播的注册方式 本地广播优点、原理 广播的安全 1.1 什么是 BroadcastReceiver 是四大组件之一, 主要用于接收 app 发送的广播 内部...
继续阅读 »

看完这篇文章,你将明白以下内容:



  • broadcast是什么,使用场景

  • Android中广播的分类

  • 广播的注册方式

  • 本地广播优点、原理

  • 广播的安全


1.1 什么是 BroadcastReceiver



  • 是四大组件之一, 主要用于接收 app 发送的广播

  • 内部通信实现机制:通过 android 系统的 Binder 机制.


1.2 广播分类


1.2.1 无序广播



  • 也叫标准广播,是一种完全异步


执行的广播。



  • 在广播发出之后,所有广播接收器几乎都会在同一时刻接收到这条广播消息,它们之间没有任何先后顺序,广播的效率较高。

  • 优点: 完全异步, 逻辑上可被任何接受者收到广播,效率高

  • 缺点: 接受者不能将处理结果交给下一个接受者, 且无法终止广播.


1.2.2 有序广播




  • 是一种同步执行的广播。




  • 在广播发出之后,同一时刻只有一个广播接收器能够收到这条广播消息,当其逻辑执行完后该广播接收器才会继续传递。




  • 调用 SendOrderedBroadcast() 方法来发送广播,同时也可调用 abortBroadcast() 方法拦截该广播。可通过 <intent-filter> 标签中设置 android:property 属性来设置优先级,未设置时按照注册的顺序接收广播。




  • 有序广播接受器间可以互传数据。




  • 当广播接收器收到广播后,当前广播也可以使用 setResultData 方法将数据传给下一个接收器。




  • 使用 getStringExtra 函数获取广播的原始数据,通过 getResultData 方法取得上个广播接收器自己添加的数据,并可用 abortBroadcast 方法丢弃该广播,使该广播不再被别的接收器接收到。




  • 总结





  1. 按被接收者的优先级循序传播 A > B > C ,

  2. 每个都有权终止广播, 下一个就得不到

  3. 每一个都可进行修改操作, 下一个就得到上一个修改后的结果.


1.2.3 最终广播者



  • Context.sendOrderedBroadcast ( intent , receiverPermission , resultReceiver , scheduler , initialCode , initialData , initialExtras ) 时我们可以指定 resultReceiver 为最终广播接收者.

  • 如果比他优先级高的接受者不终止广播, 那么他的 onReceive 会执行两次

  • 第一次是正常的接收

  • 第二次是最终的接收

  • 如果优先级高的那个终止广播, 那么他还是会收到一次最终的广播


1.2.4 常见的广播接收者运用场景



  • 开机启动, sd 卡挂载, 低电量, 外拨电话, 锁屏等

  • 比如根据产品经理要求, 设计播放音乐时, 锁屏是否决定暂停音乐.


1.3 BroadcastReceiver 的种类


1.3.1 广播作为 Android 组件间的通信方式,如下使用场景:



对前一部分 “ 请描述一下 BroadcastReceiver ” 进行展开补充




  • APP 内部的消息通信。

  • 不同 APP 之间的消息通信。

  • Android 系统在特定情况下与 APP 之间的消息通信。

  • 广播使用了观察者模式,基于消息的发布 / 订阅事件模型。广播将广播的发送者和接受者极大程度上解耦,使得系统能够方便集成,更易扩展。

  • BroadcastReceiver 本质是一个全局监听器,用于监听系统全局的广播消息,方便实现系统中不同组件间的通信。

  • 自定义广播接收器需要继承基类 BroadcastReceiver ,并实现抽象方法 onReceive ( context, intent ) 。默认情况下,广播接收器也是运行在主线程,因此 onReceiver() 中不能执行太耗时的操作( 不超过 10s ),否则将会产生 ANR 问题。onReceiver() 方法中涉及与其他组件之间的交互时,可以使用发送 Notification 、启动 Service 等方式,最好不要启动 Activity


1.3.2 系统广播



  • Android 系统内置了多个系统广播,只要涉及手机的基本操作,基本上都会发出相应的系统广播,如开机启动、网络状态改变、拍照、屏幕关闭与开启、电量不足等。在系统内部当特定时间发生时,系统广播由系统自动发出。

  • 常见系统广播 Intent 中的 Action 为如下值:



  1. 短信提醒:android.provider.Telephony.SMS_RECEIVED

  2. 电量过低:ACTION_BATIERY_LOW

  3. 电量发生改变:ACTION_BATTERY_CHANGED

  4. 连接电源:ACTION_POWER_CO             



  • Android 7.0 开始,系统不会再发送广播 ACTION_NEW_PICTUREACTION_NEW_VIDEO ,对于广播 CONNECTIVITY_ACTION 必须在代码中使用 registerReceiver 方法注册接收器,在 AndroidManifest 文件中声明接收器不起作用。

  • Android 8.0 开始,对于大多数隐式广播,不能在 AndroidManifest 文件中声明接收器。


1.3.3 局部广播



  • 局部广播的发送者和接受者都同属于一个 APP

  • 相比于全局广播具有以下优点:



  1. 其他的 APP 不会受到局部广播,不用担心数据泄露的问题。

  2. 其他 APP 不可能向当前的 APP 发送局部广播,不用担心有安全漏洞被其他 APP 利用。

  3. 局部广播比通过系统传递的全局广播的传递效率更高。



  • Android v4 包中提供了 LocalBroadcastManager 类,用于统一处理 APP 局部广播,使用方式与全局广播几乎相同,只是调用注册 / 取消注册广播接收器和发送广播偶读方法时,需要通过 LocalBroadcastManager 类的 getInstance() 方法获取的实例调用。


1.4 BroadcastReceiver 注册方式


1.4.1 静态注册


AndroidManifest.xml 文件中配置。


<receiver android:name=".MyReceiver" android:exported="true">
<intent-filter>
<!-- 指定该 BroadcastReceiver 所响应的 Intent 的 Action -->
<action android:name="android.intent.action.INPUT_METHOD_CHANGED"
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>


  • 两个重要属性需要关注:



  1. android: exported 其作用是设置此 BroadcastReceiver 能否接受其他 APP 发出的广播 ,当设为 false 时,只能接受同一应用的的组件或具有相同 user ID 的应用发送的消息。这个属性的默认值是由 BroadcastReceiver 中有无 Intent-filter 决定的,如果有 Intent-filter ,默认值为 true ,否则为 false

  2. android: permission 如果设置此属性,具有相应权限的广播发送方发送的广播才能被此 BroadcastReceiver 所接受;如果没有设置,这个值赋予整个应用所申请的权限。


1.4.2 动态注册



  • 调用 ContextregisterReceiver ( BroadcastReceiver receiver , IntentFilter filter ) 方法指定。


1.5 在 Mainfest 和代码如何注册和使用 BroadcastReceiver ? ( 一个 action 是重点 )


1.5.1 使用文件注册 ( 静态广播 )




  • 只要 app 还在运行,那么会一直收到广播消息




  • 演示:





  1. 一个 app 里: 自定义一个类继承 BroadcastReceiver 然后要求重写 onReveiver 方法


public class MyBroadCastReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
Log.d("MyBroadCastReceiver", "收到信息,内容是 :&emsp;" + intent.getStringExtra("info") + "");
}
}


  1. 清单文件注册,并设置 Action , 就那么简单完成接收准备工作


<receiver android:name=".MyBroadCastReceiver">
<intent-filter>
<action android:name="myBroadcast.action.call"/>
</intent-filter>
</receiver>

1.5.2 代码注册 ( 动态广播 )




  • 当注册的 Activity 或者 Service 销毁了那么就会接收不到广播.




  • 演示:





  1. 在和广播接受者相同的 app 里的 MainActivity 添加一个注册按钮 , 用来注册广播接收者

  2. 设置意图过滤,添加 Action


//onCreate创建广播接收者对象
mReceiver = new MyBroadCastReceiver();

//注册按钮
public void click(View view) {
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction("myBroadcast.action.call");
registerReceiver(mReceiver, intentFilter);
}


  1. 销毁的时候取消注册


@Override
protected void onDestroy() {
unregisterReceiver(mReceiver);
super.onDestroy();
}

1.5.3 在另一个 app , 定义一个按钮, 设置意图, 意图添加消息内容, 意图设置 action( ... ) 要匹配 , 然后发送广播即可.


public void click(View view) {
Intent intent = new Intent();
intent.putExtra("info", "消息内容");
intent.setAction("myBroadcast.action.call");
sendBroadcast(intent);
}


  • 运行两个 app 之后:



  1. 静态注册的方法: 另一 app 直接发广播就收到了

  2. 动态注册的方法: 自己的 app 先代码注册,然后另一个 app 直接发广播即可.


1.6 BroadcastReceiver 的实现原理是什么?




  • Android 中的广播使用了设计模式中的观察者模式:基于消息的发布 / 订阅事件模型。




  • 模型中主要有 3 个角色:





  1. 消息订阅者( 广播接收者 )

  2. 消息发布者( 广播发布者 )

  3. 消息中心( AMS,即 Activity Manager Service


1.6.1 原理:



  • 广播接收者通过 Binder 机制在 AMSActivity Manager Service ) 注册;

  • 广播发送者通过 Binder 机制向 AMS 发送广播;

  • AMS 根据广播发送者要求,在已注册列表中,寻找合适的 BroadcastReceiver ( 寻找依据:IntentFilter / Permission );

  • AMS 将广播发送到 BroadcastReceiver 相应的消息循环队列中;

  • 广播接收者通过消息循环拿到此广播,并回调 onReceive() 方法。

  • 需要注意的是:广播的发送和接受是异步的,发送者不会关心有无接收者或者何时收到。


1.7 本地广播



  • 本地广播机制使得发出的广播只能够在应用程序的内部进行传递,并且广播接收器也只能接受来自本应用程序发出的广播,则安全性得到了提高。

  • 本地广播主要是使用了一个 LocalBroadcastManager 来对广播进行管理,并提供了发送广播和注册广播接收器的方法。

  • 开发者只要实现自己的 BroadcastReceiver 子类,并重写 onReceive ( Context context, Intetn intent ) 方法即可。

  • 当其他组件通过 sendBroadcast()sendStickyBroadcast()sendOrderBroadcast() 方法发送广播消息时,如果该 BroadcastReceiver 也对该消息“感兴趣”,BroadcastReceiveronReceive ( Context context, Intetn intent ) 方法将会被触发。

  • 使用步骤:



  1. 调用 LocalBroadcastManager.getInstance() 获得实例

  2. 调用 registerReceiver() 方法注册广播

  3. 调用 sendBroadcast() 方法发送广播

  4. 调用 unregisterReceiver() 方法取消注册


1.7.1 注意事项:



  1. 本地广播无法通过静态注册方式来接受,相比起系统全局广播更加高效。

  2. 在广播中启动 Activity 时,需要为 Intent 加入 FLAG_ACTIVITY_NEW_TASK 标记,否则会报错,因为需要一个栈来存放新打开的 Activity

  3. 广播中弹出 Alertdialog 时,需要设置对话框的类型为 TYPE_SYSTEM_ALERT ,否则无法弹出。

  4. 不要在 onReceiver() 方法中添加过多的逻辑或者进行任何的耗时操作,因为在广播接收器中是不允许开启线程的,当 onReceiver() 方法运行了较长时间而没有结束时,程序就会报错。


1.8 Sticky Broadcast 粘性广播



  • 如果发送者发送了某个广播,而接收者在这个广播发送后才注册自己的 Receiver ,这时接收者便无法接收到刚才的广播

  • 为此 Android 引入了 StickyBroadcast ,在广播发送结束后会保存刚刚发送的广播( Intent ),这样当接收者注册完 Receiver 后就可以继续使用刚才的广播。

  • 如果在接收者注册完成前发送了多条相同 Action 的粘性广播,注册完成后只会收到一条该 Action 的广播,并且消息内容是最后一次广播内容。

  • 系统网络状态的改变发送的广播就是粘性广播。



  1. 粘性广播通过 ContextsendStickyBroadcast ( Intent ) 接口发送,需要添加权限

  2. uses-permission android:name=”android.permission.BROADCAST_STICKY”

  3. 也可以通过 ContextremoveStickyBroadcast ( Intent intent ) 接口移除缓存的粘性广播


1.9 LocalBroadcastManager 详解


1.9.1 特点:



  1. 使用它发送的广播将只在自身APP内传播,因此你不必担心泄漏隐私数据;

  2. 其他 APP 无法对你的 APP 发送该广播,因为你的APP根本就不可能接收到非自身应用发送的该广播,因此你不必担心有安全漏洞可以利用;

  3. 比系统的全局广播更加高效。


1.9.2 源码分析 :



  1. LocalBroadcastManager 内部协作主要是靠这两个 Map 集合:MReceiversMActions ,当然还有一个 List 集合 MPendingBroadcasts ,这个主要就是存储待接收的广播对象。

  2. LocalBroadcastManager 高效的原因主要是因为它内部是通过 Handler 实现的,它的 sendBroadcast() 方法含义并非和我们平时所用的一样,它的 sendBroadcast() 方法其实是通过 handler 发送一个 Message 实现的;

  3. 既然它内部是通过 Handler 来实现广播的发送的,那么相比于系统广播通过 Binder 实现那肯定是更高效了,同时使用 Handler 来实现,别的应用无法向我们的应用发送该广播,而我们应用内发送的广播也不会离开我们的应用;


1.9.3 BroadcastReceiver 安全问题



  • BroadcastReceiver 设计的初衷是从全局考虑可以方便应用程序和系统、应用程序之间、应用程序内的通信,所以对单个应用程序而言BroadcastReceiver 是存在安全性问题的 ( 恶意程序脚本不断的去发送你所接收的广播 ) 。为了解决这个问题 LocalBroadcastManager 就应运而生了。

  • LocalBroadcastManagerAndroid Support 包提供了一个工具,用于在同一个应用内的不同组件间发送 BroadcastLocalBroadcastManager 也称为局部通知管理器,这种通知的好处是安全性高,效率也高,适合局部通信,可以用来代替 Handler 更新 UI


1.9.4 广播的安全性



  • Android 系统中的广播可以跨进程直接通信,会产生以下两个问题:



  1. 其他 APP 可以接收到当前 APP 发送的广播,导致数据外泄。

  2. 其他 APP 可以向当前 APP 放广播消息,导致 APP 被非法控制。



  • 发送广播



  1. 发送广播时,增加相应的 permission ,用于权限验证。

  2. Android 4.0 及以上系统中发送广播时,可以使用 setPackage() 方法设置接受广播的包名。

  3. 使用局部广播。



  • 接受广播



  1. 注册广播接收器时,增加相应的 permission ,用于权限验证。

  2. 注册广播接收器时,设置 android:exported 的值为false。



  • 使用局部广播



  1. 发送广播时,如果增加了 permission

  2. 那接受广播的 APP 必须申请相应权限,这样才能收到对应的广播,反之亦然。


1.9.5 使用 BroadcastReceiver 的好处



  1. 因广播数据在本应用范围内传播,你不用担心隐私数据泄露的问题。

  2. 不用担心别的应用伪造广播,造成安全隐患。

  3. 相比在系统内发送全局广播,它更高效。


1.10 如何让自己的广播只让指定的 app 接收?



  • 在发送广播的 app 端,自定义定义权限, 那么想要接收的另外 app 端必须声明权限才能收到.



  1. 权限, 保护层级是普通正常.

  2. 用户权限


<permission android:name="broad.ok.receiver" android:protectionLevel="normal"/>
<uses-permission android:name="broad.ok.receiver" />


  1. 发送广播的时候加上权限字符串


public void click(View view) {
Intent intent = new Intent();
intent.putExtra("info", "消息内容");
intent.setAction("myBroadcast.action.call");
sendBroadcast(intent, "broad.ok.receiver");
//sendOrderedBroadcast(intent,"broad.ok.receiver");
}


  1. 其他app接收者想好获取广播,必须声明在清单文件权限


<uses-permission android:name="broad.ok.receiver"/>

1.11 广播的优先级对无序广播生效吗?



  • 优先级对无序也生效.


1.12 动态注册的广播优先级谁高?



  • 谁先注册,谁就高


1.13 如何判断当前的 BrodcastReceiver 接收到的是有序还是无序的广播?



  • onReceiver 方法里,直接调用判断方法得返回值


public void onReceive(Context context, Intent intent) {
Log.d("MyBroadCastReceiver", "收到信息,内容是 :&emsp;" + intent.getStringExtra("info") + "");
boolean isOrderBroadcast = isOrderedBroadcast();
}

1.14 BroadcastReceiver 不能执行耗时操作



  • 一方面



  1. BroadcastReceiver 一般处于主线程。

  2. 耗时操作会导致 ANR



  • 另一方面



  1. BroadcastReceiver 启动时间较短。

  2. 如果一个进程里面只存在一个 BroadcastReceiver 组件。并且在其中开启子线程执行耗时任务。

  3. 系统会认为该进程是优先级最低的空进程。很容易将其杀死。


总结






  1. 本文对 BroadcastReceiverContentProvider 的 知识进行了详尽的总结,如果有可以补充的知识点,欢迎大家在评论区指出。




  2. 希望大家通过本次阅读都能有所收获。


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

让 Flutter 在鸿蒙系统上跑起来

前言 鸿蒙系统 (HarmonyOS)是华为推出的一款面向未来、面向全场景的分布式操作系统。在传统单设备系统能力的基础上,鸿蒙提出了基于同一套系统能力、适配多种终端形态的分布式理念。自 2020 年 9 月 HarmonyOS 2.0 发布以来,华为加快了鸿蒙...
继续阅读 »

前言


鸿蒙系统 (HarmonyOS)是华为推出的一款面向未来、面向全场景的分布式操作系统。在传统单设备系统能力的基础上,鸿蒙提出了基于同一套系统能力、适配多种终端形态的分布式理念。自 2020 年 9 月 HarmonyOS 2.0 发布以来,华为加快了鸿蒙系统大规模落地的步伐,预计 2021 年底,鸿蒙系统会覆盖包括手机、平板、智能穿戴、智慧屏、车机在内数亿台终端设备。对移动应用而言,新的系统理念、新的交互形式,也意味着新的机遇。如果能够利用好鸿蒙的开发生态及其特性能力,可以让应用覆盖更多的交互场景和设备类型,从而带来新的增长点。


与面临的机遇相比,适配鸿蒙系统带来的挑战同样巨大。当前手机端,尽管鸿蒙系统仍然支持安卓 APK 安装及运行,但长期来看,华为势必会抛弃 AOSP,逐步发展出自己的生态,这意味着现有安卓应用在鸿蒙设备上将会逐渐变成“二等公民”。然而,如果在 iOS 及 Android 之外再重新开发和维护一套鸿蒙应用,在如今业界越来越注重开发迭代效率的环境下,所带来的开发成本也是难以估量的。因此,通过打造一套合适的跨端框架,以相对低的成本移植应用到鸿蒙平台,并利用好该系统的特性能力,就成为了一个非常重要的选项。


在现有的众多跨端框架当中,Flutter 以其自渲染能力带来的多端高度一致性,在新系统的适配上有着突出的优势。虽然Flutter 官方并没有适配鸿蒙的计划,但经过一段时间的探索和实践,美团外卖 MTFlutter 团队成功实现了 Flutter 对于鸿蒙系统的原生支持。


这里也要提前说明一下,因为鸿蒙系统目前还处于Beta版本,所以这套适配方案还没有在实际业务中上线,属于技术层面比较前期的探索。接下来本文会通过原理和部分实现细节的介绍,分享我们在移植和开发过程中的一些经验。希望能对大家有所启发或者帮助。


背景知识和基础概念介绍


在适配开始之前,我们要明确好先做哪些事情。先来回顾一下 Flutter 的三层结构:



在 Flutter 的架构设计中,最上层为框架层,使用 Dart 语言开发,面向 Flutter 业务的开发者;中间层为引擎层,使用 C/C++ 开发,实现了 Flutter 的渲染管线和 Dart 运行时等基础能力;最下层为嵌入层,负责与平台相关的能力实现。显然我们要做的是将嵌入层移植到鸿蒙上,确切地说,我们要通过鸿蒙原生提供的平台能力,重新实现一遍 Flutter 嵌入层


对于 Flutter 嵌入层的适配,Flutter 官方有一份不算详细的指南,实际操作起来成本很高。由于鸿蒙的业务开发语言仍然可用 Java,在很多基础概念上与 Android 也有相似之处(如下表所示),我们可以从 Android 的实现入手,完成对鸿蒙的移植。



Flutter 在鸿蒙上的适配


如前文所述,要完成 Flutter 在新系统上的移植,我们需要完整实现 Flutter 嵌入层要求的所有子模块,而从能力支持角度,渲染交互以及其他必要的原生平台能力是保证 Flutter 应用能够运行起来的最基本的要素,需要优先支持。接下来会依次进行介绍。


1. 渲染流程打通


我们再来回顾一下 Flutter 的图像渲染流程。如图所示,设备发起垂直同步(VSync)信号之后,先经过 UI 线程的渲染管线(Animate/Build/Layout/Paint),再经过 Raster 线程的组合和栅格化,最终通过 OpenGL 或 Vulkan 将图像上屏。这个流程的大部分工作都由框架层和引擎层完成,对于鸿蒙的适配,我们主要关注的是与设备自身能力相关的问题,即:


(1) 如何监听设备的 VSync 信号并通知 Flutter 引擎?
(2) OpenGL/Vulkan 用于上屏的窗口对象从何而来?



VSync 信号的监听及传递


在 Flutter 引擎的 Android 实现中,设备的 VSync 信号通过 Choreographer 触发,它产生及消费流程如下图所示:


Flutter VSync


Flutter 框架注册 VSync 回调之后,通过 C++ 侧的 VsyncWaiter 类等待 VSync 信号,后者通过 JNI 等一系列调用,最终 Java 侧的 VsyncWaiter 类调用 Android SDK 的 Choreographer.postFrameCallback 方法,再通过 JNI 一层层传回 Flutter 引擎消费掉此回调。Java 侧的 VsyncWaiter 核心代码如下:


@Override
public void asyncWaitForVsync(long cookie) {
Choreographer.getInstance()
.postFrameCallback(
new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
float fps = windowManager.getDefaultDisplay().getRefreshRate();
long refreshPeriodNanos = (long) (1000000000.0 / fps);
FlutterJNI.nativeOnVsync(
frameTimeNanos, frameTimeNanos + refreshPeriodNanos, cookie);
}
});
}

在整个流程中,除了来自 Android SDK 的 Choreographer 以外,大多数逻辑几乎都由 C++ 和 Java 的基础 SDK 实现,可以直接在鸿蒙上复用,问题是鸿蒙目前的 API 文档中尚没有开放类似 Choreographer 的能力。所以现阶段我们可以借用鸿蒙提供的类似 iOS Grand Central Dispatch 的线程 API,模拟出 VSync 的信号触发与回调:


@Override
public void asyncWaitForVsync(long cookie) {
// 模拟每秒 60 帧的屏幕刷新间隔:向主线程发送一个异步任务, 16ms 后调用
applicationContext.getUITaskDispatcher().delayDispatch(() -> {
float fps = 60; // 设备刷新帧率,HarmonyOS 未暴露获取帧率 API,先写死 60 帧
long refreshPeriodNanos = (long) (1000000000.0 / fps);
long frameTimeNanos = System.nanoTime();
FlutterJNI.nativeOnVsync(frameTimeNanos, frameTimeNanos + refreshPeriodNanos, cookie);
}, 16);
};

渲染窗口的构建及传递


在这一部分,我们需要在鸿蒙系统上构建平台容器,为 Flutter 引擎的图形渲染提供用于上屏的窗口对象。同样,我们参考 Flutter for Android 的实现,看一下 Android 系统是怎么做的:



Flutter 在 Android 上支持 Vulkan 和 OpenGL 两种渲染引擎,篇幅原因我们只关注 OpenGL。抛开复杂的注册及调用细节,本质上整个流程主要做了三件事:



  1. 创建了一个视图对象,提供可用于直接绘制的 Surface,将它通过 JNI 传递给原生侧;

  2. 在原生侧获取 Surface 关联的本地窗口对象,并交给 Flutter 的平台容器;

  3. 将本地窗口对象转换为 OpenGL ES 可识别的绘图表面(EGLSurface),用于 Flutter 引擎的渲染上屏。


接下来我们用鸿蒙提供的平台能力实现这三点。


a. 可用于直接绘制的视图对象


鸿蒙系统的 UI 框架提供了很多常用视图组件(Component),比如按钮、文字、图片、列表等,但我们需要抛开这些上层组件,获得直接绘制的能力。借助官方 媒体播放器开发指导 文档,可以发现鸿蒙提供了 SurfaceProvider 类,它管理的 Surface 对象可以用于视频解码后的展示。而 Flutter 渲染与视频上屏从原理上是类似的,因此我们可以借用 SurfaceProvider 实现 Surface 的管理和创建:


// 创建一个用于管理 Surface 的容器组件
SurfaceProvider surfaceProvider = new SurfaceProvider(context);
// 注册视图创建回调
surfaceProvider.getSurfaceOps().get().addCallback(surfaceCallback);

// ... 在 surfaceCallback 中
@Override
public void surfaceCreated(SurfaceOps surfaceOps) {
Surface surface = surfaceOps.getSurface();
// ...将 surface 通过 JNI 交给 Native 侧
FlutterJNI.onSurfaceCreated(surface);
}

b. 与 Surface 关联的本地窗口对象


鸿蒙目前开放的 Native API 并不多,在官方文档中我们可以比较容易地找到 Native_layer API。根据文档的说明,Native API 中的 NativeLayer 对象刚好对应了 Java 侧的 Surface 类,借助 GetNativeLayer 方法,我们实现了两者之间的转化:


// platform_view_android_jni_impl.cc
static void SurfaceCreated(JNIEnv* env, jobject jcaller, jlong shell_holder, jobject jsurface) {
fml::jni::ScopedJavaLocalFrame scoped_local_reference_frame(env);
// 通过鸿蒙 Native API 获取本地窗口对象 NativeLayer
auto window = fml::MakeRefCounted(
GetNativeLayer(env, jsurface));
ANDROID_SHELL_HOLDER->GetPlatformView()->NotifyCreated(std::move(window));
}

c. 与本地窗口对象关联的 EGLSurface


在 Android 的 AOSP 实现中,EGLSurface 可通过 EGL 库的 eglCreateWindowSurface 方法从本地窗口对象 ANativeWindow 创建而来。对于鸿蒙而言,虽然我们没有从公开文档找到类似的说明,但是 鸿蒙标准库 默认支持了 OpenGL ES,而且鸿蒙 SDK 中也附带了 EGL 相关的库及头文件,我们有理由相信在鸿蒙系统上,EGLSurface 也可以通过此方法从前一步生成的 NativeLayer 转化而来,在之后的验证中我们也确认了这一点:


// window->handle() 即为之前得到的 NativeLayer
EGLSurface surface = eglCreateWindowSurface(
display, config_, reinterpret_cast(window->handle()),
attribs);
//...交给 Flutter 渲染管线

2. 交互能力实现


交互能力是支撑 Flutter 应用能够正常运行的另一个基本要求。在 Flutter 中,交互包含了各种触摸事件、鼠标事件、键盘录入事件的传递及消费。以触摸事件为例,Flutter 事件传递的整个流程如下图所示:


Flutter 事件分发


iOS/Android 的原生容器通过触摸事件的回调 API 接收到事件之后,会将其打包传递至引擎层,后者将事件传发给 Flutter 框架层,并完成事件的消费、分发和逻辑处理。同样,整个流程的大部分工作已经由 Flutter 统一,我们要做的仅仅是在原生容器上监听用户的输入,并封装成指定格式交给引擎层而已。


在鸿蒙系统上,我们可以借助平台提供的 多模输入 API,实现多种类型事件的监听:


flutterComponent.setTouchEventListener(touchEventListener); // 触摸及鼠标事件
flutterComponent.setKeyEventListener(keyEventListener); // 键盘录入事件
flutterComponent.setSpeechEventListener(speechEventListener); // 语音录入事件

对于事件的封装处理,可以复用 Android 已有逻辑,只需要关注鸿蒙与 Android 在事件处理上的对应关系即可,比如触摸事件的部分对应关系:



3. 其他必要的平台能力


为了保证 Flutter 应用能够正常运行,除了最基本的渲染和交互外,我们的嵌入层还要提供资源管理、事件循环、生命周期同步等平台能力。对于这些能力 Flutter 大多都在嵌入层的公共部分有抽象类声明,只需要使用鸿蒙 API 重新实现一遍即可。


比如资源管理,引擎提供了 AssetResolver 声明,我们可以使用鸿蒙 Rawfile API 来实现:


class HAPAssetMapping : public fml::Mapping {
public:
HAPAssetMapping(RawFile* asset) : asset_(asset) {}
~HAPAssetMapping() override { CloseRawFile(asset_); }

size_t GetSize() const override { return GetRawFileSize(asset_); }

const uint8_t* GetMapping() const override {
return reinterpret_cast(GetRawFileBuffer(asset_));
}

private:
RawFile* const asset_;

FML_DISALLOW_COPY_AND_ASSIGN(HAPAssetMapping);
};

对于事件循环,引擎提供了 MessageLoopImpl 抽象类,我们可以使用鸿蒙 Native_EventHandler API 实现:


// runner_ 为鸿蒙 EventRunnerNativeImplement 的实例
void MessageLoopHarmony::Run() {
FML_DCHECK(runner_ == GetEventRunnerNativeObjForThread());
int result = ::EventRunnerRun(runner_);
FML_DCHECK(result == 0);
}

void MessageLoopHarmony::Terminate() {
int result = ::EventRunnerStop(runner_);
FML_DCHECK(result == 0);
}

对于生命周期的同步,鸿蒙的 Page Ability 提供了完整的生命周期回调(如下图所示),我们只需要在对应的时机将状态上报给引擎即可。


Page Ability Lifecycle


当以上这些能力都准备好之后,我们就可以成功把 Flutter 应用跑起来了。以下是通过 DevEco Studio 运行官方 flutter gallery 应用的截图,截图中 Flutter 引擎已经使用鸿蒙系统的平台能力进行了重写:


DevEco Running Flutte


借由鸿蒙的多设备支持能力,此应用甚至可在 TV、车机、手表、平板等设备上运行:


Flutter Multiple Devices


总结和展望


通过上述的构建和适配工作,我们以极小的开发成本实现了 Flutter 在鸿蒙系统上的移植,基于 Flutter 开发的上层业务几乎不做任何修改就可以在鸿蒙系统上原生运行,为迎接鸿蒙系统后续的大规模推广也提前做好了技术储备。


当然,故事到这里并没有结束。在最基本的运行和交互能力之上,我们更需要关注 Flutter 与鸿蒙自身生态的结合:如何优雅地适配鸿蒙的分布式技术?如何用 Flutter 实现设备之间的快速连接、资源共享?现有的众多 Flutter 插件如何应用到鸿蒙系统上?未来 MTFlutter 团队将在这些方面做更深入的探索,因为解决好这些问题,才是真正能让应用覆盖用户生活的全场景的关键。


作者:美团技术团队
链接:https://juejin.cn/post/6920862050952413197
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Flutter PlatformView 在闲鱼直播业务中的实践

背景 闲鱼近期实现了端上直播间的 Flutter 技术重构,验证和拓展了 Flutter 在音视频领域的业务边界。因为直播丰富的玩法和可变的交互,通常我们会在直播间页面覆盖一层互动层,用于处理和展示业务互动行为。这一互动层,通常是由 H5/Weex 等技术来实...
继续阅读 »

背景


闲鱼近期实现了端上直播间的 Flutter 技术重构,验证和拓展了 Flutter 在音视频领域的业务边界。因为直播丰富的玩法和可变的交互,通常我们会在直播间页面覆盖一层互动层,用于处理和展示业务互动行为。这一互动层,通常是由 H5/Weex 等技术来实现的,以满足动态性和业务投放的需求。因为其背后有着一整套配套的解决方案和能力,显然在 Flutter 场景下,复用或移植成熟的 Native 能力是比较好的解决方案,PlatformView 是最适合用于实现该组件的技术,这也是我们采用的方案。


什么是 PlatformView?


PlatformView 技术是 Flutter 提供的一种能够将 Native 组件嵌入到 Flutter 页面中的能力,有了这种能力,一些 Native 上非常成熟的功能组件,例如地图、广告页面、WebView 就可以很方便地和 Flutter 结合,在 Flutter 页面上展示。


实现技术上,iOS 中,PlatformView 的 Native View 会被加入到 Flutter 的 UI 视图层级中,这种方式称之为 Hybrid Composition;而 Android 支持使用 VirtualDisplay 和 Hybrid Composition 两种模式,前者将 Native View 绘制到内存中,然后和 Flutter Widget 一起渲染到 Flutter 页面中,后者和 iOS 上类似。闲鱼目前在 Android 中使用的是 VirtualDisplay 这种模式。


直播间互动层组件


互动层是一个覆盖整个直播间的组件,隶属于某一特定的直播间,可以跟随该直播间上下翻页滑动,一般情况下处于直播间 View 层级的最上层,这样才能做到可以在直播间任意位置布局任意的元素并展示。它是一个背景透明的组件,当用户点击互动层上的元素时,由互动层来进行响应交互,而当用户点击透明区域时,事件会穿透互动层,由下面层级上最合适的组件来进行响应,不影响正常的直播间功能。这就要求我们对该组件的事件分发进行一些处理。这里主要的处理方案是,获取用户的点击位置坐标点,判断组件该像素点的透明度,根据一定的阈值来区分究竟是该由谁来响应。以 iOS 为例,我们知道 iOS 的事件响应分为两个阶段:第一阶段用于寻找最佳响应者,即在 View Tree 上不断调用 hitTest 和 pointInside 方法进行检测,第二阶段才是真正响应事件。所以对于 iOS 实现来说 ,我们只要干预第一阶段,重写该互动层 View 的 pointInside 方法增加上我们的透明度判断逻辑,就可以实现。Android 也是进行类似的处理。


[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wV7LXOVn-1636119253919)(https://upload-images.jianshu.io/upload_images/27208383-1a3401d11fb3db0a.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]


PlatformView 互动层的事件分发问题


虽然通过 PlatformView 可以很方便地嵌入互动层 Native View,但在这个场景下事件处理遇到了一些麻烦。通常情况下,如果嵌入的 PlatformView 是一个正常响应事件的组件,那一般不会有问题,但由上面的分析可知,我们需要对事件进行特殊处理,因为互动层 PlatformView 处于整个直播间的最上层,所以正常情况下,所有它下面的 Flutter 组件都无法响应事件。我们可以将 PlatformView 的 hitTestBehavior 设置为 PlatformViewHitTestBehavior.transparent,这样可以将事件穿透到下面其他的 Flutter 组件,但是互动层本身就无法响应事件了。


PlatformView 有两个身份,一个是作为 Native View,另外一个是作为 Flutter 组件树上的一个节点(Widget),因此它上面的事件由两部分共同配合处理。


所以我们需要先探究一下 Flutter 框架是如何处理 PlatformView 在 Native 和 Flutter 两侧的事件分发和控制的,下面以 iOS 为例来进行具体分析。


PlatformView 事件响应分析


在这里插入图片描述



由 UI 层级图和下面的源码可以看出,PlatformView 是 FlutterView 的 subView。源码中的 embeded_view 是我们真正提供给 Flutter 的 Native View,它会传递给 FlutterTouchInterceptingView 的构造方法,成为其 subView,FlutterTouchInterceptingView 又是 ChildClippingView 的 subView。



FlutterTouchInterceptingView


这几个 view 中,FlutterTouchInterceptingView 是 Flutter 用来控制和处理 PlatformView 事件的关键。Flutter 需要有这个一个View 来拦截事件,因为事件毕竟是从 Native 传递给 Flutter 的,而 PlatformView 本身也是个 Native View,如果不对作用在 PlatformView 上的事件进行拦截的话,PlatformView 自身就会消化掉事件,而 Flutter 侧则感知不到也没法控制了。



FlutterTouchInterceptingView 的 frame 和 embededView 保持一致,并作为其 superView,根据 iOS 的事件传递规则,FlutterTouchInterceptingView 会先接收到事件。由注释可知,FlutterTouchInterceptingView 实现了两个能力:一是它会延迟或者阻止事件到达 embededView;二是它会将所有的事件直接转发给 FlutterView。而这两点,分别是由 DelayingGestureRecognizer 和 ForwardingGestureRecognizer 这两个手势来完成的。
在这里插入图片描述


DelayingGestureRecognizer


DelayingGestureRecognizer 需要延迟其他事件响应,并且将除了 ForwardingGestureRecognizer 之外的其他手势都失效。



DelayingGestureRecognizer 是添加在 embededView 的 superView(FlutterTouchInterceptingView) 上的手势(Gesture),之所以能够起作用拦截 embededView 的手势和事件,原因在于 iOS 的手势识别优先级高于普通的事件响应,且响应链一旦确定,每次事件响应,整条响应链上手势的 delegate 方法都会被调用,用于确定最终可以识别的手势。如下图,如果触摸了 View4,确定 View 4 为最佳响应者,则从 View4 到 rootView 上的所有手势(gesture2、gesture3、gesture4、gesture5)的 delegate 方法都会被调用。
在这里插入图片描述


ForwardingGestureRecognizer


ForwardingGestureRecognizer 的实现就很简单了,它重写了事件的相关处理方法,将事件直接转发。


在这里插入图片描述


因为 PlatformView 也作为 Flutter Widget Tree 的一个节点,事件转发到 Flutter 之后,遵循 Flutter 的事件处理机制,和其他手势一起在竞技场(Arena)中角逐是否能够响应。最终如果竞争成功,事件该由 PlatformView 来响应,则 FlutterTouchInterceptingView 的 releaseGesture 方法会被调用,DelayingGestureRecognizer 手势会被置成 Failed 状态,其他事件就可以开始响应。相应地如果竞争失败,那么 FlutterTouchInterceptingView 的 blockGesture 方法会被调用,DelayingGestureRecognizer 手势会被置成 Ended 状态,这表明事件被它响应并且完成了,其他手势或者 View 响应者就不会再响应该事件了。
在这里插入图片描述
在这里插入图片描述


解决事件分发问题


由上面 iOS 上的的事件原理可知,Flutter 主要是通过 DelayingGestureRecoginzer 和 ForwardingGestureRecoginizer 这两个手势来干预和控制 PlatformView 上 Native 的事件分发行为。所以可以想到,如果没有这两个事件,事件的响应又会和我们熟悉的 Native 流程一致。


所以想要自定义 PlatformView 事件分发,在 iOS 上我们可以这么做:


1.根据需要设置 PlatformView Widget 的 hitTestBehavior 参数;


2.重写 PlatformView 的 pointInside 方法,在里面增加控制 Flutter 这两个手势的逻辑。因为 hitTest 寻找最佳响应者的过程一定在响应链响应之前,所以此处对 Flutter 手势的处理,不会影响事件转发给 Flutter 后的处理逻辑。
在这里插入图片描述


具体到直播互动场景来说,为了能让事件在大多数情况下能够被互动层下面的组件响应,在 Flutter 侧 PlatformView Widget 的 hitTestBehavior 需要设置为 PlatformViewHitTestBehavior.transparent,目的是为了让 PlatformView Widget 之下的 Flutter Widget 可以响应事件。重写 PlatformView 的 pointInside,如果透明度判断认为该由互动层来响应,则禁用 Flutter 的这两个手势;如果不该由互动层响应(即该由其他 Flutter 组件来响应),则恢复这两个手势响应,不影响正常的逻辑。相关实现代码如下:


[图片上传失败...(image-1c9fb8-1636119207800)]


因为 DelayingGestureRecoginzer 和 ForwardingGestureRecoginizer 这两个手势是定义在 FlutterTouchInterceptingView 中,而 FlutterTouchInterceptingView 是我们互动层 Native View 的 superView,所以代码中的 self.fluttterForwardGestureRecognizer 和 self.flutterDelayingGestureRecognizer 可以通过反射、循环遍历 superView 的手势列表来获取到。


关于 Android 上的处理


因为 Android 上 PlatfromView 采用了 VirtualDisplay 方案实现的,所以 FlutterView 和 PlatfromView 并不是真正处于同一个 ViewTree 中,因而在这个问题的处理上面和 iOS 略有不同,但原理相通。这里简单的说一下Android 上面的情况。


PlatformView 原本的设计中是由 FlutterView 接收 Android 的原生 TouchEvent,然后转化为 Flutter 中用于事件处理的 Event,再分发给 Flutter中 的 Widget。当 PlatformView 的 Widget(AndroidView)接收到事件后,会再次将事件转化为 Android 的 TouchEvent,然后转给 Native 的 PlatformView 实现 View。如图:


[图片上传失败...(image-7e84ed-1636119207800)]


我们可以在 FlutterView 外面再套一层用于事件处理的 View(EventInterceptView),该 View 会优先接收到事件,然后根据实际需要,决定事件转发给 FlutterView 还是 PlatformView。如图:
在这里插入图片描述


通过上述方案,我们在 iOS 和 Android 两端都可以做到在 PlatformView 互动层中实现透明度判断逻辑,并交给正确的响应者(Flutter 组件或者 Native View)来进行事件响应。使用 PlatformView 也让我们最大限度地复用了直播互动层背后对应的一整套解决方案,业务能力和使用体验都达到了和 Native 原生实现一样的效果。


写在最后


PlatformView 提供了在 Flutter 页面中嵌入 Native View 的能力,方便了很多业务场景和功能的实现,但 PlatformView 技术也还存在一些问题,例如使用了 PlatformView 在某些场景下可能会导致图片、视频的纹理错乱等。闲鱼在直播业务中第一次在生产环境中使用了 PlatformView 技术,也解决了一些已知问题,但仍有很多问题是我们还没有发现和解决的,后续我们也会继续在这方面进行研究,探索使用 PlatformView 的最佳实践!


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