不同应用在各自独立的进程中运行。当应用以任何形式启动时，系统为其创建进程，该进程将持续运行。当进程完成当前任务处于等待状态，且系统资源不足时，系统自动回收。
成都创新互联公司 - 遂宁托管服务器，四川服务器租用，成都服务器租用，四川网通托管,绵阳服务器托管，德阳服务器托管，遂宁服务器托管，绵阳服务器托管，四川云主机，成都云主机，西南云主机，遂宁托管服务器，西南服务器托管，四川/成都大带宽，服务器机柜，四川老牌ＩＤＣ服务商
在启动应用时，系统会为该应用创建一个称为“主线程”的执行线程。该线程随着应用创建或消失，是应用的核心线程。UI界面的显示和更新等操作，都是在主线程上进行。主线程又称UI线程，默认情况下，所有的操作都是在主线程上执行。如果需要执行比较耗时的任务（如下载文件、查询数据库），可创建其他线程来处理。
如果应用的业务逻辑比较复杂，可能需要创建多个线程来执行多个任务。这种情况下，代码复杂难以维护，任务与线程的交互也会更加繁杂。要解决此问题，开发者可以使用“TaskDispatcher”来分发不同的任务。
TaskDispatcher是一个任务分发器，它是“能力”分发任务的基本接口，隐藏任务所在线程的实现细节。
为保证应用有更好的响应性，我们需要设计任务的优先级。在UI线程上运行的任务默认以高优先级运行，如果某个任务无需等待结果，则可以用低优先级。
线程优先级：
① 高优先级 HIGH
② 默认优先级 DEFAULT
③ 低优先级 LOW
TaskDispatcher具有多种实现，每种实现对应不同的任务分发器。在分发任务时可以指定任务的优先级，由同一个任务分发器分发出的任务具有相同的优先级。
系统提供的任务分发器有：
① 全局并发任务分发器 GlobalTaskDispatcher
② 并发任务分发器 ParallelTaskDispatcher
③ 串行任务分发器 SerialTaskDispatcher
④ 专有任务分发器 SpecTaskDispatcher
3.1，全局并发任务分发器，由Ability执行getGlobalTaskDispatcher()获取。适用于任务之间没有联系的情况。一个应用只有一个GlobalTaskDispatcher，它在程序结束时才被销毁。
3.2，并发任务分发器，由Ability执行createParallelTaskDispatcher()创建并返回。与GlobalTaskDispatcher不同的是，ParallelTaskDispatcher不具有全局唯一性，可以创建多个。开发者在创建或销毁dispatcher时，需要持有对应的对象引用 。
3.3，串行任务分发器，由Ability执行createSerialTaskDispatcher()创建并返回。由该分发器分发的所有的任务都是按顺序执行，但是执行这些任务的线程并不是固定的。如果要执行并行任务，应使用ParallelTaskDispatcher或者GlobalTaskDispatcher，而不是创建多个SerialTaskDispatcher。如果任务之间没有依赖，应使用GlobalTaskDispatcher来实现。它的创建和销毁由开发者自己管理，开发者在使用期间需要持有该对象引用。
3.4，专有任务分发器，绑定到专有线程上的任务分发器。目前已有的专有线程为UI线程，通过UITaskDispatcher进行任务分发。
UITaskDispatcher：绑定到应用主线程的专有任务分发器， 由Ability执行getUITaskDispatcher()创建并返回。 由该分发器分发的所有的任务都是在主线程上按顺序执行，它在应用程序结束时被销毁。
Ability
Ability是应用所具备能力的抽象
2.onActive()
Page会在进入INACTIVE状态后来到前台，然后系统调用此回调。Page在此之后进入ACTIVE状态，该状态是应用与用户交互的状态。Page将保持在此状态，除非某类事件发生导致Page失去焦点，比如用户点击返回键或导航到其他Page。当此类事件发生时，会触发Page回到INACTIVE状态，系统将调用onInactive()回调。此后，Page可能重新回到ACTIVE状态，系统将再次调用onActive()回调。因此，开发者通常需要成对实现onActive()和onInactive()，并在onActive()中获取在onInactive()中被释放的资源。
3.onInactive()
当Page失去焦点时，系统将调用此回调，此后Page进入INACTIVE状态。开发者可以在此回调中实现Page失去焦点时应表现的恰当行为。
4.onBackground()
如果Page不再对用户可见，系统将调用此回调通知开发者用户进行相应的资源释放，此后Page进入BACKGROUND状态。开发者应该在此回调中释放Page不可见时无用的资源，或在此回调中执行较为耗时的状态保存操作。
5.onForeground()
处于BACKGROUND状态的Page仍然驻留在内存中，当重新回到前台时（比如用户重新导航到此Page），系统将先调用onForeground()回调通知开发者，而后Page的生命周期状态回到INACTIVE状态。开发者应当在此回调中重新申请在onBackground()中释放的资源，最后Page的生命周期状态进一步回到ACTIVE状态，系统将通过onActive()回调通知开发者用户。
6.onStop()
系统将要销毁Page时，将会触发此回调函数，通知用户进行系统资源的释放。销毁Page的可能原因包括以下几个方面：
用户通过系统管理能力关闭指定Page，例如使用任务管理器关闭Page。
用户行为触发Page的terminateAbility()方法调用，例如使用应用的退出功能。
配置变更导致系统暂时销毁Page并重建。
系统出于资源管理目的，自动触发对处于BACKGROUND状态Page的销毁。
AbilitySlice生命周期
AbilitySlice生命周期回调与Page的相应回调类似，因此不再赘述。由于AbilitySlice承载具体的页面，开发者必须重写AbilitySlice的onStart()回调，并在此方法中通过setUIContent()方法设置页面。
Page与AbilitySlice生命周期关联
当AbilitySlice处于前台且具有焦点时，其生命周期状态随着所属Page的生命周期状态的变化而变化。当一个Page拥有多个AbilitySlice时，例如：MyAbility下有FooAbilitySlice和BarAbilitySlice，当前FooAbilitySlice处于前台并获得焦点，并即将导航到BarAbilitySlice，在此期间的生命周期状态变化顺序为：
对应两个slice的生命周期方法回调顺序为：
FooAbilitySlice.onInactive() -- BarAbilitySlice.onStart() -- BarAbilitySlice.onActive() -- FooAbilitySlice.onBackground()
在整个流程中，MyAbility始终处于ACTIVE状态。但是，当Page被系统销毁时，其所有已实例化的AbilitySlice将联动销毁，而不仅是处于前台的AbilitySlice。
在基于鸿蒙SDK开发完成应用后，可以通过 Build - Build Hap(s)/APP(s) 编译后，在 项目根目录/build/outputs/app/release/ 目录下生成两个文件: xxx_unsigned.app 和 xxx_signed.app。在某些情况下可能需要使用 xxx_unsigned.app 文件，然后使用同步的签名文件对文件进行签名。
那么问题来了，怎么对未签名的文件进行重新签名呢？这个文件就是本文想要解决的问题。
在 DevEco Studio 中有一个 hapsigntoolv2.jar 。通过这个 jar 包可以对应用进行重签名。签名脚本内容如下：
将上面内容写到一个 signer.sh 文件中保持。通过下面指令赋给脚本文件可行的权限：
至此，一个简单的签名工具已经完成。
上面章节已经完成一个简单的签名工具 signer.sh。使用方式如下:
如果执行成功，则会生成 xxx_signed.app 文件。
然后尝试运行一下试试吧。
