13518219792
原因可能是：应用程序发生异常未知的软件异常
成都创新互联公司是一家专注网站建设、网络营销策划、微信小程序开发、电子商务建设、网络推广、移动互联开发、研究、服务为一体的技术型公司。公司成立十余年以来，已经为近千家宣传片制作各业的企业公司提供互联网服务。现在，服务的近千家客户与我们一路同行，见证我们的成长；未来，我们一起分享成功的喜悦。
1.病毒木马造成的，在当今互联网时代，病毒坐着为了获得更多的牟利，常用病毒绑架应用程序和系统文件，然后某些安全杀毒软件把被病毒木马感染的应用程序和系统文件当病毒杀了导致的。
2.应用程序组件丢失，应用程序完整的运行需要一些系统文件或者某些ll文件支持的，如果应用程序组件不完整也会导致的。
3.系统文件损坏或丢失，盗版系统或Ghost版本系统，很容易出现该问题。
4.操作系统自身的问题，操作系统本身也会有bug。
5.硬件问题，例如内存条坏了或者存在质量问题，或者内存条的金手指的灰尘特别多。
1、首先测试一下硬件是否有问题。
2、其次可以尝试一下恢复出厂设置，如果没问题可以刷机解决。
3、如果有问题就需要到售后联系专业人员处理。
《【转+补充】深入研究js中的位运算及用法》
《【JS时间戳】获取时间戳的最快方式探究》
日常开发中一直没遇到过位运算导致精度丢失的问题，直到这天，搞10位时间戳取整的时候，终于被我撞上了。具体是个什么场景呢，我们来还原下案发现场：
可以看到输出的结果为：
得到的 t 是一个精确到微秒的时间戳。但是请求接口的时候需要的是一个10位（精确到秒）的时间戳，所以这里需要将它转换为10位，自然就是 ➗1000 即可，然后通过位运算来实现类似 Math.trunc 的取证效果，得到了我们要的10位时间戳。至此完美解决！那问题又是如何发生的呢？
按照上面的运算规律，如果我们要获取13位时间戳，是不是直接对 t0 就可以了呢？我们来看一下：
输出结果如下：
WTF!!!看到了咩！！！居然输出了一个负数！！！我们想要的结果应该是 1597113682985 才对啊！为什么会出现了负数呢！！！
由此，怪物出现啦！我们今天就来解读（xiang fu)一下它！
想到这里，我们一定就会怪是位运算的锅！那这个锅该怎么让位运算背起来呢！我们来研究一下！
首先我们知道，JS中没有真正的整型，数据都是以double(64bit)的标准格式存储的，这里就不再赘述了，要想搞透其中的原理，请打开 【传送门】
位运算是在数字底层（即表示数字的 32 个数位）进行运算的。由于位运算是低级的运算操作，所以速度往往也是最快的（相对其它运算如加减乘除来说），并且借助位运算有时我们还能实现更简单的程序逻辑,缺点是很不直观，许多场合不能够使用。
以下来源于w3shool:
ECMAScript 整数有两种类型，即有符号整数（允许用正数和负数）和无符号整数（只允许用正数）。 在 ECMAScript 中，所有整数字面量默认都是有符号整数 ，这意味着什么呢？
有符号整数使用 31 位表示整数的数值，用第 32 位表示整数的符号，0 表示正数，1 表示负数。数值范围从 -2147483648 到 2147483647 。
可以以两种不同的方式存储二进制形式的有符号整数，一种用于存储正数，一种用于存储负数。 正数是以真二进制形式存储的 ，前 31 位中的每一位都表示 2 的幂，从第 1 位（位 0）开始，表示 20，第 2 位（位 1）表示 21。没用到的位用 0 填充，即忽略不计。例如，下图展示的是数 18 的表示法。
那在js中二进制和十进制如何转换呢？如下
负数同样以二进制存储，但使用的格式是二进制补码。计算一个数值的二进制补码，需要经过下列3个步骤：
例如，要确定-18的二进制表示，首先必须得到18的二进制表示，如下所示：
0000 0000 0000 0000 0000 0000 0001 0010
接下来，计算二进制反码，如下所示：
1111 1111 1111 1111 1111 1111 1110 1101
最后，在二进制反码上加 1，如下所示：
1111 1111 1111 1111 1111 1111 1110 1101 +
0000000000000000000000000000 0001 =
1111 1111 1111 1111 1111 1111 1110 1110
因此，-18 的二进制就是 1111 1111 1111 1111 1111 1111 1110 1110
而其相反数18的二进制为 0000 0000 0000 0000 0000 0000 0001 0010
ECMAScript会尽力向我们隐藏所有这些信息，在以二进制字符串形式输出一个负数时，我们看到的只是这个负数绝对值的二进制码前面加上了一个负号
JavaScript 只有一种数字类型 ( Number )
我们将 1596596596.3742654.toString(2) 转为二进制字符串表示如下：
1011111001010100010000101110100.0101111111001111110111
但实际在内存中的存储如下：
说到这里就不得不简单提一下数字精度丢失的问题。上面也知道，JS中所有的数字都是用double方式进行存储的，所以必然会存在精度丢失问题。
以下转自文章： JavaScript数字精度丢失问题总结
此时只能模仿十进制进行四舍五入了，但是二进制只有 0 和 1 两个，于是变为 0 舍 1 入。这即是计算机中部分浮点数运算时出现误差，丢失精度的根本原因。
大整数的精度丢失和浮点数本质上是一样的，尾数位最大是 52 位，因此 JS 中能精准表示的最大整数是 Math.pow(2, 53) ，十进制即 9007199254740992
大于 9007199254740992 的可能会丢失精度：
9007199254740992 10000000000000...000 ``// 共计 53 个 0
9007199254740992 + 1 10000000000000...001 ``// 中间 52 个 0
9007199254740992 + 2 10000000000000...010 ``// 中间 51 个 0
实际上
9007199254740992 + 1 ``// 丢失
9007199254740992 + 2 ``// 未丢失
9007199254740992 + 3 ``// 丢失
9007199254740992 + 4 ``// 未丢失
以上，可以知道看似有穷的数字, 在计算机的二进制表示里却是无穷的，由于存储位数限制因此存在“舍去”，精度丢失就发生了。
想了解更深入的分析可以看这篇论文（你品！你细品！）： What Every Computer Scientist Should Know About Floating-Point Arithmetic
关于精度和范围的内容可查看 【JS的数值精度和数值范围】
通过前面的知识补充，我们已经知道：
这也就是为什么对于整数部位为10位的时间戳，通过位运算可以进行取整（因为目前时间戳159xxxxxxx2147483647），不存在时间戳超过范围的问题。但是对于13位时间戳，如 15966154471232147483647 ，此时再通过位运算操作的时候就会导致异常，如：
这主要是因为在进行位运算之前，JS会先将64bit的浮点数 1596615447015.01 转为32bit的有符号整型后进行运算的，这个转换过程如下：
为了验证上述过程，我们再举一个例子： 1590015447015.123 0 = 877547495
将将将将！没错的吧！所以JS的这个坑还真是。。。 让人Orz
一、JavaScript异步编程的两个核心难点
异步I/O、事件驱动使得单线程的JavaScript得以在不阻塞UI的情况下执行网络、文件访问功能，且使之在后端实现了较高的性能。然而异步风格也引来了一些麻烦，其中比较核心的问题是：
1、函数嵌套过深
JavaScript的异步调用基于回调函数，当多个异步事务多级依赖时，回调函数会形成多级的嵌套，代码变成
金字塔型结构。这不仅使得代码变难看难懂，更使得调试、重构的过程充满风险。
2、异常处理
回调嵌套不仅仅是使代码变得杂乱，也使得错误处理更复杂。这里主要讲讲异常处理。
二、异常处理
像很多时髦的语言一样，JavaScript 也允许抛出异常，随后再用一个try/catch
语句块捕获。如果抛出的异常未被捕获，大多数JavaScript环境都会提供一个有用的堆栈轨迹。举个例子，下面这段代码由于'{'为无效JSON
对象而抛出异常。
?
12345678
function JSONToObject(jsonStr) { return JSON.parse(jsonStr);}var obj = JSONToObject('{');//SyntaxError: Unexpected end of input//at Object.parse (native)//at JSONToObject (/AsyncJS/stackTrace.js:2:15)//at Object.anonymous (/AsyncJS/stackTrace.js:4:11)
堆栈轨迹不仅告诉我们哪里抛出了错误，而且说明了最初出错的地方：第4 行代码。遗憾的是，自顶向下地跟踪异步错误起源并不都这么直截了当。
异步编程中可能抛出错误的情况有两种：回调函数错误、异步函数错误。
1、回调函数错误
如果从异步回调中抛出错误，会发生什么事？让我们先来做个测试。
?
1234567
setTimeout(function A() { setTimeout(function B() { setTimeout(function C() { throw new Error('Something terrible has happened!'); }, 0); }, 0);}, 0);
上述应用的结果是一条极其简短的堆栈轨迹。
?
12
Error: Something terrible has happened!at Timer.C (/AsyncJS/nestedErrors.js:4:13)
等等，A 和B 发生了什么事？为什么它们没有出现在堆栈轨迹中？这是因为运行C 的时候，异步函数的上下文已经不存在了，A 和B 并不在内存堆栈里。这3
个函数都是从事件队列直接运行的。基于同样的理由，利用try/catch
语句块并不能捕获从异步回调中抛出的错误。另外回调函数中的return也失去了意义。
?
1234567
try { setTimeout(function() { throw new Error('Catch me if you can!'); }, 0);} catch (e) {console.error(e);}
看到这里的问题了吗？这里的try/catch 语句块只捕获setTimeout函数自身内部发生的那些错误。因为setTimeout
异步地运行其回调，所以即使延时设置为0，回调抛出的错误也会直接流向应用程序。
总的来说，取用异步回调的函数即使包装上try/catch 语句块，也只是无用之举。（特例是，该异步函数确实是在同步地做某些事且容易出错。例如，Node
的fs.watch(file,callback)就是这样一个函数，它在目标文件不存在时会抛出一个错误。）正因为此，Node.js
中的回调几乎总是接受一个错误作为其首个参数，这样就允许回调自己来决定如何处理这个错误。
2、异步函数错误
由于异步函数是立刻返回的，异步事务中发生的错误是无法通过try-catch来捕捉的，只能采用由调用方提供错误处理回调的方案来解决。
例如Node中常见的function (err, ...)
{...}回调函数，就是Node中处理错误的约定：即将错误作为回调函数的第一个实参返回。再比如HTML5中FileReader对象的onerror函数，会被用于处理异步读取文件过程中的错误。
举个例子，下面这个Node 应用尝试异步地读取一个文件，还负责记录下任何错误（如“文件不存在”）。
?
1234567
var fs = require('fs'); fs.readFile('fhgwgdz.txt', function(err, data) { if (err) { return console.error(err); }; console.log(data.toString('utf8'));});
客户端JavaScript 库的一致性要稍微差些，不过最常见的模式是，针对成败这两种情形各规定一个单独的回调。jQuery 的Ajax
方法就遵循了这个模式。
?
1234
$.get('/data', { success: successHandler, failure: failureHandler});
不管API 形态像什么，始终要记住的是，只能在回调内部处理源于回调的异步错误。
三、未捕获异常的处理
如果是从回调中抛出异常的，则由那个调用了回调的人负责捕获该异常。但如果异常从未被捕获，又会怎么样？这时，不同的JavaScript环境有着不同的游戏规则……
1. 在浏览器环境中
现代浏览器会在开发人员控制台显示那些未捕获的异常，接着返回事件队列。要想修改这种行为，可以给window.onerror
附加一个处理器。如果windows.onerror 处理器返回true，则能阻止浏览器的默认错误处理行为。
?
123
window.onerror = function(err) { return true; //彻底忽略所有错误};
在成品应用中， 会考虑某种JavaScript 错误处理服务， 譬如Errorception。Errorception
提供了一个现成的windows.onerror 处理器，它向应用服务器报告所有未捕获的异常，接着应用服务器发送消息通知我们。
2. 在Node.js 环境中
在Node 环境中，window.onerror 的类似物就是process 对象的uncaughtException 事件。正常情况下，Node
应用会因未捕获的异常而立即退出。但只要至少还有一个uncaughtException 事件处理
器，Node 应用就会直接返回事件队列。
?
123
process.on('uncaughtException', function(err) { console.error(err); //避免了关停的命运！});
但是，自Node 0.8.4 起，uncaughtException 事件就被废弃了。据其文档所言，对异常处理而言，uncaughtException
是一种非常粗暴的机制，请勿使用uncaughtException，而应使用Domain 对象。
Domain 对象又是什么？你可能会这样问。Domain 对象是事件化对象，它将throw 转化为'error'事件。下面是一个例子。
?
123456789
var myDomain = require('domain').create();myDomain.run(function() { setTimeout(function() { throw new Error('Listen to me!') }, 50);});myDomain.on('error', function(err) { console.log('Error ignored!');});
源于延时事件的throw 只是简单地触发了Domain 对象的错误处理器。
Error ignored!
很奇妙，是不是？Domain 对象让throw
语句生动了很多。不管在浏览器端还是服务器端，全局的异常处理器都应被视作最后一根救命稻草。请仅在调试时才使用它。
四、几种解决方案
下面对几种解决方案的讨论主要集中于上面提到的两个核心问题上，当然也会考虑其他方面的因素来评判其优缺点。
1、Async.js
首先是Node中非常著名的Async.js，这个库能够在Node中展露头角，恐怕也得归功于Node统一的错误处理约定。
而在前端，一开始并没有形成这么统一的约定，因此使用Async.js的话可能需要对现有的库进行封装。
Async.js的其实就是给回调函数的几种常见使用模式加了一层包装。比如我们需要三个前后依赖的异步操作，采用纯回调函数写法如下：
?
12345678910111213141516
asyncOpA(a, b, (err, result) = { if (err) { handleErrorA(err); } asyncOpB(c, result, (err, result) = { if (err) { handleErrorB(err); } asyncOpB(d, result, (err, result) = { if (err) { handlerErrorC(err); } finalOp(result); }); });});
如果我们采用async库来做：
?
12345678910111213141516171819202122
async.waterfall([ (cb) = { asyncOpA(a, b, (err, result) = { cb(err, c, result); }); }, (c, lastResult, cb) = { asyncOpB(c, lastResult, (err, result) = { cb(err, d, result); }) }, (d, lastResult, cb) = { asyncOpC(d, lastResult, (err, result) = { cb(err, result); }); }], (err, finalResult) = { if (err) { handlerError(err); } finalOp(finalResult);});
可以看到，回调函数由原来的横向发展转变为纵向发展，同时错误被统一传递到最后的处理函数中。
其原理是，将函数数组中的后一个函数包装后作为前一个函数的末参数cb传入，同时要求：
每一个函数都应当执行其cb参数;cb的第一个参数用来传递错误。我们可以自己写一个async.waterfall的实现：
?
12345678910111213141516171819202122
let async = { waterfall: (methods, finalCb = _emptyFunction) = { if (!_isArray(methods)) { return finalCb(new Error('First argument to waterfall must be an array of functions')); } if (!methods.length) { return finalCb(); } function wrap(n) { if (n === methods.length) { return finalCb; } return function (err, ...args) { if (err) { return finalCb(err); } methods[n](...args, wrap(n + 1)); } } wrap(0)(false); }};
Async.js还有series/parallel/whilst等多种流程控制方法，来实现常见的异步协作。
Async.js的问题：
在外在上依然没有摆脱回调函数，只是将其从横向发展变为纵向，还是需要程序员熟练异步回调风格。
错误处理上仍然没有利用上try-catch和throw，依赖于“回调函数的第一个参数用来传递错误”这样的一个约定。
2、Promise方案
ES6的Promise来源于Promise/A+。使用Promise来进行异步流程控制，有几个需要注意的问题，
把前面提到的功能用Promise来实现，需要先包装异步函数，使之能返回一个Promise：
?
12345678910
function toPromiseStyle(fn) { return (...args) = { return new Promise((resolve, reject) = { fn(...args, (err, result) = { if (err) reject(err); resolve(result); }) }); };}
这个函数可以把符合下述规则的异步函数转换为返回Promise的函数：
回调函数的第一个参数用于传递错误，第二个参数用于传递正常的结果。接着就可以进行操作了：
?
123456789101112131415
let [opA, opB, opC] = [asyncOpA, asyncOpB, asyncOpC].map((fn) = toPromiseStyle(fn)); opA(a, b) .then((res) = { return opB(c, res); }) .then((res) = { return opC(d, res); }) .then((res) = { return finalOp(res); }) .catch((err) = { handleError(err); });
通过Promise，原来明显的异步回调函数风格显得更像同步编程风格，我们只需要使用then方法将结果传递下去即可，同时return也有了相应的意义：
在每一个then的onFullfilled函数（以及onRejected）里的return，都会为下一个then的onFullfilled函数（以及onRejected）的参数设定好值。
如此一来，return、try-catch/throw都可以使用了，但catch是以方法的形式出现，还是不尽如人意。
3、Generator方案
ES6引入的Generator可以理解为可在运行中转移控制权给其他代码，并在需要的时候返回继续执行的函数。利用Generator可以实现协程的功能。
将Generator与Promise结合，可以进一步将异步代码转化为同步风格：
?
1234567891011
function* getResult() { let res, a, b, c, d; try { res = yield opA(a, b); res = yield opB(c, res); res = yield opC(d); return res; } catch (err) { return handleError(err); }}
然而我们还需要一个可以自动运行Generator的函数：
?
123456789101112131415161718192021222324252627282930
function spawn(genF, ...args) { return new Promise((resolve, reject) = { let gen = genF(...args); function next(fn) { try { let r = fn(); if (r.done) { resolve(r.value); } Promise.resolve(r.value) .then((v) = { next(() = { return gen.next(v); }); }).catch((err) = { next(() = { return gen.throw(err); }) }); } catch (err) { reject(err); } } next(() = { return gen.next(undefined); }); });}
用这个函数来调用Generator即可：
?
1234567
spawn(getResult) .then((res) = { finalOp(res); }) .catch((err) = { handleFinalOpError(err); });
可见try-catch和return实际上已经以其原本面貌回到了代码中，在代码形式上也已经看不到异步风格的痕迹。
类似的功能有co/task.js等库实现。
4、ES7的async/await
ES7中将会引入async function和await关键字，利用这个功能，我们可以轻松写出同步风格的代码，
同时依然可以利用原有的异步I/O机制。
采用async function，我们可以将之前的代码写成这样：
?
12345678910111213
async function getResult() { let res, a, b, c, d; try { res = await opA(a, b); res = await opB(c, res); res = await opC(d); return res; } catch (err) { return handleError(err); }} getResult();
和Generator Promise方案看起来没有太大区别，只是关键字换了换。
实际上async
function就是对Generator方案的一个官方认可，将之作为语言内置功能。
async function的缺点：
await只能在async function内部使用，因此一旦你写了几个async function，或者使用了依赖于async
function的库，那你很可能会需要更多的async function。
目前处于提案阶段的async
function还没有得到任何浏览器或Node.JS/io.js的支持。Babel转码器也需要打开实验选项，并且对于不支持Generator的浏览器来说，还需要引进一层厚厚的regenerator
runtime，想在前端生产环境得到应用还需要时间。
以上就是本文的全部内容，希望对大家的学习有所帮助。
